y.takky　てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

トップ > エンジニアリングマネージャー と 目標設定　NTT Com Open TechLunch #7　聴講メモ

エンジニアリングマネージャー と 目標設定　NTT Com Open TechLunch #7　聴講メモ

概要

https://twitter.com/hashtag/techlunch

  • ちなみに自分はNTTコミュニケーションズやNTT関連の企業とは全く関係ない企業に所属しているので、以下記事中の社は私の所属している社のことを指しているのでその点だけ注意

この勉強会に参加しようと思った理由

  • 社の目標設定の期間でいろいろと悩んでいた
    • ただでさえ目標設定に関してはネガティブなイメージを持っているのに目標設定に使うツールに関して人事と一悶着あったりなかったりしたのでさらにネガティブになっている状態であった。
    • そもそも、目標ってなんぞや？とか組織上マネージャが正しく評価できるわけないじゃんね。みたいなところを抱えていた
  • ちょうど以下のtwitterを見かけて時間も合うし参加してみようかなと思っていた (フォロワーのRTかtwitterのおすすめに流れてきたやつと思う)
  • 今回の発表者の吉羽 龍太郎さんの著書は何冊か読んでいて(SCRUM BOOT CAMP THE BOOKが一番好き)、この方の発表であれば納得感と何かしら得るものがあるのではないかなと思い参加した。

以下聴講メモ

目標設定の基本

  • よく言われること
  • 定量的に判断できるようにしましょう？
    • これはまぁまぁ怪しい
  • 大事なのは、定量的に判断できるということではないよね
  • そもそも目的と目標は別のもの
目的 : 最終的に達成したいこと
目標 : 目的を達成するための手段

上記は辞書的な定義からの引用(goo国語辞典)

  • つまり目的が上にあるよね？
  • なので、目的に立ち戻って考える必要がある

企業の目的

  • 企業とは何かを決めるのは顧客である（ピーダー・ドラッカー : マネジメント)
  • 企業の目的の定義は顧客の創造である
  • ただし、これをブレイクダウンするのは難しい
    • 顧客をキーワードにしてやるのはわかりやすいよね。

顧客との価値交換システムを中心に据える

  • 目標は価値交換システムにどう関係あるかを説明できるように必要がある
  • その目標を満たすことで、どう価値交換システムに影響あるか説明できる必要がある。
  • ただし、全部が価値交換システムに関係あるとは限らない
    • 個人のスキル獲得になるべき
  • 本質的には価値交換システムに関連のある目標であるのが自然ではないか

SMART

  • 目標設定のときに言われるやつ
Specific:具体的
Measurable : 計測可能
Achievable : 達成可能
Related : 関連性がある
Time-bounded: 期限がある
  • Relatedが重要

ビルドトラップ

  • 目標との関連性がないと陥る
  • アウトプットで成功を計測しようとして息詰まる状況。
  • 価値ではなく、機能の開発とリリースに集中してしまっている
  • 機能数、リリース回数、期日までのリリース、プロジェクトの完遂　
  • これは価値交換システムが機能していることを示さない。 Relatedではない

グッドハートの法則が発動

  • 管理のために用いられる測定はすべて信頼できない
  • リリースするって書いてしまったから適当にリリースする必要があるんですよねとか。のハック

多すぎる目標を避ける

  • あれもこれも達成したいは無理
  • 本当に重要なことを数個まで絞り込む
  • 自分の目標を全部口頭で説明できるようにする

目標の検査と適応

  • 半年間や1年前に立てた目標が有効なことは多くない
  • 目標が意味なくなる
  • 月1ぐらいで検査し適応する必要がある

    ツールがあって目標が変えられない

  • 上司との運用で合意する

まとめ

  • Relatedが大事だよ
  • 目標設定と報酬はわけろ。チートが発生する
  • 検査と適応が必要

パネルディスカッション

