問題解決上の障害を見逃さないための俯瞰的思考とは


問題を解決したと思った後でホゾを噛むのは?

一生懸命問題の解決策を考えたのに、クライアントは上の空。彼(彼女)が本当に心配していたのは「自分の地位が保てるかどうか」で問題解決の出来栄えではなかった、なんていうことはありませんか?この心配事を見逃したままでいると、肝心の問題の解決策の実行がおろそかにされることがあるので、要注意です。

コンサルタントはクライアントの問題を「確実に」解決する商売です。このような問題解決上の障害の見逃しは避けなければなりません。

でも、経験が浅いうちは「隠された」障害にはなかなか気づけません。どうしたら、この状態から脱却できるでしょうか?

そのためには、問題を見つめている自分とは別の視点を持つ事です。

Aという事象に対峙し、それを「問題」だと認識しているとします。この場合、「Aは問題だ!」と思っているのですから、通常であるならば、次に向かうべきは「問題Aに関する問題解決」です。

その結果、見逃しが生じたのならどうすべきでしょうか?

「問題解決」に向かう前に、一寸だけ、「本当にこれだけが解決すべき問題か?他に解決すべき問題(障害)はないか?」と問うべきなのです。

しかし、問題はこの問いが難しいことです。(いろいろなレベルで「問題」という言葉を使いますがご容赦ください。)

この問いが難しい理由は、問題解決をしている自分自身を一段上から見つめる視点が必要だからです。この一段上のことを「メタ」と呼びます。

大学で学ぶことで身につけられるものとは何か?:「囚われ」から自由になるための「俯瞰的思考習慣」!? の言葉を借りると「メタにあがり、問題を俯瞰する」のです。

メタな視点で、「Aという事象を問題だと認識したのはなぜか? なぜ、わたしはAという事象に”問題”のレッテルを貼り、他の事象には貼らなかったのか?」と問うのです。

さて、大学の先生であれば、これで片が付きます。でも、抽象的な思考に慣れていない街場の(笑)コンサルタントとしては手助けが欲しいですよね?

そのためには、「問題を俯瞰する方法」が必要です。

問題を俯瞰的に捉える7つの問い で、その方法をひとつ示しておきました。そこでは、「問題」そのものを幅広く俯瞰的に見る方法を示してあります。

今日は、もう少し広く問題解決を取り囲む視点での俯瞰的方法を解説することにします。

問題解決を俯瞰的に見るための質問とは

ここから述べる俯瞰滝な見方は一つの事例で、正解を示すものではありません。以下の記述を参考にして、皆さんなりの俯瞰的なものの見方を確立していただければと思います。

俯瞰的に見るための一つの方法は、地図を作成することです。地図の作成と言っても難かしいことではありません。議論の対象を明確にし、その相互関係を図示すれば良いのです。

問題そのものの地図の書き方は 問題を俯瞰的にとらえる7つの問い で論じたので、それ以外の対象を考えることにしましょう。

例えば、問題解決に関わる行為とその行為に携わる人とその環境ということで、以下のようなものを取り上げましょう。

  • 問題解決行為
  • 解決策の実行
  • クライアント
  • クライアントの環境(組織など)

この対象と自分(コンサルタント)との関係を図示すると以下の俯瞰図が得られます。この俯瞰図を眺めれば、図に示されたようないろいろなメタな質問が思い浮かび、それに対し自問自答することで、様々な隠された問題に気付くことができるようになるのです。

以下、そのような自問自答の例について見ていくことにします。

問題解決の俯瞰図

①問題解決方法は適切か?

ある製造業で三次元CADを導入しました。三次元の方が部品と部品の干渉(ぶつかり合い)などが簡単に検証できるので、実際に生産が可能かどうかの判定が容易になるなどのメリットがあるからです。

ただし、それまで2次元の図面を書いていた設計にとっては、非常に大きな改革です。

ここで、設計が大きな労力を払って三次元設計への変革をやっているにもかかわらず、後方部隊の生産技術や製造でその結果を有効活用していないということが問題になりました。

「なぜ三次元設計の結果を使わないのか」の原因究明が、設計チーム中心で延々と行われましたが、「設計が製造の事情に配慮した情報を寄こさない」などの水掛け論になり、議論が進みませんでした。

その議論を疑問に思った外部コンサルタントが、生産技術部門を歩き回って、本当に三次元の設計結果を使っていないのかを調べてみました。すると、一部の先進的な生産技術者は三次元CADの設計結果を使っていることが判明しました。

その技術者たちは、「確かに部品の干渉のチェックは易しくなるという効果がある」と述べました。そして、一言つけ加えました。

「設計から3次元情報が来るのは生産設計がほとんど終わってからだ。だから、最終検査にしか使えない。もっと早くその情報が来れば、生産設計の工数が大きく削減できるのだけが。。。」

