デスマーチプロジェクトの予感、あなたならどうするだろうか

　先日、失敗プロジェクトを1つ作ってしまった。納期は計画提供から1ヶ月遅延し、大きくはないが赤字となり、品質は安定せずリリース後も障害修正を繰り返すことになった。今日はこの失敗プロジェクトを振り返りたい。失敗プロジェクトに関する分析結果は沢山でているので視点を変え、開始時点の背景を詳細に記述してあなたならどのような対応をしたか具体的に考えてみてほしい。私は失敗プロジェクトを作ってしまったが、成功させるやりかたはあったのではないかと思う。なお、ITのプロジェクトのため他業種の方にとってはわかりにくい記載があるかと思うがご了承いただきたい。

2012年10月中旬 　発注元のA社は社内システムを構築することになった。一般的なWebベースの申請システムある。この開発はすでに始まっており、A社とアプリケーションを開発するB社で進めていた。しかし、インフラ構築（サーバやネットワークの設計・設定）はB社ではできないことと、開発マネジメントすることに不安を感じたA社はあなたの会社C社にSIを依頼してきた。あなたの会社はA社の他のシステム開発を手がけておりSIer1 として実績があった。このプロジェクト・マネジャーとしてあなたが指名された。あなたはA社の開発は始めてであり、B社はあなたもC社としても初めての取引である。 　プロジェクト・マネジャーに任命されたあなたは現状のプロジェクトを調べ、プロジェクト計画作成に取り掛かった。

2012年10月末日 　開発状況を調べていくと、業務要件定義は出来上がっていたがアプリケーションの仕様書がなく、Ｂ社は業務要件定義からプログラミングを着手してしまっているようだ。あなたはWBSを洗い出して作業期間を積み上げたところリリースは2月末日が妥当と判断した。期間延長の申し出を行ったが、A社から社内業務が止まってしまう為、1月中旬提供が必達と言われてしまっている。スコープの縮小を検討したがこれ以上の縮小を行うとシステム化する意味がなくなってしまう。このプロジェクトはハイリスクなプロジェクトであるが、他のプロジェクトで取引があるため今回のプロジェクトへの参入を断ることができない。 　あなたならどのようなプロジェクト計画を立てますか？

　デスマーチプロジェクトiを予感するプロジェクトであるが、あなたならどれだけリスクを上げてその対応策を行うことができるだろうか。その中で一番重要と思われる対策は何だろうか。
　プロジェクト・マネジャーとして任命されたとき、一番リスクだと思ったのが、B社のスキルであった。初めての取引であったため、B社のスキルがまったく見えていなく、短納期のためメンバの能力を見極めてから対策する余裕が極めて少ない。もちろん、B社のスキルが高ければプラス要因となり短納期を乗り切ることが出来ただろう。しかし、リスクとして計画時点から上げていたにもかかわらずこの対応ができていなかった。これが失敗のひとつの原因であった。この時点ではこれまでのA社とB社の経緯があったため、仕様確定もB社という固定観念があったのであるが、仕様確定はスキルがわかっている要員を別にアサインして進めるという手もあったかもしれない。結局は製造が完了するまで少し怪しいと感じながらも試験が始まって問題が判明するという後手をとってしまった。
　次に問題と感じたのは短納期だからといって仕様書が無いまま製造に入ってしまっていることである。B社は要件定義で十分な検討をしているので、仕様書作成するよりプログラミングを進めないと製造に間に合わないと言っていた。要件定義に記載が無い仕様も口約束で決められており、文書化されていなかったのに、である。アジャイル手法が出てきているが、受託開発のITプロジェクトを成功させるための重要なポイントは仕様書が漏れなく作成できていることではないかと思っている。仕様が決められなかったのは結果であって、根本原因は様々考えられるが、初めに結果として見えるのは仕様書であり、この品質によってその後のプロジェクトが変わってくるのではないだろうか。実際には、明文化するだけで1ヵ月を有し、時間的な制約が来てしまい曖昧さを残したまま仕様書が出来上がってしまった。全体3ヶ月のうち1ヶ月経ってしまうとスケジュールの恐怖を感じてしまい曖昧なままで良しとしてしまった甘さがプロジェクト・マネジャーとして未熟だったと反省している。曖昧な仕様書はその後の開発工程に大きな影響を及ぼした。プログラムはプログラマーの想いで動作するようになり、試験項目は曖昧なままとなり、実際にテスターが試験をしてもOKの判定を下してしまう。その結果、顧客の期待通りの動作とならず、改修が入り、プログラムは混乱していった。複雑になったプログラムは品質が低下し類似障害を発生させる温床となっていった。
　期間を短縮させるためにどうすればよいだろうか。PMBOKにはクラッシングとファスト・トラッキングが紹介されている。ただ闇雲に増員して並行開発を進めたら手戻りが発生したときの影響が大きく逆にプロジェクトを破綻しかねない。一つの案としては機能ブロックごとに小さく小分けしてそれぞれの機能ブロックに対してはプロセスどおりに作業すると比較的リスクを抑えることが出来る。今回もこの手法で進める事にしたのだが、先に記載したとおり仕様書の完成度が低く手戻りを頻発させてしまったのである。
　結局のところ仕様(スコープ)を如何に早く、十分なレベルまで決めることが出来るのかが短納期でプロジェクトを完了させる鍵であった。この工程だけでもスキルをよく知っていてスキルの高い要員をアサインできたらプロジェクトは成功していたかもしれないと思うと残念でならない。

ⁱ SIer とは、System Integrationの略称SIに「～する人」を意味する-erをつけて「System Integrater」とした造語であり*1、エス・アイアーと読む。System Integrationとは、個別企業のために情報システムを構築することであり、戦略立案から、企画、設計、開発、運用・保全までトータルに提供するSIerもある。(はてなキーワードより)