オフショア開発と国内開発を比較｜コストだけで選ぶと失敗する判断軸

システム開発の外注先を探していると、国内の開発会社に加えて、ベトナムやフィリピン、インドなど海外の開発拠点を使う「オフショア開発」の提案を受けることがあります。見積書を並べると、オフショアのほうが安く見えるケースは少なくありません。

ただ、見積額の差がそのまま最終的な支払総額の差になるとは限りません。仕様の伝達、確認、手戻りの修正にかかる手間は、見積書の外側で発注側が負担することになるからです。安さを理由に選んだ結果、社内の担当者が仕様の説明と確認に追われ、納期も延びたという話は珍しくありません。

一方で、仕様が固まっていて、発注側に設計や品質を管理できる人がいる案件なら、オフショア開発は有力な選択肢です。どちらが優れているかではなく、自社の案件と体制にどちらが合うかで判断する必要があります。

この記事では、オフショア開発と国内開発の違いを整理したうえで、見積額に表れないコスト、コスト以外の判断軸、案件の条件ごとの向き不向き、オフショアを選ぶ場合に契約前に決めておくことを、発注側の立場から解説します。

オフショア開発と国内開発はどこが違うか

オフショア開発は、開発作業の一部または全部を海外の開発拠点に委託する方式です。発注側が海外の会社と直接契約する形もありますが、中小企業の場合は、日本に窓口を持つ開発会社と契約し、その会社が海外拠点に作業を振り分ける形が一般的です。

国内開発は、日本国内の開発会社やエンジニアに委託する方式です。国内の開発会社がさらに外部の開発パートナーに一部を依頼していることもあり、発注側から見えている体制と実際に手を動かす人が一致しないのは、国内でもオフショアでも同じです。

両者の違いを、発注側の負担という観点で整理すると次のようになります。

観点	オフショア開発	国内開発
人件費の水準	拠点国の人件費水準が反映され、単価は低めになりやすい	国内の人件費水準が反映される
言語	日本語ができるブリッジSEや通訳を介することが多い	発注側と開発者が日本語で直接話せる
仕様の伝え方	文書で明確に伝える必要があり、暗黙の前提は伝わりにくい	口頭の補足や業務慣習の共有がしやすい
時差・稼働時間	拠点国によって時差や祝日が異なる	同じ稼働時間・同じ祝日で動ける
契約・法令	海外への個人データ移転や準拠法を検討する必要がある	国内法の範囲で整理できる

この表の中で、発注側が最も過小評価しやすいのが「仕様の伝え方」です。国内の開発会社であれば「いつもの請求書の締め処理と同じで」と言えば通じる部分が、オフショアでは画面の項目、計算のルール、例外時の動きまで文書にしなければ伝わりません。これは相手の能力の問題ではなく、業務の前提を共有していないことによる差です。

なお、オフショア開発を担う会社の中には、日本人のプロジェクトマネージャーが要件定義と設計を国内で行い、実装とテストだけを海外拠点で行う体制を取るところもあります。この場合は発注側の負担が国内開発に近くなる代わりに、単価の差も小さくなります。見積もりを比較するときは、「どの工程を誰がどこで担当するのか」を最初に確認すると、比較の前提が揃います。

見積額の差がそのまま総コストの差にならない理由

オフショア開発の見積もりが安く見える主な理由は、エンジニアの単価です。しかし、システム開発の総コストは単価だけで決まるわけではありません。発注側が支払う金額と、社内で負担する工数を合わせて考える必要があります。

見積書に表れにくいコストには、次のようなものがあります。

• 仕様書や画面イメージを、誤解の余地がない粒度まで作り込む社内工数
• ブリッジSEや通訳を介した質疑応答の往復にかかる時間
• 成果物の確認と、意図と違う部分の差し戻しにかかる工数
• 手戻りによって納期が延びた場合の機会損失
• リリース後の改修を同じ体制に依頼し続けるための調整コスト

これらは、仕様が曖昧なほど大きくなります。たとえば、要件が固まりきっていない段階で発注し、開発中に仕様を詰めていく進め方をすると、質問と回答の往復回数が増えます。国内開発なら短い打ち合わせで済む確認が、オフショアでは文書のやり取りと翻訳を挟むため、1回あたりの所要時間が長くなりやすいのです。

