【コンサル的思考入門③】「課題を分解する」とは、どういうことなのか？

前回の「コンサル的思考入門②」では、「仮説を立てる」という考え方について書きました。

仮説とは、
「まだ答えは分からない。でも、今ある情報から考えると、たぶんこうではないか？」
と仮の答えを置き、データや事実で検証していくことでした。

では、その仮説は何について立てればいいのでしょうか。

例えば、お客様から、
「在庫が多くて困っています」
と言われたとします。

そこで、
「ではAIで需要予測しましょう」
「在庫管理システムを導入しましょう」
と、すぐに解決策を考えていいのでしょうか。

まだ早い。
なぜなら、
「在庫が多い」だけでは、どこに問題があるのか分からないからです。

原材料が多いのか
仕掛品が多いのか
完成品が多いのか
保全部品が多いのか
さらに、なぜ多いのか
需要予測が外れているのか
発注ロットが大きいのか
欠品を恐れて安全在庫を多く持っているのか
販売計画と生産計画がうまく連携していないのか

同じ「在庫が多い」という現象でも、原因によって打ち手はまったく違います。

だから、いきなり解決策を考えない。

まず、
「大きく曖昧な問題を、調べられる問いに変えていく。」

これが「課題を分解する」という考え方です。

■ 課題分解とは「細かくすること」ではない

「課題を分解する」と聞くと、
「とにかく細かく分ければいい」
と思ってしまいます。

でも、そうではありません。

例えば、
「売上が下がっている」
という問題があったとします。

原因を考えたいのであれば、例えば、
売上 ＝ 顧客数 × 顧客単価
と分けられます。

さらに、
【顧客数】
→ 新規顧客が減った？
→ 既存顧客が減った？
【顧客単価】
→ 購入点数が減った？
→ 商品単価が下がった？
と分けてみる。

すると、
「売上が下がった」
という漠然とした問題が、
「新規顧客が減ったのか？」
「既存顧客が離れているのか？」
「一人あたりの購入点数が減ったのか？」
という、調べられる問いに変わります。

つまり課題分解とは、
「問題を小さくすることではなく、答えられる問いに変えること」
なのです。

■ これが「ロジックツリー」の基本

コンサルの本を読むと、
「ロジックツリー」
という言葉がよく出てきます
名前だけ聞くと難しそうですが、基本的な考え方はシンプルです。

先ほどの売上なら、
売上が減っている
↓
顧客数が減った？
・新規顧客が減った？
・既存顧客が減った？
顧客単価が下がった？
・購入点数が減った？
・商品単価が下がった？
というように、大きな問題を枝分かれさせていきます。

大切なのは、きれいな図を作ることではありません。
「どこを調べれば、原因に近づけるのか？」
を見えるようにすることです。

■ 「なぜ？」だけで掘ると危ないこともある

問題解決というと、
「なぜ？を繰り返しましょう」
という話があります
いわゆる「なぜなぜ分析」です
もちろん有効です。

例えば、
納期が遅れている
↓
なぜ？
↓
生産が遅れている
↓
なぜ？
↓
設備が止まる
と掘っていく。

一見すると、原因に近づいているように見えます。

でも、ここには注意が必要です。

本当に納期遅延の原因は、生産だけなのでしょうか
部品の入荷が遅れているかもしれない
検査工程がボトルネックかもしれない
出荷作業に時間がかかっているかもしれない
最初から「生産が原因だ」と決めて縦に掘ってしまうと、別の原因候補を見落とす可能性があります。

そこで、
「まず横に分ける。
そのあと縦に掘る。」
という考え方が役立ちます。

■ まず「横に分ける」、そのあと「縦に掘る」

例えば、
「納期遅延が増えている」
という問題なら、
受注 → 調達 → 生産 → 検査 → 出荷
という業務プロセスに分けてみます。

そして、
「実際には、どこで遅れているのか？」
を確認する。

ここでは説明のための仮想例として、ある工場で月100件の納期遅延が発生しているとします。

調べてみると、
調達起因：15件
生産起因：60件
検査起因：10件
出荷起因：15件
だった。

この数字なら、まず「生産」を深く調べる価値が高そうです。

そこで、生産起因60件をさらに分けてみます。
※ここからの内訳も、説明のための仮の数値です。

設備停止：35件
段取り遅延：15件
人員不足：10件

ここまで分かれば、
「設備停止の増加が納期遅延の大きな要因ではないか？」
という仮説を優先して検証できます。

