問題解決の基本

問題解決力を高めるために、まずやるべきこととは一体なんでしょうか？

それは何より先に自分たちの「問題解決のやり方」の「問題」を解決することです。「問題解決のやり方」だったらMECEだって、ロジックツリーだってしっかり頭に入っているし、すでに使いこなしているという人もいるかもしれません。

ところが実際のところ、これらの問題解決の手法を学んでその手法通りに問題解決を進めていくのは問題に対していきなり改善策を適用するようなものなのです。

それも、外来の標準的な改善策です。
そもそもここから間違っているのです。

問題解決の基本は、原因に対する対策・改善です。

したがって自分たちの「問題解決のやり方」の問題の原因を分析することなく、いきなり改善策を適用するという…そのやり方が正しい問題解決のわけがありません。

これは、あるプロジェクトでトラブルが発生した場合にその解決のために社内外に関係なく、何十と飛び回って奔走した経験からも同様のことが言えます。

トラブルの現場に着いて最初にすべきこと。

それは

　現状の把握
　経緯の確認
　現在求められている要求

の完全整理でした。

逆にこの３点の情報が正しく提供できないトラブルではいくら一時”火消しのプロ”と呼ばれていた私でも望む形で解決することは非常に困難となります。

まず、自分たちの問題解決のやり方をふり返ってみましょう。

　「なぜ問題解決ができないのか」
　「なぜ問題解決に時間がかかるのか｣

みなさんが抱える「問題解決のやり方」の問題は様々ですがほとんどの場合、大きくはこの２つに集約されます。そしてそれぞれに誰もがはまってしまう落とし穴が潜んでいます。

最初に「なぜ問題解決ができないのか」についてその原因と落とし穴について考えてみましょう。問題解決ができない理由は３つあります。

1つめは「問題がわからない」
2つめが「原因がわかっていない」
最後が「改善案が立案できない」

です。

問題がわからない

問題解決するのに問題自体がわからなければそもそも何を解決するかわかりませんね。そう聞くと誰だって「そんなことありえない……」と思うでしょう。ところが、これが実際にはよくあることなのです。

では、なぜそんなことになるのでしょう。

その理由はいくつかありますが代表的なものは、

　「ただの不安を問題だと思ってしまう」
　「問題が大きすぎる、複雑すぎる」

の２つです。

「不安を問題だと思ってしまう」とはどんな状況を指すのでしょうか。たとえば、"年間で売上20%アップ"という目標に向かって取り組んでいるとします。20％アップに向けた様々な施策に取り組んでいきますが、施策を打ったからといってすぐに売上がアップするというものではありません。特に抜本的改革の施策や長期的戦略施策などは、結果が出るのに時間がかかります。

すぐに結果が出てこないと人は焦ってきます。

「施策が間違っていたのではないか」と不安に駆られ、その不安から我慢が出来なくなって次第に「この施策が問題だ」と決めつけるようになります。

まだ結果が出ていない段階で「ダメだった」ことをはっきり示す事実もない中でその施策が問題だからと改善しようとします。ところが肝心の結果が出ていないのでそもそも何が問題なのか、どこが問題なのかがわかりません。

改善とは、結果に対して『改めて』『善くする』から改善であって、如何なるものであっても１度は結果を出した後でなければ改善できないということを意外にも知らない人が多いのです。

このように「不安を問題だと思ってしまう」原因は、

　過程の状況が見えていない
　評価基準を定めていない

ことにあります。

結果に至る過程で現在どの段階にあるか、その過程において達成すべき途中段階の目標をクリアできているのかが見えていれば、不安に陥ることもありません。もし途中段階の目標がクリアできていなければそれを問題として早い段階から手を打つこともできます。

このように「問題がわからない」という落とし穴は、結果までの過程が見えないことによる焦りと不安が知らぬ間に「問題」にすり替わっているところにあります。

一方で、問題が大きすぎたり複雑すぎたりすると問題の影響が様々な形で表れ、問題がたくさん発生しているように見えます。すると本質的な問題がわからなくなりいたちごっこのような問題解決が始まってしまいます。

問題が大きすぎたり複雑すぎたりするときは問題を切り分けて、一次問題なのか一次問題に引き起こされた二次問題なのかを整理することが必要です。

一次問題は、二次問題の原因です。
一次問題を解決すれば二次問題は発生しません。

この切り分けをしないまま問題の原因分析をすると一次問題と二次問題の両方の原因が洗い出されてきてしまい、解決すべき原因が多すぎて手に負えなくなります。

「問題が大きすぎたり、複雑すぎる」という落とし穴は、このように対策する必要のない問題（二次問題）と本質の問題（一次問題）を区別せずすべて解決しようとするところに潜んでいます。

原因がわからない

原因究明には特性要因図やロジックツリー、なぜなぜ分析などすでにいろいろな手法が開発され紹介されています。

しかし、それらを使っても原因が特定できないことがあります。
そこには隠れた原因が潜んでいるのです。

それは、「机上論」です。

