オフショア開発ガイド » 知られざるオフショア開発の失敗事例

知られざるオフショア開発の失敗事例

オフショア開発の浸透に伴い、成功事例だけでなく失敗事例も多数報告されるようになっています。これからのオフショア開発の命運を分けるのは、失敗から学ぶかどうか。オフショア開発の失敗事例とその対策を2つ紹介します。

失敗事例1:大量のコーディング規約違反が発覚

パトロールカー

大量のコーディング規約違反もベンダー側は修正に乗り気でなく…

複数人でコーディングする際、可読性や保守性を高めるために作成されるコーディング規約。事前に取り決めたにもかかわらず、納品物を確認すると大量のコーディング規約違反が見つかったという事例がありました。コーディング規約に違反していてもプログラムの実際の動作には影響がないこともあり、テストでは気づかれにくいのです。将来の保守のことを考えると違反個所を修正する必要がありましたが、ベンダー側は修正に乗り気でなく、温度差が生まれてしまったといいます。

失敗の原因

コーディング規約の重要性共有が足りなかった

コーディング規約は可読性や保守性を高めるために作成するものであり、違反していても問題なく動作してしまうことがあります。そのためにベンダー側は「動くのならいいじゃないか」という認識になってしまっているのです。日本人技術者ならこれくらいのことは指示書から読み取ってくれるだろう、というところも、文化が大きく違う海外のエンジニアには伝わらないことがあります。

オフショアライド編集部が見る
失敗から学ぶ対策

目的を伝え、チェック項目を明確・細分化

「なぜこの規約を作ったのか、なぜ守ってほしいのか」という目的を共有する必要があります。重要性をしっかりと認識してもらい、確実にチェックしてもらうように依頼しましょう。チェックを依頼する際は、「規約違反をチェックしてください」と作業的に指示するのではなく、規約一つひとつに対するチェックリストを作成し、見てほしい項目を明確化するほか、目的意識を醸成すると効果的です。

失敗事例2:遅延し続ける納期

時計

納期遅れの日数が知らない間に4倍に…

毎日TV会議をすることで現地の進捗状況を把握していたとある企業。早い段階で遅れが出ていたので、挽回可能かどうかを尋ねたところ、開発側は問題ないと回答してきました。しかし、その後も遅れは取り戻せないまま予定の納品日を迎えてしまい、いつ納品できるのかを聞いてみて驚きました。当初は1日分ほどの遅れだったはずが、4日分の遅れに拡大していたのです。依頼主と現場をつなぐ役割のブリッジSEに対応を依頼して現場に頑張ってもらいましたが、結局、納品されたのは予定の一週間後でした。

失敗の原因

タスク管理が甘かった

この企業は毎日進捗確認をしており、最低限のタスク管理はできていたと思われます。しかし、日本と海外の開発現場は距離が離れている都合上、実際の現場の雰囲気は中々つかめません。現場の「大丈夫」が本当に大丈夫なのかが把握できなかったのです。

オフショアライド編集部が見る
失敗から学ぶ対策

工程を細かく分けて定量的な進捗管理を

日本から現場の空気感をつかむことには限界があります。そこで導入するべきなのが客観的に判断できる定量的な進捗管理。必要な工程を細かく分けてチェックリストを作成し、今どの段階にいるのかを確実に把握できるようにしましょう。国によっては時間にルーズな文化があることもあり、精神論で納期を守ってもらうことは難しいものです。日本側でしっかりマネジメントすることが重要です。

その他のよくある失敗事例

コミュニケーションの不足

オフショア開発において、様々な情報や認識を現地と共有するために欠かせないことは、何よりもまずコミュニケーションです。言い換えれば、コミュニケーションが不足することで、規約違反や仕様の不備、開発スケジュールの遅延といったトラブルも発生し、深刻化します。

プログラミング言語は世界共通ですが、それを扱うエンジニアの使用言語や労働意識は国や地域によって様々です。そのため、開発国の特性や人材の個性を認識した上で、コミュニケーションを充実させることが欠かせません。

低品質な製品

完成した製品の質が想定よりも悪かったというトラブルは珍しくありません。