つまり、

大きな問題
↓
横に分ける
↓
数字で当たりをつける
↓
重要な枝を縦に掘る
↓
仮説を立てる
↓
検証する

という流れです。

課題分解は、すべての枝を同じ深さまで調べるためにやるものではありません
「どこを深く調べるべきか」を絞るためにやる
ここが重要です。

■ 生成AIは「横に広げる」ときに使いやすい

この「横に分ける」という作業は、生成AIが役立つところです。

例えば、
「製造業で納期遅延が発生しています。考えられる原因を業務プロセス別に分解してください」
と聞けば、

調達
生産
品質
物流
人員
設備
情報システム

など、自分だけでは思いつかなかった原因候補まで広げてくれるでしょう。

特に、
「自分が見落としている観点はないか？」
を確認する壁打ちには使えます。

ただし、AIが作ったロジックツリーをそのまま使えばいいわけではありません。

AIは、入力されていなければ、
「この工場だけ部品コードの付け方が違う」
「先月、生産計画の担当者が変わった」
「この設備だけ保全周期が違う」
「ERP上では在庫があるが、現場には実物がない」
といった、その会社固有の事情を知りません。

だから、

AIは分解の候補を広げる
人間は現場の事実を使って絞る
この使い分けが現実的だと思います。

■ MECEは「漏れを減らす」ために使う

課題分解とセットでよく出てくるのが、
MECE（ミーシー）
です。

Mutually Exclusive, Collectively Exhaustive。

簡単に言えば、
「漏れなく、ダブりなく」
考えるための考え方です。

例えば設備停止の原因候補を、
人・設備・材料・方法・測定
といった切り口から広げる方法があります。

製造業で使われる、いわゆる5Mの考え方です。

※分類にはいくつかの流儀があり、4Mに「測定」を加えて5Mとする考え方や、さらに「環境」を加えて6Mとする場合もあります。

こうした枠組みを使うことで、
「設備ばかり調べていたけれど、作業方法が変わっていないか？」
「材料ロットに変化はなかったか？」
と、見落としていた視点に気づけます。

ただし、MECEに分けること自体が目的ではありません。

現実の問題では、複数の原因が絡むこともあります。

大切なのは、
「問題を解くために役立つ分け方になっているか。」
です。

■ 製造業DXでは「システム」より先に「業務」を分解する

ここは、製造業DXではかなり重要だと思います。

DX案件では課題を、
ERP
MES
WMS
PLM
EC

と、システム単位で整理してしまうことがあります。

一見すると、きれいに整理されています。

でも、現場の仕事はシステムの境界に合わせて動いているわけではありません。

例えば、
「交換部品の発注に時間がかかる」
という問題があったとします。

そこで、
「それなら部品ECを導入しましょう」
と考えたくなる。

でも、本当に発注操作そのものが遅いのでしょうか。

まず業務を分解してみます。

設備を確認する
↓
故障箇所を特定する
↓
交換部品を特定する
↓
在庫を確認する
↓
見積を取る
↓
承認を取る
↓
発注する
↓
入荷する
↓
交換する

こうして見ると、「発注」という行為は業務全体の一部分でしかありません。

例えば実際には、
「どの部品を発注すればいいのか分からない」
ところで時間がかかっているかもしれません。

そこで、さらに分解します
なぜ部品を特定できない？
設備ごとの部品表がない

図面と過去の発注履歴が別々に管理されている
古い設備なので現在の部品番号が分からない
代替品や後継品の情報が担当者の経験に依存している。

こうなると、最初に見えていた問題とは少し違う姿が見えてきます。

■ 「ECを入れる」が課題ではなかった

先ほどのケースを整理してみます。
最初に見えていたのは、
「交換部品の発注に時間がかかる」
という現象でした。

そこだけ見れば、
「ECを導入すれば発注が速くなる」
と思うかもしれません。

しかし、業務を分解すると、
「部品を特定する工程」
で時間がかかっていた。

さらに調べると、
「設備と交換部品の紐づけが十分にできていない」
ことが原因候補として見えてきた。

すると、本当に解くべき課題は、
「ECを導入すること」
ではありません。

例えば、
「設備ごとに正しい交換部品を特定できる状態を作ること」
です。

そこで初めて、

設備BOM（設備ごとの部品表）の整備
部品マスターの統合
旧部品と後継部品の紐づけ

