論点整理のやり方｜事実・問い・判断を分けて会議の迷走を止める
会議で案はたくさん出るのに、どれを選ぶべきか分からない。解決策の議論に入る前に、答えるべき問いが共有されていない可能性があります。論点整理では、事実、答える問い、必要な判断を分けます。網羅的な分類表を作ることより、次の調査や意思決定が決まる形へ分解することを目指します。
問題・論点・解決策を区別する
問題は現状と目指す状態の差、論点はその差を扱うために答える問い、解決策は問いに対して選ぶ行動です。例えば「問い合わせ対応の負担が大きい」は問題の候補、「どの問い合わせが負担を生むか」は論点、「FAQを追加する」は解決策の候補です。最初からFAQを増やす前提にすると、別の原因を調べにくくなります。現状が測定されていない場合は、それを事実として示します。「多い」「遅い」を全員共通の認識として扱わず、比較対象や範囲を確認します。
大きな問いを判断につながる問いへ分ける
社内システムの問い合わせを減らす説明用の例です。
| 大きな問い | 分けた問い | 必要な確認 |
|---|---|---|
| どこに負担があるか | どの種類・利用者・時点に集中するか | 問い合わせ分類、対象期間、件数と対応時間 |
| なぜ起きるか | 案内不足か、操作の問題か、権限の問題か | 実際の操作、案内の所在、例外条件 |
| 何を変えるか | 案内・画面・運用のどれを変更するか | 効果見込み、制約、担当範囲 |
| どう確かめるか | 同じ条件で変化を確認できるか | 分母、期間、別の変更の有無 |
原因を確認する前に、利用者の注意不足などと決めつけないことが重要です。解決策は複数の仮説を確認した後に比較します。
事実・仮説・未確認を別の印で管理する
確認済みのログ、聞き取りによる発言、分析者の解釈を分けます。誰かが「いつも」と言っただけでは、全期間の件数を確認したことにはなりません。各論点には、現時点の答え、根拠、未確認、判断への影響を記載します。根拠が弱いものは保留できる状態にし、表を埋めるために断定しないようにします。反対意見がある場合は、何の事実や条件で意見が違うかを確認します。人物ごとに主張を並べるだけでは、次の調査へ進めません。
網羅性より使える境界を確認する
分類が重なるなら、対象の境界を定義します。ただし無理にすべてを一つの分類へ入れる必要はありません。複数原因の案件は、集計で二重計上しないルールを決めます。細分化しても判断が変わらない問いは、今回の調査から外せます。興味があるだけの調査と、意思決定に必要な調査を分けてください。制約も先に確認します。予算や変更可能な範囲が決まっているなら、その範囲で答える問いを設計します。制約そのものを見直す必要があれば、別の判断として上位者へ相談します。
次に確認する三つの問いへ絞る
整理後には、重要度と不確実性から優先する問いを選びます。「すべて調べる」ではなく、判断が変わりそうなもの、早く確認できるもの、後続作業の前提になるものを選びます。各問いに担当、確認方法、期限、結果の保管先を付けます。会議に持ち込む際は「何を報告するか」だけでなく「どこを判断してほしいか」を示します。問いへの答えが揃ったら、次の問いか選択肢の比較へ進みます。論点整理を続けること自体が目的にならないよう、調査の終了条件も決めておきましょう。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
解決策を決める前に問題を明確にする考え方を確認しました。問いの分解と業務例は独自です。 Atlassian：Problem Framing（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
背景と目的の違いも必要な作業に合わせて参照してください。
アイキャッチ写真：Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。
