発表資料の作り方

エンジニアとして世に出荷されて3年、そこそこ外部で発表してきたのでその時にやってよかったことやメソッドをまとめておく。

過去の登壇歴

SlideShare, Scrapbox, SpeakerDeckにあげてある

基本的に新しいものは全部SpeakerDeck, 資料作る時間無いときはScrapboxって感じに使い分けてる

Sota Sugiura’s Presentations on SlideShare

Presentations by Sota Sugiura // Speaker Deck

sota1235のスライド置き場 - Scrapbox

30min以上話したイベントの登壇歴だとこんな感じです。

• YAP(achimon)C Tokyo 2016(30min)
• PHPカンファレンス2016(LT), 2017(60min talk)
• PHPカンファレンス福岡2016(30min)
• PHPカンファレンス大阪2018(予定)
• 東京Node学園2017(30min)

そもそもなぜ登壇するのか

• プレゼンスを上げるため
• 己を鍛えるため
• 発表駆動開発

で、これを実現するためには価値のある発表をしなければいけないのでやるべきことは価値ある発表をするにはどうすればいいか

そのためにどんなふうにいつも発表内容つめるかって話です。

そもそもCFPを出す前

発表を考えるフェーズに行くためにはまず発表する機会を勝ち取らなければいけない。

自分の場合、発表のチャンスを得るときは2パターンある。

• 発表することが決まってから考えるパターン
  • 勉強会のLTや招待されて登壇する場合は発表が確定してから内容を考える
• 発表内容を決めて応募するパターン
  • 採択されなければ発表できない

発表することが決まってから考えるパターン

この場合、ネタの出処は普段から貯めてたネタ倉庫から引っ張るか新しく考えるかのどちらか。

前者の場合はScrapboxで#発表ネタってタグをつけて思いついた時に殴り書きしておいて、それを引っ張る感じ。

ほんとに些細なことでも発表できそうだったら書き留めてて、どうせ発表しないのでいくつか出すと例えば俺の考える最強のcomposer scriptとかジョークRFCを紹介とかが私の手元にある。

ネタをそこから引っ張るかどうかは発表することが決まった時に

• その発表のニーズとして相応しいか
• 自分が発表したいと思えるか
• 他の発表、もしくは直近で流行ったネタとかぶらないか

を基準で考えてる。

発表内容を決めて応募するパターン

→ 発表考える時の流れのCFPづくりにスキップする

発表考える時の流れ

CFPづくり

いろいろ試行錯誤したあげく、今はこんなテンプレートを作ってそれを埋めてく形で発表テーマを考えてる。

順番に説明する

タイトル

一番肝心なもの。

以下のことを満たせるよう意識する

• 何を話すのか分かる
• シンプルで短い
• 引きが強い
  • ただし釣りタイトルにならないようにする

迷ったら過去の偉人達の発表タイトルを眺めるとアイディアが出てきます。

Abstract

発表が既に決まっている場合はこの項目は不要。

基本的にはCFPを提出する時にセッションの概要を200字程度で説明してくださいと言われるあの部分。

ここが完成するのは一番最後になる。

ターゲット

この発表を誰に聞いてほしいのか考える。

初級者に聞いてほしいのか、上級者に聞いてほしいのか。

どんな問題を抱えてるエンジニアに刺さる発表なのか。

持って帰ってもらうもの

この発表を聞いたあと、聴衆が持って帰ってもらうものは何になるのか決める。

自分はよく明日から◯◯できるようになってほしいみたいな切り口で考える。

アジェンダ

超ざっくりアジェンダを考える。後で変わっても全然いい。

ここがすんなり書けないとそもそも話せない内容の可能性が高いのでこのタイミングでテーマの見直しをしたりする。

テンプレートを3章立てにしてるのはスティーブ・ジョブズ 驚異のプレゼンという本を読んだ影響で、聴衆に対するガイドラインとして一番適切な個数だからです。

実は3章立てはまだ2回くらいしかやってないんですが、今の所とてもやりやすく感じてる。

タイトル、ターゲット、持って帰ってもらうもの、アジェンダが決まったら

この4つを元にAbstractを完成させる。

CFPを提出する先に文字数を指定されてる場合はそれに合わせるが、指定されてない場合は100~300文字ぐらいが目安かなと思う。

最初はノリがわからなかったりするので過去のカンファレンスのトークのAbstractを参考にするとよい。

私は最初の頃はYAPC::Asia Tokyo 2015のトークを参考にした。

例として出すと、今まで私が考えてもりもりに持ったAbstractはこんな感じ。(PHPカンファレンス福岡2017の時のやつ)

近年Webに関する技術は非常に多様化しており、サーバサイドエンジニアであっても求められる技術の幅は急速に広まっています。
その1つとして大きな武器となるのがJavaScriptですが、ベンダー依存や非同期処理、トリッキーな言語仕様等に戸惑うエンジニアも少なくないのではないでしょうか。
そこでそこに対する1つの解として、JavaScriptの世界に型の概念を取り入れることのできるfacebook製静的ツールであるflowtypeの紹介を行います。

