give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

発表でうまく話すためには (富山Ruby会議01のPRをかねて) #toyamark

はじめに

僕は今年の8月末に銀座Railsという勉強会で登壇してきました。
講演が終わったあと、Twitterでみなさんの感想を読んでいたところ、こんなツイートを見つけました。

どうもありがとうございます!
発表のしゃべり方は、自分でもうまい方なんじゃないかと思っています(笑)。

コメントをくださった方が「構成の考え方や練習量が気になる」とおっしゃっているので、今回は僕が考える「発表でうまく話すコツ」を書いてみようと思います。

【もくじ】

いきなり種明かし = 実はある本の内容を実践してるだけ

僕が初めて人前で話したのは2012年のDevLove関西のイベントです。

blog.jnito.com

当時は人前で話すのが初めてで、僕はプレゼンのやり方について右も左もわかりませんでした。
そこで、プレゼンのイロハを学ぶために買ったのが、この「パワー・プレゼンテーション」という本です。

この本が僕にとってはすごく「当たり」で、それ以来、ずっとこの本に書かれている内容を実践し続けて現在に至ります。
(これ以外プレゼン関係の本は読んでいません)

僕が大事にしているポイントあれこれ

というわけで、みなさんもこの本を読めば僕が実践しているコツが全部わかります。以上!!

・・・で、終わると、あまりにも肩すかしなエントリになってしまうので、この本の内容で特に僕が大事にしているポイントとをいくつか挙げてみます。
また、この本の中には載っていないけど、個人的に大事にしているポイントもいくつか書きます。

参考:銀座Railsで発表した内容について

ここでは具体例として、銀座Railsで使ったスライドや話した内容を登場させます。
銀座Railsでの僕の発表については、以前書いたこちらのブログ記事を参照してください。

blog.jnito.com

それでは以下が本編です。

聞き手にメリットを与える

