オフショア開発の進め方は？7工程の手順とブリッジSE配置を発注者視点で解説

オフショア開発を始めると決めた後、実際に手を動かす順番を調べると、出てくるのは発注前の準備リストばかりです。ベンダーを選び、契約を結び、キックオフをする。そこまでは書かれているのに、走り出した後に何をどの頻度で回せばいいのかは空白のまま残ります。実務でつまずくのは、たいていその空白の部分でしょう。この記事では、企画から運用移管までを7つの工程に分け、発注側の作業がどこに集中するのかを示したうえで、ブリッジSEの配置パターン、立ち上げ90日のゲート設計、検収後の出口設計まで、時系列で追える形に整理します。

まとめ：オフショア開発の進め方で先に決める3つと90日で見る判断

進め方の失敗は、工程の抜けではなく順序の入れ替わりから起きます。先に決めておくものは3つです。1つめは、仕様書の粒度と受け入れ基準をセットで書くこと。何を作るかだけを渡して、何をもって完了とするかを後回しにすると、検収の場で認識差が全部まとめて噴き出します。2つめは、社内の意思決定者と窓口を一本化すること。海外側から見て「誰に聞けば決まるのか」が曖昧な体制では、質問が滞留して工程が止まります。3つめが、ブリッジSEを先方に置くのか自社側に置くのかを、体制規模から決めておくことです。

そのうえで、立ち上げの90日を評価期間として設計します。最初の2週間から4週間は有償のトライアルに充て、見積り精度・質問の往復速度・成果物の粒度という3つの指標を測ります。30日で開発リズムが立ち上がったか、60日で品質基準に乗ったか、90日で発注側の工数が想定内に収まったかを順に確認し、いずれかで基準を割ったら体制を組み替える。この設計を先に入れておけば、走り出してから引き返せなくなる事態を避けられます。以降では、7つの工程の中身と、各工程で発注側が実際に負う作業を順に見ていきます。

オフショア開発の進め方を7つの工程に分けた全体像と発注側の作業が集中する場所

まず全体像を押さえます。ここを飛ばして個別の作業から入ると、後半の工程で必要になる決めごとを前半で取りこぼし、手戻りが発生します。

企画から運用移管までの7工程と各工程で発注側が引き受ける作業

オフショア開発の進め方は、大きく7つの工程に分かれます。それぞれの工程で、発注側が自分で手を動かす作業は次のように整理できます。

この並びで注目してほしいのは、工程4のトライアルです。多くの進め方の解説では、契約の次はいきなり本開発に入ります。ただ、初回の委託先と初回のチームで、いきなり本番の規模を任せるのは過大な判断です。小さく発注して測る工程を挟むかどうかで、後の3工程の難易度が変わってきます。委託先そのものの比較軸についてはオフショア開発会社の選び方とチェック項目をまとめた記事で扱っているため、工程2の詳細はそちらをご覧ください。

国内受託と比べて発注側の工数が増える3つの工程と増え方の中身

オフショア開発では、開発費が下がる代わりに発注側の作業が増えます。どこで増えるのかを事前に知っておかないと、社内の担当者が想定の倍働くことになり、削減できたはずの費用が人件費で相殺されます。増えるのは工程1、工程5、工程6の3つです。

工程1では、仕様の言語化にかかる時間が伸びます。国内の受託開発なら「いつもの業務フローで」と伝えれば通る前提が、海外側には通じません。業務の前提条件そのものを文書に起こす作業が乗り、前提を置いた推計では国内案件の1.5倍から2倍の時間がかかります。工程5は、質問への回答が集中する工程です。立ち上げ月は1日あたり数件から十数件の質問が届き、これを翌営業日まで放置すると先方の稼働が止まってしまいます。工程6では、受け入れ試験の設計と実施が発注側に寄ります。国内受託なら開発側が肩代わりしていた部分まで、自社で線を引く必要が出てくるためです。

この3工程の増分を織り込まずに単価だけで比較すると、総額の見立てを外します。国別の人月単価と国内受託との総額比較はオフショア開発の費用相場と実質単価の計算手順をまとめた記事に譲りますが、進め方の観点では「社内に何人日を空けられるか」を工程1の前に確認しておくことをおすすめします。空けられないなら、進め方を工夫しても結果は変わりません。

発注前に固める要件の粒度と社内体制の作り方・契約で先に決める条件

工程1から工程3で決めたことが、その後の全工程を規定します。ここでの手抜きは、後半で必ず利息付きで返ってきます。

仕様書の粒度をどこまで上げるかと受け入れ基準を同時に書く方法

