« 第10章:プロジェクトコミュニケーションマネジメント(その2) | トップページ | やっぱりヘンだぞ雑誌「選択」 »

第11章:プロジェクトリスクマネジメント(その1)

ここでは、プロジェクトリスクマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords
 ・リスクとは何か
 ・リスクの要素
 ・リスク許容度
 ・リスクマネジメントとは何か
 ・リスクマネジメントのインプット

リスクマネジメントはリアルに使える。問題に直面したとき、具体的にどうふるまえば解決へ導き出せるのかが分かる。一方で問題を顕在化させないように予め何をしておくべきなのかも分かる。予測を超えた事態に直面したとき、どうすればよいかが分かる

一説によると、適切なリスクマネジメントを行うことによりプロジェクトで発生する問題の90%を減らすことができるそうな…というのも、リスクマネジメントはプロアクティブ(proactive)な仕事だからだそうな。プロアクティブ…予め先を見越して(pro)行動する(active)ことにより、問題化するまえに解消することがミソだからだろう

リスクとは何か(p.127)
「プロジェクトリスクとは、もしそれが起こったならばプロジェクト目標にプラスやマイナスの影響を与えるであろう不確かな事象あるいは状態のこと」だそうな。ポイントはマイナスだけでなく、プラスの影響を及ぼしうる事象でも「リスク」とであること

リスクには既知のリスクと未知のリスクがある。既知のリスクとは、既に識別・分別できているリスクのことで、対策も同時に立てることができる。未知のリスクとは、マネジメントできないリスクのこと。だからといって放置プレイすることはしない。プロジェクトマネージャはこれまでの経験により、「未知のリスクのための予算」を組んでおくとか、「未知のリスクのためのスケジュールバッファ」を取っておく。盆暮れにスケジュールを組むときにはカレンダーどおりに立てない。思わぬ欠員が出たりするから…って皆やってることを、PMBOKではコンティンジェンシー(contingency:偶発性)予備と呼んでいる

リスクの要素
リスクを識別する際、その要素は次の通り


  • 顕在化したとき、何が起きるのか?
  • どの範囲の影響が起きるのか、リスクのインパクトは?
  • プロジェクトライフサイクルのうちで、どの時点で起きうるのか?
  • どれぐらいの頻度で起きうるのか?

リスク許容度(p.129)
ガマンできるレベル。ガマンできない人がたくさんいるが、プロジェクトをこかしてもそのリスクは許せないのか? 品質が○○でもそのリスクは許せないのか? スケジュールが大幅に狂ってもそのリスクは許せないのか? などと、質問の仕方はいろいろある …でもってほとんどのリスクは何かとのトレードオフとなりうる

リスクマネジメントとは何か(p.127)
リスクマネジメントとは、プロジェクトのリスクを識別・分析し、リスクに対応するための系統的なプロセスのこと。リスクマネジメントプロセスとは、プロジェクトの目標に対し


  • プラスとなる事象については、その発生確率と発生した結果が最大となるようにする
  • マイナスとなる事象については、その発生確率と発生した結果を最小となるようにする

こと。こう考えると、プロジェクトの目標が何であるか分かっていないのであればリスクマネジメントは1ミリも動けない。取るべき優先順位はプロジェクトの目標に従う。プラス・マイナスの事象は目標に照らし合わせて判別する(ときには+-はコインの表裏となるから)…などといろいろ分かってくる。んで、リスクとして識別できた事象が分かれば、発生確率、発生結果をコントロールする方法も分かってくる

例えば、プロジェクトの目標が「新規市場開拓のため、○○技術を用いたシステムを開発すること」であれば、優先順位は


  1. スコープ(ここでは○○技術)
  2. 品質
  3. 納期
  4. コスト

となる。新技術を使っていることが最も重要だろう。一方、市場開拓のための先行投資だという言い訳は多少コスト高となっても通じるだろうからコスト優先度は相対的に低い。「○○という新技術」を念頭に考えると、いちばんありがちなのは、「メンバーはその技術に適応できるだろうか?」という疑問。うまく使いこなせないため、開発期間が延びたりするかもしれない。この場合、「スコープの新しさ」が原因で、「納期の延期」が結果だ。んで、「新しい技術に慣れない」という事象の発生確率を最小化するためには、

  • 開発メンバーへのトレーニングを充実させることで、新技術を熟知してもらう
  • まず小さい部分から着手して、スパイラルに開発していく手法を取る
  • コスト高になっても、その技術に詳しい人を集めておく

