オフショア開発で失敗に陥る50の原因【チェックシート付】

１．オフショア開発における失敗とは

オフショア開発における失敗とは一般的に「予算」「期日」「品質」にカテゴライズすることができます。それぞれの失敗の概要について下記いたします。

１－１．予算

オフショア開発は、そもそも日本国内における外注コストを抑えるための手段の1つと位置付けられています。そのため、日本国内の相場と比べて、オフショア開発の方が割高になってしまった場合、【予算】における失敗と考えて良いでしょう。オフショア開発で目指すべきは第一に、期待する品質のシステムを日本国内よりも安く開発する（納品してもらう）ことです。

１－２．期日

開発スピードが遅かったり、開発中のトラブル対応等で当初予定していたリリース日よりも納品が遅れて、そのシステムによって本来生まれるはずだった利益が少なくなり、機会損失を受けた場合、【期日】における失敗と考えて良いでしょう。また、事前にリリース日などを公表していた場合、SNS等で悪評が広がる場合があります。

１－３．品質（信用）

納品物の品質が悪く、修正を依頼してもその修正が反映されず、修正を繰り返していく悪循環に見舞われる場合、次第に【予算】を超え、予定していた【期日】も守れず、最終的に上記の【予算】・【期日】における失敗に繋がり、企業の信用が落ちた場合は、【品質（信用）】における失敗と考えて良いでしょう。

２．オフショア開発で失敗に陥る50の原因と対策

残念ながらオフショア開発で思うような結果を得られなかった声はよく聞きます。ただ、ポイントを押さえれば失敗するリスクを限りなくゼロに近づけることができます。この記事ではそのポイントを紹介します。

２－１．コミュニケーションがうまくいかない

オフショア開発で失敗する代表例がディスコミュニケーションです。特に窓口を担当してくれる人（ブリッジSE）と意思疎通がうまくいかないと様々な失敗に繋がります。ここでは、どんな場面でディスコミュニケーションが起きるのか紹介します。

２－１－１．要件定義時のディスコミュニケーションによる失敗

＜失敗レベル＞

【総合】★★★★★

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

曖昧なまま要件定義を進めると相手に細かい要件が伝わっておらず、細かいところの動作・操作性・デザイン性の認識の齟齬が生まれます。それが結果的に品質の悪さに繋がり、修正＆修正を繰り返していくうちに予算・期日の失敗に繋がり、プロジェクト全体に影響を及ぼすことになります。

＜対策＞

システム開発において、要件定義は上流工程で中心的作業になります。「業務視点」「システム視点」「ソフトウェア視点」で細かく文書化（図やキャプションを入れて分かりやすく）した上で打ち合わせをして、しっかりと詰めましょう。機能要件だけでなく、非機能要件も定義するよう心掛けましょう。また、相手がそれに対してちゃんと理解してくれているか、あえて確認の意味を込めて質問をぶつけるのも効果的でしょう。また、オフショア開発の場合、日本語で作成したドキュメントを受託側の通訳者が英語や母国語に訳して現地のSEに共有するケースが多いです。その訳したドキュメントを社内共有した後に認識の齟齬がないか最終確認すると良いでしょう。

２－１－２．契約締結時のディスコミュニケーションによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★☆

＜失敗＞

開発途中でトラブルが起きたときに多額の人件費を請求されるケースや納品形態が思ったものと異なる形で納品されるケースです。納品し直しとなると、その分期日も遅れることになり、予算、期日の失敗に繋がります。契約内容をしっかりと確認せず、曖昧なまま進めて、契約書にサインしたら最後です。

＜対策＞

契約書の内容は時間を掛けてしっかりと確認しましょう。海外を相手にするので、場合によってはすべて英語で書かれていることもあります。英語に抵抗がある場合は日本語で対応してくれる会社を選びましょう。以下の点は必ず確認してください。明確な記載がない場合は盛り込んでもらうように伝えてください。

• 金額

• 納期

•  

  支払日と取引通貨

•  

  トラブルが発生した時の補償範囲

•  

  納品形態のファイル形式

•  

  納品後のアフターフォローの内容

•  

  納期に間に合わなかった時の責任の所在

２－１－３．進行中のディスコミュニケーションによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★☆

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

進行中のこまめなコミュニケーションを怠ったことにより進捗が遅れている（納期に間に合わない）、開発の方向性が違う方向に進んでいることに気づくのが遅れて、期日や品質の失敗に繋がります。早めに気づいていれば…という後悔の念に駆られることになります。

＜対策＞

プロジェクト進行中は毎日オンライン会議で現地の担当者と打ち合わせするのがベストです。1日数分だけでも繋いで前日からの進捗確認、開発の方向性の確認はしましょう。少しでもあれ？と思ったらその場ですぐに指摘しましょう。そのため、打ち合わせの頻度は毎日対応してくれるのか、毎日が無理な場合はどの程度の頻度で対応してくれるのか確認しておきましょう。

