オフショア開発とは — 費用相場と中小企業が失敗しない発注の判断基準

オフショア開発とは、システムやアプリの開発を、ベトナム・フィリピン・インドなど海外の開発会社やチームに委託する方法です。最大の魅力は、日本国内より人月単価（エンジニア1人を1か月働かせる費用）が低く抑えられる点にあります。一方で、「単価が安い＝総額が安い」とは限らず、条件が合わない案件では、国内に頼むより高くつくことも珍しくありません。

結論を先に述べると、オフショア開発は「要件が固まっていて、ある程度の規模があり、自社または間に入る会社に仕様を整理できる人がいる」案件には有力な選択肢です。反対に、「何を作りたいかがまだ曖昧」「小規模で、頻繁に仕様が変わる」「発注側にITの窓口担当が一人もいない」という中小企業では、失敗しやすい方法でもあります。本記事では、IT専門ではない経営者・担当者に向けて、定義、国別の費用目安、総額が膨らむ理由、向き不向き、契約の型、失敗パターン、発注前チェックリストを整理します。金額はいずれも市場でよく見られる一般的な目安であり、為替やスキルで大きく変わります。

「オフショア」は、もともと「海外・沖合」を意味する言葉です。オフショア開発は、開発作業の全部または一部を海外の拠点に任せる形を指します。日本の会社がベトナムの開発会社に直接発注する場合もあれば、日本に窓口会社があり、実際の開発は海外の自社拠点が行う場合もあります。前者を直接契約、後者を日本法人経由と呼ぶことが多く、中小企業が最初に頼む場合は、日本語で窓口になってくれる後者のほうが現実的です。

似た言葉が多いので、まず選択肢を整理しておきます。「ニアショア」は国内の地方拠点（沖縄・福岡・北海道など）に任せる方法で、言葉や商習慣の壁が低いのが特徴です。「国内受託」は東京などの開発会社に頼む一般的な方法、「フリーランス」は個人に直接頼む方法です。

フリーランスと開発会社の違いはフリーランスと開発会社の比較で詳しく整理しています。オフショアはこの比較表のどれか一つに置き換わるものではなく、「コストを下げたい、人手を確保したい」という目的に対する選択肢のひとつです。

オフショアの委託先として知られる国には、ベトナム、フィリピン、インド、バングラデシュ、中国などがあります。国によって得意分野、エンジニアの人数、日本語人材の多さが違います。たとえばベトナムは日本向けの開発会社が多く、日本語を話せるブリッジ役（後述）も比較的見つけやすい国です。インドはAI・クラウドなど高度な技術領域の人材が厚く、フィリピンは英語が通じやすくカスタマーサポート的な業務との相性が良いと言われます。

下の表は、エンジニア1人の1か月あたりの費用について、市場で見られる一般的な目安です。発注先の規模、エンジニアの経験年数、為替、契約の形によって実際の金額はこの範囲を外れます。また、各国の人件費は上昇傾向にあり、数年前の相場がそのまま通用するとは限りません。あくまで比較の参考としてご覧ください。

ここで大切なのは、表のとおり単価を単純比較すると、オフショアは国内の3〜6割程度に見えるという点です。しかし、これは「エンジニアの作業費」だけの比較です。次の章で説明するとおり、実際に支払う総額にはほかの費用が加わります。

オフショアで総額が思ったほど下がらない理由は、主に4つあります。1つ目は、ブリッジSE（日本側と海外側の通訳・調整役）の費用です。仕様を日本語で受け取り、海外のエンジニアが理解できる形に翻訳して伝える役割で、開発規模の1〜2割程度の人員が付くのが一般的です。この人件費は単価の高い日本語人材のため、全体の費用に効いてきます。

2つ目は、コミュニケーションコストです。国内なら口頭で済む確認も、オフショアでは文書化して送り、返答を待つ必要があります。定例会議の通訳、議事録の翻訳、チャットでの質問対応など、「作る以外の工数」が国内より増えます。3つ目は手戻りです。日本語の曖昧な表現（「いい感じに」「適宜」「よしなに」）は、そのままでは海外のエンジニアに伝わりません。解釈の違いで作り直しになった分の費用は、請負契約でなければ発注側の負担になります。4つ目は、発注側のPM（プロジェクト管理）工数です。進捗確認、品質確認、仕様の判断など、自社側で必ず人手が必要になります。

最後の行の「2〜4割」はあくまで条件が良い場合の目安です。仕様が固まっており、規模が大きく、発注側にも調整できる人がいる場合に、ようやくそのくらいの差が出ます。逆に、小規模な案件ではブリッジSEなど固定的に必要な費用の割合が大きくなり、国内と変わらない、あるいは逆転する場合もあります。

- 単価が低く、同じ予算でより多くの人数・期間を確保しやすい
- 国内で採用が難しいエンジニア（特にAI・モバイル・レガシー言語など）を確保しやすい
- 大規模案件で、複数人のチームを立ち上げやすい
- 日本のチームが帰宅した後に作業が進む「時間差の活用」ができる国もある
- 長期的に同じチームと付き合うことで、システムの理解が蓄積される（ラボ型の場合）

- 言語・文化の違いによる認識のずれが起こりやすい
- 仕様書など文書の作成負担が増える
- 発注側がマネジメントに関与しないと、品質が安定しない
- 国や会社によっては、離職率が高くチームが入れ替わる
- 時差・祝日・文化的な休暇で、連絡が取れない日がある
- 情報管理（個人情報・営業秘密）や法令対応を、契約と運用で担保する必要がある
- 為替の変動によって、円建てでない契約の場合は費用が変わる

