オフショア開発は失敗しやすい？よくある失敗パターンの原因と対策を解説

IT人材の不足やコストメリットから、海外に業務を委託するオフショア開発に目を向ける企業は少なくありません。しかし、期待した効果を得られず、結果的に失敗してしまうケースがあります。この記事では、オフショア開発初心者の方や一度失敗したことがある方に向けて、失敗例をもとに原因と対策を紹介します。
スパイスファクトリーはフィリピンにオフショア拠点を持ち、徹底した品質管理と円滑なコミュニケーションで「ハイクオリティオフショア開発」を提供してきました。オフショア開発に関する具体的な相談がある方は、ください。
以下の記事も参考にどうぞ。
オフショア開発会社の選び方とは？確認すべきポイントを解説

オフショア開発のよくある失敗例

オフショア開発を進める中で「これなら日本国内で開発した方が良かったかも……」という結果になってしまうことは残念ながらよくあります。この章では、オフショア開発のよくある失敗例を紹介します。

成果物が低品質

納品されたプロダクトやサイトの品質が想定以上に低いのは、オフショア開発でよくある失敗のひとつです。
たとえば、以下のようなケースが考えられます。

• • 正常に動かない
  • 表示崩れがある
  • 必要な機能がない
  • 想像していたデザインと違う

成果物が低品質なのは、エンジニアの質が低いという原因だけではありません。
事前に明確な仕様を伝えていなかったり、依頼側としてはよしなにやってくれると思っていたが、期待と違っていたりといったケースもあります。
オフショア開発のメリットとして比較的コストを抑えられると知られています。しかし、上記の通り品質に関わる失敗例が多いため、オフショア開発に安かろう悪かろうのイメージを持っている人も少なからず存在するのが現状です。

納期が守られない

スケジュール通りにプロジェクトが進まず、納期が遅れるのもオフショア開発でよく聞く失敗のパターンです。
納期遅れの理由としては、初期のスケジュール設計の際に要件が整理されておらず、後から追加の開発が必要だと判明する、という国内でもよくあるケースが挙げられます。
また、残業してまで納期に間に合わせようという感覚がないといった、納期にややルーズな文化がある国も存在するため、管理がうまくいかず遅延につながる場合もあります。

予算をオーバーしてしまう

日本国内での開発でも同様ですが、請負契約の場合は基本的にプロジェクト期間中の仕様変更ができません。
追加機能など後から必要な開発が増えると、想定以上に費用がかかってしまうでしょう。
オフショア開発では、言葉や文化の壁による品質低下や納期遅れをカバーするために、追加費用が必要となることも考えられます。さらに、経済・為替の状況で単価が高騰するといった外部環境に影響を受けて予算を超えてしまうケースもあります。

また、オフショア開発ではプロジェクトの立ち上げ時にイニシャルコストがかかります。
メンバーの構成やルールの明文化などの体制構築やコミュニケーションに時間がかかるためです。
上記から、短期間のプロジェクトではオフショア開発のコストメリットを享受できないこともあります。

なぜオフショア開発は失敗するのか

前の章で紹介した通り、オフショア開発にはよくある失敗パターンがあります。なぜそのような失敗が起きてしまうのでしょうか。ここではその原因を解説します。

コミュニケーションの行き違い

コミュニケーションの行き違いはオフショア開発において最もよく起こる、かつ根深い問題の1つです。
言語が違うだけでなく、文化や商習慣にもギャップがあり日本の常識が通用しません。
お互いの「普通」の感覚がズレているため、行き違いが生じてしまいます。
さらに、コミュニケーション齟齬の内訳として 3点ご紹介します。

言語の違いから起きる行き違い

母国語を使わない会話では、どうしても細かい部分を伝えられません。
相手の言葉を間違って理解してしまうこともあるでしょう。
オフショア開発では、要件定義書を用意して開発先に渡し、現地でブリッジSE や PM などが現地語または英語に翻訳して作業するといった形がとられます。その翻訳時に、誤訳や誤読があると、依頼側の意図とは異なる仕様で開発が進むというミスが発生します。

