Published on

ベトナムオフショア開発の現状と費用相場|自社に合う開発会社の選び方

要点 / TL;DR

ベトナムオフショア開発は、場所(ベトナム)と契約形態(受託開発(請負型)・ラボ型開発(準委任契約))を分けて捉えると整理しやすくなります。費用は単価×工数で決まるため、相場の目安だけで判断せず、要件定義・体制・品質保証(QA)を同じ前提で比較することが、自社に合う開発会社を選ぶ近道です。

この記事はAIの支援で作成し、人間が確認しています

Authors
  • avatar
    Name
    MK1編集部
    Twitter
ベトナムオフショア開発の現状と費用相場|自社に合う開発会社の選び方

ベトナムオフショア開発とは?日本企業が選ぶ背景

オフショア開発とは、ソフトウェアの企画・設計・開発・運用の一部または全部を海外のパートナー企業に委ねる進め方を指します。ベトナムオフショア開発は、その委託先をベトナムに置く場合です。検討を始めるときは、「どこに委ねるか」という場所の軸と、「どの契約で委ねるか」という契約形態の軸を分けて捉えると、比較の整理がしやすくなります。

オフショア開発と国内開発の違い

国内開発との違いは、開発チームが同じ場所にいない点にあります。仕様の伝え方、レビューの頻度、判断を仰ぐタイミングを先に決めておく必要があります。日本語でやり取りできる窓口やBrSE(ブリッジSE)を置く体制であれば、進め方は国内開発に近づけられます。反対に、こうした取り決めが曖昧なままだと、認識のずれが手戻りとして表面化します。

ベトナムが候補に挙がる理由

ベトナムには、日本企業向けのソフトウェア開発・DX支援を手がける開発会社があります。委託先を選ぶときは国名だけで判断せず、日本企業向けの開発をどの程度手がけているか、日本語でのコミュニケーションをどう組み立てているかを確認すると、判断の軸がはっきりします。

契約形態の違いを押さえる

契約形態は、大きく受託開発(請負型)とラボ型開発(準委任契約)に分かれます。受託開発(請負型)は成果物と対価を結びつける考え方、ラボ型開発(準委任契約)は一定の稼働に対して対価を支払う考え方であり、同じ「開発」でも見積もりの作り方が異なります。

ベトナムオフショア開発の現状はどうなっている?

現状は、市場全体の平均値として捉えるよりも、自社が比較する前提に当てはめるほうが判断に使いやすくなります。外部環境についての説明を読むときも、対象工程や契約形態といった前提が示されているかを確認すると、自社の検討に使える情報かどうかを見極めやすくなります。

検討の背景として押さえておきたい視点

DX推進で扱う範囲は、部門単位の改善から基幹業務や業務プロセスの見直しまで、案件によって異なります。社内だけで開発リソースを確保し続けるのが難しい場合は、外部パートナーを組み合わせる選択が取られます。AIによる業務自動化や、社内ナレッジを検索できる仕組みを依頼内容に含めるかどうかも、自社の課題に照らして決める項目です。

市場データを読むときの前提

現状を調べるとき、市場規模や平均単価のような数字を先に集めたくなります。ただし、それらの数字は対象工程や契約形態、チーム構成といった前提が異なるため、そのまま自社の見積もりの基準にはできません。国単位の基礎情報は、JETROのベトナムページのような公的機関の情報で確認できます。そのうえで、自社の要件と体制に当てはめて読むほうが、検討の材料として機能します。

費用相場はどのように決まる?

費用は一律の相場表で決まるものではなく、単価と工数に分けて考えると比較の軸が見えてきます。単価は「誰が、どの契約で、どのくらい関与するか」、工数は「何を、どこまで決めてから始めるか」で変わります。同じ成果物でも前提が違えば金額は動くため、見積もりの前提をそろえることが比較の土台になります。

単価を左右する要素

単価を左右するのは、必要となるスキル、BrSE(ブリッジSE)の関与の度合い、契約形態の3点です。言語やフレームワークの経験、AI関連の知見など、求める技術が変わるほど単価も動きます。受託開発(請負型)は成果物と対価の関係が明確な一方で、仕様変更には別途の合意が必要です。ラボ型開発(準委任契約)は稼働に対して対価を支払う考え方で、仕様を変えながら進めたい場合に選択されます。

