「なんとかする」ための“引き出し”を増やす。EMの「4つのP」を捉え直し改善する方法

エンジニアリングマネージャー（EM）が向き合うべき領域は、人・組織から技術・プロダクトまで多岐にわたります。日々の業務の中で、どこに注力し、どのようにマネジメントしていけばよいのか、迷うことも多いのではないでしょうか。

本記事では、広木大地氏のEM Conference Japan 2025の基調講演の内容から、彼が提唱する、EMの役割である『4つのP』——ピープル、プロジェクト、プラットフォーム、プロダクト——についてレポートします。

メンバーの「思考のバグ」にいかに向き合うか？ プロジェクトを炎上させる「掛け算」とは？ 「見えない負債」とどう戦う？ プロダクトを非連続成長させる「弾み車」のつくり方とは？　 EMとしての引き出しを増やし、日々のマネジメントをさらに改善するヒントが詰まった登壇内容を紹介します。

• keyboard_arrow_down EMの活動領域「4つのP」
• keyboard_arrow_down ピープルマネジメント｜「本能」に抗えるような関係性をつくる
• keyboard_arrow_down プロジェクトマネジメント｜タスクとリスク、「足し算」と「掛け算」
• keyboard_arrow_down プラットフォームマネジメント｜早く失敗するための「可視化」
• keyboard_arrow_down プロダクトマネジメント｜事業を終わらせないための「弾み車」
• keyboard_arrow_down エンジニアリングマネージャーは「なんとかする人」

さて、EMが行う活動を、私は「4つのP」という領域で整理しています。

それは、

ピープルマネジメント（People Management）
プロジェクトマネジメント（Project Management）
プラットフォームマネジメント（Platform Management）
プロダクトマネジメント（Product Management）

です。（以前、プラットフォームをテクノロジーマネジメントと呼んでいましたが、Pで揃えてみました）

これらの領域は、不確実性を下げるために「早く失敗する」「リスクを早期に曝露する」という「フェイルファストの原理」に基づくという共通点があり、相互に関連し合っています。

ピープルマネジメントは、人の成長を通じてチームや組織の不確実性を減らしていく活動です。人の考え方にも「バグ」が潜んでいることがあり、それをリファクタリングすることで成功に近づけます。

これは私自身の原体験なのですが、チームメンバーとランチをしていたある時、「そういえば、あの問題どうやって解決したの？」と尋ねたことがありました。メンバーは「こうしたらできたんですよ」と説明してくれたのですが、その方法を聞いて「ん？その考え方だと、こういう条件の時に問題が起きるんじゃないか？」と疑問に思ったのです。その場で少し掘り下げて確認してみると、ソフトウェアに組み込まれていたらバグになりかねないような「思考の穴」が見つかりました。

この経験から痛感したのは、コードを書く前の「考え方」の段階で既にバグが生まれており、それがそのままソフトウェアに組み込まれてしまうことがある、ということです。ですから、ピープルマネジメントにおいては、メンバー1人ひとりの思考プロセスに目を向け、その「考え方のバグ」を早期に発見し、対話を通じてリファクタリングしていくことが、結果的にプロダクトの成功に繋がるのです。

ここで重要なのが、フェイルファストの原理に基づく心理的安全性です。

心理的安全性とは、単なる「仲良し」ではなく、「（課題の指摘など）対人リスクを取っても大丈夫」という信念を共有できていることを指します。課題を早期に言い合える関係性によって、例えば「ちょっとまずいけどいけるかもしれない」というときの「ちょっとまずい」にあたる潜在的なリスクや課題を早期発見しやすくなり、プロジェクトの炎上などを防げるようになります。1on1などを通じて細やかな問題を吸い上げ、解決していくことは、メンバーの機嫌取りではなく、チームを「成功できる状態」に持っていく活動として行うべきことです。

また、人は不確実な状況に直面すると、本能的にそれを避けようとし、「逃避」または「攻撃」の反応を選びがちです。不確実な状況とは、上長への報告や、他部門との調整といったシーンですね。こうした報告や調整を後ろ倒しにしてしまうと、フィードバックを得る機会が遅れ、結果的にプロジェクトの失敗リスクを高めてしまいます。

だからこそEMは「本能に抗えるような関係性」をつくる、つまり本能を乗り越えるための思考力や、建設的な対話ができる関係性を意図的に構築していく必要があります。

その方法論として、メンバーの成長支援を伴うチームビルディング、権限委譲によるチーム設計、メンタリング、文化形成などが挙げられます。

メンバーのキャリアと成長を支援する過程で、問題解決能力や状況を整理して説明する力、すなわち思考力や言語化能力の向上を促します。さらに、権限移譲を進めることでメンバーの自律性を高めます。メンタリングとコーチングを通して、傾聴や承認、自己開示を通じて信頼関係を築き、メンバーが直面している課題を再設定し、自ら乗り越えていけるようにするために支援を行います。そして、チーム全体で失敗を学習の糧とする文化を醸成し、未知のリスクが積極的に開示されるようにしていくことも、ピープルマネジメントの範疇となります。