２－１－４．請求時のディスコミュニケーションによる失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★★★★★

【期日】☆☆☆☆☆

【品質（信用）】☆☆☆☆☆

＜失敗＞

聞いていた単価・勤務時間と異なる数字で請求書が届き、過剰に請求されるケースです。場合によっては言った言わないで揉めたり、最悪の場合裁判沙汰にまでなる可能性もあります。自社でも対応に追われて無駄な人件費が掛かり、予算の失敗に繋がります。

＜対策＞

単価は契約書を見返してみましょう。書いてなければ契約書に盛り込んでもらってください。勤務時間の精査は金銭を支払う前に誰がどのぐらい稼働したのか、情報（勤務表）をもらってください。中身を確認し、明らかに過剰に計上されている場合は指摘しましょう。場合によってはタイムカードや入退出記録等のエビデンスを求めても良いです。勤怠管理をどのようにしているのか事前に確認しておきましょう。

２－１－５．国別におけるディスコミュニケーションによる失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★☆☆☆

【品質（信用）】★★★★☆

＜失敗＞

海外に行ったことがある／住んでいたことがある／ビジネスで日常的に海外の人とやり取りがあり、その時は問題なくコミュニケーション取れたから余裕だろうと思い込んで進めてみたものの、うまく意思疎通ができずに品質の失敗に繋がるケースです。

＜対策＞

国によってコミュニケーションの取り方、うまく付き合うためのコツが異なることは理解しておきましょう。ここではそれぞれの特色を紹介します。（オフショア開発で人気ある地域を取り上げています）

２－１－６．完成品のお互いの期待値のズレによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★☆☆☆

【期日】★★☆☆☆

【品質（信用）】★★★★★

＜失敗＞

お互いの納品物に対する期待値が合っていなく出来上がったものが期待値以下で納品され、品質の失敗に繋がるケースです。

＜対策＞

要件定義でしっかりと定義した上で、どのような機能を持った納品物が最終的に欲しいのか、その機能を持たせることの意図を1つ1つ伝えることでより相手と密にコミュニケーションを取ることができます。お互いに同じ目的を達成するために同じ方向を向いて進めることが成功に繋がります。

２－１－７．プロジェクトの目的の共通認識のズレによる失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

目的の共通認識がぶれていることにより、納品物で目的が達成できないケースです。達成できないと目的を達成するために改善をしていく必要があります。致命的な問題だと取り返しがつかなくなり、期日や品質の失敗に繋がります。

＜対策＞

「何」を作るのか、ではなく、「なぜ」作るのかを共有しましょう。当該プロジェクトで最終的に何がしたいのか（そのシステムで何をしたいのか）、目的を正確に伝えることでお互いに進む方向にぶれなく進めることができるでしょう。同じ方向を向いていないと大きな岩を動かすことはできません。

２－１－８．コミュニケーションツール（方法）の確認不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

緊急事態が発生した際にどのツールで連絡を取れば良いか分からず、普段やり取りしているツールで連絡しても連絡が付かず、緊急事態の対応ができず、期日や品質の失敗に繋がるケースです。

＜対策＞

お互いの普段の業務コミュニケーションツールを決めたうえで、有事の際にはすぐに連絡が取れる手段を確認しておきましょう。深夜帯／土日祝日等、営業時間外でも連絡取れる方法を確認しておき、1人ではなく2人～3人の連絡手段を押さえると良いです。

また、社内でのコミュニケーションツールは普段何を使用しているか確認することでしっかりと横の連携ができているか確認することができます。ここで複数のコミュニケーションツールを使っている場合は統一性がなく、連絡の見落としのリスクが増えます。

２－２．開発の予算組みの失敗

オフショア開発では当初予定していた予算・見積もりをオーバーするケースが珍しくありません。結果的に日本国内で外注するよりも高くなっては元も子もないです。どこに気を付ければオーバーしないで済むかここでは紹介します。

２－２－１．発注前の的外れな予算組みによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

発注前に予定した予算、見積もりをオーバーして結果的に日本で開発するよりも高くなり、予算において失敗に繋がるケースです。

＜対策＞

要件定義を踏まえて発注前に工程数とそれを達成するためにどのようなスキルを持った人が何名必要か、完成するまでの日数を試算する必要があります。試算した数字＋αで見込みを立てるようにしましょう。ギリギリで予算を組んでしまうと、開発におけるトラブル、為替による影響、世界情勢の影響等による想定外の費用に対応できなくなります。

２－２－２．会社選定時の的外れな予算組みによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★☆

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

契約形態を確認せずに進めて想定よりも人の稼働時間が多くなったり、取引の通貨を確認せずに進め、為替の影響を受けて結果的に日本で開発するよりも高くなり、予算において失敗に繋がるケースです。

＜対策＞

発注先の会社の契約形態が請負か準委任なのか、また取引通貨は米ドルか日本円か自国の通貨なのか、事前に確認しておきましょう。

※詳細は、２－３の章をご確認ください。

