【コンサル的思考入門② 】「仮説を立てる」とは、どういうことなのか？

前回の「コンサル的思考入門①」では、
「結論から話す」というコンサルの基本的な伝え方について書きました。

では、その「結論」はどうやって考えるのでしょうか

そこで出てくるのが、
仮説
という考え方です。

コンサルの本を読んでいると、
「まず仮説を立てましょう」
「仮説思考が重要です」
という言葉がよく出てきます

でも、初めて聞くと少し分かりにくい
「仮説って、要するに予想すること？」
「まだ調べていないのに答えを決めていいの？」
「単なる思いつきと何が違うの？」
仮説という言葉だけを聞くと、少し難しいものに感じます

しかし実際の仕事に置き換えると、
それほど特別なことではありません。

仮説とは、
「まだ答えは分からない。でも、今ある情報から考えると、たぶんこうではないか？」
と、いったん仮の答えを置くことです。

そして重要なのは、その答えを信じ込むことではありません
仮の答えを置き、それが正しいかを調べる

今回は「コンサル的思考入門②」として、この「仮説を立てる」という考え方を、製造業の例も交えながら考えてみます。

⸻

そもそも、なぜ仮説を立てるのか？

例えば、ある工場でこんな問題が起きたとします
「最近、設備停止が増えている」
原因を調べてください、と言われました。

さて、何から調べるでしょうか。

設備の故障履歴、保全履歴、部品交換履歴、PLCのデータ、アラーム履歴、作業日報、生産量、設備の稼働時間、作業者へのヒアリング……。

調べようと思えば、いくらでも調べられます
しかし、全部調べていたら時間がかかります。

そこで、まず考える。

例えば、
「最近、生産量が増えて設備の連続稼働時間が長くなり、消耗部品の交換サイクルが追いついていないのでは？」
と考えてみる。

これが仮説です。

すると、見るべきデータが変わります

生産量は増えているのか
設備の稼働時間は伸びているのか
どの部品の故障が増えているのか
交換周期は変わっていないのか

つまり仮説があることで、
「何を調べればいいのか」
が見えてくるわけです。

⸻

仮説がないと「とりあえず全部調べる」になる

仮説を立てずに調査を始めると、ありがちなのが、
「とりあえずデータを集めましょう」
です。

Excelを集める
ログを集める
担当者にヒアリングする
グラフを作る
会議資料を読む
大量の情報が集まります

でも途中で、
「ところで、何を調べていたんだっけ？」
となる。

これはDX案件でも起こりやすいと思います。

「工場のDXを進めたい」
と言われて、
とりあえずIoT
とりあえずデータ収集
とりあえずAI

でも本来は、
何が問題なのか？
そして、
なぜ、その問題が起きていると考えるのか？
が先です。

仮説は、闇雲に情報を集めるのではなく、調査の方向を決めるためのものなのです。
⸻

仮説は「正解を当てるゲーム」ではない

ここは非常に重要です。

仮説というと、
「最初から正しい答えを考えなければならない」
と思うかもしれません。

違います

仮説は外れてもいい
むしろ調べる前なのですから、外れることは当然あります。

先ほどの設備停止について、
「連続稼働による消耗部品の劣化では？」
と仮説を立てた
ところが調べてみると、生産量も稼働時間もほとんど変わっていなかった。

だったら、
「この仮説は違いそうだ」
と捨てればいい

次に、
「特定メーカーの交換部品に変えてから故障が増えているのでは？」
と考える

調べる

これも違った。
では、
「設備の老朽化では？」
「保全周期に問題があるのでは？」
「作業条件が変わったのでは？」
と次の仮説へ進む。

つまり、
仮説 → 検証 → 修正 → 再検証
を繰り返します。

仮説を立てる目的は、最初から正解することではありません
正解へ近づくスピードを上げることです。

⸻

「仮説」と「思いつき」は何が違うのか？

ここは、かなり重要だと思います。

例えば設備が止まったとき、
「たぶんモーターが悪いんじゃない？」
これだけなら、単なる思いつきかもしれません。