オフショアが向くかどうかは、「仕様をどれだけ文書で固められるか」と「規模」でほぼ決まります。次の表を一つの目安にしてください。

中小企業で「ITに詳しい担当者がいない」場合は、海外に直接発注するのは避け、日本の窓口会社が仕様整理から検収までを受け持つ形を選ぶほうが安全です。それでも、仕様の確認や優先順位の判断は発注側の仕事として残ります。任せきりにできる形は、基本的にありません。

オフショアの契約には、大きく「請負型」と「ラボ型」があります。名前は聞き慣れなくても、考え方は難しくありません。請負型は「決まった成果物を、決まった金額で作ってもらう」契約、ラボ型は「一定期間、専属のチームを確保して、その枠の中で開発を進める」契約です。

ITの専任担当がいない中小企業にとって、ラボ型は難易度が高い契約です。毎日の優先順位づけや仕様判断を自社で担う必要があり、運用できないとチームの稼働だけが費用として積み上がります。最初の案件は、範囲と金額を決められる請負型（または仕様を確定してから請負で進める二段階の形）から始めるほうが、リスクを抑えられます。どちらの型でも、契約の区別（請負か準委任か）で責任の範囲が変わるため、事前に確認が必要です。

次の表は、同じ内容の開発を国内で頼んだ場合とオフショアで頼んだ場合の総額のイメージです。条件によって大きく変わるため、あくまで比較の感覚をつかむための目安としてご覧ください。ブリッジSEなどの費用を含めた、発注側が支払う合計額を想定しています。

小規模ではメリットが出にくく、規模が大きくなるほど差が広がるのが一般的です。これは、ブリッジSEや仕様書作成のような「規模によらず必要な固定費」が、大規模になるほど全体に占める割合として薄まるためです。国内の費用感はシステム開発費用の相場ガイドも参考になります。

オフショアで起こるトラブルには、ほぼ決まったパターンがあります。事前に知っておけば、多くは避けられます。

もっとも多い原因です。「会員管理がしたい」「予約をネットでできるようにしたい」程度の指示では、海外のエンジニアは自分の経験で補って作ります。それが日本の業務の流れと合わず、完成間近で大きな修正になります。要件を整理して発注側の希望を文書にする作業は、国内でも重要ですが、オフショアでは必須です。RFP（提案依頼書）の書き方はRFPの基本で解説しています。

口頭の合意や、日本の現場では当たり前の暗黙のルールは伝わりません。画面遷移、入力項目、エラー時の動き、データの持ち方を、できるだけ図と具体例で残します。「正常な場合」だけでなく「エラーや例外の場合」を書くことが、手戻りの防止に最も効きます。

「完成した」と受託側が言っても、発注側が「求めていたものと違う」と感じる事態が起こります。何をもって完成とするか、どのテストに合格すれば受け入れるか、不具合の修正は誰の負担かを、契約前に書面で決めておきます。確認の観点は検収のチェックポイントが参考になります。

納品物の著作権が誰に帰属するか、ソースコードを受け取れるか、海外の会社との契約ではどの国の法律に従うかを、見落としがちです。権利が受託側に残る契約だと、将来、別の会社に保守を移したくても移せなくなります。基本的な考え方はソースコードの著作権で整理しています。海外との契約では、準拠法や紛争時の管轄も確認しておきましょう。

ベトナムやフィリピンは日本との時差が1〜2時間で済みますが、インドは3時間半程度あり、営業時間の重なりが短くなります。祝日や大型連休（旧正月など）は国ごとに違い、その期間は連絡が取れません。さらに、チャットの文面だけで細かな要望を伝えようとすると誤解が増えます。定例会議の時間、連絡手段、返信の目安時間をあらかじめ取り決めておくと、すれ違いを減らせます。

オフショアを検討する前に、次の項目を確認してみてください。多くが「いいえ」になる場合は、国内受託のほうが適している可能性があります。

- 作りたいものの目的・対象ユーザー・必要な機能を文書にまとめられているか
- 仕様の判断や確認に対応できる担当者（社内に1人）を決められるか
- 規模は目安として10人月以上、または半年以上の継続開発か
- 日本語で窓口になる会社（ブリッジSE付き）を選べているか
- 請負・準委任・ラボ型のどれかを理解し、案件に合う契約を選べているか
- 検収の基準とテストの範囲を契約前に書面にしたか
- ソースコードと著作権の帰属、受け取れる範囲を契約に明記したか
- 個人情報や機密情報の取り扱い、再委託の可否を確認したか
- 為替変動が起きた場合の費用の扱い（円建てか）を確認したか
- 追加費用が発生する条件（仕様変更・追加依頼）を事前に聞いたか
- 保守・運用を誰が引き受けるか、担当が変わったときの引き継ぎを確認したか
- 最初は小さく（1〜2か月の小規模な範囲）試して、相性を見る計画があるか

初めてオフショアを使う中小企業は、いきなり大きな案件を任せず、小さく試すのが基本です。たとえば、既存システムの一部機能の追加や、画面の追加のように、範囲が明確で失敗しても影響が限られる案件を選びます。そこで、仕様書の書き方、やり取りの速さ、品質、見積もりの正確さを確かめてから、規模を広げるのが堅実です。

また、見積もりは必ず複数社から取り、人月単価だけでなく、ブリッジSEの人数、仕様書の作成範囲、テストの範囲、保証期間が含まれているかを見比べます。極端に安い見積もりは、これらが含まれていない可能性があります。「何が含まれ、何が含まれないか」を一覧にしてもらうと、比較がしやすくなります。