気をつけなければならないのは、それが明らかに仕様書と違っていれば相手側の責任ですが、仕様書で書かれている内容を最低限クリアしている場合、契約上は問題ないという点です。

日本では暗黙の了解やサービス精神によって、開発側が自主的に品質を向上させたり、改善案を提示してくれたりすることもありますが、海外のビジネス現場ではあくまでも「仕様書に書かれていること」が全てです。そのため、仕様書や契約書を作る時は必ず詳細を記載し、また解釈の違いが生じないよう注意しなければなりません。

開発会社の選定失敗

そもそもプロジェクトを委託する開発会社のレベルが低ければ、どれほど仕様書や開発管理に注意していても満足な結果は得られません。また、所属エンジニアのレベルは高くても、会社の体質に問題や制限があれば、彼らの能力を充分に発揮することが難しくなるでしょう。

加えて、きちんと海外取引を行う上でのコンプライアンス意識があるかどうかといった、企業としての姿勢も重要です。

その他、開発国の社会体制や法規制、為替状況など、国家間での影響も考える必要があります。

予想外の出費・コスト増

オフショア開発の失敗事例としてしばしばあるのが、結果的に思っていたよりもコストを抑えられなかったというものです。

仮に人件費が安くても、小規模案件であればコストメリットが得られず、むしろ諸経費がかさんで総費用が高くなったというケースがあります。

また、費用の安さばかりを優先した結果、低品質な製品を修正する追加費用が生じたり、開発国の発展と共に物価や人件費が高騰したりという問題もあります。 そのため、オフショア開発ではコストだけに注目するのでなく、常に総合的なコストパフォーマンスを考慮することが必要です。

オフショア開発を成功させるポイント

コミュニケーションをルール化する

言語や文化、風習の異なる海外企業や外国人エンジニアと連携して開発を進める場合、円滑なコミュニケーションを進めるための工夫が重要です。

そのため、現地のことを正しく理解しているブリッジSEを活用したり、自社の社員を現地へ送って実際の現場を確認したりするだけでなく、定期的な連絡や報告方法の統一といった、コミュニケーションのルール化も欠かせません。

また、相手国との時差や特性を考慮して、常に最新の情報を適切に共有できるようなシステムを構築することも大切です。特に、例えば中国など既存のSNSや通信ツールが制限されている国では、きちんと通信システムを整備するコストについても検討しておきましょう。

文化や習慣といった相性を考慮

どれだけ開発国の文化や風習を理解しようとしても、根本的に自社のビジネススタイルとかけ離れた相手との契約では、必ずどこかに不備が生じてしまいます。その他、人件費は安くても、国によっては福利厚生について法規制が厳しい国があり、結果的にコストが増大するケースもあります。

そのため、日本人の働き方や考え方に似たエンジニアが多く、また現地の法律が分かりやすい国など、自社との相性を考えて委託先を選ぶことが必要です。

実績を客観的にチェック

新しく開発企業を選ぶ上で、日本企業との開発実績や、オフショア開発への取り組みなどを確認することは欠かせません。また、国際的な認証取得やエンジニアの取得資格といった客観的な指標も重要です。

その他、所属エンジニアに対する教育制度が充実しているかどうかも、注目しておきたいポイントでしょう。

契約方式を検討

オフショア開発では、プロジェクト単位で発注する受託型開発の他にも、専属の開発チームを現地へ作るラボ型開発といった契約方式があります。

受託型開発やラボ型開発にはそれぞれメリット・デメリットがあり、自社プロジェクトに対してどちらが適しているのか事前に検討することは、オフショア開発を成功へ導くための最重要課題の1つです。

失敗原因を理解して適切な対策を!

オフショア開発での失敗は、日本と海外との違いを考慮せず、また現地とのコミュニケーション不足が原因で生じることが少なくありません。

オフショア開発を成功させるには、開発企業の実績や人件費といった数字だけに注目するのでなく、積極的に現地の特性を理解して、円滑なコミュニケーションの実現に取り組んでいくことが肝要です。

B!ブックマーク Twitter Facebook LINE