【オフショア開発失敗事例】直らない不具合修正

この失敗事例はオフショア開発Eでオフショア開発ラボ型を行っている最中に開発が終了した機能を確認した所、不具合が多発し、その後不具合修正を
行っても、多くの不具合が完全に無くならない状況が発生した事例です。

失敗の解説

オフショア開発では、開発が完了しても、多くの不具合が発生して、確認、不具合発生、修正を何度も繰り返す状況が発生することがあります。

開発が終了した報告を受けても、確認してみると不具合が発生してしまう。開発の出戻りが多く不満が募る状況です。

このような状況が発生する原因として、テストケースの不備、チェック不足、ベトナムの開発者の特性など様々な問題が原因になることがあります。

プロジェクトの主な問題

今回の問題の詳細を調査したところ、一応のテストケースがあったものの網羅性に欠けていたこと、また一部テストの未実施がありました。

テストケースの網羅性が欠けていた問題は、テストケースを作成する担当者のスキル不足の問題です。

本プロジェクトの開発チームの構成は、日本人営業担当者とベトナム人ブリッジエンジニアの組み合わせでした。そのため、ベトナム人開発者が中心になってプロジェクトを進めると日本のプロジェクトの品質について甘い認識で開発を進める事があります。

開発の品質が甘くなってしまうことは、たびたび起こるトラブルでもありますが、それがリリース時やチェック時に修正ができているように、テストを行います。

しかし、今回のプロジェクトでは、日本人側が営業担当者で開発の知見がなかったことから、日本人側の品質でテストをチェックする事が困難でした。

また網羅性の欠けるテストケースで一部未実施があった問題も度々起こる問題です。

ベトナム人開発者はテストはテスターが行う認識が強く、開発者自信がテストを行うことを非常に嫌がります。そのため、時折テストをサボる事があります。

そのため、誰がどのようなテストを行ったかチェックすることで、オフショア開発会社側は評価を行い、お客様が確認するときには、テストが完璧に完了していることを行います。

今回のケースでは、テスト実施者が誰かわからずテストの責任の所在がはっきりしませんでした。

そのため、テストの未実施がしっかりと評価されず、お客様が確認する段階になって発覚するに至ったと予想できます。

具体的な対策方法

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

ラボ型開発は初めから円滑に進めることは難易度が高く、コミュニケーションの円滑さや担当者間の連携が重要だからです。

今回の失敗を避けるためには、事前に作成したテストケースをベトナム人開発者以外の開発者が確認することで避ける事ができました。

オフショア開発会社の日本人の担当者が開発者であるか、そうでなければ依頼企業側で確認・指摘できる環境を整える必要があります。

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

このプロジェクトでは、まずテストケースの網羅性の検査を行いました。

検査をした結果、テストに不備があったため、担当者のスキルについて確認をしたところ、オフショア開発の日本人担当者は営業担当のため、システム開発に関するチェックが漏れている事がありました。

まず、開発者が不具合を修正できる程度の網羅性があるテストケースを作成する必要があります。

そこで、オフショア開発の日本人担当者を開発の知見が豊富な開発者に変更して欲しい旨を伝えましたが、対応できる開発者がおらず、断念しました。

そのためオフラボでプロジェクトの詳細を把握し、テストケースを作成しました。

その後、テストケースを作成できない状況で、現在のオフショア開発会社を継続することは困難な状況と判断し、オフショア開発会社の変更を予定します。

オフラボで類似のプロジェクトの実績があるオフショア開発会社の数社と打ち合わせを行い、費用の合う開発会社に引き継ぎました。

引き継ぎ後も、オフラボにてテストケースの作成を行い、また開発者ごとのテスト実施のチェックを追加しました。正常な運用を確認し、オフラボのサポートは終了しました。