オフショア開発の失敗事例と対策｜会社選びの教訓

01はじめに｜この記事でわかること

要点：この記事では、オフショア開発でよく起きる失敗を4つの事例に整理し、それぞれ「発注前のどの判断が原因だったのか」までさかのぼって解説します。オフショア開発の基本をひととおり押さえた方が、次に委託先を選ぶために読む記事です。

「安く早く作れると聞いて頼んだのに、出てきたものが使えなかった」。オフショア開発のご相談で、いちばんよく聞く話です。

ただ、詳しくうかがっていくと、原因が開発中に生まれていたケースはあまりありません。ほとんどは契約の手前で決まっています。仕様をどこまで書いたか。窓口が誰だったか。テストを誰がやると決めていたか。だいたいこの3つです。

そこでこの記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、立て直しのご相談を受けてきた立場から、失敗の型とその手前で打てる手を整理します。読み終えるころには、「私はどの会社に依頼するべきか」を判断する材料がそろいます。

次の動画では、オフショア開発をうまく進めるための考え方が短くまとまっています。この記事の内容とあわせてご覧ください。

02オフショア開発の「失敗」は3種類ある

要点：オフショア開発の失敗は、品質・コスト・スケジュールの3つに分かれます。やっかいなのは、ひとつが崩れると残り2つも連鎖することです。オフショア開発の体制を先に決めておくと、この連鎖を止めやすくなります。

失敗と一口に言っても、中身はちがいます。整理すると次の3つです。

• 品質の失敗。動くけれど業務要件を満たしていない、または不具合が多い。
• コストの失敗。単価は安かったのに、最終的な支払いが国内委託と変わらない。
• スケジュールの失敗。納期が延び、社内の公開計画を組み直すことになる。

現場で怖いのは、この3つが独立していない点です。品質が落ちれば修正が発生し、修正はコストと納期を押し上げます。最初に崩れるのはたいてい品質で、気づいたときには3つとも崩れています。

だから対策も、品質の入口である仕様と体制に集中させるのが効率的です。外注と内製をどう判断するかを考えている段階から、この視点を持っておいてください。

03失敗事例1｜仕様どおりなのに使えないものが届く

要点：いちばん多い失敗です。書いた仕様は満たしているのに、業務では使えない。原因は仕様の粒度不足で、要件定義の段階で受入条件まで書けていれば防げます。

たとえば、ある卸売業の受発注システムで「注文を一覧で表示する」とだけ書かれた仕様がありました。納品されたものは、たしかに一覧を表示します。ただ、担当者が毎日使う「取引先ごとの絞り込み」がついていませんでした。

委託先に落ち度はありません。書いていないものは作られない。それだけです。国内の会社なら「たぶんこう使うだろう」と補ってくれることがありますが、その暗黙の補完は距離が離れると効かなくなります。

防ぐ方法はシンプルです。画面ごとに「誰が、いつ、何をするか」を1行ずつ書く。そのうえで受入条件、つまり「この操作ができたら合格」というラインを先に決めておく。RFPの書き方の考え方が、そのまま使えます。

04失敗事例2｜単価で選んで総額で損をする

要点：人月単価が安い会社を選んだのに、修正と追加で総額が国内委託を上回るパターンです。オフショア開発の費用相場を単価ではなく総額で見る習慣がつけば、避けられます。

見積書の単価だけを並べて比べると、当然いちばん安い会社が選ばれます。ところが総額は、単価×人数×期間だけでは決まりません。日本側の確認工数、仕様を伝え直す時間、テストのやり直しが上に乗ります。

特に見落とされるのが、日本側の負担です。相手の理解が浅いほど、社内の担当者が説明に時間を取られます。この時間は請求書に出てきませんが、確実にコストです。

安く見える見積書ほど、書かれていない作業が多く残っています。

見積もりの見方を押さえたうえで、「この金額に含まれていないものは何ですか」と必ず質問してください。含まれていないものが多い見積ほど、あとで膨らみます。

05失敗事例3｜ブリッジSEが名前だけだった

要点：提案時に紹介されたブリッジSEが、実際にはほとんど関与していなかったケースです。ラボ型開発のように継続的な体制を組むときほど、この人の実力が結果を左右します。