目標設定と報酬が結びついている状況で、アウトカムを意識しつつ、本人の頑張りを正しく評価できるような目標設定をどうするか？

  • 売上でエンジニアが評価されるのはどうなんだってのはある。
  • 古いシステムの維持の場合、アウトカムは高く見せづらく、アウトプットで評価しがち
  • スクラムだと個人の貢献度がわからないよね

内容

  • 目標設定の成果を見たときに達成率で本当に頑張ったよね？って言えるんだっけ。
  • 会話の土台や目線合わせのために目標があるのであって、評価って目標以外にも諸々あるはずだよね。
  • 1on1などをすることで、キャリアデベロップメントや方向を見るべき
  • 本質的にはマネージャーも現場でみて、振る舞いなどを見るべきではないか
  • そもそもマネージャー一人で評価ができるのか？
  • 他の人のインプットがないと評価できないよね。誰が何をやってるかしらんし
  • やっぱり360度評価みたいなのは必要なのではないか。
  • 目標設定のみで評価を避けるべき
  • アウトカム（業績)　と行動の部分も評価してる（NTT)
  • 評価とかでびっくりさせてはいけない。

成長をサポートする効果的な目標設定・振り返りのやり方

  • 少しストレッチして、目線をあげるような目標設定をさせたい
  • 今季チャレンジしたい事はなにか？
  • これ(=チャレンジしたいことや能力)を伸ばしたければこういう目標設定をすればよいよ。 　　
  • これ(=チャレンジしたいことや能力)がわからない、これがイケてるか、イケてないかは検査と適応でアップデートしようよ。というのが必要
  • 目標自体が更新すべきで、書き方よりは運用
  • ツリー構造っぽくしてブレイクダウンしていく必要がある
  • メンバーによって道のりの粗さは分けて良い。
  • シニアだったら勝手に考えてくれるだろう
  • 日々の運用に組み込むのが重要
  • どこどこの何々システムを導入すれば良いというわけではない。

Q&A

チームで価値を生む場合個人目標はどうする?

  • 個人目標いらなくない？
  • スキル獲得はやったほうがいいけど、それ以外はいらないかもね。

顧客への価値と技術者の評価はどのように紐づくか

  • アジャイルだと全員が同一評価かも。
  • チーム内のエンジニアの個別評価は？
  • 目標設定する上で顧客にどうやって利用されるのか、という部分を意識してもらう。というのはある。
  • 定量だけでなく、定性も入れてもらう。
  • 期待値を伝える
  • なんのために目標設定をしたいんだっけ？ってところがある。
  • 評価のために目標設定をするのであればそれはオプションの一つではないか。
  • 目標設定がなぜ必要なのかを考えるべき
  • 一つの評価では無理

業務とアウトカムとの関連が薄いチームについてどうすべきか

  • 設備保全や社内情シス、終息プロダクト
  • 存在している事自体がアウトカムでそこを握れば良い
  • 目標設定だけで評価決まるだけではないよね？
  • 運用系は難しいよね。

まとめと感想

  • 目標や目標設定の定義づけとすり合わせは必要だなと思った。
  • 制度を変えるのは難しいから、上司との1on1などで合意をとって、頻繁に検査と適応をしていく必要があるよねというのは概ね同意できる。
    • ただそれって、いわゆる運用で回避ってやつだよな...とも思ってしまう
    • 上司（マネージャー）のマネジメント力に引っ張られてしまう可能性が高い。マネージャーガチャが外れると目標設定自体が無意味なものになってしまう危険性があるなと思った。
    • 本質的には評価制度設計者（基本的には人事部だと思うけど）が、 気づいて運用をできるような組織風土づくりをしていくのが大事なんだろうけど、人事はエンジニアリングのことをわからないことが多いと思う（社だけかもしらないけど）のでそれも難しいのかなとも
      • エンジニアリング向けといわゆるセールス向けと評価制度が別になってしまうとそれはそれで対立を生むきっかけになってしまうしな..と
  • やはり、目標設定だけで、人事評価につながる。という部分が根本的にいけないのではないかなと感じた。
  • エンジニア的には根本的なところが直らないともやもやするのでこのもやもやは晴れないなみたいな気がした。