これがEMが担う「ピープルマネジメント」です。

プロジェクトマネジメントも、不確実性と向き合う活動のひとつです。

プロジェクトマネジメントについて語る際、よく「不確実性コーン」が引き合いに出されます。プロジェクト開始時は見積もりのブレが大きいものの、進捗とともに精度が上がっていく、というものです。

ただし、放置していても自然に収束するわけではありません。この不確実性を能動的に減らしていくことが、プロジェクトマネジメントであると言えます。

プロジェクトマネジメントの本質は、単なるタスク管理ではなく「リスク管理」です。プロジェクトにおける要素を、「タスク」と「リスク」に分けて考えてみましょう。

タスクとは、プロジェクトを構成する個々の作業です。これは「足し算」的な要素と言えます。タスクを一つ一つ積み上げていき、全て完了すればプロジェクトが終わる。足し算的な要素の集まりは、統計的に正規分布に従いやすく、比較的予測がしやすい性質を持ちます。皆さんの日常で経験するような小さなプロジェクトは、多くがこの足し算の世界で完結します。

一方、リスクはプロジェクト全体に影響を及ぼす可能性のある不確実な要素です。例えば、「ある技術的な問題が発生すると、プロジェクト全体が10%遅延するかもしれない」「仕様の認識齟齬により、プロダクトの効果が半減するかもしれない」といったものです。これは「掛け算」的な要素です。たった1つのリスクが、プロジェクト全体の結果を大きく変動させます。掛け算的な要素が絡むと、その結果は対数正規分布のような、裾野の長い分布に従うことが知られています。この「長い裾野」が、いわゆる「プロジェクトの大炎上」を引き起こす要因となります。

プロジェクトの規模が大きくなればなるほど、この掛け算的な性質、すなわちリスクの要素が増え、その影響も顕著になります。したがって、EMが行うべきプロジェクトマネジメントとは、いかにプロジェクトを足し算の世界に閉じ込め、掛け算的な性質を持つリスクを特定し、管理・低減していくか、という活動なのです。

さらに、ソフトウェアには「目に見えない」という厄介な性質があります。「進捗〇パーセントです」という報告が、どれだけ実態を表しているでしょうか？「ほぼ完了です、あとは実装だけです」という言葉の裏に、どれだけのリスクが隠れているでしょうか。

この「隠れた進捗」というリスクに立ち向かうために、アジャイルソフトウェア宣言でうたわれている価値観、特に「動くソフトウェア」を重視する考え方があります。

包括的なドキュメントや計画に従うこと以上に、実際に動作するものを短いサイクルで確認し、ステークホルダーに見せていく。これにより、進捗を「隠せない」状況を作り出し、認識の齟齬や問題を早期に発見（＝リスクを早期に曝露）することができるのです。

まとめると、プロジェクトマネジメントとは、タスクではなくリスクを中心に捉え、プロジェクトを可能な限り小さく保ち（足し算の世界に近づけ）、動くソフトウェアを通じて早期にリスクに曝露し、真の進捗にフォーカスし続ける活動である、と言えるでしょう。これは、ウォーターフォールであれアジャイルであれ、プロセスによらず普遍的に重要な考え方です。

プラットフォームマネジメントは、ソフトウェアを効率的に開発・発展させるための土台を管理し、開発者体験を向上させる活動です。

CI/CD、品質のシフトレフト、静的解析、フィーチャートグル、カナリアリリース、オブザーバビリティといった技術やプラクティスは、すべてフェイルファストの原理に基づき、いかに効率的に失敗（＝問題発見）を生み出し、早く修正できるようにするかを目指しています。

要求定義段階で不具合を発見・修正するコストに比べ、リリース後に修正するコストは何十倍にもなります。だからこそ、開発プロセスの早い段階で品質保証活動を行うシフトレフトは、手戻りを大幅に削減し、開発効率を飛躍的に向上させる力を持っています。

また、フロー効率を高めるためのCI/CDパイプラインの自動化や効率化を行い、繰り返し行われるビルド、テスト、デプロイのプロセスを高速化・安定化すると、頻度が質に転化し、結果として品質の確保と顧客への価値提供の効率の最大化につながります。

また、「失敗しても大丈夫」な環境を技術的につくること、すなわち「コード修正の心理的安全性」を提供することも重要です。これにより開発者はリスクを取りやすくなり、積極的に挑戦できるようになります。

技術的負債もこの領域の重要テーマです。ソフトウェア内部には「見えるもの」と「見えないもの」があり、この非対称性が技術的負債という問題を加速させます。フィリップ・クルーシュテンの定義を借りて整理してみましょう。

新機能（見えるプラス価値）やバグ（見えるマイナス価値）に対し、アーキテクチャや開発者体験は「見えないプラス価値」、そして技術的負債は「見えないマイナス価値」として整理できます。つまり、見えないことこそが技術的負債の本質的な性質なのです。そして、この技術的負債と、アーキテクチャや開発者体験といった見えないプラス価値は、対の存在と言えます。

