« Risk Triangle(その1) | トップページ | Black Friday »

2007年11月25日 (日)

Risk Triangle(その2)

20071123_1_2 スケジュールリスク、技術リスク、コストリスク、これらがお互い密接に関係していると言うことはどういう事かについて考えてみよう。

技術的な問題が発生すると(技術リスク)その問題に費やすコストが増加するのでコストリスクが高まるか、問題解決の時間が必要となってスケジュールリスクが高まる。これらのどちらかもしくは両方が起こることになる。

スケジュールに遅れが生じると(スケジュールリスク)人件費や保管費用を初めとしたコストが増加してコストリスクが高まる。逆にスケジュールを圧縮する必要が出てきたときには設計、試験、製造などの開発に当てる時間が削られるので技術リスクが高まる。

コストが予想以上にかかっているのに必要なリソースを増やすことができないと(コストリスク)これまた設計、試験、製造などが十分できないまま進めなければならなくなるので技術リスクが高まる。

前回説明しなかったが、さらにもう一つプログラムリスク(Programmatic Risk)と呼ばれるリスクがある。これはマーケティング、セールス、戦略などの非エンジニアリング的な視点から持ち込まれるもので、開発のみに集中した いエンジニアからすると非常にうっとうしいものだが決して忘れてはならない重要なものだ。

他社の新製品の動向や市場のニーズがプロジェクトの実行中に変わることは普通にある。他社が明らかに性能や使いやすさなどで上回る製品を出してきた場合や、何らかの大きな事故が起こって消費者が求める安全性や性能基準が急に変わってしまった場合には技術リスクが高くなる。
他社に勝つためなどの理由で、新製品の発売を前倒しするように求められたりしてスケジュールリスクも高まる。
会社の運営状況から予算が必要如何に関わらず限定されてしまう事もある。これでコストリスクが高まる。

つまり、実際はこのプログラムリスクを中心とした三角形のうち、どこかに問題が発生すると他の項目に必ず波及する。優れたプロジェクトマネージャーは、もちろん何とか工夫して問題そのものの解決を試みる のは当然としても、これらのうちのどこかにちゃんと余裕をみて開発を進めるか、問題が起こったときにはどこかに妥協点を見いだすことができるものだ。

そういうわけで、全てのリスク項目を締め付けてしまうと、どこにも逃げ場が無くなってしまって、結果的にリスク管理が非常に難しくなることが分かる。
3つのうち、一度に大きく改善できるのは1つ、せいぜい2つまでを選ぶのが正解なんだろう。3つ共を選んだ場合は、できれば努力目標が許される程度で、ほんの少しだけ改善するのが精一杯のはずだ。(もちろんプロジェクト差はある)

それでも本当に実行するのならば、革新的な実行プランが既にあって、旧来の仕事のやり方をがらっと変える事を厭わずに、しかもプロジェクトのメンバーやサプライチェーンに含まれる企業なども含めてそれに対応できるだけの能力がないと難しいことなのだと思う。

« Risk Triangle(その1) | トップページ | Black Friday »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/176692/9085168

この記事へのトラックバック一覧です: Risk Triangle(その2):

« Risk Triangle(その1) | トップページ | Black Friday »