第4回 リスク管理、進捗管理
(6) リスクを検討把握する
プロジェクトは新しい成果物を造り出す一連の活動ですので、必ずリスクを伴います。PMはプロジェクトのリスクを予見し、発生を未然に防ぐ対策等を打っておく必要があります。
一般的なリスクには以下のようなものがあり、PMはさらにプロジェクト固有のリスクも考慮しなければなりません。なお、リスクの発生する確率はプロジェクトの内容によって違ってきます。
- 顧客企業側の要件が固まらず、スケジュールに大きく影響する。
- 要件は固まったものの、実現が難しく、設計に手間がかかって遅れてしまう。
- 仕様詰めが遅れて突貫工事になり、PC、サーバ、作業場所等の資源、環境不足で深刻な影響が出る。
- プロジェクトメンバーが事故や病気でプロジェクトから外れる。
- サブリーダとメンバー間の関係がギクシャクする。
- ２つのサブグループ間で摩擦が発生する。
- ひとつのグループだけが、他のグループを省みることなく先に進んでしまう。
- 新しいバージョンのパッケージソフトウェアがバグなどで安定しない。
- 発注先の成果物のできが悪く、受け入れできない。
PMは、発生し得るリスクを識別し、優先付けして対策を考え、常にリスクが発生していないかどうか監視する必要があります。
リスク対策として下記のようなものが考えられます。
- 優先度の高い機能やタスクと、逆に遅らせても構わない機能やタスクを顧客と意識あわせしておき、リソースなどもダイナミックに割当ることができるように遅延発生時の準備をしておく。
- 重要な作業に常にプロジェクトメンバー２名をアサインすることにより、1名が病気、事故でプロジェクトから外れても残る１名で対応可能となるようにしておく。
- サブリーダレベルとの会議を頻繁に開いて情報交換を密にしておき、グループ間の摩擦や、グループとグループの間に落ちてしまって誰も拾わないタスクの発生を回避する。
- PMはサブチームごとに懸案事項一覧表を作成記録させて、内容を把握しておき、チームが直面している問題を把握し、プロジェクト全体の問題であれば全体で解決する。
- 資源不足に陥らないように先手を打っておく（PCについては予め発注先に協力を求める。サーバに関しては予め自社内に準備すると同時に、顧客企業側に導入を提案する、など）。
- 関連会社協力のもとに、主要なリーダクラスが一箇所で執務できるような場所を準備し、コミュニケーション不足、お互いの理解不足などに伴うリスクの発生を抑える。
- 初物（新しいバージョン、新しい製品など）を使用する場合には、十分なテスト試用期間を見込む。もし使い物にならなかった場合にどうするかの対策も立てておく。
- スケジュールを立てると同時に、予定通りに行かなかった場合の対策（戻し手順、迂回策など）を検討しておく。
- 発注先の状況を非公式に（本音を）把握できるようなパスをつかんでおく。状況がまずいことが分かった場合にも厳しくも温和に対応し、非公式パスを大切にする。
リスク発生の兆しは、プロジェクトチームメンバーや発注先企業からPMに上がってきます。従って、上ばかり向いて仕事をしている人は、PMには絶対に不向きです。下から上がって来るリスクの兆しに鈍感だからです。
楽天的な人（リスクの兆しに鈍感な人は楽天的に見えます）は、一時的にはプロジェクトメンバーに良い影響を与える場合もありますが、単に「事なかれ主義の人」の場合には、プロジェクトはほぼ失敗します。事なかれ主義により大小様々の問題を放置することで、プロジェクト全体で考えなければならない問題にも、各サブチーム、あるいは個々のメンバーが個別に問題にぶつかることになり、本来やるべき担当業務に悪影響を及ぼし、メンバーの士気を低下させるからです。
同様に問題の責任を逃れようとする人もPMには全く向きません。逃れようとする人には誰もついて行かないからです。
(7) プロジェクト進捗の阻害要因を排除する
優秀なPMが居ればプロジェクトが成功するか、というと、そう簡単ではありません。人間1人でできる仕事は限られており、メンバーに十分に力を発揮してもらわないと、プロジェクトは進みません。従って、PMは、各サブチーム、各プロジェクトメンバーの仕事が、何らかの理由で停滞していないかどうか、常にチェックしておく必要があります。ここで停止の理由には、以下のようなものがあります。
- 資源不足による停滞
- 仕様未定義による待ち
- 実現方式の検討遅れによる停滞
- メンバーの能力不足による停滞
- マンパワーの不足による停滞
- 自社または他社の製品、成果物納入待ち
- 自社または他所の製品、成果物の不具合による待ち
この中でも資源不足による活動停止は、プロジェクトにとって大きな無駄となり、士気の低下を招きます。PCが無いためにメンバーの仕事が停滞する、開発環境のCPUが足りずにエディタが動かない、コンパイルができない。このような資源不足による時間の浪費、メンバーのやる気の損失、人件費の損失は計り知れないものがあります。PMはこのような問題を放置せず、少しでも改善する方向に導かねばなりません。そのために、顧客企業や自社の営業、上位マネジメント、あるいは他のプロジェクトチームのPMとの交渉が必要となることもあります。
仕様未定義による遅れについては、原因を正確に突き止めて、改善する方向に持って行かなくてはなりません。必要であれば顧客企業へのクレーム、改善申し入れも重要なPMの仕事です。
実現方式の検討遅れは、サブチーム内だけでなく、もっと全体で解決を図ったほうが進む場合があります。メンバーの能力不足の場合には、時間があれば教育やOJTを受けさせることができますが、最悪の場合には交代も考えなければなりません。
自社、他社の製品、成果物の納入待ち、製品、成果物の不具合による待ちは、場合によって深刻な問題に発展することがありますので、こういうことが発生しないように先手先手を打つことが必要です。