一方、

「過去3回とも高負荷運転のあとにモーター温度上昇のアラームが出ている。今回も同じ現象ではないか？」

となると、仮説らしくなってきます。

違いは、
「なぜそう考えたのか？」
があることです。
仮説には、何らかの根拠があります。

過去の経験
既に分かっているデータ
現場で聞いた話
業界知識
似た案件
設備の構造

もちろん、その根拠自体が間違っている可能性もあります。

それでも、
「Aという事実がある。だからBではないか？」
という筋道がある。

これが仮説です。
⸻

データが完全につながっていたら、それはもう仮説ではない

例えば調査した結果、
「設備停止の90％が部品Aの破損によって発生している」

さらに、

「部品Aが破損する原因も特定されている」
ところまで分かったとします。

ここで、
「設備停止の原因は部品Aではないか？」
と言っても、もはや仮説を立てる段階ではありません。

すでに答えがかなり見えているからです。

仮説が必要になるのは、
関係がありそうだが、まだ本当に原因なのか分からないときです。

例えば、
「生産量が増えた時期と設備停止が増えた時期が重なっている」
これはデータから確認できる事実かもしれません。

しかし、

生産量が増えたから設備停止が増えた
とは、まだ言えません
たまたま同じ時期だった可能性もあります。

そこで、
「生産量増加による設備負荷の上昇が、停止増加の原因ではないか？」
という仮説を立てる意味が出てきます。
⸻

「相関がある」と「原因である」は違う

仮説を考えるうえで、ここは大きな落とし穴です。

例えば、
夏になると工場の設備故障が増える。
同じ時期に、工場の電力使用量も増える。

すると、

「電力使用量が増えたから設備が故障しているのでは？」
と考えたくなります。

でも、本当の原因は気温上昇による設備内部の温度上昇かもしれない
あるいは夏場の増産によって稼働時間が伸びたことかもしれません

つまり、

一緒に動いているデータが見つかったことと、原因が分かったことは別です。

だから仮説を立てたら、
「本当にそうなのか？」
「別の説明はできないか？」
と検証する必要があります。
⸻

良い仮説は「反証できる」

例えば、
「この工場には何か問題があるのではないか」
これは仮説として弱い
何を調べればいいのか分からないからです。

一方、

「設備停止が増えた原因は、部品Bの交換周期が実際の稼働時間に対して長すぎるからではないか」

なら調べられます。

部品Bの交換履歴を見る
設備の稼働時間を見る
故障した設備と故障していない設備を比較する
そして、交換時期が近づくほど故障が増えているのかを確認する

もし、交換直前に故障が集中しておらず、交換後、間もない部品でも同じように故障しているのであれば、
「交換周期が長すぎることが原因」という仮説は弱くなります。

だったら、その仮説を捨てるか修正して、別の原因を考えればいい。

つまり良い仮説とは、正しさだけでなく、誤りも確認できるものです。

検証した結果、
「この仮説では説明できない」
と分かることにも価値があります。

一つ可能性を消せたことで、次に調べるべき方向が絞られるからです。
⸻

仮説を立てるには「現場を知ること」も重要

では、どうすれば良い仮説を立てられるのでしょうか

ここで、知識や経験が効いてくると思います

同じ、
「設備停止が増えた」
という情報を聞いても、設備を知らない人なら、
「AIで予測できませんか？」
となるかもしれません

でも設備保全を知っている人なら、
「どんな故障モードですか？」
「TBM（時間基準保全）で定期交換しているのか、CBM（状態基準保全）なのか？」
「部品の交換履歴はありますか？」
「同じ部品ばかり壊れていませんか？」
「PLCやCNCに異常発生前のデータは残っていませんか？」
と考えるかもしれません。

持っている知識によって、立てられる仮説が変わります。

だからコンサルに必要なのは、ロジカルシンキングだけではありません。

業界知識、現場知識、経験が、仮説の質を大きく左右する。

これは製造業DXでは特に大きいと思います。
⸻

生成AIは仮説を立てるのが得意なのか？