過去の交換・発注履歴との連携
そして、その先に部品ECとの連携
といった施策候補が出てきます

順番が重要です

■ 「現象」「原因」「課題」「施策」を混ぜない

課題分解で特に混乱しやすいのが、この4つです。

現象
↓
原因
↓
課題
↓
施策

先ほどの交換部品の例なら、

【現象】
交換部品の発注に時間がかかる。
↓
【原因候補】
交換すべき部品の特定に時間がかかっている。
↓
【課題】
設備ごとに正しい交換部品を確認できる状態にする。
↓
【施策】
設備BOMの整備、部品マスター統合、履歴連携、部品EC連携など。

ここで注意したいのが、
「課題：AIを導入する」
「課題：ERPを刷新する」
「課題：ECを構築する」
という書き方です。

AIもERPもECも、基本的には施策です。

重要なのは、
「それによって何を解決するのか？」
です。

■ 課題を分解すると、最初の解決策が消えることもある

課題分解の面白いところはここです。

最初は、
「ECを導入すればいい」
と思っていた。

でも分解してみると、発注画面が問題ではなかった。

必要なのは、
設備BOMかもしれない。
部品マスターの整備かもしれない。
QRコードによる設備・部品情報へのアクセスかもしれない。
既存ERPとのデータ連携かもしれない。
場合によっては、新しいシステムを導入する必要すらないかもしれません。

つまり課題分解とは、
「自分が最初に思いついた解決策が、本当に必要なのかを疑う作業」
でもあります。

これはコンサルだけでなく、IT営業でも重要だと思います。

「何を売るか」から考えると、自社製品に問題を合わせてしまいやすい。

でも、
「どこで仕事が止まっているのか？」
から考えると、本当に必要なものが見えてきます。

■ 課題分解と仮説思考はセット

課題分解と、前回の仮説思考は別々の技術ではありません。

分解する
↓
怪しい場所を見つける
↓
仮説を立てる
↓
検証する

実際の問題解決では、このサイクルを何度も繰り返します。

そして検証結果によって、さらに分解したり、別の枝へ戻ったりする。

だから問題解決は、最初に作ったロジックツリーを上から下まで埋めていく作業ではありません
「分けて、考えて、調べて、必要なら分け直す。」
その繰り返しです。

■ 明日から使うなら、この3つだけ

難しいロジックツリーを最初から作る必要はありません。

何か問題を相談されたら、まず3つだけ考えてみる。

① これは「現象」「原因」「課題」「施策」のどれなのか？
「在庫が多い」は現象なのか。
「AIを導入する」は課題なのか、それとも施策なのか。
まず位置を確認する。

② この問題を横に分けると、何があるのか？
工程別
製品別
顧客別
工場別
設備別
時間帯別
原因別
どの切り口なら、問題が起きている場所を特定できるかを考える。

③ 実際には、どこで止まっているのか？
全部を同じように調べる必要はありません
データを見る
現場に聞く
業務を見る

そして、
「ここが一番怪しいのでは？」
と仮説を置いて検証する。

■ 課題分解とは「答えられる問い」に変えること

「課題を分解する」と聞くと、大きな問題を細かく切り刻む技術のように思えます。

でも、本質は少し違うと思います。

「曖昧な問題を、答えられる問いに変えること。」
「在庫が多い」
から、
「どの在庫が増えている？」
へ。

「納期が遅い」
から、
「どの工程で遅れている？」
へ。

「設備が止まる」
から、
「どの設備の、どの故障モードが増えている？」
へ。

「交換部品の発注が遅い」
から、
「部品特定・在庫確認・承認・発注の、どこで時間がかかっている？」
へ。

特にDXでは、
AIを入れたい。
ERPを刷新したい。
ECを作りたい。
と言われると、すぐシステムの話を始めてしまいがちです。

でも、その前に一つだけ聞いてみる。

「その仕事を最初から最後まで分けると、実際にはどこで止まっていますか？」

解決策から入らず、仕事が止まっている場所を探す。

それが、課題分解の第一歩なのだと思います。

第1回では「結論から話す」
第2回では「仮説を立てる」
第3回では「課題を分解する」

そして課題を分解すると、たくさんの問題が見えてきます。

では、その全部に手をつけるのでしょうか
もちろん、そんなことはできません

次回の「コンサル的思考入門④」では、

「課題に優先順位をつける」とはどういうことなのか？
を考えてみたいと思います。