仕様書をどこまで細かく書くべきかという問いには、粒度ではなく判定可能性で答えるのが実務的です。書かれた一文を読んで、成果物がそれを満たしているかどうかを第三者が判定できるなら、粒度は足りています。判定できないなら、どれだけ長く書いても足りません。

具体的には、次のような表現が機械的に潰す対象です。「使いやすい画面」は判定できないので「1画面あたりの入力項目は10個以内、必須項目には印を付ける」という記述に置き換える形です。「速く動くこと」は「一覧表示は1,000件のデータで3秒以内に描画される」とします。「一般的なセキュリティ対策」は、対策の名前を列挙する形に開きます。この置き換えを進めると、仕様書の文が自動的に受け入れ基準の文になっていることに気づくはずです。仕様と受け入れ基準を別の文書として順番に作るのではなく、同じ文を両方の役割で使う書き方に変えると、工程6での認識差がほとんど消えます。

もう1点、作らない範囲を明記してください。オフショア開発の見積りは提示された範囲に対して行われるため、書かれていない機能は「後で追加できる小さなもの」ではなく、追加見積りの対象になります。企画段階で「今回は対象外」と書いた項目の一覧があるだけで、途中の交渉が短くなります。

社内の意思決定者と責任分界を先に決めて窓口を一本化する体制設計

海外側のチームが止まる原因の上位に、決裁待ちがあります。時差があるぶん、1回の待ちが1営業日を消費するためです。これを防ぐには、工程ごとの最終意思決定者を名前で決め、その人が不在のときの代理も決めておきます。

窓口は一本化してください。社内の複数部署が直接海外側に要望を投げる形にすると、優先順位の判断が先方に委ねられ、誰の依頼から手を付けるかで揉めます。窓口を1人に絞り、社内の要望はいったんその人に集約してから海外側へ流せば、優先順位の決定権は発注側のままです。この窓口担当が、後述するブリッジSEの相手役になります。

責任分界は、テスト工程で特に効きます。単体テストは開発側、結合テストは共同、受け入れテストは発注側、といった線引きを契約書か体制図に書いておきます。書かれていない場合、結合テストの不具合が出たときに「仕様の理解違いか、実装の誤りか」で議論が始まり、その間は誰も直しません。失敗が起きたときの原因の切り分け方についてはオフショア開発の失敗の要因と立て直しの判断をまとめた記事で扱っています。

ブリッジSEの役割と3つの配置パターンを体制規模で選び分ける基準

進め方の成否を実質的に決めるのが、ブリッジSEの置き方です。役割の説明はどこにでもありますが、どこに何人置くのかという配置の話はあまり書かれていません。

ブリッジSEが担う4つの仕事と通訳や単なる窓口との決定的な違い

ブリッジSEは通訳ではありません。担っている仕事は4つあります。1つめは仕様の翻訳ではなく、仕様の補完です。発注側の文書に書かれていない業務前提を推測して質問を作り、抜けを埋めます。2つめは優先順位の翻訳で、複数の依頼が同時に来たときに、発注側の事情を踏まえて開発側の着手順を組み替えます。3つめが品質の一次判定です。成果物を発注側へ出す前に自分で確認し、明らかな不備を戻します。4つめが工程の警報で、遅れの兆候を発注側に早めに伝えます。

この4つのうち、通訳や事務的な窓口でも代替できるのは2つめの一部だけです。残りは開発の実務経験がないと成立しません。ブリッジSEを名乗る担当者が付いたときは、日本語の水準ではなく、要件定義や設計レビューの経験があるかを確認してください。日本語が流暢でも実装経験がない担当者が付くと、仕様の補完と品質の一次判定が機能せず、結果として発注側の工数が増えます。

先方常駐・自社側配置・両建ての比較と体制規模で選ぶときの基準

配置には3つのパターンがあります。それぞれ費用と効き方が違います。

選び分けの基準は体制規模です。海外側が5名前後までなら、先方常駐の1名で対応可能です。発注側は窓口担当を1人立てるだけで足ります。5名から15名の規模になると、先方常駐だけでは優先順位の判断が現地に寄りすぎるため、自社側にも技術がわかる担当者を半日単位で確保しておくと止まりにくくなります。15名を超える体制や、複数チームが並行する案件では両建てが現実的です。オフショア開発白書2025年版に基づく集計（2026年2月時点で公開されている数値）では、ベトナムのブリッジSEの人月単価は59万円前後、プロジェクトマネージャーは71万円前後で、実装者に比べて開きがあります。両建ての判断は、この管理系の単価を体制全体でどこまで飲めるかで決まってくるでしょう。

