【オフショア開発失敗事例】テスト未実施の状態での納品・検収後の修正を拒否

こちらの事例は、モバイルアプリをオフショア開発会社Bが開発完了後にテスト未実施の状態で納品を行なった後に、不具合が多く発生したため、修正を依頼した時に追加費用を請求された事例です。

プロジェクトの主な問題

特に大きな問題は、システムの納品時の状態の共通の認識をあらかじめ共有できていなかったことです。

不備はあるものの開発仕様書はある状態です。しかし納品時のシステムの状態の認識を事前に共有できていませんでした。

プロジェクト開始前に、テストケースの作成やサポートするOSのバージョンや環境などの技術的な取り決めをしておく必要がありました。

失敗の解説

この失敗事例でも、多くの原因があります。

一番大きな原因は、システムの納品時の状態の共通の認識を持っていなかった事です。

請負型は契約前にシステムの機能や状態について詳細を決めます。その中には当然、システムの納品の状態や瑕疵（不具合）発生の場合の取り決めも含まれます。

本事例の場合は、主要な機能に関する開発要件書類はあるものの納品時がどのような要件を満たしているか、また満たしていなかった場合にどのような対応や責任が発生するかを決めていませんでした。

よってオフショア開発会社Bはタスクの指示にある機能の開発とデザインに沿ったページを作成し、納品を行いました。

具体的な不具合の内容は、大きく２点発生していました。

ユーザーが使用した時に、想定以外の動作を行なった時に不具合が発生してしまう使用面での不具合とOSのバージョンによって不具合が発生してしまう技術面での不具合です。

モバイルアプリでの開発だったこともあり、リリースされた後の対応に多くの手間がかかる状態が発生し、追加費用がかかるトラブルが発生しました。

このようなトラブルは、オフショア開発では多く発生します。

発生する原因として、請負型のオフショア開発では契約前に多くの取り決めが発生してしまうことで、時間がかかります。オフショア開発会社は契約を急ぐばかり、曖昧な取り決めの状態や必要な要件を決めずに契約を行います。

しかし、その後に大きな手間が発生する段階では出来るだけ最小限の工数に抑えるためにテストケースや対応するバージョンなどを出来るだけ限定します。

テストケースが決まっていない状態で、開発会社の都合の良い状態での納品となり、それ以上の対応は追加費用となる主張をされる状況になります。

具体的な対策方法

納品の時期になった時に、テストケースの取り決めや対応OSバージョンの取り決めをすることは難しいです。

大きな改善が必要になることも多く、工数が発生する事が多いためです。

このような状態になってしまった場合は、根気よくオフショア開発会社と交渉をしていく事が必要になるでしょう。

そのため対策としては、開発が始まる前に納品の状態に関して認識を合わせておく事が必要です。

テストケースを網羅的に作ることで納品の状態を正確に認識を合わせる事が出来ます。

また対応OSバージョンを含めて、そのほかセキュリティやサーバーなど技術的な不具合につながる要件に関しても正確に取り決める事が必要です。

契約前に開発者の確認を受ける

システム開発についてあまり経験がない場合は契約前に開発要件書やテストケースについて開発者に確認をしてもらう必要があります。

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

お客様がオフラボに問い合わせをしてきた時点では、すでに追加費用が発生することが前提で話が進められている状態でした。

お客様はトラブルに発展してしまったことで、信頼性が無くなったオフショア開発会社Bに追加依頼をすることは避けたいとこのことから、別のオフショア開発会社を探している状態でした。

しかし、開発開始当初の予算から追加で多くの費用がかかることは出来るだけ避けたい様子でした。

そこで、まずは修正範囲を把握するためにシステムの調査を行いました。

オフラボで内容を調査した結果、予算内で修正するには難しい状況でした。そこでオフショア開発会社の中でも、コミュニケーションスキルが低いが開発スキルが高い比較的安価の開発会社の数社から見積もりを取得して、オフラボの技術的な修正依頼書を作成し、予算内で修正を行いました。

しかし、予算の関係から一部の古いモバイルOSの対応は断念しました。