広木大地が考察する、EMの本質と未来：不確実性、フェイルファスト、そしてAI時代の生存戦略

エンジニアリングマネージャー（EM）の役割は多岐にわたり、その定義も変化し続けています。特に、急速に進化するAI技術は、私たちの働き方や組織のあり方に大きな変革を迫っています。

この変化の時代に、EMとして本当に向き合うべきことは何なのでしょうか？

本記事では、日本のエンジニアリングマネジメント領域を牽引してきた広木大地氏の、EM Conference Japan 2025の基調講演の内容を一部再構成してお届けします。

エンジニアリングの本質と、その方法論である「フェイルファスト」の原理。そしてAIが業務に入り込むことで起きる、組織やEMの役割の変化とは。新たな視点と実践のヒントが詰まっています。

• keyboard_arrow_down エンジニアリングの本質とは？
• keyboard_arrow_down エンジニアリングは「フェイルファスト」の原理によって駆動する
• keyboard_arrow_down AIの進化で、メンバーが「マネージャーの仕事」をするようになる
• keyboard_arrow_down EMは「AIをマネジメントするエンジニア」のマネージャーになる
• keyboard_arrow_down 組織とアーキテクチャの統一理論へ

まず、「エンジニアリングとは何か」という問いから始めたいと思います。私自身は、エンジニアリングとは、最初は曖昧な構想だったものが、最終的にソフトウェアという具体的で明確な形に落ちていく、その過程全体だと捉えています。この過程で、私たちソフトウェアエンジニアやチームは、実に多くの試行錯誤を繰り返します。

この「実現していくための試行錯誤」そのものが、エンジニアリングの本質ではないでしょうか。そう考えると、私たちの日々の活動の中に、様々な要素が見えてきます。

エンジニアリングの過程には、常に不確実性が伴います。分からないことを決め、未知の領域に挑戦し、それを明らかにしていく必要があります。この不確実性、言い換えれば「リスク」と向き合うことこそが、エンジニアリングの、そしてソフトウェアビジネスの本丸なのです。

私たちは日々、人間関係の不確実性、プロジェクトの不確実性、技術負債やアーキテクチャ、そしてマーケットといった、様々な不確実性と戦っています。その中で、物事を具体化し、明確化し、そして意思決定を重ねていかなければならない。

「蓋を開けてみなければ分からない」のであれば、その蓋を開け、コミュニケーションを取っていく勇気を持つこと。小さな実験を繰り返し、小さく、そして早く失敗しながら成功に近づけていく。この考え方が、現代のソフトウェア開発において非常に重要だと考えています。

この、不確実性を減らすための試行錯誤は、「フェイルファスト（FailFast）」という原理に集約されると私は捉えています。スタートアップ界隈でよく聞かれる言葉ですが、「失敗してもいいから、とりあえずやってみよう」といった安易な意味で捉えられがちな側面もあります。

しかし、本来フェイルファストとは、「早く失敗すること」、すなわち「リスクを早期に曝露すること」を意味します。問題や課題、あるいは認識の齟齬といったリスクを早い段階で明らかにできれば、それだけ早く、そして低コストで対処できるからです。手遅れになってから大きな問題として発覚するのを防ぎ、結果として、強靭でレジリエンスの高いプロダクトを実現することに繋がります。

このフェイルファストの原理に基づいて、ソフトウェア開発における様々な技術、文化、そして組織のあり方が作られてきました。

リスクを早期に曝露するには、メンバーが安心して課題を指摘し合える関係性（心理的安全性）と、失敗から学び合える文化が必要です。また、開発プロセスにおいては、短いイテレーションで実際に動くソフトウェアを確認することで、認識のずれや技術的な問題を早期に発見できます。そして顧客や市場にプロダクトを早期に提示し、フィードバックを得ることで、市場とのずれというリスクを早期に発見できる。

エンジニアリングマネジメントにおける多くの活動は、まさにこのフェイルファストの原理によって駆動されています。EMは、チームや組織がこの原理に基づいて効果的に活動できるよう、環境を整え、プロセスを設計し、文化を醸成していく役割を担っているのです。

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

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

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

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

※4つのPは【「なんとかする」ための“引き出し”を増やす。EMの「4つのP」を捉え直し改善する方法】にて詳細に解説しています。

では生成AIの発展により、これからのEMがどうなっていくのか、私なりの考えをお話しします。まずはこれまでのソフトウェアの歴史に起きた変化を振り返ってみましょう。

ソフトウェア開発は常に「簡単」になり続けています。サーバー構築、フレームワークの利用、データベースアクセスなど、昔は専門知識と多大な労力が必要だったことが、今ははるかに容易になっています。しかし、情報処理速度が増加したことで、ソフトウェアに対する要求の「複雑化」も進んでいます。結果として、ソフトウェア開発における「複雑性あたりのコスト」は劇的に下がりました。

これにより、ソフトウェアの適用領域はあらゆる産業へと爆発的に拡大しました（Software is Eating the World）。これは、石炭の利用効率が上がった結果、石炭の用途が広がり、結果的に石炭消費量が増えたという「ジェボンズのパラドックス」と同様の現象が、ソフトウェアの世界でも起きていると見ることができます。生成AIの登場は、この「簡単化」の流れをさらに加速させるでしょう。

そしてこの変化は、私たちの働き方や組織のあり方にも大きな影響を与えます。かつて人間が行っていた、不確実性の低い定型的な作業は、ますますAI（≒半導体）に置き換えられていきます。