なお、ブリッジSEの人材層は委託先の国によって大きく変わります。日本語で仕様を回す前提なら選択肢は絞られるため、配置の設計を国選定と同時に進めるほうが手戻りの少ない進め方です。国ごとの人材の厚みと条件はオフショア開発の国の選び方と判断基準をまとめた記事で整理しています。

立ち上げ90日の運用リズムと撤退可能点を残すゲート設計の作り方

契約して人を集めれば動き出す、とはなりません。立ち上げの3カ月は、開発そのものと並行して、進め方を作り込む期間として設計します。

最初の2から4週の有償トライアルで測る3つの指標と合否の線引き

本開発の前に、2週間から1カ月の有償トライアルを挟むことをおすすめします。無償の技術検証ではなく有償にするのは、実際の契約条件と同じ緊張感で測るためです。対象は本番システムの一部でよく、規模は1機能から2機能で足ります。

測る指標は3つです。1つめは見積り精度で、トライアル開始時に提示された工数と実績の差を見ます。前提を置いた基準では、差が2割以内なら本開発の見積りも信用できます。5割を超えるなら、見積りの前提が共有できていません。2つめは質問の往復速度です。発注側が回答してから、それが成果物に反映されるまでの時間を測ります。時差2時間程度の国なら、翌営業日中の反映が目安になるでしょう。3つめが成果物の粒度で、納品されたコードとドキュメントが、こちらの指定した基準を満たしているかを確認します。

3つのうち2つが基準を割った場合は、本開発の契約を結ぶ前に体制の入れ替えを打診してください。この段階なら費用の損失は1カ月分に収まります。走り出した後に同じ判断をすると、引き継ぎの費用が数カ月分乗ってきます。

会議体と非同期の比率設計と30日60日90日で置くゲートの条件

開発期間中の運用リズムは、同期と非同期の比率で設計します。時差があるため、全部を会議で解決しようとすると、双方の勤務時間が重なる数時間に予定が集中して身動きが取れない状態です。目安として、決めごとの8割は非同期の文書とチケットで処理し、会議は残りの2割に絞ります。

会議体は3つに整理すると回ります。日次は15分の進捗確認で、止まっている作業と待ちの解消だけが対象です。週次は1時間の仕様確認で、翌週着手分の認識合わせをします。月次は体制と工程を見直し、遅れの傾向と人員の増減を議論する場です。この3層を守ると、日次で拾えなかった論点が週次に、週次で決着しなかった論点が月次に上がる流れができ、決めごとが宙に浮きにくくなります。

そのうえで、90日のあいだに3つのゲートを置きます。30日のゲートでは、週次のリズムが定着し、質問の滞留がゼロになっているかを見ます。60日のゲートは、成果物が受け入れ基準を1回で通る比率の確認です。前提を置いた基準では、この比率が5割を下回るなら、仕様の伝わり方に構造的な問題があります。90日のゲートでは、発注側の担当者が実際に使った工数を集計し、当初の想定を超えていないかを見ます。想定の1.5倍を超えていれば、費用の前提が崩れているため、範囲か体制のどちらかを組み替える段階です。ゲートの通過条件は契約前に文書化し、割ったときに何をするかまで書いておくと、実際にその場面が来たときに感情の議論になりません。

検収から運用移管と内製化までを見据えた出口設計と国内へ戻す判断

進め方の解説はたいてい検収で終わりますが、実務ではその先に運用が続きます。出口を設計しないまま検収を迎えると、作ったシステムを誰も直せない状態が残ります。

受け入れテストの責任分界と完了条件を発注の前に決めておく理由

受け入れテストでもめる原因は、テストの実施方法ではなく、完了条件が発注前に決まっていないことです。前述のとおり仕様書の各文を判定可能な形にしておけば、受け入れテストの項目はそこから機械的に作れます。逆に言えば、仕様書が判定不能なままだと、検収の場で初めて基準を作ることになり、そこから交渉が始まります。

実務では、完了条件を3階層に分けておくと運びやすくなります。1階層目が機能の充足で、仕様書の各文に対応する項目です。2階層目が非機能の充足で、応答時間や同時接続数のように数値で書いた条件です。3階層目が引き渡し物の充足で、設計書、テスト結果、環境構築手順、権限の一覧といった、運用に必要な資料が揃っているかを見ます。3階層目を検収条件に入れておかないと、動くシステムだけが残り、資料は「後で送ります」のまま契約が終わります。

ナレッジ移転の具体的な進め方と内製化や国内へ戻すときの判断基準

