問題解決フレームワーク｜課題管理・仮説思考・原因分析の六つの手法

問題解決フレームワークは、現状と目標の差を定義し、原因の仮説を確かめ、対応と結果の確認につなぐための道具です。ロジックツリーを作ることや「なぜ」を繰り返すことだけでは、原因が正しいと証明されたことにはなりません。本記事では、課題管理・仮説思考・原因分析で使う六つの手法を、根拠と判断を区別して使う方法に整理します。

問題を定義し、ロジックツリーと課題空間で調べる範囲を決める

まず「何が、いつ、どの対象で、どの状態と比べて困っているか」を記述します。「売上が悪い」だけでは、対象商品、期間、売上の計上方法、比較先が定まりません。「対象商品の受注金額が、同じ集計条件の目標を下回った」と書き、実績と目標の取得元を示します。目標そのものが現実的だったか、集計方法が変わっていないかも確認対象です。

本稿では、①What：差を定義する、②Where：差が大きい場所を絞る、③Why：原因の仮説を検証する、④How：対応と評価方法を決める、という四段階で整理します。これは実務の整理例で、必ず一方向に進む手順ではありません。調査で対象の定義が変われば戻ります。障害など被害の拡大を止める必要がある場合は、暫定対処を先に、または原因調査と並行して行い、恒久対応と区別して記録します。

手法1：ロジックツリーは、同じ意味の数字と比較条件で分解する

ロジックツリーは、問題を枝に分けて調べる方法です。McKinseyの2019年の対談では、問題定義、論理的な分解、重要性と変えられる範囲に応じた優先順位付けが説明されています。特定の分け方をすべての案件へ当てはめるのではなく、調査対象を明確にするために使います。McKinsey：構造化された問題解決の対談

例えば、ここでいう売上を対象期間の「受注金額」と定義すれば、受注件数×平均受注額へ分けられます。会計上の売上や入金額とは区別してください。さらに対象機会数×契約率×平均受注額で見る場合、同じ機会群の契約結果を追い、観測期限も揃えます。当月の問い合わせ数と、過去の問い合わせから生じた当月受注をそのまま掛け合わせる方法は避けます。

調べる枝	確認する事実	直ちに原因としないこと
機会の量	同じ定義の対象件数、経路、計測漏れ	広告単価の上昇だけで機会減少と断定する
契約への転換	同じ対象群の契約・失注・未決着と観測期限	担当者の説明不足だけに結び付ける
受注単価	商品構成、数量、値引き、取消の扱い	件数が同じなら受注金額も同じとみなす

数式による内訳の関係と、原因の関係も分けます。契約率が下がった事実だけでは、提案資料、価格、顧客構成のどれが原因かは決まりません。枝に仮説と確認する資料を付け、説明できない例や別の要因も探します。指標の分母や目標との関係は、KPI・KGIの違いとKPIツリーの設定方法で具体化できます。

手法2：課題空間の設計で、見落としと重複を点検する

本稿の「課題空間」は、業務や機能、工程などの軸を置き、どこを調べたか示す整理方法です。①対象と期間を決める、②工程・機能などの軸を選ぶ、③境界や例外を点検する、④根拠と課題を対応付ける、⑤状況の変化で見直す、という五段階を提案します。公的な共通規格や、課題を必ずすべて発見できる方法という意味ではありません。

MECEは、分類の重複や抜けを点検する考え方として使います。例えば「営業・開発・その他」で区切ると部署間の引き継ぎが見えにくいため、受け渡しと例外処理も確認します。現実の原因が複数の工程にまたがる場合には、関連を消さずに課題を相互参照します。表計算、課題管理ツール、文書のどれを使うかより、対象範囲と未確認の場所を共有できることが大切です。

仮説思考・なぜなぜ分析・SWOT・PDCAを根拠の確認につなぐ

手法3：仮説思考は、結論の先取りと区別する

仮説は「この条件が影響しているのではないか」という暫定的な説明です。候補ごとに、支持する事実、反する事実、未確認事項、次に見るデータを並べます。「おそらくレビュー不足」と考えたなら、レビューの実施記録と指摘内容、欠陥が混入した工程を調べます。都合のよい記録だけを集めず、レビュー済みでも問題が起きた案件との違いを確認してください。

事実と考察の配分に一律の割合は置きません。必要な調査量は、判断を誤った場合の影響、期限、やり直しやすさによって決めます。また、「過去の案件の10％で遅延した」ことから「工程に10％の日数を追加すれば十分」とは導けません。前者は件数の割合、後者は期間の割合であり、遅延した日数や工程の依存関係が不明だからです。これは単位の異なる情報を混ぜないための例で、遅延率の実績値ではありません。

検証では、何が起きれば仮説を支持し、何が起きれば見直すかを先に決めます。「資料を変えたら受注が増えた」だけでは、顧客構成や季節性の変化を切り分けられないことがあります。比較対象、測定期間、対象外の条件を記録し、結果を適用できる範囲を示しましょう。AIやDXの試行に落とす場合は、PoCの仮説・評価基準と本番移行の設計が、検証後の判断まで整理する手がかりになります。

手法4：なぜなぜ分析は、回数より各段のつながりを確かめる

なぜなぜ分析では、起きた事象に対して理由を掘り下げます。ASQはFive Whysについて、原因や解決策に至るまでの質問が五回より少ない場合も多い場合もあると説明しています。五回答えれば原因が証明される、という達成条件にはしません。ASQ：Five Whys and Five Hows

