日本で深刻なIT人材の採用難やリソース不足の解消方法として注目されているオフショア開発。オフショア開発先の国によっては、現在の為替水準（円安）でもまだ、東京などと比べてコストメリットがある国も存在するため、コスト削減でオフショア開発を選ぶという企業もあるでしょう。
しかしせっかくオフショア開発を始めたのに上手くいかなかった、手直しやスケジュール遅延などで想定以上のコストがかかってしまったという失敗事例も少なくはありません。
今回の記事では、「よくある失敗パターン」「失敗の根本原因」「成功に変える発注者の心得」といった点について解説しますので、オフショア開発成功の可能性を高めるにあたって参考となれば幸いです。
1.オフショア開発でよくある失敗事例6選
ではどのようなケースで失敗する可能性が高いのか、代表的な6つの例を紹介します。
1-1.コミュニケーション不足による「認識のズレ」と手戻りの発生
失敗事例として一番多いのは、出来上がってきたソフトウェアが想定していたものと違う事が判明し、修正対応によりスケジュールが遅延、場合によっては追加で開発費用も発生した、もしくはその負担を巡ってオフショア開発会社（ベンダー）と揉めたというケースです。
発注者が開発を依頼した時点では、開発者にちゃんと伝わっていると考えていた（認識していた）ものの、実はそれが正しく伝わっていなかったもしくは、曖昧な箇所があったため、開発者は異なる形で解釈し、実装されてしまったという事があります。
例えば「この部分では、ユーザーから見て使いやすくして欲しい」という依頼である場合、「使いやすさ」というのはエンジニアの解釈によって異なります。
本来なら具体的に「どういう風にすると使いやすくするのか」を図などで示すことや、それが思い浮かばない場合、開発会社から案を受け取って発注者が選択をして、選択結果での実装を指示する必要があります。
しかしそれをせずに「使いやすく」と依頼したのだから大丈夫だろうと確認せずにいた場合、出来上がってきた開発者の考える「使いやすいもの」と発注者の考える「使いやすいもの」に認識の差が生じて、手戻りが発生する可能性が高くなります。
1-2.仕様変更多発による完成時期の後ろ倒しと予算超過
ラボ型開発（準委任型開発）の契約形態で、新しいプロダクトやITサービスを作っていくような場合に多いケースです。
開始時点では「この体制とスケジュールなら、いつまでに完成するだろう」と目星をつけて開発をスタートします。しかし、後から「この機能も欲しい」「あれも入れたい」という要望が次々と追加され、スケジュールは後ろ倒しに。体制の増強も必要になり、気がつけば当初の想定を大幅に超える予算オーバーに陥ってしまいます。
結果として、予定時期にサービスを投入できず収益化の目途も立たないため、事業自体の見直しをせざるを得なくなったという会社も少なくありません。
ビジネス環境が短期間で変わる時代、変更すること自体は悪いことではなく逆に必要なことでもありますが、ずっと変更をし続けているといつまでも収益化しない、ビジネスにならないため、予算も踏まえてどこかで踏ん切りをつけることや、仕様変更に伴うその先のスケジュール（見込み）の確認が必要です。
1-3.キーマンの離職による開発停滞やトラブル急発生
本サイトの「オフショア開発の運営に日本語人材は必要なのか？」の記事でも取り上げましたが、属人化してしまったケースです。
自社のプロジェクトを担当するオフショア開発会社（ベンダー）の人材（ブリッジSE・優秀なエンジニア）が、運よく優秀な人であり開発プロジェクトは非常に順調に進んでいました。しかしその人が退職もしくは休職（産休・育休など）で別の人材に替わってから、新しい人に問題が無く普通のレベルの人材であったとしても、急に上手く進まなくなったり、問題が発生するようになってしまったという事があります。
これは、最初にアサインされていた優秀な人の個人に紐づいた能力で開発チームが回っていた為、例えば曖昧な指示であっても上手く対応できていたものの、普通のレベルの人に替わってそれができなくなり、今まで能力の高さによって表に出てこなかった問題が顕在化したと言えましょう。
よって発注者側でも明確な指示出しをするなど、特定の人物の能力に依存しない形での開発を実施できるよう注意する必要があります。
1-4.納期遅延の常態化やクオリティの低さの多発
特に仕様変更もせず、余裕をもって組んだスケジュールのはずなのに納期が遅延することが多く、途中で進捗確認をしたときは「順調です」と回答されていた。
出来上がってくるものが明確に定義された仕様書と異なっている、バグが多数残ったまま納品されてくるため、手戻りが多い。
こういうケースで考えられるのは、そもそもそのオフショア開発会社（ベンダー）の能力が開発内容とマッチしていないケースです。
開発会社を選定する際には、
「どのような開発において強みであるのか、それに該当する実績にはどのようなものがあるのか」
「逆にどのような開発は向いていない（苦手）で経験も無いのか」
といった点を確認し、依頼しようと考えている開発内容がそのオフショア開発会社の得意とする分野と合致しているのかという点について事前に確認をすることで、ミスマッチを避けることにも繋がります。
1-5.カレンダーの違いによる開発期間の不足
オフショア開発は日本ではない外国で開発を行う以上、その国のカレンダーに沿って開発が行われることになります。
よって祝日や大型連休なども日本と異なるため、日本では平日だから開発が進むと考えていたら、オフショア開発会社は長期休みで開発対応できず、予定していたスケジュールの変更を余儀なくされたというケースがあります。
具体的には、ベトナムでは旧正月（テト、例年1月後半～2月頃）に1週間ほど休みとなりますし、インドネシアなどイスラム圏では、断食月であるラマダン明けに連休が、タイなどでもソンクランと呼ばれる時期の連休があり、通常この連休と合わせて有給休暇を取得して長期休みを取る従業員も多いです。
一方で日本では公式の祝日ではないものの、一般的に12月31日の大晦日や、1月2日と3日は正月三が日（さんがにち）として、土日や祝日とは関係なく休みとしている会社も多いです。8月の中旬、お盆の時期も同様でしょう。しかし同じ期間中、例えばベトナムでは平日であるため、通常の営業日として開発が進むことになります。
よってお互い、別の国であることを前提にして確認を含めたスケジュールの事前調整などが欠かせません。
また時差があるため、MTG時間の設定調整や、自社と営業時間がどのくらい被るのかという点も把握したうえで、日々の連絡の調整をする必要があります。
1-6.カントリーリスク顕在化
最後に忘れてはならないのが「カントリーリスク」です。
特に安さ（コスト削減）を重視するとどうしても1人当たりのGDPが低い新興国となりますが、こういった国では何らかの政情不安や紛争などに巻き込まれる可能性もあります。
例えば、ミャンマーはその人件費の安さから注目されていましたが、2021年の国軍によるクーデター以降、国内の一部エリアでは内戦状態となりそれは現在でも継続しています。
実際にベトナムにある弊社にも、ミャンマーで開発をしていてこういう状態になってしまい開発継続できなくなって、開発を引き継ぐことはできないかという相談が当時ありました。
同じく人件費の安さで注目されていたバングラデシュでも2024年7月の大規模デモが起きた際は混乱状態に陥り、インターネットへのアクセスが強制的に遮断され、しばらくの間、連絡がつきづらくなったことがあります。
またかつてヨーロッパからのオフショア開発先として有名であったのが人件費の安い、ウクライナやベラルーシといった国々でしたが、2022年のロシアによる軍事侵攻以降、戦争状態になり、またベラルーシも経済制裁（金融制裁）によって取引が難しくなりました。
また上記と意味合いは異なりますが、近年で発生している為替の変動（円安）によって、外貨建てオフショア開発費用を日本円換算した際の金額高騰も、ある意味、日本という国（日本円）に依存しているが故の、日本のカントリーリスクの顕在化と言えるかもしれません。
この様に、どの国でカントリーリスクが顕在化するのか未来を完全に予測することは難しいものの、安さ（コスト削減）の裏側にある理由としてカントリーリスクも念頭に置き、依頼先の国を選ぶ際に考慮する必要があります。
2.オフショア開発で失敗してしまう根本原因
失敗には表面的な理由だけでなく、構造的に失敗してしまう要素もあります。そこで失敗を避けるために発注者側で注意しなければならない点を2つ紹介します。
2-1.発注側の丸投げ体質
「それなりの費用を払っているのだから全部うまくやっておいて」という事で丸投げしてしまうことこそ、失敗に繋がる一番の要因となります。
もちろん契約に基づいてお金を払う以上、ちゃんと開発役務を提供してもらう事は前提ですが、それは丸投げしても上手くいくことを意味しません。
例えるなら「お金を払って馬に乗るものの、ちゃんと手綱は自身で握る必要がある」という事になります。そうしないと目的地と違う方向へ行ってしまったり、道草を食ったり、途中で振り落とされることにも繋がりかねません。
具体的には、発注者側の方で
◆作りたいものを明確に伝える
なぜ作るのか、どういう用途に使い、どうやってビジネスを成り立たせるのかも含め伝え開発側に理解してもらう
◆上がってきた要件定義書や仕様書を確認し把握する
内容に理解できない点があるならば、それを伝えて説明を求め、理解したうえで開発を進める
◆責任をもって判断を行う
開発者から選択肢を提示された場合、どれが自社のビジネスに合致するのか判断し、その選択に責任を持つ
◆進捗を把握する
会社や国は違えど、同じチームと考えて進捗に関心を払う
◆成果物を確認し、フィードバックする
出来上がってきたものが想定通りのものかを確認・判断する
といった点をちゃんとやっていくことで丸投げではない開発の依頼となります。
2-2.金額（コスト）だけでオフショア開発先を選んでいる
まず金額（コスト）が、オフショア開発先を選ぶ際に大事なポイントであることは否定しません。
しかしオフショア会社の選定にあたって判断基準を金額（コスト）だけで選ぶと、何らかのトラブル、多いケースでは品質やスケジュールの遅延などに遭遇する可能性が高くなります。
契約が請負型契約などで追加費用を支払う必要が無かったとしても発注側における対応稼働や、予定していた時期にソフトウェア（ITシステム）が出来上がらないことによるビジネス上の機会損失が生じることになります。これでは結果的に「安物買いの銭失い」となってしまいます。
オフショア開発会社を選ぶ際は、あらかじめ何を基準に（どのようなポイント）を重視して選ぶのかを社内で整理しておき、候補先の会社（ベンダー）から提案された内容と照らし合わせて評価を行うことで、単純に金額の安さだけの基準で選ばずに済みます。
またオフショア開発会社から提示されてくる見積額の中には、何が（どういったサービスが）含まれているのか、どういう前提でこの見積もりが作られているのかという「前提条件」を確認しましょう。
そして仮にある会社の見積もりが他社より高い場合は、それを相手に伝えて理由を確認し納得がいくかどうかで判断するというのも、選択にあたって賢いやり方の１つとなります。
3.失敗を回避する！オフショア開発で発注者が持つべき5つの心得
以上で述べてきた失敗事例や根本原因を踏まえてオフショア開発における心得を5つにまとめるなら以下の通りです。
3-1.開発依頼内容と役割分担の明確化
要件定義書や仕様書を作る場合は、「〜など」「適宜」といった曖昧な表現を排除して明確にすることで読み手によって異なる解釈の違い発生を避けることに繋がります。
そしてテキストだけでなく図や絵、画面遷移図、ワイヤーフレームなど視覚的に理解しやすいものを活用して認識を一致させることも効果的です。
また発注側にもエンジニアがいる場合、発注側のエンジニアではどこを担当し、オフショア開発会社側ではどこを担当するのかといった役割や担当範囲を明確にして認識を合わせましょう。
ここがはっきりしていないと、お互いに相手がそれをやるものだと思っていて抜け漏れが生じたり、問題発生時に責任のなすりつけあいが発生することにもなりかねません。
3-2.丸投げ厳禁！同じビジネスを作る仲間として密なコミュニケーションの実施
丸投げの危険性は既に述べた通りなので省きますが、ソフトウェア開発という形で同じビジネスに参加する仲間としての一体感をもってもらうため、ビデオ通話を使った毎日の定例ミーティング（朝会）の実施や、ビジネスチャットツール（Chatwork、Slack、Teams）でのコミュニケーション頻度は失敗の回避にも繋がります。
またもし可能であるなら半年に1回もしくは年1回でもオフショア開発先へと出張し、実際に顔を合わせてMTGをして、一緒にご飯を食べることで国籍や国は違えど同じ仲間という意識を持つことに繋がり、開発エンジニア達のモチベーション向上に繋がるでしょう。
3-3.スモールスタート（PoC・部分発注）で相性をテストする
オフショア開発会社によって得意・不得意はもちろんありますし、選定時にそれを確認すべきですが、実際のところは開発をやってみないと分からないことも多いです。
よって大規模な開発を考えている際は、最初からそれを発注し、最初から大きな開発チームをつくって開始するのではなく、まずは小さなプロジェクトとして依頼をして小さな開発チームで試してみるという方法が考えられます。
そうすることでそのオフショア開発会社の開発力がどの程度のものなのか、今後大規模な開発を任せられそうかを判断できますし、発注者との相性も確認できます。もし合わないようであれば、契約を更新しないことで失敗を最小限に抑えることにも繋がります。
3-4.特定の人物の能力へ過度に依存しない
日本語人材などで運よく特に優秀な人材がアサインされることもありますが、その人の能力に依存して曖昧な指示や、コミュニケーションが十分でない場合でも開発が上手く進んでいた場合、別の人に替わったタイミングでトラブルが多発する属人化問題が発生してしまいます。
よって急にアサインが替わっても問題が生じないよう、明確な指示出しや密なコミュニケーションなど発注元でも特定の人物の能力へ過度に依存しないやり方を日ごろからしておくことが大切です。
3-5.相手国の文化・商習慣を理解し、敬意を払う
既に述べた祝日の違いや時差の点もそうですが、オフショア開発は日本ではない外国で開発をする形態ですので、開発者は日本人ではありませんし、日本語を話せるブリッジ人材であっても日本人ではありません。
よってそれを念頭に置いたうえで接し方を配慮する。例えば、日本語で説明をする際も、できるだけ分かりやすい表現でゆっくり話すことで、相手に正しく伝わる可能性が高まります。
また仕事に対する考え方（ワークライフバランス）なども日本人とは異なるため、バッファ（余裕）を持たせた計画と依頼の仕方、進め方が重要となります。
契約に基づく役務はちゃんとやってもらう、しかし相手は日本にいる日本人ではないことを念頭におき、開発が成功に繋がるよう発注者としても配慮する。このようなマインドセットがオフショア開発の失敗を避けて成功に繋がる要素でもあります。
4.失敗事例に注意しつつ、オフショアを上手く活用しよう
以上で述べてきた点を踏まえると、オフショア開発は何か難しそうだなと思う方もいるかもしれません。しかしお気づきの方もいるかもしれませんが、ほとんどの点は、日本国内の開発会社に依頼する際に気を付けなければならないこととも被ります。
日本国内で日本の開発会社に対して依頼した場合でも、発注者と開発会社とで認識のずれがあって手戻りが発生した・揉めた、仕様変更の多発で予算超過、キーマン離職で遅延、開発会社の能力が足りず（または、開発内容が未経験の分野だったので）バグだらけだった、このようなトラブルはよく聞く話でもあります。
そして丸投げで失敗した、ブラックボックス化した、金額だけで選んだらそれ以上に費用が掛かったという話も日本においても同様です。
オフショア開発ならではとなると、相手が日本人ではないこと、オフショア開発先国の状況に注意・配慮という点ですが、現在、日本国内にも多くの外国籍人材が働いており、様々なビジネスにおいて国内だけで完結しない（海外の影響を受ける）時代、それは特別なことではなくなりつつあります。
そしてオフショアという選択肢を使うことで、たとえ国内だけで行っているビジネスであっても、国際化の一歩を踏み出すことへと繋がります。
これまで述べてきた点に注意しつつ、ビジネスを1つ上のステージへと上げて行く手段の1つとして、ぜひオフショアを活用いただければと思います。
また、オフショア開発先を選ぶ際にどうすればよいのか、具体的にチェックすべきポイントを知りたいという方がおられましたら、関連記事「失敗しない「オフショア開発会社」の見極め方5選｜発注前に確認すべきポイント」に確認項目を挙げていますので、そちらをご活用ください。