工数を左右する要素

工数を左右するのは、要件定義の深さ、スコープの広さ、非機能要件の扱いです。要件定義が浅いまま開発に入ると、後半の手戻りとして工数に現れます。性能、セキュリティ、運用といった非機能要件は、後から追加するほど影響が大きくなります。見積もりを読むときは、金額の横に「何が含まれていないか」を書き出しておくと、あとで突き合わせられます。

比較軸確認する内容見積もりの前提としてそろえる点
契約形態受託開発(請負型)かラボ型開発(準委任契約)か変更時の扱いと対価の考え方
単価の考え方どの職種・スキルが、どの期間関与するか想定する役割と関与の度合い
工数の見積もり方どの工程をどこまで含むか要件定義・設計・実装・テスト・運用の範囲
変更時の扱い仕様変更をどう合意するか起案から承認までの流れ

4つの項目がそろっていない見積もりは、金額だけを取り出しても比較の意味を持ちません。まず前提をそろえ、そのうえで差が出た理由を確認する順序が有効です。

開発会社はどう選ぶ?比較するときのチェックリスト

選び方は金額の大小ではなく、前提をそろえて比べられるかで決まります。同じ要件を同じ前提で提示し、どこに差が出るかを確認します。差が出た理由を言葉にできる会社は、進め方の説明も期待できます。

契約形態で比べる

完成形がある程度固まっている場合は受託開発(請負型)、仕様を変えながら継続的に改善したい場合はラボ型開発(準委任契約)が候補になります。判断の軸は、要件がどこまで確定しているかと、体制をどこまで自社で持つかです。契約形態が異なる見積もりを並べても、金額の比較にはなりません。

体制とコミュニケーションで比べる

窓口の言語、BrSE(ブリッジSE)の有無、レビューと報告の頻度、要件定義の進め方を確認します。担当者が変わったときの引き継ぎ方法や、課題を共有する場の持ち方も確認しておくと安心です。「日本語が話せる」だけでなく、仕様の確認をどの言語で、どの文書で行うかまで決めておきます。

品質保証(QA)と保守運用で比べる

テストの方針(手動テストから自動化まで、アジャイルテスト、受け入れテスト)と、保守運用の範囲を確認します。品質と情報セキュリティについては、開発プロセスが文書化されているか、レビューの記録が残るかといった点が手がかりになります。当社はISO取得に向けて品質・情報セキュリティのプロセスを整備中です。

比較のときは、次の項目を同じ表に書き出しておくと、抜けを減らせます。

  • 契約形態(受託開発(請負型)/ラボ型開発(準委任契約))
  • 窓口の言語と、BrSE(ブリッジSE)の有無
  • 要件定義の進め方と、決めた内容の残し方
  • レビューと報告の頻度
  • テストの方針(手動テストから自動化まで、アジャイルテスト、受け入れテスト)
  • 保守運用の範囲
  • データの取り扱いと秘密保持契約(NDA)の範囲

見積もりと契約前に確認すべき項目は?

見積もりをもらってから比べるのではなく、依頼する前に前提をそろえておくと、比較の精度が上がります。要件の棚卸しから始めて、範囲と変更ルールの合意で終える流れが基本です。

  1. 要件の棚卸し:対象となる業務と、解決したい課題を書き出す
  2. 前提条件の明文化:契約形態、期間、体制、想定する技術を文章にする
  3. 見積もり依頼:同じ前提を同じ形式で複数社に渡す
  4. 項目ごとの比較:金額に加えて、含まれる工程と含まれない工程を突き合わせる
  5. 範囲と変更ルールの合意:追加や変更の起案から承認までの流れを決める

見積もりで確認する項目

前提条件、含まれる工程、含まれない工程、追加変更の扱い、テストと受け入れテストの基準。とくに「含まれない工程」は見落としやすく、あとから追加費用として現れます。テストの完了条件と、受け入れテストの判定者を先に決めておくと、進捗の判断基準がはっきりします。

契約前に決めておく項目

