【連載】リスクは優先的に解消する

スポンサーリンク

プロジェクトのリスクが見えているか?

D社小林から、プロジェクトのリスクと優先順位について、プロジェクトメンバーへ説明があった。
プロジェクトには様々なリスクがあるが、優先的に解消することをする人は少ない。リスクは、後になればなるほど、リスクを解決するパワーが必要になってくる。つまり、初期段階に潰すことが重要であると説明した。

すみません。そもそも、リスクとは、なんでしょうか? 不確実なものがリスクとは違うのでしょうか?

厳密な定義はなく捉え方になりますが、プロジェクトにおけるリスクは、下記のように定義をしましょう。もちろん、不確実なものはリスクですが、不確実は課題として認識できていますので、確実に変えることでリスクではなくなります。しかし、他へ影響するものや、多数の人と協力し合って解決しなければならないものも、リスクです。ですので、個人で解決できるものは、リスクとはしません。理由は、個人の努力で解決できるからです。つまり作業だからです。
・他への影響があるもの(他の人や、サブシステム等に影響があるもの)
・量が多いもの(一人ではこなせない・助けてもらわないといけないもの)
・不確実

たとえば、要件定義のミスを発見したら、設計書の修正・プログラムの修正・再テストが発生します。つまり、要件定義のミスを修正するだけではないのです。要件定義のミスを優先的に解決して、後工程に情報を提供しなければならないのです。後工程も同じ人が担当するわけではありませんので、影響する人の工数やスケジュールにも影響します。期限もなく、時間に余裕があればよいのですが、クリティカルパスを意識して常に最短になるように行動しなければならないのです。つまり、「自分の仕事の優先順位は後行程の影響も考慮して決める」ということをしなければならないのです。これが、リスクは優先的に解決するということです。

エスカレーションをしっかりルールを守らせれば、良いのでは?
そうかもしれません。しかし、何故このような説明をしたかということにもなるのですが、どうもエスカレーションされていないように思えるからです。
考えるに、リスクをリスクとして認識できないので、リスクがあるとは気づかないようです。経験豊富な人が、常に森・木を見て、リスクを発見できれば良いのですが、残念ながら経験豊富でも、森と木の両方の視点で見ることができないのです。これは、どうにもなりません。だから、リスクの定義をすることで、リスクをリスクとして認識できるようにしたいのです。
言われれば、当然のことかもしれませんが、実際にプロジェクトで業務に集中してしまうと、忘れがちです。だから、リーダーの人は、常に意識をするようにしてください。

タイトルとURLをコピーしました