プロジェクトをあるべき方向に導くためには、いかに協力者をつくり、説得するかがカギです。その際に欠かすことのできない技――人を巻き込み、説得する力を発揮するための「意思決定プロセス」について解説します。
プロジェクトを管理する立場にある現場リーダーは、プロジェクトを軌道に乗せておくために、あらゆる工夫をします。綿密な計画を立て、慎重にモニタリングし、進捗が遅れれば是正処置を取ります。それでも、想定通りに進むことは、まずありません。
進捗が遅れれば、スケジュールを延ばすのか、リソースを追加するのか、メンバーを入れ替えるのか、判断しなくてはなりません。場合によっては要件を縮小する必要があります。こうした意思決定の場面が、経験豊かな現場リーダーと、そうでない人との違いが最も表れるところなのです。
現場リーダーの意思決定能力は、プロジェクトに直接的に影響します。特に、想定外の問題が発生したときに判断を間違えれば、会社や組織にもダメージを与えることすらあります。
意思決定の方法論として知られるものの1つに「ケプナー・トリゴー・メソッド」があります。この方法論を開発した、チャールズ・ケプナー氏とベンジャミン・トリゴー氏は、優れた管理者たちが共通の特徴を持っていることを発見しました。
その特徴とは、(1)自分自身の意思決定のプロセスを説明できる(2)意思決定プロセスがシンプルである(3)問題の大小にかかわらず同じ意思決定プロセスを用いる、というものです(図1)。
リーダーたちは意思決定を求められるとき、たいてい決まって同じことを聞きます。私のかつての上司は「ほかに方法はないか?」「その方法を採ったときに起き得る問題は何か?」と尋ねるのが常でした。質問が同じであることは、決まったプロセスで判断していることを示しています。
意思決定のプロセスを身に付けるメリットは大きく分けて4つあります(図2)。
( i )問題に落ち着いて対処できる
意思決定が求められる場面は、緊急であったり、判断が将来に大きな影響を与えたりする場合のほうが多いでしょう。その状況では、どんなに冷静な人であっても、通常の精神状態を保つのは難しいものです。同じ問題は1つとしてありません。経験豊富なリーダーでも、目前の問題は常に未経験といえます。重要性や緊急性が高く、未経験の問題に、落ち着いて対処するためのアプローチが「決まったプロセス」を用いることです。
( ii )どんな分野にも応用できる
プロジェクトとは「独自のアウトプットを生み出す、有期性のある業務」です。おのずと、やったことがない仕事に取り組む形になります。当然、知識や経験の乏しい部分があります。プロジェクトには数多くのタスクが含まれ、各タスクには専門知識が必要です。現場リーダーがこれらの専門知識のすべてに精通するのは不可能です。
それでもリーダーには正しい判断を下す力が求められます。ただ、リーダーに求められるのは「自分で正しい答えを出すこと」ではなく、「正しい答えを出せるように導くこと」です。この際、どんな分野にも応用できる「決まったプロセス」が役立ちます。
( iii )経験のバイアスを避けられる
問題解決を図るとき、専門知識があると大きな助けになるものの、問題が発生したときに「原因はこれに違いない。前もそうだった」という思い込みに陥りがちです。過去にうまくいった解決策が今回も同じようにうまくいくとも限りませんし、もっとよいアプローチがあるかもしれません。人は思い込みがあると、考えるべき道筋をショートカットしてしまいます。しかし、決まったプロセスを用いることでショートカットを避け、思い込みのワナに陥るのを防ぐことができます。
( iv )意思決定を論理的に説明できる
現場リーダーは、プロジェクト内外のさまざまなステークホルダー(利害関係者)との利害を調整しなければなりません。そのためには、プロジェクトとして決定した内容をステークホルダーに伝えたり、上司を説得したりしなければならない場面も多いでしょう。
このような場面で、多くのリーダーが悩むのが「なぜ、そのように判断したのか」「なぜ、そのように対処すると考えたのか」をうまく説明できないことです。経験上も状況的にも「そうするべき」だと確信しているのに「根拠を示せ」と言われて戸惑った経験がある人も少なくないでしょう。
「なぜ、そのように判断したのか」を説明できなければ、ステークホルダーは納得しません。説明できないのは根拠がないのだと見られるのです。合理的な意思決定のプロセスを持つことで、根拠を論理立てて説明できるようになります。
現象と問題を区別する
意思決定が求められるのは、そこに「解決すべき問題」があるからです。では「問題」とは何でしょうか?「問題解決」というワードが一般的になっていますが、「問題とは何か」を突き詰めて考えている人は少ないようです。
プロジェクトの要件定義フェーズでは「お客さまが抱える問題をヒアリングする」というフレーズをよく聞きます。多くの現場では、フェーズやプロセスの名称として「問題分析プロセス」と記述しています。ただ、「問題とは何ですか?」と尋ねても、答えられる人は少ないのです。
ここで「問題」といっているのは、単に「お客さまが困っていること」だったり、「今のシステムに対する不満」だったりします。しかし、これらはあくまで困りごとや不満という「現象」であって、問題の本質ではありません。問題の本質に踏み込み、意思決定プロセスを適用して解決するためには、まず「問題とは何か」を構造的に捉える必要があります。
問題とは何か
問題の本質とは、現状(AsIs)とあるべき姿(ToBe)との「ギャップ(乖離(かいり))」です。このギャップを探し出し、ギャップを埋める方策を導き出すのが問題解決のプロセスです。このプロセスの中で、合理的に方策を選択し、説明可能にするのが意思決定プロセスといえます。
ギャップには、大きく分けて2つの種類があります。
1つは、あるべき姿が何かの変化によって、ギャップが生じてしまった場合です。多くの場合、何かの条件が変わった結果、ギャップが生じます。この条件の変化を突き止め、その変化は取り除けるかどうか、一時的な変化なのか、永続的な変化なのかによって、解決のアプローチを変えます。
例えば、これまでずっと計画通りに進捗してきた作業が、何かをきっかけに遅れたとしたら、何らかの変化があるはずです。新たなフェーズに移行し、計画の前提としていた生産性が出せていない、担当者が変わったなどです。
もう1つは、初めから一度もあるべき姿を満たしていないものです。変化を伴わないギャップは、設定されたあるべき姿に問題があるか、あるべき姿を達成するための条件がそろっていないかのどちらかです。
プロジェクトが一度も“オンスケジュール”になっておらず、ずっと進捗が遅れている状況がこれに当たります。この場合、何かがきっかけで遅れたのではなく、計画そのものに無理があったわけです。工数見積もりの前提が間違っていたり、予算が先に決まってから金額を工数換算していたりなど、計画立案そのものが間違っていないかをチェックする必要があります。