≪　会社選定で失敗しないための詳細　≫

２－２－３．国（地域）選定時の的外れな予算組みによる失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

依頼した企業の拠点の国（地域）の情勢が不安定になり為替が大きく変動したり、物価や人件費が高騰し、結果的に日本で開発するよりも高くなり、予算において失敗に繋がるケースです。場合によっては、人がどんどん離脱して開発スピードにも影響が出て期日の失敗にも繋がることも考えられます。

＜対策＞

その国の治安、情勢の状況は確認しておきましょう。国が良くても一部の地域が不安定であるケースもあります。地域単位で確認しておくと尚良いでしょう。

※詳細は、２－４の章をご確認ください。

≪　国（地域）選定で失敗しないための詳細　≫

２－２－４．開発進行中に予算オーバーして失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★☆

【品質（信用）】★★☆☆☆

＜失敗＞

要件定義の時点で曖昧なために、「追加でこの機能欲しい」となったときに工程数が増えて、結果的に日本で開発するよりも高くなり、予算において失敗に繋がるケースです。

＜対策＞

要件定義の時点で事細かに盛り込むようにしましょう。何度も出てきていますが、本当に要件定義書でプロジェクトの運命が決まると言っても過言ではないです。ただ、要件定義書だけで満足してはいけません。

２－２－５．業務完了時に予算オーバーして失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★★★

【期日】★☆☆☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

開発中のトラブルや開発遅延、納品物が期待値以下だったときに想定以上に工程が掛かり結果的に日本で開発するよりも高くなり、予算において失敗に繋がるケースです。

＜対策＞

開発中の開発の方向性が問題ないか、どこかで躓いていないか、日々の進捗管理を怠ることなく進めましょう。少しでもあれ？と思ったら、その時点で軌道修正を依頼するようにしましょう。

２－２－６．市場・経済による影響を受けて予算オーバーして失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★★☆

【期日】★☆☆☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

依頼した企業の拠点の国（地域）の情勢が不安定になり為替が大きく変動したり、物価や人件費が高騰し、予算において失敗するケースです。

＜対策＞

その国の治安、情勢の状況は確認しておきましょう。２－１－５で取り上げた国の中ではベトナムが一番安定しています。

２－２－７．支払いの遅延による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★★★

【期日】★☆☆☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

支払予定日を超過しても支払いが確認できずに督促に自社でも対応に追われて無駄な人件費が掛かり、予算の失敗に繋がるケースです。

＜対策＞

実績が少ない会社、経営が安定していない会社、本社が海外にある会社は支払いの遅延が発生する可能性が高くなります。また、海外からの振込の場合、振込手数料はどちらが持つのか事前に確認しておきましょう。

会社を選定する際にその会社の資本金、ここ3年以内の売上、設立年は指標として事前に確認しておきましょう。

２－３．会社選びの失敗

オフショア開発では会社選びも重要なポイントです。規模が大きい会社でも体制がパッとしないケースが大いにあります。規模が大きいからといって、その会社が果たして失敗しないで済む会社でしょうか？ここでは、そんな疑問を解決します。

２－３－１．オフショア開発の歴史が浅い会社での失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★★★

【期日】★☆☆☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

オフショア開発の歴史が浅い（3年以内）会社はその国・地域の国民性について十分に理解していないと言えるでしょう。また体制も曖昧な状態（構築段階）でノウハウも少なく、手探りで進めており、イレギュラー対応もままならず結果的に期日の失敗に繋がるケースです。

＜対策＞

会社の資本金、オフショア開発を始めてから5年以上経過しているか、直近5年の売上推移等は指標として事前に確認しておきましょう。売上が右肩上がりであれば成功していて、方々から信用され実績を増やしているとみても良いでしょう。

※5年という基準は5年以内に倒産するケースが多いためです。

２－３－２．類似プロジェクトの開発実績がない会社での失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★★☆

＜失敗＞

２－３－１の条件はクリアしているが、今回依頼する予定のプロジェクトの類似実績がなく、手探りで進めることになり様々なエラーが発生して、結果的に期日の失敗に繋がるケースです。

＜対策＞

オフショア開発という言葉は広義で使われることが多いです。例えば、社内業務システムを作りたいのに、アプリ開発や保守・運用しか実績がない会社に依頼してもスムーズに開発することはできないです。事前にこれまでの実績についても確認しておきましょう。

２－３－３．会社全体の組織が不明瞭な会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★★★

＜失敗＞

会社の組織について把握せずに打ち合わせで言われた体制を鵜呑みにして進めていて、緊急事態が発生した際に担当者（ブリッジSE）に連絡が取れず、誰に連絡を取れば良いか分からず、迅速な対応ができず、期日や品質の失敗に繋がるケースです。

＜対策＞

言葉巧みに騙されないように組織の実態として組織図を出してもらいましょう。誰がトップにいて、その下に誰がいるのか。プロジェクトがうまく回っていないときに誰に言えば良いのか、確認しておくと良いでしょう。

