この記事は、Engineering Manager Advent Calendar 2020 7日目の記事です（間に合った……！）。
エンジニアリングマネージャの「次に何学べばよいか問題」
エンジニア組織のマネジメントを学んでいる人が抱えがちな問題として、「次に何学べばよいか問題」 があるのではないか、と思っています。実際に私がぶち当たったものですから。
この問題は、エンジニアリングマネージャ（EM）が
- 自分は何をどこまで学んでいるのか
- その中で何が得意で何が苦手なのか
- まだ学んでないことはどんなことなのか
が非常にわかりにくいため、次に何を学べばよいかわからなくなる、というものです。
これは、EMに求められる仕事の体系化がほとんどなされていないことが大きな原因と思われます。
求められる知識の幅が広いEMにとって、体系化されてないイコール学習効率が悪いということは死活問題であり、同様に幅広い知識が求められるエンジニアの学習ロードマップが作成されて広く知られている1のとは対照的な状況にあります。
そこで、「次に何学べばよいか問題」にぶち当たって途方に暮れた私は、自分なりにEMの学習ロードマップを作ることを考えました。
この作業における困難は「組織に依存しやすいEMの仕事を一般的に定義すること」だったのですが、これには 「マネジメントとは何をすることか？」という根源的な疑問から出発してEMの仕事を定義し、その仕事に必要なメタスキルを考えるという手法で対処を試みました。
できあがったものは納得の行くレベルになったのですが、これが無意識に私の独りよがりになっている可能性は否定できません。そこで、アドベントカレンダーという機会を借りて公開し、他の人の意見を聞いてみることにしました。
文中に違和感を覚える部分がある方や、異なる意見を持つ方がいらっしゃれば、コメントいただけると助かります。
では、私の独自研究にしばらくお付き合いください。
TL; DR
エンジニアリングマネージャは以下の領域を学ぶべきです。
以下の議論は、すべて上の図の導出過程です。
エンジニアリング組織のマネージャとは何をする人なのか
EMの仕事の一般的な定義を考えるにあたり、出発点になるのは「エンジニアリング」「マネジメント」という2つの単語です。
EMはほぼエンジニア出身であることから、まずは後者を考えてみましょう。
マネジメントとは、一般に日本語では「管理」と訳されます。しかしこれでは意味が広すぎますね。EMが行っているのは企業における管理ですから、まずは「経営管理」を調べてみましょう。
Wikipediaを引くと、「経営管理」とは以下のような活動のことです。
簡単にまとめると、経営管理とは、企業活動を円滑に行うとともに、企業の目的を達成するために、「ヒト・モノ・カネ・情報」の4つの経営資源を調達し、効率的に配分し、適切に組み合わせる、といった諸活動のことである。
経営管理論 - Wikipedia https://ja.wikipedia.org/wiki/%E7%B5%8C%E5%96%B6%E7%AE%A1%E7%90%86%E8%AB%96
つまり、経営管理とは 経営資源を使って利益を生むための活動のこと なわけですね。
しかし、エンジニアリング組織のマネジメントは確かに経営管理の一部ではあるものの、利益を生む活動をしているか？というところには疑問符が付きます。社内の開発組織だけで利益を生んでいるわけではないからです。
もう少し掘り下げて考えてみましょう。
エンジニアリング組織を抱えている企業は、それが事業会社であれ開発会社であれ、社内に
- 経営資源を使ってプロダクト（成果物）を生み出す役割
- プロダクトを売上に変える役割
が存在します。
「プロダクトを売上に変える役割」とは営業だけでなくビジネスモデルの考案やマーケティングも含むのですが、便宜上、前者をエンジニアリング組織、後者を営業組織と呼びましょう。
エンジニアリング組織の生み出したプロダクトを媒体に両者が連携して、「経営資源を使って利益を生む」という活動を行っているわけですね。
実際には、いわゆるバックオフィス系の役割が社内にあったり営業組織が活動するのにも経営資源を使用したりしますが、エンジニアリング組織を抱える企業の活動を簡単にモデル化すると上の図のようになります。
この図のうち、エンジニアリング組織の活動を管理するのがEMというわけです。「エンジニアリング組織の活動とはなにか」を考えれば、EMの仕事内容が見えてきそうです。
エンジニアリング組織が社内で担う役割
「エンジニアリング組織の活動とはなにか」を考えるため、エンジニアリング組織の社内での役割をもう少し具体化してみましょう。
エンジニアリング組織がプロダクトを生み出すための経営資源とは要するに「ソフトウェア開発に必要とされるもの」なわけですから、
- ヒト：エンジニア
- モノ：開発用PC、社内ネットワーク、サーバなど、開発・運用に必要な備品など
- カネ：クラウドサービスの契約費用や業務委託契約費など
- 情報：顧客の要望やマーケットの需要などの要求
が該当します。
このうちエンジニアリング組織が内部でかかえていないのは「要求」のみです。つまり、「要求」以外は社内の他の組織から見えていないわけですから、エンジニアリング組織は「要求を入力すると、プロダクトを出力する」装置のように社内の他の組織からは見えます。
言い換えると、エンジニアリング組織が社内で担う役割は「要求をもとにそれにフィットしたプロダクトを生み出すこと」である、ということです。
ちなみに、「入力された要求をもとに、より速く、より高品質で、よりフィットしたプロダクトを生み出す力」がそのエンジニアリング組織の技術力と呼べるでしょう。
理想的なエンジニアリング組織と現実
前述の通りエンジニアリング組織とは「要求をもとに、それにフィットしたプロダクトを生み出す」役割を担っています。
この役割を果たすための活動が、まさに「エンジニアリング組織の活動」でしょう。
しかし、そのために何をすればよいかはまだわかりません。
まずは、役割をもとに、目指すべき理想的なエンジニアリング組織を考えましょう。愚直に考えると、理想的なエンジニア組織とは以下のようになるはずです。
要求をどんな形であれ伝えれば、それに完璧にフィットした成果物を一瞬で生み出す
どんな曖昧模糊な要求でも、それを完璧に汲み取って「そうそうこれが欲しかったんだよ」というプロダクトを一瞬で出してくれる。つまり、エンジニアリング組織に求められている役割とは「ドラえもん」のようなものなのですね2。
ITエンジニアの中では「エンジニアを魔法使いだと思っている人」に対する愚痴が話題に上ることがありますが、実際に理想的な役割はそれで間違いないわけです。
ですが、エンジニアリング組織が社内でドラえもんのように振る舞えるかと言われれば、現実はそう甘くないのはご承知の通り。
エンジニアリング組織は、現実を理想に近づけるように努力することになります。
これはつまり、理想を現実に近づけることこそがエンジニアリングそのものであることに他なりません。
戦うべき現実の正体
理想的なエンジニアリング組織を考えることで、エンジニアリング組織の活動が「理想を現実に近づけること」とわかりました。
戦うべき「現実」の正体をもう少し具体化すれば、戦い方、つまりエンジニアリング組織の活動が見えてくるはずです。
エンジニアリング組織が遭遇する現実とは、例えば
- 顧客の要望やマーケット調査の結果など、与えられる要求は正確とは限らない
- 要求を正しく解決できるプロダクトを設計できるとは限らない
- 要求を満たすための技術を組織が十全に扱えるかどうかわからない
のようなものです。
これらの共通項は、「作ってみなければわからない」または「作って動かしてはじめてわかる」ことがリスクだということです。
エンジニアリング組織の活動とはエンジニアリングそのものなわけですが、作ってみないとわからないリスクとの戦いがエンジニアリングだというならば、納得感があります。
これらの「現実」のことは、
「エンジニアリング」は、不確実性を下げ、情報を生み出す過程です。
広木大地, 2018, エンジニアリング組織論への招待, p.73
とほぼ同様の主張をしている「エンジニアリング組織論への招待」に倣って、「不確実性」と呼ぶことにしましょう。
現実との戦い、つまり不確実性の削減がエンジニアリング組織の活動であり、エンジニアリングそのものなのです。
不確実性の分類と発生状況
次に、これを使ってエンジニアリング組織の活動を網羅的に挙げることを考えます。
前出の「エンジニアリング組織論への招待」によると、不確実性は以下のように分類できるようです。
不確実性は、3つに大別されます。将来がわからないことから生じる方法不確実性と目的不確実性、それから、他人とのコミュニケーションの失敗や不足によって生じる通信不確実性です。
広木大地, 2018, エンジニアリング組織論への招待, p.181（後半部は図の一部を引用）
これらが発生しうる状況をそれぞれ考えると、
- 方法不確実性
- なんらかの目的を達成しようとするにあたって、手段が複数考えられるとき
- 目的不確実性
- 何らかの要求を満たそうとするとき
- 通信不確実性
- 誰かのアウトプットしたことを別の誰か（未来の自分含む）がインプットするとき
のようになります。
エンジニアリング組織が直面する不確実性を列挙する
ここまでで、
- エンジニアリング組織の役割は要求からプロダクトを生み出すことである
- 要求からプロダクトを生み出す際に戦う現実の正体は不確実性である
- 不確実性は大きく3つに分類でき、それぞれ特定の状況で発生する
ことができました。これをもとに、エンジニアリング組織の活動を具体的に体系化していきます。
しかし、ここまでくればやることは簡単です。要求をもとにプロダクトを出力する活動を継続的に行うにあたり、上記の状況が発生する場面 を考えれば、それがエンジニアリング組織の活動になるからです。
エンジニアリング組織が役割を果たすとき、
- 外部から示された要求を受け取る
- 要求をもとにプロダクトをより速くより質が高くなるように作る
- 未来に製作するプロダクトに対する投資も含む
- プロダクトを納品またはリリースする
の3ステップを経ますので、それぞれのステップにおいて対処すべき不確実性を思いつく限り以下に列挙してみました。
外部から示された要求を受け取る
- 与えられる要求が正確に定義されているか？
- 定義された要求が正確に組織内で共有されているか？
要求をもとにプロダクトをより速くより質が高くなるように作る
- 組織に要求を満たしたプロダクトを作れる技術力はあるか？
- 組織は技術力を発揮できるようになっているか？
- 未来の組織が要求を満たしたプロダクトを作れるか？
- メンバー間で情報が正しく共有されているか？
- 組織に残っているドキュメントは正確に読み取れるようになっているか？
プロダクトを納品またはリリースする
- 完成したプロダクトは要求を満たしているか？
- 開発中のプロダクトは要求を満たせそうか？
- 要求とプロダクトのギャップは許容範囲か？
- プロダクトのQCDは許容範囲に収まっているか？
これで、エンジニアリング組織の活動、ひいてはEMが責任を持つ領域がだいたい網羅できたのではないでしょうか。
不確実性から、エンジニアリング組織の仕事を列挙する
さあ、やっとここまでやってきました。上記に列挙した不確実性をもとに、エンジニアリング組織の仕事を以下に列挙してみました。
- 要求を正しく定義し、適宜修正するのを支援する
- 定義された要求を組織で正確に共有する
- 要求をプロダクトに変える計画を立てる
- 組織の発揮できる技術力を伸ばす
- 組織の既存メンバーの技術力を上げる
- 組織のメンバーが技術力を十分発揮できるようモチベーションを維持する
- 技術力とモチベーションを持った新しいメンバーを連れてくる
- 技術に関する情報を社内に正確に記録し、読み取れるようにする
- 組織内で正確にコミュニケーションを行う
- 組織内で流れる情報の量を増やす
- 組織内の情報をできるだけたくさん形式知にする
- プロダクトが要求を満たすか継続的に検査する
- 要求の内容を満たすか検査する
- QCDを許容範囲内が収まるように検査する
たくさんありますね。
文字だけでは各ステップとの対応が分かりづらいので、図にしてみました。
エンジニアリングマネージャに求められるスキル
さあ、ようやくエンジニアリング組織の仕事、つまりEMが責任をもつ領域が定義できました。
もともとは学習ロードマップを作るのが目的でしたので、それぞれの領域に役立ちそうなメタスキルを図に書き加えてみました。スペースが足りず、もとの吹き出しを消すことになったのはご愛嬌。セットでご覧ください。
これで、当初の目標である「EMが学ぶべきことの体系化」が行えました。お疲れさまでした。
これを見れば、最初に挙げた
- 自分は何をどこまで学んでいるのか
- その中で何が得意で何が苦手なのか
- まだ学んでないことはどんなことなのか
を考えることができるようになります。
当初考えていたロードマップという形式が異なるものの、全く異なる領域の複数の職責を持つというEMの性質から、各領域をパラレルに捉えられる形式でよかったと思っています。
まとめ
- 「マネージャとは何をする人か？」から出発して、エンジニアリング組織の役割と活動を整理した
- 整理の結果をもとに、EMの仕事を網羅的に定義した
- さらにその定義をもとに、EMに求められるスキルを体系化した
冒頭に書いたとおり、皆さんのご意見お待ちしております。
-
のび太くんの要求をドラえもんが完璧に満たしてしまうとお話が成り立たないので、ドラミちゃんのほうが近いかもしれない ↩