その結果、人間はより不確実性が高く本質的な領域に注力するようになり、組織構造や、組織に求められる機能が変わっていきます。

旧来は、経験豊富な先輩がいて、後輩がその背中を見て学び、同じようなスキルを身につけていく、比較的同質性の高いメンバーで構成された組織が一般的でした。マネジメントは上意下達のコマンド＆コントロール型が中心で、長期雇用を前提としたメンバーシップ型の考え方が主流です。

しかし、下の図の右側のように、メンバークラスが担っていた運営（Run the Business）をAIが代替していくと、状況は変わります。これまで主にマネジメント層が担っていたような、事業の成長（Grow the Business）や変革（Transform the Business）といった、より上流で本質的な領域に関わる思考や判断が、メンバークラスにも求められるようになります。

その結果、チーム内で必要とされるスキルや専門性が多様化します。エンジニアだけでなく、デザイナー、マーケター、データサイエンティスト、あるいは特定のドメイン知識を持つ専門家など、異なるバックグラウンドを持つ人々と協働（コラボレーション）することが不可欠になります。これは、単に性別や国籍といったデモグラフィックな多様性だけでなく、技能や役割における「全体論的な多様性」が重要になるということです。

このような新しい組織では、旧来型のマネジメントは機能しにくくなります。多様な専門家が自律的に能力を発揮するためには、トップダウンの指示命令ではなく、権限移譲を進め、各々が判断できる範囲を広げる必要があります。また、チーム全体が同じ方向を向いて進むためには、透明性の高い目標設定とその共有（OKRのような仕組み）、そして個々の役割と責任範囲を明確にするジョブディスクリプションの重要性が増してきます。

このような組織の変化は、一部の先進的な企業だけの話ではなく、また単なる流行でもありません。私は、仕事の進め方そのものがソフトウェア（AI含む）に移譲されてきたことによって引き起こされた、必然的な変化だと捉えています。

私自身、最近は複数のAIエージェントを並行稼働させ、指示を出しながら開発を進める、といったことを試しています。AIにタスクを依頼し、その結果を確認し、次の指示を出す。これはまるで、AIを部下としてマネジメントしているような感覚です。

そして気づくのは、自分自身がボトルネックになるということです。AIの能力を引き出すためには、的確な指示や課題設定が必要であり、それを人間が的確に行えないと、全体の生産性が頭打ちになってしまいます。これは、かつて自分がマネージャーになりたての頃に陥りがちだったマイクロマネジメントの罠を、AI相手に追体験しているかのようです。

ここから見えてくる未来像は、「全てのエンジニアが、AIをメンバーに持つエンジニアリングマネージャーになる」という可能性です。エンジニアはコードを書くだけでなく、AIを効果的に活用し、オーケストレーションする能力が求められるようになるでしょう。

では、その時、本来のエンジニアリングマネージャーは何をするのでしょうか？おそらく、AIと人間のエンジニアの両方を含む、より大きなシステム全体をオーケストレーションする、さらに高度な役割を担うことになるでしょう。

ここで、「人月の神話」で語られている「偶有的複雑性（Accidental Complexity）」と「本質的複雑性（Essential Complexity）」という概念が重要になります。

偶有的複雑性‥ツールや技術の未熟さ、環境構築の手間など、問題解決の本質とは関係なく発生する複雑性。AIの発展により、これらは大幅に削減されていくでしょう。

本質的複雑性‥顧客の真の課題は何か、ビジネスとしてどうあるべきか、どのようなソフトウェアを作るべきか、といった、問題領域そのものに内在する複雑性。

偶有的複雑性が減る一方で、私たちの生産性は向上します。仮に、今まで10人で作っていたものがAIの助けで1人でできるようになったとしたら、10人いれば、以前の10倍複雑な問題に取り組むことが可能になります。つまり、私たちは今後、より本質的な複雑性と向き合っていくことになるのです。

私は2018年に出版した『エンジニアリング組織論への招待』という本で、あえて「招待」という言葉をタイトルに入れました。それは、まさにこれから訪れるであろう時代を見据えていたからです。

これからの時代、私たちが指示を出す対象は、コンピュータか人間かを区別する意味が薄れていきます。クラウドを使えば、膨大なコンピューティングリソース（ある種の「部下」）を一瞬で用意できます。AIの進化により、コンピュータへの指示も、より抽象的で曖昧なもので済むようになるでしょう。

そうなると、人間をたくさん雇用してビジネスをスケールさせるという従来の考え方だけでは通用しなくなります。コンピュータと人間の区別をしないシステム設計や組織設計が、ますます重要になってきます。

ソフトウェアアーキテクチャの理論と、組織設計の理論には、実は非常に近しい部分があります。私は、今後この両者が融合し、「組織とアーキテクチャの統一理論」とも言うべきものが現れてくるのではないかと考えています。「招待」というタイトルには、そのような新しい時代への入り口に立っている、という思いを込めたのです。

私たちのロードマップは、技術的なアーキテクチャだけでなく、それと不可分な組織構造をも含めた、より大きなシステム全体の設計へと向かっていくのではないでしょうか。エンジニアリングマネージャーは、まさにその最前線に立ち、この変化をリードしていく存在になるのだと、私は信じています。

今日の話の中で、皆さんのこれからの活動において、少しでも参考になる点があれば嬉しく思います。ご清聴ありがとうございました。

執筆・編集：光松 瞳