エンジニアが「明日からマネジメントして」と言われたら
最初に結論
エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。
以降、もう少し詳しく説明します。
なんで書こうと思ったか
エンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。
しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。
最近だとVP of Engineeringみたいなポジションがメジャーになってきて、エンジニアの組織マネジメントという役割が少しわかりやすく定義される傾向もありますが、それでも組織の規模や戦略によってエンジニアマネージャーの定義は各社さまざまです。
自分は今年1年は特にマネジメントの比率が大きくなった年でしたが、実際自分もマネジメントっぽいことが業務にはいってきたときに、わりと曖昧にスタートして右往左往してしまったので、その頃の自分のために簡単に整理してみます。これ読めばまぁ最低限概要わかったわ・あとはググるわ、という状態を目指します。
目次
- そもそもマネジメントとは
- 製品開発における”マネジメント”を分割する
- 自分に求められているマネジメントの範囲を明確にする
1.そもそもマネジメントとは
マネジメント初心者としては、1on1やスプリントなど各論から入らず、王道にマネジメントとはなにかを先に知っておくとよかったなと思います。全体像がわかれば、各論もより効率よく学べたのは間違いないでしょう。また自分がなにを知っていて、なにを知らないかも気づきやすくなります。
定義を言い出すとwikipediaやらドラッカーやらhatena keywordやら定義はそこらじゅうにあるのですが、個人的にはこの本に書いてあるように
自分の組織のアウトプット+自分の影響力が及ぶ隣接諸組織のアウトプット
＝マネジメントの成果物、というのが今までの実感値と一番しっくり来る表現でした。
もう少し砕けていうと、マネジメントは組織全体のアウトプットを上げることをゴールとし、個々の生産性を上げたり、各プロセスの連携を強めたりすることが具体的な仕事となります。数式に例えれば、インパクトの大きい変数・係数を狙って改善すること、ということになります。
本書ではそれらの行為を「テコ作用」と読んでいましたが、いかに最小限の力で「テコ入れ」をして、最大の効果＝組織のアウトプット向上がなせるかを考えて仕事をせよ、というのはエンジニアにとってのマネジメントでも言えることでしょう。
図にするとこんな感じでしょうか
開発には各工程があり、それを支えるチームがあり、それが実際お客様に届くことが開発組織の最終的なアウトプットである、ということを表現してみました。
具体的なアウトプットをKPI?スピード?品質?となにとするかはケースバイケースで一概にはいいにくい部分ですが、そのアウトプットを構成する要素（変数）やその関係性（係数）はだいたい同じで図のようになるでしょう。
企画やデザイン、開発といった個々のクオリティはもちろん大きな変数ですし、それぞれが上手く受け渡しされるか、コミュニケーションがしっかりとられるかも重要な係数(図でいうとX）のとなってくるでしょう。開発チーム全体という意味では、製品の戦略や顧客・競合との接点も大事な「テコ入れ」ポイントです。1on1やメンタリングなども、図内のTeam内の１人の人のアウトプットを最大化するための大事なマネジメントタスクの一つです。
ただし、相当なスーパープレイヤーでない限り、この範囲を１人でカバーすることはできないでしょう。やることが多すぎますし、チームが大きくなったら物理的に全部見ることは不可能になります。
かといって、むやみやたらに動いても最適な「テコ入れ」ができず、他のマネージャーとの連携も上手くいきません。
そこで、あなたが「どこをマネジメントするのか」を明確にする必要がでてくるのです。
2.製品開発における”マネジメント”を分割する
より具体的に噛み砕いていくために、先ほどの図を、Product / Project / People Managementという定義で分解してみますと、おおよそ以下ようになります。
各論はまたの機会としますが、簡単に説明します。
1. Product
- 1–1.strategy:戦略
- 1–2.roadmap:ロードマップ
ここはいわゆる「プロダクトマネジメント」と言われる部分です。
最近はプロダクトマネージャーという言葉が普及してきたのでわかりやすくなってきましたが、簡単にいえば、何を作るべきか・作らないべきかを意思決定し、プロダクトの戦略や計画を立てるパートです。
ビジネスサイドの人間がいれば多くの場合エンジニアがメインで持つことは少ないかもしれませんが、海外では多くのエンジニアがプロダクトマネージャーをやっていますし、小さなチームでそんなに人もいないし自分が実質リーダー、という場合は請け負う可能性も十分ある役割です。
2. Project
- 2–1.execution:進捗管理
- 2–2.process:プロセス改善
ここは、いったん「プロジェクトマネジメント」と定義しました。(語弊が多少あるかもしれませんがコレも定義が揺れるものなので一旦ご了承を）
すごく簡単にいってしまえば、やると決まったことが正しく最速で実行されているかという「進捗管理」と、最速で行えていない場合なにが問題か発見・解決するプロセス改善を代表的なものとして上げました。
ここは切り口次第で他の代替する概念はいろいろあり、スクラムマスターといって開発のファシリテーションや「2–2:process プロセス改善」をメインにおく役割もありますし、「2–1:execution:進捗管理」はビジネスサイドのリーダー的な役割が持つ場合もありますし、チームが小さくエンジニアが多ければ実質開発マネージャーが両方見ている、なんてチームもスタートアップなら少なくないかもしれません。
3. People
- 3–1.motivation: 動機づけ
- 3–2.allocation: 配置・アサイン
- 3–3.recruiting: 採用
最後が「ピープルマネジメント」です。これが一番エンジニアにとってのマネジメントというワードとリンクしやすい部分かもしれません。部下をもってマネジメントする必要性がでてきた、という一番多いケースがここかと思います。
チームの方向性や、チーム全体の問題というより、チームのメンバー個々の活躍をサポートしたり、1on1面談、評価をしたり、ときにはアサインを調整したりすることでしょうか。新しい人を採用したりもしたりすることもこの枠にいれました(が、ここは意見が分かれそうな微妙なライン)。
GoogleなどはPeople Managementする人が開発チームとは別にいたりするそうですが、ここも規模やフェーズによって、プロジェクトリーダーがピープルマネジメントをしていたり、小規模だとCTOが全部やっていて他メンバーはやっていない、などという場合もありそうです。
3.自分に求められているマネジメントの範囲を明確にする
前置きが長くなりましたが、要はマネジメントをしなければとなったとき、闇雲にやるのではなく、上記のような前提知識を入れた上で、まずあなたの会社、組織、チームにおけるあなたのマネジメントの責務はどこにありますか？ということをまずは整理してマネジメントをはじめてみましょう、と過去の自分に言いたいし、みなさんもやってみてはどうでしょう、いうことです。
例えばあなたが今回Engineering Managerというroleでマネジメントをすることになったとしたら、こんなふうに自分の役割範囲だと思うものに◯をしてみてください。サブカテゴリーは会社に即していろいろとカスタマイズしてみるとよいと思います。
そしてあなたにマネジメントをやってくれと依頼してきた上司とも合意し、チームにも共有しましょう。意外とずれていることは多いです。
よくありそうな食い違いによる結果は「チームにマネージャーはいるのに、なかなかプロセスが改善しないで生産性上がらない」「メンバーを見ることだけじゃなく進捗もしっかり担保することを実は期待されていた」などでしょうか。
開発全体のマネジメントはどれかが欠けると生産性が連鎖的に下がるので、まずチームとしてしっかりカバーするように設計するのは重要です。
また自分が何に責任を持つべきか明確にすることで、なにをすればいいか迷いがなくなり、仕事のパフォーマンスもよくるのではないでしょうか。
終わりに
エンジニアにとってのマネジメント、その入口になるようにと思って書いてみました。
マネジメントは毛嫌いされがちですが、上手く成果をだせば今までと違った形でチームに大きく貢献できますし、プロダクト思考の強いエンジニア、地頭・問題解決力の高いエンジニア、能力コミュニケーションが得意なエンジニアなどなどが、自分の強みを活かす一つの役割にもなりうるので、個人的にはより敷居は低く、魅力のあるポジションになればいいなと思います。
こんな考えに共感してくださった方、そんなマネジメントスタイルで働いてみたい、そういう考えをもったチームでやってみたい、という方がいましたらぜひお声掛けください！お待ちしております。
