顧客向けプレゼン資料の構成と作成例

六枚で判断までの道筋をつくる

冒頭に「次の試作で使うメニュー構成を決める」と書きます。担当者が知りたいのは、制作した順番ではなく、選ぶために必要な情報です。前回の合意と今回の検討範囲も短く確認しましょう。

好みを聞く前に比較基準を決める

この例の基準は、入口の分かりやすさ、担当者による更新のしやすさ、合意済みの掲載内容を整理できるかの三つです。クライアントが別案を好んだ後で、新しい基準を追加して結論を誘導しないようにします。

比較表は、根拠のない点数を付ける場所ではありません。未検証なら「試作で確認」と記します。案Aは目的を知っている人に説明しやすい一方、案Bは属性が重なる人をどう扱うかが課題になる、というように条件を説明します。

観察と提案を混ぜない

現在のページ構成で案内が重複していることは、ページを確認して示せます。しかし「利用者の大半が迷っている」と言うには、その主張を支える資料が必要です。担当者の懸念は、懸念として記載しましょう。

「利用者は案Bを好む」ではなく、「利用者区分から探す入口を試すため、案Bの試作を提案する」と書けば、まだ検証していない段階が伝わります。説得力を出すために、存在しない調査結果や成功率を足す必要はありません。

修正に使える質問を用意する

「気に入りましたか」だけでは、好みと要件が混ざります。「この手続きを探す人は、どの名称を使いますか」「この情報の更新は誰が担当しますか」と聞くと、判断基準に結びついた意見を得られます。

意見は、事実の訂正、必須要件、好み、追加提案に分けて記録します。担当者同士で意見が割れたら、合意したようにまとめず、対立点と判断する責任者を明確にします。会議中に解決できなければ、次回までの確認事項に残します。

AIへの依頼にも判断範囲を書く

依頼例は「この議事メモから、クライアント向けのレビュー資料を六枚で作成してください。判断対象は案内メニューの構成です。二案を同じ三基準で比較し、調査未実施の部分は仮説と明記してください。前回からの変更を示し、承認条件、担当者、次の確認事項で締めてください」です。

Syaxisで修正する場合も、「もっと説得力を出す」ではなく「案Bが支持されたという表現を削り、試作を提案する理由に置き換える」と指定します。事実の強さを保ったまま、説明を分かりやすくする修正です。

会議後に決定を反映した版を残す

決定事項をまとめたページは、実際に承認された内容に更新します。「案Aで進む。ただし予約情報の扱いは運営担当が確認する」のように、方向と条件を一緒に残します。会議前の推奨案だけを送ると、未決定の提案が承認事項として読まれるおそれがあります。

前回からの変更は「懸念、変更、残る確認」の短い記録にまとめます。承認済みの範囲を再検討する場合は理由を示してください。提出前にPowerPointを開き、読み手が会議に参加していなくても条件が理解できるか確かめます。

フィードバックを意思決定の記録に変える

架空のレビュー例として、クライアントが提案した構成案を受け入れ、公開日程の修正を求め、新しい対象者の追加を提案したとします。これはそれぞれ別の判断です。1つ目は承認済み、2つ目は事実関係の修正、3つ目はスコープの論点として記録します。単に「フィードバック」という1つの一覧にすると、3つとも必須のデザイン修正のように見えてしまいます。

初回提案の場では、課題認識と進め方への合意を取りにいきます。中間レビューでは、合意済みの要件に対して進捗を確認します。承認会議では、どの版を承認するのかと、まだ条件付きで残っている点を明確にする必要があります。その版と一緒に意思決定の記録も共有しておけば、後続の修正で何が受け入れられたのかが曖昧なまま変わるのを防げます。