このトークで学べることは以下の点です。

・flowtypeの概要
・flowtypeのできること、できないこと
・flowtypeで得られる恩恵

そのためにお話する具体的な内容は以下のとおりです

・flowtype概要
・flowtypeを導入すべき場面、別ツールとの比較
・flowtypeで実現する堅牢な設計パターンをいくつか

このトークを聴くことでJavaScript、ないしはflowtypeに興味を持ってもらい少しでも世界を広げてもらうことを目標とします。

また1からJavaScriptを始める人に限らず、今書いているコードを改善したい方にも価値のあるトークにすることも目標とします。

アウトラインづくり

CFPが通ったらアウトラインを作る。

発表が決まってる場合はターゲット、持って帰ってもらうもの、アジェンダだけ決めてアウトラインづくりに入る。

アウトラインは箇条書き形式で書ける何かでざっくり書くのがいいと思う。

イメージ的にはトップレベルが1枚のスライド見出し、その下がスライドの内容という感じ。

flowtypeの発表の時だとこんな感じ。

アウトラインは下書きみたいなものとして、余計かもと思うものでもガンガン書き足していく。

アウトラインづくりの流れは以下のような感じ。

• 1つの文章＝スライドの意識で箇条書きで最初から最後まで書いてみる
• ざっくり流れが違和感がないか、何かしらのストーリーがあるか見てみる
• 大丈夫そうなら1つ1つの文章の下に箇条書きで内容を肉付けしていく
• その過程で絶対「このスライドはいらないな」とか「これはもっと詳しく説明したい」となるのでそれに合わせて添削する
• 8割くらい完成したらスライド作り始める
  • これは人によるのかも
  • 自分の場合、7割見通せれば後はスライド上で流れを手直しするほうが楽なのでだいたい8割目安です

スライドづくり

作ったアウトラインをスライドにしていく。

自分の場合はKeynoteを使うが、何使っても特に何か変わるわけじゃないと思う。

基本的な流れは以下。

• タイトルと3章のアジェンダスライドを作る
• アウトラインのトップラインの文章分だけスライドを足す
• 一枚目から順番にアウトラインを元に作っていく

ここが一番疲れるポイントなので、例えばアーキテクチャ図を作るのとかはあとに回すためにTODO: あとでサンプルコード貼るとかTODO: 後でサーバ構成図書くとかやって、元気な時にガッとやるのがオススメです。

特に図はスライドを推敲してる間に作り直さなきゃいけなくなったりして面倒なので自分はかなり終盤にならないと作らない。

練習する

発表慣れしてる人はぶっつけ本番みたいなことしてる人いるけど私はまだ慣れてないので必ず家でスライドを読みながら発表する。

特に事前に原稿は作らず喋ってみる。

するとだいたい「このスライドいらん」とか「ここ足りない」とか気づいたりするので逐一直す。

と同時に時間も測って、発表枠に収まるかきちんと確認する。

人によると思うけど、私の場合は5分枠なら4分半、30分枠なら28分、60分枠なら55分に収まる程度にしておくと本番ではみ出すことはほぼほぼ無いように思う。

足りない分にはまぁいいけど枠をはみ出るとどんなに良い発表をしても「あ、枠はみ出た」感出ちゃって個人的に悔しいのでここは守れるように練習してる。

いくつか悩んでること

カッコいい図を作れない

他の人のスライドを見るとキレイなアーキテクチャ図とか色使いしてるんですが、それがなかなか私は作れず悩んでます。

初期はKeynote上で頑張って、今はSketchにチャレンジしてるんですがまだまだ修行中という感じです。

文字が多くなりがち

これはそうならないようかなり意識してるんですが、どうしても文字が多くなります。

発表あるあるで書いてあることを読み上げるだけ、みたいになるともったいないのでなるべく文章を簡易化＆図を多用するようにしてるんですがなかなか文字が減らないです。

Googleの発表とかは文字がマジでほとんどなくて、図かコードぐらいしか出てこない上にデザインもカッコいいのであれぐらい綺麗に作りたいなぁと妄想してます。

ちなみに

よくMarkdownをスライドにしたいという欲求がありますが私の場合はあまりworkしなかったです。

いくつか理由があって

• 普段、自分用の情報をMarkdownでまとめてない
• Markdown書いてる途中にMarkdownでできないことに脱線したくなる
  • 図を書くとかスライドのカラムの置き方をその場で作りたくなるとか
• GitHubで管理とかしようと思ったけど一覧性悪くていまいちだった

割とスライド作るときはノッてくるとKeynoteとかでリッチになったものを手直ししていくほうが楽しいたちでこうなってるのかなと思う。

雑に作るときとかにMarkdownいいかもって思ってたけど今は全部Scrapboxに上げてるので特に必要じゃないという感じです。

最後に

あくまで個人のメソッドですがおすすめの別の方法なりツールなりあったら教えてください。

特にみんなどうやっていい感じのカッコいいアーキテクチャ図とか書いてるのか知りたいです…