技術系プレゼンテーションの前にやっておくべきこと

プレゼンテーションの下準備を行う際に、普段心がけていることを整理する。

導入

ブログ、翻訳に続く舞台裏シリーズの第３弾として、プレゼン前の下準備の際に自分が心がけていることをまとめておきたいと思います（もう舞台裏ネタはないので、これで最後です）。2010年10月のDevLOVE "Beautiful Development"が、私が個人として行う初めてのパブリックスピーキングでした*1。その時から今まで何度か登壇の機会を頂いていますが、最初のとき以来、事前に必ずやるようにしていることが３つあります。一般的に基本と言われるものがすべからくそうであるように、たいしたことではないのですが、地道にやることでそれなりの効果は得られているような気がします。もちろん、「こうしなければいけない」という話ではありません。「私はこうしています」という話です。参考にして頂ければ幸いです。

内容に入る前に、すこし本のご紹介を。プレゼンテーションのマニュアルとして私が読んだのは次の２冊です。

プレゼンテーションzen

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

プレゼン資料を見て頂いたことのある方ならおわかりのとおり、私はzen主義者です。ただ、それほど原理的ではなく「写真を使ってメッセージを伝える」ということを除いて、書いてあったことを色々忘れているような気もします。『パブリックスピーカーの告白』もやはりいい本で、これを読んでからプレゼンを技術としてとらえるようになりました。

さて、私が必ず守っている教えは、『zen』から２つ、『告白』から１つもらっています。

メッセージを明確に（プレゼンテーションzen）

プレzenの奥義は「Flickrを使いこなすこと」ではもちろんありません。大切なのは「メッセージを伝えること」です。「メッセージ」という言葉が何か格式張った印象を与えるのであれば、「エレベーターピッチ」と言い換えてもいいでしょう。要するに、聞きに来てくれた方（しかも、仕事帰りだったり、休みの日だったりする貴重な時間を割いて来てくれた方）に対して、何を持って帰ってほしいのか、一言で、ということです。

具体例のためにさらに舞台裏をさらすと、

• 「ドメイン駆動設計入門」のメッセージは、「オブジェクトが表現するのは概念である」と「MVCのMはモデルであって、スクリプトではない」の２つでした。サブテーマとして、これを軸にDDD本を概観し、その後の佐藤さん、増田さんの発表の土台をつくる、というものがありました。
• 「戦略的設計入門」のメッセージは、「戦略的設計とは何かを具体的にイメージしてほしい」というものでした。抽象的な議論が多く、DDD本を読んでいるだけだとイメージが湧きにくいのですが、かなり重要な箇所なのです。これはドメイン駆動設計入門の続編であると同時に、DDD前夜祭陽の巻の第4部編でもありました。
• 「Growing Grails Application」のメッセージは、「DDDを実践するために、欠けているものを埋めよう」でした。DDDは設計の話はしてくれますが、意外と具体的なプロセスの話をしてくれておらず、実際現場に適用するには、いくつかのプラクティスと組み合わせる必要があるのです。もちろん、抜き打ちモデリングセッションで交流を、というのも大きなテーマでした。

他にも、「旅行手配ドメイン」とか「Geb+Spock」とか、スパイスっぽいものはあるのですが、メインとなるメッセージをぼかしてしまうような話はかなり削っています。メッセージに焦点を合わせ続けられるようにし、余計なものを削る上では次のプラクティスが助けになります。

発表原稿を作成する（プレゼンテーションzen）

プレzenのいいところは、スライドを眺めているだけでそれなりに楽しいところ。悪いところは、話者がいないと何の話かさっぱりわからないところです。それを補うためにプレzenには「ハンドアウトを配ればいいじゃないか」という素朴なソリューションが提示されます。

とはいえ、「ハンドアウトをプリントアウトするのもそれなりに手間がかかるし、どうしたものか」と考えた結果が、「発表前に書いて、後でブログで公開」でした。やはり原稿を書くとストーリーを前もって組み立てられるので、論理に飛躍があるところとか、脱線しているところに気づくことができます。ただ、読み上げはしていません。ライブ感が失われるような気がするので。じゃあ、原稿も読まずにどうやっているのか、暗記でもしているのか、という話が次のプラクティスにつながります。

リハーサルをする（パブリックスピーカーの告白）

これは目からウロコが落ちました。曰く「うまくなりたいなら、練習しろよ」と。発表原稿を書くのとは前後するケースがありますが、私は最低２回リハーサルをやっています。PCを操作しながら、立って実際に声を出してやっているので、傍から見たら相当奇妙に見えるでしょう。

２回というのは、別に勤勉なわけではありません。１回目は時間が大きくズレたり、話がうまくつながらなかったり、脱線したり、言いよどんだり・・・要するにうまくいかないんですよ。それを発表原稿にフィードバックして、スライドを増減させた上でもう一回やっています。これでうまくいくこともありますが、うまくいかないこともあります。そういう場合は、もう一度。大体３回やれば感じがつかめます。

このときに心がけているのが、「セリフを覚える」のではなく、「論点を整理する」ことです。「このスライドではこれとこれとこれを伝えよう」―こうしておけば、わりと普通に話すことができます。たまにセリフがとんでいることもありますが、本当に伝えるべきメッセージが１つか２つに絞られているので、多少細かいことを言いそびれても、全体のメッセージを大きく外すことはありません。時間も、すこし早めに終わるように事前に調整していれば、手元のタイマーを見ながら話して大体ぴったりに収められます。

ちなみに、タイマーとレーザーポインタのついたリモートコントローラを @t_wadaさんに紹介してもらいました。お値段はちょっとするのですが、それに十分見合う便利なアイテムです。

LOGICOOL プロフェッショナルプレゼンター タイマー機能・LCD搭載 R800

最後に

一言で言えば、私のプレゼンは「上演」です。準備してきたものを「演じる」わけですね。だから、準備がしっかりできていれば、当日はそれなりに心に余裕が持てます。実際にプレゼンをしているときに意識しているのは、なるべく聞いてくださっている方の反応を見ること。やっぱり、うなずいてくださったり、笑ってくださったりすると、うれしいじゃないですか。スライド作りとか、リハとか、それなりに準備に時間はかかるんですけど、でも喜んでくださる方の顔を見ると、やってよかったなー、と思います。

一番大事なことですが、プレゼンは一人ではできません。場を準備して登壇させて下さる方がいて、聞いてくださる方がいて、初めて成り立つことなんですよね。とても感謝しています。いつも、どうもありがとうございます！

*1:学会発表は以前にもやったことはありますが、あれはちょっと別ですので。また、2010年のデブサミで、JavaEE勉強会のメンバーとパネルディスカッションをやらせて頂いています。あれは勉強になりました。