例えば「テストが遅れた→欠陥の修正が増えた→レビューに抜けがあった→予定に確認工程がなかった」は、説明用の仮説の連鎖です。欠陥の発生時期、レビューの対象、実際の作業予定を照合する前に、最後の項目を根本原因と確定しないでください。要件変更、環境の問題、見積もり条件など別の枝があり得ます。「注意不足」で終えず、確認方法や承認条件をどう変え、同じ問題をどう検知するかまで検討します。

手法5：SWOTは、内外の条件を並べた後に判断する

SWOTは、内部の強み・弱みと、外部の機会・脅威を整理する枠組みです。Business Queenslandも、SWOTだけで課題に優先順位が付いたり、解決策が選ばれたりするわけではないと説明しています。項目には確認した事実を添え、目標への影響、対応可能性、費用や制約を別途検討します。Business Queensland：SWOTの使い方と限界

手法6：PDCAは、試して学んだことを次の対応へ戻す

PDCAはPlan・Do・Check・Actの循環です。ASQの説明に沿えば、変更を計画し、小さく試し、結果を分析し、学んだことに基づいて対応します。試験に成功したら適用範囲を検討し、失敗したら計画を見直します。報告会を繰り返すだけでなく、測定結果と変更内容を残しましょう。原因分析の方法や成功基準は別に設計する必要があります。ASQ：PDCAの手順

課題候補の整理を日次の処理へ組み込む場合は、PMOエージェントの多ソース統合と検証・通知の実装パターンも参照できます。Slack・議事録・タスク・カレンダーの取得範囲、ルールとLLMの分類、根拠や重複の確認、通知後に人が判断する流れを分け、仮説の整理だけで課題を確定・解消扱いにしない方法を説明しています。

課題管理表で対応を追い、AIの出力を確認可能な材料として使う

分析した内容を実行へ移すには、「解きたい課題」と「行う作業」を対応付けます。本稿では、課題を未解決の差や判断事項、タスクを具体的に行う作業、TODOを作業上の小さな項目として整理します。用語は組織で異なるので、同じ表を使う場合も種類の列や関連IDで区別します。タスクは最初の計画だけで決まるものではなく、調査や変更によって追加される場合があります。

記録の種類	説明用の例	管理する内容
課題・判断事項	必要な利用許諾の有無が未確認で、公開可否を決められない	影響、根拠、判断する人、期限、解消条件
対応タスク	利用条件を調べ、必要な確認を依頼する	担当、成果物、期限、依存する作業
TODO	確認用の資料を指定の場所へまとめる	所属するタスク、実施者、完了の確認

同じ管理表に入れること自体を禁止する必要はありません。ただし、資料を送っただけで公開可否の課題を解消扱いにするような、作業完了と判断完了の混同を避けます。対応担当と判断者が違う場合は両方を記載します。期限を過ぎた項目を並べ直すだけでなく、何が確認待ちなのか、どこまで影響するのか、誰へ判断を求めるかを明確にします。

課題から、根拠・対応・結果までを一続きにする

課題ごとに、現象、期待する状態、原因の仮説、根拠への参照、暫定対応、恒久対応、確認期限を揃える方法が考えられます。対応後には、実施した証跡だけでなく、目標との差がどう変わったかも確認します。解消しなかった場合は、実施が不十分だったのか、原因の仮説が違ったのか、測り方に問題があったのかを分けて再検討します。

すべての項目を同じ頻度で確認する必要もありません。影響の大きさ、期限までの余裕、依存する工程に合わせて確認日を設定します。緊急の暫定対処をした案件は、原因の検証や恒久対応が残っていることを表示し、対処済みだけで記録を閉じない運用にします。完了・保留・中止のいずれも、判断した理由を後から追える形にしておきましょう。

AIは原因候補や要約を作り、人が根拠と適用範囲を確認する

AIを使う場合は、原因候補の列挙、分類案、議論の要約、課題と対応の対応付けなど、確認可能な出力へ用途を絞ります。入力には観測した事実と未確認の仮説を分けて示し、「各候補を検証する資料」「反証になり得る条件」「不足している情報」も出すように依頼します。もっともらしい説明が出ても、実際の因果関係や担当者の判断を代替したとは扱いません。

利用するサービスについて、入力してよい情報、権限、保存・利用条件を確認し、必要以上の個人情報や機密情報を渡さないようにします。元の記録に戻れる参照と人の確認を残し、自動で担当や期限を決めたり、課題を完了扱いにしたりする範囲は別に定めます。本稿は特定製品のプランや自動化機能の利用を前提とせず、実際の機能・契約条件は導入時に確認してください。

日々の習慣としては、①事実と仮説を別に書く、②反する例を探す、③対応と成果の確認を結び付ける、の三点から始められます。回数や様式を守ることより、未確認の点を共有し、次の判断に必要な情報を集められることを重視します。

部署ごとに課題の捉え方が異なる、優先順位が決まらない、分析後の実行や成果確認が続かない場合は、renueのコンサルティングで、課題定義と優先順位付け、経営・現場の合意形成、実行計画・KPI設計、成果レビューの進め方を相談できます。フレームワークの作成そのものを目的にせず、何を判断し、誰がどう実行するかを具体化します。