オフショア開発の進め方【2026年版】｜7工程の手順と発注側の作業、契約・ブリッジSE配置・立ち上げ90日のゲート・運用移管まで

「オフショア開発をやると決めたが、準備リストは出てきても、走り出した後に何をどの頻度で回せばよいかが分からない」「発注側の工数がどこで増えるのか、社内の人をどれだけ空ければよいのか」「初回の発注で失敗したくない。引き返せる形で始めたい」——来期の開発体制を段取りする担当者から、こうした相談を受けることが増えました。進め方の記事は多いのに、契約後の空白を埋めるものは少ないのが実情です。

先にお伝えしたいのは、オフショア開発の進め方で失敗するのは工程の抜けではなく、順序の入れ替わりからだということです。ベンダーを探す前に「作らない範囲」と「受け入れ基準」を書き、社内の意思決定者と窓口を一本化し、ブリッジSEをどこに置くかを決める。契約後はいきなり本開発ではなく2〜4週の有償トライアルで測り、立ち上げ90日にゲートを置いて撤退できる設計にする。この順序を守れば、初回の発注でも引き返せなくなる事態を避けられます。

オフショアでは開発費が下がる代わりに、企画・立ち上げ・検収の3工程で発注側の工数が増えます。どこで増えるかを先に知って社内の人日を確保し、日々の管理を日本人PMやブリッジSEを含む体制に寄せれば、削減分が社内の残業で消える失敗は防げます。

私は人材業界の出身で、2018年からベトナム・ホーチミンで約100社の開発体制を支援してきました。その立場から本記事では、進め方を7工程の全体像、発注前に整える3つの準備、契約と体制設計(契約形態・条項・ブリッジSEの配置)、立ち上げ90日の運用リズム(トライアル・会議体・ゲート・時差のルール)、品質・コスト管理と出口設計、そして当社の進め方の順で、時系列で追える形に整理します。

読み終えるころには、工程表とチェックリストをそのまま社内の段取りに落とし、「誰が・いつまでに・何を」を決められる状態になっているはずです。まずは、7工程の全体像から確認していきましょう。

オフショア開発の進め方——7工程の全体像と、発注側の作業が集中する3つの工程

まず全体像を押さえます。ここを飛ばして個別の作業から入ると、後半の工程で必要になる決めごとを前半で取りこぼし、手戻りが発生します。この章では、企画から運用移管までを7つの工程に分け、各工程で発注側が引き受ける作業と完了条件、そして発注側の工数が国内より増える3つの工程を示します。期間の目安は、当社が相談を受ける案件でよく見られる一般的な値です。

7工程の表: 企画と範囲決め→委託先の選定→契約と体制設計→トライアル→本開発の立ち上げ→開発と検収→運用移管(期間の目安・発注側の作業・完了条件)

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

発注側の工数が増える3つの工程——企画(仕様の言語化)、立ち上げ(質問対応)、検収(受け入れテスト)

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

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

この3工程の増分を織り込まずに単価だけで比較すると、総額の見立てを外します。工程1の前に「社内に何人日を空けられるか」を確認してください。空けられないなら、日々の管理を日本人PMやブリッジSEを含む体制に寄せるか、委託範囲を小さくするかを先に決めます。費用の総額の見方はオフショア開発のメリット・デメリットで整理しています。

失敗は工程の抜けではなく順序の入れ替わりから——先に決める3つ

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

この3つを工程1〜3で決め、工程4のトライアルと工程5の90日にゲートを置く。以降の章では、この順に各工程の中身を見ていきます。次章はまず、発注前に整える3つの準備からです。

工程1〜2 発注前に整える3つの準備——判定可能な仕様書と作らない範囲、意思決定者と窓口の一本化、品質基準と受け入れテスト

失敗する案件の多くは、ベンダー選定の失敗ではなく発注者側の準備不足が原因です。この章では、工程1〜2で整える3つの準備を示します。工程1〜3で決めたことがその後の全工程を規定するので、ここでの手抜きは後半で必ず利息付きで返ってきます。

仕様書は細かさではなく「判定可能性」で書く——受け入れ基準と同じ文にし、作らない範囲を明記する

