【コンサル的思考入門④】「課題に優先順位をつける」とは、どういうことなのか？

前回の「コンサル的思考入門③」では、「課題を分解する」という考え方について書きました。

大きく曖昧な問題を、
「どこで起きているのか？」
「何が原因なのか？」
と、答えられる問いに変えていく

そして、
現象
↓
原因
↓
課題
↓
施策
を混ぜずに考える

ここまで整理すると、次の問題が出てきます。
「課題が多すぎる。」
設備停止も減らしたい。
在庫も減らしたい。
紙やExcelもなくしたい。
部品マスターも整備したい。
システムも連携したい。
セキュリティも強化したい。
全部やった方がいい。
でも、人も予算も時間も限られています。

では、
「何から手をつけるのか？」
これが今回のテーマ、

「課題に優先順位をつける」

という考え方です。

■ 「重要そうなものから」では決められない

課題が10個並んだとき、
「重要なものからやりましょう」
と言いたくなります

でも、
そもそも「重要」とは何でしょうか？
売上への影響が大きい。
コスト削減効果が大きい。
工場停止につながる。
品質事故につながる。
現場の負担が大きい。
顧客への影響が大きい。
短期間で改善できる。
どれも「重要」です。

判断基準を決めずに優先順位をつけると、
声の大きい人。
役職の高い人。
直近で問題になったこと。
経営会議で最近話題になったこと。
などが上位に来やすくなります。

だから最初に必要なのは、
課題を並べることではなく、
「何を基準に比べるのか」を決めることです。

■ 優先順位を決める5つの軸

難しいフレームワークを使わなくても、まず次の5つを見るだけでかなり整理できます。
① 影響度
② 緊急度・リスク
③ 実現性
④ 影響範囲
⑤ 依存関係

一つずつ見てみます

■ ① 影響度――解決すると、どれくらい変わるのか？

最初に見るのは、
「この課題を解決すると、どれくらい効果があるのか？」
です。

例えば、
売上。
利益。
コスト。
工場の停止時間。
在庫金額。
作業時間。
不良率。
納期。
などです。

「現場が困っている」
だけではなく、
「どれくらい困っているのか？」
まで考えます

例えば、
「部品検索に時間がかかる」
という課題でも、
1人が月に30分困っているのか。
100人が毎日30分困っているのか。
では、意味がまったく違います。

■ ② 緊急度・リスク――放置すると何が起きるのか？

次に見るのが、
「今やらなかったら、何が起きるのか？」
です。

ここは製造業では特に重要です

例えば、
設備停止。
品質。
安全。
法令遵守。
OTセキュリティ。
BCP。
こうした課題は、単純な費用対効果だけでは判断できません。

セキュリティ対策をしても、
「売上が1億円増える」
とは説明しにくい

しかし、サイバー攻撃によって製造ラインが長期間停止すれば、事業への影響は大きくなります。

安全や品質も同じです。
だから、
「改善するといくら儲かるか？」
だけではなく、
「放置すると、どんな損失やリスクがあるのか？」
を見る必要があります。

■ ③ 実現性――本当にできるのか？

効果が大きくても、実現できなければ進みません。

そこで、
「本当に実行できるのか？」
を考えます。

必要なデータはあるか。
予算はあるか。
技術的に実現できるか。
担当者はいるか。
現場が運用できるか。
既存システムと連携できるか。

例えば、
「AIで設備故障を予測する」
という施策があったとします。

実現すれば効果は大きいかもしれません。
でも、
設備データが保存されていない。
故障履歴もない。
交換履歴もない。
正常時と異常時のデータも区別できない
この状態なら、いきなりAIから始めるのは難しい
まずデータを取れる状態にする方が先かもしれません。

■ ④ 影響範囲――何人、何拠点、何工程に効くのか？

課題の大きさを見るとき、1回あたりの負担だけを見ると判断を誤ることがあります。

例えば、
A工場の1人が、毎日30分余計な入力作業をしている

一方で、
全国100人が、毎日10分ずつ二重入力している。
一人あたりの負担は前者の方が大きい。
でも全体で見ると後者の方が大きいかもしれません。

そこで、
1回あたりの負担
× 発生頻度
× 対象人数
というように考える。

さらに、
1部署だけなのか。
1工場なのか。
国内全拠点なのか。
海外拠点まで共通なのか。
顧客や仕入先にも影響するのか。
という範囲も見ます。

■ ⑤ 依存関係――これを先にやらないと、次に進めないのでは？

これはDXでかなり重要です。

例えば、
「AIで需要予測をしたい」
という話があったとします。

でも、
品番が工場ごとに違う。
顧客コードが統一されていない。
販売実績の粒度がバラバラ。
マスターも整理されていない。
この状態でAIを導入しても、うまくいかない可能性があります。

