Home / 問題構造化とは ― 問題を分解し、関係を明らかにして解決への道筋をつくる

問題構造化とは ― 問題を分解し、関係を明らかにして解決への道筋をつくる

問題構造化（Problem Structuring）とは、複雑で曖昧な問題を整理し、その構成要素や相互関係を明らかにすることで、調査、分析、意思決定、問題解決を進めやすくする活動です。問題を小さな要素に分解する、業務の流れを可視化する、原因と結果の関係を整理する、目標を具体的な指標へ展開するなど、さまざまな方法が利用されます。

例えば、「売上が伸びない」という問題があるとします。その原因を考えるには、顧客数、購入頻度、購入単価などの要素に分解する方法があります。また、問い合わせから受注までの営業プロセスを調べ、どの段階で顧客が離脱しているかを調べることもできます。

しかし、最初から「売上を増やす」という課題を設定することが適切とは限りません。利益率の低い商品が多いことや、既存顧客への依存が高すぎることが、より重要な問題かもしれません。

問題構造化では、単に与えられた問題を細かく分解するだけでなく、何を問題と捉えるべきか、どの範囲までを対象とするか、どのような関係に注目するかを検討することも重要です。

問題構造化は一つの思考技法なのか

問題構造化は、特定の一つの技法ではなく、複数の技法を含む広い概念です。

実務では、ロジックツリー、イシューツリー、KPIツリー、プロセスマップなどを用いて、問題を階層的に分解したり、要素間の関係を図式化したりすることが一般的です。

一方、経営科学やオペレーションズ・リサーチ（Operations Research：OR）には、問題構造化手法（Problem Structuring Methods：PSMs）と呼ばれる研究領域があります。そこでは、関係者によって問題の認識や目的が異なる複雑な状況を扱い、問題の定義そのものを検討することが重視されます。

両者は関連していますが、同じ範囲を指すわけではありません。

問題構造化を広く理解するには、次の四つの活動を区別すると便利です。

活動主な問い代表的な方法
問題を捉え直すそもそも何が問題なのか問題定義、リフレーミング、SSM
問題を分解するどのような要素から構成されるかロジックツリー、イシューツリー
関係を明らかにする要素がどのようにつながっているかプロセスマップ、特性要因図、因果ループ図
測定・検証できる形にする何を測り、どこを改善するかKPIツリー、統計解析、実験計画法

実際の問題解決では、これらの活動を行き来することになります。

1. ロジックツリー ― 問題を階層的に分解する

ロジックツリー（Logic Tree）は、ある問題やテーマを複数の構成要素に分解し、階層的に整理する方法です。

例えば、「売上が伸びない」という問題を、顧客数と顧客当たりの売上という観点から分解できます。さらに、顧客数を新規顧客と既存顧客に分けたり、顧客当たりの売上を購入頻度や購入単価という要素に分解したりできます。

ロジックツリーには、目的に応じていくつかの使い方があります。

**Whatツリー（要素分解）**は、対象がどのような部分から構成されているかを整理します。例えば、製品コストを材料費、人件費、設備費などに分解できます。

**Whyツリー（原因分析）**は、問題がなぜ生じているのかという原因候補を階層的に整理します。例えば、「納期遅延」の原因候補を、部品調達、生産能力、作業計画などへ展開できます。

**Howツリー（対策展開）**は、目標を達成するための手段を整理します。例えば、「納期短縮」という目標から、工程の改善、在庫管理の見直し、設計の標準化などの対策を考えます。

MECEという考え方とその限界

ロジックツリーでは、MECE（Mutually Exclusive, Collectively Exhaustive）、すなわち「互いに重複せず、全体として漏れがない」という考え方がよく使われます。

例えば、顧客を「国内顧客」と「海外顧客」に分ける場合、対象地域の定義を明確にすれば、重複のない分類を作れます。

しかし、問題の原因を分類する場合、MECEを完全に実現することは容易ではありません。

