ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

デブサミ2019「【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと」聴講メモ

はじめに

Developers Summit 2019 (Developers Summit 2019)
【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと
スピーカー:山本 学 [ヤフー]
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2019【15-B-2】メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと #devsumiB - Togetter

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

まず伝えたいこと

マネジメントの定義「組織の為に組織の人たちをいきいきとさせ高度な成果を上げる」はドラッカーの言葉を引用した。

そもそも

小さい頃のブロック遊びが楽しかったように、モノ作りは根源的に楽しいこと。だからエンジニアリングは楽しいといえる。

マネジメントに対する印象

マネジメントへの興味がまだ薄そうな周囲の若者にマネジメントへの印象を聞いてみた。

この中で「体制側」と出てくるが、これはプレイヤーには決定事項のみが伝えられ、マネジメント側が全て決めている。その間には越えられない一線がある。ということらしい。

このアンケート結果を受けて、発表の内容を変えることにした。当初はhow-toを中心に資料をまとめていたが、それよりもまずはこのマイナスな印象を払拭することにした。

パフォーマンスの方程式 Robbins (2001)

チームのパフォーマンス=
チームが本来持つ生産性
+プロセスゲイン(協働作業によるシナジー効果・適材適所の役割分担)
+プロセスロス(協働作業による負のシナジー効果・コミュニケーションコスト)

この方程式からチームのパフォーマンスは個人の能力以外にも影響を受けていることが分かる。

また、プレイヤーとマネジメントでは成果の出しどころが違う。

  • プレイヤーの成果の出しどころ
    • チームが本来持つ生産性
  • マネジメントの成果の出しどころ
    • プロセスゲイン
    • プロセスロス

Ep2.はじめてのピープルマネジメント

評価の際はする側とされる側で組織の評価制度のすり合わせから始めた方が良い。面談をしていると、この認識のズレていることが意外と多い。

達成感を感じる瞬間/成長を感じる瞬間

マネジメントの達成感は対象がチームなのでちょっと感じにくいところはある。

だが、(自分の成長だけでなく)メンバーの成長も感じられることをふまえると、もしかするとメンバーよりも達成感を感じやすい面もあるかもしれない。

成長の支援

個人を成長させることができれば、チームとしての生産性も上がる。

なにを/どう学べばいいか分からない

ティーチングが有効。エンジニアリングマネージャーとして、組織での評価や市場価値を上げるために何を学ぶと良いかを教える。これにはエンジニアとしてのバックグラウンドが活きてくるはず。

学ばざるを得ない状況を作る。このままではいけない、周囲に迷惑をかける、という思いがあると動く。
ただ、危機感で動くと初速は出るが、その勢いを継続させるにはポジティブな体験が必要となる。例えば、仕事に活きたとかリスクを回避できたとか。

学んでいるはずだが成長の実感が無い

同じプロジェクトに長く従事していると成長を感じられなくなる。これにはコーチングが有効となる。

1on1で仕事から学んだ経験やメタ知識を掘り出してあげる。

エンジニアがアウトプットしやすい環境づくり

オープンな勉強会を会社主催で開催することで、広くフィードバックを得られるようにしている。

楽しくマネジメントを続けるためには

自己犠牲をしない。例えば、自分が行きたいイベントに参加するチャンスを安易に他の方に譲ってしまうこと。これは自分のモチベーションに影響してしまうので、やってはいけない。

楽しさにフォーカスを当てることでマネジメントを避ける人を減らしたい。

Ask The Speaker

セッション後、登壇者に質問してみました。

Q1.
本人の方向性と組織が望む方向性にずれがあるときどうするか?

A1.
1on1で話し合う時は日を分ける。今週は個人目標、来週は組織目標のように。これをまとめて話し合うことはしない。
個人目標と組織目標の方向性にずれがある場合、個人目標は給与などへ反映できないことを説明する。

Q2.
私にとってマネジメントは個人のリーダーシップを最大限引き出すことだと思っているが、山本さんはどのように考えられているか?

A2.
全員がリーダーシップをとれるわけではない。エンジニアを風林火山に分類した方がいたが、その人に適した役割をアサインすることが重要なのではないだろうか。
【参考】
風林火山の分類は小野和俊さんが提唱されたものだと思われます。下記の記事を参照ください。
プログラマー風林火山 : 小野和俊のブログ
リーダーシップについては私と山本さんの間で定義が違ったかもしれません。この点についてすり合わせたうえでお話ししてみたかったです。

所感

私はマネジメントが楽しいものだと思っています。私の場合、マネジメントする対象が小さく、気持ちよく働けるメンバーに恵まれたからという状況ではありますが、今回の発表には共感するポイントがいくつもありました。

まとめの「自己犠牲をしない」という言葉は心に響きました。というのも、仕事があまりに忙しく、周囲に迷惑をかけたくないという思いから、今回のデブサミ参加は見送ろうかと直前まで悩んでいたからです。でも、メンバーの「行くべきです。(迷惑をかけたくないからと)諦めたらだめです。」という言葉に背中を押され、今回参加することができました。今はメンバーへの感謝とともに、「自己犠牲をしない」という言葉の重みを感じています。

チーム全員が活き活きと活躍できる場をこれからも作っていきます。