問題解決は問題文作成が9割
会議のアジェンダは、「売り上げが悪い。どうするか」です。
営業部長は「営業人数を増やしたい」と言い、マーケティング部長は「広告投資を増やすべきだ」と言う。プロダクト側からは「新機能が必要ではないか」という案も出る。それぞれ、自分の持ち場から解決策を出していく。会議としては、ごく自然です。
ただ、問題解決が得意な人は、この段階ではまだ解決策を考えません。「売り上げが悪い」という事実だけでは、何が起きているのかを十分に理解したとは考えないからです。どの売り上げが悪いのか。いつからなのか。新規なのか既存なのか。商談数なのか、受注率なのか、単価なのか。どこでは起きていて、どこでは起きていないのか。
つまり、問題解決が得意な人とそうでない人では、
「問題が分かった」とみなす基準が違う。
「売り上げが悪い」は、問題解決が苦手な人には問題文に見え、得意な人には問題文を作り始めるための材料に見えます。
問題解決の9割は、解決策を作ることではなく、本質的に解くべき問題文を作ることです。
問題文を作る6つの問い
私が問題を発見・詳細化するときは、だいたい次の6つを繰り返します。
1．いま何を「問題」と呼んでいるのか？
まず、その時点の問題文を一文で書く。「売上が足りない」のように粗くても構いません。
2．何が分かっていて、何が分かっていないのか？
事実と仮説を分けます。両者が混ざると、単なる推測を事実として扱い始めます。
3．曖昧な言葉は何か？
「売上が悪い」「顧客が不満」「開発が遅い」。それは具体的に何を意味するのか。言葉の定義を細かくします。
4．どこで、誰に、どんな条件で起きているのか？
顧客、商品、地域、時期、工程、関係者などで分ける。うまくいっているケースとの違いも見ます。
5．何が分かれば、次の意思決定ができるのか？
分からないことを全部調べる必要はありません。「分かれば判断が変わること」を優先します。
6．どうすれば、それを確かめられるのか？
データを見る、聞く、試す。そこで得た情報を使って、また1の問題文を書き直します。
この6つを、「売り上げが悪い」という話に当てはめてみます。
「売り上げが悪い」は、まだ問題ではない
まず現在の問題文を書きます。
問題文①：売り上げが悪い。
かなり雑です。でも最初はこれでいい。次に数字を確認します。
今四半期の売上は計画比80％。既存顧客はほぼ計画通りですが、新規顧客の売上が不足している。商談数は前年と変わらず、受注率が28％から18％へ落ちている。ここまでは事実です。
一方、「競合が強くなった」「営業の質が落ちた」「価格が高い」は、まだ仮説です。
そこで問題文を書き換えます。
問題文②：新規顧客からの売上が計画を下回っている。商談数は維持されているが、受注率が低下している。
最初より、かなり問題らしくなりました。
「どこで起きているか」を見ると、問題はさらに小さくなる
次に顧客規模、業界、営業担当、流入経路などで分けます。すると、従業員500人未満の企業では受注率はほぼ変わっていない。落ちているのは500人以上の企業でした。
さらに案件を見ると、提案後にセキュリティ審査が始まる案件では、契約期間が長期化していることが分かりました。その結果、顧客の予算期限を越え、翌四半期へずれる案件が多い。
ここで問題文をもう一度変えます。
問題文③：500人以上の新規顧客で受注率が低下している。特に、セキュリティ審査が提案後に始まる案件では契約が長期化し、予算期限を越える案件が多い。
「広告を増やそう」という話は、だいぶ遠くなりました。広告が悪かったわけではない。最初の問題文が広すぎて、広告まで容疑者になっていただけです。
分からないことは、全部調べなくていい
まだ分かっていないことはたくさんあります。競合価格も気になる。ブランド認知も調べたい。営業担当者ごとの差も見たい。
でも、全部調べる必要はありません。いま決めたいのは、大企業向けの営業プロセスを変えるべきか？です。ならば知りたいのは、**セキュリティ審査を早く始めれば、契約期間が短くなるのか？**です。
ここで、調べるべきことが一つに絞られます。
一部の商談で、初期段階からセキュリティ担当者を確認し、必要資料を先に渡してみる。すると、審査そのものにかかる時間はあまり変わらない。しかし開始が早くなった分、契約までの期間は短くなり、予算期限を越える案件も減った。
また問題文を書き直します。
問題文④：500人以上の新規顧客では、セキュリティ審査を提案後に始める営業プロセスによって契約が遅れ、予算期限内に受注できない案件が増えている。初期商談から審査を開始できるプロセスへ変更する必要がある。
最初の「売り上げが悪い」とは、ほとんど別の問題です。
問題文を絞ると、解決策はシンプルになる
問題文④まで来ると、解決策の方向はかなりシンプルになります。初期商談でセキュリティ担当者を確認する。必要資料を先に渡す。大企業向けの営業プロセスを変更する。
最初の「売り上げが悪い」という問題では、営業を増やす、広告を増やす、新機能を作るなど、ほとんど無限に解決策を考えられました。しかし、問題文を詳細にするにつれて、考える必要のある解決策は減っていきます。
解決策を頑張って絞ったのではなく、問題文を絞った結果、考える必要のある解決策が減ったのです。
解決策がシンプルでも、実現が簡単とは限らない
ただし、シンプルな解決策と、簡単に実現できる解決策はまったく違います。 むしろ、本質的な問題まで絞り込むと、実行は難しくなることがあります。
最初の「売り上げが悪い」という問題なら、営業部長は営業人数を増やし、マーケティング部長は広告投資を増やし、プロダクト側は新機能を作る。それぞれ自分の裁量の範囲で、既存の仕事を少し強化すればよい。だから実行しやすい。
一方、「大企業ではセキュリティ審査を始めるタイミングが遅い」という問題を解くには、営業だけでは完結しません。営業プロセスを変える。セキュリティ部門に早い段階から協力してもらう。必要な資料を整備する。場合によっては法務や開発にも動いてもらう。
つまり、何をすべきかはシンプルになっても、それを実現するには組織を動かさなければならない。 ここでは発想力より、他部署を巻き込み、既存のやり方を変え、実行まで前へ進めるリーダーシップが必要になることもあります。
問題文を絞る目的は、仕事を簡単にすることではありません。
解くべき本当の難所がどこにあるのかを、正しく見極めることです。
解けないときは、解決策ではなく問題文を疑う
問題解決が難しいとき、私たちはつい「もっと良い解決策を考えよう」とします。アイデアを増やし、選択肢を並べ、どれが一番よいかを議論する。
でも、本当に足りないのは解決策ではないかもしれません。
そもそも問題文が曖昧すぎる。
だから、解けない問題に出会ったときほど、解決策を増やす前に問題文を作る。
問題を書く → 事実と未知を分ける → 言葉を定義する → 条件を絞る → 判断に必要な未知を選ぶ → 現実で確かめる → 問題文を書き直す。
これを繰り返して、本質的に解くべき問題まで絞っていく。
問題解決は、解決策をたくさん考える仕事ではありません。
考えるべき解決策がシンプルになるところまで、問題文を作る仕事なのです。
あわせて読みたい
リーダーは、決める人ではなく、仕事を前に進める人
本質的な問題が見つかっても、自分一人では解決できないことがあります。必要な情報を集め、人を動かし、意思決定できる状態を作る。問題設定の次に必要になる「前へ進める力」を考えた記事です。
不毛な議論は、「相手が言っていないこと」への反論
問題解決では、問題文を正確に扱うことが重要です。議論でも同じで、条件や因果、比較を少し読み違えるだけで、まったく別の問いに答え始めてしまう。言葉と論理を正確に扱うための記事です。
「結論から話せ」と注意される人は、“結論から”話してはいけない
結論を出す前に必要なのは、「何を聞かれているのか」を特定することです。会議でも、話題が決まっているだけでは問いは決まっていません。「答えより先に問いを決める」という意味で、今回の記事とかなり近い内容です。
意見が合わないのに、なぜこの人とは「話が早い」のか
議論が噛み合わないとき、説明不足ではなく、そもそも違う問いに答えていることがあります。問い、目的、制約、時間軸など、答えを作っている構造まで理解することの重要性を考えた記事です。