もう一つ見落とされやすいのが、為替の影響です。海外拠点の人件費や外貨建ての契約は、為替の変動によって円換算の金額が変わります。日本の窓口会社と円建てで契約する場合でも、長期の契約や継続的な保守では、更新時の単価改定に為替が反映されることがあります。数年単位で保守を任せる予定なら、単価改定のルールを契約時に確認しておくと安全です。

総コストを比較するときは、見積額に加えて「社内の誰が、週に何時間、どの作業に関わる必要があるか」を両方の候補に同じ質問で確認し、その工数を社内の人件費で換算して足し合わせます。社内に担当者を割けないのであれば、その時点で、確認作業まで含めて任せられる体制を選ぶべきだという判断になります。

コスト以外で差がつく判断軸

オフショアか国内かを判断するときは、コストに加えて、次の軸で自社の案件を評価すると判断がぶれにくくなります。

仕様の確定度

画面、項目、計算ルール、例外処理まで文書で決まっている案件は、どの体制でも進めやすくなります。反対に、業務の進め方そのものを見直しながら作る案件や、使ってみてから仕様を固めたい案件は、発注側と開発者が頻繁に話せる体制のほうが手戻りを抑えられます。

発注側の管理能力

オフショア開発で成果を出している企業の多くは、社内に設計や品質を判断できる人がいます。成果物のレビュー、テスト結果の確認、仕様の優先順位付けを社内で行えるかどうかが、オフショアを使いこなせるかの分かれ目です。情報システム部門がない場合は、この役割を誰が担うのかを先に決めておく必要があります。

業務知識への依存度

会計、労務、医療、不動産など、日本の制度や商慣習に依存する業務は、開発者が背景を理解していないと仕様の行間を埋められません。制度に関わる計算ロジックが多い案件では、仕様書の記述量が大きく増えることを前提に考えます。

スピードと稼働時間

時差は拠点国によって異なり、ベトナムのように日本との時差が小さい国もあります。時差が小さくても、祝日や長期休暇の時期が日本と異なるため、日本の繁忙期に開発が止まることもあります。障害が起きたときに日本の営業時間内ですぐ対応が必要なシステムでは、誰がどの時間帯に対応するのかを確認しておきます。

データの取り扱い

開発や保守で個人データを扱う場合、海外の拠点がそのデータにアクセスできるかどうかで、法令上必要な対応が変わります。詳しくは後の見出しで説明しますが、本番データを使わずに開発できる案件かどうかも判断材料になります。

オフショアが向く案件・国内が向く案件

ここまでの判断軸を組み合わせると、案件の条件ごとに向き不向きを整理できます。一つの条件だけで決めず、複数の条件が同じ方向を向いているかを見てください。

案件・体制の条件	向いている方式	理由
仕様書が完成しており、社内にレビューできる担当者がいる	オフショア	伝達コストが小さく、単価の差がそのまま効きやすい
既存システムの移植や、決まった仕様のテスト作業が中心	オフショア	作業内容が明確で、成果物の正誤を判定しやすい
要件が固まっておらず、業務を見直しながら作る	国内	仕様の往復が多く、対話の速さが品質と納期に直結する
情報システム部門がなく、発注側にレビューできる人がいない	国内（または日本側が設計と管理を担う体制）	確認作業を開発側に任せる必要がある
日本の制度・商慣習に依存する計算や帳票が多い	国内	仕様の行間を開発者が補える
本番の個人データを使わないと開発・保守ができない	国内（オフショアなら法令対応を整えたうえで）	海外移転の手続きと管理の負担が増える

中小企業でよくあるのは、「情報システム部門はないが、費用は抑えたい」という状況です。この場合、オフショア開発の会社と契約しても、仕様の作り込みとレビューの負担が社内に残るため、結果的に担当者の本業が圧迫されがちです。費用を抑えたいなら、まず作る範囲を絞り、最初のリリースに必要な機能だけを国内の体制で作るほうが、総額でも期間でも有利になることがあります。

