クライアントの依頼書からコンサルティングの説明資料を作るときは、まず確定している条件と、これから確認する事項を分けます。次に、業務範囲を左右する要望の食い違いを示し、実質的に異なる2つの進め方を比べます。成果物や日程を並べる前に、見積もりに必要な判断をクライアントに求めるのが順序です。
ここで作るのは最終提案書ではなく、業務範囲をすり合わせるための説明資料です。何を依頼し、どこまで対応するかを双方で確認します。方向性が固まったら、Presentiの営業・提案資料作成を使い、次回の打ち合わせに向けた編集可能な下書きを準備できます。以下は架空の例です。元の依頼内容と、まだ答えの出ていない質問を最後まで対応づけて進めます。

キーワードだけでなく、何を約束することになるかを読む
ある卸売会社から、次の依頼が届いたとします。
「見積書の作成に時間がかかりすぎています。CRMは入れ替えず、6週間で3か国のチームの手順を統一したいです。営業は依頼時の情報不足が原因だと言い、業務部門は承認待ちが問題だと言っています。現状を示す信頼できる測定値はありません。担当者が参加できるのは週1回、30分の打ち合わせです。」
これをそのまま「3か国の見積もり業務を6週間で効率化する」とまとめると、一見わかりやすい資料になります。しかし、希望納期を納品の約束に変え、異なる2つの見立てを確定した診断として扱ってしまいます。
依頼書は2回読みます。1回目は、求める結果と制約を抜き出します。2回目は、答えが変われば方法、工数、約束の内容が変わる箇所に印を付けます。自分たちの解釈の隣に依頼書の原文を残すと、どこに判断や仮定が入ったかがわかります。
条件、希望、未確認事項を分ける
| 依頼書の記述 | 位置づけ | スライドに載せる内容 |
|---|---|---|
| CRMを入れ替えない | 明示された制約 | 既存システム内で対応する。設定変更を承認できる人を確認する。 |
| 3か国のチームで手順を統一 | 希望する結果。合意済みの業務範囲ではない | どの工程を共通化し、どの工程は各国に残せるかを聞く。 |
| 6週間 | 希望する期間 | 提言の提出、試行の完了、全面展開のどこまでを指すかを確認する。 |
| 情報不足、または承認の遅さ | 検証する2つの仮説 | 両方を示し、具体例を見る前に原因を決めない。 |
| 信頼できる現状値がない | 不足している資料 | 日時と承認工程がわかる、直近の見積もり事例を数件依頼する。 |
同じ言葉に複数の意味があるときほど、この区別が重要です。「標準化」は、入力項目の統一かもしれませんし、承認ルールの共通化、あるいは全工程の統一かもしれません。考えられる意味を書き出します。曖昧さを隠した断定的なスライドより、具体的な確認質問のほうが役に立ちます。
業務範囲の食い違いを資料の中心に置く
この例で難しいのは、3つのチーム、6週間、限られた協力時間、現状値なしという条件の組み合わせです。クライアントの要望を無理だと責めるのではなく、実行可能にするために何を変える必要があるかを示します。
見出しは、たとえば「作業計画の前に、6週間後の到達点を決める」とします。その下に「診断」「試行」「全面展開」の3つを横並びにします。必要なのは単純な順序図です。クライアントが本当に必要とする到達点を明示し、残りはその後の作業として分けます。すべてを一度に約束する形にしないことが大切です。
続けて、判断につながる質問をします。「試行を終えることが優先なら、1か国のチームから事例と確認担当者を提供できますか」。これなら、必要な協力と選択肢が結びつきます。「追加情報をください」だけでは、その関係が伝わりません。
異なる不明点を解消する2つの進め方を比べる
名前だけが違い、中身がほぼ同じ3つのプランを出す必要はありません。この依頼なら、意味のある選択肢は次の2つです。
- 先に診断する:3つのチームの直近の見積もり工程を調べ、主な遅延箇所を確認して、共通手順を提案する。成果物は提言と優先順位を付けた変更案であり、運用開始済みの仕組みではありません。
- 1チームで試行する:1か国のチームを選び、見積もり工程の限られた変更を試し、その結果から展開範囲を決める。事例へのアクセスと確認担当者が必要です。また、同じ変更が3チームすべてに適することまで証明するものではありません。
必要な資料へのアクセス、参加する人、具体的な成果物、残る不明点で比較します。評価項目や点数の意味について合意していない段階で、数値評価を付けないようにします。工数を見積もる情報が足りなければ、費用の提示は次の段階に残します。
未決定事項を軸に6枚のスライドを組む
| スライド | 見出しの例 | 示す内容 |
|---|---|---|
| 1 | 「6週間で完了」は、どこまでを指すか | 今回決めることと、3つの到達点。 |
| 2 | システムの条件は決まっているが、解決策は未定 | 確定条件と未確認の要求を並べる。 |
| 3 | 2つの原因仮説には、異なる資料が必要 | 情報不足と承認遅延の仮説、それぞれを調べる事例の依頼。 |
| 4 | 診断から始めるか、1チームで試すか | 2つの進め方、成果物、前提条件、限界。 |
| 5 | 試行は3か国への全面展開ではない | 対象に含む作業、含まない作業、クライアントの協力事項。 |
| 6 | 進め方、確認担当者、提供できる事例を決める | 業務範囲と費用を詰める前に必要な3つの回答。 |
依頼書の全文は付録か添付資料に残します。本編で繰り返すのは、選択の理由がわかる表現だけです。短い引用の隣に解釈を置けば、クライアントが依頼書を全部読み直さなくても、認識の違いを見つけられます。
AIには曖昧な点も渡し、勝手に埋めさせない
組織の規則に従って利用できる形に依頼書を整えます。議論に不要な機密の名称や案件情報は取り除きます。そのうえで、下書き作成ツールに具体的な指示を渡します。
架空の卸売会社を対象に、業務範囲をすり合わせる6枚の説明資料を作成してください。顧客はCRMを入れ替えず、6週間で3か国のチームの見積もり手順を統一したいと考えています。打ち合わせは週1回30分のみです。営業は依頼情報の不足を、業務部門は承認の遅さを原因と考えています。信頼できる現状値はありません。確定条件、仮説、未解決の質問を分けてください。先に診断する方法と、1チームで試行する方法を比較してください。費用、削減効果、日付、事例の証拠、優先する原因を創作しないでください。6週間は希望期間であり、納品の確約ではありません。最後に、進め方、顧客側の確認担当者、事例へのアクセスについて判断を求めてください。
見た目を整える前に、構成を読みます。「見積もり時間を40%削減」という見出しが生成されたら、依頼書で裏づけられる「変更内容を決める前に、見積もりが遅れる工程を特定する」に置き換えます。前者は結果の創作ですが、後者は会議の目的になります。
打ち合わせの回答を業務範囲に落とし込む
クライアントが1チームでの試行を選んだものの、個別の見積もり記録は提供できないと答えたとします。この回答は作業内容を変えます。業務を観察する時間を設けるか、別の出発点が必要かもしれません。日程表の下に隠してよい細部ではありません。
打ち合わせ後は、選んだ進め方を更新し、不足している資料と、それを用意する担当者を記録します。それから成果物、責任分担、費用を具体化します。役に立つコンサルティングの説明資料は、こうした選択を明確にします。不完全な依頼書を、完成した計画に見せるためのものではありません。