BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

エンジニアにおける登壇の心構えと資料作成のプラクティス

f:id:aiyoneda:20191202145228p:plain

こんにちは。基盤グループのめもりー (@m3m0r7) です。

この記事は、BASE アドベントカレンダー24日目 の 2 つ目です。

みなさんは、いざ登壇をするとなった時の準備に何を意識されていますか。例えば「本番で失敗しないように練習をたくさんする」だとか「場数をこなす」とか「伝わらないと困るからとりあえず資料に盛り込んどく」などなどあるかと思います。

私の初めての登壇は 2019 年の 1 月 26 日の PHP カンファレンス仙台が初めてで、多くの方に「え？本当ですか？信じられない」と言われたりもしました。今年はいろんな場所で、幸いにも登壇させていただける機会をいただき、初めての登壇回数は 15 回、登壇時間 270 分までにものぼりました。 とはいえ、私自身、いろんな方の登壇を見させていただいてもっと精進しなければならないと痛感しており、日々どうしていくべきか試行錯誤しています。

そんな中で、登壇についての心構えや資料作成といったベストプラクティスのような解説を書かれている文献がそう多くないと主観ではありますが感じてきていました。そのためどう資料を構成したり、登壇までに何をしたらいいのかがわからず、多くの方は登壇自体のハードルが高いと感じてしまうのではないかと思っています。私も実際そうでした。

私自身エンジニアとしてはひよこですが、今まで1日に何個も企画資料や開発資料、外部へのアウトプットサービスを通じて得た経験を元に社内のドキュメントに「資料作成のすゝめ」を投稿したところ、ブログに公開してほしいと嬉しいお声がけを頂いたので、ブログ向けにリライトしたものを公開したいと思います。

資料の作成

相手に「何を伝えたいのか」を自分自身が完璧に理解する

資料の作成には自分自身の納得と理解が必要だと感じています。私はなにを伝えたいのか？という自問自答を繰り返していきます。そして、発表タイトルから話すゴールを決定します。例えば私の場合であれば「PHP で JVM を実装して、 HelloWorld を出力してみる」という内容であれば「Hello World を出力する」というのをゴールとして置きます。そして、ゴールとは別に、伝えたいことを設定します。 「JVM の実装はそこまで難しくない」というのがこの発表での伝えたいことでした。 JVM を Go, R や Ruby などで実装してくれる方々が出てきてくださってとてもうれしく感じました。私自身は登壇の前にはこの 2 つを設定するようにしています。

いろんな方にご興味を持ってもらえたのがスピーカーとしてとてもうれしく思っています。

アジェンダの構成

資料におけるアジェンダは重要な役割を担っています。オーディエンスがどういったトークになるのかを頭の中で流れを理解できる唯一の情報源になるからだと考えています。 起承転結で書くと言われてもそこまでのイメージが湧きづらく筆がなかなか進まないこともあり、スタートから作っていくことを私は辞めました。

発表タイトルからプロフィール、そして話したいことを順番に作っていくとなると予め頭の中に何を話したいのか順序立てられており、スライドのイメージが既に湧いていないと難しいなという結論です。 したがって、私が資料を作る際には上にも書いてあるようにゴールと伝えたいことの 2 つ定義をした後、ゴールからスタートまでの大きな章を 4 〜 6 つほどに分割します。

そして、スタートは「なぜしたのか？」というところに落ち着くようにします。 例ですが、PHP で JVM を実装するという話では主に下記のように章分けをしました。

▲ゴール

  • Hello World を出力するまで
  • JVM のオペレーションコードの話
  • PHP と JVM の互換性の話
  • JVM を実装するとは？
  • なんでこんなことをしたのか

▼スタート

そして、章分けをした後それぞれの章が一つの発表内容だと考え、それぞれの章をさらに章分けをします。

▲ゴール

  • Hello World を出力するまで
    • 必要なもの
    • 使うもの
    • JVM 実装までの大まかな流れ
    • オペランドスタックの説明
    • オペレーションコードを知る
    • オペレーションコードの処理を実装する
  • JVM のオペレーションコードの話
    • オペレーションコードとはなにか？
    • Constant Pool とは？
  • PHP と JVM の互換性の話
    • 制約
    • それでも実装するのか？
  • JVM を実装するとは？
    • コンパイルされた class ファイルを読んでいくこと
    • コンパイルされた class ファイルとは？
    • JVM の実装は難しくない
  • なんでこんなことをしたのか
    • 刺激がほしかった
    • みんなやってないことをしたかった
    • PHP という言語そのものの可能性

▼スタート

上記のように章に分割できないまで繰り返していきます。そうすると必然と細かい箇所で話したい内容が明確になったり前後のスライドで辻褄が合わないから変えようといった具体的な改善点が見いだせます。