そこで分かったことは、慣れた2次元設計の方法から離れたくない設計が、一旦2次元の図面を書いた後、最後の段階で3次元に移しているということでした。

本当は、設計が最初から3次元で設計をしていれば、後方部隊は喜んでその結果を使ったはずだったのです。

「なぜ3次元の設計結果を使わないのか」という大上段に振りかぶった原因の究明をしようとしたために、「ごく一部で使われている」ということが見過ごされたのです。このように設定した問題の原因を深掘りするアプローチをプロブレム・トークと呼びます。

このケースでは、「後方部隊が3次元設計結果を使いこなしている」というあるべき姿に向かって「何かうまくいっている例はないか?」という全く逆方向の問いをする方が効果的だったのです。このようなアプローチをソリューション・トークと呼びます。

コンサルタントは、クライアントの問題の解決策策定方法が適切か(過度のプロブレム・トークに陥っていないか、ソリューション・トークをした方が良いのではないか)と問い直すことも時として求められるのです。そうすれば、見逃しかけていた原因や解決策が見つかることもあるからです。

これについての詳しいブログ記事は、 成果の出ない解決策を作り出したのは、あなたのプロブレム・トーク を参照ください。

②解決策の実行まで考えているか?

策定された解決策が実行されるまでは、何も変化せず、改革プロジェクトの効果ははっきりしません。当たり前のことですよね?

でも、このことがコンサルティングで無視されがちなのです。コンサルタントが解決策の策定に熱中し、その後のことを考えないことが多いのです。そのために見す見す機会を逃すことも多々あるのです。

ある製造業の購買改革プロジェクトのことです。

このブログでも何度か触れたように、部品カテゴリごとの専門チームを立ち上げ、購買金額の削減策を立案していました。

しかし、今まで設計に対して従属的な立場にいた購買担当者たちは、自分たちが主体的に行動することを求められ、不安で仕方ありませんでした。議論にもなかなか前向きになれずにいたので、各チームの担当コンサルタントも議論のリードに苦労していました。

その中の一つに半導体メモリの購買チームがありました。

そこで考えられた施策の一つが「毎月価格交渉をする」というものでした。メモリは市況商品で価格の変動が激しいのですが、これまでこの会社は半年か一年に一度だけ価格交渉をしていたのです。

しかし、この案は担当コンサルタントから持ち込まれたものだったので、購買チームは乗り気ではありませんでした。

ところが、このプロジェクト時にメモリの価格が下がり始めました。そこでコンサルタントは、議論をやめて実際に価格交渉をすることを迫りました。

すると、当然ですが大幅なコスト削減が実現できました。しかも、メモリは購入金額が大きいので、購買部門全体のコスト削減予算にも大きな貢献となりました。

この削減効果でプロジェクト・チームの雰囲気が一挙に明るくなり、その後の改革に弾みがついたのです。理論上計算できるコスト削減額と実際に手にした果実とでは、人々の心理に与える影響が大きく違うのです。

もし、この時コンサルタントが「自分の仕事は解決策の策定」だけと思い込み、実際のコスト削減作業を迫らなかったら、どうなっていたでしょうか?解決策が出揃い、いざ実行する段階になった時には、メモリの価格は上昇に転じていたかもしれません。

解決策の策定・実行に当たっては、実行にあたる人たちのやる気をどう高めるか、実行にあったての障害をどう取り除くか、などを視野に入れるかどうかが、改革プロジェクトの成否を大きく分けます。コンサルタントは、そのことを知っておくべきなのです。

この話題については、チェンジマネジメントの勉強をしておくと良いでしょう。参考書としては、 ジョン・コッターの企業変革力 などがあります。

③クライアントの思考の癖が問題を捉えることを妨げていないか?

クライアントの思考の癖も本当の問題を捉えられるか否かに大きな影響を及ぼします。クライアントの頭に思い浮かばないことを現状として把握することは難しいからです。

例えば、このブログでもクライアントの思考の癖が次のように問題解決を妨げることを述べてきました。

これらの思考の癖は、間違った問題解決に向かわせるものです。

それ以外の思考の癖としては、問題解決プロセスそのものの進行を妨げる、という類のものもあります。

例えば 「洞察力」があらゆる問題を解決する という本は、「見えない問題を見抜く力」について論じています。

この中に、組織は意図的にその中の従業員の「見えない問題を見抜く力」を抑圧している、と書いてあります。組織は、予測可能であることに価値を置き、誤りがないことを期待する体質があります。その結果、組織の構成員は「予測可能性の罠」と「完璧守備の罠」にはまっているというのです。

この罠に囚われているクアイアントと議論する時は、それなりの対処をする必要があります。

