単価表を並べて比較している方へ
オフショア開発の検討で、各社の単価表を横に並べている段階の方に向けて書いています。
その比較は必要ですが、AIが実装工程に入った今、単価差で決まる部分は年々小さくなっています。代わりに効いてくるのが、曖昧な要件をどこで止めるかです。
実装が速くなると、要件の曖昧さも速く流れます
AIとオフショア開発チームを組み合わせると、実装速度は上がります。問題は、上がるのが実装速度だけだということです。
何を作るか、どの品質で受け入れるかを人が整理する速度は変わりません。ここが詰まっていないまま実装だけが速くなると、「言われたとおりに作ったが、欲しかったものと違う」成果物が、以前より速く、より多く出てきます。
日本側PMは、経営者や現場の意図を開発タスクへ翻訳し、レビューと受入の基準を明確にする役割を担います。旧来のブリッジSEの役割に近い部分もありますが、AI活用が前提になると、確認記録とタスク分解の重要性がさらに上がります。
上流で止めるほうが、あとで安くつきます
これは感覚論ではなく、公開データがあります。
IPAが実プロジェクトのデータを分析した資料では、上流工程での不具合摘出比率（設計レビューで摘出する不具合件数が、基本設計から総合テストまでで摘出する件数に占める割合）の目標を、目安として85%程度に高めて設定することを挙げています。同資料では、設計レビューの指摘密度が高いプロジェクトのほうが、この比率が中央値で約1.6倍高い傾向も示されています（IPA 設計レビュー・要件定義強化のススメ）。
要件の合意についても、IPAの「機能要件の合意形成ガイド」が、発注者と開発者の合意形成が不充分だと下流工程で手戻りが発生すると整理しています。
距離と言語をまたぐオフショアでは、この手戻りの検知が国内案件より遅れます。だから上流の比重は、AI以前から相対的に高いままです。
日本側PMが渡すもの
日本側PMは、開発者へ依頼する前に、目的、画面、データ、制約、優先順位、確認方法を日本語で整理します。AIで作った仕様案も、そのまま渡すのではなく、業務の前提に合っているか確認します。
実装を依頼する前に渡す6点
- 目的: この機能で何が変わるか。使う人は誰か
- 優先順位: 全部できないとき、どれを落としてよいか
- 制約: 使えないデータ、触れないシステム、守る規程
- 正解の例: 代表的な入力と、期待する出力を最低3組
- 例外時の扱い: 入力が不正・データがない・外部が落ちているとき、どう振る舞うか
- 確認方法: 誰が、何を見て、受け入れたと判断するか
依頼テンプレートとして使えます。「正解の例」が書けない機能は、まだ実装を依頼できる段階にありません
4番目でつまずくことが多いはずです。書けないのは準備不足ではなく、その機能の仕様がまだ決まっていないというサインです。
契約形態の議論は、体制設計に集約されます
オフショア開発では、ラボ型か受託か、ブリッジSEを置くか、どの会社へ依頼するかといった論点が語られてきました。AI活用が前提になると、これらは切り離した議論ではなく、開発体制をどう設計するかという一つの問いにまとまります。
契約形態や担当者の呼び方が変わっても、要件整理、タスク化、レビュー、受入、改善記録という実務は変わりません。体制を選ぶときは、この実務を誰がどう担うかを先に確認します。工数課金から成果対価へ移す場合の論点は工数課金から成果対価へ移る契約設計で扱っています。
安さだけで選ばない
オフショア開発は、単価だけで判断すると、手戻りや確認不足で総コストが上がることがあります。
AI活用型の開発では、実装の速さと同じくらい、レビュー、テスト、変更記録の運用が重要になります。安く作ることよりも、作ったものを直し続けられる体制があるかを見ます。価格の見方そのものは安いAI受託開発に飛びつく前にで整理しています。
AIをチームの補助として使う
AIは、仕様の分解、コードの下書き、テスト観点、ドキュメント更新、レビューコメントの整理に使えます。日本側PMと開発チームが同じ記録を見られる状態にすると、AIの出力も確認しやすくなります。
ただし、AIの提案は常に正しいわけではありません。OWASPのLLM09:2025 Misinformationは、もっともらしく見える誤った出力や安全でないコードの提案をリスクとして挙げ、対策に人によるクロスチェックと監督を含めています。仕様、セキュリティ、権限、運用手順、顧客への説明は、人が確認します。具体的なレビュー観点はAIが作ったコードを人がレビューする理由にまとめています。
継続できる体制に必要な記録
継続開発では、誰が作ったかよりも、なぜそうしたか、何を確認したかが重要になります。チケット、Pull Request、レビュー記録、テスト結果、リリースメモを残すことで、次の変更がしやすくなります。
外注ではなく、体制の設計です
AI時代のオフショア開発は、単なる外注ではなく、日本側PM、ベトナム開発チーム、AIを含めた開発体制の設計です。
進め方の全体像はAIネイティブ開発、AI時代に受託が何を売るのかという論点はAI時代の受託開発で何を売るかで扱っています。
体制の作り方から相談したい場合は、お問い合わせからお聞かせください。いまの要件がどこまで固まっているかを確認するところから始めます。