文化の違いから起きる行き違い

生活習慣や商習慣など、文化の違いからも行き違いが発生します。
日本人には「よしなにやる」「阿吽の呼吸」に代表されるように、相手の意図を汲み取って柔軟に仕事を進めることがよくあります。しかし、基本的に外国籍のメンバーには「そのあたり、うまくやっといてください」などの曖昧な指示は通用しないと考えておくべきでしょう。「そのあたり」とは何か、「うまくやる」とは具体的にどういうことか、「いつまでに」するのかを具体的に伝える必要があります。

他にも、仕事に対する価値観や年中行事の違いにも注意が必要です。
たとえば、フィリピンではクリスマスなどのイベント近くでは「家族」の優先順位が仕事を圧倒的に上回り、ベトナムではとりわけテト（旧正月）を大事にします。当然ながら国民の祝日も日本とは異なりますので、スケジュールを決める際には注意が必要です。

物理的な距離から生じる行き違い

物理的な距離から生じる行き違いも存在します。
拠点としている国と日本との時差によっては、必要なタイミングでのクイックな連携は難しいでしょう。
対面コミュニケーションには細かなニュアンスを伝えやすかったり、気軽にコミュニケーションが取れたり、雰囲気などの非言語情報を得やすいなどのメリットがあります。
海外にチームがある場合、どうしてもこのメリットを受けにくい体制となるためコミュニケーションに行き違いが発生しやすくなります。

管理体制の未整備

言語や文化差・距離によるコミュニケーション齟齬は、どれだけ配慮しても完全になくすことが難しい問題といえるでしょう。
オフショア開発ではそうした違いを前提としたうえで、品質を担保するための管理体制の構築が重要となります。
この管理体制がうまく機能しない場合も、失敗を引き起こしてしまいます。
以下に管理体制の構築がとくに必要な領域をご紹介します。

コード品質の管理

オフショア開発においては、依頼側が認識しているレベルのコード品質が担保できるように、レビューやテストなどの体制整備が欠かせません。
エラーが出ないか、といった一般的なシステムテストの実施はもちろん、単に動くだけでなくメンテナンス性を考慮したコード品質の管理体制が重要です。
コード品質の管理体制が機能していない場合、仕様書通りの動作はするもののパフォーマンスが悪かったり、リリース後に多くのバグが発生したりといったことが懸念されます。

プロジェクトマネジメントの体制不備

先述の理由からコミュニケーションの行き違いが起こりやすいオフショア開発においては、国内での開発以上にプロジェクトマネジメントが重要といえるでしょう。
言語や文化の違いを踏まえて、余裕を持ったスケジューリングや突発的なトラブルへの柔軟な対応が求められます。
たとえばベトナムでは「就社」ではなく「就職」の意識が強いといわれています。
今の会社でスキルを身につけ、成果を出して早く次の会社に転職して給料を上げたいと考えているため、プロジェクトの途中で担当エンジニアが変わるといったことはめずらしくありません。
そのような場合でもプロジェクト自体の遅延等が発生しないようにあらかじめ引き継ぎがしやすいような体制やチームメンバーがフォローしあえるようなルール・仕組み作りが大切です。
この点が体制として担保されていない場合、体制維持が難しくなりプロジェクト進捗や品質に影響を及ぼします。

失敗しないための対策

ここまで、オフショア開発のよくある失敗とその原因について確認してきました。
この章では、失敗を避けるために取るべき対策について解説します。
請負契約で自社がオフショア開発拠点をマネジメントする必要がない場合もプロジェクト成功のために協力は必須です。どういった点で協力できるのかを確認しておきましょう。
また、ベンダー選定の軸として、以下で紹介する内容ができている会社か確認をすることをおすすめします。