２－３－４．プロジェクト体制が不明瞭な会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★☆☆☆

【期日】★★★★☆

【品質（信用）】★★★★★

＜失敗＞

打ち合わせで言われた体制を鵜呑みにして進めていて、いざ始まって蓋を開けてみたら全く異なる体制で組まれており、言われていた人数よりも少ない体制で結果的に期日・品質の失敗に繋がるケースです。

＜対策＞

こちらからオーダーした人数・時間通りに稼働しているのか、ブリッジSEだけでなくその下にいるSE・PGのメンバーも名前を含めて確認しておくと良いでしょう。また国外は国によっては出入りが激しい国もあります。メンバーが退職した後のバックアップ体制はどうなっているのか確認しましょう。

２－３－５．プロジェクトの進め方が不明瞭な会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★☆☆

【品質（信用）】★★★★★

＜失敗＞

開発サイクルが不明瞭で品質管理が杜撰なケースです。品質管理が杜撰だと結果的に品質が悪い完成品が出てきて最悪の場合、追加の費用と時間が必要になり、すべてにおいて失敗に繋がるケースです。

＜対策＞

どのようなサイクルで開発～テストまで進めているか確認しておきましょう。モジュールごとに検証環境で確認しているか、テストコードを書いているか、テストケースを作成してE2Eテストをしているか、コードレビューを取り入れているか等、品質管理のためにどのようなテスト工程を何人掛けてチェックしているのか明確なスキームを確認しておきましょう。

２－３－６．チケットドリブンを採用していない会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★☆☆☆

【期日】★★★★★

【品質（信用）】★★☆☆☆

＜失敗＞

開発の進捗確認をしても「順調に進んでいるから心配しないで」等の曖昧な回答しか返って来ずに、実際には開発の進捗が遅れており、結果的に期日の失敗に繋がるケースです。

＜対策＞

開発方法やフローについて予め確認しておきましょう。チケットドリブンを取り入れている会社は開発のそれぞれの工程を細かなタスク（チケット）で進めるため、担当者ごとに誰がどこを開発しているか管理できている証拠にもなります。タスクの進行状況を追跡しやすく、プロジェクト全体の進捗を可視化しやすくします。また、チーム内のコラボレーションやタスクの優先順位付けが容易になり、プロジェクトの進捗状況や残りのタスクを把握しやすくなります。

２－３－７．アジャイル開発を採用していない会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★★★

【品質（信用）】★★★☆☆

＜失敗＞

ウォーターホール開発を採用している会社で、急遽仕様変更が発生したときにスムーズな舵切りをすることができなく、期日の失敗に繋がるケースです。また、一気通貫での開発になるので、納品されてから大きな失敗に気づくこともあります。その場合、すべての失敗に繋がりかねません。

＜対策＞

アジャイル開発を採用している会社を選びましょう。小さな機能単位で開発を進めるアジャイル開発であれば、たとえコミュニケーションのロスが原因で発生したミスも早期に見つけることができ最小限の影響にとどめることが可能になります。

２－３－８．バックアップフォロー体制が不明瞭な会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★☆

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

一度起こしたトラブルを2回、3回と頻繁に起こして結果的に追加の費用と時間が発生して、予算や期日の失敗に繋がるケースです。

＜対策＞

イチ担当者が起こしたトラブルに対してのフォロー体制とそれを他の担当者に周知して再発防止についてどこまでしっかりと対応しているのか確認しておきましょう。日頃の教育環境についても確認すると良いかもしれません。社員に対して誰がどのぐらいの頻度でどのように教育しているか、社内の風通しの良さ／悪さも指標になるかもしれません。

２－３－９．本社が海外にある会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★☆☆☆

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

本社が海外にあることで、契約手続きが英語であったり、開発以外のコミュニケーションも英語や母国語でのやり取りになる可能性があります。担当者も日本人ではない可能性があります。日本人独自の感性が伝わりづらくなります。これらが結果的にディスコミュニケーションに繋がり、要件定義の齟齬、契約内容の齟齬、請求金額の相違に繋がり、期日や品質の失敗になります。

＜対策＞

本社が日本にある会社を選択しましょう。

２－３－１０．セキュリティ意識の低い会社での失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★☆☆☆☆

【品質（信用）】★★★★★

＜失敗＞

セキュリティ対策が甘く、ハッカーや盗賊によって技術情報や個人情報が漏洩してしまうケースです。昨今、このような漏洩は多額な損害賠償金を支払うことが求められることになり、予算・品質（信用）の失敗に繋がります。最悪の場合、倒産の危機まで追いやられることがあります。

＜対策＞

国によっては日本よりもセキュリティ対策が緩い国もあるので事前にどのような環境下で作業をしているのか確認しましょう。作業場にセキュリティキーはあるのか、そのキーの管理方法はどうなっているのか、技術情報等のファイル／データのやり取りはどのように対応しているのか、ご自身の会社のセキュリティポリシーに反していないか必ず確認をしましょう。また、情報セキュリティに関する資格をその国で認証を受けているか確認しましょう。