紹介されている手法はすべて思考の仕方を扱ったものです。どのように頭の中を整理し、どのように推論していけばよいかを導き出す手法です。もちろんこれらの手法は大変素晴らしいもので正しい使い方をすれば原因をしっかりと特定することができるものばかりです。

しかし、間違った使い方をすれば原因を究明できないどころか問題解決の取り組みを混乱させ、ムダなことに時間を費やさせ、問題解決力を低下させる怖さすらあります。

その間違った使い方とは、すべてを机上で自分たちの知識と経験の延長線で行うことです。

これらの手法は推論を助けるものですが、推論は必ず検証とセットで扱わなければなりません。検証結果をインプットして推論をさらに高めるのが、これらの手法の正しい使い方です。検証することで自分たちの知識と経験にはない事実に触れることができます。

これらの手法は、本来自分たちの知識と経験ではたちうちできない問題と原因を紐解くためのサポートをしてくれるツールなのです。机上だけで推論していても、自分たちの知識と経験の外にある原因にはたどり着けません。

ところが残念なことに深刻な問題の多くは未知のもので、自分たちの知識と経験の外側にあることが多いのです。「原因を特定できない」という落とし穴は知らぬ間にこの知識と経験の"狭い世界"で原因分析をしているところにあります。

改善案が立案できない

改善案の立案を阻むものは何でしょう。

多くの場合、それは「技術の壁」と「経済性の壁」です。原因が特定できても自分たちの技術では解決できない、または立案された改善案が技術的に実現不可能というのが｢技術の壁」です。一方、改善案に金がかかりすぎるのが「経済性の壁」です（時間が不足しているというのも、結局は金銭的な問題に行きつきます）。

技術の壁はどうにもならない────。
果たして、そうでしょうか。

原因分析は、何らかの前提条件を課していることが多くあります。

たとえば「パンケーキを焼くと焦げる」という問題点について考えてみましょう。

パンケーキはガスレンジや電磁調理器で生地に熱を加えて焼き上げます。焦げる原因は「パンケーキ内部が焼き上がる前に表面に加えられる熱が多すぎる」点にあります。

改善策は、パンケーキ内部への熱伝導と加える熱のバランスをとる技術的な内容になります。ガスレンジや電磁調理器は表面層から内部に熱を伝達させて焼くという機器です。つまり

　「表面層から内部に熱を伝達させる方法で行う」

という前提条件が付けられています。

では、この前提条件を外したらどうなるでしょう。
たとえば、内部に直接熱を加える方法を考えてみます。

電子レンジを使うのです。

電子レンジでパンケーキ内部に直接熱を加えて生地を焼き、表面はガスレンジで焼きます。この場合、表面は焼くというより焼き目をつけるだけかもしれません。熱伝導と加える熱のバランスをとる技術的改善は不要となりました。

「技術の壁」は確かにあります。
ＩＴの場合、高度なものはやはり開発の領域の話となるでしょう。

しかし前提条件を見直せば、技術開発せずとも既存の技術で解決できることはたくさんあります。ということは、実際のところほとんどは「技術の壁」ではなく「前提条件の呪縛」が本当の原因と言えます。

「経済性の壁」も「技術の壁」と同じです。

その本当の原因は「前提条件の呪縛」です。前提条件に縛られて手間とお金のかかる改善策しか選択できないのです。この呪縛を解けば選択肢は広がり、経済的に優位な改善案を立案できるようになります。

たとえば顧客のシステム監視をインターネットを通じて24時間行うという改善策が立案されたとき、24時間勤務によって25％の深夜手当が必要となり、人件費が高くなって実現できないというケースがあります。

ここでの呪縛は「日本で行う」というものです。

日本が深夜であったとしても、地球の反対側のアメリカやブラジルは昼間です。つまり日本が深夜のときは昼間のブラジルで監視してもらえばいいのです。

幸い、監視はインターネットを通じてできますし、システム監視ですから言語の違いの問題もありません。地球の反対側が日中ですから深夜手当はかかりませんし、物価の違いなどから日本より人件費が安く済みます。

改善案が立案できない落とし穴は知らぬ間に前提条件に縛られて思考が固くなっており、改善案立案に柔軟性がなく、選択肢が狭められているところにあります。

問題解決に時間がかかる原因と落とし穴

「なぜ問題解決に時間がかかるのか」について、その原因と落とし穴について考えてみましょう。問題解決に時間がかかる理由は２つあります。

１つは「分析・立案に時間がかかる｣
もう１つは解決に寄与しない「ムダな時間が多い」

です。
　
分析や立案に時間がかかるのは前述の「原因が特定できない落とし穴」によるところも多分にありますが、それ以上に「やり直しは悪」という考え方が根底にあるものです。

　「失敗したくない」
　「一発で決めたい」

という思いや「やり直しはムダ」という考え方が綿密に分析し、間違いない対策案・改善案を立案しようとする行動につながっていきます。

しかし実際は、失敗の連続です。
人間で凡そ失敗しない者などいません。

にも拘らず、失敗は分析力・立案力のなさが原因と考えて、さらに分析や立案に時間をかけるようになるという悪循環に陥っていきます。

