asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです！

自分より優れているエンジニアをマネージメントする技術

組織 Advent Calendar

はじめに

askenでエンジニアリングマネージャー(以降、EM)をしている西です。

この記事は、株式会社asken (あすけん) Advent Calendar 2024 の10日目の記事です。

全国のIT業界で働く管理職の皆さん。部下なのに自分よりつよつよエンジニアがいる場合、上司って何してあげるんだろう？って考えたことありませんか？(贅沢な悩み) 僕は前職も含めて管理職を始めて5年間ずっと、自分より優れているエンジニアが配下にいました。 その中で、EMとしてどう振る舞ってきたのかを共有したいと思います。そして、この内容が少しでも悩める管理職の人の助けになれば幸いです。

エンジニアリングマネージャーの仕事とは？

EMの仕事はエンジニアに成果を出してもらうための支援をする事です。つよつよエンジニアともなれば、ほっておいても勝手に実現手段を見つけてアウトプットを出してくれますが、より良い成果を出してもらうためにEMが働きかけてあげないといけないです。

では、EMは何を働きかけるべきなのか？工程を「問題(issue)」「実現手段」「解決した状態」の３つフェーズに分けて説明します。

EMが働きかける3つの工程

コミュニケーションを「問題(issue)」ベースでとる

何か仕事をしてもらうために実現手段を決めてタスクを渡すのは勿体無いです。 つよつよエンジニアともなれば、こっちが想定している以上に実現手段をいっぱい持っています。そこへ実現手段の縛りとなるような仕事の渡し方はエンジニアの能力を制限するに等しいです。 能力を制限せずに働くためには、実現手段を限定せずに問題(issue)だけを渡して、実現手段、解決した状態は考えてもらった方が良いです。

僕が問題(issue)を定義するときに一番気をつけているのは「ゴールデンサークル理論」です。

手段(How)、解決した状態(What)を決めつけて問題を定義していないのかを考えるために常に何のために？(Why)を問いながら問題(issue)を定義するようにしています。

EMとしては、つよつよエンジニアが存分に能力を発揮してもらう事が一番の成果につながるので、問題に対してWhyを繰り返して、質の高い問題を定義して存分に能力を発揮してもらうために労力を割くのがいいと思ってます。問題を定義したら、あとは成果を出してくれると信じるのみです。

参考) ゴールデンサークル理論 (サイモンシネック) をご存知ない方はこちらをどうぞ

https://youtu.be/qp0HIF3SfI4

「実現手段」の質はコーチングで高めよう

EMがつよつよエンジニアと接する上で難しいのが実現手段を決める時で、その手段が本当に良いものか判断がつかない時です。自分が把握していない技術で実現する事を提案された時に何をもとに判断するべきか悩みます。実現できるならいいかと思ってしまいがちですが、ここはコーチングの技術を使って、実現手段の質を高めましょう。

この状況においては、つよつよエンジニアが一番技術力が高いため、本人に考えてもらうのが一番質の高いレビューを行えると考えられます。問題は本人が実現手段を考えているため、だいぶバイアスがある状態にいるという事です。

コーチングにおける本質は良いフィードバックをして本人に気づきを与える点だと思います。技術的な判断についても同じようにこちらからのフィードバックを利用して、何かを見落としていないか気付いてもらいましょう。

フィードバックすることは主に以下の2つです。

  • 一般的な実現方法を提示してみる
  • 自分がどう理解したのかを説明してみる

僕がこのようなフィードバックをする事で達成したいと思っていることは、実現手段がつよつよエンジニアの趣味・個人視点での判断になる事を回避するという事です。

「解決した状態」は期待値から考えよう

目の前の問題が解消しても実は解決した状態の期待がズレていて、結局、技術的な負債になってしまったという経験はあるのではないでしょうか。その状況を避けるためには解決した状態の期待値を事前に定義しましょう。定義さえしておけば、つよつよエンジニアは、その状態を達成してくれます。

期待値を考えた方が良い点

  • 今後の変更・維持コスト
    • 変更頻度と変更のコストは見合ってるか
    • 維持コストは見合っているか
  • 提供するべき成果
    • (要求された機能) ※コレがズレるは無いかも
    • レスポンスタイム
    • 改善される工数削減量
  • 保守の計画
    • 保守する人がメンテナンスできる技術レベルで作られているのか(誰に任せる？)
    • アラームなどの対応
  • どれぐらいの期間、使われるシステムなのか
    • 今後のEOL / VerionsUpを計画できているか
    • 期間に応じたドキュメントを残しているか

ここの期待値がズレる可能性が高いのはEMとつよつよエンジニアの立場の違いです。

EMの方が、組織・経営の視座で考える事が多く、考えないといけない立場でもあります。そのため「解決した状態」を考える時に技術的な観点は任せておいて、別の視点を考えるために視座を上げて、組織・経営の視点、時間軸が長くなった場合の視点で期待値を考えてあげると良いです。

どうやって達成するかはつよつよエンジニアなら考えてくれますし、はじめにゴールをちゃんと設定してあげればそこへ挑戦してくれます。

さいごに

世の中でEMをされている人の多くはエンジニアを経て今の立場になっているのではないでしょうか？

僕も元々は一エンジニアとしてアウトプットを直接出す立場でしたが、EMになってからはエンジニアを率いてアウトプットを出してもらう立場へ変わり、働き方には色々と悩みました。

同じように悩みを抱えている、どこかのEMの助けになればいいなーと思ってます。

hrmos.co