序文
このエントリーは Engineering Manager AdventCalendar 2018 の 11日目の記事になります。
筆者とエンジニアリングマネジメントの関わり
現在、サーバサイドエンジニアのエンジニアリングマネージャという肩書きでエンジニアリングマネージャをしています。
現職ではエンジニアリングマネージャはピープルマネジメント中心とした役職です。
前職でもエンジニアのマネジメントするポジションで、技術に関する部分のプロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントなどの全ての責任を持っており、チームに居るエンジニア全体をマネジメントしていました。
前職では２つの事業立ち上げと既存事業の途中から参加した３つの事業での開発マネジメントに順番に携わっていました。
今は大きな組織の中で数名のエンジニアを担当するエンジニアリングマネージャをやっています。
このようなエンジニアマネジメントのポジションに就いてから4年半ほどが経ちます。
ゼロイチでチーム文化から作るところや成果が出なくてスケジュールギリギリで走り続けたり、長く運営されたチームに入り文化変革をしたりなど、いくつかの入り方でチームに入り、自分の得た知識をいくつもチーム内で実践してみたりしてきました。
最初の頃はスクラムなどのアジャイル開発の知識もなんとなくはありましたが、長くマネージャ職を続けていった時に、完全にマネジメントに振り切って勉強しようと考えてから２年程度が過ぎました。
その切り替わりの時期で感じた、マネジメントのスキルを勉強して習得することを意識しながら、よく区分けされるマネジメントについて書こうと考えました。
今回は技術のエンジニア側から既存マネジメントが組み合わされたものを見ると、どのような観点で対応する必要があるのかの考えを書いています。
想定読者
エンジニアリング x マネジメント に興味がある人
片方ではなくて、両方同等に知識として欲しいと思う人
エンジニアリング x マネジメント
マネジメントを学ぶ習慣のないエンジニアではエンジニアリング + マネジメント (エンジニアが足しているだけ) になっていて、それはエンジニアの力の最大化にはならないと思っています。
マネジメントとエンジニアリングは掛け算の関係であり、最終的に完成するプロダクトを何倍にもする力があると信じています。
エンジニアリング x マネジメント (掛け算)にすることで、その価値を作り上げられるエンジニアは楽しく喜びを得られると共に最大のパフォーマンスを発揮すると信じています。
エンジニアの技術を持っているからこそ出来るマネジメントが全てのマネジメントの中に存在していると考えていて、いくつかの領域のマネジメントの考えを書いてみました。
今回の領域は
- プロダクトマネジメント
- プロジェクトマネジメント
- ピープルマネジメント
についてそれぞれの観点で書いてみました。
##プロダクトマネジメント x エンジニアリング
プロダクトマネジメントとは
プロダクトを何を作るかを決める作業になります。つまり作るべきものの目標そのものを決めるマネジメントです。
理想だけでは目標は達成できないため、ビジョンからリソース(人・モノ・金)を考えて実現性のある機能提供の目標を作ります。
高速で移動がしたい！と考えたときにF1カーを作るべきか、軽自動車を作るべきかはその時によります。
軽自動車のコストでF1カーは作れないので、そのバランスを見極めることこそプロダクトをマネジメントすることです。
####プロダクトマネジメント x エンジニアリングとは
実現性の部分でより精緻な審査が出来るのはエンジニアだけです。
仕様を聞いた時に実装するべきデータフローが瞬時に浮かぶ技術のレベルが必要になります。
また、実現する実装方法についてアイデアマンである必要もあります。
価値 > コスト → 本当のコストがわかるのはエンジニアだけ
提供スピードが早いほど価値を大きく出来る。
しかし、実装コストは技術が分かる人間にしかわからないので、エンジニアがマネジメントする必要がある領域。
実現したいことのコアな価値がどこにあるのかを理解して、技術的にコストが低く長期的に安定出来る実装はどのようなものかを考えながら提案する必要がある。
つまり、早く届けられるかどうかによって、価値の優先順が変わるはずなのです。
技術を知らないプロダクトマネージャだけで優先順を最終決定出来るケースはないと思います。
それが出来るのは定常的な慣れた技術であるときだけです。新しい技術や新しい設計が必要なときには必ずエンジニアの力が必要だと思います。
そのエンジニアの確認をしないマネジメントでは通常では到達不能な目標をプロジェクトマネジメントをする時に圧倒的な軋轢が発生することになるはずです。
技術的負債のコントロール
技術的負債がプロダクトに与える影響度を測ることが出来るのもエンジニアだけです。
プロダクトマネージャに言われるがままに作るエンジニアはマネージャではないと思います。
中長期のプロダクトのシステム内のバランスを考えながら技術的負債をコントロールすべきです。
エンジニアにとってシステムのアーキテクチャデザインや構成、品質こそがプロダクトのはずです。
それは プロダクトマネジメント x エンジニアリング が必要な領域です。
プロジェクトマネジメント x エンジニアリング
プロジェクトマネジメントとは
作るべき機能をどのようなスケジュールで作って実行するかをマネジメントします。
簡単に言えばプロダクトマネジメントの時に決めた目標を達成するというものにフォーカスしたマネジメントです。
クリティカルパスの並び順を整理したり、全体量を把握しながら進めたりするだけで効率が上がるものです。
コミュニケーションを促進したり、認識を合わせるためのツールやフレームワークなどもあります。
プロジェクトマネジメント x エンジニアリングとは
機能の工数の積み上げだけでは実はアプリケーションは完成しません。
特にサーバサイドの技術が多い場合にはPMが出す機能スケジュールとは別のスケジュールを持つ必要があります。
エンジニアにしか見えない非機能要件や開発環境の作成、たくさんの機能の基盤となる部分の実装などの工数を加味したスケジュールを作り出して、プロジェクトのスケジュールとシンクロしながら開発のスケジュールをマネジメントする必要があります。
パーキンソンの法則
大きくバッファを持つ方法でスケジュールリスクに対応する方法もありますが、本質的ではないと思っています。
それは自分で技術を見積もることが出来ない、またはタスクを洗い出す事ができないという技術力不足に対応するための手段に過ぎないと思うからです。
単純にバッファだけ積まれたスケジュールはパーキンソンの法則(夏休みの宿題を最終日にすべてこなすなど)に沿って、スケジュールの時間をすべて使うことになってしまうと思います。
不確実性のコーン
技術が高く、かつプロジェクトマネジメント力があるならば、もっと本質的な技術リスクを見積もることが出来ると思います。
本当に技術リスクが高い機能と、今まで得た技術を使うことだけで実現できる機能では、スケジュール上の日数は同じでも、不確実性へのリスクは大きく違います。
不確実性のコーンは不確実なリスクに対して早期に手を付けて、不確実性を減らすことによって収束していくもです。
分からないからと言って手を付けていなければ、不確実性のコーンは収束することはなく、スケジュールの延期を余儀なくされます。
何が不確実であるかはプロダクトマネージャはもちろん分かりません。プロダクトマネージャには全ての機能が不確実に見えていることでしょう。技術がわかるリードエンジニアだからこそ、実現性に対する実装リスクの濃淡が機能の仕様から見えるのです。
マーケットや経営の判断の動きを見ながらスケジューリングする
提供価値が他の機能よりも上であっても、不透明な技術のものはタスクとして優先順位が上げづらいです。
見通しが明るい機能の方が提供価値が低くても実装を先にしてしまうのです。
１人のメンバーであるエンジニアの多くはマーケットにおける機能の価値を理解するだけの十分なマーケット知識を備えていません。
マネジメントするにはそれらを捉えて、スケジュールに落とし込む必要があります。
本当に対応すべきタスクが何かをコントロールし、リスクについての不確実性を考慮に入れたタスク優先度、スケジュール順、アサインなどは、とても高いレベルの技術とマネジメント力を要すると思われます。
緊急ではない重要な仕事
締め切りやバグなどの緊急事態になったときにのみ不確実なリスクに対応しているようではプロジェクトマネジメントが出来ているとは言えないと考えます。エンジニアの技術力を活かしてこそ プロジェクトマネジメント x エンジニアリング のマネジメントになりえるはずです。
スクラムベーシックなエンジニア理想とスケジュールベースなFIXスケージュールの現実
締切の自由さや機能の削減の余裕があるならば、スクラム等で実行されているバックログリファインメントやスプリントバックログで解決出来ます。
しかし、スケジュールをFIXさせたい、機能もFIXさせたい要件が強いときには現在のスクラムフレームワークでしっかりとエンジニア側が必要な作業について洗い出す力やリスクを見積もり、バッファの誤差を減らし、技術的なリスクがクリティカルパスにならないようにタスクの着手を優先する勇気を持ちならがカンバンのチケットを取る戦略が必要です。
自由にカンバンからチケットを取るだけでは上手くいかないのも当然です。マネジメントされていないのですから。
そして、それは真のアジャイルではないと思います。
スケジュールがFIXしていても、アジャイルであることは出来ると考えています。
それはウォータフォールとは別のものです。
##ピープルマネジメント x エンジニアリング
####ピープルマネジメントとは
個々の働く人へのマインドに関わるマネジメントになります。
その人の価値観や求める働き方、その人のパフォーマンスを最大に発揮させることや中長期のキャリアを考えます。
ピープルマネジメント x エンジニアリングとは
エンジニアリングを行うのは当然エンジニアになります。
エンジニアの技術を理解しない人に対して、エンジニアはどれだけ技術の話を出来るのでしょうか？ 通常は難しいでしょう。
毎日技術を駆使し、技術を勉強し、技術で成長しているのに、その話が出来ない人にあなたの成長や成果を説明できるでしょうか？ 現在の課題を相談できるでしょうか？ 将来を相談できるでしょうか？
エンジニアの技術とマネジメントの知識があるからこそ
・ 困っている技術の相談
・ エンジニアのキャリアの相談
・ あなたの技術力の評価
を話が出来ると思います。
それだけでピープルマネジメント x エンジニアリングの価値があります。
目標管理と評価
ピープルマネジメントのスキルで言えば、目標設定やキャリア、パフォーマンスの最大化などがあります。
MBO、OKR、KPI、KGI
色々な指標や個人の目標の立て方があります。
OKRを１つとっても、上手くやれるOKRとやれないOKRがあります。
タイトルだけOKRにしても、OKRではないのです。必要なのはOKRの観点といくつかの要素が守られているかという事です。
ただブレイクダウンするだけでは上手くいかない。ゴールツリーのような考え方や伝え方も重要になります。
会社がどの方向にビジョンを持っているかを理解していなければエンジニアの目標を導けないですし、会社のビジョンに対してキャッシュフローや事業計画を理解しなければ、その実効性がただの理想なのか、硬い目標なのかわかりません。そこまで理解してエンジニアの目標を作る必要があります。硬い目標ならMUST目標で立てなければならないですし、理想目標ならばビジョン目標としてモチベーションを作る必要があります。そこに技術を掛け算して目標を提案する必要があるかと思います。
会社の経営の理解が浅ければ、プロジェクトマネジメントのスケジュールに振り回された目標設定のみになり短期的なものしか見えなくなってしまう。本当のその人のパフォーマンスや成長性を考えた目標を考えれるようになりたいところです。
評価
評価の方法もどんな会社も頭を悩ませ、試行錯誤しているところになります。
この項目については定型的なパターンはあまりなく、事例ベースが多い気がします。
弊社はPeer Reviewを採用しており、自分を評価して欲しい人の複数から評価コメントを受けて、上長が最終決定しています。
環境作成
組織文化の浸透や福利厚生も含めて働くひとの環境作成が必要になります。
PCのスペックやモニタ、机や椅子、開発の時に使うツールなど、自由に揃えたり、良いものを使える方がエンジニアは当然うれしいですし、効率も上がると思います。
最近ではエンジニアのコアタイム勤務によるフレックスやリモート開発も増えているように感じます。
そのような環境そのものを変革することは会社の文化もありますが、進めるための上手さも必要です。
最小単位の個人と最大単位の組織をマネジメント
ピープルマネジメントは個人にフォーカスする部分と組織そのものにフォーカスする部分があり、ターゲットの大小の差が大きいので非常に難しい部分のマネジメントのように思います。
この記事を見ている人はきっとエンジニアリングを勉強してきた。そしてマネジメントの興味、知識がある
あなたがエンジニアならばエンジニアリング技術を学んできたと思う。
エンジニアという職業があなたをエンジニアにしたわけではないと思う。
エンジニアと名乗るために勉強した事があるはずです。
マネジメントのフレームワークや技術
エンジニアがそうであったのと同じようにマネージャになったならマネジメントが出来るようになるわけではない。
マネジメントも多くのフレームワークや手法があります。
あなたはオレオレフレームワークばかりを作るエンジニアと一緒に働きたいだろうか？
センスが群を抜いていればRuby on Railsのようなフレームワークを作ってしまうかもしれないが、ほとんどのケースがそうではないことを知っていると思う。
コピペではない、活用をすること
事例ばかりみてそれを適応するのも、ちょっと違うかなと思います。
StackOverFlowに載っている解決方法のコードを意味もわからずコピペするだけで上手く動いたけど、根本が違っていることもあると思います。
もちろん、最初の一歩はそこから始まるとは思います。しかし、本当に使いこなすには、その一行一行に何の意味や意図があるかを理解することの方が大切です。
ふりかえりでKPTをやっているときに、KPTをやっていればチームが良くなるわけではないです。
KPTで解決できる問題や課題の観点でKPTが使われているときにだけ効果を発揮するんです。
このように、技術は意味があって使われているので、その適応範囲は自分で考える必要があります。
真のエンジニアリングマネージャ
僕はマネジメントの勉強をしなければ 真のエンジニアリングマネージャ にはなれないと考えています。
残念ながら僕は凡人なので、センスよくマネジメントを実行することはなかなか出来ませんでした。
だからこそマネジメントの手法を学び、上手く実行できるようになるまで実践をしようとしています。
使いこなすまでにはまだまだ練習が必要です。
GoFのデザインパターンを覚えても、使いこなすまでには時間がかかります。
それまではデザインパターン厨になってしまう時期はあるかもしれないです。でも、やるしかない。
マネジメントも同じです。コーチングの本を１冊読んだからと言って、コーチング出来るわけではないです。
エンジニアリングを掛け算する
色々なマネジメント単体の知識がエンジニアリングと掛け算されることになると思います。
それは今あるマネジメントフレームワークをベースにしながらエンジニア向けにカスタマイズしながら使うことになるような気がします。もちろん、開発向けに作られたアジャイル開発系のフレームワークなどはそのまま利用できます。
さまざまなマネジメント領域
様々なものをマネジメントするために色々なマネジメント分野の勉強が必要と思います。
- プロダクトマネジメント
- プロジェクトマネジメント
- ピープルマネジメント
それぞれにたくさんの考えや事例、本などがあります。
さまざまな考え方や手法が存在しています。
上では３つにまとめていますが、この３つがとてつもなく深くて広い、、、。
また、この枠に当てはまらないマネジメント技術も、もちろん沢山あります。
レピュテーションマネジメントでは会社の評判をマネジメントする話ですが、その観点をエンジニアに照らし合わせ、外に表現されづらいエンジニアのスキルや貢献をどう表現することで評判としてアピールするかをエンジニアリングと掛け算することで考えたりもできます。
ゾーンマネジメントは経営におけるグロース事業と新規事業などのフェーズごとに組織や観点、ルールを分けてマネジメントをする手法ですが、その観点はエンジニアリングに於いても同様に存在すると感じました。
技術的負債に対する投資の考え方もこのようなフェーズによって違います。
このようにどんなマネジメントに関してもエンジニアリングを掛け算することで活用できる面があるのではと考えています。
いくつかの手法の紹介
今回の３つのマネジメントに関するいくつかの手法に関するキーワードはこちらの過去記事にもあります。
現在と少し考えが違う部分があるのですが、参考になるかもしれません。
エンジニアの次のステップの勉強法２ - 技術の別の道への活かし方
終わりに
いろいろ書きましたが、ぶっちゃけエンジニアが良い感じに働けるようにすることがマネージャの仕事で、それ以外の目標はないと思います。
今回書いた勉強することについても１つの考えや手段に過ぎない。
色々なマネジメントの技術を学んで真のエンジニアリングマネージャを目指したい！
エンジニアが楽しく開発できる環境を作る。エンジニアリングマネージャの責務はそれだけ！
みんなで頑張ってエンジニアにとって最高のやりがいある環境を作りましょ！