日本国内の会社が何か開発をしたい、しかし開発するためのエンジニアは足りない・・・
このような日本国内の会社が開発リソースを確保したいと考えたとき、比較対象になりやすいのが「海外オフショア開発」と「日本国内SESの活用」です。
どちらも外部のエンジニアリソースを活用する方法ですが、契約形態、進め方、コストの考え方、管理に必要な工数は大きく異なります。
特に「コスパ」を考える場合、単純な人月単価だけで比較してしまうと、実際の開発スピードや管理負担、成果物の品質、長期的なナレッジ蓄積といった重要な要素を見落としてしまうことがあります。
この記事では、ベトナムでのオフショア開発支援に携わってきた実務上の視点も踏まえながら、日本国内SESとベトナムオフショア開発の違いを整理します。
自社の開発体制やプロジェクトの性質に照らして、どちらを選ぶべきか判断するための参考にしていただければ幸いです。
◆本ページの目次
Toggleこの記事の結論|SESとオフショア開発はどちらがコスパ良いのか?
結論から言えば、日本国内SESとベトナムオフショア開発は、単純に「どちらが安いか」の金額面だけで比較すべきものではありません。
人月単価だけを見るとオフショア開発の方が安く見えやすい一方で、要件整理や指示出し、レビュー体制が不十分な場合は、管理工数や手戻りが増えて、結果的にコスパが悪くなることもあります。
一方で、目的や開発内容がある程度明確で、外部チームと中長期的に開発体制を作っていきたい場合は、ベトナムオフショア開発の方が高いコストパフォーマンスを発揮しやすいと言えます。
この記事で伝えたいポイントは、主に以下の5つです。
- SESとラボ型オフショア開発は、どちらも準委任型に近い契約形態で活用されることが多い
- SESは、日本語での細かなやり取りや曖昧な要件への対応に強みがある
- ベトナムオフショア開発は、モダンな技術人材の確保や開発チームの拡張性に強みがある
- コスパは人月単価だけでなく、管理工数・手戻り・開発スピード・ナレッジ蓄積まで含めて判断すべき
- 短期的な人手不足の補完ならSES、中長期的な開発体制づくりならオフショア開発が向いているケースが多い
SESとベトナムオフショア開発の比較表
| 比較項目 | 日本国内SES | ベトナムオフショア開発 |
|---|---|---|
| 契約形態 | 準委任契約が中心。エンジニアの稼働や技術提供を前提とする。 | 請負型もあるが、現在はラボ型など準委任型に近い契約も多い。 |
| 主な目的 | 既存プロジェクトへの人員補充、短期的な開発リソース確保に向いている。 | 外部に専属開発チームを作り、中長期で開発体制を強化する用途に向いている。 |
| コスト構造 | 多重下請け構造がある場合、各階層の手数料が上乗せされやすい。 | 人月単価は比較的抑えやすいが、ブリッジ・管理・レビュー体制の設計が重要。 |
| 技術トレンドへの対応 | レガシーシステムや既存業務システムの保守・改修に強いケースが多い。 | 若手エンジニアを中心に、モダンなWeb技術やクラウド技術への対応力を期待しやすい。 |
| コミュニケーション | 日本語で細かなニュアンスを伝えやすく、曖昧な指示でも進めやすい場合がある。 | 曖昧な指示はズレにつながりやすいため、要件整理や仕様化が重要になる。 |
| 管理工数 | 日本語や商習慣が通じやすく、管理負担を抑えられる場合がある。 | 体制設計が不十分だと、レビュー・修正指示・認識合わせの工数が増える可能性がある。 |
| 開発開始までのスピード | 面談や人材選定に時間がかかる場合がある。 | 開発会社側でチーム提案ができる場合、比較的早く開始できることがある。 |
| 人材の拡張性 | 必要な人材が市場にいない場合、追加確保に時間がかかる。 | 一定規模の開発会社であれば、増員やチーム拡張に対応しやすい。 |
| ナレッジ蓄積 | プロジェクト終了後にエンジニアが離任すると、知識が残りにくい場合がある。 | 同じチームを継続することで、プロダクト理解や開発ノウハウを蓄積しやすい。 |
| 向いているケース | 要件が曖昧、現場で細かく調整したい、既存システムの保守・改修を進めたい場合。 | 目的が明確で、外部チームと継続的に開発体制を作りたい場合。 |
| 注意点 | 多重下請けによるコスト増、責任範囲の曖昧さ、技術力の見えにくさに注意が必要。 | 単価だけで判断せず、要件整理・ブリッジ体制・品質管理まで含めて見る必要がある。 |
使い分けの目安
| 状況 | 向いている選択肢 |
|---|---|
| 要件がまだ曖昧で、会話しながら進めたい | 日本国内SES |
| 既存のレガシーシステムを保守・改修したい | 日本国内SES |
| 日本語の細かなニュアンスを重視したい | 日本国内SES |
| モダンなWeb開発やアプリ開発の体制を作りたい | ベトナムオフショア開発 |
| 開発チームを中長期で維持・拡張したい | ベトナムオフショア開発 |
| 人月単価だけでなく、将来的な開発体制の投資対効果も重視したい | ベトナムオフショア開発 |
| 短期的に足りない人員を補いたい | 日本国内SES |
| 自社プロダクトに詳しい外部開発チームを育てたい | ベトナムオフショア開発 |
それぞれを詳しく掘り下げていくので、お時間ある方はぜひ最後までお付き合いください。
1. 契約形態上、実は同じ?日本国内のSESとオフショア開発