すると、
AIより先に、
「マスター整備」
が必要かもしれません。

同じように、
設備BOM。
設備ID。
顧客マスター。
商品マスター。
データ連携基盤。
業務標準化。
などは、それ単体では派手な成果が見えにくい。

でも、
「これをやらないと、後ろの施策が成立しない」
のであれば優先度は高くなります。

■ 「Impact × Effort」という考え方

コンサルやプロジェクトの現場では、
「Impact × Effort」
という考え方もよく使われます。

日本語にすると、
「影響度 × 実現負荷」
くらいの意味です。

以降は日本語で考えてみます。

課題を大きく4つに分けます。

【影響度：大 × 実現負荷：小】
→ 優先的に取り組みやすい。
短期間で効果を出せる、いわゆるQuick Win（短期で成果を出しやすい施策）です。

【影響度：大 × 実現負荷：大】
→ 重要だが、中長期で計画する。

【影響度：小 × 実現負荷：小】
→ 余力があれば取り組む。

【影響度：小 × 実現負荷：大】
→ 基本的には後回し。

非常にシンプルですが、課題を整理するときには使いやすい考え方です。

ただし、これだけで最終判断するのではなく、先ほどの「緊急度・リスク」や「依存関係」も合わせて見る必要があります。

■ 「簡単だから先にやる」は正しいのか？

DX案件では、
「まず、できるところから始めましょう」
という言葉をよく聞きます

もちろん、小さく始めることには意味があります

しかし、
「簡単にできる」＝「優先すべき」
ではありません

例えば、
紙の日報をタブレット化する。
比較的始めやすいDXかもしれません。
一方で、その工場では設備停止によって大きな損失が発生している。

それでも、
「日報電子化の方が簡単だから」
という理由だけでそちらを優先する。

すると、
「DXをやっている感は出るけれど、経営課題はほとんど改善していない」
ということが起こります。

「できることから始める」は重要です。
でも、その前に、
「それをやる意味は大きいのか？」
を確認する必要があります。

■ 逆に「効果が大きいから先にやる」も危ない

反対もあります。

例えば、
「全社ERPを刷新すれば大きな効果が期待できる」
とします。

でも、
導入に数年かかる。
関係部署が非常に多い。
既存システムとの連携も複雑。
データ移行も必要。
業務そのものも変えなければならない。
となれば、すぐに成果が出るとは限りません。

だから、
効果だけを見るのでもない。
簡単さだけを見るのでもない。
影響度と実現性の両方を見る必要があります。

■ 仮想例で優先順位を考えてみる

ここでは、説明のための仮想例を使います。

ある製造会社で、次の4つの課題が見つかったとします。

【課題A：設備停止】
月4回発生。
1回あたり2時間停止。
停止による損失を1時間100万円と仮定すると、
4回 × 2時間 × 100万円
＝ 月800万円
です。

【課題B：保全部品の検索】
100人の担当者が、1日15分ずつ部品検索に時間を使っている。
月20日稼働とすると、
100人 × 15分 × 20日
＝ 30,000分
＝ 月500時間
です。

【課題C：紙の日報転記】
50人が1日10分。
月20日なら、
50人 × 10分 × 20日
＝ 10,000分
＝ 約167時間
です。

【課題D：全社ERP刷新】
全社への影響は非常に大きい。
ただし、実現には数年規模の期間が必要とします。

※以上の数字や条件は、優先順位の考え方を説明するための仮想例です。

■ 「設備停止が月800万円だから最優先」でいいのか？

数字だけを見ると、
「課題A：設備停止」
が最優先に見えます。

確かに影響度は大きい
でも、ここで終わらない。

次に、
「実現性」
を見ます。

例えば、
停止原因がある程度分かっている。
特定部品の交換周期を変更すれば改善できそう。
必要なデータもある。
半年以内に改善可能。
という状態なら、優先度はかなり高いでしょう。

逆に、
停止原因がまったく分からない。
ログも残っていない。
設備メーカーでも原因を特定できていない。
となれば、同じ月800万円の損失でも、すぐ解決できるとは限りません。

まず、
「原因を調査できる状態を作る」
ことが先になるかもしれません。

つまり、
「損失額が大きい順」に並べれば終わりではない
ということです。

■ 「根っこの課題」を先にやる

ここで⑤の「依存関係」が効いてきます。

例えば製造業DXで、
部品検索に時間がかかる。
誤発注が多い。
在庫が重複している。
旧部品と後継部品の対応が分からない。
という4つの課題があったとします。

一見すると別々の問題です。

でも課題を分解してみると、
「部品マスターが統一されていない」
という共通原因につながっているかもしれません。

