問題の原因を考えているうちに、対策案や別の問題まで思い浮かび、何から確認すればよいのか分からなくなる・・・といったことはありませんか？
例えば複数人の会議では、現象について話す人、原因を推測する人、解決策を提案する人が同時に現れ、議論がかみ合わなくなることがあります。こうした事態に頭を悩ませている方もいらっしゃるのではないでしょうか。
このように、検討すべき項目が多い問題を整理するときに役立つのがロジックツリーです。
この記事では、ロジックツリーの意味、代表的な種類、作り方を具体例とともに解説します。
作成時によくある失敗や、実務で活用するためのポイントも紹介します。
ロジックツリーとは、複雑な問題や課題を、木の枝のように階層的に分解して整理する手法です。
最初に大きなテーマを置き、そこから構成要素、原因候補、解決策などを枝分かれさせます。抽象的な問題を具体的な項目へ分けることで、何を検討し、どこを詳しく調べるべきか把握しやすくなります。
ロジカルシンキングでは、問題を明確にし、情報を整理・分解し、それぞれの関係を確かめながら、事実や根拠に基づいて結論を導きます。ロジックツリーは、このうち複雑な問題や情報を分解し、構造を見える形にする場面で使われる代表的な手法です。
ただし、ロジックツリーを作っただけで、正しい原因や解決策が分かるわけではありません。ツリーに書き出した内容を、データや事実と照らし合わせながら確認することが必要です。
※参考：ロジカルシンキングについてはこちらもご参照ください。
ロジカルシンキングの鍛え方｜論理的思考力を高める練習方法
一つの問題に多くの要素が関係していると、頭の中だけで全体を把握することが難しくなります。
大きな問題を小さな項目へ分けると、何について考えているのかを整理しやすくなります。
最初に思いついた原因や対策が、必ずしも重要とは限りません。
考えられる項目を分解して並べることで、ほかに確認すべき原因や選択肢がないか検討できます。
問題を分解すると、どの項目から確認すべきか、どこまで詳しく調べる必要があるかを考えやすくなります。
影響の大きさ、確認のしやすさ、緊急性などから優先順位をつけられます。
ロジックツリーを共有すると、作成者が問題をどのような要素に分け、どの範囲まで検討したのかが見えやすくなります。聞き手も、不足している項目や確認が必要な関係について具体的に質問しやすくなります。
ロジックツリーに唯一の分類方法が定められているわけではありません。分解する対象や目的によって、さまざまな形で使われています。
そのうえで、ビジネス実務では用途を理解しやすくするため、Whatツリー、Whyツリー、Howツリー、KPIツリーの4つに分けて説明されることがあります。
|
種類 |
整理する内容 |
主な問い |
|
Whatツリー |
全体の構成要素 |
何で構成されているか |
|
Whyツリー |
問題の原因候補 |
なぜ起きているか |
|
Howツリー |
解決策や実行方法 |
どうすれば解決できるか |
|
KPIツリー |
目標に影響する数値要素 |
どの数値が目標を構成するか |
4種類すべてを順番に作る必要はありません。何を明らかにしたいのかによって、必要なツリーを選びます。
Whatツリーは、ある対象が何で構成されているのかを分解する方法です。例えば、売上を分析するとき、商品別、顧客別、地域別など、目的に合った一つの切り口を選んで整理します。同じ階層に異なる切り口を混在させないことが重要です。
Whyツリーは、問題がなぜ起きているのかを掘り下げる方法です。例えば、売上低下を「顧客数の減少」と「顧客単価の低下」に分け、さらに具体的な原因候補へ分解します。書き出した項目は、原因として確定した事実ではなく、検証すべき仮説です。
Howツリーは、課題を解決する方法を分解するために使います。確認された問題や原因に対して、どのような方向から改善できるかを整理し、実行を検討できる施策へ具体化します。洗い出した施策は、期待できる効果、実行可能性、必要な費用や期間などの基準で比較します。
KPIツリーは、最終的な目標を、それに影響する数値要素へ分解する方法です。例えば、売上を「顧客数×顧客単価」に分け、日常的に確認すべき中間指標を具体化します。KPIツリーは、WhatツリーやHowツリーの考え方を数値目標の管理に応用したものとして扱われることもあります。
「売上について考える」ではなく、「今期の売上が計画を下回っている原因を調べる」など、何を明らかにしたいのかを具体化します。
構成要素、原因、解決方法、数値指標のどれを整理したいのかに応じて、適したツリーを選びます。
既存データ、関係者へのヒアリング、過去の事例などから候補を集めます。最初から完成した構造を作ろうとせず、項目を集めた後で整理しても構いません。
挙げた項目を、上位と下位の関係が分かるように配置します。漏れや重複を抑えるには、MECEの考え方が役立ちます。ただし、完全なMECEを作ること自体を目的にせず、今回の検討に必要な範囲を整理します。
※参考：MECEについてはこちらもご参照ください。
MECEとは？意味・具体例・使い方をわかりやすく解説
Whyツリーならデータや現場で確認できる原因候補、Howツリーなら実行を検討できる施策など、確認や行動につながる段階まで具体化します。
下位項目が上位項目を適切に説明しているか、枝を合わせると検討したい範囲を捉えられているかを確認し、必要に応じて追加・削除・移動します。
Whyツリーの原因候補やKPIツリーで想定した関係が実際に成立しているか確認します。新しい情報が分かった場合は、ツリーも修正します。
ここでは、Webサイトからの問い合わせ数が減ったケースを例に、複数のツリーをどう使い分けるか説明します。
問い合わせ数を、次のような指標に分解します。
各指標を前年同月や過去の推移と比較します。流入数、遷移率、フォーム到達率には大きな変化がなく、フォーム完了率だけが低下していれば、まずフォーム完了率が低下した原因を調べます。
フォーム完了率が低下した原因について、Whyツリーで整理します。
この時点では原因を確定していません。デバイス別の完了率、項目別の離脱状況、エラーログ、表示速度などを調べ、実際に影響している原因を確認します。
調査の結果、スマートフォンでは入力項目が多く、エラー発生時に修正箇所が分かりにくいことが判明した場合、次のようにHowツリーで改善策を整理できます。
このように、必要なツリーを問題解決の段階に応じて使い分けると、問題が発生している箇所、原因候補、解決策を混同せずに整理できます。
「業務を効率化したい」など範囲の広いテーマをそのまま分解すると、枝が増え続けます。どの業務の、どの状態を、何のために改善するのかを具体的にしましょう。
例えば「業務を効率化したい」だけでは、営業、経理、会議など対象が広がります。「月次報告書の作成時間を減らすため、どの作業を見直すか」と絞れば、情報収集、集計、資料作成、確認・修正など、調べる作業を具体化できます。
対象範囲と分類軸を明確にし、重要な項目が抜けていないか、同じ対象が複数の項目に入っていないか確認しましょう。
例えば、顧客の購買傾向を地域別に分析する際、「東京在住者と全国平均」を比較する場合と、「東京在住者と東京以外の在住者」を比較する場合では、答えられる問いが異なります。
【全国水準に対する東京の位置を見る】
東京在住者の平均購入額 ← → 全国の顧客の平均購入額 ※全国には東京も含まれる
【東京とそれ以外の違いを見る】
・全国の顧客（居住地を確認済み）
‐ 東京在住者
‐ 東京以外の都道府県の在住者
全国平均は比較の基準として使えるため、東京を含むこと自体が誤りではありません。一方、顧客を重複のない二つの集団に分けて比べたい場合は、「東京／東京以外」とします。「東京／全国」を同じ親項目の内訳として並べると、東京の顧客が重複します。
どちらの比較が分析のテーマに合っているかを確認することが大切です。居住地が不明な顧客がいる場合は、「不明」を設けるか分析対象から除いたことを明示すると、対象範囲の漏れも把握しやすくなります。
同じ階層に年代、地域、購入商品など異なる切り口を並べると、項目同士の関係が分かりにくくなります。例えば、顧客を年代別に分け始めたのに、枝を追加する途中で別の切り口に変わってしまうケースです。
・顧客
‐ 20代の顧客 ←年代で分けている
‐ 30代の顧客 ←年代で分けている
‐ 関東に住む顧客 ←切り口が地域に代わってしまっている
- 商品Aを購入した顧客 ←購入商品に代わってしまっている
上記の分類だと「関東在住の30代で、商品Aを購入した顧客」は三つの枝に該当します。また、年代構成を見たいのか、地域分布を見たいのか、購入商品の傾向を見たいのかも曖昧になります。
前項が「分類した集団の範囲と重なり」を確認する例なのに対し、こちらは分ける切り口そのものが途中で変わっている例です。年代構成を調べたいのであれば、まず年代で枝をそろえると、比較したい内容が明確になります。
なお、年代別に分けた後、その各年代を地域別に細分化することは問題ありません。階層が変わるたびに同じ切り口を使い続けるという意味ではなく、同じ親項目から分かれる枝の切り口をそろえることがポイントです。
項目を枝分かれさせても、親子関係が成立していなければ論理的な構造にはなりません。そのツリーの目的に合った問いを各階層で繰り返しましょう。
例えば、問い合わせが減った原因を整理するツリーに、次のような枝を置いた場合です。
・問い合わせが減った原因
- サービスページの閲覧者が減った
- 広告予算を増やす
「広告予算を増やす」は対策であり、「なぜ問い合わせが減ったのか」への答えではありません。
原因を検討する枝には原因候補を置き、対策案は別に記録すると、問いと答えの関係を保てます。
ツリー上で線をつないでも、因果関係を証明したことにはなりません。データや現場の状況を確認しましょう。
例えば、「問い合わせが減った」の下に「フォームの入力項目が多い」と置いても、それだけでは今回の減少原因とは判断できません。項目数が以前から変わっていなければ、フォームへの到達者数や入力途中の離脱率、利用端末の構成なども確認し、何が変化したのかを調べます。
きれいな図を作っても、原因の確認や解決策の実行につながらなければ役立ちません。完成後に何を確認し、どの判断や行動につなげるのかを明確にしましょう。
例えば、原因候補を「入力負担」「操作性」「送信エラー」まで整理しても、調査しなければ原因は分かりません。「送信エラー」の枝なら、システム担当者が今週中に直近1か月のエラーログを確認するなど、担当・期限・確認内容を決めると、図を次の行動につなげられます。
ロジックツリーは、すべての問題に必要なわけではありません。
単純な問題では、図を作る手間の方が大きくなることがあります。また、複数の原因が相互に影響する問題や、人の感情など定性的な要素を扱う問題は、一方向の階層構造だけでは捉えにくい場合があります。
作成者の知識やデータが不足していれば、重要な枝が抜ける可能性もあります。必要に応じて、関係者へのヒアリング、データ分析、ブレインストーミングなどを組み合わせましょう。
数値が前月より下がっていても、必ずしも問題が発生しているとは限りません。
例えば問い合わせ数が減っていても、前年同月にも同じ傾向があれば、季節的な変動の可能性があります。営業日数、キャンペーン期間、集計条件、顧客側の事情などが影響していることもあります。
問題ではない現象を起点にすると、その後の原因分析や対策も不要なものになります。
まずは、解決すべき問題が実際に存在するかを確かめましょう。
会議では、「問い合わせが減っている」という現象の話、「検索順位が下がったのではないか」という原因の仮説、「広告を増やそう」という対策案が同時に出ることがあります。どれも関係する情報ですが、そのまま議論すると、原因を確認しないまま対策が決まる可能性があります。
原因を検討するときはWhyツリー、解決策を検討するときはHowツリーと段階を分けましょう。原因を検討している途中で対策案が出た場合には否定せず別に記録し、原因を確認した後で検討するようにします。ツリーによって正しい結論が自動的に得られるわけではありませんが、参加者が同じ構造を見ながら話しやすくなります。
|
手法 |
主な用途 |
|
ロジックツリー |
問題、原因候補、解決策などを階層的に分解する |
|
MECE |
分類の漏れや重複を抑える |
|
なぜなぜ分析 |
特定の問題や原因を繰り返し掘り下げる |
|
マインドマップ |
一つのテーマから自由に連想を広げる |
例えば、問題に関係する要素を自由に出したい場合は、ブレインストーミングやマインドマップが適しています。出てきた要素を分類し、上位・下位の関係へ整理するときにはロジックツリーが役立ちます。一つの原因を深く掘り下げる場合は、なぜなぜ分析を組み合わせることもできます。
ロジックツリーの形を知っていても、実際の問題を適切に定義し、目的に合った切り口で分解するには練習が必要です。ツリーを図として完成させるだけでなく、仮説を立て、事実を確認し、解決策へつなげるには、ほかの思考法と組み合わせて使うことが重要です。
トレノケートの研修「ロジカル・シンキングによる問題解決」では、問題解決のプロセス、発散・収束の技法、MECE、フレームワーク、ロジックツリーなどを、講義と演習を通じて学びます。
ロジックツリーを問題発見や仮説構築、解決策の立案へつなげて活用したい方に適した研修です。
ロジックツリーは、複雑な問題や課題を階層的に分解し、検討すべき項目を整理するための手法です。
一人でも複数人でも、関係する要素が多く、何から確認すべきか分からなくなったときに役立ちます。
ロジックツリーを作る前には、その現象が本当に解決すべき問題なのかも確認しましょう。作成したツリーをデータや現場の状況と照らし合わせ、必要に応じて修正することで、問題解決に活用しやすくなります。