Contents
はじめに
オフショア開発はコスト削減やエンジニアのリソース不足の解消、技術力の活用を目的として採用を行う企業が増えています。他方でオフショア開発では失敗事例やネガティブな印象を持たれることが多く、リスクを感じる人も多いのではないでしょうか。実際にプロジェクトを成功に導くためには多くの課題を解決しなければなりません。本記事では、オフショア開発の管理やコンサルティング経験のある筆者がオフショア開発でよくある失敗事例を紹介し、その為の対策をお伝えします。
オフショア開発で失敗するポイント
オフショア開発で失敗する事例としては以下のようなポイントが多いです。
- コミュニケーションの障害
- プロジェクト管理不足
- 技術スキルのミスマッチ
- 成果物に対する期待値の相違
- 業務・業界知識の不足
コミュニケーションの障害
オフショア開発におけるコミュニケーション不足はよくある失敗例の一つです。コミュニケーションで課題の出るポイントを具体的に見ていきましょう。
- 言語の違い
-
開発チームが異なる言語を話す場合、意思疎通に問題が生じることがあります。技術的な用語や微妙なニュアンスが誤解されることが多いです。特に言語特有のニュアンスの違いも問題になるケースがあります。日本語や日本人のコミュニケーションは行間を読むなど抽象的で曖昧な表現も多いため、他言語とのコンフリクトが起こりやすいため注意が必要です。
- 文化の違い
-
文化的背景が異なると、仕事の進め方やビジネス慣習に違いが出てきます。これが原因で誤解や不満が生じることがあります。文化によっては休みを取らなければならない期間が発生するケースもあるので確認が必要です。また、タスクやスケジュール、品質に対する価値観や進め方が異なるケースがあるため、これに対する目線合わせがチーム作りにおいて重要です。
- タイムゾーンの違い
-
開発拠点によりますが、時差によりリアルタイムでのコミュニケーションが難しくなるケースがあります。それにより問題解決の遅れや進捗確認の遅延が発生します。JiraやAsanaなどプロジェクト管理ツールを利用した適切なタスク管理と非同期でも行えるSlackやWikiツールによる情報共有が重要です。
コミュニケーション不足を解消するためには、ツールを活用したプロジェクト管理も重要ですが、その前段でオフショア拠点の文化や言語特性の違いを意識することが重要です。
プロジェクト管理不足
オフショア開発に限らずですが失敗例の一つとして、プロジェクト管理の不足と作業の見える化が不十分であることが挙げられます。このような状況では、以下のような問題が発生することが多々あります。
まず、プロジェクトの進行状況を把握することが困難になります。タスクの進捗や各メンバーの作業状況が明確でないため、プロジェクトリーダーやマネージャーが全体の進捗を正確に把握できず、適切な指示やサポートが行えなくなります。結果として、見積工数を超過する稼働が発生し、スケジュールの遅延に繋がります。
さらに、作業の見える化が不十分な場合、問題が発生しても早期に発見することが難しくなります。例えば、技術的な問題やコミュニケーションの障害が発生しても課題の検知がが遅れるため、対策が後手に回りがちです。この結果、知らず知らずのうちにプロジェクトで大きな問題を抱えたまま進行され、気づいた頃には取り返しのつかない状況になることも。
これらの問題を防ぐためには、プロジェクト管理ツールの運用や定期的な進捗報告の実施、タスクの明確化といった対策が不可欠です。また、作業の見える化を徹底し、リアルタイムでの進捗管理を行うことが重要です。具体的な進捗率や作業内容を詳しく報告してもらうことで、潜在的な課題を事前に解決することに繋がります。タスクだけ渡して管理をエンジニアに任せる体制は避けていきましょう。
技術スキルのミスマッチ
技術スキルのミスマッチは、オフショア開発において品質の低下やプロジェクトの遅延を引き起こす大きな原因にもなります。期待する技術スキルを持たない開発チームにプロジェクトを委託すると、成果物が基準に達しない可能性があります。
これを防ぐためには、開発チームのスキルセットを事前に評価し、試用期間を設けてスキルを確認することが重要です。また、チームとしてオンボーディングのため十分な期間のトレーニングを提供し、必要な技術スキルを持つリソースを確保することで、スキルミスマッチを防ぐことができます。多くのオフショア企業では数カ月間のトレーニングを経て案件にアサインする体制が組まれています。
また、国によってプログラム言語のシェアが異なるため、国とプログラム言語の組み合わせによっては経験が十分にないことも可能性として出てきます。事前に国別の特性を把握しておきましょう。
成果物に対する期待値の相違
オフショア開発チームとの間で、成果物の仕様や品質に関する認識が一致していない場合、納品物が期待に応えられず、不満が生じることがあります。これを避けるためには、プロジェクトの初期段階で詳細な要件定義を行い、期待する成果物の仕様や品質基準を明確にすることが重要です。
また、非機能要件などパフォーマンスに関わる内容も事前に合意をしておく必要があります。筆者の経験則でもオフショア開発ではSQLの設計が十分でなかったり、その場しのぎのjavascript実装によりパフォーマンスが低下するなど多くの課題を発見してきました。これらはDB設計の目線合わせやコーディングガイドラインの周知徹底、静的解析ツールの導入を進めることで改善を図ることができます。
QAチームを現地へ配置し受け入れ基準を事前に定義し、オフショア開発チーム側で最低限の品質を担保するような体制が理想的です。その上で日本側で受け入れテストを行うことで、全体として品質の向上に繋がります。
業務・業界知識の不足
オフショア開発チームがクライアントの業界やビジネスの特性の理解が不足しているケースはプロジェクトに大きな影響を与える恐れがあります。これには多くの原因が考えられます。
- 前提知識の説明不足
-
オフショア開発チームに対して、これから作るモノに対する前提知識の説明が不足しているケースです。単純にタスクだけを渡すような関係性になっているとそのような前提知識が不足し、成果物の意図や目的を理解できず、誤ったものが開発されるリスクがあります。
- 現地での文化的な背景による前提知識の不足
-
日本では一般的なモノや仕組みであっても他国では想像もつかないケースも出てきます。食文化が異なり、日本では一般的な食べ物であってもそれを詳しく知らなかったり、日本人では想像のしやすい業務内容でも、他国では存在しない業務もあったりします。これについては説明しても解像度高く理解することが難しいケースもあるので特に慎重な説明が必要です。
- 日本人でも理解に時間のかかる要件・仕様
-
日本人同士でも理解に時間がかかるような複雑なロジックや仕様は、他言語を介してオフショア開発チームに説明を行うのがより難しくなります。難易度によっては一部日本側でモジュールを切り出して開発を行うことも検討が必要です。
プロジェクト開始前に前提知識や業務内容を詳細に共有し、必要なトレーニングを提供することが重要です。また、開発チームとクライアントの間で定期的な知識共有セッションを設け、業界特有の要件や期待を明確に伝えることも効果的です。現地メンバーに出張してもらうなど、そのシステムが使われる現場を見てもらうことも中長期的に重要な投資です。
失敗事例
ここから実際の失敗事例とその原因をご紹介します。
いずれもオフショア開発チームを起点にした説明ですが、本質的は日本でのプロジェクト管理、設計スキルなどが原因になっているという日本側で解決できる課題が大きいです。
失敗事例を読んでいただくにあたり、「日本側でできたことはないか？」を考えながら読み解いてみてください。
大量のデータや高度なデータ分析を要するシステム開発
ある開発チームでは新規のサービス開発として大量のデータ分析ロジックを含むシステムの開発が行われていました。体制としてブリッジSEが日本側におり、オフショア開発拠点で実際の開発を行うという体制が取られています。このプロジェクトはスケジュールが非常にタイトな中で進行されました。プロジェクトの流れとしてはブリッジSEがクライアントから業務要件やデータ分析のロジックを詳細にヒアリングを行い、仕様に落とし込むことを行いました。この仕様をオフショア開発チーム向けに英語翻訳し説明会を行うなどといった作業も行われています。
ここでブリッジSEが多くの時間を使用し説明を行いましたが、現地メンバーへ複雑なロジックの説明が難航しました。日本側チームでも一部仕様の認識に齟齬が出るほどの難易度で、現地からは「何がわからないのか分からない」状態になり、質問すら挙がらないままタイトなスケジュールに合わせて開発を進めなければならない状況が発生しました。また、大量のデータが必要になるプロダクトであったため、テストデータのパターンを多く必要となり、かつ計算速度に課題も多い状況となりました。その中でクライアントからの仕様変更依頼も多々発生し、プロジェクトは混乱状態に陥ります。
最終的に多くの機能が完成せずにプロジェクトは頓挫し、プロジェクトチームは解散となりました。
原因と対策
このプロジェクトには以下のような課題が見られました。
- 要件・仕様が非常に困難でフィジビリティスタディも行えてない状態でタスク依頼をしていた
-
システムの根幹にあたる部分について、日本側で十分に仕様の検証が行っていないまま現地への指示出しを行っていました。まずは日本側で実現可否や難易度を把握したうえで、オフショア開発チームへの指示出しが必要です。
- オフショア開発メンバーが十分に仕様を理解できない状況が続いた
-
仕様の難易度が非常に高く、背景知識を伝えることも難しい状況が見られました。また、この状況で更に度重なる仕様変更が発生したことも混乱を招きました。これらの仕様を満たす上で現地との技術スキルのミスマッチも発生しており、タスクベースでも実装完了が非常に難しい状況です。本プロジェクトにおいては一部の仕様を日本側で実装することも検討すべきでした。
- 開発状況の見える化が行われていなかった
-
タスクベースではスケジュールが管理されている状況ではありましたが、そのタスク内でのステータスや課題、作業状況が把握できていない状況が見られています。これによりオフショア開発チーム側で問題を抱えたままプロジェクトが進行し、意図しない実装や特定ケースしかカバーされない成果物が発生することにより急激な品質低下が発生しています。
仕様難易度が高いものほど作業状況をより細かく見る必要があり、進捗報告の詳細化や必要に応じてペアプログラミングを行うなど、タスクに隠れた課題発見が行いやすい環境を作ることが大切です。
オフショア現地で馴染みのない事業のシステム開発
ある工場における業務システムの開発をオフショア開発チームで実施した事例です。ある食品の製造管理・自動化を行うシステムで、やや複雑度が高いシステムではありましたが、機能は制限されているため日本で開発を行ったと仮定すれば問題なく実装できた可能性のある案件でした。
しかし、オフショア開発チームで開発を行ったところ、ロジックの実装やUIの実装で数多くの認識齟齬が発生しました。ブリッジSE側では適宜業務内容やロジックを詳細に説明するMTGを実施し、MTGも録画を取ったうえでアーカイブし、仕様書もまとめている状態で進行をしています。
原因と対策
- ある食品と製造の自動化がオフショア開発チームの国ではあまり馴染みのないものであった
-
ある食品はオフショア開発チームの国ではあまり食べる習慣がないものであり、かつ工場で食品製造の自動化をする仕組みは現地で馴染みのないものだったことが課題でした。説明をしたものの、日本人と比べ解像度がどうしても低くなってしまい、仕様をイメージすることが難しいという課題が発生しています。この前提はプロジェクト実施時には想定しておらず、振り返りをしていく過程で明らかになってきました。
この課題解決は非常に難しいです。現地メンバーに出張で現場をみてもらうことや、設計をより詳細化し前提知識を要しないレベルでタスク依頼をする粒度が求められます。また、プロジェクト開始当初から「現地チームにとって馴染みのあるものか」という前提を把握しておくことで、チームとのコミュニケーションの仕方も変わった可能性があります。
まとめ
オフショア開発には多くの潜在的なリスクがありますが、適切な対策を講じることで適切にコントロールすることが可能です。また、オフショア開発固有の課題であると思われがちですが、日本国内で日本人同士の開発でも十分に発生する可能性のある課題です。本質的にはプロジェクト管理の問題であるため、プロジェクト計画とチームビルディングを適切に行うことで、日本と近いレベルで運用することが可能になります。安易に”オフショアの問題”として片付けるのではなく、1開発チームとして共創することが大切です。
コミュニケーションの強化、品質管理の徹底、適切な技術力の確保、スコープ管理の徹底、コスト管理の最適化が重要です。これらのポイントを押さえて、今後のオフショア開発における成功を目指しましょう。
