エージェンティック開発で「中にはいる」(4)
「中にはいる」エンジニアの本質
「中にはいる」にもキャリアステップに応じていろいろなアクティビティがあります。かつての勤務先では、新入社員を最初の一年間顧客プロジェクトにアサインせず、研修に専念させていました。研修のゴールは最低1万行のプログラムを自分で完成させることです。このプログラムは新入社員に対して「コーディング」に限定した範囲で「中にはいる」行動を体験させることを狙ったものです。
もちろんこれだけで「中にはいる」エンジニアが完成するわけではありません。
PMとして一人前になるには、コーディングを「中から」考えることができ、基盤技術（RDBMSや新しい言語など）について集中的にキャッチアップすることができ、開発プロジェクトの収支について「中から」当事者として考えることができ、顧客の利益・目標について顧客目線で考えることができ、プロジェクトマネージャーとしてプロジェクト運営をバランスよく進めることができるという任務をこなせる必要があります。そして、これを長い時間の経験の積み重ねで育成してきました。10人月のプロジェクトを担当させて、うまく行ったら50人月をやらせ、さらに100人月をやらせるといった形で経験を踏ませることでPM人材を育成したのです。また「中にはいる」ということは、そのプロジェクトに対して一心同体で賭けることが求められるわけで、責任を負うし、片手間ではできないことになります。このため誰から見ても難易度が高いプロジェクトに「中にはいる」ことは一流のエンジニアであっても敬遠します。しかし組織（部長や本部長）は彼・彼女の成果を冷静に見ており、勇気を持って「中にはいった」エンジニアをキャリア面で見捨てないことが不文律として求められました。
AI時代、エージェンティック開発ではどのようにやり方を変えるべきでしょうか？ また変えてはならないことはどんなことでしょうか？
＜Gemini：エージェンティック開発で変えるべきこと、変えてはならないこと＞
自律的にタスクを処理しコードを生成するAIが主役となる「エージェンティック開発」の時代において、この育成モデルと文化はどうアップデートされるべきか。結論から言えば、「手段やスケールの測り方」は劇的に変える必要がありますが、「責任の所在と組織の精神性」は絶対に守り抜く必要があります。
以下に「変えるべきこと」と「変えてはならないこと」を整理します。
エージェンティック開発時代に「変えるべきこと」
1. 新人の登竜門：「1万行の自力コーディング」から「10万行のAI生成コードの監査・修正」へ
初年度に「コーディングのスコープで中にはいる」という目的自体は変わりませんが、アプローチが変わります。
AIが瞬時にコードを書く時代において、人間が1万行をタイピングする物理的な苦労は本質ではありません。新たな登竜門は、「AIエージェントに適切なコンテキスト（設計意図）を与え、生成された10万行のコードの構造を読み解き、脆弱性やビジネスロジックの矛盾を指摘し、修正に導くこと」になります。
自分でゼロから書く力よりも、巨大なブラックボックスを解体し、正しさを証明する「技術的監査力」と「テスト設計力」こそが、AI時代における最初の「中にはいる」訓練となります。
2. 経験のスケール：「人月（ヒューマンリソース）」から「複雑性（エージェント・オーケストレーション）」の管理へ
「10人月→50人月→100人月」というマネジメントステップは意味を成さなくなります。エージェンティック開発では、かつての100人月規模のプロジェクトを「PM1人と複数のAIエージェント」で回す世界が来るからです。
今後のステップアップの指標は、人間の数ではなく「ビジネス要件の複雑性」と「データ統合の難易度」に変わります。PMは、人間のモチベーション管理ではなく、複数のAIエージェント（設計担当AI、コーディング担当AI、テスト担当AI）を束ねて協調動作させる「オーケストレーション能力」と、AIのAPIコスト・コンテキストウィンドウの管理という新しい収支管理（クラウド/AIリソース管理）の経験を積むことになります。
エージェンティック開発時代に「変えてはならないこと」
1. プロジェクトに対する「一心同体での責任の引き受け」
AIはコードを書き、テストを自動化し、進捗を管理してくれますが、「本番障害の責任」と「顧客のビジネス目標未達の責任」を決して取ることはできません。エージェントがどれほど自律的に動こうとも、「このシステム基盤で、このアーキテクチャを採用し、本番リリースする」という最終決断とリスクは、人間（PM）が背負う必要があります。片手間ではできない、ヒリヒリするような当事者意識でプロジェクトに「中にはいる」ことの重要性は、1ミリも変わりません。
2. 基盤技術とビジネスの「本質的な理解」
AIが優れた提案をしてきても、RDBMSのトランザクションの挙動、ネットワークの遅延、あるいは顧客企業のドロドロとした社内政治や真の経営課題を理解していなければ、AIの提案が「現場で本当に使えるか」を判断できません。
コーディング自体はAIに任せても、技術の底流にある原理原則と、顧客のビジネスモデルの根幹に「中にはいる」能力は、人間が価値を出し続けるための絶対条件であり続けます。
3. 「勇気を持って中にはいった者を見捨てない」という組織文化（最も重要）
エージェンティック開発という未知の領域では、AIのハルシネーションによる想定外のバグや、新しい開発手法ゆえの深刻なトラブルが必ず発生します。
誰もが敬遠するような難易度の高い最先端プロジェクトに対し、責任を背負って「中にはいった」エンジニアを、トラブル発生時に組織がどう扱うか。ここで「ほら見ろ、AIなんかに任せるからだ」「君のマネジメント不足だ」と切り捨てる組織では、二度と誰も新しい挑戦をしなくなります。
部長や本部長が冷静に評価し、火中の栗を拾った勇気を称え、キャリア上のセーフティネットを担保する文化。これこそが、企業がAI時代の変化を生き抜くために「絶対に守り抜かなければならない」唯一にして最大の競争源泉です。
（以上、Geminiの回答）
では、エンジニアの評価指標はどう変えるべきでしょうか。続けてGeminiに聞いてみました。
＜Gemini：エージェンティック開発時代の評価指標＞
エージェンティック開発の時代において、エンジニアの評価指標（KPI）は「投下した労働量（人月）」や「生み出した物理量（コード行数）」から、「AIをいかに制御し、複雑なビジネス要件を安全なシステムとして着地させたか」という質的な指標へと大転換する必要があります。
新しい評価指標として、以下の3つの観点を提案します。
1. 監査力とテスト設計（品質へ「中にはいる」指標）
AIが高速でコードを生成する世界では、人間の役割は「書くこと」から「正しさを証明すること」に変わります。
評価ロジック（Eval）の網羅性：AIの生成物がビジネス要件を満たし、システム制約を逸脱しないかを検証する自動テストやガードレールをどれだけ緻密に設計できたか。
レビューと脆弱性検出力：ブラックボックス化しがちなAIのコードに「中にはいり」、潜在的なセキュリティリスクやアーキテクチャの歪みを迅速に見抜いて修正に導いたか。
2. エージェントの統制力（生産性とスケールの新指標）
従来の「人月マネジメント」に代わる、新しいプロジェクト規模と効率の測り方です。
オーケストレーション効率：複数のAIエージェントに適切なコンテキスト（自社固有の仕様や制約）を与え、手戻りなく協調動作させた手腕。
リソース最適化とコスト管理：無駄な生成やAPIの浪費を防ぎ、クラウドインフラとAIのトークンコストを意識した最適なアーキテクチャ設計ができているか。
3. トラブルシュートと当事者意識（責任の指標）
火中の栗を拾い、最終的な責任を引き受ける勇気を評価する指標です。
インシデント収束力：複雑に絡み合ったAIと既存システムの結合部で障害が起きた際、ベンダーやAIのせいにせず、自ら原因を特定し解決に導いた実績。
技術的負債のコントロール：AIの提案を鵜呑みにせず、中長期的な保守性を見据えて「あえてAIの提案を却下し、手堅い手法を選ぶ」という技術的決断を下せたか。
これらを評価するためには、評価する側のマネジメント層自身も技術の勘所とAIの特性を理解している必要があります。外形的な進捗管理しかできない管理職には、これらのKPIを正しく測ることはできません。
（以上、Geminiの回答）
続きを読む