ブリッジSEは、日本側の要望を現地の開発者に伝え、現地の状況を日本語で返す役です。ここが弱いと、開発全体が伝言ゲームになります。

よくあるのは、面談では流暢な日本語を話す人が出てきて、契約後は別の人が窓口になるパターンです。あるいは1人が5案件を掛け持ちしていて、質問の返信に3日かかる。どちらも、進行が止まる原因になります。

確認の方法はあります。契約前に、その人が書いた議事録や仕様確認シートを見せてもらってください。日本語の正確さより、「あいまいな点を質問として書き出せているか」を見ます。ここができる人は、開発中も止まりません。

• 面談に出た人が、契約後もそのまま担当するか。交代するなら、後任にも同じ質問をします。
• 同時に何案件を担当しているか。3件を超えると返信が遅れやすくなります。
• 質問への回答は何営業日で返るか。目安を数字で答えられるかを見ます。

06失敗事例4｜受入テストで初めて品質を知る

要点：開発中は順調という報告だけが届き、受入テストで大量の不具合が出るパターンです。テストの分担を契約前に決めておけば、問題の発覚が数か月早まります。

進捗率90%という報告を、3週間続けて受け取った経験はないでしょうか。オフショア開発に限らず起きることですが、顔が見えないぶん気づくのが遅れます。

対策は、報告の形式を変えることです。パーセンテージではなく、「どの画面が受入条件を満たしたか」で報告してもらいます。2週間ごとに動くものを触れる状態にしてもらえば、認識のずれはその時点で見つかります。

あわせて、単体テスト・結合テスト・受入テストの担当を契約書に書き分けてください。ここが空欄のまま進んだ案件は、検収の場でほぼもめます。ZenWeb Japanのオフショア開発でも、テスト範囲は契約時に必ず文書化しています。

07失敗はどの工程で表面化するのか

要点：立て直しのご相談を整理すると、問題の約6割は受入テストから公開後のあいだに表面化しています。気づいたときには、作り直す範囲が広がっているということです。オフショア開発の進め方を早めに固める理由がここにあります。

この数字が示しているのは、発見が遅いという一点です。要件定義や設計の段階で気づけた案件は、1割にも届いていません。

早く気づくために必要なのは、細かい監視ではなく接触の頻度です。2週間に一度、動くものを触る。それだけで、問題に気づくタイミングはかなり早まります。

08原因別｜発注前に防げる失敗はどれか

要点：原因を並べ直すと、上位4つはすべて発注前の準備で防げるものでした。防ぎきれないのは為替とメンバー交代くらいで、それも契約条項で影響を小さくできます。RFPの段階で手を打つのがいちばん確実です。

表を眺めてわかるのは、対策のほとんどが「文書に書く」ことで済んでしまう点です。特別な管理手法も、高価なツールもいりません。

09手直しは総額をどれだけ押し上げるか

要点：手直しの影響をモデル試算すると、当初見積の3割ぶんの手直しで、単価の優位はほぼ消えます。システム開発の費用相場と比べるときは、この上振れ幅も一緒に見てください。

たとえば当初800万円の案件で、国内委託より200万円ほど安く見えたとします。手直しが3割起きた時点で総額は1,040万円になり、その優位はなくなります。

だから見積を比べるときは、上振れの余地も一緒に置いてください。手直しが起きにくい進め方を提案できる会社のほうが、結果的に安くつきます。

10この5年で減った失敗と残った失敗

要点：言語や時差が原因の失敗は、この5年で明らかに減りました。一方で仕様とテストに関する失敗はほとんど減っていません。相手側ではなく、発注側の準備の問題だからです。

ベトナムをはじめ、委託先で日本語に対応できる人材は年々増えています。ベトナムオフショア開発の実態を見ても、その層は確実に広がりました。

それでも失敗が減りきらないのは、残った原因が発注側にあるからです。相手を変えても、仕様の書き方が変わらなければ結果は同じになります。

ちなみに、国内の受託開発でも品質のばらつきは残っています。5,546件のプロジェクトを分析したIPAのソフトウェア開発分析データ集2022では、信頼性も生産性も前回の分析から低下する傾向が報告されました。海外だから品質が落ちる、という単純な話ではないわけです。

