問題解決プロセスの全体像を示した前回に引き続き、第2回となる今回は、その第1歩となる、「何が問題かを明確にする（＝What）」ステップについて詳説する。
例えば「部門間のコミュニケーションが悪い」という悩みは、どの組織にもあるのではないだろうか。しかし多くの場合、「それは、あまり良いことではない」と認識されつつも、解決に向けたアクションには至らない。仮にマネジメントが動いたとしても大概は、「部門を横断するタスクフォースを作る」「機能別の組織に横串を通す役割（例えばプロダクトマネージャなど）を設置する」といった、通りいっぺんの解決策を採るにすぎず、「そもそもタスクフォースが何を検討するものかが明白でなく、部門間の言い合いに終始する」「各部門の調整が難しく、部門の横串を通すはずの人間がただ疲へいする」など、無為に終わるケースが散見される。
なぜこうしたことが起きるのだろう。私の経験から言えばその大半は、「そもそも問題自体が明確になっていない」ことから生じている。例えば「部門間のコミュニケーションが悪い」というのは、どういった問題なのだろうか。どのような状態であれば、それが解決したと言えるのか。具体的な「問題」であれば「解決」も可能だが、「何となく悩んでいる」というレベルでは、何をどのように考え、解決に向けたアクションを取るべきかが、はっきりとしない。
さらに状況を悪くするのが、「部門間のコミュニケーションが悪い」といった形で表現される問題は、誰もが同意しやすいという点だ。コミュニケーションに全くストレスを感じないという人は稀であるため、「コミュニケーションに問題はないですか？」と問われれば、「そう言われてみれば、何となくストレスを感じている」などと安易に同意してしまう。だが、「では問題の本質は何か？」と問われると、誰も正確には答えられない。そのような段階で、いきなり解決策だけを考え始めれば、「総論は全員賛成、しかし各論になると議論百出」となるのは当たり前のこととも言える。
前回、「What→Where→Why→How」という問題解決プロセスの中で肝となるのは、前半の「What」「Where」、即ち「何が問題か」「どこが問題か」を特定するステップであり、この部分を経験的、直感的に「なんとなくここが問題・原因だ」と決め打ちすると、有効な解決策は講じられないと述べたが、上記の議論はまさにその典型例と言える。
理想状態と現状の差分から具体的な問題点を抽出する
では、どのようにすれば「漠然とした悩み」は「考えられる問題」となるのか。
例えば、「営業部門と開発部門のコミュニケーションが悪く、結果として顧客ニーズに合った商品をタイムリーに提供できていない」という状況があるとしよう。ここで、「営業部門と開発部門の情報共有が不十分であることが問題だ」では、まだ具体的ではない。
誰が実際に困っていて、誰は困っていないのか。困っている人は何についてどのくらい困っているのかを具体的に考えてみよう。情報が不足して困っているのは開発部門なのか、営業部門なのか。仮に開発部門が困っているとして、それは現場の技術者か、あるいは全体を統括するマネージャか。情報が足りないのは商品企画の段階か、あるいは発売直前の段階か。
この企業がもし、顧客ニーズの変化を即座に捉えて商品の仕様に反映させるスピードを求められているならば、「営業部門から開発部門に顧客動向がスピーディーに伝えられていない」ことが問題になる。逆に、この企業が先進的な商品を開発しているにも関わらず、用途開発が不十分であり、いかにして商品の魅力を潜在顧客に伝えていくかが課題であるとすれば、「開発部門から営業部門に商品特性を顧客に分かりやすく伝えるための情報が適切な形で伝えられていない」ことが問題となる。
ここまで整理してようやく、この2つが全く別の問題であり、従って「何を解決すべきか」「どのように解決すべきか」も変わってくることが、明白に理解できるだろう。
問題を明確にするために、すべきことは大きく2つある。1つは、「どのような状態になれば良いのか」という理想の状態を、具体的に定義することだ。理想状態は「あるべき姿」「ありたい姿」「ビジョン」「目的」など色々な形で表現されるが、言葉は何でも構わない。要するに、どうなると嬉しいのか、不満がなくなるかを、定義する。
2つ目は、その理想状態から見て「現状がどうなっているか」を、なるべく具体的にチェックすること。これによって、理想と現実で特にギャップのあるのがどの部分であるのかが、絞り込まれていく。その絞り込んだ先こそが、「問題」の本質である。
具体的に検討することで問題を組織全体のものとして共有する
ここでポイントとなるのが、再三、用いている「具体的に」というキーワードだ。ものごとを具体化するのは頭で考えているよりも、難しい。どのようにしてよいか迷ったら、まずは「5W1H」に要素分解して考えてみよう。また、数値化できる部分はなるべく数値化して定量することも有効だ。
「誰が」「何について」「どのくらい」困っているのか。例えばコミュニケーションの問題では、情報の送り手側は全く困っていないが受け手側は非常に困っている、ということが多く見られる。また、困っている内容を具体化していくと、それはスピードやタイミングの問題であったり、情報の精度であったり、あるいは量であったりと、「問題であると感じているが実は問題ではないこと」が精査され、「本当に問題なのは何か」が、よりクリアに浮かび上がってくる。
問題を具体化することは、それによって確実に有効な打ち手を考え出せるという以外に、「組織内での議論を進めやすくする」というメリットもある。こう書けば、組織内で何か新しいことをはじめたり、変革を起こそうと腐心してきた方であれば、ピンと来るだろう。
ある提案を行う場合、「それは、本当に重要な問題なのか」という点で組織内の認識をすり合わせることは、極めて難しい。それが問題なのか否かという、出発点以前のところで議論が紛糾してしまうと、話はまるで前に進まなくなる。また仮に前に進んだとしても、部下や関係者に「なぜそれをやるべきなのか」を腹に落ちるまで納得してもらい、「それは自分が解決すべき問題だ」と当事者意識を持ってもらわなければ、組織全体としての実行力は導き出せない。目的意識がズレれば、不測の事態での対応を誤り、的外れな方向に進んでしまうことにもなりかねない。
つまり、問題を具体的にする（できれば定量化する）ことで、組織に関わる全ての人の間で意識をすり合わせ、同じ方向に進みやすくすることが可能となるのである。
次回はこれを踏まえ、問題の本質がどこにあるか（Where）を特定する方法論について検討していく。