運用移管は、資料を受け取って終わりではありません。前提を置いた推計では、社内の担当者が障害対応を単独でこなせる状態になるまで、1カ月から3カ月の並行期間が必要です。この期間は、海外側にまだ稼働を残したうえで、発生した障害の一次対応を自社側が担い、詰まったところだけを聞く形にします。読むだけの引き継ぎでは、手が動くようにはなりません。

移管の対象は、コードと設計書だけではありません。判断の背景も移管の対象です。なぜこの構成を選んだのか、どの制約でこの実装になったのかが残っていないと、次の改修で同じ検討を最初からやり直すことになります。設計判断の記録を成果物として要求しておくと、この手戻りを減らせます。

そのうえで、体制を組み替える判断基準を持っておきます。委託を続けるか、社内で回すか、国内の受託開発へ戻すかの分岐です。判断の材料は3つで、改修の頻度、要件が動く度合い、そして扱うデータの機微度です。改修が四半期に1回以下で仕様も安定しているなら、海外側に置いたままで問題ありません。月次以上の頻度で改修が入り、要件も動き続けるなら、往復の待ち時間が費用に効いてくるため、社内か国内へ寄せるほど総額を下げられる条件です。運用の引き取りと社内で回せる状態づくりを外部と組んで進める場合は、国内で対応する保守運用と内製化支援のように、移管そのものを工程として扱う相手を選ぶと引き継ぎが早く済みます。海外委託と国内受託の使い分けの前提そのものはオフショア開発の定義とメリット・デメリットを整理した記事にまとめています。

よくある質問

オフショア開発の進め方について、発注前後によく聞かれる質問をまとめました。

オフショア開発の進め方で、最初にやるべきことは何ですか？

委託先を探すことではなく、作らない範囲を書き出すことです。オフショア開発の見積りは提示された範囲に対して行われるため、範囲が曖昧なまま選定に入ると、各社の提案が比較できない形で返ってきます。目的と対象範囲を確定し、今回は対象外とする機能を一覧にしてから、委託先の選定に進んでください。この作業に2週間から1カ月かけておくと、後の工程が短くなります。

仕様書はどこまで細かく書けばよいですか？

細かさではなく、判定できるかどうかで決めてください。書かれた一文を読んで、成果物がそれを満たしているかを第三者が判定できるなら十分です。「使いやすい画面」ではなく「1画面あたりの入力項目は10個以内」、「速く動くこと」ではなく「1,000件で3秒以内に描画」と書きます。この書き方にすると、仕様書の文がそのまま受け入れテストの項目になり、検収時の認識差がほとんど消えます。

ブリッジSEは委託先に任せればよいですか、自社にも必要ですか？

判断軸は体制規模です。海外側が5名前後までなら、委託先の常駐ブリッジSE1名と自社の窓口担当1人で回ります。5名から15名になると優先順位の判断が現地に寄りすぎるため、自社側にも技術がわかる担当者を確保しておくと止まりにくくなります。15名を超える体制や複数チームが並行する案件では、両方に置く構成が現実的です。管理系の職種は単価が高いため、体制全体の費用で判断してください。

いきなり本開発を発注しても問題ありませんか？

初回の委託先であれば、2週間から1カ月の有償トライアルを挟むのが妥当です。見積り精度、質問への反映速度、成果物の粒度という3つを測り、2つが基準を割ったら本契約の前に体制の入れ替えを打診します。この段階なら損失は1カ月分ですが、走り出した後に同じ判断をすると引き継ぎ費用が数カ月分乗ります。トライアルは有償にして、本契約と同じ条件で測ってください。

検収が終わった後、社内で運用できるようになりますか？

資料を受け取るだけでは、手が動く状態にはなりません。前提を置いた推計では、社内の担当者が単独で障害対応をこなせるまで1カ月から3カ月の並行期間が要ります。この間は海外側に稼働を残し、一次対応を自社が担って詰まったところだけを聞く運用です。あわせて、設計判断の背景を記録として要求しておくと、次の改修で同じ検討をやり直さずに済みます。

関連記事

• オフショアとニアショアの違いは？コスト・品質・納期で比較し発注先を選ぶ判断軸を解説：海外に出すか国内の地方拠点に委託するかを、進め方を設計する前段で判断したい場合の比較軸です
• ベトナムのオフショア開発は何が違う？向く案件と2026年のデータ規制を発注者視点で解説：委託先として最も選ばれている国の人材構造と稼働カレンダーを、体制設計の前提として扱っています
• ニアショア開発とは？オフショア開発との違いと国内委託が向くケースを発注者視点で解説：要件が動き続ける案件など、海外委託の進め方が噛み合わない場合の受け皿となる選択肢です