２－３－１１．人の入れ替えが頻繁な会社での失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

人の入れ替えが激しい会社で、伝言ゲームや引継ぎがうまくいかずに納期や品質の失敗に繋がるケースです。

＜対策＞

ジョブホッパーで転職を繰り返していく文化がある国が多いです。2，3年で辞めてしまうケースがよくあります。IT業界では5年以上の経験があるとベテランとみなされることがあり、経験とスキルの蓄積ができていることなど、様々なメリットがあります。また、会社としてしっかりとマネジメント体制が取れていることの証明にもなります。何年目の社員が多いのか、事前に確認しておきましょう。

２－３－１２．日本人デザイナーがいない会社での失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★☆☆☆☆

【期日】★☆☆☆☆

【品質（信用）】★★★☆☆

＜失敗＞

国内と国外では色が持つ意味合いが異なります。そのため国外の人が良かれと思ってデザインした作品も国内で見たときにイメージと全く異なるケースがあります。結果的に品質の失敗に繋がるケースです。

＜対策＞

美的感覚の違いから日本人に好まれない見た目になることがあります。日本人デザイナーが在籍している会社を選ぶことで、より日本人好みに合わせたものが出来上がるでしょう。日本人デザイナーが在籍していない場合は、過去の作品実績を見せてもらうようにしましょう。

２－３－１３．見積もりがあまりにも安い会社での失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★★☆

【品質（信用）】★★★★★

＜失敗＞

見積もりが破格だったので、安いからといってその会社に依頼した結果、プロジェクト体制が杜撰であり、結果的に期日・品質に影響を及ぼすケースです。

＜対策＞

２－３－４でも取り上げている通り、必ずプロジェクトの体制を確認しましょう。またその人数が妥当であるか、第3者に聞くのも1つの手です。また、なぜそれだけ安く抑えることができるか理由を確認しましょう。他社とは違うカラクリがあるはずです。そのカラクリを許容するかどうかはそれぞれの判断に委ねることになります。例えば、他社に比べて人・時間を削減している／日本人がいないケース等が考えられます。

２－３－１４．口コミの評価が低い会社での失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

口コミの評価が低いとはいえ、過去のことだし、規模が大きい会社だし、担当者も良い人だったので、自分には関係ないだろうと安易に会社を選んだ結果、実際の体制は酷いもので予算・期日・品質すべての失敗に繋がるケースです。

＜対策＞

口コミで書かれていることは事前に目を通すと良いです。特に採点が低い人のコメントを参考にすると過去にどんなトラブルがあったのか理解することができます。とはいえ、口コミだけで判断するのも良くありませんので、２－３で取り上げた内容を総合的に見て判断して会社を選択しましょう。

２－４．国（地域）選びの失敗

オフショア開発では国（地域）選びも重要なポイントです。国によって言語はもちろん、国民性や習慣等、言語以外にも日本と異なることがたくさんあります。ここでは、それぞれの国（地域）のどのような点を押さえれば失敗を防ぐことができるか紹介します。

２－４－１．オフショア開発の実績がない国（地域）での失敗

＜失敗レベル＞

【総合】★★★★★

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

ハイリスクハイリターンを覚悟の上でこれまで日本で実績がない国にチャレンジした結果、完成品として商品として売り出せるようなものができないケースです。これまで実績がない国は当然誰もノウハウを持っていません。その環境下でシステム開発できるでしょうか。仮に成功した場合はハイリターンが待っているかもしれませんが、、ハイリスクであることは変わりません。

＜対策＞

少なくとも以下の国のいずれかで調整すると良いでしょう。これらの国は実績が多くある国です。

（参照）オフショア開発白書（2023年版）　P.7

２－４－２．拠点周辺の環境悪化による失敗

＜失敗レベル＞

【総合】★★★★★

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

国の選択までは良かったものの拠点周辺の環境が劣悪で拠点に盗賊が入ったり、放火被害・天変地異の被害にあったりして最悪の場合、完成品が出来上がらずに終わってしまうケースです。

＜対策＞

２－４－１で取り上げられている国を選択しても拠点周辺の環境がスラム街のようなところにある可能性があります。Googleマップ等で周辺の様子を確認したり、地域を検索して治安等を予め調査しておきましょう。

２－４－３．祝日・時差による失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

急ぎの対応（その日中の対応）に迫られたときにオフショア先の国が旧正月等の長期休みに入っていて対応ができなく、結果的に納期や品質に影響を及ぼすケースです。また、時差が4時間以上あるとコミュニケーションの頻度も劇的に下がり、密なやり取りができなくなります。依頼する側が夜にやり取りをせざるを得なくなります。

＜対策＞