11会社選びで必ず聞きたい6つの質問

要点：委託先を比べるときは、実績の数より「進め方を自分の言葉で説明できるか」を見ます。次の6つを同じ順番で全社に聞くと、差がはっきり出ます。制作会社の選び方と同じ考え方です。

1. 担当するブリッジSEは誰ですか。面談に出た人がそのまま担当するかを確かめます。
2. 同時に何案件を担当していますか。3件を超えると返信が遅れやすくなります。
3. 仕様が固まっていない部分は、どう進めますか。ここで具体的な手順が出るかどうかが分かれ目です。
4. テストはどこまで御社の範囲ですか。単体・結合・受入の線引きを言葉にしてもらいます。
5. この見積に含まれていないものは何ですか。含まれないものを即答できる会社は信用できます。
6. 契約後、最初の2週間で何が出てきますか。動くものが出る会社を選びます。

6つとも、技術力ではなく段取りを聞いています。段取りを説明できない会社は、開発が始まってからも説明できません。ここは経験上、かなり当たります。

12契約書で決めておく5項目

要点：オフショア開発の契約で抜けやすいのは、テスト範囲・検収基準・知的財産・交代時の引き継ぎ・支払い通貨の5つです。どれも後から決めようとすると、発注側が不利になります。

• テストの範囲。単体・結合・受入の担当を分けて書きます。
• 検収の基準。何ができたら合格かを、画面単位で決めておきます。
• 知的財産権の帰属。ソースコードとドキュメントの権利がいつ誰に移るかを明記します。
• メンバー交代時の対応。交代の通知期限と引き継ぎ期間を入れます。
• 支払い通貨と為替。円建てにするか、レートの基準日をいつにするかを決めます。

契約形態そのものも確認してください。請負か準委任かで、責任の所在と検収の考え方が変わります。ラボ型開発と請負・準委任の違いを押さえたうえで選ぶと、あとで解釈がぶれません。

13まとめ｜失敗の分かれ目は契約前にある

要点：オフショア開発の失敗は、相手の実力より発注側の準備で決まります。受入条件を書く、ブリッジSEを確かめる、テスト分担を契約に入れる。この3つで大半は防げます。

この記事で見てきたとおり、問題の約6割は検収以降に表面化します。ただし原因は、そのずっと手前にありました。

逆に言えば、契約前の数週間で結果はかなり動かせるということです。仕様の粒度を上げ、窓口の実体を確かめ、テストの線を引く。大がかりな体制はいりません。

オフショア開発をご検討中でしたら、まずは要件の整理からご相談ください。費用は案件ごとのお見積りでご案内しています。

14よくある質問

要点：オフショア開発の失敗について、ご相談の場でよくいただく質問をまとめました。引き継ぎの可否や向いている案件の見分け方など、判断に直結するところを中心に整理しています。

1. オフショア開発の失敗率はどのくらいですか

公的に集計された失敗率の統計はありません。ただ、立て直しのご相談を見るかぎり、問題の約6割は受入テストから公開後のあいだに表面化しています。発生率より、発見が遅れやすい構造のほうが実務では重要です。

2. 失敗しやすいのはどんな案件ですか

仕様が固まりきらないまま発注した案件です。特に、社内の業務ルールが人によって違う業務システムは、書き出す作業を省くと確実にずれます。逆に、仕様が明確な改修や機能追加は、オフショアでも安定しやすい領域です。

3. 一度失敗した開発を、途中から引き継いでもらえますか

可能です。ただし最初に、現状のソースコードとドキュメントを確認させていただきます。残せる部分と作り直す部分を切り分けてから、範囲と工程をご提示する流れになります。契約書と知的財産権の条項もあわせて確認します。

4. 小さな案件でもオフショア開発は向いていますか

規模が小さいほど、単価差より調整の手間が効いてきます。数十万円規模の改修であれば、国内で完結させたほうが早いこともあります。判断の目安は、オフショア開発の費用相場で規模別に整理しています。

5. 失敗を防ぐために、社内に技術者は必要ですか

必須ではありません。ただし、業務を説明できる担当者は必要です。技術は委託先が補えますが、「その業務をどう回しているか」は社内の人しか知りません。そこを言語化する役割さえ置ければ、技術者がいなくても進められます。