予測可能性の罠にはまっている人は、次のように無意識のうちに大事なアイデアを排除してしまう可能性があり、その対策が必要です。

  • 議論を、自分が慣れた言語・方法論に従って進めようとする人たちがいる。手順が定まっていて、しかも一定の成果が出ることを経験上知っているため、それに従うのが安心だからである。例えば、SE(システムズ・エンジニア)と議論すると、かなりの確率で対象となる問題をシステム・フロー図で表現しようとする。この表現様式は人間の困りごとを表現するのには向いていないのだが、そのことには気づかずに無意識に人間的な問題を排除する。このタイプの人には、使用する問題表現方法の限界を意識させるところから議論を始める必要がある
  • 問題の解決策が複数存在するときは、どれを選択するか決定する必要がある。その時に、実行時のリスクを評価し、無意識に必ずリスクの小さい代案を選ぼうとする人たちがいる。この種の人たちには、解決策の実行後得られる状態の評価を迫り、その状態が望んでいたものかを判定してもらう必要がある。そういう人たちは、望んだ結果が得られるかどうかではなく、解決策を実行したことで満足してしまうからである

完璧主義の罠は、プロジェクトの進行を遅らせる傾向があります。その結果時間切れで大事な意思決定ができなくなるリスクがあります。その例と対処方法には、次のようなものがあります。

  • 議論をしていると、「網羅性は大丈夫か?」としつこく確認する人がいる。この種の人に議論を主導させると、たとえ瑣末であっても考えられる全ての場合を尽くさないと、議論を先に進められなくなる。この人たちには、予め議論の進め方について次のような合意形成をしておく必要がある。
    • 議論に費やせる時間の制限の合意
    • 議論内容の重要性の評価基準の合意
    • 重要度の高いものから議論していき、時間制限が来たら議論を終了することの合意
  • 世の中には問題を完璧に解決しないと気が済まない人がいる。100点主義である。しかし、一般に問題を完璧に解決することは難しい。多くの解決策の実行は易しいが、一部に実行が難しい解決策があるのが常である。難しい解決策の実行方法の検討に拘ると、他の解決策の実行に手がつかず問題の解決が遅れる。0点より50点の方が良いので、まず50点の実現を先行させるように迫るべきである

コンサルタントは、常にこのようなクライアントの思考の癖に関する知識を広げておき、その癖がもたらす問題解決上の障害を取り除けるようにしておくべきなのです。

④クライアントの環境・組織が問題解決を妨げていないか?

クライアントが置かれている環境が問題解決を妨げることがあります。

この環境としては、次のようなものがあります。

  • 変革プロジェクトの体制そのものに関わるもの
  • 変革対象の事業の環境に関わるもの

変革プロジェクトの体制が問題解決に与える影響については、以下のようにプロジェクト・オーナーに関するものとプロジェクト・メンバーに関するものがあるので、プロジェクトの体制確立時に十分な注意を払うことが求められます。

事業の環境に関しては、クライアント自身が問題の解決策を知っていても、その実行が難しい場合があります。例えば、 問題はなぜ解けないままで残っているか? で述べた、部品メーカーの受注激減問題がその例です。

そこでは、次のような問題がありました。

  • 設計プロジェクトの詰め込みすぎが開発スピードの遅れを引き起こしており、その結果受注を逃している
  • 設計部門はこのことに気づいていたが、詰め込みすぎを引き起こしている年長の営業部門に対して意見が言えずにいた

この関係に気づいたコンサルタントが、この問題を営業が反論できない形で整理して事実として提示しました。そうなって初めて、解決策が検討されるようになったのです。

コンサルタントは、クライアントを囲む環境にまで目を向けて、問題解決の障害を取り除くべきなのです。

 まとめ

  • 問題解決をしていると様々な障害に出くわす。コンサルタントは、それらの障害も解決すべき問題だと心得るべきである。それらの障害が取り除かれないと、本来の問題が解決しないからである
  • しかし、それらの障害に気づくことは簡単ではない。問題解決に取り組んでいる自分自身を一段上のメタな視点から観察する必要があるからである。
  • メタな視点から物事を見られるようにするための一つの良い方法は、地図を書くことである。対象となる問題解決行為と当事者、環境などからなる地図を書くと、以下のようメタな視点からの質問ができ、問題解決上の障害の除去が容易になる
  • 「問題解決方法が適切か」と問えば、過度に原因の深掘りをしていて手近な成功例を見逃している、などのことに気づける
  • 「解決策の実行方法まで考えているか」と問えば、実行容易な解決策を先出しにして効果を上げ、プロジェクトに勢いをつける、などのことができる。これにより、長期にわたるプロジェクトの失速を防げる
  • 「クライアントの思考の癖が問題解決を妨げていないか」と問えば、完璧主義による時間切れなどの問題を防げる
  • 「クライアントの環境が問題解決を妨げていないか」と問えば、組織間の力関係が問題解決を妨げているなどの事象に気づけ、適切な手立てを打てる