フレームワーク活用ガイドひとことで言うと#
問題を**「なぜ？（Why）」で抽象度を上げ、「どうやって？（How）」で具体化する**ことで、ハシゴを上り下りするように思考の階層を移動し、問題を解くべき適切なレベルを見つける思考法。
押さえておきたい用語#
- ラダリング（Laddering）
- 問いを「なぜ？」「どうやって？」で上下に移動させる技法を指す。マーケティングのインタビュー手法としても広く使われる。
- 抽象度（Level of Abstraction）
- 問題や概念の具体性と一般性の度合いのこと。上に行くほど抽象的（広い）、下に行くほど具体的（狭い）。
- リフレーミング（Reframing）
- 問題の枠組み（フレーム）自体を変えるアプローチ。抽象のハシゴを上って問題を再定義することがリフレーミングにつながる。
- HMW（How Might We）
- 「どうすれば〜できるだろうか？」という問いの形式のこと。抽象のハシゴで適切なレベルを見つけた後、具体策を発想する際に使う。
抽象のハシゴの全体像#
こんな悩みに効く#
- 目の前の具体的な要望に応えたが、本質的な課題が解決されていない
- アイデアが具体的すぎて、もっと広い選択肢が欲しい
- 抽象的な議論ばかりで、具体的なアクションに落ちない
基本の使い方#
今、目の前にある問題や課題をそのまま書く。
例：「社員食堂のメニューを増やしたい」
「なぜそれが必要なのか？」を繰り返して、問題の抽象度を上げていく。
- 「社員食堂のメニューを増やしたい」
- なぜ？ → 「社員食堂の満足度を上げたい」
- なぜ？ → 「社員のランチ体験を良くしたい」
- なぜ？ → 「社員の午後のパフォーマンスを上げたい」
- なぜ？ → 「会社全体の生産性を上げたい」
- なぜ？ → 「社員の午後のパフォーマンスを上げたい」
- なぜ？ → 「社員のランチ体験を良くしたい」
- なぜ？ → 「社員食堂の満足度を上げたい」
上に行くほど解決策の選択肢が広がる。
適切な抽象度のレベルから「どうやって実現するか？」で別の具体策を考える。
「社員のランチ体験を良くしたい」から下りると：
- メニューを増やす（元の案）
- 外部のフードトラックを呼ぶ
- ランチ補助金を出してどこでも食べられるようにする
- ランチタイムを柔軟にする
- 食堂の空間をカフェ風にリノベーションする
元の問題のレベルでは見えなかった選択肢が生まれる。
抽象度を上げすぎると「会社の生産性を上げる」のように大きすぎて手が打てない。具体的すぎると選択肢が狭い。
判断基準：
- 自分の裁量で実行できるか？
- 複数の解決策の選択肢があるか？
- 成果が測定できるか？
3つを満たすレベルが、解くべき適切な問題の粒度。
具体例#
ハシゴを上る：
- FAQページを改善したい
- なぜ？ → 問い合わせを減らしたい
- なぜ？ → カスタマーサポートの負荷を減らしたい
- なぜ？ → 顧客が自分で問題を解決できるようにしたい ← ここで止める
- なぜ？ → カスタマーサポートの負荷を減らしたい
- なぜ？ → 問い合わせを減らしたい
ハシゴを下りる（「顧客が自分で問題を解決できるようにしたい」から）：
- FAQページの改善（元の案）
- チャットボットの導入
- 動画チュートリアルの作成
- 製品のUI自体を改善して疑問が生まれにくくする
- コミュニティフォーラムで顧客同士が助け合う場を作る
最適レベルの判断： 「FAQページの改善」だけではなく、「顧客のセルフ解決率を上げる」をゴールに設定。FAQ改善＋動画チュートリアル＋UI改善の3本柱で取り組むことに。
問い合わせが40%減少（月間1,200件→720件）。FAQ改善だけでは20%減にとどまる見込みだったため、抽象度を1段上げたことで2倍の効果を得られた。CS人件費に換算すると年間約600万円のコスト削減。
ハシゴを上る：
- インスタのフォロワーを増やしたい
- なぜ？ → SNS経由の来店を増やしたい
- なぜ？ → 新規顧客の来店数を増やしたい ← ここで止める
- なぜ？ → SNS経由の来店を増やしたい
ハシゴを下りる（「新規顧客の来店数を増やしたい」から）：
- インスタのフォロワー増加（元の案）
- Googleマップの口コミを充実させる
- 近隣企業へのケータリング営業
- 地元イベントへの出店
- 紹介割引制度の導入
最適レベルの判断： インスタに固執せず「新規集客」として幅広く検討。Googleマップの口コミ強化と近隣企業への営業を優先。
インスタに固執せず「新規集客」として検討範囲を広げたケースだ。Googleマップの評価を3.8→4.5に改善し検索からの来店が月32人→87人に増加、近隣3社への週2回のケータリングで月商が約12万円アップした。
ハシゴを上る：
- 検査項目を増やしたい
- なぜ？ → 出荷後の不良品を減らしたい
- なぜ？ → 製品品質を安定させたい ← ここで止める
- なぜ？ → 出荷後の不良品を減らしたい
ハシゴを下りる（「製品品質を安定させたい」から）：
- 検査項目を増やす（元の案）→ ただし検査時間が1.5倍になり生産効率が低下
- 製造工程の自動化で人的ミスを減らす
- 統計的品質管理（SPC）で工程内の異常を早期発見
- 原材料の受入検査を強化する
- 作業者のスキル認定制度を導入する
最適レベルの判断： 検査項目の追加だけでなく、工程内管理と受入検査の2つを追加。「出荷前で不良を見つける」から「不良が生まれない仕組み」に転換。
「出荷前で不良を見つける」から「不良が生まれない仕組み」に転換した結果、不良率1.8%→0.3%、年間不良品コスト2,400万円→400万円に削減。検査項目追加だけなら1.8%→1.2%にとどまる試算だった。
やりがちな失敗パターン#
- 具体的な要望をそのまま解決してしまう — 「メニューを増やしたい」と言われて、本当にメニューを増やすだけで終わる。「なぜ？」を2〜3回聞くだけで、より本質的な課題が見つかることが多い
- 抽象度を上げすぎて手が打てなくなる — 「世界を良くしたい」まで上がっても意味がない。「自分のアクションで変えられるレベル」に留める
- ハシゴの上り下りを1方向だけで終わる — 上に行くだけ、下に行くだけでは効果半減。上がって視野を広げてから、別ルートで下りるのが最も効果的
- チームで使うとき「なぜ？」が詰問に聞こえる — 「なぜそれが必要？」を繰り返すと相手が責められている気持ちになることがある。「それが実現すると何が嬉しいですか？」のように問いの表現を工夫する
まとめ#
抽象のハシゴは「なぜ？」で上り「どうやって？」で下りることで、問題の適切な粒度を見つける思考法。具体的すぎる要望に直接応えるのではなく、一度抽象度を上げて本質的な課題を把握し、そこから複数の解決策を検討することで、より効果的なアプローチが見つかる。