ラボ型の場合

ラボ型オフショア開発の場合、オフショアメンバーが依頼する企業側のチームに参画するため、依頼企業側が直接マネジメントに入るケースが多いでしょう。
マネジメントにあたり、以下のような対策が必要です。

文化差の理解

基本として、文化差への理解と対応が必要です。
言語の違いはもちろん、日本の働き方の常識は通用しないことを前提としたうえで、協力して業務を進められる体制を構築します。

また、時差に関しては修正ができないため、気になる場合はフィリピンなど日本との時差の少ない（フィリピンは時差1時間）オフショア拠点を持っている企業に依頼することを検討しても良いでしょう。

ドキュメント化の徹底

コード規約や各種ルール、決定した仕様、その他技術的なナレッジも含め明確にドキュメント化して共有しましょう。
仕様や決定事項が明文化されれば、認識の行き違いを小さくできます。
仕様や技術的知見を蓄積しておくことで、万が一引き継ぎが発生した場合も柔軟な対応がしやすくなります。

ブリッジSE ・ QAエンジニアなどの参画でコードレビュー・機能テストを実施

オフショアメンバーに必要なコードの品質を理解してもらうことも重要です。
先述したドキュメント化でルールや共通認識を定めるのに加え、QAエンジニアによるテスト・機能チェックやブリッジSE によるコードレビューで品質の担保と基準レベルの共有を行えます。
※参考記事①：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説
※参考記事②：QAエンジニアの重要性とは？システム品質を保つプロが求められる背景や役割を解説

可能な限り仕様の具体化

曖昧な情報から忖度して仕事を進めるのは、日本人ならよくあることです。しかし、これまでにお伝えしたとおり、オフショア開発においてこういった仕事の進め方は通じません。
そのため、日本側のメンバーで可能な限り仕様を具体的にしたうえで着手してもらうといった、依頼者側の工夫も必要です。

請負型の場合

請負型の場合、開発を依頼された側の企業がオフショア拠点を管理します。
実際の対策については基本的にラボ型の場合と共通です。加えて、直接管理を行わない依頼企業として、失敗を引き起こさないために協力できる点を以下で紹介します。

要件の具体化・明確化

曖昧な仕様が伝わらないのは先述のとおりです。
依頼側としても要件を明確にして提示することで認識の行き違いを減らせます。
直接的な管理をしないからと任せきりにならず、具体的にしてドキュメントなどで行き違いがないように伝えましょう。

企業選定時に実績等を確認しておく

日本国内でも同様ですが、依頼するシステムや制作物の類似案件を手掛けているなど、実績を把握しておくことで品質レベルが推し量れます。
依頼しようとしているシステムの類似案件の実績がある企業を選べば、失敗のリスクを下げられるでしょう。

どのような対策をしているか確認する

本記事で紹介してきた課題に対し、どのような対策を講じているのか聞いてみることをおすすめします。
何らかの対策ができている企業であれば、快く対策内容を教えてくれるでしょう。
何の対策もされていない場合は、依頼を考え直すことも必要です。
体制に不安が残る企業への依頼を避ければ、オフショア開発で失敗するリスクを減らせるでしょう。

課題はどの会社も抱えている

オフショア開発を実施する場合、大小の差はあれど、どの企業も今回ご紹介したような課題を抱えているでしょう。
重要なのは課題がないことではなく、課題に対して適切な対策を講じることができているかどうかです。
当社スパイスファクトリーでは、社内QAエンジニアによる「機能レベルの外部品質担保」とブリッジエンジニア／エンジニアリングマネージャーの 2重レビューによる「コードレベルの内部品質担保」、現地駐在責任者によるマネジメント体制構築や CTO による直接の技術指導、などを実施してオフショア開発の課題解消に取り組んでいます。
オフショア開発の依頼を検討している方はください。
本記事の内容が皆様のお役に立てれば幸いです。

オフショア開発