誰・何から得た情報か
情報源・根拠管理
発言や資料の記述を、情報源・主張の種類・確認状態の3軸で記録する。
EVIDENCE MODEL
「何が書いてあるか」だけで事実扱いしない
案件資料には、顧客が述べた事実、仲介者の要約、原因の解釈、解決案、受託側の推測が混在します。これらを一つの「確からしさラベル」へ押し込まず、3つの問いで分けます。
事実、仮説、要望、要件のどれか
どこまで裏付け・合意されたか
3軸は独立しています。顧客本人の直接発言でも未確認の解決仮説はあり、仲介者の要約でも後から根拠確認済みにできます。
SOURCE
情報源 — 誰・何から得たか
出所は信頼度の点数ではありません。次に誰へ確認すべきか、どの文脈が欠けているかを判断するために記録します。
顧客本人の直接発言
商談・メール等で本人が述べた内容。役割と決定権も併記する。
現場担当者の直接発言
実務の事実や例外に近いが、組織決定とは限らない。
仲介者による要約
紹介会社や別部署が編集した情報。原文・話者・文脈を再確認する。
文書・既存資料
報告書、仕様書、規程、議事録。作成者と更新日を残す。
実データ
件数、時間、ログ、見積、BOM、原価など。抽出条件も残す。
業務観察
現場同席や操作観察で確認した内容。観察範囲と例外性に注意する。
提案側
受託側の分析・解釈・推測。顧客情報と混ぜず、仮説として扱う。
CLAIM TYPE
主張の種類 — 何についての記述か
特に「原因仮説」「解決仮説」「要望」「正式要件」を分けます。具体的に書かれていることは、正式要件である証拠にはなりません。
業務事実
誰が、何を、どの頻度・時間・条件で行っているか。
課題認識
何を問題と感じ、誰にどの影響があると捉えているか。
解釈・原因仮説
なぜ起きているかについての説明。事実とは分ける。
解決仮説
AI化、連携、自動化など、問題を解くための案。
要望
欲しい機能・状態。背景や優先度が未確認でも存在する。
正式要件
決定権者が対象・優先度・制約を含めて合意した条件。
制約
法令、期限、予算、既存契約、技術、運用上の動かせない条件。
VERIFICATION
確認状態 — どこまで使えるか
成熟度の段階ではなく、個々の情報を提案条件へ使う際の状態です。必要に応じて戻したり、関係者ごとに差分を残したりします。
未確認
出所は分かるが、内容・背景・根拠をまだ確かめていない。
本人確認済み
話者本人へ意味と文脈を確認した。
根拠確認済み
資料、実データ、観察など裏付けを確認した。
複数関係者確認済み
異なる役割の関係者間で認識の一致・差分を確認した。
顧客合意済み
提案や意思決定に使う条件として、顧客側で合意された。
CLASSIFICATION EXAMPLE
「AIが必須」を正式要件へ昇格させない
「AIが必要な部品を判断する機能が必須」
情報源仲介者による要約
顧客本人の原文・発言文脈をまだ確認していない。
主張の種類解決仮説
課題を解く手段の案であり、業務事実や原因ではない。
確認状態未確認
決定権者の合意、代替案との比較、データ面の成立性が未確認。
この時点での扱い
提案書の必須機能には入れない。顧客本人へ目的と利用場面を確認し、実務担当者へ判断プロセスを確認したうえで、解決仮説として比較対象に残します。
OPERATING RULES
記録から次の確認へつなげる
- 01原文を残す
要約する前の発言・記述と、日時・話者・資料名を記録する。
- 023軸を別々に付ける
情報源、主張の種類、確認状態を一つのラベルにまとめない。
- 03根拠と反証を残す
裏付けだけでなく、矛盾する発言や例外も紐付ける。
- 04次の確認先を決める
誰に、何を、どの資料・実例で確かめるかを書く。
- 05提案条件へ昇格させる
必要な確認と合意を得た情報だけを、スコープや見積りの前提に使う。