「負債」というアナロジーは、この「見えない」問題を関係者に認識させ、対応の必要性を訴えるためのコミュニケーション手段として使われます。しかし重要なのは、技術的負債とは、見えさえすれば管理可能な「非機能要件の束」であるということです。解析ツールやテスト、アーキテクチャ決定レコード（ADR）、ドメインモデリングなどを通じて、この見えない負債を可視化し、計画的に管理していくことが求められます。

プロダクトマネジメントとプロジェクトマネジメントの最も大きな違いは、その目的です。プロジェクトは「終わらせること」が重要ですが、プロダクトは「事業を終わらせないこと」が重要です。

プロダクトマネジメントで核となるのは、仮説検証サイクルの管理です。短期的な売上や機能開発だけでなく、顧客価値を起点とした成長の仕組みを構築・管理することが求められます。

価値あるプロダクトを提供し、顧客が繰り返し使ってくれるようになれば、顧客は定着し、自然と増加していきます。これがオーガニックな成長です。しかし特に目指すべきは、プロダクトが自律的に成長していく仕組み、すなわち「グロースサイクル（フライホイール）」を構築し、それを力強く回していくことです。フライホイールとは「弾み車」のことで、一度回転が始まると、その勢いによってさらに回転が加速していくような自己強化型のループ構造を指します。

例えば、

1. 1. 良い顧客体験が更なる利用を促す
2. 2. 利用が増えることでデータが蓄積されプロダクトが改善
3. 3. 改善されたプロダクトが新規顧客を引きつける
4. 4. 顧客が増えることで収益が上がり更なる投資が可能になる

といったサイクルが回り始めると、それぞれの要素が相互に作用し、プロダクトは自律的に成長していきます。

このように、投入したエネルギー（開発リソースなど）が、次の成長を生み出すエネルギーへと転換され、サイクルが自己強化的に回り続ける状態を作り出すこと。これが指数関数的な、すなわち非連続的な成長を実現する鍵となります。

したがって、プロダクトマネジメントの本質は、単に機能を作ることではなく、この「弾み車」となるグロースサイクルを見つけ出し、構築し、それが健全に回り続けるようにマネジメントして、プロダクトに自律的な成長、すなわちレバレッジの効いた状態をもたらすことにあると言えます。この弾み車が回り始めれば、資源を継続的に投下でき、マーケットフィットの限界までオーガニックな成長を続けることが可能になるのです。

では、どのようにしてグロースサイクルを見つけ出し、効果的に回していくのでしょうか。ここで重要になるのが仮説思考、特に「仮説法（Abduction）」の活用です。

これは、観察された事実から、それを最もよく説明する大胆な仮説を導き出し、その仮説を検証するための証拠を探しに行く思考プロセスです。プロダクト開発においては、限られた証拠から「もしかしたらこうではないか？」という大胆な仮説を立て、それを検証するために果敢に実験に介入します。

その実験結果から得られるファクトを積み重ねていくことで、より確からしい方向性を見出し、プロダクトを進化させていくのです。グロースサイクルを構築・改善していく過程においても、この仮説思考に基づいた実験と学習の繰り返しが不可欠です。

ただし、プロダクトマネジメントには常に「探索（Explore）」と「活用（Exploit）」のジレンマが伴います。

・探索：新しい市場機会や顧客価値を探すための実験的な活動。不確実性は高いが、大きな成長の可能性を秘める。
・活用：既に分かっている顧客の課題を解決し、既存の価値を最大化する活動。確実性は高いが、成長には限界がある。

プロダクトの初期段階では探索が重要ですが、成長期に入ると目の前の顧客課題に対応する「活用」に偏りがちです。しかし、活用ばかり続けていると、いずれ成長は鈍化します。その前に、次の成長ドライバーとなる「探索」活動にもリソースを割かなければなりません。この探索と活用のバランスを、プロダクトの状況や戦略に応じて見極め、優先順位をつけていくことが、プロダクトマネージャーやエンジニアリングマネージャーの重要な役割です。

ここまで4つのPについてお話ししてきましたが、「これら全てを完璧にこなせないとEMではないのか？」と不安に思う方もいるかもしれません。私の答えは明確で、「スーパーマンである必要はない」ということです。

マネジメント（Management）の語源は、「なんとかする」「やりくりする」といった意味合いです。つまり、エンジニアリングマネジメントとは、「エンジニアリングによる価値実現のために、なんとかする」ことです。

EM自身が全ての領域に精通し、実行できる必要はありません。しかし、何が課題で、何をすべきかを理解し、必要なリソース（人、モノ、カネ、情報）を調達・調整して「なんとかする」ことが求められます。そのためには、やはり4つのPの各領域について、基本的な理解、すなわち「分かっている」状態であることが不可欠なのです。

執筆・編集：光松 瞳