クライアントの依頼書からコンサルティングの説明資料を作るときは、まず確定している条件と、これから確認する事項を分けます。次に、業務範囲を左右する要望の食い違いを示し、実質的に異なる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チームすべてに適することまで証明するものではありません。
必要な資料へのアクセス、参加する人、具体的な成果物、残る不明点で比較します。評価項目や点数の意味について合意していない段階で、数値評価を付けないようにします。工数を見積もる情報が足りなければ、費用の提示は次の段階に残します。
得られる成果物と、各案で扱わないことを並べる
卸売会社の依頼なら、次のように比較できます。これは話し合いのために提案する範囲であり、納品の確約や費用見積もりではありません。
| 比較する範囲 | 先に診断する | 1チームで試行する |
|---|---|---|
| 答える問い | 3チームの見積もり依頼はどの工程で止まり、何が原因と考えられるか。 | 特定の変更を、選んだチームの日常業務で実行できるか。 |
| クライアントの協力事項 | 各国の比較可能な直近事例と、記録された日時を説明できる担当者。 | 1チームの合意済み事例、現地の確認担当者、選んだ変更を試す許可。 |
| 提案する成果物 | 文書化した工程比較、不足する根拠、変更案。 | 範囲を定めた試行、観察結果、次の検証や展開についての提言。 |
| 含まないこと | 選んだ変更の実装や、その変更による業績改善の証明。 | 3チームへの全面展開や、一部の結果を全体に当てはめられると証明すること。 |
| 費用見積もりを出せない条件 | 記録にアクセスできるか不明、または見積もり工程の開始・終了の定義がそろわない。 | 確認担当者や試行の許可がなく、結果を観察する方法も決まらない。 |
表の上には「希望期間は6週間」と残します。希望納期があるからといって、前提条件を隠してはいけません。クライアントが参加できるのが週1回30分だけなら、会議外で誰が記録を用意するか、判断が出るまでどの程度待てるかを確認します。週1回の会議を6回行っても、会議時間は計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か国のチームでの試行を選び、匿名化した直近事例を提供すると合意したとします。最後のスライドには、次のように短く書けます。
提案する作業:対象チームの現在の見積もり工程を文書化し、試す変更を1つ決め、観察結果を指定の確認担当者と検討する。クライアントは、適切な事例記録へのアクセスと、試行を承認できる担当者を確認する。成果物は試行の結果と提言であり、3か国への全面展開は含まない。6週間の日程は、資料へのアクセス、確認担当者の都合、試行範囲が合意されるまでは暫定とする。CRMの入れ替えは対象外とする。
続いて、提案した作業が完了したと確認できるものを決めます。合意した工程の説明、何を変えたかの記録、試行で得られた観察結果、結論を出せなかった点の説明などです。見積もり作成時間を何%短縮すると保証することとは違います。適切に試行した結果、変更を広げるべきではないと分かる場合もあります。
承認後、この記載に別の国、新しいシステム連携、追加の成果を黙って含めないでください。費用を見直す前に、新しい依頼によって必要な資料や作業がどう変わるかを示します。同様に、会議中に反対がなかっただけで、未回答の前提条件をクライアントが承諾したと扱ってはいけません。
打ち合わせの回答を業務範囲に落とし込む
クライアントが1チームでの試行を選んだものの、個別の見積もり記録は提供できないと答えたとします。この回答は作業内容を変えます。業務を観察する時間を設けるか、別の出発点が必要かもしれません。日程表の下に隠してよい細部ではありません。すでに範囲が承認されている場合は、約束事項を黙って書き換えず、プロジェクトの変更要求として新しい要件と承認済み計画の差を示します。
打ち合わせ後は、選んだ進め方を更新し、不足している資料と、それを用意する担当者を記録します。それから成果物、責任分担、費用を具体化します。役に立つコンサルティングの説明資料は、こうした選択を明確にします。不完全な依頼書を、完成した計画に見せるためのものではありません。合意した試行案を説明するときは、問題・解決策・根拠の順に組み立てる構成で、例から分かることと試行で確かめることを分けられます。