例えば、納期遅延の原因には、設備の問題と作業計画の問題が相互に影響している場合があります。こうした原因を一つの分類だけに割り当てると、重要な関係が失われる可能性があります。

また、最初に思いついた項目をすべて整理できたとしても、そもそも未知の要因が含まれていなければ、本当に漏れがないとは言えません。

ロジックツリーは、問題を整理するために有用ですが、作成した分類が現実の構造を完全に表しているとは限りません。

2. イシューツリー ― 答えるべき問いを整理する

イシューツリー（Issue Tree）は、解決すべき問題を、答える必要のある問いや論点へ分解する方法です。

例えば、「新しい市場へ参入するべきか」という課題について、次のような問いを設定できます。

  • 市場に十分な需要があるか。
  • 顧客の未解決問題は何か。
  • 既存の競合企業とどのように差別化できるか。
  • 自社に必要な技術や事業能力があるか。
  • 期待できる収益と必要な投資はどの程度か。

さらに、それぞれの問いについて、追加で調査すべき事項を整理できます。

ロジックツリーとイシューツリーは厳密に区別されず、同じような意味で使われることもあります。ただし、イシューツリーでは特に「何について答えを出す必要があるか」という問いの設定に重点があります。

最初の問いが間違っている可能性

イシューツリーを作成する際には、最上位の問いが適切であるかを検討する必要があります。

例えば、「新市場へ参入するべきか」という問いの前に、「既存製品の用途を広げることと、新製品を開発することのどちらが望ましいか」を検討すべきかもしれません。

最初の問いが適切でなければ、その下にどれだけ詳細な論点を展開しても、重要な問題が検討対象から外れてしまいます。

イシューツリーは、問いを体系的に整理すると同時に、問いそのものを見直すためにも利用できます。

3. KPIツリー ― 目標を測定可能な指標へ分解する

KPIツリー（KPI Tree）は、売上、利益、生産性などの目標を、それに関係する下位の指標へ分解して整理する方法です。

例えば、取引ごとに売上が発生する事業では、一定期間の売上を次のように表せます。

売上 = 取引件数 × 平均取引単価

さらに、取引件数を次のように分解できます。

取引件数 = 購入顧客数 × 顧客当たりの平均購入回数

この場合、売上が低下している理由を考える際に、顧客数、購入頻度、購入単価のうち、どの指標が変化しているかを調べられます。

KPIツリーの長所は、上位の目標と下位の指標の関係を数量的に把握できることです。

ただし、すべてのKPIが単純な掛け算や足し算で結びつくわけではありません。

例えば、従業員満足度が高まることで生産性が向上するという関係は、単純な計算式ではなく、検討すべき因果仮説です。

計算上の関係と因果関係を区別する

KPIツリーでは、次の二種類の関係を区別すると理解しやすくなります。

一つは、売上と取引件数・平均取引単価のような、定義上または計算上の関係です。

もう一つは、広告投資が増えると顧客数が増える、研修を実施すると生産性が向上する、といった因果的な仮説です。

計算上の関係は、指標の定義が適切であれば数式によって確認できます。しかし、因果的な関係については、実際のデータや実験などによる検討が必要です。

KPIツリーを作成しただけでは、どの対策が効果を生むかまで証明されたわけではありません。

また、設定したKPIが本当に最終的な目標を表しているかも検討する必要があります。

例えば、顧客サポートの問い合わせ件数を減らすことが目標であっても、利用者が問い合わせを諦めるようになっただけなら、サービスの改善とは言えないでしょう。

4. プロセスマップ ― 業務や作業の流れを可視化する

プロセスマップ（Process Map）は、業務や作業がどのような順序で行われ、どの段階で判断や情報の受け渡しが発生するかを図式化する方法です。

フローチャートは、プロセスマップの代表的な形式です。

例えば、受注から納品までの流れを次のように整理できます。

