提案書の冒頭に「業務効率化が課題」とだけ書いても、相手の仕事を理解した説明にはなりません。一方、AIがもっともらしい原因を補うと、相手が言っていない課題を提案の前提にしてしまいます。
課題整理では、要望、観察した事実、原因の仮説、提案する範囲を分けます。ここでは、提案書全体ではなく、最初の数段落を作る工程に絞ります。
「してほしいこと」と「起きていること」を分ける
架空の例として、顧客から「FAQをAIで作りたい」と相談されたとします。これは要望であり、なぜFAQが必要かという原因の説明ではありません。
| 要素 | 入力例 |
|---|---|
| 要望 | よくある質問への回答をAIで用意したい |
| 観察した事実 | 同じ質問への回答を、担当者が個別に作っている |
| まだ不明なこと | 質問件数、回答の違い、既存文書の状態 |
| 原因の仮説 | 現行の回答を共有する場所が決まっていない可能性 |
| 今回の候補 | 質問と根拠資料を整理し、回答案を試す |
既存のFAQがないのか、あっても探しにくいのかで、必要な作業は変わります。AIを使うことを先に固定せず、課題の説明から確認します。
仮説には、確認方法を添える
原因の仮説を提案書に書く場合は、何を見れば確かめられるかも示します。「資料が分散していると考えられるため、担当者が参照する場所と更新日を確認する」と書けば、次の作業につながります。
「属人化が深刻」「対応品質が低い」といった強い表現は、根拠がなければ避けます。相手の仕事を評価する言葉より、観察できる状態を記述する方が、認識を合わせやすくなります。
AIへ渡す指示例
あなたは提案書の編集担当です。商談メモから課題整理の下書きを作ってください。
出力：相手の要望／確認済みの事実／原因の仮説／追加質問／提案範囲
各項目に根拠の発言を付け、仮説には確かめる資料や質問を添えてください。
その表を使って課題整理の一段落を書き、未合意の目標は提案として区別します。
入力にない件数・時間・損失額を加えないでください。
生成した後は、主張の横に元の発言や資料名を置きます。出典を示せない文は、仮説に移すか削除します。
提案書の文章にする例
現在、同じ内容の質問に対して、担当者ごとに回答を作成されていると伺いました。まず、質問の種類と回答に使う資料を整理し、共通化できる範囲を確認します。そのうえで、担当者が確認して使う回答の下書きを試します。質問件数と確認時間は、試行前に記録します。
これは架空の例文です。「AIで何％削減」といった未確認の効果を加えず、対象と手順を説明しています。
相手と確かめるための一文を残す
課題の章を作ったら、「この理解と異なる点があれば教えてください」と確認できる形にします。相手が訂正した内容は、後の見積もりや評価条件にも反映します。最初の仮説を提案書の完成後まで固定しないことが、提案のずれを減らします。
必要な資料の集め方は提案書の準備ガイドを参照してください。
課題の仮説を、次のヒアリングで確かめる
「FAQを作りたい」という要望があっても、質問が多い原因が資料不足とは限りません。資料を探せない、担当部署が分からない、例外判断が多いなど、別の可能性を残します。
| 仮説 | 確認する材料 | 提案を変える条件 |
|---|---|---|
| 回答の原本がない | 実際の質問と参照資料 | まず回答内容の整理が必要 |
| 原本はあるが見つからない | 検索・案内の流れ | 資料の入口と分類を整える |
| 部署で回答条件が違う | 利用者の所属と適用条件 | 一つの回答へ統合しない |
| 個別判断が多い | 例外の件数と判断担当 | FAQより相談の振り分けを整える |
AIには、要望に沿った解決策を一つ作らせる前に、複数の仮説と確かめる材料を出してもらいます。どの仮説が採用されたかと、その根拠を残してください。「AIを使うこと」を先に確定せず、既存資料の整理だけで改善できる範囲も提案の候補になります。
提案の課題文がいつも抽象的になるなら、確認できた事実と追加で聞きたいことを分けて、提案準備の業務整理を相談する材料にできます。