これを何度も繰り返していき、資料のストーリーを完成させます。

最後にストーリーを埋めていく

最後にスライドのストーリーを埋めていきます。これはアジェンダの次にとても大事なことです。 立てられた章のタイトルから話が脱線しないようにその内容に関係する方法や術、内容だけを書いていきます。そうすることにより、オーディエンスが聞いた時にコンテキストのスイッチが発生せずに済み、すんなり内容が入りやすくなるためだと考えているからです。

資料の存在意義

資料の存在意義で最初に思い浮かぶのはなんでしょうか。「自分のセッションを聴きに来てくれた方に伝えたいことがあるから」というのが理由の一つではないでしょうか。 私はもう 2 つ理由があると思っています。

  • 当日セッションを迷いに迷って見に来れなかった人に向けての資料
  • 自分自身が資料を暗記するという辛さから逃げるための術

当日セッションを迷いに迷って見に来れなかった人に向けての資料

当日魅力的なセッションがたくさんあります。自分のセッションが見れなかった人が資料を公開した際に見る可能性があります。その資料がワンラインだけだと、伝えたいことが意図と反して伝わっていたり、そもそも伝わららない可能性があります。せっかく興味を持ってもらえているので、それは避けたいです。

自分自身が資料を暗記するという辛さから逃げるための術

そして、もう 1 つが自分自身が暗記をしなくて済むようにするためでもあります。登壇当日、緊張しないとは限らないため予防線の一つとして、話したいことを資料に粗く書くことにより、頭の中が真っ白になったりしても資料に書いてある文字を読み上げるだけで済む逃げ道ができます。緊張が解れたら、書いてあること以外に自分が伝えたかった内容を話せばよいと私は考えています。今ではほとんど緊張しないものの、一番はじめの登壇である PHP カンファレンス仙台の際はとても緊張していましたが、この予防をしておいたため、伝えたいことを伝えれたと思っています。

そして、粗く書くというのは、見れに来れなかった人や資料を読み返した人でも、ある程度は伝えたいことのニュアンスが、すんなり入って来るのではないかと思います。

資料は熟成させる

資料は普段は登壇 1 ヶ月前くらい、遅くても 3 日前に作り終わるように心がけています。この理由は発表内容を忘れるためです。発表内容を忘れることにより、発表数日前に読み返した時に理解できるのか？を見ます。つまり資料を熟成をさせます。熟成した資料は誤字脱字、そして公の場で公開するのに適切であるのかを冷静な判断で見ることができます。例えば深夜の 26 時に勢いで書いたコードを翌日見直すと「なんだこれ！！」となる経験は誰にでもあると思います。資料も同じで、その時できたと思っていても数日立つと前後のスライドで話が噛み合っていなかったり、唐突に現れる専門用語だったりが浮き彫りになることもあります。そのため熟成という過程はコードにおいても資料においても大事であると考えます。

登壇の準備における心構え

「意義」のあるトーク練習をする

「意義」のあるトークとは何か？それは伝えたいことを伝えきることだと私は考えています。 そのためには実際のトークにかかる時間を綿密に計測し、時には伝えたいことを減らす、または増やすということが必要です。 慣れてくると発表時間と自分のトークに対してどれほどの資料の枚数が必要なのか自然とわかるようになってきます。

登壇前日に行うべきこと

デモがある場合は事前に動くかテストをし、そのあとは発表のことは忘れて酒を飲んで楽しみます。

登壇本番

自分はピエロだと思いこむ

登壇当日私は自分自身のことを「ピエロ」だと思いこむようにしています。これは誰かにそう言われたからではなく、自分自身の緊張を解す意味でもそう思うようにしています。ピエロであるからには、オーディエンスの皆様に楽しんでもらって帰ってもらいたいという気持ちを持つようにします。 楽しんでもらうわけですから、誰か一人でも傷つけたり不快な思いにならないように最善の注意を払います。

画面に映された資料は凝視してもいい

緊張をするとどうしても資料を凝視しがちです。それが良くないと全く思ってなくて、逆に凝視してもいいのではないかと思っています。楽しくなってもらえて、更に伝えたいことを伝えれることができれば、それ以上のことは慣れてからでも問題ないと強く思っています。

ここまで書いてきましたが…

ここまで書いていて私自身もできていないことが多くあります。私も迷ったらこの記事自体を見返すかもしれません。それでも完璧にやる必要はなく、あくまで一つの手段だと思っていただけると幸いです。これよりももっと良い方法を自分たちで作っていければ、もっとよりコミュニティ活動及び貢献が活発になるのではないかと考えています。