顧客からの注文 → 受注内容の確認 → 在庫確認 → 製造・出荷指示 → 納品

実際の業務では、在庫不足による発注、仕様確認のやり直し、承認待ち、部門間の情報伝達など、さまざまな分岐や例外的な処理が存在します。

これらを可視化することで、どこで作業が停滞しているのか、どの工程で手戻りが発生しているのかを検討できます。

プロセスマップでは、作業の順序だけでなく、担当部門、必要な情報、処理時間、待ち時間などを記録することもできます。

現状と改善後のプロセス

業務改善では、現在のプロセスを表すAs-Isモデルと、改善後の望ましい状態を表すTo-Beモデルを区別することがあります。

例えば、現在はすべての注文について複数の承認を必要としている場合、一定の条件を満たす注文について承認手順を簡略化することが考えられます。

ただし、現在の業務を担当者に聞くだけでは、実際の運用を正確に把握できない場合があります。例外処理や非公式な作業が、公式の業務手順書に記載されていないこともあるからです。

そのため、現場観察や業務記録などによって、実際の処理状況を確認することが重要です。

プロセスマイニングとの関係

情報システムにイベントログが保存されている場合には、プロセスマイニング（Process Mining）によって、実際に実行された処理の流れを分析できます。

プロセスマップが人間の観察や記述に基づいて作成されるのに対し、プロセスマイニングでは記録されたイベントから処理の経路や頻度を調べられます。

ただし、イベントログに含まれていない作業や、記録されていない判断を把握できるわけではありません。

現場観察、プロセスマップ、イベントログの分析を組み合わせることで、業務の構造をより詳しく理解できる可能性があります。

5. 原因や相互作用を構造化する方法

ロジックツリーやKPIツリーは階層的な構造を表すことに適しています。しかし、現実の問題には、階層構造だけでは表現しにくい関係があります。

例えば、製品の不良率が高くなる原因として、設備の状態、作業方法、材料、環境条件などが考えられます。これらの要因が互いに影響し合っている可能性もあります。

特性要因図は、ある結果に対する原因候補を体系的に整理する方法です。原因の全体像を把握する際に役立ちますが、図に記載された関係が実際に成立しているとは限りません。

因果ループ図は、複数の要因が循環的に影響し合う構造を表現する方法です。例えば、設備故障が増えることで保全作業が増え、計画保全の時間が不足し、さらに故障が増えるというフィードバックの仮説を考えられます。

概念マップでは、原因だけでなく、目的、制約、依存関係、分類など、さまざまな種類の関係を表現できます。

これらの方法は、問題を単純な階層構造ではなく、要素間のネットワークとして理解する場合に役立ちます。

ただし、複雑な図を描くことが問題解決につながるとは限りません。関係の種類を明確にし、どの関係が観察された事実で、どの関係が未検証の仮説なのかを区別する必要があります。

代表的な問題構造化手法の比較

方法表現する構造得られる結果注意点
ロジックツリー階層・分解要素、原因候補、対策候補の一覧分類の漏れ、相互作用の見落とし
イシューツリー問いの階層調査すべき論点、判断事項最上位の問いが適切とは限らない
KPIツリー指標の階層・関係目標と指標の関係、改善対象候補計算関係と因果仮説の混同
プロセスマップ時間的な流れ・分岐業務手順、待ち時間、手戻りの位置記録されない実際の運用
特性要因図結果と原因候補要因の整理因果関係は別途検証が必要
因果ループ図相互作用・循環フィードバック構造の仮説定量的な効果は図だけではわからない
概念マップ概念間の多様な関係問題の意味的な構造関係の正確さは自動的に保証されない
SSM・SODAなど認識・目的・関係者の視点問題状況の再定義、行動案関係者の参加と解釈に依存する

重要なのは、これらの方法を優劣によって選ぶのではなく、何を構造化したいのかによって選択することです。

問題の定義自体を見直す ― Problem Structuring Methods