ここは今の時代なら避けて通れません。
生成AIに、
「設備停止が増えています。原因の仮説を出してください」
と聞けば、

老朽化、部品劣化、潤滑不良、温度上昇、振動異常、作業ミス、保全周期、負荷増大……。

かなりの数の仮説候補を出してくれるでしょう

これは便利です。

人間が思いつかなかった可能性を広げる用途にも使えます。

ただし、問題があります。

AIは、その工場を見ていません
どんな設備なのか
最近、生産条件を変更したのか
過去にどんな故障があったのか
異常が起きる前にどんな音や振動があったのか
現場の担当者が何となく感じている違和感

そうした情報をAIに渡していなければ、当然知りません。

だからAIは、
「仮説候補を広げる」
ことには強い。

しかし、

「この現場では、どの仮説から検証すべきか」
を決めるには、現場情報が必要です。

AI時代になっても、仮説を立てる人間の仕事がなくなるわけではないと思います。

むしろ、

AIが大量に出した仮説から、検証する価値のあるものを選ぶ力
が重要になるのかもしれません。
⸻

仮説は「当てるため」ではなく「捨てるため」にもある

仮説思考で意外と難しいのは、自分の仮説を捨てることです。

一度、
「原因はこれだ」
と思ってしまうと、それを裏付ける情報ばかり探してしまいます。

「やっぱり自分の考えは正しかった」
と思える情報だけが目につく

逆に、自分の仮説に都合の悪いデータを軽く見てしまうこともあります。

だからこそ、

「この仮説が間違っているとしたら、どんなデータが出るはずか？」
も考えておく

調べてみて違うと分かったなら、捨てる。

むしろ、

一つ原因候補を消せた
と考えた方がいい

仮説とは、自分の正しさを証明するためのものではありません。

問題の正体を絞り込むための道具です。
⸻

コンサルの仮説思考をシンプルにすると

難しいフレームワークを覚える前に、まずはこの流れだけでも十分だと思います。

① 何が起きている？
設備停止が増えている。
↓
② なぜだと思う？
稼働時間の増加で部品劣化が早まったのでは？
↓
③ なぜそう思う？
増産開始後から停止件数が増えている。
↓
④ 何を見れば確かめられる？
稼働時間、故障履歴、部品交換履歴を見る。
↓
⑤ 何が出たら「違う」と判断する？
稼働時間と故障発生に関係が見られない。
↓
⑥ 違っていたら？
仮説を修正するか捨てて、次の原因候補を検証する。

この⑤を最初から考えておくことが、実は重要です。

「自分の仮説を証明するデータ」だけを探すのではなく、
「自分の仮説を否定するデータは何か？」
も考える。

これだけでも、仮説の検証はかなり変わります。
⸻

明日から使える「仮説」の一言

何か問題を調べるよう頼まれたとき、いきなりExcelを開かない。
いきなり検索しない。
いきなりAIに聞かない。

まず紙でもメモでもいいので、
「私は今のところ、○○が原因ではないかと考えている。なぜなら△△だから」
と1行書いてみる。

そして、もう2行追加する
「それを確かめるには、何を見ればいい？」
「逆に、何が出たらこの仮説は間違いだと言える？」
この3つです。

仮の答え
↓
検証方法
↓
反証条件

ここまで書けば、「なんとなくそう思う」という思いつきから、一歩進んだ仮説になります。

仮説とは、未来を当てる特殊能力ではありません。

限られた情報から仮の答えを置き、必要な情報を集め、検証し、違っていれば修正する

その繰り返しです。

第1回の「結論から話す」が伝え方の基本だとすれば、今回の「仮説を立てる」は考え方の基本です。

そして次に問題になるのが、
「そもそも、何について仮説を立てればいいのか？」
です。

「設備が止まる」
「在庫が多い」
「納期が遅れる」
「DXが進まない」

目の前に見えている現象が、本当に解くべき課題とは限りません。

次回の「コンサル的思考入門③」では、「課題を分解する」とはどういうことなのか？を考えてみたいと思います。