- Published on
ベトナムオフショア開発の費用はどう決まる?単価と工数の考え方
要点 / TL;DR
ベトナムオフショア開発の費用は「単価×工数」で決まります。単価はエンジニアのスキル、BrSEの関与、契約形態で変わり、工数は要件の解像度、機能範囲、非機能要件で変動します。見積もりは総額だけでなく内訳で確認することが判断の出発点です。
この記事はAIの支援で作成し、人間が確認しています
- Authors

- Name
- MK1編集部

ベトナムオフショア開発の費用とは?基本の計算式
ベトナムオフショア開発の費用は、「単価×工数」で表せます。単価はエンジニア1人あたりの月額または時間額、工数はプロジェクトの完了までに必要な総作業量です。見積もりに記載された総額だけを見ても、この2つの内訳が分からなければ、金額の妥当性は判断できません。
工数は、人月(1人が1か月従事した量)や人日(1人が1日従事した量)で数えます。例えば、複数のエンジニアが数か月にわたって開発に従事する場合、人数と期間を掛けた値が人月の工数になります。単価にこの工数を掛けたものが、費用のおおまかな考え方です。
費用には、開発の工数だけでなく、要件定義、テスト、プロジェクト管理、場合によってはインフラの利用料も含まれます。何を費用に含めるかは、見積もりの前提条件として確認しておきたい項目です。
見積もりを評価するときは、総額を「何人月の想定か」「月額単価はいくらか」に分解してみてください。金額の大小が単価の高さによるものか、工数の多さによるものかが見えます。
ベトナムオフショア開発の「単価」は何で決まるのか?
単価は、エンジニアのスキル、日本人との橋渡しを担うBrSE(ブリッジSE)の関与、契約形態の3つで大きく変わります。同じベトナムでも、体制の組み方によって単価の意味合いが異なります。
エンジニアのスキルと経験年数
担当する工程と、自走できる範囲によって、求められる単価は変わります。実装だけを担うのか、設計や技術選定まで任せるのかで、必要な経験年数は異なります。対応する技術(例えば、React、Go、AWS)も、人材の集まりやすさによって条件が変わります。
| ポジション | 主な役割 | 単価への影響 |
|---|---|---|
| ジュニア | 指示された範囲の実装とテスト | 相対的に小さくなる |
| ミドル | 設計の一部を担い、自律して実装する | 中程度 |
| シニア | 設計・技術選定・レビュー、後進の指導 | 相対的に大きくなる |
| BrSE | 要件の翻訳、日本側との調整 | 体制に含めるかで総額が変わる |
| QA担当 | テスト設計・実行・自動化 | テスト範囲に応じて変動する |
具体的な金額は時期や条件で動くため、複数社の見積もりを同じ条件で並べて比較します。
BrSEの役割
日本語の要件を、ベトナム側の開発チームに伝わる形へ翻訳し、認識のずれを埋める役割です。BrSEの工数を見積もりに含めるかどうかで、総額は変わります。含めずに済ませれば単価は下がりますが、認識のずれが手戻りとして工数に跳ね返ることがあります。
契約形態(ラボ型開発・受託開発)
ラボ型開発(準委任契約)は月額固定で、仕様を固めきれない探索的な開発に向きます。受託開発(請負型)はプロジェクト総額で提示され、スコープが固まっている場合に判断しやすい形です。
ラボ型開発では「1人月いくら」が単価として前面に出ます。受託開発では総額が先に示され、そこから逆算して実質的な単価が決まります。同じ開発でも、どちらの契約形態かによって単価の見え方が違います。
ベトナムオフショア開発の「工数」はどう見積もるのか?
工数は、要件定義の解像度、開発スコープ、非機能要件の3つで大きく変動します。機能の数が同じでも、前提が違えば見積もりの結果は変わります。
要件定義の解像度
要件が曖昧なまま見積もりを出すと、担当者は仕様変更に備えて余裕(バッファ)を積みます。その結果として総額が上がり、後から金額の根拠を説明しにくくなります。画面遷移、入力項目、例外時の動きまで決まっていると、工数の内訳を示せます。
開発スコープ(機能一覧)
WBS(Work Breakdown Structure)のように機能を小さな作業に分解し、それぞれへ工数を割り当てる方法が一般的です。作業単位が細かいほど、見積もりの精度は上がります。機能一覧に優先度を付け、初回リリースに含める範囲を決めておけば、工数の総量を調整できます。
非機能要件(品質・セキュリティなど)
性能、セキュリティ、テスト範囲は工数に直接影響します。例えば、手動テストに加えて自動化テストも整備する場合、その設計と実装の工数が加わります。リリース後の保守運用をどこまで含めるかも、見積もりの前提として確認しておきたい項目です。
ベトナムオフショア開発の見積もりで確認すべきチェックリスト
受け取った見積もりは、金額の大小ではなく内訳で確認します。次の項目を説明できるかどうかが、判断の材料になります。
- 前提条件(スコープ、期間、稼働時間、体制)は明記されているか
- 機能ごとの工数内訳が示されているか
- BrSEやQAの工数は含まれているか、別枠か
- インフラ構築と保守運用の費用は含まれているか、別途か
- リスクやバッファをどの程度見込んでいるか
- 追加変更が生じた場合の単価と手続きが決まっているか
「総額はいくらか」だけでなく、「どの前提で、どの作業に、何を見込んだのか」まで確認すると、条件をそろえて比較できます。説明が足りない項目は、契約前に質問しておきます。
ベトナムオフショア開発の費用を抑えるには?
安さだけで選ぶと、後工程の手戻りが総額を押し上げます。費用対効果を高める進め方を4つ挙げます。
- MVP(実用最小限の製品)から始める。すべての機能を作る前に、主要な機能だけをリリースして反応を確かめます。検証を経てから次の開発へ進めば、不要な機能に工数を割らずに済みます。
- 発注側で要件定義を固める。決めるべきことを先に決めておくと、想定外の仕様変更による追加費用を抑えられます。
- 長期的なパートナーシップを前提にする。プロジェクトごとに体制を組み直すと、毎回同じ説明と学習の工数が発生します。継続して依頼できる相手を選べば、この工数を減らせます。
- 契約形態をプロジェクトの性質に合わせる。仕様が固まっている開発は受託開発、方向を探りながら進める開発はラボ型開発が向きます。
ベトナムの投資環境や日系企業の動向については、ジェトロが公開する国・地域別の情報も参考になります。
まとめ
ベトナムオフショア開発の費用は「単価×工数」で決まります。単価はエンジニアのスキル、BrSEの関与、契約形態で変わり、工数は要件の解像度、機能範囲、非機能要件で変動します。見積もりは総額ではなく、前提と内訳を確認することが判断の出発点です。
当社は2020年7月にベトナム・ハノイで設立し、20名以上の体制で、これまで100件以上のプロジェクトを通じて日本企業のソフトウェア開発を支援してきました。自社の場合は単価と工数のどちらを調整できるのか整理したい場合は、お問い合わせからご相談ください。
FAQ
ベトナムオフショア開発の費用は日本国内の開発と比べて安いですか?
単価の水準だけでは優劣を判断できません。日本国内と比べる場合も、同じスコープ、同じ期間、同じ体制の条件で見積もりを並べ、総額で比較します。BrSEやQA、プロジェクト管理の工数をどちらが含むかで結果が変わるため、前提をそろえることが先になります。
単価が安い会社を選べば費用は下がりますか?
単価が低くても工数が増えれば総額は下がりません。要件の解像度が低いまま開発が進むと手戻りや追加開発が発生し、結果として工数が膨らみます。単価と工数の両方を見て判断します。
見積もり後に費用が増えることはありますか?
仕様変更や追加要望が生じた場合、費用は変わります。変更が起きたときの単価と手続きを契約前に確認しておくと、後からの認識のずれを避けられます。リスクやバッファをどの程度見込んでいるかも、あわせて確認したい項目です。
ラボ型開発と受託開発では、どちらが費用を抑えられますか?
一概に決まりません。仕様が固まっている開発は受託開発(請負型)で総額を把握しやすく、方向を探りながら進める開発はラボ型開発(準委任契約)の月額固定がなじみます。プロジェクトの性質に合わせて選びます。
工数見積もりの精度を上げるにはどうすればよいですか?
要件定義の解像度を上げることが近道です。機能一覧を小さな作業に分解し、非機能要件やテスト範囲も明記したうえで見積もりを依頼します。仕様を固めきれない段階では、MVPで初回リリースの範囲を絞る方法もあります。
リリース後の保守運用の費用は開発費用に含まれますか?
見積もりの前提によって変わります。開発費用に含めるか、別途の契約にするかを最初に確認してください。運用中の問い合わせ対応や改修の範囲を決めておくと、後から費用の認識がずれにくくなります。