予めその国の祝日、会社カレンダーを入手しましょう。そのうえで要件定義の段階でスケジュールを組むときにその祝日を考慮したスケジューリングをしましょう。また、時差が4時間以上ある場合はコミュニケーションを取れる時間に制限が出てくることも覚悟しておきましょう。（あえてその時差を利用して開発するケースもありますので、「時差がある＝避けた方が良い」とは一概には言えません。）

２－４－４．国民性の理解不足による失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

細かいところを「そんな感じにやっておいて」「良しなにやっておいて」で作業をお願いしたところ想像とは全く異なるものが出てきて結果的にやり直しすることになり期日や品質に影響を及ぼすケースです。

＜対策＞

日本人同士でも当然のことながら、お互いの「当たり前」が「当たり前」でないことを認識しておきましょう。それが国外の人となれば当然そのギャップは広がります。事細かな指示、コミュニケーションを大事にしていきましょう。

２－４－５．文化・宗教の理解不足による失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

その日のうちに仕上げたく、残業をお願いしないといけないほどの作業量になった時に残業含めて依頼をしたが残業せずに帰宅され、次の日に回されて結果的に期日の失敗に繋がるケースです。また、その地域の宗教のことを調べずにNGワードを言ってしまい、関係性が悪くなり最悪の場合、途中で頓挫されることもあります。

＜対策＞

日本人のように真面目に残業して仕事をこなす文化は少数派です。他の国では家族や自分の時間を優先するケースが多いのでスケジュール管理は徹底しましょう。余裕を持ったスケジューリングが必要です。また、宗派によってはNGワードがありますので、どこの地域に依頼するか決まったら宗派やNGワードは事前に調べておくと良いでしょう。

２－４－６．法律の理解不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★☆☆

【期日】★☆☆☆☆

【品質（信用）】★★★★★

＜失敗＞

現地の法律の知識なく契約を交わした際に契約法に違反しており、裁判沙汰になるケースです。裁判沙汰になると自社でも対応に追われて無駄なリソースが発生します。

＜対策＞

特に気にしないといけないのは契約法でしょう。国によって契約の成立や解釈、違反等の対処方法が異なります。契約する予定の国の契約法は事前に調べておきましょう。日本企業と契約するときは日本の契約法に基づくので普段気を付けていることを抑えれば問題ないでしょう。日本は社会全体の利益を重視しますが、海外は個人の権利や自由を重視した判決になります。

２－４－７．コンプライアンスの理解不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★★★☆☆

【期日】★☆☆☆☆

【品質（信用）】★★★★★

＜失敗＞

法律を遵守しているから安心しきっていたが、目に見えない社会的ルールを違反して、裁判沙汰になるケースです。裁判沙汰になると自社でも対応に追われて無駄なリソースが発生します。

＜対策＞

法律だけでなく、社会的ルールについても国によって異なりますので、事前に調べておくと良いでしょう。例えば、日本では伝統的な価値観や倫理観が強く、企業の行動規範や倫理規定を重視する傾向がありますが、他国では家族やコミュニティが重視され、そうした文化的な要素がビジネスにも影響を及ぼすことがあります。

２－４－８．治安悪化による失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

治安・社会情勢が不安定な国の場合、為替変動による影響を受ける可能性が高くなります。また、ボイコットや開発スピードも遅くなり、すべてにおける失敗に繋がることもあります。

＜対策＞

依頼する予定の国の治安・社会情勢の現況について調べておきましょう。

外務省のホームページで各国の危険度について、レベル分けされています。

≪　外務省危険レベルマップ　≫

２－５．ブリッジSEの能力不足

オフショア開発で失敗する原因はブリッジSEの能力不足によるところが大半を占めています。今回依頼する予定のプロジェクトにどのようなブリッジSEがアサインされるのか発注前の段階で確認しておくことをおススメします。具体的にブリッジSEのどのようなところを見ておけば良いのかここでは紹介します。

※記事中に出てくるN1、N2…は日本語能力試験の認定レベルを指しています。

２－５－１．日本人以外のブリッジSEを採用して失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

日本語が堪能だから、、N1の資格を持っているから、、確かに事前の打ち合わせでは問題なく意思疎通はできたので問題ないだろうと高を括って実際に開発が進んだら細かいところの意思疎通やニュアンスの微妙の違いがうまく伝わらずに結果的に期日や品質の失敗に繋がるケースです。

＜対策＞

日本人ブリッジSEを配置できる会社を選びましょう。アプリの操作性も国によって微妙に異なります。例えば、日本であればポップアップが出るけど、発注先の国ではポップアップを出さないのが当たり前とか、日本のアプリに慣れている人から見たら微妙な違和感を感じます。そんな違和感の積み重ねが結果的にアプリの品質にも繋がっていきます。

２－５－２．担当ブリッジSEの言語能力不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★★☆

＜失敗＞

どうしても日本人以外のブリッジSEを採用しないといけなくなり、N1の資格を持っているという情報だけを頼りにして、実際に開発を進めていく中で細かいニュアンスが伝わらずに結果的に操作性の違い等思ったものと違うものが仕上がり、品質の失敗に繋がるケースです。

