オフショア開発における「AI駆動開発」― PMがコードを書き、エンジニアが“Thinker”になる新しいチームの姿 ―

はじめに：開発現場で起きている静かな変化

こんにちは、モンスターラボにてプロジェクトマネージャーを務めている野挽です。

ここ数年、「AI」「自動化」「効率化」という言葉が開発現場を賑わせてきました。しかし、私が体感したのは、そうしたツール的な進化ではありませんでした。私が見たのは、開発という営みそのものが根底から変わる瞬間でした。

先日、私はとあるプロジェクトでPdM・PMとして、AIと共にコードを書きました。そのコードをエンジニアがレビューし、議論を重ねる…そんな体験をしたのです。
「PMがコードを書く？」
「エンジニアがレビューだけ？」
最初は違和感の塊でした。しかし、その1サイクルを終えたとき、私は確信しました。
「これは、開発の新しい形だ」と。これまでのように「要件を文書に落とし、チケットを切り、伝達する」時代は終わりを迎え、AIが介在することで、ビジネスとコードが直接つながり、思考そのものがコードとして表現される時代がきます。
そして何よりも驚いたのは、この構造がオフショア開発という難題に対する、最も本質的な解答になりうるということでした。

➡︎【資料ダウンロード】オフショア拠点を活用したラボ型開発チーム構築のご紹介

オフショア開発が従来抱えていた課題

これまでオフショア開発の課題は、「言語の壁」「時差」「文化の違い」といった要因で語られることが多かったです。しかし本質はそこではないと私は考えます。その根底にあるのは、情報と意思決定の非同期構造です。

課題1：文脈が断絶する

PMはビジネスの背景を理解していますが、エンジニアは仕様書しか見えません。仕様書は意図を削ぎ落とした「結果」でしかなく、そこに「なぜ」がありません。結果、同じコードを見ても目的が共有されず、意図通りに実装されません。

課題2：意思決定のラグ

質問・確認・修正が、時差や文化の問題で遅れます。1つの問いに1日、仕様変更に3日といった具合に「日単位の遅延」が開発全体のリズムを崩します。

課題3：成果物がドキュメント駆動

仕様書、チケット、設計書、議事録。開発に必要な情報は常に分断され、“説明のための作業”が膨れ上がります。ドキュメントを作ること自体が目的化し、コードが後追いになります。

課題4：階層構造による分断

PM（プロジェクトマネージャー） → TL (テックリード)→ エンジニアという多層構造が、意思伝達を鈍らせます。物理的・言語的な距離も相まってプロジェクト全体を俯瞰することが難しくなり、分断が生まれます。

★オフショア開発が抱えている課題について詳しくはこちら

➡︎【資料ダウンロード】オフショア拠点を活用したラボ型開発チーム構築のご紹介

AIがもたらす構造的な解決策

オフショア開発が抱えていた課題はAI駆動開発によって解決が可能です。しかも、AI駆動開発が変えたのは、単なる「作業の効率化」ではありません。人と人、情報と意図の結びつき方そのものに変化をもたらしました。

解決策1：文脈をコードに埋め込む

AIに対してビジネス背景・依存関係・制約条件をプロンプトで伝えることで、コードそのものが“意図を内包した構造体”として生成されます。コードが仕様書を超え、会話の共通言語になります。

解決策2：意思決定の即時化

AIとの対話の中でPMが即座に設計・実装・検証を行います。かつて3日かかった確認が、30分で完結します。質問・確認のラグが消え、意思がリアルタイムで形になります。

解決策3：ドキュメント駆動からコード駆動へ

AIはコードと同時にコメント・ER図・API仕様まで出力します。仕様書、チケット、設計書、議事録とそれぞれに情報がまたがり、分断していたものが、「コード＝ドキュメント」という新しい関係が生まれます。

解決策4：チーム構造の再編

AIが実装層を担うことで、中間階層が消滅します。AIが共通言語となることで、通訳やブリッジ役を介さずにPMとTLが連携し、意思決定が即時に行えます。エンジニアは「作業者」ではなく、「構造思考者（Thinker）」へと変化します。

➡︎【資料ダウンロード】ビジネス効果最大化のために有効なAI導入ロードマップ

★AI駆動開発について詳しくはこちら

新しい開発フロー：AIと共創するチームの動き方

では、具体的にどのようにAI駆動で開発を進めればよいでしょうか。AIと共創するためのフローや従来型の開発との変化をみていきましょう。

フロー全体像

1.ビジネス要件をAIに伝える

• ・「何を」「なぜ」「どう実現するか」を自然言語でプロンプトします
• ・ドキュメントではなく“意図”を渡します

2.AIが設計・実装案を生成

• ・技術スタック・依存関係を指定してコードを出力します
• ・ファイル単位で業務文脈を保持した構造が自動生成されます

3.PMが一次レビュー・修正

• ・コードの整合性・命名・構造を確認します
• ・AIに再プロンプトを行い、対話的にリファクタリングを実施します

4.TL・エンジニアがレビュー・最適化

• ・パフォーマンス・セキュリティ・拡張性を中心に「Thinker」としてレビューします

5.AI＋TLによるテスト・品質保証

• ・テストコード・エビデンスをAIが生成します
• ・TLが最終品質を保証します

6.AIがドキュメントを同期生成

• ・API仕様書、ER図、Mermaidフローを自動生成します
• ・コードとドキュメントの乖離が発生しません

作業順序設計の重要性

