オフショア開発失敗事例５　納品日当日にいきなり遅延が拡大

今回は、私が未だベトナムオフショア開発を活用し始めたばかりの頃に経験した失敗事例をご紹介します。

最初は1日の遅延でした

8人で1ヶ月の開発作業をベトナムのオフショア開発先に委託したときのことです。
あと後４日で納品というところで、1日遅れの状態でした。そのプロジェクトでは毎朝ＴＶ会議を行っていたので、その場でＰＭに対して「遅れは回復できますか？」と聞くと、「大丈夫です。まったく問題ありません。」との答えが返ってきました。
私は、「まあ、1日遅れだしなんとかするだろう」と考え、それ以上は追及しませんでした。

しかし、翌日もその次の日も1日遅れのままです。遅れは拡大こそしないものの一向に回復しませんでした。
さすがに不安になって「遅れは回復できますか？」と聞くと、「大丈夫です。まったく問題ありません。」と以前と同じ答えが返ってきます。
実は、万が一のことを考え、3日ほど余裕を見て納期を設定していたので、それほど深刻には考えていませんでした。

納期当日、いきなり遅延が拡大

結局、1日遅れのまま納品日を迎えました。
もう予定通り納品してもらえることは期待していませんでした。しかし、朝のＴＶ会議での報告内容を聞いて驚きました。いきなり4日遅れになっていたのです。
私　「昨日まで1日遅れだったのに、なぜ1日で4日遅れに遅延が拡大したのですか？」
ＰＭ「一生懸命作業したのですが、間に合いませんでした。」
私　「間に合わなかったことではなく、1日何もしなくても2日遅れにしかならないはずなのに、なぜ4日遅れになったのですか？」
ＰＭ「技術的に難しい問題があることに気づかなかったためです。」
私　「どういう問題ですか？」

問題の内容を聞いたのですが、以前から分かっていることでした。しかも問題とは関係ない機能にも遅れが生じています。
しかし、ＰＭを責めても遅れは回復するわけではありません。遅れ自体は、オフショア開発向けの余裕3日と、国内の作業向けの余裕を取り崩せば何とかなりそうです。
問題は、4日遅れで本当に納品してもらえるかどうかです。

結局7日遅れで作業完了

進捗の妥当性を検証するため、未完了の機能の作業状況（コーディングステップ数やチェックリスト件数等）を詳しくチェックしました。
すると進捗報告よりも実態はさらに遅れていることが分かりました。
ＰＭにその状況を説明し、担当者には休日出勤等を行ってもらいましたが、結局7日遅れで納品してもらうことができました。

この経験から得た教訓

このプロジェクトでは、タスクが完了したかどうかだけで報告してもらっていました。しかし、それでは進捗の妥当性が評価できないので、コーディングステップ数やチェックリストの作成・消化件数など、定量的な数値で報告してもらうべきでした。このプロジェクト以後は、そのように手順を改善しています。
毎日進捗を確認するのは面倒ですが、最低、委託先が進捗をちゃんと管理していることが確認できるまでは、しっかり見なければなりません。

今後の見通しに関しても甘いことがよくあるので、日本側でチェックし、問題があれば早期にＰＭに働きかけていくことが大切です。