＜対策＞

どうしても日本人以外のブリッジSEを採用せざるを得ないときは、日常会話ができるのか、開発用語も日本語でちゃんと理解してくれているか、打ち合わせを通して言語能力を確認しましょう。対面よりもWEB会議の方がコミュニケーションが取りづらいので、あえてWEB会議で試してみるのも良いでしょう。とはいえ、日本人のブリッジSEを採用してくれる会社をギリギリまで粘って探したほうが良いです。それほど重要です。

２－５－３．担当ブリッジSEの技術能力不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★★☆

＜失敗＞

稀にSE未経験者でコミュニケーションに長けているからといってブリッジSEを名乗っている人がいます。これは日本人でも考えられます。そんな人と技術的な話をしても細かいところがその人に伝わりません。はいはい言っているだけで分かった振りをしている可能性もあるでしょう。結果的に品質の失敗に繋がるケースです。

＜対策＞

その人がどこまで技術的知識を持っているか事前の打ち合わせの中で探ってみましょう。このケースの場合はどうしていますか？等、はい・いいえでは言い逃れできないような質問をぶつけるとより明確に推し量ることができるでしょう。

２－５－４．担当ブリッジSEの実績不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★☆☆

＜失敗＞

コミュニケーションも上手だし、技術的な話もできるので問題ないと思い、進めたところ今回お願いする分野の開発実績がゼロであり、細かいところの指示が伝わっておらず、結果的に操作性の違い等思ったものと違うものが仕上がり、品質の失敗に繋がるケースです。

＜対策＞

その人の開発実績、SEとしての実績やブリッジSEとしての実績で具体的にどんなシステムを開発したことあるのか実例を紹介してもらうようにしましょう。その時に使用した言語についても確認するとより具体的に把握することができます。

２－５－５．担当ブリッジSEの理解不足による失敗

＜失敗レベル＞

【総合】★★★☆☆

【予算】★☆☆☆☆

【期日】★★★☆☆

【品質（信用）】★★★★☆

＜失敗＞

担当者によっては分からないのにはいはい言って分かっている振りをしている人もいます。その人がすべて理解している＝伝わっていると思っていたが、実は分かってないところが多く、結果的に品質や期日の失敗に繋がるケースです。

＜対策＞

今回のプロジェクトの目的、最終的にどんなものを作りたいのか、何のために作るのか、作ったものをどうしたいのか、要件定義の内容をブリッジSEにもしっかりと共有して進む方向性を合わせましょう。伝えるだけでなく、それをちゃんと理解しているか確認をしながら進めるとより良いものが出来上がると思います。

２－５－６．担当ブリッジSEとの性格不一致による失敗

＜失敗レベル＞

【総合】★☆☆☆☆

【予算】★☆☆☆☆

【期日】★☆☆☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

担当ブリッジSEとウマが合わずにお互いに毎日ストレスを抱えながらコミュニケーションを取るケースです。関係性がギスギスしていき、言いたいことも言えずに結果的に品質や期日の失敗に繋がります。

＜対策＞

今回のプロジェクトの目的、最終的にどんなものを作りたいのか、何のために作るのか、作ったものをどうしたいのか、要件定義の内容をブリッジSEにもしっかりと共有して進む方向性を合わせましょう。伝えるだけでなく、それをちゃんと理解しているか確認をしながら進めるとより良いものが出来上がると思います。

２－６．発注側の管理不足

依頼先に投げっぱなしではうまくいきません。発注者側もどのような体制で当該プロジェクトを管理していくか、事前に決めておきましょう。具体的にどのような点に注意すれば良いかここでは紹介します。

２－６－１．発注内容・範囲が粗笨による失敗

＜失敗レベル＞

【総合】★★☆☆☆

【予算】★★★☆☆

【期日】★★★☆☆

【品質（信用）】★☆☆☆☆

＜失敗＞

曖昧なまま発注したい内容・範囲を伝えて、結果的に思っていた内容・範囲と違う形で納品され、修正を繰り返していくうちに予算や期日の失敗に繋がるケースです。

＜対策＞

国内の開発チームと、オフショア開発チームの双方が同時進行で開発を進める場合、ソースコードが重複することがあります。それを避けるためにフロントエンドとバックエンドで分担を分ける、機能モジュールで分担を分けるといった点を明確にすることで失敗を避けることができるでしょう。事前に見積書のやり取りもあると思いますので、見積書の内容で精査することもできます。

２－６－２．契約書の内容が粗笨による失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★☆

＜失敗＞

契約書の内容をしっかりと確認せずに進めた結果、開発途中でトラブルが起きたときに多額の人件費を請求されるケースや納品形態が思ったものと異なる形で納品され、品質や期日の失敗に繋がります。

＜対策＞

海外を相手にするので、場合によってはすべて英語で書かれていることもあります。英語が苦手な場合は日本語で対応してくれる会社を選びましょう。以下の点は必ず確認してください。明確な記載がない場合は盛り込んでもらうように伝えてください。