秘密保持契約(NDA)の範囲、成果物の扱い、データの取り扱いルール、連絡体制と頻度。誰がどのデータに触れるかを決めておくことが出発点になります。法令や規制への対応が前提となる案件では、社内の担当部門や専門家の確認を経てから進めるのが安全です。

自社に合う開発会社を選ぶ進め方

比較の前提がそろったら、次は実際の進め方を決めます。対象範囲の絞り方と、社内で説明できる形へのまとめ方の2点から考えると、進め方の輪郭が見えてきます。

MVP(実用最小限の製品)から小さく試す

対象範囲を絞り、検証したい仮説を決めてから依頼すると、本開発に進むかどうかを判断する材料がそろいます。例えば、社内の問い合わせ対応を自動化するという場合、まずは一部の業務に限定して試し、効果と進め方の相性を確かめる方法があります。この場合も、要件定義と受け入れテストの基準を先に決めておくことが欠かせません。

当社はソフトウェア開発をはじめ、Web開発、モバイルアプリ開発、AI/MLソリューション、QA/テスト、クラウドサービス、組み込みソフトウェアといった領域を扱っています。小さく試す段階でも、その後の拡張を見据えて相談できるかどうかが判断材料になります。

社内で説明できる形にまとめる

稟議書にそのまま使える形として、「前提」「比較軸」「判断理由」の3行を用意しておくと、説明の材料がそろいます。例えば、「前提:契約形態はラボ型開発(準委任契約)、対象範囲は問い合わせ対応の一部」「比較軸:単価の考え方、工数の見積もり方、QA体制」「判断理由:要件定義の進め方が明確で、変更時の合意ルールが示されている」という形です。社内で数値を示す場合は、出典が確認できる数字に限ると安全です。

まとめ

ベトナムオフショア開発は、場所と契約形態を分けて捉えると整理しやすくなります。費用は一律の相場ではなく、単価と工数に分けて読むことで比較の前提がそろいます。開発会社を選ぶときは、金額の前に、要件定義・体制・品質保証(QA)・保守運用の前提を突き合わせることが判断の土台になります。現状の情報は、公的機関の情報と自社の要件の両方に当てはめて確認する進め方が有効です。

MK1 テクノロジーベトナムは、2020年7月にベトナム・ハノイで設立し、20名以上の体制で100件以上のプロジェクト実績を重ねてきた開発会社です。

自社の場合にどの契約形態が合うか整理したい場合は、お問い合わせからご相談ください。

FAQ

ベトナムオフショア開発の費用相場はどのくらいですか?

費用は一律の相場で決まるものではなく、単価と工数に分けて考えると整理しやすくなります。単価は必要なスキルや契約形態、工数は要件定義の深さや非機能要件の範囲で変わります。まずは同じ前提で複数社から見積もりを取り、比較できる形にそろえることが有効です。

受託開発(請負型)とラボ型開発はどう使い分ければよいですか?

完成形がある程度固まっている場合は受託開発(請負型)、仕様を変えながら継続的に改善したい場合はラボ型開発(準委任契約)が向いています。判断の軸は、要件がどこまで確定しているかと、体制をどこまで自社で持つかです。発注側の意思決定のスピードも前提に含めて考えると選びやすくなります。

開発会社を選ぶときに最初に確認すべきことは何ですか?

要件定義の進め方、コミュニケーションの体制、テストと保守運用の範囲の3点から確認すると比較しやすくなります。見積もりの前提がそろっていないと、金額だけでは判断できません。確認した内容は社内の比較表に残しておくと、検討を説明しやすくなります。

小規模な範囲から依頼することはできますか?

対象範囲をMVP(実用最小限の製品)に区切り、検証したい仮説を決めたうえで見積もりを依頼する進め方が一般的です。範囲が小さいほど、要件定義と受け入れテストの基準を先に決めておくことが大切になります。

セキュリティ面はどう確認すればよいですか?

契約前に、情報の取り扱いルール、アクセス権限の管理、開発環境の分離方針を確認します。あわせて、秘密保持契約(NDA)の範囲や、開発プロセスが文書化されているかも確認しておくと判断材料になります。

参考文献