仕様書をどこまで細かく書くべきかという問いには、粒度ではなく判定可能性で答えるのが実務的です。書かれた一文を読んで、成果物がそれを満たしているかを第三者が判定できるなら粒度は足りています。判定できないなら、どれだけ長く書いても足りません。「使いやすい画面」は判定できないので、1画面あたりの入力項目の上限と必須項目の示し方を、自社の業務にあわせて数で決めて書きます。「速く動くこと」は、想定する件数と描画が終わるまでの秒数を入れた文に、「一般的なセキュリティ対策」は対策の名前を列挙する形に開きます。数字は他社の目安を借りるのではなく、自社の業務量と利用環境から決めてください。

この置き換えを進めると、仕様書の文がそのまま受け入れ基準の文になっていることに気づくはずです。仕様と受け入れ基準を別の文書として順番に作るのではなく、同じ文を両方の役割で使う書き方に変えると、工程6での認識差がほとんど消えます。準備すべきドキュメントは、要件定義書(何を・誰が使うか・どうなれば完成か)、機能仕様書(入力・処理・出力)、UI/UXのワイヤーフレーム、用語集の4つです。

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

社内の意思決定者と窓口を一本化し、責任分界(単体・結合・受け入れ)を決める

海外側のチームが止まる原因の上位に、決裁待ちがあります。時差があるぶん、1回の待ちが1営業日を消費するためです。工程ごとの最終意思決定者を名前で決め、その人が不在のときの代理も決めておきます。窓口は一本化してください。社内の複数部署が直接海外側に要望を投げる形にすると、優先順位の判断が先方に委ねられ、誰の依頼から手を付けるかで揉めます。窓口を1人に絞り、社内の要望はいったんその人に集約してから流せば、優先順位の決定権は発注側のままです。この窓口担当が、次章で述べるブリッジSEの相手役になります。

責任分界はテスト工程で特に効きます。単体テストは開発側、結合テストは共同、受け入れテストは発注側、といった線引きを契約書か体制図に書いておきます。書かれていない場合、結合テストの不具合が出たときに「仕様の理解違いか、実装の誤りか」で議論が始まり、その間は誰も直しません。中小企業で初めて担当する場合、PMが開発実務も兼任することが多いので、管理に割く時間を確保できるよう業務量を事前に調整してください。

品質基準と受け入れテストを発注前に定義する(機能・非機能・バグの重大度)

「品質が低い」という問題の多くは、何が合格品質かを事前に定義していないことが原因です。機能テストの合格基準(各機能の期待動作と合否判定の方法)、非機能要件(レスポンスタイムなどの性能目標・セキュリティ要件)、バグ管理の基準(クリティカル・メジャー・マイナーの重大度分類と対応期限)の3つを定義しておけば、納品後に「使えないものが届いた」という事態を防げます。加えて、開発途中でも中間チェックポイント(マイルストーンレビュー)を設定しておくと、受け入れ直前で初めて開けて全部ダメ、という最悪の形を避けられます。品質を工程で担保する見極め方はオフショア開発の品質をご覧ください。

私が受ける「3か月目に仕様のずれが噴き出した」相談——受け入れ基準を後回しにした結果

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制を支援してきました。相談で多いのは「契約してすぐ本開発に入り、3か月目に仕様のずれが一気に噴き出した」というケースです。話を聞くと、仕様書は用意していたのに「何をもって完了とするか」を後回しにしており、検収の場で初めて基準を作ることになっていました。仕様と受け入れ基準を同じ文で書き、作らない範囲を先に決める。この2つを飛ばすことが失敗のもとです。

工程3 契約と体制設計——請負型とラボ型、押さえる条項、ブリッジSEの4つの仕事と配置3パターン

準備が整ったら契約と体制設計です。この章では、契約形態の選び方、契約書で押さえる条項のチェックリスト、そして進め方の成否を実質的に決めるブリッジSEの仕事と配置パターンを整理します。役割の説明はどこにでもありますが、どこに何人置くかという配置の話はあまり書かれていません。

契約形態の選び方: 要件が明確なら請負、変動するならラボ型。初回は小さな請負PoC→ラボ型のスモールスタート

