エンジニア採用が決まらない会社の方へ
求人を1年出しても決まらない。ようやく採れても定着しない。SESの単価は上がり続ける。そういう状況でオフショア開発を調べ始めた方に向けて書いています。
先に立場を言います。オフショア開発を単価の安さで選ぶことには反対です。私たちはベトナムオフショア開発を社名にした会社ですが、そう考えています。理由を順に説明します。
採れないという前提から始まります
経済産業省が2019年に公表した「IT人材需給に関する調査」は、2030年のIT人材の不足を、需要の伸びなどの前提に応じて約16万人から最大約79万人と試算しました。中位シナリオでも約45万人です。
数字の幅は大きいものの、どのシナリオでも共通する結論があります。国内の採用だけで開発体制を賄う前提が、多くの企業で成立しないということです。
この前提に立つと、オフショア開発の位置づけが変わります。従来の「国内より安い外注先」ではなく、採用の代替となる人材供給の経路です。比較対象は他国の単価表ではなく、自社で採用した場合の充足の見込みになります。
なぜベトナムか
ベトナムを選ぶ理由は、労働力が安い国だからではありません。ITが基幹産業として育っている国だからです。
政府は「2025年までの国家DXプログラムおよび2030年までの方針」を掲げ、大学でのIT人材育成に注力しています。IT系学部を持つ大学の卒業生には、就職先として日本企業を選ぶ学生も少なくありません（JETRO・ベトナムのIT系大学と日本企業等との連携可能性に関する調査）。
産業としての立ち位置は、統計にも表れています。ベトナムの情報通信業は総資産利益率がサービス業で最も高く、下請け構造の産業ではありません。IT人材の給与水準は国内産業で2番目に高く、優秀な人材が集まる側の産業です。日本との時差は2時間で、日中の作業時間がほぼ重なることも、日々のレビューを回すうえで効いています。
つまり、ベトナムのIT人材は「安いから使う」対象ではなく、自国で最も競争的な産業に集まった人材です。この認識のずれが、次の失敗パターンにつながります。
単価で選ぶと失敗します
時間単価の比較でベンダーを選ぶと、構造的に次のことが起きます。
単価が安くても、要件の伝達に往復が増え、やり直しが増えれば、総額は膨らみます。管理の工数は発注側に乗るため、見積書には現れません。そして単価を一番の理由に選ばれたベンダーは、より安い競合が現れた瞬間に同じ理由で切り替え候補になります。切り替えを恐れるベンダーは価格を守るために体制を薄くし、品質が落ち、さらに切り替えが近づく。この循環に入ると、どちらも得をしません。
見るべきは単価ではなく、続けられる価格かどうかです。月額の総額で費用が読めるか。その金額に管理・レビュー・テストが含まれているか。担当者が変わっても体制が続くか。1回の開発の安さではなく、開発が続く前提での価格設計かを確認します。
安さは理由になりません
それでも、ベトナムの開発単価が日本より低いのは事実です。
ただ、それを選定理由の一番に置いた契約は、値上げ・離職・品質のどれかで壊れます。続いている体制は、価格以外の理由で選ばれています。
AIで実装が速くなっても人は要ります
「AIが実装を自動化するなら、オフショアで人を確保する意味はなくなるのではないか」という問いを最近よく受けます。
逆だと考えています。AIによって実装の速さそのものは差にならなくなりました。差になるのは、AIの出力を検証し、受け入れ、運用する人を安定して確保できるかです。生成されたコードをレビューする人、テストで挙動を確かめる人、本番で異常に気づく人。AIの活用量が増えるほど、この検証の総量も増えます。
だから私たちは、AIを使う開発プロセスと人材供給を別の話として扱いません。日本側PMが要件と受入基準を整え、ベトナムのチームがAIを使って実装し、レビューと受入で品質を確認する。AIネイティブな開発の進め方と、それを回し続けられる人の供給。この組み合わせが、どちらか片方より強いというのが私たちの立場です。
現場に入って実装まで担う働き方については、いま日本で広がっているFDEという職種の定義がそのまま参考になります。
単価表の代わりに聞く5つの質問
- 月額の内訳: 開発枠は何時間で、管理・レビュー・テストは含まれるか。単価×時間だけの見積もりは、管理コストが発注側に乗ります
- 引き継ぎの手順: 担当エンジニアが離職したとき、誰がどの記録を使って引き継ぐか。属人化した体制は単価が安くても高くつきます
- 受入基準を書く人: 日本語の要件と受入基準を誰が作るか。「御社で用意してください」なら、その工数も総額に足して比較します
- 記録の粒度: レビュー記録・開発記録がどの粒度で残るか。Pull Request単位で残る体制なら、後からの検証と保守が利きます
- AIの使い方と検証: どの工程でAIを使い、出力を誰がどう検証しているか。「AIで安くなります」だけで検証の説明がない提案は、品質確認が発注側に乗ります
相見積もりの比較表に、単価の行の代わりに足してそのまま使えます
順番だけ最後に
オフショア開発の検討は、ベンダー比較から始めないことを勧めます。先に自社側を整理します。採用で埋まらない役割はどこか。日本語で要件を書ける人が社内にいるか。受入の判断を誰がするか。
この整理ができていれば、ベンダー選びは上の5つの質問で足ります。できていなければ、どのベンダーを選んでも同じ場所で詰まります。
自社側の整理から相談したい場合は、お問い合わせからどうぞ。体制の設計と受入基準の作り方から入ります。ベトナムでの開発体制そのものはサービスページに分担と進め方をまとめています。