ここまで紹介した技法の多くは、ある程度定義された問題を分解したり、関係を表現したりするために利用できます。

しかし、現実には、問題の捉え方自体が適切でない場合があります。

例えば、「営業活動の効率を改善したい」という問題について、営業プロセスを詳細に可視化したとします。

その結果、営業担当者の作業時間や見積作成の手順を改善できるかもしれません。

しかし、本当の問題が「そもそも顧客が必要としていない製品を販売していること」であれば、営業活動を効率化しても根本的な改善にはつながりません。

このような問題では、最初に設定した問題そのものを見直す必要があります。

経営科学やORでは、こうした複雑で曖昧な問題を扱うためにProblem Structuring Methods（PSMs）が発展してきました。

代表的な方法には、ソフトシステム方法論（Soft Systems Methodology：SSM）、Strategic Options Development and Analysis（SODA）、Strategic Choice Approach（SCA）などがあります。

SSMは関係者の異なる世界観や目的を考慮して問題状況を検討します。SODAでは、関係者の認識を認知マップなどによって表現し、問題の関係を考えます。SCAでは、複数の意思決定と不確実性を整理し、行動の方向性を検討します。

これらの手法では、最初から唯一の正しい問題定義が存在することを前提とせず、異なる視点を比較しながら理解を深めることが重視されます。

この専門的な意味でのPSMsと、一般的なロジックツリーなどによる問題整理は区別できます。ただし、実務では両者の考え方を組み合わせることも可能です。

実践例 ― 研究開発テーマが見つからない

ある企業の研究開発部門で、「有望な新規R&Dテーマが見つからない」という問題があるとします。

この問題について、複数の構造化手法をどのように利用できるか考えてみましょう。

イシューツリーで調査すべき問いを整理する

最初に、何が不足しているのかを区別します。

研究テーマの候補が少ないのでしょうか。候補は多数あるものの、評価基準を満たさないのでしょうか。研究テーマが採用されても、実用化や事業化につながらないのでしょうか。

これらは異なる問題であり、調査するべき内容も変わります。

KPIツリーで結果を数量的に把握する

次に、研究テーマの提案件数、採択率、開発継続率、事業化率などの指標を整理できます。

例えば、テーマ提案件数は十分に多いのに採択率が低い場合、アイデアの数を増やすことだけが適切な対策とは限りません。

ただし、採択率が低い理由は、指標だけではわかりません。評価基準が厳しすぎるのか、提案の質に問題があるのか、開発予算が不足しているのかなどを調べる必要があります。

プロセスマップで研究テーマの形成過程を調べる

技術情報の収集から、テーマの提案、評価、採択、試作、開発継続の判断までの流れを可視化します。

どの段階に時間がかかっているのか、どこで候補が失われているのか、どのような判断が行われているのかを調べます。

例えば、研究テーマの提案後に事業部門の評価が行われるものの、評価基準が明確でないために何度も検討をやり直している可能性があります。

問題の捉え方を見直す

さらに、「技術情報が不足している」という前提そのものを考え直します。

既存の専門技術の範囲にテーマ探索が限定されていることが問題かもしれません。あるいは、テーマの候補は見つかっているものの、将来の市場や顧客との結びつきを評価できないことが問題かもしれません。

この場合には、単に情報収集量を増やすのではなく、異分野の技術や新しい用途を探索する方法、顧客の問題から必要な技術を考える方法などを検討することになります。

このように、異なる構造化手法を組み合わせることで、問題を分解するだけでなく、問題の定義自体を変える可能性が生まれます。

問題構造化と定性・定量の統合

問題構造化は、定性的な方法と定量的な方法を結びつける活動でもあります。

例えば、ロジックツリーによって問題の要素を整理することは、主に定性的な分析です。しかし、要素に測定可能な指標を対応させれば、数量的な分析へ進むことができます。

KPIツリーでは、数量的な指標を体系化できますが、どの指標が重要なのかを考えるには、事業の目的や顧客の価値についての定性的な理解が必要です。

