仕事で問題が増えるほど、対策まで増やしていませんか？ゴールドラットの『ザ・チョイス』をもとに、「本来のシンプルさ」の意味と、複数の問題にすぐ対処する前に本当に解くべき課題を見極める問題解決の考え方を、自身の営業経験とともに解説します。
みなさんこんにちは！サラリーマンの大樹です！
仕事をしていると、こんな会議があります。
課題を洗い出す。
優先順位を決める。
担当者を決める。
期限を置く。
「これで前に進める」
そう思って次の会議を迎えると、解決した課題の横に、また新しい課題が並んでいる。
そして、また対策を考える。
もちろん、目の前の問題に対応することは必要です。
でも、もし問題が10個見つかったら、本当に10個すべてを別々に解決しなければならないのでしょうか。
僕自身、以前は問題が一つ出るたびに、
「じゃあ、どうする？」
と解決策を考えるタイプでした。
一つ解決する。
また問題が出る。
また答える。
以前、自分でもこの状態を、
テニスみたいに問題を一個ずつ打ち返している
と表現したことがあります。
目の前にボールが来れば返す。
返せている限り、仕事を前に進めているようにも感じます。
だから、その仕事の進め方そのものを疑うことはありませんでした。
そんな問題解決について考えるきっかけになったのが、エリヤフ・ゴールドラットの『ザ・チョイス』です。
ゴールドラットといえば、『ザ・ゴール』で知られるTOC（制約理論）の生みの親です。
『ザ・チョイス』では、個別の経営手法よりさらに奥にある、
「どう現実を見るのか」
という思考そのものが語られます。
本書の中心にある考え方の一つが、
「ものごとは、本来シンプルである」
というものです。
ただ、この言葉は誤解しやすいと思っています。
「難しく考えず、単純に考えればいい」
という意味ではない。
むしろ逆です。
複雑に見える現実を簡単な説明で片づけず、因果関係を考え抜く。
そして、複数の問題の裏側にある構造を探す。
だから僕は、問題解決について今こう考えています。
解決する前に、何を解決するかを決める。
この記事で伝えたいことは一つです。
問題が増えたときほど、すぐに対策を増やしてはいけない。まず「本当に解くべき問題は何か」を問い直し、問題を生んでいる構造を理解してから解決策を選ぶ。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/2cee0e1c.8d66cd7a.2cee0e1d.ca70dd30/?me_id=1213310&item_id=21841398&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F4062%2F9784478124062_1_2.jpg%3F_ex%3D128x128&s=128x128&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
問題が10個あっても、10個すべてを別々に解く必要はない
営業の仕事だけでも、問題は同時にいくつも起こります。
アポイントが取れない。
商談化しない。
提案しても決まらない。
担当者から返事が来ない。
社内の協力が得られない。
競合に負ける。
こうした問題が並ぶと、自然と一つずつ対策したくなります。
アポが取れないなら、メールを改善する。
商談化しないなら、ヒアリングを改善する。
提案が決まらないなら、資料を改善する。
それぞれの施策が必要なこともあります。
でも、その前に一度だけ考えてみる。
この問題たちは、本当にすべて別々なのでしょうか。
たとえば、
アポが取れない。
商談化しない。
受注しない。
この三つが同時に起きているとします。
表面的には三つの問題です。
しかし、
「そもそも会うべき相手が違う」
という一つ上の問題設定で、複数の現象を説明できる可能性があります。
あるいは、
「顧客の重要課題を捉えられていない」
という共通した構造が影響しているかもしれません。
もちろん、何でも一つの原因にまとめられるという話ではありません。
ここで大切なのは、
見えている問題の数と、解くべき問題の数は必ずしも一致しない
ということです。
問題が10個ある。
だから10個の施策を作る。
この反応をする前に、
「同時に起きている理由はないか」
「共通する構造はないか」
と問い直す。
それだけで、問題の見え方は変わります。
目の前に並んだ症状を、そのまま課題一覧へ変換するのではなく、
症状同士のつながりを見る。
ここが今回の問題解決の出発点です。
問題が起きるたびに対策を足すほど、仕事は複雑になっていく
問題に対してすぐ対策を考えることには、もう一つの危険があります。
対策そのものが、仕事を複雑にすることがある。
何かミスが起きる。
チェック項目を一つ増やす。
報告漏れが起きる。
報告資料を追加する。
意思決定が遅れる。
確認する人を増やす。
問題が起きるたびに、
会議。
資料。
ルール。
承認。
チェック。
が追加されていく。
一つひとつを見ると、どれも合理的です。
問題を再発させないために作られたものだからです。
ところが、それが積み重なると、
確認することが増える。
関係者が増える。
情報を整理する作業が増える。
意思決定に時間がかかる。
そして今度は、
「仕事が遅い」
という新しい問題が生まれる。
そこでまた、
「効率化のための施策」
を追加する。
こうして、
問題を解決するために増やした対策が、新しい複雑さを作っていく
ことがあります。
ここに、問題解決の大きな罠があると思っています。
対策を置くと前進したように見える。
担当者が決まると安心する。
Todoが増えると、何かをしている感覚もある。
でも、
対策が増えたことと、問題が減ったことは別です。
問題の構造を理解しないままルールだけ足していけば、症状は押さえられても、問題を生んでいる仕組みそのものは残ります。
だから問題が多いときほど、
「次に何をやる？」
より先に、
「なぜ、こんなに問題が生まれている？」
を考える。
原因側の構造を考えずに、対策側だけを増やさない。
これが大切です。
「原因が分かった」と思った瞬間に、思考は止まる
営業をしていると、原因らしく聞こえる言葉がたくさん出てきます。
「予算がない」
「競合が安い」
「時期が悪い」
「決裁者が乗り気ではない」
「商品力が弱い」
どれも実際に起こり得ることです。
でも最近の僕は、こういう言葉を聞いたとき、一度止まるようにしています。
それは本当に原因なのか。
たとえば、
「予算がないから失注した」
という説明。
確かに、予算がなければ買えません。
でも、
なぜ予算が取れなかったのか。
顧客にとって優先順位が低かったのか。
期待効果が十分に伝わっていなかったのか。
社内で説明する材料が足りなかったのか。
そもそも提案テーマ自体が重要ではなかったのか。
ここまで考えると、
「予算がない」
という言葉が、原因ではなく結果だった可能性も出てきます。
『ザ・チョイス』には、
「決して、わかったつもりになるな」
という重要な考え方が出てきます。
この言葉は、単なる謙虚さの話ではないと思います。
問題解決において怖いのは、間違った仮説を持つことだけではありません。
仮説を「答え」だと思ってしまい、
その先の因果を探すことをやめること
の方が危ない。
原因らしい言葉が見つかる。
説明できる。
自分も納得できる。
そこで思考を終える。
でも、本当に原因を理解できているなら、その理解から次の行動を変えられるはずです。
同じ結果が繰り返される。
同じような問題が何度も起きる。
それなら、
「説明はできているけれど、理解はできていないのではないか」
と疑う余地があります。
説明できることと、因果を理解していることは違う。
この違いは、仕事をするうえでかなり重要です。
『ザ・チョイス』の「本来のシンプルさ」は、物事を雑に単純化することではない
『ザ・チョイス』を理解するうえで重要なのが、
「本来のシンプルさ」
という考え方です。
シンプルという言葉をそのまま受け取ると、
「難しいことを考えなくていい」
「情報を減らせばいい」
と思ってしまうかもしれません。
でも、ゴールドラットが言うシンプルさは、そうではありません。
複雑な現実をしっかり見る。
そして、
何と何がつながっているのか。
どの現象が、どの原因から生まれているのか。
どこへ手を入れると、大きく状況が変わるのか。
因果関係を探していく。
僕はこれを、
複雑さを消すのではなく、複雑さを生んでいる構造を理解すること
だと捉えています。
木で考えると分かりやすいかもしれません。
一本の木には、葉が何百枚もあります。
枝もたくさんあります。
でも、葉一枚一枚に、それぞれ独立した幹があるわけではありません。
細い枝をたどる。
太い枝につながる。
さらに幹へつながる。
表面では別々に見えていても、下ではつながっています。
仕事の問題も同じです。
売上。
営業。
人員。
会議。
品質。
顧客対応。
一見まったく別の問題でも、同じ前提や同じ制約が影響していることがあります。
ここは『ザ・ゴール』との違いとして考えると面白いです。
『ザ・ゴール』では、
「どこが全体を制約しているのか」
という考え方が大きなテーマになります。
『ザ・チョイス』は、さらにその一段前にある。
なぜ複雑に見える現実にも、理解できる因果関係があると考えるのか。
なぜ最初の説明で諦めず、構造を探し続けるのか。
より根本的な「世界の見方」の話です。
だから、
「シンプルにしよう」
と最初から情報を切り捨てるのは逆だと思います。
情報を見る。
考える。
関係を探る。
仮説を置く。
そして、重要でないものが徐々に落ちていく。
シンプルさは、考える前にあるのではない。考え抜いた先に残る。
図解で伝えたいのは、
問題を無理やり減らすことではなく、問題を生んでいる構造を理解すること。
です。
解決策を考える前に、「何を解くべきなのか」を決める
ここからは、『ザ・チョイス』の考え方を仕事へ持ち込んだときに、重要だと思っていることです。
僕は今、
いきなりSolutionへ飛ばないようにしています。
考える順番は、
Fact
↓
Issue
↓
Why?
↓
Hypothesis
↓
Solution
です。
ただ、この型自体が重要なのではありません。
一番重要なのは、
「まだ自分は問題を正しく理解していないかもしれない」
という状態を残すことです。
たとえば顧客から、
「営業力を強化したい」
と言われたとします。
すぐにSolutionへ行けば、
営業研修。
SFA。
営業DX。
人員増強。
いろいろな施策が考えられます。
でも、そこで一度止まります。
本当に営業力なのか。
アポが足りないのか。
ターゲットが違うのか。
商談化しないのか。
提案が弱いのか。
顧客社内で意思決定が進まないのか。
同じ「営業を強化したい」という言葉でも、解くべきIssueが違えば、Solutionもまったく変わります。
だから、
解決する前に、何を解決するかを決める。
答えを出すスピードより、問題設定の精度を上げる。
解決策を増やす前に、問いを深くする。
それが結果的に、無駄な施策を減らすことにつながります。
左は、
「何をするか？」から始める。
右は、
「何を解くべきか？」から始める。
ここで伝えたいのは、
解決策の質は、問題設定の質を超えない。
ということです。
解いている問題を間違えれば、どれだけ優れた打ち手でも成果にはつながりません。
僕自身、以前は目の前の問題を一つずつ打ち返していた
僕も最初から、こんなふうに考えていたわけではありません。
以前はもっと、
問題 → Solution
に近い考え方をしていました。
何か問題が出る。
「じゃあ、どうする？」
と考える。
一つ答える。
また別の問題が出る。
また答える。
それを繰り返していました。
先ほども書いたように、自分では、
テニスみたいに問題を一個ずつ打ち返していた
と表現しています。
当時は、それが問題解決だと思っていました。
目の前の問題へ答えている。
仕事も進んでいる。
だから、
「そもそも、この問題の置き方は正しいのか？」
まで考える必要性を強く感じていませんでした。
でも、このやり方には限界があります。
自分が問題を処理するスピードは上がるかもしれない。
でも、
問題が生まれる構造そのものは変わっていない。
次の問題が出てきたら、また自分が処理する必要があります。
つまり、
「問題解決が上手くなった」
というより、
「問題処理が速くなった」
だけになることがある。
ここは自分の中でも大きな違いでした。
今は、顧客から課題を聞いても、
最初から答えへ行かない。
なぜそう考えているのか。
本当にそこが一番重要なのか。
別の仮説はないか。
周囲では何が起きているのか。
複数の可能性を残しながら考えるようにしています。
そして最後に、
「では、何を解くべきなのか」
を置く。
今振り返ると、以前の自分は、
考えることより、答えることに意識が向いていた
のだと思います。
問題が来たら返す。
それよりも、
なぜこのボールが何度も飛んでくるのか。
ゲームの構造自体はどうなっているのか。
そちらを見る。
だから今は、
「答えをたくさん知っている人が強い」
とは思っていません。
むしろ、
答えを出す前に、問いを深くできる人の方が強い。
そう考えています。
顧客が口にする「課題」さえ、本当に解くべき課題とは限らない
この考え方は、現在のコンサル営業でもかなり意識しています。
たとえば顧客が、
「営業を強化したい」
と言ったとします。
これは非常に重要な情報です。
顧客自身が、営業に問題を感じている。
だから軽視してはいけません。
でも、
「営業を強化したい」＝本当に解くべきIssue
とは限りません。
なぜ営業強化が必要なのか。
アポ数が足りないのか。
リードが弱いのか。
ターゲットが違うのか。
商談化率なのか。
提案内容なのか。
顧客側の意思決定が止まっているのか。
「営業強化」という言葉の中に、複数の可能性があります。
だから顧客の言葉を否定するのではなく、
仮説の一つとして大切に扱う。
その上で、
「なぜ？」
を掘る。
別の仮説も持つ。
周囲の情報を見る。
本当に解くべき問題を一緒に探していく。
コンサル営業の価値は、ここにもあると思っています。
もし顧客自身が、
課題。
原因。
解決策。
優先順位。
まで全部明確に理解しているなら、外部の人間が入る意味は小さくなります。
実際には、
「何となくこのあたりが問題だと思う」
というところから始まることもあります。
その状態でSolutionだけを持っていけば、
営業側が売りたいものを当てはめるだけになる。
そうではなく、
顧客の言葉を起点にしながら、顧客自身もまだ言語化できていない構造まで考える。
そこまでできて初めて、
「何を売るか」
ではなく、
「何を解くか」
から仕事を始められると思います。
「根本原因は一つ」と決めつけた瞬間、それもまた“分かったつもり”になる
ここまで読んで、
「分かった。根本原因を一つ探せばいいのか」
と思った方もいるかもしれません。
でも、ここでも一度止まりたいです。
「根本原因」という言葉自体が便利すぎる
からです。
一つ原因らしいものが見つかる。
すると、
「全部これのせいだ」
と説明したくなる。
価格。
人。
組織文化。
上司。
競合。
市場。
何か一つ強い言葉を見つけると、そこにすべてを説明させたくなります。
でも、それもまた、
分かったつもり
になる危険があります。
現実の問題には、複数の要因が絡むことがあります。
一つの原因だけでは説明できないこともあります。
だから、シンプルに考えることを、
「一つの答えに素早く絞ること」
だとは思いません。
仮説を置く。
事実と照らす。
反証できないか考える。
別の仮説と比較する。
新しい情報が出たら修正する。
必要なら、問題設定自体をやり直す。
Hypothesis
→ 検証
→ 反証
→ 更新
を繰り返す。
その結果として、
「重要なのはここだ」
と絞れていく。
つまり、
シンプルさはスタート地点ではなく、思考した結果です。
最初から、
「原因はこれ」
と決めることは単純化です。
複雑な現実をしっかり見た上で、
重要な構造が残る。
それがシンプルさだと思っています。
だから、
シンプルに考えることと、単純に決めつけることは正反対です。
『ザ・チョイス』の、
「決して、わかったつもりになるな」
という考え方は、ここでも効いてきます。
「原因が分かった」
と思った瞬間こそ、
もう一度、
本当に？
と問い直す。
この姿勢があるからこそ、シンプルさが雑な断定にならないのだと思います。
問題が増えたら、最初に「この問題たちは本当に別々か？」と聞いてみる
では、明日から何をすればいいのでしょうか。
難しい分析フレームを全部覚える必要はありません。
一つだけ持ち帰るなら、この問いです。
「この問題たちは、本当に別々なのか？」
次に仕事で複数の問題が並んだとき、
すぐに施策を書かない。
まずこの問いを置く。
それだけでいいと思います。
さらに考えたい場合は、次の5つを使えます。
1. 何が事実か？
まず、事実と解釈を分けます。
「営業が弱い」は解釈です。
「商談数が減っている」は事実です。
この二つを混ぜない。
2. なぜ起きているか？
最初に出てきた説明で止めない。
「予算がない」
なら、
なぜ予算が取れなかったのか。
もう一段掘る。
3. この問題たちは本当に別々か？
複数の問題を並べる。
同じタイミングで起きていないか。
同じ顧客層で起きていないか。
同じ工程に集中していないか。
共通点を見る。
4. 他の仮説はないか？
最初の原因へ飛びつかない。
価格かもしれない。
提案かもしれない。
ターゲットかもしれない。
意思決定構造かもしれない。
複数の可能性を残す。
5. 何を変えれば、最も大きく状況が変わるか？
最後にSolutionです。
全部を同時にやる必要はありません。
どこを変えると、複数の問題が同時に改善する可能性があるのか。
そこから手をつける。
全部を完璧にやる必要はありません。
まず一つ。
「この問題たちは、本当に別々なのか？」
と聞く。
それだけでも、
目の前の問題へ反射的に対策を置くことは減ります。
『ザ・チョイス』から僕が学んだのは、問題解決のテクニックを増やすことではありません。
現実を簡単に分かったつもりにならないこと。
そして仕事では、
解決策より先に、問題設定を置くこと。
問題が10個ある。
だから10個の施策を作る。
その前に、一度だけ自分へ聞いてみる。
この問題たちは、本当に別々なのか？
そこから、見える構造が変わるかもしれません。
最後に、この記事で一番伝えたかった言葉をもう一度。
シンプルさは、考える前にあるのではない。考え抜いた先に残る。
コメント