• 金額
• 納期
• 支払日と取引通貨
• トラブルが発生した時の補償範囲
• 納品形態のファイル形式
• 納品後のアフターフォローの内容
• 納期に間に合わなかった時の責任の所在

２－６－３．要件定義・仕様の内容が粗笨による失敗

＜失敗レベル＞

【総合】★★★★★

【予算】★★★★★

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

曖昧なまま要件定義や仕様の内容を決めて、進めると相手に細かい内容が伝わっておらず、細かいところの動作・操作性・デザイン性の認識の齟齬が生まれます。それが結果的に品質の悪さに繋がり、修正＆修正を繰り返していくうちに予算・期日にも影響を及ぼし、すべてにおいて失敗するケースです。

＜対策＞

２－１－１の要件定義時のディスコミュニケーションの項とリンクしますが、発注内容をいかに細かく伝えるかでそのプロジェクトの運命が決まります。「こんな感じでよろしく」のような曖昧な表現ではなく、1つ1つ丁寧に伝えることが大事です。時間は掛かるかもしれませんが、ここを怠慢してしまうとトラブルのもとになり、余計に時間が掛かります。急がば回れです。

２－６－４．進捗管理を怠慢して失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★★☆

【期日】★★★★☆

【品質（信用）】★★★★☆

＜失敗＞

進捗管理を発注先にお任せして、自分自身では開発のどのフェーズまで進んでいるか把握していないときに気づいたら開発が予定よりも遅れているときがあります。それが結果的に期日の失敗に繋がるケースです。

＜対策＞

発注先と定期的に連絡（できれば毎日数十分でも）を取って進捗確認をするようにしましょう。例えばその日に終わっているべき開発が終わっていないことが確認できたら、人を増員してもらえないか、どこかの開発を妥協するか、もしくは遅れている部分だけ後回しにするか、相談しながら進めましょう。そこで発生する追加費用については、契約書に基づいて対応するようにしましょう。

２－６－５．フィードバックの内容が粗笨による失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★☆☆

【品質（信用）】★★★★☆

＜失敗＞

要件定義ではしっかりと細かいところまで伝えているのでよしっ！と思い、開発中のフィードバックをざっくりとした伝え方で、気づいたら開発の方向性がズレているケースです。結果的に最終形が思っていたものと違うものが納品され、品質における失敗に繋がります。

＜対策＞

要件定義だけでなく、開発中の管理や事細かに伝えることを癖付けるようにしましょう。要件定義で細かく定義付けできているあなたならできます。

２－６－６．完成品の事前確認を怠慢して失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★☆☆

【品質（信用）】★★★★★

＜失敗＞

発注先の品質を信頼しきって、リリース前の最終確認を自分自身でほとんどしなかった結果、リリース後にユーザーから多くのクレームを受けて、会社の信用が落ちてしまい、品質（信用）の失敗に繋がるケースです。

＜対策＞

発注先の会社でももちろん品質チェックをしますが、自社でもチェック要員を数名用意して納品されたものの品質チェックをしましょう。ユーザーは様々な環境からアクセスするケースが想定されます。チェックする母数が多いほど様々な環境でチェックができるので、集められるだけ集めて1人10分程度でも時間を取って触ってもらいましょう。

２－６－７．発注側の管理体制不備による失敗

＜失敗レベル＞

【総合】★★★★☆

【予算】★★★☆☆

【期日】★★★★★

【品質（信用）】★★★★★

＜失敗＞

発注側が担当者1人しかアサインできず、その担当者が体調不良や休暇日にトラブルが発生し、収拾がつかなくなりトラブルがどんどん波及してしまうケースや進捗が遅れていることに気づくのが遅れたり、品質が悪いまま開発が進んでしまうケースです。結果的に期日・品質の失敗に繋がります。

＜対策＞

発注側も発注以降もしっかりとプロジェクトの管理をする必要があります。進捗管理、品質管理が自社でもできる体制を構築しておく必要があります。イチ担当者が不在や休暇の時は誰が対応するとか、出来上がったものに対しての品質チェックは誰がどの部分をチェックするとか、予め決めておきましょう。自分たちで実施することで、自己防衛にも繋がります。

３．オフショア開発で失敗しないチェックシート（50個）

本記事のチェックシートを使うことで、50の失敗をクリアしているか一目でわかります。すべての項目にチェックがつく会社選定・事前準備をすれば失敗するリスクを限りなくゼロに近づけることができるでしょう。

チェックシートをダウンロード

まとめ

ここまで50の失敗と対策を取り上げてきました。失敗はゼロにすることはできませんが、限りなくゼロに近づけることはできます。ここには書いていない失敗を経験したことある人がいるかもしれません。

そんな人からこんな失敗を経験したことあるよ。を募集しています。

意見を投稿する

オフショア開発で失敗するリスクを限りなくゼロに近づけたい人は、弊社が少しでもお力になれればと思います。

是非お気軽にお問合せください。