プロセスマップによって業務の流れを整理した後に、実際の処理時間や待ち時間を測定すれば、ボトルネックを数量的に把握できます。

また、統計分析によって予想外の関係が見つかった場合には、問題構造を修正する必要があるかもしれません。

このように、問題構造化は、最初に一度だけ行う作業とは限りません。

問題の構造化 → 測定・分析 → 新しい発見 → 問題構造の修正という往復を通じて、問題についての理解を深められます。

問題構造化の限界

問題構造化は、複雑な問題の理解に役立ちますが、図や階層を作成すること自体が問題の解決を保証するわけではありません。

第一に、分類や分解は、作成者が何を重要と考えるかに依存します。ロジックツリーが整っていても、最初から考慮していない要素は含まれません。

第二に、階層的な分解では、要素間の相互作用や循環的な関係を十分に表現できない場合があります。

第三に、KPIツリーや因果ループ図で関係を描いても、それが実際の因果関係であるとは限りません。

第四に、問題構造を詳細化しすぎると、情報量が増えるだけで、何を判断するための分析なのかが不明確になる可能性があります。

さらに、問題の定義について関係者が合意したとしても、その定義が必ずしも適切であるとは限りません。

重要なのは、作成した構造を最終的な正解として扱うのではなく、新しい情報が得られたときに修正できることです。

AIによる問題構造化の支援

LLMは、自然言語で表現された問題を分解したり、関係を整理したりする作業を支援できます。

例えば、「新製品の売上が伸びない」という問題を入力すると、考えられる要素分解や原因候補を提案し、ロジックツリーの原案を作成できます。

また、KPIツリーの作成を支援し、必要な計算式や測定指標を提案できます。プロセスマップについても、業務手順を文章で入力することで、作業の順序や分岐の候補を整理できます。

さらに、異なる構造化方法で同じ問題を分析し、その違いを比較することも考えられます。

ただし、AIが生成した問題構造が正しいとは限りません。

LLMは一般的な業務や経営の知識に基づいて、それらしい原因や指標を提案できますが、対象となる企業や業務についての事実を確認したわけではありません。

したがって、観察された事実、関係者の意見、AIが提案した原因仮説、検証済みの関係などを区別する必要があります。

また、問題構造化をAIに支援させる際には、既存の分類を埋めるだけでなく、別の分解方法や問題の捉え方を提案できることが重要です。

ThinkNaviでの位置づけ

ThinkNaviでは、問題構造化を、問題発見と問題解決を結びつける方法群として位置づけます。

利用者が問題を入力した際に、最初から特定の手法を選ばせるのではなく、何を知りたいのかに応じて適切な方法を紹介する構成が考えられます。

例えば、問題の要素を整理したい場合はロジックツリー、調査するべき問いを明確にしたい場合はイシューツリー、業績の変化を分析したい場合はKPIツリー、業務の流れを調べたい場合はプロセスマップを選べます。

さらに、原因候補を考えたい場合には特性要因図、要素間の相互作用を調べたい場合には因果ループ図、問題の定義自体を考え直したい場合にはSSMなどの考え方を参考にできます。

これらの方法は、一部をThinkNavi Freeの手入力ツールとして実装することも考えられます。LLMを利用する場合には、問題の自動分解、異なる構造の提案、指標の対応づけ、分析結果を受けた問題構造の更新などが開発候補になります。

これらは今後の機能開発の方向性であり、現在すべてが提供されていることを意味しません。

問題構造化の目的は、必ずしも完成度の高い図を作ることではありません。最初に与えられた問題を分解するだけでもありません。

問題をどのように捉えるかによって、調査するべき情報も、利用する分析方法も、得られる解決策も変わります。問題構造化とは、問題を解く前に、そして問題を解きながら、何を問題として考えるべきかを明らかにしていく活動です。

関連ページ

参考文献・関連資料