契約形態は大きく2つです。請負型は成果物の完成を約束する契約で費用は固定、要件が明確で変更が少ない案件に向きますが、仕様変更があると追加費用が発生しやすい。ラボ型(準委任)は専属チームの稼働時間を確保する契約で、要件が変動しやすい案件やアジャイル開発に向きますが、コスト上限の管理は発注側の関与が要ります。開発方式(ウォーターフォールかアジャイルか)も契約形態と合わせて決めます。

初めての発注では、スコープを絞った小規模な請負でPoC(概念実証)を行って信頼関係を築いてからラボ型に移行するか、ラボ型で1〜2名から始めるスモールスタートが安全です。要件が動く案件を請負で始めると、変更のたびに追加見積もりで止まります。ラボ型の仕組みはラボ型開発とはで詳しく解説しています。

契約で押さえる条項(チェックリスト): 準拠法・紛争解決・正本言語、NDA(再委託先への承継・漏洩時の通知)、知財の帰属、人員交代と引き継ぎ

海外ベンダーが用意した雛形には、相手国の法律を準拠法とする条項が含まれることがあります。トラブル時に相手国の弁護士を探して現地の手続きで対応する事態を避けるため、次の項目を契約前に確認してください。

• 準拠法が「日本法」と明記されているか(拒否される場合は、シンガポールなど中立的な仲裁機関を指定する交渉も)
• 紛争解決機関・管轄裁判所が日本または中立的な仲裁機関か。契約書の正本言語が明確か
• NDA(秘密保持契約): 機密情報の定義、利用目的の制限、保管方法、有効期間、違反時の損害賠償に加え、再委託先にも同等の義務を承継させる条項と、漏洩・不正アクセス時の通知期限・内容
• 知的財産権: 「本プロジェクトで作成された全成果物の著作権は発注者に帰属する」の明記、OSSや外部ライブラリの利用条件、ベンダー持ち込みの独自フレームワークの扱い
• 再委託の有無と事前承認。誰が実際にコードを書くかを把握する
• 主要メンバーの無断交代の禁止と、交代時の引き継ぎ期間の義務化
• 解約の予告期間とソースコード・資料の引き渡し条件

当社は日本国内の法人と日本法準拠で契約し、海外送金も不要なので、準拠法と紛争解決の論点は発生しません。

ブリッジSEの4つの仕事(仕様の補完・優先順位の翻訳・品質の一次判定・工程の警報)と、通訳との違い

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

この4つのうち、通訳や事務的な窓口で代替できるのは第二の一部だけです。残りは開発の実務経験がないと成立しません。ブリッジSEを名乗る担当者が付いたときは、日本語の水準ではなく、要件定義や設計レビューの経験があるかを確認してください。丸投げするとブリッジSEが「仕様の再定義者」になって工数が膨らむので、発注側も技術判断ができる窓口を置くか、日本人PMを含む体制を選びます。見極め方はブリッジSEとはをご覧ください。

配置3パターン(表): 先方常駐・自社側・両建て。体制規模(〜5名・5〜15名・15名〜)で選ぶ

選び分けの基準は体制規模です。海外側が5名前後までなら先方常駐の1名で足り、発注側は窓口担当を1人立てるだけです。5〜15名になると優先順位の判断が現地に寄りすぎるため、自社側にも技術が分かる担当者を半日単位で確保します。15名を超える体制や複数チームが並行する案件では両建てが現実的です。オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)ではベトナムのブリッジSEの人月単価は59万円前後、PMは71万円前後で、実装者より高いため、管理系の単価を体制全体でどこまで飲めるかで判断します。当社の場合、ブリッジSE・日本人PMをフロントに置くパターンAと、社内にPMがいる会社向けのエンジニアのみのパターンBを選べ、ブリッジSEは3,000USD(約45万円、1USD=150円換算目安)で公開しています。

契約形態・条項・ブリッジSEの配置が決まれば、体制設計は完了です。では、契約してすぐ本開発に入ってよいのでしょうか。次章で立ち上げ90日の設計を示します。

工程4〜5 立ち上げ90日の運用リズム——有償トライアルの3指標、会議体3層と非同期中心の運用、30/60/90日のゲート、時差とツールのルール

