オフショア開発の費用相場｜会社の選び方

オフショア開発の費用は、エンジニア1人月あたり35万〜100万円程度が一般的な目安です。ただし、国内より単価が低くても、要件整理や通訳、品質管理、手戻りを含む総額で判断しなければなりません。成功の鍵は、安さではなく類似実績・日本語での橋渡し体制・品質基準・契約範囲を比較することです。

• オフショア開発が向いている案件・向いていない案件
  • オフショア開発が向いている案件
  • オフショア開発を慎重に判断すべき案件
• オフショア開発の費用相場と期間
  • 役割別の人月単価
  • 国・地域別の単価目安
  • 案件規模別の総額と期間
  • ラボ型と請負型の費用構造
  • 総額に含めるべき付帯費用
• 発注前の準備とオフショア開発の進め方
  • 1. オフショア開発を使う目的を決める
  • 2. 発注側の責任者と意思決定方法を決める
  • 3. 候補会社へ同じ条件で情報を渡す
  • 4. 実際の担当候補者と面談する
  • 5. 有償トライアルまたは一部機能から始める
  • 6. 連絡と承認のルールを決めて開始する
• 見積もり比較と開発会社の選び方
  • 見積もりで確認すべき項目
  • 評価表を使って候補会社を比較する
  • 開発会社を見極めるチェックリスト
  • よくある失敗と回避策
• まとめ
• よくある質問
  • オフショア開発は国内開発よりどのくらい安くなりますか？
  • 小規模案件でもオフショア開発を利用できますか？
  • ラボ型と請負型はどちらを選ぶべきですか？
  • オフショア開発のセキュリティは何を確認すべきですか？

オフショア開発が向いている案件・向いていない案件

オフショア開発とは、海外にある開発会社や開発拠点へシステム開発を委託する方法です。ベトナム、フィリピン、インド、中国、東欧などが主な委託先として挙げられます。

国内の地方企業へ委託するニアショア開発とは異なり、オフショア開発では言語、時差、商習慣、為替なども考慮する必要があります。単価を下げるためだけの方法ではなく、一定規模の開発チームを確保する選択肢として検討するのが適切です。

オフショア開発が向いている案件

次の条件が多く当てはまるほど、オフショア開発の利点を得やすくなります。

• 3〜6カ月以上の継続的な開発を予定している
• 複数人のエンジニアを一定期間確保したい
• 作りたい機能と優先順位を文章や画面イメージで共有できる
• 発注側にプロダクトオーナー（＝仕様の優先順位を決める責任者）を置ける
• 週1回以上の定例会と、日常的なテキスト連絡に対応できる
• 小さな単位で開発・確認・改善を繰り返せる
• 将来の機能追加や運用改善を予定している

たとえば、Webサービスや業務システムの新規開発、既存サービスの継続改修、テスト業務などは比較的相性のよい領域です。

オフショア開発を慎重に判断すべき案件

一方、次のような案件では、立ち上げ負担が費用削減効果を上回る可能性があります。

• 数週間で完了する小規模な修正
• 即日対応や頻繁な対面調整が必要な案件
• 発注側で仕様を決める担当者がいない
• 口頭の指示だけで開発を進めたい
• 既存システムの資料やソースコードが整理されていない
• 法令や業界固有の業務知識について細かな判断が必要
• 機密情報を海外拠点から扱えない社内規程がある

これらの案件でもオフショア開発が不可能とは限りません。ただし、日本側で要件を整理する担当者を置く、国内チームと海外チームを組み合わせるなど、追加の体制が必要です。

開発のご相談を受ける立場では、「海外へ任せれば日本側の担当者が不要になる」という誤解がよく見られます。実際には、発注側で判断する人が不在だと確認待ちが増え、開発速度も費用面の利点も失われやすくなります。

オフショア開発の費用相場と期間

費用は、国だけでなく、担当者の経験、必要な日本語水準、契約方式、品質管理の範囲によって大きく変わります。以下は日本企業がオフショア開発会社へ委託する場合の一般的な目安であり、税金、クラウド利用料、外部サービス利用料などは含めていません。

役割別の人月単価

