まえがき
近年ソフトウェア開発、チーム開発におけるエンジニアリングマネージャーの重要性は高まってきている一方、マネージャーを目指したいというソフトウェアエンジニアはあまり多くないのが実態で、どのようにマネージャーを育成していけばよいのか悩まれている企業も多いのではないでしょうか。
私自身6年ほどエンジニアリングマネージャーとして仕事をしていくなかで、日々どのような仕事をしているのか、何を考えているのか、何に悩むのか、どのようなに気持ちの持ちようでいるのか、考えるている部分をまとめられそうかなと思い記事に書いてみることにしました。
※個人の意見として受け取って頂けると幸いです。所属企業の中での役職の期待役割とは関係がありません。
本記事の対象者
- 現在エンジニアリングマネージャーをしていて何かしら悩んでいる方
- これからエンジニアリングマネージャーを目指したい方、上司から提案されている方
- インディビジュアルコントリビューターだが、エンジニアリングマネージャーについてよくわからない方
エンジニアリングマネージャーの仕事
エンジニアリングマネージャーの仕事とは何なのか。この問いに一言では回答するのは難しいと思います。
よく「プロダクトマネージャーは総合格闘技だ」という例えを目にしますが、私は「エンジニアリングマネージャーこそ総合格闘技だ！なんなら総合格闘技プラス大相撲だ！」なんて思ったりします。
普段の業務内容は大きくわけておよそこの5つくらいの領域に分けてみました。
- エンジニアリング
- ピープルマネジメント
- 組織マネジメント
- プロダクトマネジメント
- プロジェクトマネジメント
各領域に分けて、目指すべきこと、注意すべき点などを書かせていただきます。
エンジニアリング
言わずもがな中心となるのはエンジニアリングです。Tech Leadが別で立てられるチームであれば、技術戦略、アーキテクチャー、メンバーフォローといったことを任せられるかもしれませんが、そのようにメンバーが充実しているチームは限られており、エンジニアリングマネージャーがTech Leadを兼ねる、プレイヤーとしても実装に入るという状況は多いと思います。
エンジニアリングにおいては、ソフトウェア開発、専門領域の基礎知識はもちろん、その周辺領域の知識も必要となることが多いです。
複数のチームが連携するソフトウェア開発では、エンジニアリングマネージャーがチームを俯瞰して設計を考えたり、システムとシステムを繋げるインターフェースを抑えておくが重要となってきます。
専門領域には精通するが、自身の関心には線引きしない
ここでの重要なマインドセットとしては、専門領域には精通するが、自信の関心には線引きしないということかなと思います。
多くの意思決定をしていく中で、多くの判断材料を集めることがとても重要となってきます。
その材料を人から聞いた2次情報ではなく、1次情報として自身の中に蓄積できることで、より正しい意思決定へと繋げることができると思います。
常に貪欲に吸収し続ける姿勢は、エンジニアの基本姿勢として心得ておくが大切だと思います。
部分的にロールモデルとなる
次のピープルマネジメントの育成とも共通することですが、意識してロールモデルなることも必要となります。
場合によってはTech Leadのような立場となって技術的な相談を受ける、解決策を実行する、技術的に方針が迷った場合は、落とし所を見つける、何かのイベントで登壇する、といった行動を見せることで、それをメンバーが真似てチャレンジできる機会を作ってあげることで成長へ導いてあげることができます。
また、マネージャーのキャリアを選ぶと、エンジニアリングから遠のいてしまう、スキルの成長が止まってしまうという不安を抱く方が多いと思います。
そういう方は『スタッフエンジニア』を読むことをおすすめします。
本書で書かれているスタッフエンジニア（スタッフプラスエンジニア）という上級役職のスペシャリストにおいても、エンジニアリングマネージャーと業務が近いものが多いと感じます。
なので、私自身エンジニアリングマネージャーとなってからの方が幅広く技術を身につけることができたと感じますし、決してエンジニアリングから遠のいているのではないと勇気をもらえる1冊となりました。
リーダーシップとマネジメントの違いを意識し、委譲させる
ただし、全ての領域においてリードしなくても、特定領域に強いメンバーを見つけ、委譲していくことも重要です。
マネージャーが多くのことを委譲できればできるほど、チームとしてのレベルが上がっていき、より強いチームへと成長することができます。リーダーというロールでなくとも、場面によってリーダーシップを発揮させることはできます。
チームが立ち上がった初期はカバーする範囲が多くとも、 「ここはあなたに任せたい、任せられるようになれることを期待している」 という明確なメッセージを添えて委譲をしていきましょう。
権限委譲という面では『サーバントリーダーシップ』を読むこともおすすめします。
メンバーのリーダーシップを重視し、マネージャーとして在り方の参考になると思います。
ピープルマネジメント
ここではピープルマネジメントとは、メンバーの目標設定、人事評価、育成、採用、労務管理のような業務を指すことにします。
エンジニアリングマネージャーに関わらず、多くのマネージャーが悩むのはピープルマネジメントではないでしょうか。
それは 人とは"アンコントローラブル"な存在 だからだと思っています。
似たような状況があっても、そこに関わる人によって問題は千差万別です。
また、その人のその時の心理状況によっても変わります。調子が良い/悪い、私生活が安定している/不安なことがある。そういう個人的のことはコントロールできません。
他人をコントロールができないことを踏まえ、どのようにピープルマネジメントに対する心構えを持っていればよいのか、ポイントを絞って説明していきます。
人となりを知る。知ってもらう。
普段1on1をしている組織では、業務内容の相談だけではなく、キャリアの相談から人間関係、私生活の変化、体調といった広範囲のトピックを扱うことになる場合があります。
そういった相談を受ける側としては、特別な訓練、ナレッジ、経験を持っていないと対処できず悩んでしまう場合が多いのではないのでしょうか。
まずは、関係性を築くことが大切です。心を開いて信頼関係が築いている相手でないと、本心を打ち明けるといったことはできません。
そのためにはメンバーの関心事が高いものはなんなのか、何をしていると心地よいのか、といったところから聞いてみましょう。
人は自分が好きなものは語りやすいという傾向があるので、まずはそれをとっかかりとしてその人となりを知ることが大切です。
そして、メンバーにも自分を知ってもらう必要があります。
自分はどんな人なのか、何が得意で何は苦手、こんなことが好き嫌いといったことを伝えていくことで、メンバーからも人となりを知ってもらうことができ、信頼関係を築くことができます。
基本的に知らない人、事には警戒心が強いので、私はこんな人ですということを素直にオープンにしていくことが警戒心を解くことに繋がります。
カウンセラーでもなければ、ライフプランナーでも、アシスタントでもない
メンバーとの関係性が深まると、仕事と私生活の境界が曖昧になってくることもあるかもしれません。
お互いにとって、何でも話せて相談できる関係が心地よければそれでも良いですが、あなたはカウンセラーでもなければ、ライフプランナーでも、アシスタントでもないということは心に留めておくとよいと思います。
例えば人間関係がうまくいかないといった相談を受けた場合、業務を円滑に進めるために、チームメンバーが心地よい環境を作るためにマネージャーとして問題を解決に向かうはよくあります。
場合によっては、第3者として間に入ったり、メンバー代わりに誰かに頭を下げにいったりということもあるでしょう。
そういった人間関係を問題を取り扱う場合は、精神的な負担が大きくなります。
あまりにそれに気持ちを向けすぎてしまうと、マネージャー側が疲弊してメンタルをやられてしまう場合があるので、割り切りも大切です。
チームのためにやれることはやりますが、それでも解決しない場合は、メンバーの配置転換などで対処していくしかありません。カウンセラーではありませんので、完全に心のケアをし続けることは限界がありますし、結局はアンコントローラブルである他人を変えることは本人次第です。
キャリア相談についても、そのメンバーが成長できる環境、機会を作って道筋を立ててあげることはできますが、実際に行動するのはメンバー自身です。
どれだけ業務上のサポートしても、その人の人生設計まで介入することはできません。どんなキャリアを歩みたいのか、どのくらい報酬がほしいのか、あくまで最終的に行動するのはメンバー自身だということをはっきりと伝えておくことは場合によってはお互いの期待値をはっきりさせることになり、関係性が安定することもあります。
また、マネージャーとして様々な相談を受ける中で、必要以上に動いてあげる必要もありません。
たとえば、社内規則や資料を探してあげたり、社内の各種申請方法を教えてあげたり、健康診断や研修を受けるようリマインドしてあげたり、諸々の情報は誰でもアクセスでき、探してマニュアルを確認してできるのであれば、手取り足取りサポートしてあげるアシスタントのようなことはするべきではありません。
マネージャーとしてあなたでないとサポートできないことに専念しましょう。
組織マネジメント
組織マネジメントは、エンジニアリングマネージャーの中でも組織によっては上位役職で求められる業務となるかと思います。
具体的には、組織設計、業務プロセス設計、コミュニケーション設計、予算管理、決裁業務などです。
開発組織において組織設計は骨組みとなる重要な領域だと感じています。
組織設計においては、『チームトポロジー』を読むことをおすすめします。
その組織を運営していくには、どのようなチームが必要で、チーム同士はどのように連携しあうのか、チーム名一つにとっても毎日色んな場面で飛び交う名前ですので、かなり熟考すべきものとなります。
「名は体を表す」という言葉にあるように、名前はチームのアイデンティティとして、ビジョンに結びつくものとなり得ます。
予算管理や決済業務はその組織によってどこまでエンジニアリングマネージャーが担当するかは変わってきますが、メンバーの工数管理などは、プロジェクトのコストと減価償却などに影響してくるため、その事業の予算管理に必要な業務となりますし、備品の発注から購入、経費精算などその開発組織に関わる決裁をマネージャーが担う必要があります。
非合理的物事との戦い
エンジニアリングマネージャーに限らず、マネージャーという立場において非合理的だと思うことに何度も立ち向かうことになると思います。
それは社内プロセスであったり、人間関係だったり、会社の決定だったり、様々なことが降り掛かってくると思います。
ときには自分が納得できないこともあるでしょう。
そんなときは「Disagree and Commit」という言葉を思い出してみてください。
｢リーダーは同意できない場合には、敬意をもって異議を唱えなければなりません。たとえそうすることが面倒で労力を要することであっても、例外はありません。リーダーは、信念を持ち、容易にあきらめません。安易に妥協して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコミットして取り組みます｣
先に触れた『スタッフエンジニア』でも触れられたこの言葉は、組織の成長のために異議を唱えることを重要視し、マネージャーとしてあなた個人の尊重を重視しつつ、一方で組織の決定にはフルコミットすることの大切さを教えてくれます。
プロダクトマネジメント
プロダクトマネジメントとプロジェクトマネジメントは、それぞれ専門職(PdM:Product Manager, PjM:Project Manager)が置かれているかもしれませんので、間接的な関わり方になるかもしれませんし、もしそのような職種がいない場合は、やはりエンジニアリングマネージャーが担う場合もあります。
いずれにおいても、それぞれの領域には常に関心を持ち続けなければなりません。
プロダクトマネジメントを知るには、『プロダクトマネジメント』を読むことをおすすめします。
事業戦略を考えるところはPdM、事業長、CEOなどが担当する領域ではありますが、市場を理解し、事業戦略からプロダクト開発に落とし込む際には、エンジニアリングの観点で戦略に関わり、分析し、方針を提示していくことが大切です。
マーケティング施策のために1日の大半をデータと向き合うといった日もあるでしょう。他社のUXデザインを調査し、資料に落とし込むこともあれば、コスト削減のための機能整備をしてロードマップを立てることも必要になるかもしれません。
一度、エンジニアとしての立場は置いておいて、ビジネスを成功させるためにはやるべきことは何かというマインドでいると、それまで見えてなかった様々なタスクが見えてくるかもしれません。
プロジェクトマネジメント
プロジェクトマネジメントは、エンジニアとして近い領域にあるので、PMBOKやスクラムガイドにあるようなそのプラクティスは体系的に学べることが多いかと思います。
ここではプラクティスではなく、マインドの部分を触れていきます。
コミュニケーションのハブとなる
複数の人、チームと連携するプロジェクトでは、エンジニアリングマネージャーがコミュニケーションのハブとなる必要があります。
そのためには情報収集と共有が基本となり、ミーティングに出て、マネージャーとしての意思決定をしていくことが期待役割となります。
マネージャーとしての意思決定、アウトプットについては、『HIGH OUTPUT MANAGEMENT』を読むことをおすすめします。
意思決定するときには、以下の６つを自問自答すると良いと書かれています。
- どのような意思決定をする必要があるのか？
- それはいつ決めなければならないのか？
- 誰が決めるのか？
- 意思決定をする前に相談する必要があるのは誰か？
- その意思決定を承認あるいは否認するのは誰か？
- その意思決定を知らせる必要がある人は誰か？
その議題の性質を理解し、上記6つの観点からその意思決定に関わるアクションを導き出すことを速くすることで、組織としての意思決定のスピードを速くすることができます。
あとがき
エンジニアリングマネージャーの心構えと題して、5つの領域に分けて触れていきました。
最後に総じてマネージャーとしてドキュメントを書き上げたり、それを伝えるという場面は日々多いと思います。
そういうときに常に相手を意識するということを大切にしてください。
読み手聞き手が理解しやすいかどうかというのは、より多くの人を動かすことに繋がっていきます。
そして、エンジニアリングマネージャーとは大変な仕事だと思います。
悩んだ時はその仕事をする大義としてあなたにしかできないことを考えてみると良いと思います。
エンジニアリングマネージャーとして任されている以上、あなたにしかできないことは必ずあります。
あなたが組織を動かしているという自覚と自信を持って、日々立ち向かっていきましょう。
ここまで読んでいただいた皆さんにとって少しでもこの記事が将来の役に立てたら幸いです。