◆チェックリストは有効か
まず、現在、リスクの洗い出しの方法として最も一般的なチェックリストについて考えてみたい。リスクから離れてもいいので、みなさんがチェックリスクを作る場面を何か考えてみてほしい。
チェックリストが有効なのは、プロジェクトの目的達成のために行わなくてはならないことの全体像が分かっている場合である。チェックリストを作ってみて、それを何人かで点検し、抜けがないことを確認し、そのチェックリストを使う。
例えば、要件定義に関するリスクだと
・顧客側で部門間の利害が対立し、仕様が一本化できない
・顧客側の担当者の時間がとれない
・顧客側の仕様の調整役が不在
・役員などの介入がある
・顧客に申し入れた時間では終わらないで尻切れになる
・…
といった定番的なリスクがあるが、このようなものはチェックリストを使うことによって過去の経験を活用でき、有効である。
ところが、あまり経験のない仕事だったり、あるいは不確実性の高い仕事だったりすると、チェックリストを網羅的に作成することは難しいし、また、質という点でも問題が残る場合が多い。例えば、上の例で、作業の途中から顧客側にＩＴコンサルタントが入っていて、顧客のとりまとめをしたとすると、上のリスクは考える必要がなくなるものもあるし、逆に、例えば、仕様が重くなってしまうという新たなリスクもあるかもしれない。つまり、前回、説明したようなリスクの変動が発生する。
そのような場合、プロジェクトの進行に応じてチェックリストを見直すことは大変難しい。
チェックリストが有効な方法であることは間違いないが、このようにチェックリストだけで済まそうとすると、前回、説明したようにリスクが変動した場合に対応できないケースが多いことは頭に入れておく必要がある。
◆構造的なアプローチ
そこで考えるべきことは構造的なアプローチである。リスクの変動に対応しようとした場合、リスクの洗い出しの方針（視点）を明確にしておくことが重要である。そのためには、リスク洗い出しの枠組みを明確にすることが重要だ。そうすることによって、全体の整合性を保ちつつ、必要に応じてその視点でもう一度リスクの見直しをすることができるからだ。
その枠組みとしては、ＭＥＣＥであることが要求される。例えば、ＷＢＳのワークパッケージ、リスクによるダメージのカテゴリ、ステークホルダなどさまざまなものが考えられる。ＭＥＣＥとは全体をもれなく、ダブリのない集合に分けて、枠組みをつくり、その枠組みに具体的な要素を洗い出していくという思考方法である（詳細は、http://www.pmos.jp/honpo/solution/MECE.htm を参照）
ＷＢＳに注目する方法は、プロセスアプローチと呼ばれるものであり、ＷＢＳのワークパッケージ、あるいは、場合によってはアクティビティに注目し、初期リスクを洗い出し、さらに、プロジェクトの実行中にもリスクの見直しをする方法である。Ｗ
ＢＳは成果物の構造に対してＭＥＣＥになっており、したがって、ＷＢＳのワークパッケージもＭＥＣＥな枠組みになっている。
リスクカテゴリは、例えば、技術、品質、コスト、時間、情報、モチベーション、ヒューマンリソース、契約といったカテゴリを設定し、必要に応じて、このカテゴリにさらにサブカテゴリを設定し、カテゴリに対してリスクの洗い出しを行い、さらにはカテゴリごとに見直していく方法である。チェックリストを作る際には、現実には、アドホックに作ることは珍しく、実際にはこのようなカテゴリを考えてチェックリストを作る。これにより、チェックリストをより効果的に運用することができる。
ステークホルダは、ステークホルダとの関係性に注目し、関係の中でどのようなリスクが想定されるかを洗い出していく方法である。この方法は意外と現実的な方法である。というのは、リスクというのはそもそも、ステークホルダの何らかの意思が発生源になっているからだ。極論であるが、例えば、品質リスクは顧客の意思によって変わる。ソフトウエアは本当にそのような傾向があるが、顧客がバグと考えなければ、バグもバグではない。ごまかすとかいうことではなく、品質リスクの大きな原因の一つである潜在バグは顧客との間のテスト計画書の合意内容で決まるといったことだ。
そう考えると、ステークホルダの意思を分析することによってリスクの洗い出しができるし、また、見直しもできる。
◆ＷＢＳによるリスクの洗い出し
ＷＢＳによるリスクの洗い出しは、上に触れたようにワークパッケージに注目して、リスクを分析する方法である。つまり、
ワークパッケージＡの中でリスクになるのは何か？
という考え方でリスクの分析をし、洗い出しをするのだ。この方法は、上で述べたカテゴリーと併用するとよりリスク分析の高くなる。つまり
ワークパッケージＡの中で
スケジュールを遅延させるリスクは
品質基準をクリアできない原因になるリスクは
コストを増大させるリスクは
情報の行き違い引き起こすリスクは
パフォーマンスを下げるリスクは
ヒューマンリソースの不足を引き起こすリスクは
契約上の問題を引き起こすリスクは
というように考えていく。さらに、精度を上げようとした場合、ワークパッケージではなく、アクティビティを対象にして同様なリスク分析を行う。ただし、アクティビティまで落とし込んだ場合、そこで想定されるリスクにはダブリのあるものが多くなり、洗い出しの後に、もう一度、全体をまとめて整理しておく必要がある。
◆リスクの洗い出しは何を根拠に行うのか
意外と難しいのが、何を根拠にリスクの洗い出しを行うかだ。チェックリストのように経験というのがまず考えらえる。確かに経験でカバーできる範囲は大きい。しかし、経験だけでは不十分であることは、チェックリストのところでの議論のとおりである。
そこで、あらゆるドキュメントを収集してくる必要がある。リスクの洗い出しという観点からドキュメントを整理すると
・プロジェクトの経緯資料
営業アプローチ、顧客情報、プロジェクトのテーマ発生の際の議事録など
・契約書
顧客、ベンダーとの契約書のテンプレート（契約前）
法律的な解釈が必要な情報
・経験情報
過去の類似プロジェクトのドキュメント、チェックリスト
・一般情報
技術、顧客、ベンダーなどの一般公開されている情報（帝国バンクなどで得られ
る有料の情報も含む）
・口コミ情報
ステークホルダとの接触、第三者との接触から得られる情報
・自社の経営情報
自社のキャッシュフローなどの経営情報
に分類できる。これらの情報を徹底的に収集し、分析を行い、リスクの洗い出しをしていく必要がある。
◆リスク洗い出し作業の進め方
リスク洗い出しの作業は基本的にはチームで行う。その際の進め方は、プロセス８の「チームによる問題解決」で説明しているので、改めて解説しない。そちらを参考にしていただきたい。
（2004/02/12号より抜粋）
■アクティビティ１：リスクの対処の考え方とプロアクティブな対処の必要性
■アクティビティ２：リスクの洗い出しの方法
■アクティビティ３：リスクの評価と対策の立案
■アクティビティ４：変化するリスクへの対応
> 2004/02/05 アクティビティ１：リスクの対処の考え方とプロアクティブな対処の必要性
◆プロジェクトマネジメントはリスクとの付き合い
◆リスクは変動する
◆リスクを変動させる要因
◆プロアクティブリスクマネジメント
◆プロアクティブリスクマネジメントの実現のポイント
> 2004/02/12 アクティビティ２：リスクの洗い出しの方法
◆チェックリストは有効か
◆構造的なアプローチ
◆ＷＢＳによるリスクの洗い出し
◆リスクの洗い出しは何を根拠に行うのか
◆リスク洗い出し作業の進め方
> 2004/02/19 アクティビティ３：リスクの評価と対策の立案
◆リスクの評価
◆リスク戦略
◆リスク対策
> 2004/02/26 アクティビティ４：変化するリスクへの対応
◆リスクマネジメントの難しさはリスクの変化
◆リスク事象が変わる
◆リスクトリガーが変わる
◆対策が変わる
◆変化への対処
◆リスクの見直しの周期
◆リスクシナリオの見直し