まずSESですがSystem Engineering Serviceの略となり、契約期間中に顧客に対してエンジニアの技術力やスキルといった労働力を提供する形態です。契約上では、「準委任契約」という業務の遂行を約束した契約形態となります。
簡単に言えば、エンジニアが顧客企業へ行って常駐し月何時間働くことを約束するものの、稼働時間を通じて開発するソフトウェアという成果物自体に対しては、契約上の責任は負わない(ただし最低限の善管注意義務は負う)という形です。
似たような形態として派遣契約がありますがSESとの違いは、「エンジニアに対して仕事をする時間や場所といった指揮命令権を誰が持つか」になります。
派遣の場合は、顧客がエンジニアに対して直接指揮命令をすることになりますが、SESの場合は、顧客には指揮命令権が無くSESサービスの提供企業が指揮命令権を持つことになります。よって顧客側に何か要望がある場合は、エンジニアに直接指揮命令できず、SES企業に伝えて、SES企業からエンジニアへ伝える(指揮命令する)形となります。
次に日本国外で開発を行うオフショア開発ですが、契約形態として成果物に対して責任を負う請負型と、準委任型の契約形態であるラボ型があるものの、弊社も含めて現在、オフショア開発で主流、契約が多いのはラボ型となります。
よって契約形態が「準委任型契約」であるという点においては、オフショア開発もSESと同じであると言えます。
では2つの開発手法では何が異なるのでしょうか。その為にも日本におけるSESについてより深堀してみます。
2. SESは、どのように活用されているのか?
開発においてSESが利用されている事例を1つ挙げるとするなら、「大規模業務システム・公共インフラの開発プロジェクト」があります。
例えば、銀行のシステム統合、官公庁のデジタル化、大企業の基幹システムのリニューアルなど、ウォーターフォール型(最初に完璧な計画を立てて、前工程が完了してから次の工程へと順次進んでいく形態)で進む、長ければ数年単位でかかるような大規模開発です。
何層もの下請け会社が入って開発を進めることが多いことから、SIer案件などとも言われたりするプロジェクトです。
まず発注元の会社から開発全体を一括で受注する元請け会社として、SI(システムインテグレーション)会社が入ります。この会社では要件定義やプロジェクト全体の管理などを担当するものの、プログラミング自体をすることは少ないとされています。
具体的なプログラミングなどを行うのは、SI会社から仕事を受ける2次請け会社以降となります。開発の内容や規模によっては、ここに中堅規模のSI会社が入ることもあり、詳細設計や実装を行っていきます。
さらに2次請け会社から一部の業務を委託される3次請け会社やさらにその下で請け負う会社などもあり、孫請け、ひ孫請けといった言葉を聞いたことがある方もおられるでしょう。
こういった多重下請け構造の中の各レイヤーで多用されているのが、SESによる開発リソースです。
そもそも、なぜこのような多重下請け構造が存在するのでしょうか?これには4つの理由があるとも言われています。
①多重下請け構造の理由:日本の解雇規制や雇用の調整弁
これは開発に限らずですが、忙しい時は多くの人手が必要な一方で、ピークが過ぎた後や完了後は、人手が不要になるという事があります。しかし日本では法規制上、忙しくなくなったからという理由だけで正社員を解雇することはできません。社員の側としても、そう簡単に解雇されてしまうと生活の見通しが立たず困ることになります。
よって企業側としては、自ら大量に雇用するのではなく、必要な時に下請け会社を活用する、SESを通じた開発リソースを確保する、このような方法が合理的になります。よってSESは、雇用の調整弁として機能しているとも言えます。
②多重下請け構造の理由:取引を実現するための信用力
大企業などがシステム開発を外部へ依頼する場合、過去の取引の有無、開発実績やその内容、営業年数、外部認定(ISMSやプライバシーマーク等)の有無、資本金額、場合によっては、過去の損益(黒字かどうか)などの開示を求めることがあります。そしてこれらにおいて大企業側が設定している基準を満たさない場合、そもそも直接取引はできない場合があります。
それゆえ、基準を満たした元請けから発注してもらい、下請けという形でプロジェクトに参加するしかない場合があります。
③多重下請け構造の理由:比較優位~営業力と開発力~
元請けの会社には、前述の様に大企業と取引をするための信用力に加えて、大企業を開拓するための営業力という強みがあります。そしてプログラミングをする開発者自体は少なかったとしてもプロジェクト全体の管理能力という点において強みを持っています。
一方で2次請け以降の会社には、元請けの様な大企業開拓の営業力や管理能力が無かったとしても、実際に手を動かして開発する開発力があることを強みとしています。また特定の技術分野にのみ特化して、それを強みとした会社もあります。
各自が相対的に得意な分野に特化して分業すれば、それぞれの生産効率が高まり、利益が最大化される「比較優位」という考え方があり、このような構造が必要とされている側面もあります。
④多重下請け構造の理由:手数料という儲かる構造
通常、下請けに発注する場合は下請けから上がってくる見積金額に対して手数料を上乗せした金額で、より上位の会社と契約することになります。
例えばエンジニアが1ヶ月稼働する際の契約金額は、3次請け会社で60万円であった場合、2次請け会社では、60万円+手数料の80万円という金額で元請け会社と契約し、元請け会社では、80万円+手数料の100万円という金額で発注元と契約するという形です。
これは単に「中抜き」で悪いことの様にも見えますが、各社ともに下請け会社の仕事分に対して連帯して責任を負っている以上、その分で何らかの収益(手数料)が得られなければ、割に合わないという理由があります。
しかしながら程度によるものの、右から左へと流すだけで手数料分のマージンを抜くことができる、リスクが顕在化しなければうまみが大きいこともまた事実である為、儲かる構造としてこのような多重下請けが必要とされている側面があります。
しかしこのような多重下請け構造によって、
・下層のSESで働く労働者ほど労働環境が悪化し低賃金である
・責任の所在が曖昧となり、末端のエンジニアに責任が押し付けられやすい
・発注元の意図が1次、2次、3次と経由するにしたがって正しく伝わらない伝言ゲームの発生
・上位は管理ばかり行うため、技術力の空洞化
という弊害も指摘されています。
では、以上で見てきたSESと、ベトナムで開発を行うオフショア開発(ラボ型開発)を比べた場合、どういう違いが見えてくるのでしょうか?
3.SESとオフショア開発の比較する5つの視点
2つを比較するため、コスパに関わる異なる5つの視点でSESとベトナムオフショア開発とを比べて見ます。
「多重下請け構造の手数料」という視点
既に述べてきた様にSESが多重下請け構造となっている場合、各階層で手数料が載っている分、同じスキルのエンジニアであってもより高い単価を払っていることになります。
もっともこの点は、オフショア開発においても委託先の会社で、同様のことをするのであれば、同じことでもあります。
しかしながら一般的にベトナムオフショア開発(ラボ型)においては、1回目の再委託(元請け⇒一部業務を2次請け)という話は聞いても、日本のSES業界で言われるような多重下請け構造という話はあまり聞きません。
よってオフショアかSESかを問わず、多重下請けの少ない方が比較的コスパが良いと考えることもできそうです。
「技術トレンドへの適応力」という視点
日本の多重下請け構造の中でSESは、レガシーなシステムの開発・保守案件などが多いことから、そういった開発に適したエンジニアが比較的多いと考えられます。
もちろん新しい技術、例えばクラウド技術(AWS、Azure、GCP)やWeb系のモダンな言語(React, Goなど)に長けた人材もいますが、比較的高単価であり、奪い合いとなるため人材の供給力という点では若干劣るのではないかと考えられます。
一方でベトナムの若手エンジニアは、最新の技術トレンドの習得に貪欲であり、それを身に着けたエンジニアが毎年の様に供給されている環境があります。
その背景には、そういったスキルを身に着けた場合、短期間で給与が2~3倍にもなるような給与格差が日本以上に大きい環境であること、及びそういうエンジニアを市場価値に応じた高い給与で雇用する欧米企業や中国・韓国・アジアといった企業が多数存在するためです。
よって同じ予算を出した時、どちらがよりモダンな技術力のあるエンジニアをアサインできるかという点で考えるなら、ベトナムオフショアの方に「技術面でのコスパ」という軍配を上げることができるのではないでしょうか。
「見えない費用発生の可能性」という視点
日本国内のSESで日本人もしくは日本語ネイティブなエンジニアがアサインされる場合、日本的な曖昧さ、文脈、背景、暗黙の了解、人間関係などを元にしたハイコンテクストな指示であっても、比較的、意図したことが伝わる可能性があるという点にあります。(もちろんそれで失敗するケースもありえますが、可能性についてでいえば、上手くいく場合がそれなりにあり、SESはそこが評価されているサービスであるとも言えましょう。)
そしてそれが実現することで発注元のPMにおいては、細かいところまで網羅した指示、例えば仕様書を書かなくても済むため、PM自身の稼働コストが最小限で済むという大きなメリットが生まれます。
一方でオフショア開発の場合、ブリッジ人材という日本語が話せる役割を挟んだとしても、相手は日本人では無いため、日本人の様に曖昧さを正しく汲み取ってはくれていない可能性が高く、結果、認識のずれによって発注元の管理工数の増大や手戻りが多発することが考えられます。
そのため人月単価だけで見た場合、オフショアの方が安かったとしても日本(発注元)のPMがレビューや修正指示に忙殺され、見積書では見えなかった費用が増大し、結果的に国内SESよりも高くついたという話は、オフショア開発における失敗事例として良く語られるケースでもあります。よってこういったケースでは、SESの方がコスパが良いと言えるのかもしれません。
しかしSESでこれが成り立つのは、曖昧な指示であっても意図を正しく汲んでくれるという日本人(かつアサインされた人がそういう人材であった)という前提があるからです。
日本では現在、恒常的な人手不足の環境下にあり、IT人材であればなおさらです。その為、日本国内にいる外国籍人材のSESも増えています。
曖昧であっても察してくれて意図を正しく汲んでくれる様な人材であれば、価値が高いと評価されて契約金額が高くなっていく、特に最近のインフレや人材の奪い合いも考えるなら十分に考えられる話です。
よって(コスパの前提となる)今まで通りの単価で、曖昧さが通じ続けるのかは、不確実であるともいえます。
「開発リソース調達スピードと機会損失(機会費用)」という視点
日本国内でSESを利用しようとする場合、面談という機会を挟むことになります。発注元である顧客から見て、SESで来るエンジニア候補と顔合わせをしてスキルをチェックし、開発プロジェクトとのマッチングを確認します。
技術力に加えてコミュニケーション能力や現場への適応力などを判断する機会でもあります。その為、発注元において合致する人材を見極める力が必要となりますし、最適な人材がいない場合は、複数のエージェントを跨いで人材を探し回るため、選定完了までに時間がかかる可能性があります。
この時間がかかっている分だけ開発完了が遅くなることになるため、顧客から見ると機会損失(機会費用)が発生していると言えましょう。
一方でオフショア開発の場合は、会社によって違いはあるものの通常、ある程度の実績や規模のある会社でその会社の技術標準と合致する開発であれば、その会社として責任をもって開発の完遂ができると考えられる人材を即座に提案できる(スキルシートなども共有できる)ことが多いです。
それゆえSESの様に面談を繰り返していく、複数の会社を使って人材を探し回るのと比べれば比較的早く開発を開始できる=機会費用が小さいと表現できるのではないでしょうか。
またこれは開発開始時だけでなく、開発途中で一時的にエンジニアの増員が必要となった場合においても同じことが言えます。
開発内容によっても変わりますが、必要な時にすぐ開発を始められ、開発リソースの追加投入も容易であり、結果、素早く市場にプロダクトを投入できるというスピード感は、ビジネス全体で見た時の視点においてコスパが良いと表現できるかもしれません。
「ナレッジ蓄積の価値をどう評価するのか」という視点
会社によっても異なりますが、SES利用で多いのはプロジェクトの開発期間とあわせて契約し、終了すればSESで来ているエンジニアが離任する形であると聞きます。
追加開発などでプロジェクトを再開する時に、1度離れた同じエンジニアが再びアサインされる可能性は、ちょうどそのタイミングで空いていない限り低いとも考えられます。よって開発を通じて培われたノウハウなどは、SES終了と合わせて消失するとも言えるのではないでしょうか。
オフショア開発のラボ型では、専属の開発チームを長期にわたって維持することで所属会社の違いはあれど、「顧客の仮想的な開発部門」という位置づけで考えてもらう、ラボ型とはそういう商品であることを打ち出している会社が多いです。
中長期間、同じチームがプロダクトを担当し続けることで、そのプロダクトに関するビジネス知識や開発ノウハウが蓄積されることになり対応能力、生産性が向上していく。
こういった点をどう評価するのかは、顧客のビジネスによっても変わりますが中長期で考えて「自社プロダクトに熟知した開発組織への投資」という側面を評価するのであれば、オフショアの方がコスパが良いと言えるのかもしれません。
4. コストパフォーマンス(コスパ)という視点で総括するなら・・・
最後にまとめると以下の様な結論が出てきます。
◆日本国内SESの方が高いコスパがあると考えられるケース
レガシーなシステムの開発対応、要件がはっきり固まっていない、仕様に変更なども多く、曖昧な点も多い。そういった点をオフィスで一緒に仕事をしながら、日本語による会話のニュアンスなどから読み解いて進めて欲しいというケース。
◆ベトナムオフショア開発の方が高いコスパがあると考えられるケース
課題や、なぜやるのかなどが明確であり、自社の外であってもモダンな技術とスピード感を持った人材がいる開発チームを作りたい。
そしてそういった開発チームの価値を中長期的な視点で評価したいというケース。
以上から分かることは、単に人月単価だけを見て高いか安いかの比較でコスパを考えるのではなく、自社の希望やプロジェクトの性質に合わせて両者をうまく使い分ける(あるいは組み合わせる)ことこそが、最も高いコストパフォーマンスを実現する=コスパが良いと考えられるのではないでしょうか。