人月とは、1人が1カ月稼働する作業量を表す単位です。実際の給与ではなく、開発会社の管理費や設備費などを含む請求単価として考えてください。

ブリッジSEを省けば安く見えますが、日本語での要件理解や調整を発注側が直接担うことになります。発注側に英語または現地語で細かな仕様を伝えられる担当者がいない場合、ブリッジSEは実質的に必要な費用です。

国内案件を含む単価の考え方は、人月単価の相場｜システム開発見積もりの見方でも詳しく解説しています。

国・地域別の単価目安

この表は国ごとの優劣を示すものではありません。同じ国でも、都市、会社規模、担当者の経験、日本語対応の有無によって金額は変わります。国だけで発注先を選ばず、実際に参加するメンバーの経験を確認することが重要です。

案件規模別の総額と期間

MVPとは、顧客ニーズを検証できる最小限の製品を意味します。同じ「MVP」でも、決済、外部システム連携、スマートフォンアプリ、複雑な権限管理などが含まれると費用は上がります。

ラボ型と請負型の費用構造

オフショア開発の主な契約方式は、ラボ型と請負型です。

ラボ型では、確保したメンバーの稼働時間に対して費用を支払います。仕様を柔軟に変更できますが、完成物そのものが契約の中心ではないため、発注側が開発項目の優先順位を継続的に管理しなければなりません。

請負型では、仕様書に基づく成果物の完成が契約の中心です。予算を固定しやすい一方、要件が曖昧な状態で契約すると、後から追加見積もりが発生しやすくなります。

総額に含めるべき付帯費用

単価比較だけでは、実際の予算を判断できません。少なくとも次の費用を確認してください。

• ブリッジSEとプロジェクトマネージャーの費用
• 要件定義（＝作るものを決める工程）の費用
• 画面・デザイン制作費
• テスト計画と品質管理費
• 開発環境や検証端末の費用
• クラウド、外部API、各種ライセンスの利用料
• 翻訳、出張、現地訪問の費用
• セキュリティ対策と監査対応費
• 公開後の保証、保守、障害対応費
• 為替変動時の価格改定条件

オフショア開発の総額は、「海外メンバーの単価×人数×期間」だけではありません。日本側の管理工数や手戻りまで含めた総保有コストで比較する必要があります。

発注前の準備とオフショア開発の進め方

成功率を高めるには、いきなり大きな契約を結ばず、目的の整理、候補会社の確認、小規模な検証、段階的な拡大という順番で進めます。

1. オフショア開発を使う目的を決める

最初に、発注する目的を一文で説明できる状態にします。「安くしたい」だけでは、候補会社も適切な体制を提案できません。

目的の例は次のとおりです。

• 国内だけでは確保できない開発人員を補いたい
• 継続改修を行う専属チームを作りたい
• 新規サービスを一定予算で検証したい
• テスト工程を分離して品質確認を強化したい
• 将来の内製化に向けて開発知識を蓄積したい

費用削減を目的にする場合も、「国内開発費から何％下げるか」だけではなく、公開時期、必要な品質、運用後の改修体制を併せて定義します。

2. 発注側の責任者と意思決定方法を決める

発注側では、少なくとも次の役割を明確にします。1人が複数の役割を兼ねても構いません。

• 予算と契約を承認する責任者
• 機能の優先順位を決める業務責任者
• 仕様の質問に回答する担当者
• 納品物を確認して検収する担当者
• セキュリティや法務を確認する担当者

海外チームから質問が届いても、回答に数日かかれば開発は止まります。「誰が、何営業日以内に、どの範囲まで決められるか」を決めておくことが大切です。

3. 候補会社へ同じ条件で情報を渡す

複数社を比較する場合は、提案依頼書（RFP＝候補会社へ同条件で提案を求める資料）を用意します。詳細な仕様書が完成していなくても、次の情報は共有しましょう。

• 開発の目的と解決したい課題
• 想定する利用者と利用人数
• 必要な機能と優先順位
• 参考にしたいサービスや画面
• 既存システム、データ、外部サービスとの連携
• 非機能要件（＝速度、セキュリティ、稼働時間など機能以外の条件）
• 希望する公開時期
• 予算の上限または検討可能な範囲
• 発注側の体制と連絡可能な時間帯
• 希望する契約方式