あるいは、
「設備と部品を紐づける設備BOMが整備されていない」
ことが根底にあるかもしれない。

だったら、
検索システムを改修する。
発注画面を改修する。
在庫画面を改修する。
と個別に対応するより、
「部品マスターや設備BOMを先に整備する」
方が、複数の課題に効く可能性があります。

これが、
「根っこの課題を優先する」
という考え方です。

■ 「業務課題」と「基盤課題」は見え方が違う

DXでは、
「業務課題」
と、
「基盤課題」
を分けて考えると分かりやすくなります。

例えば、
【業務課題】
・発注に時間がかかる
・在庫が多い
・設備停止が多い
・問い合わせが多い

一方、

【基盤課題】
・設備BOMがない
・部品マスターが統一されていない
・設備IDが拠点ごとに違う
・必要なデータが蓄積されていない

業務課題は、
「今、困っていること」
として見えやすい。

一方、基盤課題は地味です。

マスターを整備しても、
「売上が○億円増えました」
とはすぐに言いにくい。

でも、その基盤課題が複数の業務課題の原因になっているのであれば、優先順位は高くなります。

「目立つ課題が、必ずしも最優先とは限らない。」

ここはDXではかなり重要です。

■ 優先順位は「声の大きさ」で決めない

会社で課題を集めると、
営業が困っている。
製造が困っている。
保全が困っている。
経理が困っている。
情報システム部門が困っている。
と、たくさん出てきます。

そして会議では、
一番強く主張した部署。
役職の高い人。
最近トラブルが起きた部署。
の課題が優先されやすくなります。

でも本来見るべきなのは、
「誰が言ったかではなく、会社にどれだけ影響するのか。」
です。

そのために、
影響度。
緊急度・リスク。
実現性。
影響範囲。
依存関係。
という共通の軸で比較します。

最終的な優先順位は経営判断になります。

コンサルの仕事は、その判断そのものを勝手に決めることではなく、
「なぜAをBより先にやるべきなのか？」
を判断できる材料に整理することでもあります。

■ 生成AIは「比較するところ」で使える

生成AIを使えば、
課題を一覧化する。
評価軸の候補を出す。
比較表を作る。
論点の抜け漏れを確認する。
といった作業はかなり効率化できます。

ただし、
売上を最優先するのか。
安全を最優先するのか。
短期成果を重視するのか。
将来の基盤投資を重視するのか。
という判断基準は、会社によって違います。

AIに順位を聞く前に、
「何を大切にして順位を決めるのか？」
を人間側で決める必要があります。

■ 明日から使うなら「なぜ今やるのか？」を1行で書く

難しい評価表を作らなくても、すぐできる方法があります。

課題が並んだら、それぞれの横に、
「なぜ、これを今やるのか？」
を1行で書いてみる。

例えば、
【設備停止対策】
→ 月800万円相当の損失があり、原因もある程度特定できているため。

【部品マスター整備】
→ 部品検索・誤発注・在庫管理など、複数課題の前提になるため。

【紙日報の電子化】
→ 効果はあるが、他課題と比較すると経営への影響が小さいため後回し。

こうすると、
「なんとなくAが重要」
ではなく、
「Aは影響度が大きく、実現性も高く、さらにBとCの前提になるため最優先」
と説明できるようになります。

これが優先順位づけです。

■ 優先順位とは「やらないこと」を決めること

課題に優先順位をつけるというと、
「何をやるか決めること」
だと思いがちです。

でも、それだけではありません。

むしろ重要なのは、
「今は何をやらないのか」を決めること。
です。

全部を最優先にすると、結局どれも最優先ではなくなります。
人も分散する。
予算も分散する。
プロジェクトも増える。
現場の負担も増える。
そして、どれも中途半端になる。

だから、

今やる。
次にやる。
今はやらない。
を決める。

そのために、

① 影響度
② 緊急度・リスク
③ 実現性
④ 影響範囲
⑤ 依存関係
を見る。

そして最後に、
「なぜ、これを今やるのか？」
を説明できるようにする。

これが「課題に優先順位をつける」ということなのだと思います。


第1回では、「結論から話す」。
第2回では、「仮説を立てる」。
第3回では、「課題を分解する」。
そして第4回では、「課題に優先順位をつける」。

ここまで来ると、
「何を解決すべきなのか」
がかなり見えてきます。

では次に、
「その課題を、どうやって解決するのか？」
を考えなければなりません。
同じ課題でも、解決策は一つとは限りません。
システムを導入するのか。
業務を変えるのか。
ルールを変えるのか。
組織を変えるのか。

あるいは、何もしないという選択肢もあるかもしれません。

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

「解決策を考える」とはどういうことなのか？
を考えてみたいと思います。