一方、「納期の延期」という結果を最小化するためには、

  • 試験工程を短縮するために試験メンバーを多めにとっておく
  • 設計開発より先行して新技術の研修会を開いておく
  • 最初から開発期間を長めに取るよう、スタートを前倒しする

などなど。ここでは「コスト」の優先度が低かったが、それはトレードオフ。コスト優先のプロジェクトであれば、上記の傾向と対策は全く異なるものになる。「何を優先(=目標に)するかにより、リスクは異なる」ことが重要。これがぜんぜん理解できていない厨房オヤヂが「ぜんぶ最優先だ」とか「あらゆるリスクを排除せよ」とかのたまう。フローラを選べばビアンカは引きこもる

リスクマネジメントのインプット(p.129)
PMBOKには6つあるが、噛み砕くともっとある。以下の通り


  • プロジェクト憲章 : プロジェクトそのものの情報や、プロジェクトを取り巻くビジネス環境を知ることにより、「いまここ」よりも広い視野でリスクを探すことができる。プロジェクトの概観をが分かるので、一般的にむずかしめなのかやさしめなのかが判断できる。どこまでがプロジェクトとして扱うのかが書いてあるため、リスクが依拠する対象がプロジェクト内なのか外なのかが分かる
  • 過去のプロジェクト : 似たようなプロジェクトで発見されたリスクは、このプロジェクトにも潜んでいる可能性が高い
  • スコープ記述書 : RFP(request for proposal)でも可。そのプロジェクトの複雑性は一発で分かるし、プロジェクトに必要なスキル/知識も分かる←足りない場合はリスクと化す
  • チーム : プロジェクトマネージャ単独で全てのリスクを洗い出すことはできない。リスクにはグループであたる。チームで取り組むとより正確でタイムリーなリスクマネジメントを行うことができる
  • ステークホルダー : チームで足りない部分を補ってくれる。ステークホルダーマネジメントにもなる
  • WBS : 神は細部に宿る。リスクはタスクに潜む
  • ネットワーク図 : タスクの依存関係がわかる。さらにどのパスにどのタスクが集中しているかがわかるため、特性的なリスク解析ができる
  • 見積もり : 時間とコストの見積もりはそのままリスクマネジメントのインプットになる。「時間リスク」と「コストリスク」になる
  • 人員計画 : どのリソースがいつ使えるかが分かれば、足りなさそうなところはリスクになるし、リスク対応計画のインプットにもなる
  • 組織のテンプレート : テンプレート(標準様式)を埋めるだけでリスクマネジメントの助けになる…が本来リスクはプロジェクト毎に有するもの。たやすく一般化できるとは思えないが…
  • 調達計画 : リスクと契約には強い相関関係がある。そのリスクをプロジェクト内でとるよりも、ずっと低いリスク(あるいは低いコスト)で他組織で取ってもらう方法がアウトソーシングといえる
  • ステークホルダーのリスク許容度 : 個々のリスクをどれぐらいのインパクトがあるものとして扱えばよいかが分かる。またリスク低減手段に何を選べばよいかの判断になる

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--

|

« 第10章:プロジェクトコミュニケーションマネジメント(その2) | トップページ | やっぱりヘンだぞ雑誌「選択」 »

コメント

役立つ情報ありがとうございます。
かなり、参考にさせて頂いております。
1点質問させて下さい。

>盆暮れにスケジュールを組むときにはカレンダーどおりに立てない。思わぬ欠員が出たりするから…って皆やってることを、PMBOKではコンティンジェンシー(contingency:偶発性)計画と呼んでいる

とのことですが、この例えは、コンティンジェンシー予備かと思うのですが・・・。
いかがでしょうか?

投稿: がんばる父さん | 2005.04.15 10:05

がんばる父さん、ご指摘ありがとうございます。たしかにコンティンジェンシー予備(contingency reserve)と呼ぶべきですね。訂正しておきました、ありがとうございます。

試験がんばってください。

投稿: Dain | 2005.04.17 22:18

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 第11章:プロジェクトリスクマネジメント(その1):

« 第10章:プロジェクトコミュニケーションマネジメント(その2) | トップページ | やっぱりヘンだぞ雑誌「選択」 »