契約して人を集めれば動き出す、とはなりません。立ち上げの3か月は、開発そのものと並行して進め方を作り込む期間として設計します。この章では、最初の2〜4週の有償トライアルで測る指標、会議体と非同期の比率、30/60/90日のゲート、時差とツールのルールを整理します。

最初の2〜4週は有償トライアル——見積り精度・質問の往復速度・成果物の粒度の3指標と合否の線引き

本開発の前に、2週間〜1か月の有償トライアルを挟むことをお勧めします。無償の技術検証ではなく有償にするのは、実際の契約条件と同じ緊張感で測るためです。対象は本番システムの一部でよく、1〜2機能で足ります。測る指標は3つです。第一に見積り精度で、開始時に提示された工数と実績の差を見ます。差が2割以内なら本開発の見積もりも信用でき、5割を超えるなら前提が共有できていません。第二に質問の往復速度で、発注側が回答してから成果物に反映されるまでの時間を測ります。時差2時間のベトナムなら翌営業日中の反映が目安です。第三に成果物の粒度で、コードとドキュメントが指定した基準を満たしているかを確認します。

3つのうち2つが基準を割った場合は、本開発の契約前に体制の入れ替えを打診してください。この段階なら損失は1か月分に収まります。走り出した後に同じ判断をすると、引き継ぎの費用が数か月分乗ります。当社では契約前にお客様と候補者が面談する工程を標準にしており、トライアルの前段で人を確かめられます。

会議体は3層(日次・週次・月次)、決めごとの大半は非同期。ツールは「必ずチケット化・期限はISO形式」

時差があるため、全部を会議で解決しようとすると、双方の勤務時間が重なる数時間に予定が集中して身動きが取れません。決めごとは原則として非同期の文書とチケットで処理し、会議は同期でなければ決まらないものに絞ります。会議体は3層に整理すると回ります。日次は短時間の進捗確認で、止まっている作業と待ちの解消だけが対象。週次は仕様確認の場で、翌週着手分の認識合わせ。月次は体制と工程を見直し、遅れの傾向と人員の増減を議論する場です。議題は「前回からの進捗・課題・次回までのアクション・リスク」の4項目で固定し、議事録は共有ドキュメントに蓄積します。

ツールはBacklog・Jira・GitHub Issuesなどを使い、タスクは必ずチケット化する(口頭・チャットのみのやり取りは禁止)、期限はISO形式(YYYY-MM-DD)で統一する(「来週中に」は使わない)、バグ報告は再現手順・期待動作・実際の動作をセットで書く、ステータスは業務開始時と終了時に更新する、の4ルールを決めます。

30日・60日・90日のゲート条件(表)と、割ったときの組み替え

ゲートの通過条件は契約前に文書化し、割ったときに何をするかまで書いておくと、実際にその場面が来たときに感情の議論になりません。この設計を先に入れておけば、走り出してから引き返せなくなる事態を避けられます。

時差のルール——午前中に連絡、回答期限の明文化、祝日とテトを共有カレンダーに

ベトナムとの時差は2時間(日本が先行)で、現地の8〜17時は日本の10〜19時に当たります。日本の9時に連絡しても現地は7時なので、応答は10〜11時になります。このラグを前提に、回答を求める連絡は日本時間の午前中に送る、緊急でない課題についても回答の期限を決めて明文化する、緊急時の連絡ルート(チャットの緊急チャンネルなど)を事前に決める、日本と現地の祝日を共有カレンダーで管理する、の4つをルールにします。ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)と少なめですが、旧正月のテト(2026年は2月14〜22日)は1週間以上の連休になるため、2月の検収はテト前に終えるか3月に設定してください。詳しくはベトナムと日本の時差ベトナムの祝日で整理しています。

トライアルで測り、3層の会議体と非同期で回し、3つのゲートで判断する。これが立ち上げ90日の設計。

工程6〜7 品質・コスト管理と出口設計、当社の進め方——遅延のメカニズム、エスカレーションと撤退基準、検収の完了条件3階層、運用移管

進め方の解説はたいてい検収で終わりますが、実務ではその先に運用が続きます。この章では、開発中の品質・コスト管理(遅延の仕組み・中間レビュー・エスカレーションと撤退の基準)、検収の完了条件、運用移管の進め方を整理し、最後に当社の進め方をお伝えします。

