くろいぬの矛盾メモ

旧・はてなダイアリーから移行しました。現在は「モフモフ社長の矛盾メモ」 をたまーに更新しています。

プレゼン資料作成テクニックのまとめ(企画書、提案書など)


元ネタ、というかフォーマットを借りました。文系の方向けに。

プログラミングテクニックのまとめ - プログラミング日記
http://d.hatena.ne.jp/morchin/20080922#p1

とりあえず思いついたもののまとめ。
クライアント向け提案書、社内向け企画書に関わらず有効なものを。


まずは、ベーシックなものから。


  • 議論のスコープ(論点)をなるべく狭くしろ

最小単位なら、1ページ1メッセージ原則。資料全体なら、1提案1ゴール原則。他は利害関係の異なるプレイヤーを同時に口説こうとするな(提案フェーズを分けろ)とか、押し付けをせずに顧客からヒアリングしたニーズを第一に意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係するポイントは、経営面でのメリットだけに終始して話を決裁者に通す担当者のメリットを忘れると前に進めない、まず多少不恰好でも与件定義(オリエンテーションやヒアリング内容をまとめると、解決すべき課題はこれですよね、という確認)が大事、など。


  • 同じメッセージの紙(ページ)を2度以上作るな

要は過去資料からコピペをしろ、統計データ+メッセージは万能、など。自分の場合、使いまわしだけでなく特化した方が顧客へのコミットメントが明確になる場合(重要な顧客の場合)、新しく書いたり、かなり加筆することもある。特に、遷移イメージ図、運用体制図など、個々の事例によって微妙に異なる図の場合、各要素の名称まで汎用的な内容でわざわざ無難にまとめて、それを元に説明するのは本末転倒。何度も使う紙の場合、顧客名などを「●#顧客名#●」などと記して全置換できるようにテンプレ化しておくのも良い。


  • 提案ストーリー内でのわき道への分岐を減らせ

他は主となるストーリーだけで最後まで貫け、既存のスキーム同士を無理に組み合わせるな、など。わき道への分岐は論点がブレるだけでなく、資料の汎用性を損なう原因にもなる。もしくは、1つの提案ストーリーやスキームの中に2つ以上のゴールや目的が混ざってしまっていて、きちんと絞り込めていない証拠。
テクニックとしては、中心となる訴求内容をストーリーにまとめた場合、その他の参考資料は、別資料か巻末にまとめて追い出す。「参考資料」、「再掲」、「別表参照」などの見出しを利用して、顧客の視点がストーリーを外れることを防げる。



次に、自分のセンスや主観的なもの。


  • Simple is the best

他はKISS原則(Keep It Simple, Stupidなどの略)、パレートの法則(80:20の法則)など。私のプレゼン・提案資料作成における座右の銘である。提案資料は初稿を作る時間より、読み返して図を整えたり微修正を加える時間の方が何倍も多いと言われている。誤字脱字や概念図の間違いなどは論外だが、細かい図のクオリティや色合いの統一などに時間をかけても、効果は薄い(大企業、アパレル系など、資料としての美しさを重視するクライアントもいるが、提案初期は叩き台で問題ないだろう)。
少し話はズレるが、仕様書、一覧表、テンプレート、リストなどの実務資料が重要になる実装フェーズでは、サマリー的な資料よりも実務担当者が使う情報を漏らさず全部入れた詳細な資料の方が重要になると思われる。もちろんExcelの添付など、用途に応じてファイルを分けたり最適な形式を選ぶのが重要。

  • オープン化(汎用資料化)の原則

よくナレッジマネジメント指向の原則みたいに書かれているが、ナレッジ蓄積の目的に限らず、提案資料は基本的にそうあるべきだと思う。ただし汎用性を最重要視して、顧客別のカスタマイズを行わないのは本質的ではないとも思う。ページを追加するたびに既存のページのストーリーを修正しないといけないのは、全体のストーリーが複雑になっている証拠。もしそういう傾向があるならページ追加のたびに資料全体の複雑さもうなぎのぼりに上がっているはず。基本的に、ページ追加はなるべく別表的なアプローチで行えるべき。すなわち別表化や参考資料化。


  • ケースバイケース

他は、バランスの問題、など。こういう言葉は嫌いだが、ほとんどのケースにおいては、発表する人のキャラクターも影響するし、ケースバイケースであると思う。100%守るべき原則というのは非常に少ない。例えば、時間がないプロジェクトや使い捨て資料で汎用性にこだわってもしょうがない。状況によって何を優先させるべきかで資料は変化する。


  • 1つのオーサリング(資料作成)ツールを極めろ

他はいろいろな単機能ソフトを使い分けろなど。この意見はいろいろなソフトを使い分けろと対極な考えであると思われるかもしれないが、私から見れば同じことである。つまり、テキストエディタ、連続文字列生成(Excelのオートフィル機能が神)、文字列一括置換、フローチャート図作成、画像キャプチャとトリミング、カットイラスト(通称:ポンチ絵)の管理、グラフ作成などは、用途に合ったいろいろな単機能ソフトを用いることで効率化出来るが、オーサリングツールはPowerpointかExcelかWordあたりから、自分の使いやすいものを選べ、ということである。ショートカットは奥が深い。ひとつのソフトを極めれば極める程すばやく資料が作成出来るようになる。業務の効率化に終わりはない。


  • 提案のフェーズを意識せよ

ソースコードの階層はフラットではない。関数呼び出しを重ねていくとだんだん上の階層になってくるが、上と下の関数は明らかに意味が違う。私は以下のように分類している。一番下の階層がアプリに依存しない汎用的な処理(ライブラリ)である。次の階層が分野(ドメイン)に特化した汎用的な処理(ライブラリ)である。次の階層がアプリ自体の処理(業務ロジック)である。フレームワークなども考えるともっと階層化されるかもしれない。しかしこの程度でも意識するのとしないのでは、ものすごく違いが出ると思われる。



他は気がついたら追記していく予定。


元のフォーマットに合わせすぎてるところもあるので、
ネタはつかみだけにして、これから随時加筆修正して行きます。
追加のご意見は、コメント欄やブックマークコメントにお願いします。