情報量が候補会社ごとに違うと、見積もりの前提も変わります。その結果、価格差が会社の違いなのか、対象範囲の違いなのか判断できなくなります。

4. 実際の担当候補者と面談する

営業担当者や経営者だけでなく、プロジェクトマネージャー、ブリッジSE、開発責任者の候補とも面談します。会社として実績があっても、実際に参加するメンバーが同様の経験を持つとは限りません。

面談では次の質問が有効です。

• 類似案件でどの役割を担当したか
• 要件に曖昧な点がある場合、どのように整理するか
• 不具合を減らすためにどの工程で何を確認するか
• 予定より遅れた場合、いつ、どのように報告するか
• 担当者が交代する場合の引き継ぎ方法は何か
• 日本側の発注者に求める作業は何か

良い候補会社は、できることだけでなく、現時点で不明な点や発注側が準備すべき事項も説明します。すべての要望へ確認なく「対応できます」と答える会社より、前提とリスクを具体的に質問する会社の方が検討しやすいといえます。

5. 有償トライアルまたは一部機能から始める

初回から大規模な契約を結ぶ必要はありません。一般的には、2〜6週間程度の有償トライアルや、一部機能の開発から始める方法があります。費用は内容によって数十万〜200万円程度が一つの目安です。

トライアルでは完成物だけでなく、次の点を評価してください。

• 質問の意図を正しく理解できるか
• 約束した日時までに報告があるか
• 進捗や課題が見える状態になっているか
• 不明点を推測だけで進めず確認できるか
• テスト結果や設計の根拠を説明できるか
• 指摘内容が次の作業へ反映されているか

トライアルを無償で求めると、実際の担当者ではなく提案専任者が対応する可能性もあります。実務と同じ条件で相性を確認するためには、適切な範囲の有償契約にする方が現実的です。

6. 連絡と承認のルールを決めて開始する

開始前に、日常連絡、会議、課題管理、承認のルールを決めます。

• 日々の進捗はテキストで共有する
• 週1回は進捗・課題・次週予定を確認する
• 重要な仕様変更は文章で記録する
• 誰がいつまでに回答するかを課題ごとに設定する
• 予算や納期に影響する変更は作業前に承認する
• 遅延の兆候を報告する基準を決める

発注後の管理方法については、システム開発の進捗管理｜発注後の遅延対策も参考にしてください。

自社案件がオフショア開発に向いているか、国内開発とどう組み合わせるべきか判断が難しい場合は、開発のご相談はこちらからご相談ください。

見積もり比較と開発会社の選び方

開発会社は、最安値ではなく「要件を理解し、品質を管理しながら完了まで運営できるか」で選びます。単価が安くても、管理費や追加費用が多ければ総額は下がりません。

見積もりで確認すべき項目

候補会社の見積もりを受け取ったら、次の項目が明記されているか確認します。

• 開発対象となる機能と対象外の機能
• 要件定義、設計、開発、テストの工程別費用
• 役割別の人数、人月、単価
• ブリッジSEと管理者の稼働割合
• 作成される設計書、テスト結果、操作資料
• 対応する端末、OS、ブラウザの範囲
• セキュリティ確認の内容
• 仕様変更時の計算方法と承認手順
• 為替変動時の価格改定条件
• 保証期間と無償修正の範囲
• 公開後の保守費用
• 契約終了時に引き渡されるデータや資料

見積もりに「開発一式」としか書かれていない場合は、そのまま契約せず、工程、役割、成果物に分けてもらいましょう。

また、金額差が大きいときは値引き交渉の前に、前提条件を確認します。安い見積もりでは、要件定義、テスト、デザイン、公開作業、保証などが対象外になっている場合があります。

評価表を使って候補会社を比較する

担当者の印象だけで決めず、評価項目と配点を事前に決めると社内で合意しやすくなります。

配点は案件に応じて調整してください。個人情報を扱う案件ならセキュリティの配点を上げ、新規事業なら提案力と変更対応を重視します。

開発会社を見極めるチェックリスト

