オフショア開発失敗事例8 仕様変更によりプロジェクトが混乱

突然、仕様変更が発生

Webシステムをベトナムのある会社に発注した時の話です。
そのプロジェクトでは、詳細設計(内部設計)から組合せテスト(統合テスト)までをオフショア開発に発注していました。
コーディングに入った直後、お客様から仕様変更の要求が来ました。しかも、結構件数があります。
どうも基本設計の内容を現場に見せたところ、どうしても変えて欲しいと言われたみたいです。プロジェクトには現場のお客様の代表も入ってもらっていたので安心していたのですが、詰めが甘かったようです。

ここでオフショア開発側に仕様変更を取り込んでもらうと作業が混乱する恐れがありました。
そこで、単体テストまではこのまま作業を続けてもらい、単体テスト完了後に仕様変更を集中して取り込んでもらうことにしました。

日本側で期日までに基本設計を完了し、オフショア開発側に設計書を引き渡しました。そして計画通りに仕様変更の取り込みを行ってもらい、組合せテストに入ってもらいました。

日本側の確認で仕様変更の取り込み漏れを発見

無事組合せテストも完了し、日本側で受入テストを実施しました。すると仕様変更の取り込み漏れが何件も見つかりました。単純な担当者のミスにしては件数が多すぎます。
原因を調べるためにチェックリストなどを調べていきました。すると問題を起こした箇所の担当者が使っている設計書が古いバージョンであることが分かりました。

早速、PMに確認します。
私 「なぜ、新しい設計書を担当者に渡してないのですか?」
PM「新しい設計書を日本側からもらっていないからです。」

そんなはずはありません。
このプロジェクトでは情報の引き渡しにftpサーバを使用していたので、その履歴を確認しました。
やはり渡しています。証拠を送ると、ようやくPMも自分たちに非があることを認めました。

調べてもらうと、PMからコミュニケータへの翻訳指示がもれていたことが原因だと判明しました。
まとめて設計書を送ると翻訳作業の負荷大きいので、完成した設計書から順次送っていました。設計書を送る都度、PMにメールで知らせていたのですが、メールの見落としがあったようです。

他の担当者の使っていた設計書も調べてもらい、取り込み漏れはあらためて作業してもらいました。

この事例から得た教訓

正しいバージョンの設計書で作業しているかを確認するため、設計書のバージョン一覧表を作成し、作業を開始する前に付き合わせ確認を行うべきでした。

また、争いを避けるために、やりとりしたものを取っておいて、あとで検証する手段は必須であると感じました。
この件で、もし引き渡した記録が残っていなかったら、確実に有償対応になっていたでしょうし、対応も遅くなっていたと思います。