うまく話すための大事なポイントは、聞き手に明確なメリットを与えることです。
これを「パワー・プレゼンテーション」の中ではウィッフィー(WIIFY = What's in it for you?)と呼んでいます。

発表の構成を考えるときは、自分の中にある「これを話したい!」「これを聞いてほしい!」という思いが起点となることは間違いありません。
しかし、そのままスタートを切るのではなく、一度自分の視点を聞き手の視点に置き換えて「それを聞いて何がうれしいの?」「その話のどこがおいしいの?」と自問自答してみると、聞き手にとっていっそう満足度の高い発表にすることができます。

先日の銀座Railsの発表で言えば、「普段あまり目にする機会がない、"他の人がリアルにコードを書いている姿"を見られること(それを通じて、プログラマがコードを書きながら考えていることや、コーディングのテクニックを知れること)が聞き手にとってのメリットになるはず」と僕は考えていました。

A地点は何か?B地点は何か?

書籍の中では、プレゼンは聞き手をA地点からB地点に連れて行くことがゴールだとしています。

A地点というのは、プレゼンを聞く前の聞き手の状態です。
B地点というのは、あなたのプレゼンを聞いた後に聞き手が抱く気持ちです。

すなわち、聞き手が「話を聞く前は○○だったが、話を聞いた後には△△な気持ちになった」という感想を抱けば、その発表は大成功、ということです。

たとえば、先日の銀座Railsの発表で言えば、A地点とB地点の設計はこんな感じになります。

話を聞く前は「すごいプログラマは何でも知っていて、すらすらコードを書く」と思っていたが(A地点)、話を聞いた後は「別にそんなことはないんだ(でも、自分と違うところもたくさんある!)」と思うようになり、その結果、気持ちが軽くなってこのままがんばっていこうと思えた(B地点)

ペルソナを明確にする

プレゼンの内容を考えるときはペルソナを明確にします。
すなわち、「こんな経歴で、ふだんこんなことを考えている人が最も喜ぶ話を提供しよう」と考えることが重要です。

これはプレゼンに限らず、技術記事を書くときも同様ですね。
qiita.com

プレゼン当日に聞き手が100人いた場合、100人全員が喜ぶ話を提供するのはほぼ不可能です。
全員を喜ばせるような内容にしようとすると、逆に何が言いたいのかよくわからない、誰も嬉しくない発表になってしまうかもしれません。

別に100人の中の5人とか10人ぐらいでもいいんです。
「客席にはきっと、こんなことで困っている人やこんなことを知りたがっている人がいるはず」という「仮想オーディエンス」を設定して、その人が大喜びするような内容を考えます。

こういう設計にした方が、内容が濃くて面白い話になりやすいです。
仮に100人中の90人はターゲットでなかったとしても、濃くて面白い話になっていれば「その話はすでに知ってるけど、たしかにそのとおり!」とか、「へ〜、そういう世界もあるんですね。初めて知りました」と、納得してもらえる内容になるはずです。

ちなみに、先日の銀座Railsの発表で僕が設定したペルソナは、

「プログラミング歴があまり長くなくて、自分のプログラミングスキルにあまり自信がなく、なおかつ他の人がコードを書く様子を見たこともないので、"きっと自分以外のプログラマはもっとすさまじいスピードで書いているに違いない"と、何の根拠もなく考えている人」

でした。

背伸びをしない

「背伸びをするな。自分の言葉で語れる内容だけを語れ」

これは書籍の内容ではなく、僕が初めてDevLove関西で登壇するときに、弊社ソニックガーデンの倉貫社長から言われたアドバイスです。

これはプレゼン初心者に多いと思うのですが、人前で話す自分を想像すると、「あいつ、バカなんじゃない?」とか「大したことねーのに偉そうにしゃべりやがって」みたいにdisられるんじゃないかと、つい妄想してしまうことがあります(僕もそうでした)。

こういった恐怖心があると、「えーと、あまり詳しいわけじゃないんだけど、この話も盛り込んでおいた方がいいかな・・・」という、「見栄をはりたくなる気持ち」が湧きあがってきます。

が、自分がよく知らない話をプレゼンに盛り込むのはやめた方がいいです。

自分がよく知らない話は自信をもってしゃべれないので、説得力がなくなります。
また、質疑応答で「あまり詳しくない話」に質問が来ると、しどろもどろになってロクな回答ができなくなります。

それよりもむしろ、自分がちゃんと理解している内容、自分自身の考え、自分自身の経験だけを話すようにしてください。
その方が話が生き生きとして、説得力が高まります。
質問が来ても自分の中にある話なので、自信をもって答えることができます。

自分が理解していることを自分の言葉で堂々と語っていれば、話のレベルが低いだの高いだの、そんな文句を言う人は出てきません。

アイスブレイクは重要だが、ウケ狙いは不要

プレゼンの冒頭では軽いアイスブレイクを入れて、聞き手の気持ちをほぐしておくと、その後のトークもなごやかに進めやすくなります。

アイスブレイクは何でもいいです。
簡単なのは「〜な人がいたら挙手!」みたいな感じで、会場に向かって質問を投げかけることですね。

先日の銀座Railsでは、「今日、僕は新幹線で東京までやってきたんですけど、この中で僕と同じように新幹線で来た人はいますか!?」と質問を投げてみました。(絶対いないだろうと思ったら、1名だけいましたw)

その一方で、発表中に笑いを取りに行くのは、僕は非常に危険だと思っています。
ウケを狙おうとすると失言につながったり、意図せず誰かを傷つけたりしやすいからです。
会場では何も問題が起きなくても、スライドを公開したあとにSNSで大炎上、みたいなこともよくあります。

また、ウケを狙って盛大に滑ってしまったときは、自分へのダメージも大きいですし、聞き手も痛々しい気持ちになってしまいます。

とはいえ、始終お堅い話ばかりしてもしんどいと思うので、僕は「クスッと笑えるぐらいの軽いユーモア」を入れることはあります。
大爆笑を狙いに行くのではなく、あくまで「クスッと笑える程度」に留めておくのがポイントです(そのさじ加減はなかなか難しいと思いますが)。
軽いユーモアであれば、仮に滑ったとしても致命傷にはなりにくいです。

たとえば、銀座Railsでは若干自虐気味にこういうスライドを挟み込んだりしていました。

f:id:JunichiIto:20191002094615p:plain

客席に目をやる、問いかけを盛り込む

発表中は頻繁に客席に目をやることも大事なポイントの一つです。
話すのに必死になって、ずっと目の前のパソコンを見ていたり、会場のスクリーンに向かって話し続けていたりすると、話し手と聞き手の心の距離がどんどん離れていきます。

発表中は何度も客席の様子を確認しましょう。
自分の話にうなずいてくれる人が何人かいたら、いい感じに自分の話が伝わっている証拠です。

また、発表の途中に「問いかけ」を盛り込むのも効果的なテクニックのひとつです。
「〜ですよね?」とか、「〜だったりしませんか?」とか、「〜ってご存じですか?」とか、こういった問いかけを挟み込むことで、聞き手はあなたと会話をしているような気持ちになります。
そうすると、話し手と聞き手の心の距離が縮まって、聞き手はあなたの話にじっくり耳を傾けてくれるようになります。

以下は銀座Railsで使ったスライドの「問いかけ」の例です。

f:id:JunichiIto:20191002095806p:plain

スライドを読ませない(聞き手の意識をスライドに集中させない)

自分の話したいことをふんだんにスライドに盛り込もうとすると、スライドが文字だらけになります。
スライドが文字だらけになると、聞き手はスライドの字を読むことに必死になります。
スライドを読むのに必死になると、聞き手の意識があなたの言葉ではなく、スライドの文字に集中します。
結果として、聞き手は「あなたの話を聞いた」というよりも、「スライドをがんばって読んだ」という形になります。

このように、「うまく話す」という観点においては、情報量が多すぎるスライドはマイナスに作用します。
そもそも、自分が話したいことをすべてスライドに盛り込むのであれば、何も話さずにスライドを配って終わりにすればいいはずです。

情報量が多すぎるスライドを防止する方法のひとつは、「スライドの中の文字を絶対に折り返さない」という制約を課すことです。
この制約を守るようにすると、自ずとスライドの文字が削られていきます。

以下は「絶対に文字を折り返さないスライド」の一例です。

f:id:JunichiIto:20191002100612p:plain

また、最初から全部スライドの文字を見せると、やはり聞き手の意識がスライドの文字に移ってしまいます。
なので、僕はアニメーション機能を使って箇条書きをひとつずつ表示するようにしています。

f:id:JunichiIto:20191002204114p:plain

同僚にレビューしてもらう

初めての発表で慣れていないときは、発表の構成やスライドがある程度できた時点で会社の同僚にレビューしてもらいましょう。
ちょっと恥ずかしいかもしれませんが、軌道修正は早ければ早いほど良いです。

完全に作り込んでしまう必要はありません。
むしろ、完全に作り込んだあとでは、「発表直前に大量のフィードバックを受けて途方に暮れる」といった事態になりやすいです。
「だいたいこんな感じ」というイメージが固まった時点で早めにレビューしてもらうことをオススメします。

そして最後に練習、練習、練習!!

ところで、冒頭で紹介した感想ツイートの中に「練習とかはどのぐらいしたんだろうか」というコメントがありました。
「練習ってwww 僕がそんな泥臭い努力をするわけないじゃないですか!」と言いたいところですが、めちゃくちゃ練習してます。はい。

練習の重要性は書籍「パワー・プレゼンテーション」の中でも説明されています。

では、どうしたら命を吹き込むことができるのだろうか。それは、「声に出して練習する」ことだ。

その際には、本番で使用するスライドを使い、大きな声で練習してほしい。実際に聞き手の前に立ってプレゼンテーションするつもりで行おう。この「声に出して練習する」プロセスなくしては、効果的なプレゼンテーションなどありえないのだ。


「パワー・プレゼンテーション」183p.

僕はだいたい発表当日の1週間前にはスライドをいったん作り終えて、練習(というかリハーサル)を始めます。

本番までに最低でも4〜5回、多いときは10回以上やります。
ときどきPCの画面と自分の声を録画して、自分で動画をチェックすることもあります。

MacであればQuickTime Playerを使って画面を録画することが可能です。
(参考:MacのQuickTime Playerで画面を収録する - Apple サポート (日本)

事前に練習を繰り返すと、次のようなメリットが生まれます。

当日の時間配分をほぼ完璧にコントロールできる

リハーサルをやると、自分のトーク時間がわかります。
これ、意外なことに時間をオーバーしてしまうケースの方が圧倒的に多いんですよね。
今までリハーサルをしてみて、予定時間より早く終わった経験は一度もありません。

なので、リハーサルをまったくせずに本番にのぞむと、たいていの場合、制限時間をオーバーしてしまうと思います。

時間が足りないと最後だけ急に早口になって「このスライドは飛ばします」みたいなセリフを連発したり、「あっ、あっ、あと5分ください!」とお願いしたりするハメになります。

こうなると聞き手も変に焦ってしまいますし、時間をオーバーするとタイムテーブルが押してしまって、あとの登壇者に迷惑がかかったりします。

ですので、リハーサルを繰り返して、自分のトーク時間をコントロールできるようにしましょう。
リハーサルでは時間をオーバーしても誰にも迷惑がかかりません。
明らかに制限時間を超えてしまう場合は、スライドの枚数や口で話す内容を減らして、トーク時間を調整しましょう。

リハーサルを4〜5回やってトーク時間が制限時間内に収まれば、本番でも同じように制限時間内にしゃべれるはずです。

スライドやトークの内容が洗練される

練習を繰り返したり、録画した自分の発表をチェックしたりすると、第三者の視点で自分の発表を振り返ることができます。
そうすると、「ちょっとここはわかりにくいな」とか、「ここはこういう説明の方がいいな」という改善点が見つかります。

そういった改善を繰り返していけば、スライドやトークの内容がどんどん洗練されていきます。

発表中に挟む軽いジョークなんかも、練習を繰り返すうちに「あ、ここでこういうジョークが入れられるかも?」と気づくことが多いです。

落ち着いて話せるようになる(えー、あー、あのー、の回数が減る)

ぶっつけ本番で話そうとすると、芸能人やアナウンサーではない僕たちは、「えー」「あー」「あのー」みたいな言葉がしょっちゅう出てきてしまいます。

練習を繰り返すと、落ち着いて話せるようになるので、えー、あー、あのー、の回数が減ります。

多少の「えー、あー、あのー」であれば口に出しても問題はありませんが、頻繁にこの言葉が出てくると聞き手も少し落ち着かない気分になってくるので、プレゼン初心者の方は要注意です。
(練習を録画して自分で見直してみると、自分がどれくらい「えー、あー、あのー」を連発しているのか、よくわかります)

また、上で述べたように、発表中はなるべく客席に目をやることが大事です。
これも余裕がない人ほどパソコンやスクリーンに集中しがちになります。
ですので、事前に練習を繰り返して「心の余裕」を十分持つようにしましょう。

まとめ

というわけで、このエントリでは僕が普段意識している「発表でうまく話すためのコツ」をいろいろと紹介しました。

もちろん、発表の上手・下手はこれまでに踏んできた場数によっても変わってきます。
ですが、場数だけがすべてではありません。

ここで紹介したようなコツを意識すれば、プレゼン初心者の人でも「発表、とてもお上手ですね」と言われるはずです。
ですので、みなさんもこのエントリで紹介した「発表のコツ」をぜひ実践してみてください!

あわせて読みたい

Macで使えるプレゼンソフト、Keynoteの使い方を解説した記事です。
スライドの作り方に慣れていない人は、こちらの記事も参考にしてみてください。

blog.jnito.com

最後に宣伝:富山Ruby会議01で発表します!

さて、最後にちょっと宣伝をさせてください。
今度、2019年11月3日(日)に開催される富山Ruby会議01で、招待講演として「○○からRubyへ」という発表をさせてもらいます。

f:id:JunichiIto:20191002203426p:plain

スライドはまだ作り始めていませんが、だいたいこんな発表にしようと考えています。

聞き手のペルソナ

この講演のターゲットとなるのは「普段は地元のSIerでコンパイル型の言語を触っているが、Rubyの名前はよく聞くし、密かに憧れをもっていたりするSEやプログラマ」です。

A地点とB地点

A地点は「Rubyはまだ使ったことがないけど、ちょっと興味がある。でも、実際どうなの?いいの?悪いの?」と疑問を持っている状態です。

B地点は「へ〜、Rubyってちょっと面白そう!このイベントが終わったらちょっと試してみようかな」と思う状態です。

講演のターゲットとなる方々が、僕の講演を聞いてこんなふうに感じてくれたら、僕の発表は大成功、ということになります。

「伊藤さんのプレゼンスキル」は果たして!?

当然のことながら、今回のエントリで紹介した「発表のコツ」は、この発表でもすべて実践するつもりです。
ふつうに発表を聞いてもらうだけでも構いませんが、このブログを読んだ人は「発表のコツがどこで使われているか?」を意識して僕の発表を見てみると、より楽しめるかもしれません。

また、僕の講演だけでなく、このイベントでは著名なRubyプログラマの方々が登壇されるので、その内容も必聴です。
さらに、普段北陸地方とあまり縁がない方は、旅行を兼ねて美味しい魚料理やお寿司を楽しむのも良いと思います(僕も妻と金沢や富山を旅行する予定です😄)。

北陸地方に住んでいる方はもちろん、東京や関西など、遠方に住んでいる方たちもぜひ足を運んでもらいたいです。

登壇者情報と参加申込みページはこちらです。
toyamarb.github.io
toyamarb.connpass.com
それではみなさん、11月3日の富山Ruby会議01でお会いしましょう〜!

追記:フィヨルドブートキャンプの受講生のみなさんへ(2022.3.12追記)

フィヨルドブートキャンプの受講生のみなさんが内部LT会の参考資料としてこのエントリをよく見に来ている、という話を聞いたのでちょっと追記しておきます。

このエントリで想定しているのは「ガチめの発表」です。
「ガチめの発表」というのは、オーディエンスが50人以上いて、発表時間も20分以上あって、発表者はオーディエンスにとって価値のある情報を提供することが期待されている、そういう発表のことを指します。

一方、LT(ライトニングトーク)というのは、この業界(ITエンジニア業界)では「ゆるくて雑な発表(でもOK)」と捉えられることが多いです。

少し古い動画ですが、ベテラン勢が考える「(いわゆる)LT」っていうのはこういうイメージなのではないでしょうか(YouTubeでたまたま見つけてきただけなので、ここでこの動画を紹介することに深い意味はありません)。

www.youtube.com

もちろん、LTでもきっちり作り込んで発表するのはまったく構いません!
ですが、もっといい加減で雑な発表であってもLTであれば許されるはずです。
なので、LT会で発表しようかどうか迷っている人は自分の中のハードルを下げて、もっと気楽に登壇を申し込んでみてください😄