ここ数ヶ月、私は創業者、エンジニア、オペレーターたちと一つの問いについて議論を重ねてきました。「AI時代において、組織はどのような姿であるべきか？」という問いです。これらの対話から――そして自ら実践してきた経験から――私は、組織設計が競争変数として著しく過小評価されているという確信に至りました。私のテーゼは、組織そのものの形こそが、AI時代における次世代企業にとって最も過小評価され――そして最も重大な意味を持つ――変数であるということです。モデルではありません。ツールでもありません。組織図こそが鍵なのです。
以下では、私たちのチームが実践の中で採用した3つの思考の転換を、それぞれを裏付ける――そして複雑にする――研究とともに共有します。
転換1：AIにできると想定する。できないときだけ人が介入する。
私たちの開発ワークフローにおいて、デフォルトのアクターは人間ではなく、AIです。パイプライン全体がこの前提のもとに設計されています。設計ドキュメント、コーディング、コードレビュー、デプロイ後のモニタリング――すべてのファーストパスをAIが担います。私たちのツールチェーンは、プロジェクト管理にLinear、実装にClaude CodeなどのAIコーディングエージェント、自動コードレビューにCodeRabbit、ログ分析とモニタリングにInstanaを統合しています。このアーキテクチャのもとでは、AIが実行しAIがスクリーニングを行い、人間はAIレイヤーが問題を検知したとき、または不可逆性の境界に触れる変更があるときにのみエスカレーションします。リスクの低いコードであれば、エンジニアが一度もIDEを開くことなく本番環境にデプロイされることも十分にあり得ます。
このパイプラインにおける最後のセーフティネットがコードレビューです。そしてここで本質的な問いが浮かび上がります。従来の人手によるコードレビューは1〜2日かかるかもしれません。AIコードレビューは10分です。その速度と引き換えに、わずかなリスク増加を受け入れる覚悟はあるでしょうか？小規模な企業にとって――特にセキュリティクリティカルでない更新については――答えはほぼ間違いなくイエスです。何か壊れたら、多くの場合コミットをリバートすればよいのです。しかし「リバートして終わり」がカバーできるのは障害の一部にすぎません。データベースマイグレーション、データ破損、副作用を伴う外部API呼び出し、送信済みの通知、決済トランザクションなどはgit revertでは取り消せません。AI-firstパイプラインには、ハッピーパスでの高速ロールバックだけでなく、こうした不可逆性の境界における意図的なガードレールが必要です。
「AIにできることはAIにやらせる。何かがうまくいかなかったとき、人間が修正する。」 AIによるコードレビューの導入は、このメンタルモデルの転換を示す教科書的な事例です。AIが完璧かどうかの問題ではありません。たまに失敗するコストが、恒常的な人的ボトルネックのコストより低いかどうかの問題なのです。
研究が示していること
Shopifyはこの原則を全社規模で実践しています。CEOのTobi Lütkeは2025年4月の社内メモでAI活用を基本的な期待事項と宣言し、追加人員を要求する前にAIにはその仕事ができないことを証明するようチームに求めました。VP of EngineeringのFarhan Thawarは数ヶ月以内にCursorのライセンスを3,000件発注し、最も急速に利用が拡大したのはエンジニアではなく、サポートチームと営業チームでした。
Klarnaはこの戦略を最も積極的に実行しました。CEOのSebastian Siemiatkowskiの公式発言によれば、従業員数を約5,500人から3,400人へ――40%削減――しながら、従業員一人あたりの売上を$400,000から$700,000に急増させました。しかし2025年半ばまでに、Siemiatkowskiは過剰修正であったことを認めました。Klarna自身の報告によれば顧客満足度が低下し、同社は複雑なやり取りのために人間のエージェントを再雇用し始めたのです。Klarnaの方向転換は示唆的です。「AI-first」は「AI-only」を意味しません。フォールバックパス――問題が発生したときに介入する人間――は堅牢かつ意図的でなければならず、後付けであってはなりません。
GitHubのランダム化比較試験では、開発者がCopilotを使用してタスクを55.8%速く完了したことが判明しました。しかし、これまでで最も厳密な研究――2025年7月のMETRによる経験豊富なオープンソース開発者を対象とした試験――では、参加者はAIツールを使用した場合に実際には19%遅くなっていたにもかかわらず、自分では20%速くなったと感じていたことが明らかになりました。認識と現実の間に43ポイントもの乖離があったのです。CodeRabbit独自の分析では、AI生成コードは全体で1.7倍多くの問題を含み、XSS脆弱性の発生率は人間が書いたコードの2.74倍でした。
これらの知見はAI-firstワークフローを否定するものではありません。設計上の課題をより鮮明にするものです。運用モデルは「AIが実行・スクリーニングし、人間が例外時にエスカレーションする」であり、「AIが全てを無監督で行う」ではありません。Human-in-the-loopは飾りではありませんが、デフォルトのアクターでもありません。適切なチョークポイント――コードレビューが最も重要な箇所です――に配置されなければならず、組織は「リバートして修正する」ことを障害状態ではなく通常の運用手順として扱う文化を持つ必要があります。
転換2：コーディネーションオーバーヘッドを削減する。プロセスではなく、成果を所有する。
第二の転換は、プロセスベースの分業から成果ベースの分業への移行です。各チームメンバーは中間的な作業工程ではなく、最終成果物そのものに責任を持つべきです。人間同士のコーディネーションが少なければ少ないほど、コミュニケーションコストは低くなります。そしてAIが個人の能力を十分に高め、タスクの分解が不要になった領域では、成果の所有がプロセス分解よりも効率的な協働の形になります。
プロセスベースの分業がデフォルトになった理由は単純でした。プロジェクトが複雑になりすぎて一人では対処しきれなくなり、作業を専門家間で分解する必要が生じ、コーディネーションがその分解の対価となったのです。しかし開発チームを率いた経験のある人なら誰でも、チームスケーリングの非線形性を知っています。チームが2〜3人から5人に増えるとき、生産性は線形に向上しません――私の経験では、一時的に低下するのです。私が見てきた限り、5人のチームは、大きな規模で生産性が回復するまで、元の2人のチームより少ない成果しか出せないことがあります。正確な変曲点はタスクの結合度、マネジメントの質、ドメインによって異なりますが、一般的な形状は一貫しています。スケーリング初期においてコーディネーションコストは能力より速く増大するのです。2人のチームはオーバーヘッドがほぼゼロで運営できます。3人目が加わった瞬間、コーディネーションの負担が追加された能力を相殺して余りあることがあります。
AIは各個人の能力の上限を劇的に拡張しました。かつてはチーム全体への分解を必要とした範囲の作業が、AI支援を受けた1〜2人で対処可能になりつつあります。これが欠けていたピースです。BrooksとQSMはコーディネーションコストがチーム拡大を罰することを証明しました。AIは個人の能力を十分に引き上げることで方程式を変え、多くのタスクをそもそも分解する必要がなくしたのです。その結果、かつては理想論にすぎなかった成果ベースの分業が、現実的なエンジニアリング上の選択肢になりつつあります。作業を小さく、相互依存的で、逐次的なタスクに分解するのではなく、大きく、独立して検証可能で、並列化可能なブロックをコラボレーションの単位として定義できるようになります。開発におけるコミュニケーションコストは大幅に低下します――ただしゼロにはなりません。共有API、データモデル、デプロイ調整といった横断的な関心事には依然として人間同士の調整が必要だからです――しかし、高効率な並列実行がはるかに現実的になります。
研究が示していること
Fred Brooksは1975年にコーディネーション問題を定式化しました。チーム内のコミュニケーションチャネルはn(n-1)/2で増大するため、10人のチームには45のチャネルがあるのに対し、5人のチームではわずか10です。QSMの10,000件以上のデータベースから抽出した1,060件のソフトウェアプロジェクトの分析は、3〜7人のチームが最も高い生産性、最短のスケジュール、最低のコストを達成することを実証的に確認しました。最も衝撃的な発見は次のとおりです。大規模チームは小規模プロジェクトでスケジュールを約24%、大規模プロジェクトで約6%短縮するものの、コストは3〜4倍、欠陥密度は2〜3倍に増加していました。これは、私が実体験から述べたJカーブが、大規模に検証されたものです。
Microsoft Researchの調査では、開発者が実際にコードを書いている時間は全体の約11%にすぎず、残りはミーティング、レビュー、コミュニケーション、ドキュメンテーションに費やされていることが判明しました。AIが主にコーディング部分を加速するだけであれば、周囲のコーディネーションオーバーヘッドを構造的に除去しない限り、全体的な効果は限定的です。これは成果ベースの働き方を支持する論拠になります。最大の時間の浪費がコーディングではなくコーディネーションであるなら、個人を速くするだけでは不十分で、作業の分け方そのものを再構築する必要があります。成果の所有はその一つの方法です――唯一の方法とは限りませんが、AIが個人の能力を十分に高め、細粒度の分解が不要になったとき、自然にフィットするアプローチです。
AIによるチーム圧縮の証拠は、アナリストの推計や業界ランキングから浮かび上がりつつありますが、監査済みの財務報告に基づくものではまだありません。Midjourneyはわずか11人の従業員で推定$200M ARRに達し、その後約40人で$500M近くに到達したとされています。CursorはBloombergによれば、50人未満でSaaS企業史上最速クラスの$500M ARRを達成しました。トップクラスのリーンなAIスタートアップにおける従業員一人あたりの売上は、Jeremiah Owyangの分析によると平均推定$3.48Mであるのに対し、従来のSaaS企業では$610K――5.7倍の効率格差です。これらの数字は並外れたレバレッジを示していますが、その原因を分離することはできません。プロダクト・マーケット・フィット、タイミング、プロダクトの性質（限界費用がほぼゼロのソフトウェア）、創業者の資質、すべてが寄与しています。確実に言えるのは、これらの企業が構造的な共通点を持っていることです――少人数のチーム、最小限のハンドオフレイヤー、高い個人所有――そしてこの特性は少なくとも成果ベースモデルと整合的です。重要な留保として、これらはすべてAIネイティブまたは高レバレッジのスタートアップです。同じ比率がより大規模で、規制が厳しく、レガシーを抱える組織でも成り立つかどうかは未解決の問いであり――エビデンスベースは狭いということについて正直でありたいと思います。
あるソフトウェア開発組織を追跡した縦断研究（2023年〜2025年）では、AIが個々のタスクを加速する一方で、パフォーマンスに対する説明責任や脆弱なコミュニケーションといった持続的なコラボレーション上の課題は未解決のままであることが判明しました。これは別の角度から同じ論点を裏付けています。AIは実行のボトルネックを解消しますが、コーディネーションのボトルネックは解消しません。成果を中心に再構築しない組織は、個人のアウトプットが増加しても、コミュニケーションコストが変わらないことに気づくでしょう。
転換3：エンジニアからビルダーへ――プロダクトと実装を一つの役割に圧縮する。
ロジックは明快です。エンジニアリングチームこそが、実際の成果物に最も近い存在です。プロダクトを構築する人間がプロダクトの成果も所有すべきであり――AI拡張されたワークフローにおいて、その人物はますますエンジニアになりつつあります。 これはエンジニアが本質的に優れたプロダクト思考者であるという主張ではありません。実装とプロダクト判断を一つの役割に統合することで、別々の役割が生み出す翻訳ロスを削減できるという主張です。
しかし、この転換にはエンジニアの進化が求められます。私がビルダーと呼ぶ存在になる必要があります。ビルダーとは、エンジニアとPMを兼ね備えた人材です。ビルダーは技術的能力とプロダクト感覚を兼ね備え、ユーザーと直接対話できます。ビルダーは中間フィルターや歪曲なしにユーザーの声を聞き、実際のニーズに応じて構築し、その結果に責任を持ちます。
なぜこの進化が必要なのでしょうか？エンジニアは誰よりもモデルの能力の限界を理解しているからです。ユーザーからリクエストが来たとき、エンジニアは現在のAIツールで実現可能かどうかをすぐに判断できます。これがフィージビリティの優位性であり――それは実在しますが、不完全です。何が構築できるかを知ることと、何を構築すべきか、誰のために、どの順序で構築すべきかを知ることは同じではありません。後者にはプロダクトセンスが必要です。ユーザーへの共感、優先順位づけ、戦略的判断――従来PMが担ってきたスキルです。ビルダーのテーゼは、エンジニアがすでにこれらのスキルを持っていると主張しているわけではありません。フィージビリティ判断とプロダクト判断を同一人物に圧縮し――両方を育成すること――が、価値以上の歪みをもたらす翻訳レイヤーを排除するという主張です。技術者でないPMが提供する翻訳レイヤー――ユーザーニーズを技術仕様に変換する作業――は、プロダクトを構築する人間が両方の側面を理解するよう訓練されているとき、はるかに必要性が低くなります。
念のために明確にしておきます。技術者でないPMもビルダーになることは完全に可能です。モデルやツール、実装の基礎を学ぶことは100%可能です。「ビルダー」というアイデンティティはCS学位によって制限されるものではありません。
はっきり述べておきます。ビルダーモデルはアンチPMの立場ではありません。責任の単位に関する主張です。PMの中核機能――ユーザーを理解すること、優先順位を設定すること、成功の定義を明確にすること――はなくなりません。実装する人間と同一人物に圧縮されるのです。「何を構築すべきか」と「何を構築できるか」のフィードバックループが、ハンドオフの境界を越えるのではなく、一人の頭の中で回るようになるということです。
しかし、多くの組織における現状は異なります。技術者でないPMがエンジニアリングチームを率いています。PMがAIに何ができて何ができないかの実用的なモデルを欠いている場合、ユーザーニーズから技術仕様への変換に歪みが生じます。エンジニアはユーザーから切り離され、PMが渡すタスクにのみ責任を持ちます。これは非効率のループを生み出します。PMが仕様を誤り、エンジニアが誤った仕様を実装し、ユーザーは不満を抱き、AIの潜在能力は実現されません。このループを断ち切ること――PMとエンジニアを一人の「ビルダー」に統合し、成果全体を所有させること――が構造的なブレークスルーなのです。
採用と報酬も変わらなければならない
私自身の実践において、ビルダーを見極める最良の方法は1〜2日のチャレンジプロジェクトです。タスクは、与えられた時間内に合理的に完了できる範囲を意図的に超えて設計されています。評価しているのは、候補者がタスクを完了するかどうかではなく、進捗を加速するためにどれだけ効果的にAIを活用するかです。ここで明らかになるのが真のスキルです。単独でのコーディング能力ではなく、プロダクトの成果に向けてAIをオーケストレーションする能力です。
報酬体系も見直しが必要です。従来の「固定給＋ボーナス」の構造は、プロセスの一工程を担う労働者向けに設計されたものです。成果全体を所有するビルダーには適合しません。私は現在、コントラクターとパートナーの間に位置するモデルを試行しています――エンドツーエンドの責任と経済的インセンティブを一致させる構造です。この分野については、より多くの人と探求し議論したいと考えています。
研究が示していること
Linearはビルダーモデルを大規模に体現しています。評価額$1.25Bと報じられる同社は、約100人の従業員とわずか2人のPMで運営されています。2〜4人のチームがプロジェクトごとに編成され、完了後に解散します。OKRなし、A/Bテストなし、ストーリーポイントなし。CEOのKarri Saarinenは、なぜ大規模チームが標準になったのか理解できないと述べています――彼の経験では、小さなチームが常により高い品質とより速いスピードを実現してきたからです。（具体的な人員数やリテンションの数字は、公式開示ではなくプレスインタビューに基づくものです。）
Andrew Ngは最も挑発的な定量的フレーミングを提供しました。従来のPMとエンジニアの比率（約1:4〜6）が逆転する可能性があるというものです。彼は、PM 1人に対しエンジニア0.5人という比率を提案したチームを引き合いに出しました――1年前なら非常識とされたであろう比率です。その論理は、エンジニアはAIにより10倍速くなったが、PMは同じ割合で速くなっていない――PMが新たなボトルネックになっているということです。逆説的に、彼はこれが「何を構築すべきか」を定義できる人材の需要を増加させる可能性があるとも主張しています。これはビルダーのテーゼとまさに一致しています。価値あるスキルは、コーディングや仕様書作成を単独で行う能力ではなく、その二つの融合なのです。
「Product Engineer」という肩書は、2022年から2024年にかけてHacker Newsの"Who's Hiring"掲載において約2%から約5%へとおよそ倍増しました。Claire VoはLenny & Friends Summitでの「Product Management is Dead」講演で、AIがタレントスタックを統合するだろうと主張しました――PM、エンジニアリングリード、デザイナーという従来のトライアドは、一人の「AI-powered Triple Threat」へと進化する可能性があるというのです。
組織のフラット化は、すでに大企業でも顕在化しています。Gartnerは2026年までに20%の組織がAIを活用して組織構造をフラット化し、現在の中間管理職の半分以上を削減すると予測しています。AmazonのCEO Andy Jassyは、個人貢献者とマネージャーの比率を少なくとも15%引き上げることを義務付けました。
採用に関して：状況はまだ流動的です。Karatによれば、ほぼ3分の2の企業が面接でのAI使用を依然として禁止しており、AI対応に評価を更新している企業は30%未満です。しかし先行者はその方向性を示しています。Metaは候補者がコーディングテスト全体を通じてAIアシスタントを使用する面接を試験的に導入しています。私が述べた転換――生のコーディング能力ではなくAI活用力を試すチャレンジプロジェクト――はまだ業界標準ではありませんが、その方向性は明確です。
報酬に関して：a16zの2024年12月の分析は、AI-native企業が成果ベースの価格設定に移行しつつあることを指摘しており、これはやがて報酬体系にも波及するでしょう。PwCの2025年データでは、AIスキルを持つ労働者がすでに56%の賃金プレミアムを享受しており、前年の2倍です。私が試行しているコントラクター・パートナーのハイブリッドモデルはこの変化に対する一つの回答ですが、より広い論点は、プロセスワーカー向けに設計された報酬モデルではビルダーを引き留められないということです。
より難しい問い
上述した3つの転換――AI-firstワークフロー、成果ベースのコラボレーション、エンジニアからビルダーへの進化――は相互に強化し合うものですが、厳密に相互依存であることを証明したわけではありません。それぞれを部分的に、あるいは独立して採用することも可能です。しかしそれらを総合すると、同じ方向を指し示しています。組織の形が、AIの潜在的価値のうちどれだけを実際に獲得できるかを決定する。 世界最高のモデルを持っていても、AIがすでにその必要性を低下させたコーディネーションレイヤーを通じて意思決定がルーティングされるような組織図であれば、その価値の多くを取り逃がすことになります。この主張のエビデンスベースは、主にAIネイティブのスタートアップと先進的なテック企業から得られたものです――レガシーの制約、規制上のオーバーヘッド、数千人の従業員を抱えるエンタープライズに一般化できるかどうかは、より困難な試金石です。
McKinseyの2025年State of AI調査では、25の組織属性をテストした結果、企業が生成AIからEBITインパクトを達成できるかどうかに最も大きな影響を与えたのは「ワークフローの再設計」でした。しかし、ワークフローを根本的に再設計した組織はわずか21%にとどまり、BCGは60%の企業が多額の投資にもかかわらずAIから実質的な価値を生み出せていないことを明らかにしました。
最も永続的な洞察は、Kasparovの2005年フリースタイルチェストーナメントから得られます。優勝したのは、強力なコンピューターを持つグランドマスターではなく、3台の弱いコンピューターと優れたプロセスを持つ2人のアマチュアでした。Kasparovの観察――「弱い人間＋マシン＋より良いプロセスは、強力なコンピューター単体よりも優れており、さらに注目すべきことに、強い人間＋マシン＋劣ったプロセスよりも優れていた」――は今もなお基本原則として有効です。
プロセス設計は、生の能力に勝る。組織設計こそが拘束条件であることが多い――唯一の要因ではないが、最も過小評価されている要因である。
私がまだ考え続けている――そして他の人々にも一緒に考えてほしい――問いは、この定常状態がどのような姿になるかということです。ビルダーモデル、成果ベースのチーム、AI-firstパイプライン。これらは今、小さな会社で速く動いている私たちにとって機能しています。これが50人、あるいは500人の規模でも成り立つかどうかは、まだ実験の途上にあります。