納期遅延のメカニズム(確認待ち→待機→スライド)と、中間レビューの置き方、エスカレーション基準・撤退基準

納期遅延は突然起こるのではなく、少しずつ積み重なって発生します。仕様の曖昧な箇所が確認待ちになる、日本側の確認に時間がかかる、開発チームが待機状態になりスケジュールがスライドする、仕様変更で完成した機能をやり直す、という流れです。防止策は、マイルストーンを週単位で細かく設定する、確認依頼に対するレスポンスの期限をあらかじめ決めておく、仕様変更は変更管理プロセス(変更要求の起票・承認・スケジュール影響の評価)を経てから反映する、各マイルストーンで進捗率(完了タスク/全タスク)を実測する、の4つです。品質面では、ブリッジSEによる一次レビューをスプリント単位で行い、工程の途中に複数回デモのレビューを置き、自動テストを開発フローに組み込みます。受け入れ直前で初めて開けるのが最大のリスクで、中間レビューが最も効くリスクヘッジです。

エスカレーション基準は事前に決めておきます。マイルストーン達成率が計画の80%を下回った、同じバグが3回以上再発した、理由不明の遅延が2週間以上続いた、残作業があるのにコスト実績が予算の90%を超えた、のいずれかで早期に対処します。撤退の検討基準は、仕様変更・追加工数・修正を含めた総コストが当初見積もりの1.5倍を超えた、品質やセキュリティの重大な問題が繰り返す、コミュニケーションが実質的に機能していない、の3つで、「続けた場合の追加コスト」と「撤退して別の会社か国内に切り替えた場合のコスト」を比べて判断します。失敗の兆候と立て直しはオフショア開発の失敗パターンで整理しています。

検収の完了条件は3階層(機能・非機能・引き渡し物)、運用移管は1〜3か月の並行期間と設計判断の記録

受け入れテストで揉める原因は、完了条件が発注前に決まっていないことです。仕様書の各文を判定可能な形にしておけば、テスト項目はそこから機械的に作れます。完了条件は3階層に分けると運びやすくなります。第一階層が機能の充足(仕様書の各文に対応する項目)、第二階層が非機能の充足(応答時間や同時接続数のように数値で書いた条件)、第三階層が引き渡し物の充足(設計書・テスト結果・環境構築手順・権限の一覧)です。第三階層を検収条件に入れておかないと、動くシステムだけが残り、資料は「後で送ります」のまま契約が終わります。

運用移管は資料を受け取って終わりではありません。社内の担当者が障害対応を単独でこなせる状態になるまで、1〜3か月の並行期間が要ります。この期間は海外側に稼働を残し、発生した障害の一次対応を自社側が担い、詰まったところだけを聞く形にします。移管の対象はコードと設計書だけでなく、なぜこの構成を選んだのかという判断の背景も含めます。設計判断の記録を成果物として要求しておくと、次の改修で同じ検討をやり直さずに済みます。その後、委託を続けるか、社内で回すか、国内に戻すかは、改修の頻度・要件が動く度合い・データの機微度の3つで判断します。

当社の進め方——打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始で最短2週間、パターンA/B、1か月単位の増減、日本国内契約

当社(TALENTBASE VIETNAM)の進め方は、上の7工程のうち工程2〜4を短縮する形になっています。打ち合わせで要件と体制を確認し、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から候補をアサイン(約1週間)、お客様と候補者が面談(約1週間)、開発開始という流れで、最短2週間で始められます。1名から契約でき、増員は約1週間、交代・縮小は1か月単位なので、トライアル的に小さく始めて90日で拡張を判断する進め方がそのまま組めます。

体制は、日本人PMまたはブリッジSEをフロントに置くパターンA(推奨)と、社内にPMがいる会社向けのエンジニアのみのパターンBです。パターンAでは、ブリッジSEの4つの仕事(仕様の補完・優先順位の翻訳・品質の一次判定・工程の警報)を当社側が担い、日本人PMの設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを工程に組み込むため、発注側は週1回の定例で優先順位を決めることに集中できます。第1章で述べた「発注側の工数が増える3工程」を体制で吸収する形です。契約と支払いは日本国内の法人と日本法準拠で、生成AIとAIコーディング支援を標準で使うAI活用開発体制で進めます。介護記録SaaS「CareViewer」は日本語BrSE1名+エンジニア2名で要件定義から保守運用まで一貫して支援し、FinTechのマッチングアプリは要件が固まる前の構想段階からPMが参画しました。事例の詳細はオフショア開発の事例でご覧いただけます。