AI駆動開発では、作業順序（依存関係の理解と構築順）が非常に重要になります。AIが即時にコードを生成できるため、チケット整備や作業分解の工数は最小化されますが、逆に順序を誤ると依存関係の衝突・コンフリクト・テスト破綻を引き起こします。
そのためPM、TLは、チケット作成を最小限に留めつつも、「作業の順序設計」には時間をしっかり割く必要があります。
これは、従来の「進捗管理」の時間が「構造設計」の時間に置き換わったとも言えます。

作業・進捗管理の変化

AI駆動開発では、コードとAIのプロンプトログそのものが進捗レポートになります。

• ・チケットは「やること」ではなく「やったこと」を記録するログへと変化
• ・GitコミットやAIログがリアルタイムに可視化
• ・日報やステータス会議が不要

結果、私のプロジェクトでは、管理コストは約70〜80%削減されました。「管理のための管理」から解放され、PMとTLは思考と構造に集中できるようになります。

チーム体制の変化：PMとTLの「ペア」モデルへ

AI駆動開発において、これまでの階層構造である、PMの下にTL、その下に複数のエンジニアという体制は、もはや過去のものです。

AIが実装を担う今、チーム構造は以下のように変わります。

• ・小規模ではPM×TLの2名体制で完結
• ・大規模でもEpic単位でPM×TLのペアを並列展開可能
• ・エンジニアは補助的・専門的レビュー担当

これにより、スケールしながらも軽量な組織構造が成立します。役割の再定義を行うと以下のようになります。

➡︎【資料ダウンロード】ビジネス効果最大化のために有効なAI導入ロードマップ

成功の鍵：プロジェクト辞書（PJ辞書）の整備

AI駆動開発を進めるうえで、PJ辞書（Project Dictionary）の存在は絶対条件となります。
AIは最初に与えられた命名や構造を“前提知識”として連鎖的に生成を進めるため、一度誤った定義で走り出すと、後戻りが極めて困難になります。

辞書を整備しない場合のリスク

辞書を整備しない場合のリスクはたとえば以下のような内容が挙げられます。

PJ辞書がもたらす効果

PJ辞書の効果はAIに対してはもちろん、チームメンバー間の共通言語としても重要です。

• ・命名・構造・用語の統一性
• ・再生成時の安定性
• ・属人性の排除とレビュー効率向上

PMに求められる「辞書設計力」

PJ辞書を設計することは、AIの思考モデルを設計することです。以下の基本原則を意識し設計する必要があります。

基本原則

• ・抽象度の一貫性：業務用語と物理名を階層的に整理
• ・拡張性の確保：未来機能や新API追加を見据えて命名
• ・依存関係の明示：どの定義がどのモジュールに関与するか可視化
• ・更新ルールの明示：辞書更新フロー・責任者を定義

辞書設計に「余白」を残す考え方

PJ辞書には「正確さ」だけでなく「余白」が必要です。余白を持たない設計は、AIと人間の柔軟性を奪います。
未来における変化（新機能の追加、ユースケースの多様化、ビジネスの転換）、これらに対応するためには、余白を残す設計力が不可欠です。この「余白の設計」は、単なる技術設計ではなく、プロダクトの未来像やビジネスの方向性と真摯に向き合う行為です。
余白とは、未来を受け入れるための設計であり、それを描くのが、PMという職能の本質だと私は考えます。

➡︎【資料ダウンロード】ビジネス効果最大化のために有効なAI導入ロードマップ

AIにビジネスロジックを「インストール」する

AIをチームの一員として機能させるためには、AI自身が業務構造を「理解」している必要があります。私はAIにMermaid形式でユーザーフローやデータフローを描かせ、ロジック関係をAI自身に整理させています。
これにより、AIも人も同じ構造・同じ世界観で会話できるようになり、“仕様伝達”が不要になります。

新しいPM像：「思考の設計者」へ

AI駆動開発によって、PMの役割は根本から変わりました。もはや進行管理者ではなく、思考を設計し、AIと共にプロダクトを創る存在へと変わります。

新しいPMの3つの軸

1. 1.Architect（構造設計者）
   • ・技術構造・業務構造・情報構造を横断的に設計します
   • ・コードを理解し、AIに構造を“教える”役割を担います
2. 2.Translator（翻訳者）
   • ・ビジネス意図をAIが理解できる形式に翻訳します
   • ・自然言語と技術言語の橋渡しをします
3. 3.Visionary（未来設計者）
   • ・現在の要件だけでなく、プロダクトの未来像・ビジネスの進化方向まで見据えて設計を行います

PMの役割は「伝える」から「描く」へ

従来のPMは「要件を伝える人」でした。ですが、AI時代のPMは、「意図と未来を描く人」へと進化します。AIと対話しながら構造を設計するPMは、もはやマネージャーではなく、思考のデザイナーです。

➡︎【資料ダウンロード】ビジネス効果最大化のために有効なAI導入ロードマップ

おわりに：AIが再定義する、開発とチームの未来

オフショア開発は長年、「言語」「距離」「文化」「時差」という壁に支配されてきました。
しかし、AI駆動開発は、それらを単に“乗り越える”のではなく、構造ごと書き換えました。AIがコードを生成し、PMが意図を与え、TLが構造を整える。この三位一体のモデルでは、国境も階層も意味を持ちません。AIは“認識を同期させる装置”であり、開発という営みを再定義する存在となったのです。

執筆後記

AIがコードを書き、PMがレビューし、TLが導く。その構造の中で、チームは“指示のための開発”から“思考のための開発”へと変わりました。私は、AI駆動開発とは、「考えるチームを創る技術」だと考えます。