抽象度のはしごとは？問題定義の粒度を調整して最適な解決策を導く手法
抽象度のはしご（Abstraction Laddering）は、「Why?」で問題を抽象化し「How?」で具体化することで、問題定義の最適な粒度を見つけ出す手法です。フレーミングの技術から実践プロセスまでを解説します。
抽象度のはしごとは
抽象度のはしご（Abstraction Laddering）とは、問題の定義を「Why?（なぜ?）」で上位に抽象化し、「How?（どうやって?）」で下位に具体化することで、問題解決に最も適した粒度を見つけ出す手法です。デザインシンキングや問題解決の文脈で広く活用されています。
この手法の起源は、言語学者S.I.ハヤカワ（S.I. Hayakawa）が1939年の著書 “Language in Action” で提唱した「抽象のはしご」（Abstraction Ladder）にさかのぼります。ハヤカワは言葉の抽象度が思考に与える影響を論じましたが、この概念がのちにデザインシンキングやマーケティング（ラダリング法）にも応用されるようになりました。
コンサルティングの現場で問題解決がうまくいかない原因の多くは、実は「問題の解き方」ではなく「問題の定義」にあります。問題を狭く定義しすぎると解決策の選択肢が制限され、広く定義しすぎると焦点がぼやけて実行に移せません。抽象度のはしごは、この「問題定義の粒度」を意識的に調整するためのフレームワークです。
構成要素
はしごの5段階
抽象度のはしごは、最も具体的なレベルから最も抽象的なレベルまで、5つの段階で構成されます。
| 段階 | レベル | 問いかけ | 例（小売業の売上低下） |
|---|---|---|---|
| 5 | ビジョン・目的 | 究極的に何を実現したいか？ | 地域の生活インフラとして不可欠な存在になる |
| 4 | 戦略・方針 | 何を達成すべきか？ | 顧客の来店頻度と購買単価を向上させる |
| 3 | 問題定義 | 解くべき問題は何か？ | 30代共働き世帯の夕方の買い物ニーズに応えられていない |
| 2 | 施策・アプローチ | どうアプローチするか？ | 夕方の惣菜ラインナップを強化し、ネット注文を導入する |
| 1 | タスク・作業 | 具体的に何をするか？ | 惣菜メーカーとの契約変更とECシステムの導入 |
Why?で上がる（抽象化）
「なぜそれが問題なのか？」「なぜそれを達成したいのか？」と問いかけることで、はしごを上に登ります。具体的な事象から、その背後にある本質的な課題や目的を掘り下げます。上に登りすぎると「世界平和を実現したい」のような漠然としたレベルに達し、具体的なアクションにつながりません。
How?で下がる（具体化）
「どうすればそれを実現できるか？」「具体的に何をするか？」と問いかけることで、はしごを下に降ります。抽象的な方針から、実行可能な施策やタスクへと落とし込みます。下に降りすぎると、手段が自己目的化し、「なぜそれをやるのか」が見えなくなります。
実践的な使い方
ステップ1: 最初の問題定義を言語化する
まず、クライアントやチームが最初に提示した問題をそのまま書き出します。「営業の生産性が低い」「新規顧客の獲得が停滞している」「離職率が高い」など、現時点で認識されている問題です。この段階では正しいかどうかの判断をせず、スタート地点として受け止めます。
ステップ2: Why?を3回繰り返して上に登る
最初の問題定義から「なぜそれが問題なのか？」を繰り返して、はしごを上に登ります。たとえば「営業の生産性が低い」→（Why?）→「見込み客への提案活動に十分な時間が割けていない」→（Why?）→「既存顧客の対応に時間が取られすぎている」→（Why?）→「顧客対応プロセスが属人化しており、効率化の仕組みがない」。3回程度のWhy?で、当初の問題定義とは異なる本質的な課題が見えてきます。
ステップ3: How?を3回繰り返して下に降りる
逆方向にも展開します。「顧客対応プロセスの属人化」→（How?）→「対応手順の標準化とナレッジベースの構築」→（How?）→「CRMシステムへの対応履歴の一元化と対応テンプレートの整備」→（How?）→「CRMの導入ベンダー選定とテンプレート設計のワークショップ実施」。具体的なアクションアイテムにまで落とし込みます。
ステップ4: 最適な粒度を選択する
はしご全体を俯瞰し、「このプロジェクトのスコープと期間で解くべき問題はどのレベルか」を判断します。高すぎるレベルを設定すると、プロジェクトの期間とリソースでは手に負えません。低すぎるレベルを設定すると、根本的な問題が解決されません。プロジェクトの制約条件（時間、予算、権限）と照らし合わせて、現実的に解決可能かつインパクトの大きいレベルを選びます。
活用場面
- プロジェクトの初期段階で、クライアントの「お題」を再定義し、真の課題を特定する場面
- ブレインストーミングが行き詰まったときに、問題の粒度を変えて発想を切り替える場面
- デザインシンキングのプロセスで、ユーザーの表面的な要望から潜在的ニーズを掘り起こす場面
- 経営層と現場の認識のギャップを可視化し、全員が同じレベルの問題を見ている状態をつくる場面
- 複数の施策案を評価する際に、それぞれが解こうとしている問題のレベルを揃える場面
- コンサルタント自身の思考を整理し、提案の論理構造を明確にする場面
注意点
抽象度のはしごで最もよくある失敗は、「上に登る」ことにばかり注力して、実行可能な具体策に落とし込まないことです。「本質的な問題は何か？」を追求すること自体は重要ですが、最終的に具体的なアクションにつながらなければ、分析のための分析に陥ります。
また、Why?の連鎖で「犯人探し」に陥るケースにも注意が必要です。「なぜ売上が下がったのか？」→「営業担当のスキルが低いから」→「採用基準が甘いから」→「人事部門の怠慢だ」というように、原因追及が組織内の責任追及に変わってしまうと、問題解決ではなく問題の悪化を招きます。
さらに、チームメンバー間で「はしごの段」の認識がずれていると議論がかみ合いません。「ビジョンレベルの話をしている人」と「タスクレベルの話をしている人」が同じ場にいると、双方ともに「話が通じない」というフラストレーションを抱えます。議論の前に「今どの段の話をしているか」を明示することが、建設的な対話の前提です。
まとめ
抽象度のはしごは、Why?で問題を抽象化しHow?で具体化することで、問題定義の最適な粒度を見つけ出す手法です。問題解決の成否は「何を解くか」の定義で大きく左右されるため、このフレーミングの技術はコンサルタントの基礎力として極めて重要です。上にも下にも行き過ぎない「スイートスポット」を見つけ、チーム全員が同じレベルの問題を共有した状態をつくることが、効果的な問題解決の出発点となります。