現在の体制と要件をお聞かせいただければ、7工程のどこから始めるべきか、どの体制でいくらから始められるかを、概算見積もりでお答えします。

オフショア開発の進め方でよくある質問

オフショア開発の進め方について、発注前後に繰り返し聞かれる5つの質問に短く答えます。社内の段取りを組む際の確認事項としてお使いください。

Q1. 最初にやるべきことは何ですか

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

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

細かさではなく、判定できるかどうかで決めてください。書かれた一文を読んで、成果物がそれを満たしているかを第三者が判定できれば十分です。「使いやすい画面」ではなく「1画面あたりの入力項目の上限」を数で示し、「速く動くこと」ではなく「何件のデータを何秒以内に描画するか」を書きます。この書き方にすると、仕様書の文がそのまま受け入れテストの項目になります。

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

体制規模で決まります。海外側が5名前後までなら委託先の常駐ブリッジSE1名と自社の窓口担当1人で回ります。5〜15名になると自社側にも技術が分かる担当者を確保し、15名超や複数チーム並行では両方に置く構成が現実的です。社内に技術判断ができる人がいない場合は、日本人PMがフロントに立つ体制を選んでください。

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

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

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

資料を受け取るだけでは手が動く状態になりません。社内の担当者が単独で障害対応をこなせるまで、1〜3か月の並行期間を置き、一次対応を自社が担って詰まったところだけを聞く運用にします。設計判断の背景を記録として要求しておくと、次の改修でやり直しが減ります。社内で回せない場合は、当社のように保守運用まで含めて継続できる体制を選ぶのが現実的な出口。

まとめ: 進め方は7工程——先に決める3つと90日のゲートで、引き返せる設計にする

オフショア開発の進め方は、企画と範囲決め(2週間〜1か月)→委託先の選定(1〜2か月)→契約と体制設計(2週間〜1か月)→トライアル(2週間〜1か月)→本開発の立ち上げ(1か月)→開発と検収→運用移管(1〜3か月)の7工程です。発注側の工数は企画(仕様の言語化)・立ち上げ(質問対応)・検収(受け入れテスト)の3工程で増えるので、社内の人日を先に確保するか、日本人PMやブリッジSEを含む体制に寄せてください。

失敗は工程の抜けではなく順序の入れ替わりから起きます。先に決めるのは、仕様書を判定可能な文で書いて受け入れ基準と同じ文にし作らない範囲を明記すること、社内の意思決定者と窓口を一本化して責任分界(単体・結合・受け入れ)を決めること、ブリッジSEを先方・自社側・両建てのどこに置くかを体制規模(〜5名・5〜15名・15名〜)で決めることの3つです。契約では準拠法・紛争解決・NDA(再委託先への承継)・知財の帰属・人員交代と引き継ぎを確認し、契約後はいきなり本開発ではなく2〜4週の有償トライアルで見積り精度・往復速度・成果物の粒度を測ります。立ち上げは日次・週次・月次の会議体と非同期中心の運用で回し、30日(質問の滞留ゼロ)・60日(1回で通る比率5割)・90日(工数が想定の1.5倍以内)のゲートで続ける・組み替えるを判断します。検収の完了条件は機能・非機能・引き渡し物の3階層で決め、運用移管には1〜3か月の並行期間と設計判断の記録を含めてください。

当社は、打ち合わせ→人財データベースからのアサイン(約1週間)→候補者面談(約1週間)→開始の流れで最短2週間、1名から始めて1か月単位で増減でき、日本人PMをフロントに置くパターンAで発注側の工数増を体制で吸収します。会社の選び方はオフショア開発会社の選び方、ブリッジSEの見極め方はブリッジSEとはもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、7工程のどこから始めるべきかと概算見積もりでお答えします。