リスク計画は、パニック防止

ITプロジェクトでは、なぜか、しっかりとしたリスク計画を作っていません。言葉では、リスク、リスクといっていますが、明確にリスクを定義しているプロジェクトにお目にかかったことがありません。
私自身も、やはり、明確に文書を作成して管理した経験はありません。プロマネをしながら、状況を判断して、次にこんなことが起こるのではないかと予測をつけて、それが起こらないように対策を講じるだけです。
KKD(勘、経験、度胸)という昔から言われているプロジェクトマネジメントの真髄(?)に頼っているだけです。


ここで、一度リスクとは、何かを考えて見ましょう。
リスクとは、将来起こり得るイベントで、プロジェクトの成功に影響を及ぼすものを指します。影響は、マイナスのものや、プラスのものも含みます。(PMBOK第3版からは、プラスの影響を与えるリスクも取り扱うようになりました。)
ところで、皆さんもよく管理している課題とは何でしょうか。
課題とは、現在起こっているイベントで、プロジェクトの成功に影響を及ぼすものを指します。
したがって、リスクが発生してしまえば、課題になるということができます。
PMBOKでは、リスクを考える時に、
リスクをカテゴリに分け、カテゴリでリストアップする
リスクをその発生頻度と、影響度で評価する
発生頻度と影響度で重み付けを行い、優先順位を付ける
優先順位の高いものから対応策を検討する
というような手順が示されています。
リスク計画は、なぜ、必要なのでしょうか。
それは、発生を未然に防ぐこともありますが、発生した時にパニックに陥らないようにするためです。
先週紹介した、ある製造業のERPプロジェクトでは、非常に影響の大きいリスクが発生してしまいました。
このプロジェクトでは、明確な文書は、作成していませんでしたが、顧客側プロマネが、非常に細かくリスク対策を考え、実行していました。(リスクは、プロマネだけが考えれば良いものではありませんが)
進捗会議でも、リスクが取り上げられ、どのように対応していくかが常に討議されていました。
しかし…
まったく考えていなかったリスクが発生してしまいました。それも、カットオーバー間際の結合テストの時に…
それは、バックグラウンドジョブがabendを起こしてしまい、異常終了してしまうということでした。
原因究明に時間がかかり、結論の出ない対策会議ばかりが繰り広げられ、次第にメンバーの間にも、カットオーバー延期もやむなし、という雰囲気が広がり、モラールも低下してしまいました。
この異常終了の原因は、32bit OSの限界を超える処理をしていたということでした。処理に必要なメモリー容量が限界を超えていた…いかんともしがたい問題です。
究極の解決策は、OSを64bitにあげることですが、使用しているハードベンダーの64bit OSがまだ出ていない状況で、それはできません。結局、データ処理を細かな単位で行い、処理が終わると強制的にメモリーを解放するようにプログラムを変更しました。
さらに、常にメモリー状況を監視し、ある閾値を超えると、処理が終了した時点で、メモリーを解放するアドオンプログラムを作成して、異常終了が起こらないようにするしかありませんでした。
この例など、自社のデータ量を考えれば、ある程度リスクとして考えられたかもしれません。(あくまでも、後追いですが)
問題は、考えられたかどうかということではなく、発生した時に、メンバーに対してどのような影響が出たかということです。このプロジェクトでは、カットオーバーできるかどうかという時に、逆に、モラールが低下してしまったことです。
このようなことがないように、リスク計画は、しっかりと立てたいものです。
よく映画などである、「よし、プランBに変更!」というようなのりで対応できるように。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*