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

　意思決定には大きく分けて、以下の4つのプロセスがあります。

（A）問題把握プロセス（状況把握と明確化）
（B）問題分析プロセス（原因と結果）
（C）決定分析プロセス（選択）
（D）潜在的な問題分析プロセス（将来の予測）

　これらは、それぞれ「何が起こっているのか？」「なぜそうなったのか？」「どういう対応をすればいいのか？」「将来起こりそうなことは何か？」の問いに答えるものです（図3）。

　以下、この4つのプロセスを基に、プロジェクトマネジメントの視点を交えながら見ていきましょう。

（A）問題把握プロセス

　問題の解決には、まず「何が起こっているのか」を把握する必要があります。プロジェクトでは、さまざまな問題が起こる一方で、すべての問題に等しく時間を割けません。だからこそ、優先順位を付ける必要があります。問題には緊急度もあります。緊急時とそうでないときとでは、アプローチが異なります。

　今回は、緊急時のアプローチを見てみましょう。状況を把握するためには、まず情報を集めなければなりません。初動時にいかに質の高い情報を集められるかが、意思決定プロセス全体の質を左右します。以下の順に進めていきます。

（1）問題を5W1Hで詳細化する
　まず、何が起こっているか、「5W1H」の視点で情報を集めます。これは「六何（ろっか）の原則」とも呼ばれます。危機管理の第一人者である佐々淳行氏は著書『危機管理のノウハウ』の中で六何の原則に基づいた情報収集の重要性を強調しています。

　5W1Hの中で、真っ先に知るべきは「What：何が起こっているか」です。その次が「Who：誰が」。以下、「When：いつ」「Where：どこで」の順番で続きます。残りの「Why：なぜ」「How：どのように」については、後からで構いません。緊急の問題が発生したときには、この2つは分からない場合が多く、情報を集めるには時間を要するからです。

　例えば、納入したシステムで障害が起こったとしましょう。まず知るべきは「どんな現象が起こっているか」です。この場合「誰が」は明確ですね。次は「いつから起こっているのか」「どの部署で起こっているのか」を把握します。原因追及や犯人探しは後からでよいのです。

（2）最悪の事態を想定する
　問題が発生したときには、最悪のケースを想定し、それを避ける対策を講じます。最もやってはいけないのは、「大したことにはならないだろう」と高をくくることです。事態を甘くみれば、対策も甘いものになります。

　事態の深刻度を50で見積もっている状況で、80の現実が起こると、どうしようもありません。現実に翻弄されるだけになります。しかし、深刻度を100で見積もっていれば、80の現実が起こっても対処できるのです。問題が起こったときに考えるべきは「この問題が引き起こす可能性のある最悪の事態は何か？」ということです。

（3）最悪の事態の回避方法を考える
　次に「どうすれば最悪の事態を避けられるか」を考えます。このとき、最初に思いついた方法に飛びつかないようにしましょう。必ず、複数の方法を考えます。最初に思いついた方法には思い込みが入っている可能性があります。それ以外にもよい方法があるかもしれません。精度の高い判断をするには「比べる」ことが有効です。人の判断力は比較するときに発揮されるからです。2つ以上のアプローチを考え、比較するようにします。

（4）新たな問題の発生を考える
　複数の解決策を考えたら、それらの選択肢の中から、どの手段を取るのかを選択し、より解決に近づく可能性の高い方法を選びます。

　このとき「その方法は新たな問題を生み出さないか」を考えることを忘れてはいけません。アクションを取れば、どこかに何らかの影響を与えます。障害対策に人を使えば、工数を使います。並行して動いているプロジェクトのリソースを使えば、スケジュールの遅延を招く可能性があります。問題への対策が新たな問題を生み出すことはよくあります。新たな問題への対策まで取ってこそ、真に問題が解決できたといえます。

（5）情報を伝達する
　問題が起きたときには、速やかに情報を伝達する必要があります。情報伝達で最も避けるべきは「もう少し状況がはっきりしてから」と待つことです。情報はリアルタイムに発信するのが原則。時間がたてばたつほど、打てる手が限られてきます。状況がはっきりしないのであれば、「現時点ではここまで分かっているけれど、ここからははっきりしない」と、ありのままに発信します。

（B）問題分析プロセス

　状況把握プロセスで「いま何が起こっているのか」を把握したら、次は「なぜ、そうなったのか」を考える「問題分析プロセス」です。問題分析プロセスは、以下のプロセスをたどります。

（1）あるべき姿を明確化する
　問題とはギャップのことで、ギャップとは「現状」と「あるべき姿」との乖離（かいり）ですから、問題を知るためにはあるべき姿を明確にしなければなりません。プロジェクトの進捗が遅れているのであれば、あるべき姿として本来の進捗率を知る必要がありますし、障害が発生していれば障害が発生していない本来の状態を知る必要があります。

（2）「IS」と「IS NOT」で比較する
　多くの場合、問題は変化によって引き起こされます。変化を探ることが問題分析の手がかりとなります。問題が起きている部分（IS）と、同じような問題が起きていそうなのに起きていない部分（IS NOT）を明らかにすると変化を見つけやすくなります。

　例えば、同じソフトウエアを利用しているのに、一方だけ障害が発生している場合、両者の差異から変化を見いだせる可能性が高いわけです。このとき「状況把握プロセス」で使用した「六何」を切り口にして、「IS」と「IS NOT」を探していきます（図4）。

（3）区別点と変化点を摘出し仮説をつくる
　IS とIS NOT を整理すると、どの点で違っているのかという「区別点」が明らかになってきます。この区別点のあるところが怪しいわけです。区別点が明らかになったら、そこに変化の要素がないかを調べます。区別点に変化の要素を見いだせれば、そこから問題を引き起こす「原因」が浮かび上がってきます。これが「仮説」です。

　図4の例であれば、「3週間前にサポートが設定を変更した」「設定変更前にバージョンアップを実施した」ことが問題の原因かもしれないという仮説が立てられます。

　仮説を立てるとすぐにそれを基にした解決策を試したくなります。しかし多くの場合、トライアル＆エラーを繰り返して時間ばかりがムダに過ぎてしまいがちです。

　仮説は検証しなければなりません。検証せずに解決策を考えると、その解決策に執着してしまいます。仮説の正しさを証明しようとしてしまうのです。仮説はあくまでも仮説に過ぎません。仮説の精度を高めてから解決策に移るほうが遠回りに見えて実は近道なのです。

（4）仮説を検証する
　仮説の検証には、その仮説は「IS」と「IS NOT」を正しく説明できるかと、仮説が示す原因を取り除いた際に問題が収まるか、の2点を確認します。

　図4の例で「設定変更前にバージョンアップしたこと」が原因だと仮説を立てたとします。検証には、「他に同じバージョンを利用しているところでも、同じ現象が発生しているか」「他のバージョンで同じ現象は発生していないか」を調べる必要があるでしょう。さらに、テスト環境を用意し、バージョンを戻したら問題が収まるかどうかを確認します。