■プロジェクトマネジメントの内容 ６（解説編・計画）
◆リスクを見積る
プロジェクトとはそもそも初めてやる事項で，しかも不確定な要素を多く含んでいる。即ち，リスクがあることを前提としている。従って，できるだけ当初の計画を必達するために，予め，想定されるリスクの事象にはどんなものがあるか？を考えておくことが重要であり，プロジェクトの成否を左右することさえある。言い換えれば，プロジェクトはリスクとの戦いとも云える。そのリスクには，以下に述べる事象があり，事前にそうしたリスクを回避する方法を検討しておくことが重要である。
●リスクの事象
①スコープ関連 －－市場（顧客）の動向，競合他社動向，環境
②スケジュール関連 －－計画の甘さ，マルチタスク，マージン少
③コスト関連 －－リソース過多，コスト増大
④テクニカル関連 －－品質不良，特性未達，技術難易度大
◇スコープ・リスク
これはプロジェクトを開始する前に検討していたスコープが，途中で変わる場合である。
１．計画時の不確定要素
スタート時点で，スコープがすべて明確になっている場合もあるが，プロジェクトによってはプロジェクトがある程度進んだ段階でしか決まらないものがある。或いは条件付きで決められていて，その条件が変わった段階で見直しをする，と云ったものもある。こうしたプロジェクトでは，当然，それらが決まった段階で，当初の計画を大きく見直さなければならないことが起こる。
２．顧客（市場）要求の変化への対応
スタート時とプロジェクトが進んで行く中では，顧客や市場要望が変化する場合がある。プロジェクトでは，スコープが一旦決まったら絶対に変えないと云うのではなく，むしろこうした環境変化，特に，顧客要求が変わった場合，プロジェクトがそのまま完成しても受け容れられないケースもあり，顧客要求に柔軟に対応することが求められる。もちろん，契約を交わしたりしている場合，その変更による負担など明確にした上での対応となる。
３．環境変化への対応
環境の変化とはいろいろな場合がある。競合他社の対抗品の情報で，このままでは遅れをとるとか，内部事情でどうしてもリソースが不足する事態を招くとか，環境規制，法規制などプロジェクトをやっている中でその周りの変化はいろいろなものがあり，これらを素速く察知して対応しなければ，結果的に大きなロスを生む危険性を孕むことになり，こうした環境変化で大きくスコープの変更を余儀なくされる場合がある。
◇スケジュール・リスク（日程の遅れ）
最も日常茶飯事的に発生しているのが，プロジェクトの日程遅れである。当初予定した通りにプロジェクトが進まない経験したことが無い人はいないだろう。しかし，プロジェクトの遅れる理由には，次のようなものが代表的である。
１．計画時点の甘さ
新製品開発プロジェクトにおいては，すべてこれにつきる，と云っても過言でない。そもそも計画を立てる時点では，課題が全て明確になっているわけではなく，どちらかと云えば，この日程でやらねばならない，と云った思いの強い日程計画になる。従って，その計画でプロジェクトが走り出すと，次々と課題が出てくる毎に少しずつ日程が遅れ出す。全体日程がはっきりしていると，何とか挽回策を検討するが，経験則からしてそう上手く挽回できるケースは少ない。全体計画がきっちりできていないプロジェクトにおいては，挽回策などが採られることもないままになるケースもある。
２．マルチタスク
仕事のできる人に集中する，即ち個別プロジェクトを掛け持ちでやらなければならないことが起こり，高負荷状態になることがある。特に，同じプロジェクトの中でも，スケジュール表を作り担当者を入れると，あたかもＡさんが何人も存在するようなリソースの割り当てがなされることがある。異なったプロジェクトに関連する場合は，両者の調整はその該当者任せになるケースが殆どである。そうしたケースでは，声が大きかったり，火が付いた状態の仕事から片づけていく仕事のやり方になってしまう。従って，各々のプロジェクトとしてのスケジュール管理が困難になる。
３．バッファーを無駄にする仕組みと心理
通常プロジェクト日程を立てる場合，何らかのバッファーを見込む。そのバッファーは，技術的困難度であったり，限られたリソースでのやりくりであったり，外的要因の変更度合いなどを加味される。また，計画する人のリスクの見方によっても大きく左右される。
各々のタスクはもともとバラツキをもっており，しかもタスクが従属関係にあるため，前のタスクの統計的変動（バラツキ）の影響を受けるため，全体での効率が低下する一つの要因になる。一方，心理的要因が働き，タスクが予定より遅れると大変であるが，予定より早く終わっても，必ずしも次のタスクへ早めに引継するとは限らないことがある。これは，タスクが早く終わっても褒められるわけではなく，遅れは目立つが，早まった分は引き続いて自分が担当する場合は早めに次のタスクをスタートするが，そうでなく次の人へバトンタッチする場合は，敢えて早めに引き継ぐことなく，表面化しないで消えているのが実態である。
◇コスト・リスク（リソース不足・過多，コスト増大）
当初設定した人，予算でプロジェクトが進まない場合である。
１．リソース不足（コスト増大）
当初計画していたリソースではプロジェクトが必達しないことが起こる。その一番多いケースは，プロジェクトがどんどん遅れ，それを挽回するにはリソースを増やすしか方法はない場合である。原因は計画の甘さや，スキル不足などいろいろな要因が考えられるが，要するに当初計画した人員ではプロジェクトが完了せず，人員を増してプロジェクトを完了させることで，結果としてコストが予算をオーバーしてしまうことである。
２．リソース過多（生産性悪化）
リスクと云えるかどうか判らないが，計画した時点よりリソースが余ってしまうことである。計画が予定より順調に進み早くプロジェクトが終わることは好ましいことであるが，こうしたケースは滅多にない。しかし，リソースが部分的に余ることは，現実いろいろな場面で起こる。しかし，一旦抱えたリソースは，一時的に要らないから，他へ回し，必要になったら戻すなど物のように自由自在には扱えない。つまり，余った時間があっても何か仕事をさせるのがプロジェクトである。こうした点は，生産性と云う効率面の指標で見るとムダな部分で，プロジェクトがどんどん精鋭化，シビアになってくるとこうした点の追求まで及び，プロジェクトとしてはリスクになってくる。
◇テクニカル・リスク（品質不良，特性未達成）
新製品開発におけるテクニカルリスクは，スケジュールリスクについで発生する頻度が高い。即ち，未知の分野への挑戦であるだけに，技術的解決の困難度が高ければ高いだけ，このテクニカルリスクもスケジュールリスクも高くなる。
１．テクニカル・リスクの難しさ
プロジェクトとは，元々初めてやるタスクなので，未知なる技術への挑戦も含まれる。したがって，そのハードルの高さと持ち合わせるスキルがそれを乗り越えられるかである。この技術的なハードルは，質の問題であり，リソースを増やしたからと云って解決できる問題ではない。しかも，そのハードルを乗り越えなければプロジェクトが完成しないとなると，その見極めが重要で，特に，プロジェクトリーダはこのようなテクニカル・リスクの大きさ，高さを十分把握し，それに見合った対策を講じる手腕が問われることになる。必要に応じて，例えば研究所を巻き込むとか，場合によっては，他社と上手くアライアンスをすることで技術課題を克服するなど，そのプロジェクトの成功に向けた動きをすべきである。
●リスクの事象の評価
想定したすべてのリスクに対して手を打つことは不可能に近いし，効率的ではない。従って，それらの事象を次のような評価をして優先度を決めながら対処することになる。
発生の確率 －－その事象が発生する確率が高いか，低いか
影響の大きさ－－その事象がプロジェクトに及ぼす影響が大きいか，小さいか
自ずと判るが，発生確率が高く，影響の大きいリスク事象については，予防策を十分検討しておいたり，発生してもすぐ対処できるようにしておかなければならない。いずれかが，高い，又は大きいものは，発生時の対策を講じたり，万が一起こっても，影響が少ない方法を見つけておいたり，事前に策を考えておくだけでも，プロジェクトが安心して進められるものである。
以上のように，プロジェクトマネージャーは常にリスクに対する備えを考慮しながら，リーダシップを発揮してプロジェクトを成功に導くことが求められている。
[Reported by H.Nishimura 2009.07.30]
Copyright (C)2009 Hitoshi Nishimura
