「ITエンジニア不足で新規システム開発が全く進まない」
「国内のSES（客先常駐）に依頼しても合致する人材が見つからず開発チーム構築に時間がかかっている」
深刻化するITエンジニアの不足、そんな課題を抱えている日本企業にとって、ベトナムをはじめとした「オフショア開発」は強力な解決手段でもあります。
しかし、いざ検討を始めると「自社の作りたいシステムはオフショアで本当に対応できるのか？」「どんなシステムなら安心して任せられるのか？」と踏み止まってしまう方も多いのではないでしょうか。
本記事では、オフショア開発において日本企業の利用が一番多いベトナムを対象に、現在のベトナムオフショア開発が「得意とするシステム開発（向いているもの）」と「不得意とするシステム開発（向いていないもの）」を分かりやすく解説します。
1.オフショア開発の「得意分野」
一口にベトナムのITエンジニアといっても何十万人もおり、エンジニアや開発会社によって能力のばらつきや得意とする分野の違いは、非常に大きいものがあります。
しかしながら、一般論でいうとベトナム人ITエンジニアは、最新技術へのキャッチアップが非常に早い（ITエンジニアの向上心が旺盛である）という特徴があります。その背景にあるのは、日本以上に給与格差が大きいことにあります。
| Location | Fresher | Junior | Middle | Senior | Leader/Manager | Director/Architect |
|---|---|---|---|---|---|---|
| Ho Chi Minh | $390 | $815 | $1,216 | $1,708 | $2,083 | $2,771 |
| Ha Noi | $380 | $808 | $1,128 | $1,482 | $1,652 | $2,200 |
| Da Nang | $380 | $805 | $1,126 | $1,327 | $1,550 | No data |
TopDev社「VietnamITMarketReport2024_2025_VietnamITTechTalentLandscape」より
上記は、TopDevという求人メディアを運営している会社が出したレポートによるものですが、一番左のFresher人材とLeader/Managerクラスとの間の給与格差は、ホーチミンで約5.4倍の差があります。ハノイやダナンでは4倍ちょっとまで落ち着きますがそれでも大きな格差です。
日本、例えば東京などでITエンジニアにおける新卒の給与が月収25万円だとして、Leader/Managerクラスが月収100〜135万円もらっているかというと、そういったケースはほぼない（あっても稀）でしょう。
ベトナムでITエンジニアは、スキルを高めることで短期間で給与を大きく上げることができる環境があり、会社が評価してくれない場合は他社（特に欧米などの外資企業）へ転職して評価を得る人も多いため、特に外資企業など選択肢の多いホーチミンの若手ITエンジニアにおいては、より高い報酬を得るため自ら日々スキルアップを図っています。
このような環境下であるため最新の技術（モダンな開発手法）を身に着けたITエンジニアが比較的多く、彼らを組織し開発チーム構築がしやすいといえます。
そしてこれを踏まえると、以下のようなシステム開発が得意と言え、日本国内以上のパフォーマンスを期待できると言えます。
1-1.新規事業におけるMVP開発
要件を最初から完璧に固めるのではなく、まずは最小限の機能（MVP=Minimum Viable Product）で市場に出し、実際にユーザーに触ってもらってから、その感想を元に素早く改善していきたい。
こうした新規サービスの立ち上げには、オフショア開発が非常に向いているといえます。
なんとなくのイメージを素早く形にし、走り出しながら方向性を決めていく柔軟な開発方法、新しい技術をどんどん取り入れてモダンな開発を進めていくやり方。ベトナムの若く機動力のあるエンジニアチームの大きな強みが活きる開発内容となります。
1-2.R&D（研究開発）の実施
製品化（商品化）できるかどうかわからないけど、アイデアを元にまずは形作ってみる。もちろん実際に作ってみたら、イマイチだったのでその案は没にしてまた別のアイデアで試してみることも十分にあり得る。これを何回、何十回と繰り返して行く中で、良さそうな結果が出れば、製品化（商品化）へと開発を進めていく。
このような試行錯誤を繰り返すケースにおいてもベトナムオフショア開発が得意とする領域で、実際に弊社への開発依頼においても、こういったR&Dでのご利用は多いです。
1-3.PoC（概念実証）の実施
AI開発などにおいては、「事前に精度〇〇%のAIモデルを必ず完成させる」と約束して進めることは困難となります。なぜなら実際に作ってみてからでないと、どのような精度となるのかが分からないためです。
よってまずはデータを投入してAIモデルを作り、評価・再学習（チューニング）を繰り返していくことでAIモデルを作っていくことになります。この工程をPoC（Proof of Concept、概念実証）と呼びますが、これもR&Dと同様にベトナムオフショアへご相談いただく事が多い開発内容です。
1-4.短期間で人数の多い開発チーム構築が必要となるもの
日本国内のSESやニアショアなどにおいては、ITエンジニアの人手不足という環境もあり、PM、フロントエンド、バックエンド、テストエンジニアなどを「短期間かつ同じタイミングで一気に集める」のは、なかなか難しいと考えられます。特に特定のスキルや経験を持った人材となるとなおさらです。
一方でIT人材が豊富なベトナムのオフショア開発であれば、役割分担された専属チームを丸ごと迅速に構築しやすい環境にあります。最初からまとまった開発リソースとスケーラビリティが必要な自社プロダクト（SaaSなど）の開発を得意としています。
2.オフショア開発の「不得意分野」
一方で、物理的な距離や言語・文化の壁、そして契約上のミスマッチが起きやすいと考えられる以下のようなプロジェクトにおいては、オフショア開発に不向きとも考えられます。
2-1.仕様書が全くなく、暗黙知に依存するレガシーシステムの改修
「長年使っている社内システムを刷新したいが、設計書が残っておらず、業務フローは担当者の頭の中にしかない」。
こうした案件を人手不足を理由に丸っとオフショアに依頼するのは、依頼側にとってもそれを受託する開発会社側にとってもリスクが高いと考えられます。
「言わなくても分かるだろう」「日本の商慣習ならこう動くはず」といった暗黙知は、外国（オフショア）の日本人ではないエンジニアには伝わらないため、手戻りが大量に発生する原因となります。
こういったプロジェクトの場合、例えば日本国内の発注元のオフィスに常駐してもらい、業務フローなどを分析して要件を一緒にドキュメント化していくといったやり方が考えられますが、そうなるとオフショア開発よりもSESなどの方が望ましいと考えられます。
2-2.特殊な専用ハードウェアと密接に連携するシステム
オフショア開発では、IoTデバイスとのデータ連携などは得意であるものの、日本国内の特定の工場や現場にしかない「実機（特殊なハードウェア）」に直接接続もしくは組み込んで、物理的なテストを繰り返す必要があるソフトウェアにおいては、難しいことが多いです。
その理由は、オフショア側で完結しようとする場合、機材を日本国外へ輸送・輸出し、開発完了後に返送（日本へ再輸入）する必要があるからです。これには、各種手続きなどが必要となり、輸送費に加えて場合によっては、税金や外部の手続き代行会社に支払う費用なども発生してしまいます。
なお小型で法規制上も問題の生じないような機材、例えば日本でしか販売されていないスマートフォンの様な機材であれば、出張時と合わせてハンドキャリーという方法も実務ベースでは、よく利用されていますが、この場合はタイミングなども限られます。
こういったケースにおいて開発（実装）や、PC上で動作するシミュレータ上でのテストまではオフショアで行うものの、実機検証部分だけは日本側（例えばSESなどを活用）で行うといった連携型で実施するか、最初から日本国内だけで完結する開発方法が望ましいと言えます。
2-3.日本国内での開発が必須または、注意が必要なもの
日本の官公庁に関係するシステムであったり、日本の補助金を使って開発するようなソフトウェアの場合、条件として日本国内での開発が必要となっている場合もあります。これは全てがそうだという事ではなく、内容によっては「そういった条件が付いていることもある」というものです。
特に補助金の場合、せっかく補助金対象に採択されても日本国外にあるオフショアの会社に委託して開発した場合、条件を満たせず対象外となってしまうケースもありうるため、事前に補助金の条件を確認しておくことが必要となります。
また個人情報を扱うシステムの場合、どこまでを海外にあるオフショア開発会社の方で扱うのかについて、ユーザーに対して提示している規約や個人情報の取り扱いポリシーと照らし合わせを行い、事前に問題ないか確認するといった注意が必要です。
3.オフショア開発の得意を活かすには、作りたいシステムに合わせた「契約形態」の使い分けが必要
「オフショア開発で作れるシステムにおける得意・不得意」は、どのような開発契約形態で進めるかによっても大きく変わります。
それゆえ作りたいシステムに合わせて、以下の2つの契約形態から適した方を選ぶのが望ましいと考えられます。
3-1.請負型開発（受託開発と呼ばれることもある）
事前に決めた仕様を満たした成果物に対して、対価が支払いされる契約形態です。
既存の社内基幹システムの刷新（リプレイス）や、古い言語から新しい言語へのマイグレーション（移行）プロジェクトなどにおいて「現行システムと同じ仕様・同じ業務フローを新環境で再現できればよい」というプロジェクトであれば、途中で仕様が変わることがなく、成果物が明確です。
キャンペーン用のランディングページ（LP）制作、単発の小規模な社内管理ツール開発、特定のAPI連携モジュールの開発など、開発期間が数日といった1ヶ月にも満たないものから、最大でも3ヶ月程度と短く、納品後の継続的な機能追加や頻繁なアップデートを前提としていない単発の開発プロジェクトにおいては、最適な形態です。
3-2.ラボ型開発（準委任型契約）
開発エンジニア（開発リソース）の「稼働時間」を保証する形態です。この契約形態を用いて、一定期間とエンジニアの人数を確保し、自社専属の開発チームを構築できます。
新規事業のプロトタイプ、研究開発（R&D）、AI開発、PoC、継続的な機能改善を伴うWeb・アプリ開発など、開発する内容が途中で変わるシステムにおいては、最適な形態です。
なお、請負型とラボ型の違いについては、以前の記事「オフショア開発での請負型とラボ型の違い｜成功企業が実践する体制の選び方を解説」により詳しく書いていますので、こちらもご参考ください。
注意すべき点として、開発途中で仕様変更が頻繁に発生する新規サービスを、完成責任を負う「請負型開発」で依頼すると、変更のたびに再見積もりやスコープの交渉が発生し、プロジェクトが頓挫しやすくなります。
これは本来オフショア開発で「得意」であったはずの開発内容が、契約形態の選択ミスにより「不得意」となってしまうケースです。こういったことを避けるためにも、仕様が変わる前提の開発では、「ラボ型」で進める必要があります。
