システム構築のための調整力向上講座（第38回） 成功確率を高める意思決定の4プロセス<下>

（C）決定分析プロセス

　問題の原因が特定されれば、解決策を講じるのはそう難しくはありません。しかし、プロジェクトの遅延対応のような問題には、複数の人の思惑が絡む場合が多く、最善策を決めるには混乱を伴うことが多いのも事実です。声の大きい人の意見が通ったり、自部門の都合ばかりを考えた議論になったりします。このような事態を避けるためには、納得感のある合理的なアプローチが必要となります。

　決定分析プロセスは、以下の3つのプロセスをたどります。

（1）目的を明らかにする
（2）満たすべき要素を定義する
（3）複数案を評価する

（1）目的を明らかにする
　問題は同じであっても、問題解決の目的が異なるケースはよくあります。例えば「プロジェクトの進捗が遅れている」としましょう。このとき、問題解決の目的が「コストを予算内に収める」なのか、「納期を守る」なのかで、対策は全く違ってきます。

（2）満たすべき要素を定義する
　目的が定まれば、次に「目標」を設定します。目標とは「どうなれば、目的が達成されたといえるのか」という判断基準です。目標を定義すれば、解決策を評価可能になります。

　目標の中でも、必ず満たさなければならないものが「絶対目標（MUST）」です。絶対目標には程度がありません。絶対目標は「満たすか」「満たさないか」のどちらかです。

　具体例で示しましょう。システム構築プロジェクトのスケジュールが遅延し、現状で「半年遅れ」の状況だとします。プロジェクトマネジャーのあなたはクライアントと交渉し、「3カ月遅れでのカットオーバー」までは許容してもらえました。また、構築中のこのシステムは、稼働後に止めるのが難しく、クリティカルな不具合は絶対に出さない条件となっています。この場合、「3カ月以内の遅延で収める」「リリース後のクリティカル不具合ゼロ」の2つが絶対目標となります。

　ミーティングの結果、上記2つの絶対目標を達成するための案として、「外部に委託する」「メンバーを他のプロジェクトから引き抜く」「要件を削減（ドロップ）する」という3つの案が出されました。図5を見れば分かるように、1つ目の案は「4カ月遅れに短縮」ですから、「遅延を3カ月以内に収める」という絶対目標を満たしていません。よって「NO GO」となります。

（3）複数案を評価する
　絶対目標以外の「できれば望ましい」ものが「希望目標（WANT）」です。希望目標は「GO/NO GO」の2値ではなく、相対的にどの程度満たしているかの判断となります。また、それぞれの目標の重要度では同じではないため、目標に重みを付ける必要があります（図6）。

　図6の例では重みを付けて評価した結果、A案がスコア144、B案がスコア160となりました。B案がより良い選択ということになります。重み付けやポイントは感覚値ですから、このスコアは厳密に定量的なものではありません。しかし、判断のプロセスとロジックが見える化されて説明が可能になり、ステークホルダーの納得感も得やすいのです。

（D）潜在的問題分析プロセス

　ここまでの3つのプロセスが目前の問題を解決するためのプロセスであるのに対し、「潜在的問題分析プロセス」は、将来を予測し、将来に備えるプロセスです。「将来、どんな不都合が起こり得るか」「それに対して、いま何ができるか」という2つの問いに答えます。

　潜在的問題とは「リスク」のことです。リスクとは「起こるかもしれないし、起こらないかもしれない」という潜在性を指します。プロジェクトを軌道に乗せておくには、このリスクに対して敏感になる必要があります。

　潜在的問題分析プロセスは、次の4つからなります。

1.危険領域を確認する
2.具体的なリスクを抽出する
3.原因を特定し、予防対策を講じる
4.発生時対策

1.危険領域を確認する
　潜在的問題分析プロセスは、プロジェクトを進めるに当たり「最も危険なところはどこか？」を考えるところから始めます。メンバーでブレーンストーミングをしたり、経験豊富な社内外の専門家に意見を募ったりしてプロジェクトに潜む危険性を特定します。

2.具体的なリスクを抽出する
　危険領域を特定したら、次に具体的に起こりそうな現象を考えていきます。危険領域の特定で、大ざっぱに範囲を絞り、その範囲の中でより具体的にリスクを特定するわけです。

3.原因を特定し、予防対策を講じる
　次に、それらの具体的問題がどのような原因によって引き起こされるかを考え、予防対策を講じます。予防とは、考えられる問題の原因を部分的、もしくは全面的に取り除くことを指します。

　例えば、「要件が固まらず、設計フェーズに移行できない」という問題であれば「クライアントから新たな要求が次々に追加される」や「クライアント側の業務メンバーの時間が確保できない」などが原因として考えられるでしょう。想定される原因が分かれば、「変更管理委員会を設け、クライアントにも入ってもらう」「業務メンバーをプロジェクトメンバーとしてアサインする」など、予防策を考えられます。

4.発生時対策
　発生時対策とは、リスクが顕在化し、「問題」となったときにどうするかをあらかじめ決めておくことです。事前に対策を考えておけば、後手に回ることなく、問題に対処できます。

　先の例でいえば、「クライアント側の業務メンバーの時間が確保できない」という問題が実際に起こってしまったらどうするかを考えます。「土日に休日出勤してもらい、集中的に行う」「長期休暇を返上してもらい、合宿を実施する」などが考えられるでしょう。この案を事前に示しておけば、なんとか回避しようとする可能性もあります。

　リスクを知っていながら、本気になって取り組まない原因は、「このままいくとどうなるか」が具体的に見えていないからです。発生時対策を考えることで、リスクに向き合わざるを得なくなるのです。

●デキるリーダーは「意思決定プロセス」を持っている。
●意思決定プロセスは「状況把握」「問題分析」「決定分析」「潜在的問題分析」の4つからなる。
●意思決定プロセスによって判断の根拠を明らかにし、判断の精度を高める。