• 実際に参加する担当者と契約前に面談できる
• 類似案件での担当範囲を説明できる
• 日本側と海外側の責任分界が明確である
• ブリッジSEの日本語力と業務理解を確認できる
• テスト工程と不具合管理方法が具体的である
• 進捗の遅れや課題を報告する基準がある
• 再委託の有無と委託先を開示できる
• ソースコードやクラウドの管理主体を決められる
• 担当者交代時の引き継ぎルールがある
• 契約終了後に資料とデータを受け取れる
• セキュリティ事故時の連絡手順が決まっている
• 仕様変更時の追加費用を事前に算定できる

特に重要なのは、ソースコード、クラウド、外部サービスの契約アカウントを誰が管理するかです。開発会社だけが管理する状態にすると、契約終了後の保守や他社への引き継ぎが難しくなります。可能な範囲で発注者名義の環境を用意し、開発会社へ必要な権限だけを付与します。

よくある失敗と回避策

単価だけで会社を選ぶ

最安単価の会社を選んでも、ブリッジSE、管理、テストが別料金なら総額は上がります。単価ではなく、同じ機能、品質、体制、期間を前提にした総額で比較してください。

仕様決定まで海外チームへ任せる

開発会社は仕様案を提案できますが、事業上の優先順位や業務ルールを最終決定するのは発注者です。社内で判断できない項目を放置すると、確認待ちか手戻りのどちらかが発生します。

最初から全機能を一括発注する

コミュニケーションや品質を確認しないまま大規模契約を結ぶと、相性が合わなくても変更しにくくなります。要件整理、トライアル、主要機能、全体開発というように段階を分ける方法が有効です。

契約範囲と検収条件が曖昧である

検収とは、納品物が契約どおりか発注者が確認する手続きです。「問題なく動くこと」だけでは判断が分かれるため、確認する機能、対応環境、性能、不具合の扱いを事前に決めます。

問題が起きてから連絡方法を決める

遅延や品質問題が発生してから報告ルールを作ると、状況把握に時間がかかります。開始時点で、日次報告、定例会、課題一覧、緊急連絡先、意思決定期限を設定してください。

まとめ

• オフショア開発のエンジニア単価は、1人月35万〜100万円程度が一般的な目安です
• 単価だけでなく、ブリッジSE、品質管理、翻訳、手戻りを含む総額で比較します
• 3〜6カ月以上の継続開発や、複数人のチーム確保を必要とする案件と相性があります
• 仕様が固まった案件は請負型、変更しながら進める案件はラボ型が候補になります
• 発注側にも、機能の優先順位と仕様を決定する責任者が必要です
• 候補会社へ同じ条件を伝え、実際に参加する担当者と面談します
• 初回は2〜6週間程度の有償トライアルや一部機能から始める方法が現実的です
• 見積もりでは、対象範囲、役割別単価、成果物、追加費用、保証条件を確認します
• 開発会社は、類似実績、橋渡し体制、品質管理、セキュリティ、契約終了時の引き継ぎまで含めて選びます

よくある質問

オフショア開発は国内開発よりどのくらい安くなりますか？

人月単価だけなら国内開発より2〜5割程度低く見えることがあります。ただし、ブリッジSE、品質管理、翻訳、手戻りまで含めると差は縮まります。比較時は同じ要件と品質基準で総額を確認してください。

小規模案件でもオフショア開発を利用できますか？

可能ですが、数週間で終わる小規模案件は立ち上げ負担が相対的に大きく、割安になりにくい傾向があります。まず2〜6週間程度の有償トライアルや一部機能から始め、相性と品質を確認する方法が現実的です。

ラボ型と請負型はどちらを選ぶべきですか？

仕様と納品物が固まっている案件は請負型、優先順位を変えながら継続開発する案件はラボ型が向いています。要件が不確かなまま請負型にすると追加費用が増えやすいため、要件整理後に請負へ移る方法もあります。

オフショア開発のセキュリティは何を確認すべきですか？

契約や認証の有無だけでなく、アクセス権限、端末管理、ソースコードの保管先、再委託、退職者の権限削除、事故時の報告手順を確認してください。機密データを使わない検証環境から始めるとリスクを抑えられます。