この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「みんな、登壇するとき、何に気をつけて喋ってんの？すげぇ聞きたい」
そんな素朴な疑問から、「登壇勉強会〜それぞれの流儀がそこにある〜」という社内イベントを企画しました。登壇者は自分含めて3人。
当日他の登壇者（藤村、塩谷）という歴戦のツワモノの発表を聞いていて思ったんですが、はっきり言って登壇って100人100様です。めっちゃ個性がでまくります。
唯一の正解なんてなく、それぞれが独自のやり方で登壇の技を磨いているんだなぁと心底思いました。これ自分が企画した勉強会でしたが、自分が一番楽しんでたと確信してます。このブログでは、自分が普段登壇する時に気をつけているところを主観丸出しで書いてます。「それぞれの流儀がそこにある」ということで、何かしら皆さんの参考になれば、これ幸い。
なんかすげぇメタ的な企画…!! ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ /
登壇資料
以下、登壇したときの喋りを再現しながら、ブログにおこしていきます。
自己紹介と今日のアジェンダ
一応自己紹介します。AWS事業本部コンサルティング部のハマコーです。パワーポイントにtwitterのアイコンを載せようとしたら、素敵なデザインを提案してくれました。ナイステクノロジー。
twitterアカウントだけ宣伝しときます。ハマコー（@hamako9999）です。
今日のアジェンダはこんな感じ。
- 人生を変えた登壇
- 登壇機会の作り方
- 登壇内容のストーリーの作り方
- 秘伝のスライドテンプレート
- 聴衆をつかんではなさない話し方、動き方
人生を変えた登壇
自分、クラスメソッドに入社するまで特に外部での登壇経験とかほぼなかったです。ので、そんなにこだわりがなかったのですが、自分の転機となった登壇は確実にこれ。
「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 #cmdevio2018 ｜ Developers.IO
登壇までの経緯はあっさりしてます。
自分が悶々としているところ意を決して本部長にアピールしたら、3分後に社長からレスがあって登壇決まるとか、何だこれと。入社して1年ぐらいでしたが、この時初めてクラスメソッドという会社を本当に理解した気がしました。
意を決して登壇したことで、ごっつ沢山の事を得ることができました。やっぱり手を挙げてみるもんですね。これにより、
- 登壇に対する自分なりのスタイルを確立できた
- 社内外で「コンテナハマコー」的な雰囲気になった
- 登壇することの怖さが全くなくなった
と、良いことづくめでした。
登壇機会の作り方
登壇ってなんだかんだ、経験も非常に重要です。その機会の作り方ですが、やはりなんといっても基本は「手を挙げまくる」ってことですね。臆してたらなんのきっかけも得られない。
気になるイベントのLT枠から挑戦する
技術的に気になるイベントでLT枠があるやつは積極的に爆速で応募しましょう。早いものがちの場合が多いですし、時間も短いので挑戦しやすいです。
CFPに対してプロポーザルを出す
王道ですね。出さないとなにも始まらない。ここミソなんですが、自分プロポーザル通ったことないです。まぁ出してる数が少なすぎってことなので、今後もガンガン出していきたいんですけど。
- ビルダーズコン2019 → 落ちた
- デベロッパーズサミット2020 → 落ちた
- けどなぜかパネラーでの登壇打診が！
落ちても登壇のきっかけを得ることもあります！！ほんま出さないとなんも始まらないと強く思った出来事でした。
ブログ書く
弊社では王道です。【GOJAS Meetup-11】 GOJAS Meetup Summer Special - Go Japan Splunk User Groupへの登壇も、「【祝】FargateでログドライバーにSplunkが利用可能になりました！」というブログを書いたのがきっかけでした。
コミュニティ運営側に回る
まぁこれもありでしょう！今まで参加はしてたんですが喋る機会がなかったJAWS-UG コンテナ支部ですが、前回から運営に入って、アレよこれよという感じで、「EKS入門者向けに「今こそ振り返るEKSの基礎」というタイトルで登壇しました #jawsug_ct」で喋りました。
登壇内容のストーリーの作り方
登壇内容の作り方なんですが、自分のほぼすべてのベースはこちらの講座を参考にしてます。
新エバンジェリスト養成講座／企業のIT、経営、ビジネスをつなぐ情報サイト EnterpriseZine
2時間6000円の講座ですが、はっきり言ってコスパはめちゃくちゃ良いので、気になる方は受講してみると良いんじゃないでしょうか。
自分が登壇のストーリーの作り方で気をつけていることは大きく２つ。
- 「技術の伝達」だけではなく「行動を促す」内容にする
- 冒頭で「この話を聞く意味」を強く出す
1. 「技術の伝達」だけではなく「行動を促す」内容にする
実際、代表的な技術登壇の時間が45分として、その時間で得られる技術知識の量って限られてるんですよね。そう考えた時、プレゼンテーションの場を技術要素の羅列だけで終わらせるのはすごくもったいないなと感じてます。
なので、自分としては、登壇が終わった後聞いてくれた人に、「あー、ええ話やったわぁ」という感想で終わる内容ではなく「そっか、早速今の現場で試してみよ！」という行動を促す事にこだわりたいと思ってます。
具体例で振り返ってみます。
登壇：「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 #cmdevio2018 ｜ Developers.IO
このときですが、流れをこのような旅形式にしました（もちろん、カイゼン・ジャーニーにもろに影響を受けています！）
ストーリーを作る時、以下の点にこだわっています。
仮定
実際に現場でコンテナ化を検討するとき、どこから始めるかわからない人たちが多いのではないか？
ストーリーの展開
最初のハードルが高いのは良くない。ミニマムなところから初めてストーリー仕立てで話すことで、「おー、そっか。こんな簡単に始めれるんだ」と思ってもらいたい
全体構成
５段階の旅形式にして、いろんなシチュエーションにある人達に、それぞれの観点で「次に何をするのか」を持ち帰ってもらいたい
というところから、「ジャーニー」という単語を使って、旅形式でコンテナ導入のハードルを下げていこうと意図してストーリーを組み立てました。
2. 冒頭で「この話を聞く意味」を強く出す
いわゆる「デマンドの植え付け」と呼ばれる手法です。45分は長いです。今聞いている話が「これ、ほんまに自分の役に立つのかなぁ」というところが曖昧なままだと、聴衆の集中力を集めるのが難しく、結果、昼寝や内職につながるんですね。そういう人が多いと喋っている自分のテンションもさがっていくし、悪循環。
なので、プレゼン冒頭でできるだけ、「この話はあなたにとってこんなメリットあるんですよ」ということを明確に出すようにしてます。45分枠だと、最初の7分ぐらいは自己紹介とデマンドの植え付けでも良いんじゃないでしょうか。
これも具体例で、長めに振り返ってみます。
登壇：CloudFormationの全てを味わいつくせ！「AWSの全てをコードで管理する方法〜その理想と現実〜」 #cmdevio ｜ Developers.IO
最後、赤バックで恐怖を煽るような雰囲気にしているのは、「あんた、このままCloudFormation知らなかったら、めっちゃ損するかもしれんで？大丈夫？」という事を前面に押し出したかったからです。
このデマンドの植え付けをやろうとすると、それはそのまま「この登壇の中で、自分が一番聴衆に伝えたいこと」を明確に意識しまとめることにもつながるので、ストーリーを考える時のやりかたとして非常にオススメです。
秘伝のスライドテンプレート
これには、自分とくにこだわりないです。クラスメソッドの登壇用標準テンプレートがあるのでそれを普段つかってます。
デザインの原則は、この書籍が非常に簡潔でシンプルに纏まっているのでオススメです。
一生使える見やすい資料のデザイン入門 | 森重湧太 | Kindleストア | Amazon
聴衆をつかんではなさない話し方、動き方
主に意識しているのはこの3つ。
- リハーサルをやる。というかやれ
- 可能な限り聴衆を見る
- スライドではなく自分の喋りをメインにする
1. リハーサルをやる。というかやれ
百戦錬磨のツワモノは無くても良いかもですが、登壇慣れていない人は必須です。実際に喋って通してみることで無限のメリットがあります。もちろん録音も一緒にしましょう。
- 時間配分が適切か
- 自分の喋りたいことが頭にはいっているか
- 自分の喋りとスライドの辻褄があっているか
- 自分の意識していない口癖がないか
ここらへんが完全に明らかになります。また、他人に聞いてもらうのもめちゃくちゃ有効ですね。
- 独りよがりになっている説明がないか
- ストーリーがわかりやすいか
- 変な動きしてないか
といったところは、実際に見て聞いてもらわないとなかなかフィードバックが難しい点だと思います。
2. 可能な限り聴衆を見る
これも凄く重要。どうしても登壇中、ノートPCやスクリーンの方を見てしまいがちな人も多いですが、登壇って誰に向けて喋ってるかといえば、そりゃもちろん聴衆なんですよ。聴衆をみないでどんなコミュニケーションが取れるってんですか。
実際にやろうとすると、実は凄く難しかったりします。自分も正直できてない部分沢山あります。技術プレゼンだと喋る内容を完全に頭にいれるのは難しいのですが、努力する意識があるだけでも全然違うかと思います。
ノートPC5割、聴衆5割ぐらいの視線配分にできれば上出来かと。
3. スライドではなく自分の喋りをメインにする
登壇慣れてない人で、いまいち自分の喋りに流れがないなぁと思う場合に、一番意識すると良いと思う点がこれです。
更に言うとこれ。
登壇という場において、聴衆に届ける材料は大きく2つ、喋りとスライド。この喋りをメインにすることで、登壇に流れが生まれて、聴衆がすっと内容に集中しやすくなるんですね。
イメージとしてはこんな感じ。スライド切替前に、ある程度次のページの前フリを言葉でいれながら、スライドを切り替えて喋るイメージです。
これが、スライドを切り替えた後に「…はい。で、この内容について〜」が続くと、プレゼンに流れが出ないです。
リハーサル不足であったりプレゼンの流れが頭にはいっていない時に、スライドが出てから喋ってしまいがちです。これは、登壇に慣れていたりリハーサルを繰り返すことで、殆どは自然と解消されますが、今まで具体的に意識していなかった人は、この部分着目してリハーサルをしてみると全然ちがうと思います。
まとめ
最後にまとめです。
- 登壇機会を得るには行動力のみ
- プレゼン冒頭で「聴衆が聞くことの意味」を強く訴える
- スライドテンプレートはなんでもよい
- 「一生使える見やすい資料のデザイン入門」はおすすめ
- まずは下の３つをおさえておく
- リハーサルを絶対やる
- 可能な限り聴衆をみるように意識づける
- 自分の喋りをメインにする
- しつこいけど、西脇さんのエバンジェリスト養成講座はオススメ
当日他の登壇者の発表
当日の勉強会、他の登壇者の資料もアップされているのでご紹介。たまたまですが、デブサミ2020にクラスメソッドから登壇したメンバーが揃いました。
藤村新
登壇経験から準備方法から当日の喋り方まで、自分とは全くスタンスが違ってめっちゃ面白かったです。デブサミの発表間近で見たんですが、本当に登壇中一切集中力をきらさない、全く間延びしない喋りは壮絶の一言。話も内容も素晴らしく筋が通っているし、喋っている途中、観客の反応をみながら話の内容まで変えていくと聞いたときは、「あ、この人やばいわ」と真剣に思いました。
塩谷啓
登壇経験半端ない歴戦のツワモノ、塩谷の発表もめちゃくちゃ参考になりました。こんにちはのアイスブレイクの考え方から、登壇することによるエンジニアとしての裾野の広がり、時間のコントロールの仕方など全て参考になります。藤村も、塩谷も、最後にバッファーをもたせるというのを聞いて、完全に目からうろこでした。そこまで全然考えたこともなかったので。
都元ダイスケ
実はこの登壇勉強会の企画を自分が社内Slackに書き込んだ時、なんやかんや手が上がり、都元ダイスケ含めて4人で登壇する予定でした。ご存知の方もおられると思いますが、突然の訃報により、その機会は永遠に失われました。
自分は、AWS Dev Day Tokyo 2018や、Developers.IO 2019 at 岡山城で、都元さんの登壇を直接みる機会がありました。今でも、あの人ほどこみいった技術要素を噛み砕いて親切に、たとえ話を交えながら誰にでも解りやすく伝える術を持った人はいなかったと思ってます。
登壇者4人の事前の打ち合わせで、「みやもっちゃん、ノウハウ全部さらけ出しなよ」ってふったら、「え？俺、別にこれといってなにも考えてないよ？」とかとぼけていたのを、今でも思い出します。
そのノウハウを彼の口から直接聞く機会は、なくなってしまいました。めちゃくちゃ残念です。ですが、彼の登壇のブログは残っています。認証認可やアプリケーションログの内容を、メタ的なところまで掘り下げて本質を明らかにしながら解説していく都元さんのスタイルが全面にでている、本当に役に立つスライドなので、是非エンジニアの皆さん参考にしてみてください。
「完全に思った。登壇は楽しい」
クラスメソッド、技術系の勉強会は頻度高く、それこそAWS事業本部だけでも週1以上のペースで開催されています。最近、Slackに#misc-studyというチャンネルが創設され、お金の話や色彩の話など、直接のエンジニア技術以外の勉強会も増えており、すごい活況です。
そんな中、完全に自分のために登壇勉強会を企画してやってみたんですが、普段聞くことのないノウハウを思う存分聞くことができて超絶楽しかったし、参加者の方にも参考になったのではないかなと思います。
エンジニアのアウトプットとしてブログももちろんありですが、登壇はそれ以上にエンジニアの幅や機会を広げていく重要な要素だと思ってます。このブログが、これから登壇しようとされるかたの何らかの参考になれば幸いです。
それでは、今日はこのへんで。濱田（@hamako9999）でした。