オフショア開発失敗事例１１　発注先に渡す設計書が間に合わなかった

オフショア開発で一番難しいのは、予定通りに作業を開始することではないでしょうか。
予定通りに作業を始めるために必要なものは、オフショア開発側に渡す設計書ですが、これを期日通りに完成させるのは至難の技です。

お客様は、つぎつぎと追加要求を出してきますし、決まったはずの要求をひっくり返します。その詳細を詰めて設計書に書いているうちに次の追加要求が出てきます。
いろいろな要求を取り込んだために設計書の記述に矛盾が生じて、それを見直すためにまた残業が続く。
こんなことが、今日も多くのプロジェクトで起きているはずです。

オフショア開発の失敗の真の原因は開始時期の遅れであることが多い

この設計の遅れを製造工程の期間を短縮することによって取り戻そうとするＰＭがたくさんいます。
しかし、工程表の上で短縮するのは簡単ですが、実際にそのスケジュールを守るのは非常に困難です。元々余裕のあるスケジュールを組んでいるプロジェクトなんて滅多にありません。それをさらに短縮しようとするわけですから、うまく行かなくて当然です。

開始時期が遅れて、開発期間を短くしたことが進捗遅延や不良多発を招いて失敗したプロジェクトがたくさんあります。ただ、期間短縮の決定は工程の最初に行われ、問題が顕著になった頃にはみんなそのことは忘れているので、オフショア開発側が悪いということになりがちです。しかし、元々無理な工程を要求した発注側に真の原因があります。それが分かっているＰＭもいますが、そのことを言うと責任が自分に来るので黙っています。

オフショア開発側が、受注時に「このスケジュールでは無理です。」と言えれば良いのですが、受注側の弱い立場ではなかなか言えません。また、このような難しい交渉ができる人材は、オフショア開発側には滅多にいないのが実情です。

製造直前に仕様の全面見直しが発生

私自身も、オフショア開発の開始時期をずらしたことが何度もあります。
大体は、オフショア開発側に謝って待ってもらっていたのですが、規模が大きくてそれができなかったことがあります。

そのプロジェクトは、約250画面のWebシステムで、設計は多少遅れつつも何とか進んでいました。
製造の準備のために、オフショア側に10名の体制を用意し、開発規約やフレームワーク、共通プログラムの内容の習得を開始してもらっていました。本格的に製造が始まれば50人に体制を増員する予定です。
順調に行けば、後3週間で製造を開始する予定でした。

ところが、お客様から「仕様を全面的に見直したい」との連絡が入りました。
丁寧に仕様を確認してきたつもりだったので、まさに青天の霹靂という感じでした。
早速、お客様に確認すると「エンドユーザ部門から新システムの効率性について検証したいとの申し出がありました」とのことでした。
こうなると抵抗しても無駄だというのは、それまでの作業で分かっていたので、スケジュールを引き直すことにしました。
その結果、オフショア側の作業開始が3カ月後ろ倒しになりました。
元のスケジュールでは、製造開始まで後2週間のところでした。

オフショア開発側との交渉は難航

早速、オフショア開発側の管理者に連絡します。

私　　「大変申し訳ありません。作業の開始時期が3ヶ月後ろ倒しになります。」
管理者「それは困ります。体制を既に用意しています。」
私　　「それは承知していますが、なんとかなりませんか。」
管理者「延期すると、今予定しているメンバーは別のプロジェクトにアサインします。
今、準備に充てている10名だけでも何とかなりませんか。」
私　　「分かりました。検討します。」

結局、準備を行っている10名だけ継続することになりました。
しかし、10名が3ヶ月で30人月ありますが、やらせる仕事がありません。
困った挙句、比較的変更のなさそうな機能を作ってもらうことにしました。

このプロジェクトで幸いだったのは、設計の遅れについてはお客様の責任も認めてもらえ、プロジェクト完了時期も延ばしてもらえたことです。
そのため、製造期間は圧縮しないで済みました。