プロジェクトにおけるリスクマネジメント。
今回のテーマはかなりの時間をかけて追及されてきたテーマだと思います。
かなり前になりますが、アポロ13号の奇跡の生還においても取り上げられました。
私の経験を元に、大失敗したITプロジェクトにおいて何が原因で失敗したのかとのご紹介をしたいと思います。

時期は、1984年頃でしたが、最初に勤めた会社で当時のヨコハマタイヤ(横浜ゴム)のプロジェクトが色んな要素を含んでいました。
それまで、受託計算が中心で、初めての大規模一括請負のITシステム開発プロジェクトでした。
直接の担当はしていませんでしたが、後で当時の社長から調査を依頼されて調べた結果です。
1, 事象(起きた事)
納期の前日時点で、納品物となる予定の、仕様書・ソースコード・運用手順書等が、
一切出来ておらず、一から請け負った会社の責任でやり直しとなった。
2, 対処
急遽、全国の支社から要員を集めて、プロジェクトチームを再編成して、再度開発を
行った。
3, 結果
再作成された成果物は、結局顧客は採用せず、プロジェクトは消滅した。
かなり深刻な結果になりましたが、調べると原因は以下にありました。
1, プロジェクト進行中に、レビュー含めチェック体制が無かった。
2, プロジェクトマネージャ及びメンバーの経験不足及び資質の低さ。
3, 顧客との間でプロジェクトの目的が共有されていなかった。
以上の中で、1, 2, は体制を変えれば改善は出来ますが、致命的なのは3,でした。
顧客にとってのプロジェクトの目的は、単純でした。
当時の主力商品であった、スノータイヤを、降雪前線(雪のシーズン)に合わせて、
生産計画とサプライチェーンを動的に切り替えるしくみの構築。
この話は、当時の開発メンバーは誰一人理解しておらず、プロジェクトルームの中で
とにかく何か作業して作れば良い、と言う状況でした。
本来なら、工場や物流部門、販売店(チェーン店・チャネル)全体で設計が必要なのに、一切現場には行っていません。また、その状況をリスクと判断する機能も無かったという事でした。
結局、顧客であるヨコハマタイヤの旧システムを受託運用することに落ち着きましたが、この失敗の教訓はあまり活かされなかったようです。
Comments