果たしてやり直しは本当に悪なのでしょうか？

自分たちの知識や経験の外にある問題は、どんなに知識と経験を出動させて分析・立案しても的を射た原因や改善案を見出すことは困難です。ですから自分たちの知識や経験の外にある問題を理解し、必要な知識や経験を手に入れるには、やってみて、失敗から学ぶという方法が一番の問題解決の近道だったりします。

最近ではやっとＰｏＣ（Proof of Concept：概念実証）と言った言葉も市民権を得て、「やってみて、検証する」ことが比較的当たり前のように受け入れられる人も増えてきたように思われます。

やってみれば経験を得ることができ、今まで気づかなかったものを見つけ、
存在すら知らなかったものを知ることができるようになります。失敗したとしても自分たちに足りない知識、正しく理解できていなかったものが何であるか明らかになります。その知識は学べばいいのです。

実は問題解決では経験と失敗からの学びこそが解決力を高める１番有効な手段です。分析・立案に時間がかかる落とし穴は、経験と失敗からの学びの手段である「やり直し」を悪と決めつけて一番の近道を避けていたことにあります。

では、失敗しながら進む際に、計画は不要なのか？と言うとそれは違います。失敗することも念頭に入れて、スケジュールが逼迫しないよう、

　「試作、試走」と「本開発」

を切り分けて計画を立てられればいいのです。しかし、それすらも「無理」「難しい」と言う人が後を絶たないことでしょう。ここでは別にすべてを作り切る試作や試走など必要ありません。

たとえば新しい設計書様式で設計しなければならないとして、対象が１０機能あったとします。はたして１０機能全てに対して失敗しなければならないのでしょうか？

答えはＮＯです。

１機能だけ試作して、そこから学んだ失敗や課題を次以降の９機能に活かし、成功を収めれば結果的に全体は成功となるはずです。

要するにここでも、「前提条件の呪縛」が原因の本質で、勝手に実施する条件を自分の中で固定化してしまっていることが問題となるのです。

ムダな時間が多い

問題解決につながらないムダな時間が多いのは分析・立案に時間がかかっていることにも一因がありますが、問題の特性を無視した画一的な問題解決アプローチが原因のケースも多くあります。

たとえば、

　「以前はこれで成功したので」
　「お客がこうしろと言ったので」

と言った他責思考により、プロジェクトごとの固有の特性を無視してしまうケースです。一口に問題と言っても、様々な特性を持ったものがあります。問題解決で扱うものの中には「課題」と呼ぶべきものもたくさんあります。

ここで確認の意味も込めて整理しておくと、

　「問題」と「課題」は異なるもの

ということです。同じ扱いにできはしますが、定義としては別物になります。したがってそもそもこの特性が異なる２つを同じ問題解決プロセスや
手順、手法を用いて解決しようとすること自体に無理が生じることがあります。

たとえば、カタログと電話による通信販売を行っていた会社に新たにインターネットのサイト上に商品を掲載して、サイトから注文を受けて販売する計画があるとします。

このとき「サイトへ顧客を誘導することができない」という問題が出てきたとします。

ではこの問題について、原因を分析して改善策を立案する問題解決アプローチを適用して解決することはできるのでしょうか。

顧客を誘導できない原因を特性要因図やロジックツリーで整理・分析すれば、何らかの原因を挙げて対策することはできますが、果たしてそれでムダなく効率的に解決できるのでしょうか。

この事例のように、初めてインターネットに取り組むとき「サイトへ顧客を誘導することができない」のは問題というより『課題』です。

「問題」とは、今までできていたことができなくなったり、正常だったものが何か不具合を起こし正常ではなくなることです。別名「不良」や「故障」とも言います。つまり、実績や事実があるものにおける不具合が「問題」です。

「課題」は、まだ実績も事実もないものを実現するために解決しなければならない事柄です。めざすものに対して足りないもの、合っていないものが「課題」です。

課題解決で重要なのはめざすものを明確にして共有することです。事例にある誘導する顧客はカタログをすでに配布している既存顧客なのか、今まで取引のなかった新規顧客なのか、どちらをターケットにするかでやるべきことはまったく異なります。

このように課題を解決するアプローチでは、原因分析の前にめざすものを明らかにして、それを実現するための課題の定義が一番重要なステップとなります。

課題が定義されれば、その後の原因分析は原因ごとの施策のリストアップに近いものとなり、一部の厄介なケースを除いてほとんどの原因の分析には特性要因図やロジックツリーなどの手法は必要ありません。

めさずものを明確にしないまま「サイトへ顧客を誘導することができない」という「問題」の原因を分析すると、カタログをすでに配布している既存顧客が誘導できない原因、今まで取引のなかった新規顧客の原因の両方について洗い出し・分析することになります。

めざすものを「既存顧客の誘導」とすれば、新規顧客の誘導について考える必要はありません。新規顧客の誘導について考える時間がムダな時間です。

問題解決に寄与しない「ムダな時間が多い落とし穴」は、問題特性を無視した画一的な問題解決アプローチを採用しているところにあります。