また、一つの案件の中で使い分ける方法もあります。要件定義、設計、受入テストは国内で行い、仕様が確定した部分の実装やテストの実行だけをオフショアに出す形です。この場合は、国内側が仕様書の品質に責任を持てるかが前提になります。発注先の候補が「日本側で設計し、海外で実装する」と説明している場合は、日本側の担当者が設計書をどこまで作るのか、海外の担当者からの質問に誰が答えるのかを確認してください。

オフショアを選ぶ場合に契約前に決めておくこと

オフショア開発を選ぶ場合は、国内開発以上に、契約前の取り決めが結果を左右します。次の項目は、見積もりの段階で確認しておきます。

確認項目	確認する内容
体制	日本側の窓口、ブリッジSE、開発者の人数と役割、担当者の交代時の引き継ぎ方法
コミュニケーション	定例の頻度、質疑の手段と回答期限、使用言語、議事録をどちらが作るか
成果物	設計書、ソースコード、テスト結果の納品形式と言語
品質	コードレビューとテストを誰がどこまで行うか、受入テストの基準
契約条件	契約の相手方、準拠法、紛争時の管轄、著作権の帰属、単価改定のルール
データ	本番データへのアクセスの有無、アクセスできる人と場所、データの消去方法

契約の相手方と準拠法

日本の窓口会社と契約する場合は、日本法を準拠法とし、国内の裁判所を管轄とする契約にできることが多いです。海外の会社と直接契約する場合は、準拠法や紛争解決の方法が相手国側になる可能性があり、問題が起きたときの対応が難しくなります。中小企業が初めてオフショアを使うなら、日本に法人や窓口があり、日本法で契約できる会社を選ぶほうが安全です。

個人データを扱う場合の法令対応

個人情報保護法第28条は、外国にある第三者に個人データを提供する場合、原則として本人の同意を求めています。個人情報保護委員会のQ&Aでは、外国にある第三者に個人データの取扱いを委託する場合もこの規定の対象となり、相手国が日本と同等の水準の制度を持つ国として定められている場合や、相手先が法令の求める措置に相当する体制を整備している場合などを除き、本人の同意が必要とされています。

実務では、開発や保守で海外拠点が本番の個人データにアクセスするかどうかで対応が大きく変わります。テストには架空のデータや匿名化したデータを使い、本番データには国内の担当者だけがアクセスする設計にできれば、海外移転の論点を小さくできます。本番データへのアクセスが避けられない場合は、相手先の体制と契約上の措置を確認し、必要に応じて専門家に相談したうえで進めてください。

小さく試してから広げる

初めてのオフショア開発で、いきなり基幹業務のシステム全体を任せるのはリスクが高いといえます。まずは仕様が明確な小さな機能や、既存システムのテスト作業などで一度取引し、仕様の伝わり方、質問の質、納品物の品質を確認してから範囲を広げる進め方が現実的です。

参考：個人情報の保護に関する法律／e-Gov法令検索（デジタル庁）

参考：外国にある第三者に個人データの取扱いを委託する場合の本人同意に関するQ&A（Q12-1）／個人情報保護委員会

まとめ

オフショア開発と国内開発の違いは、単価の違いだけではありません。仕様を伝え、確認し、手戻りを直す負担がどちら側にどれだけ発生するかが、総コストと納期を左右します。

判断の基準をまとめると次のとおりです。

• 仕様が確定しており、社内にレビューできる担当者がいるなら、オフショアの単価差が効きやすい
• 要件が固まっていない、または社内に確認できる人がいないなら、国内の体制で作るほうが総額と期間で有利になりやすい
• 日本の制度や商慣習に依存する業務が多いほど、国内開発の利点が大きくなる
• 本番の個人データを扱う場合は、海外移転の法令対応を前提に検討する

どちらを選ぶ場合も、比較の前提を揃えることが出発点です。候補の会社に「どの工程を誰がどこで担当するか」「社内の担当者は週に何時間関わる必要があるか」を同じ形式で質問し、見積額と社内工数を合わせて比べてください。そのうえで、最初の発注は小さな範囲に絞り、実際の進め方を確かめてから広げると、方式選びの失敗を小さく抑えられます。