オフショア開発失敗,、オフショア開発事例、オフショア開発会社

【オフショア開発失敗事例】進まないラボ型開発

17 View

この失敗事例はオフショア開発ラボ型で開発スケジュールが遅延してしまい、当初予定していた機能の多くが期間内に開発不可能になってしまった事例です。

状況に困ったお客様がオフラボにお問い合わせをした事例です。

失敗の解説

オフショア開発ラボ型は、開発チームを期間ごとに契約して、期間内に開発を行う開発方法のため、柔軟な開発を行う事ができる反面、開発の効率が悪いとうまく進める事が出来ません。

この事例においては、ラボ型の開発タスクのマネジメントがうまくいかず、開発効率が落ちている状況でした。

そのため、開発機能の遅延が発生して、期間内に開発が完了しない状況が発生していました。

プロジェクトの主な問題

今回の問題の詳細を調査したところ、開発効率が悪くなった経緯として、最初の開発が終わった段階で、不具合が多く発生したため、その不具合対応に当たる開発者が、次の開発タスクを行う事が出来なくなり、全体の開発スケジュールに遅延が発生した事が原因でした。

開発スケジュールやタスクを確認したところ、テストケースを作成せず、開発チームに任せていたこと、修正の発生の有無で開発スケジュールを複数用意していなかったため、開発スケジュールの修正や対策ができなかったことが大きな問題でした。

特にテストケースについて事前に用意していないことは、ラボ型開発において致命的です。

ほとんどのシステム開発には不具合が生じます。しかし、基本的なテストケースを用意しておくことで、不具合の発生数を削減することが出来ます。

よって他の開発タスクへの影響を減らし、開発スケジュールを円滑に進める事が出来ます。

不具合の発生することを削減することは、予想以上に大きな影響があります。

なぜならラボ型は開発チームで行っているため、主要な開発者が不具合修正に時間を要し、通常の開発タスクが出来ない場合、他の機能開発が出来なくなる可能性があります。

そのため、不具合対応に当たっている開発者以外にも影響する可能性が発生します。

具体的な対策方法

まず依頼者がラボ型の経験が少ない場合は、日本人開発者がブリッジエンジニアとして開発チームにはいるラボ型開発を選択する事がおすすめです。

ラボ型開発の中でも、短期間で開発サイクルを作りリリースを行なっていくアジャイル開発などを円滑に進めることは難易度が高く、コミュニケーションの円滑さや担当者どうしの連携が重要だからです。

次に出来るだけ、ラボ型の開発サイクルについて、打ち合わせを行い、どのような流れで開発を進めていくか、開発する機能の情報やテストケースなどについていつまでに情報を共有するなどラボ型の大枠を決めておきましょう。

加えて、ラボ型を契約する前またはラボ型の最初の開発が始まる前までに、開発スケジュールと開発タスク、タスクが終わった場合の対策、テストケースを決めておきましょう。

ラボ型開発が始まってからは、開発内容の詳細の確認や機能変更があった場合の様々な調節などを行いますので、時間的な余裕はありません。

そのため、開発サイクルの大枠を修正する事が難しくなります。

開発が始まる前の時間に余裕がある期間に必ずラボ型の進め方について担当者と協議して開発サイクルについて大枠を決めておきましょう。

できれば、リリース毎の開発サイクル期間を可能な限り短く小機能グループごとに分けてラボ型を進めていきましょう。

大きな開発サイクルやまとめて機能リリースすることは、不具合発生が多数発生することや開発スケジュールのリカバリが出来なくなります。

特にラボ型の初期では、短く開発サイクルを行い、改善を繰り返す事が重要です。

その後のプロジェクトの経過

6ヶ月のラボ型契約のうち、すでに4ヶ月を経過していましたが、開発する機能は1/3ほどしか進んでおらず、未だ開発が完了した機能の修正が終了していない状況でした。

まず、オフラボではオフショア開発Dの聞き取りとラボ型の調査を行いました。

聞き取りと調査の結果、前述したテストケースの未作成があり、また開発スケジュール管理も簡易的なものでした。

1ヶ月ほどで上記状況を改善したとして、開発を行なったとしても、効果が出てくる頃には、オフショア開発会社Dでのラボ型開発の期間は終了します。

お客様とオフラボのサポートで検討し、オフショア開発会社Dでは、今回のラボ型契約で終了し、他のオフショア開発会社に変更することになりました。

そこで、

  1. オフショア開発会社Dの残り期間に出来るだけ開発タスクを進めてもらうこと

  2. 次のオフショア開発会社でのラボ型開発の準備

  3. オフショア開発会社Dから次のオフショア開発会社に移行

を行う事が必要になります。

オフショア開発会社Dの残り期間に出来るだけ開発タスクを進めてもらうこと

こちらはオフラボのサポートのもとテストケースの作成、タスク管理のサポートを行いました。

テストケースの具体的な進め方と作業時間を管理して、現在開発が終わっている機能については、不具合のない形にしてもらいました。

引き継ぎ後のオフショア開発会社と責任の所在を明確にするため、新しい機能追加よりも現在完了している機能を正常にすることを優先しました。

次のオフショア開発会社でのラボ型開発の準備

オフラボからラボ型開発でのアジャイル開発に定評があるオフショア開発会社の複数社と見積もりを取得して、開発するプロジェクトと類似している実績があるオフショア開発会社に引き継ぐことになりました。

まず引き継ぎ時の情報に不備や漏れがあると、開発を進めることが困難になります。

そのため、オフショア開発Dと引き継ぎ後のオフショア開発会社とオフラボで正確な情報共有をする必要がありました。

オフラボが中心になり、開発ドキュメントと共有可能なデザインファイルを作成しました。

次に移行後のオフショア開発会社でのラボ型開発を円滑に行うため、ラボ型開発の準備を始めます。

作成した開発ドキュメントを参考に、残っている開発タスクと今後の開発機能をリスト化し、開発スケジュールを作成しました。

また開発機能に応じて、テストケースを作成しました。

時間も限られていることから、まずは短い開発期間のラボ型開発を行い、随時プロジェクトに合わせて改善していくことにしました。

オフショア開発会社Dから次のオフショア開発会社に移行

実際に移行期を1ヶ月ほど確保して、開発の移行を行いました。

以降完了後、オフラボがラボ型開発をサポートし、開発を継続しています。

関連記事

【オフショア開発失敗事例紹介】 決済サービスの申請トラブル

2022/11/28 オフショア開発の基本 詳しく

【オフショア開発失敗事例】決済システムの申請トラブル

2022/11/24 オフショア開発の基本 詳しく

【オフショア開発失敗事例紹介】テスト後の修正を拒否された事例

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】タスク管理トラブル

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】日本語での情報共有の誤解

2022/11/22 オフショア開発の基本 詳しく