Information Technology Planning, Implementation and IT Solutions for Business - Baseline

やってはいけないプロジェクト管理（後編）
（2008/12/04公開）

リスクの文書化

　自分のブースに戻った後で、私はKAIDプロジェクトと提案されたスケジュールに関して予見した10あまりの重要なリスクについて、（思い返せる限り）詳細なメモを作りました。そのとき書いたリスクのいくつかをここに示します。

・システムに関して、完全な仕様と要件が十分に決定されていない。これでは、必要な作業量の推定を始めることもできない。

・主要な設計ソリューションが存在しないばかりでなく、システムのアーキテクチャさえ決定されていない。

・システムの開発に使用するプログラミング言語が、不明瞭（めいりょう）で特化したものである。

・チームメンバーの誰も、このプログラミング言語での開発を行ったことがない。メンバーは9月に2週間の訓練コースを受けたが、それ以後この言語での作業を行っていない。

・その理由は、開発ツール、つまり統合開発環境（IDE）やライブラリなどが、まだ商業的に利用可能でなかったためである。開発スイートのバージョン1.0が、12月初めにリリースされる予定であった（この理由だけでも、ソフトウエア技術者やチームのリーダーはプロジェクトに大きな不安を抱くと予想される）。

・また、この言語の開発ツールを提供しているほかのベンダーは存在しないため、バージョン1.0開発スイートになんらかの問題が発生した場合でも、別の開発ツールに置き換えることができない。

　問題点はまだまだ数多く存在していました。それぞれのリスクについて、リスクの発生する可能性と、発生した場合にプロジェクトに及ぼすと思われる影響の大きさを評価しました。私は、このメモをプロジェクトチームの全員に配布し、同時に部門のリーダーと、その直下の技術マネジャーへもCCで一斉送信しました。

　その結果、チームのエンジニアの何人かは、スケジュールに反対したことと、メモの作成について感謝を伝える個人的な電子メールを返してきました。しかしクライアントは、「設計以外に口出しするな」と書いてよこしました（これは、一字一句クライアントの返事そのものです）。クライアントは、KAIDプロジェクトに関するリスク、不確定要因、未知の要素について正直に認めることで、顧客とのビジネスを失うことを恐れていたのです。

　2ヶ月ほどたったころ、1月の頭に、私はこの同じメモを掘り出しました。そのときには、予定されたコーディング期間の半分が経過していましたが、プロジェクトは既に丸1ヶ月遅延していました。私が予見したリスクは、1つを除いてすべて実際に起き、すべてがプロジェクトとそのスケジュールに悪影響を及ぼしていました。そこで、私は最初に配布した全員に対して、このメモを注釈付きで再度送りました。

　4月には「コーディング完了」の日付が3月初めから、6月中にまでずれ込んでいました。クライアントは既に私のサービスを必要としていなかったため、私はそれ以上KAIDプロジェクトに関与しませんでした。私は、部門のリーダーと、彼の直下の技術マネジャーと共に、最後の昼食をとりました。私たちは、過去9ヶ月に起きた多くの衝突は、大規模なIT開発プロジェクトで一般的なものであると、同一の意見を持っていました。しかし私は、11月の時点でリスクを無視するべきではなかったことを指摘しました。リスクを無視することによる最悪の結果は、顧客に自社が無能か不誠実、あるいはその両方であると見なされることです。

　さらに1ヶ月ほどたったころ、KAIDのエンジニアから、「コーディング完了」の日付がさらに遅れ、9月になったという連絡がありました。これは、最初の見積期間の3倍です。それから間もなく、顧客がKAIDプロジェクトを完全に中止したという連絡を受け取りました。

　何年も前から言われているように、リスク管理を行わなければ、リスクによって管理されるようになります。来週は、ITプロジェクトでリスク管理を適切に行った2つの実例を紹介します。