Reject Conのスライド作成時は 登壇資料の作り方 - id:onk のはてなブログ と ストーリー性のあるプレゼン - id:onk のはてなブログ を参考にさせてもらった。自分のやり方と似ている部分もあって、言語化されたものを読んで改めて自己流のプロセスにも型があることを意識した。
喋る内容をテキストで書き出すのは自分もやっていて、今回でいうと「サポートの仕事について話す」というテーマだけ決まっている状態から、登壇が決まってさあ具体的な内容を考えるぞとなった段階で、まず一週間くらい話したいトピックを頭の中で考えてアイデア出しをする。この段階ではまだアウトプットせず、頭の中で想像するにとどめる。想像に任せて、というか妄想半分でぼんやり考えていると連想ゲーム的に話題がつながっていってストーリーっぽいものが浮かび上がったりするので、大事そうなアイデアが思いついたらキーワードだけでも大まかにメモしておく（でないと忘れてしまうので）。
ある程度考え尽くしたかな、というタイミングでテキストとして書き出す。今回は Workflowy を使ったけど、Emacs を使ったこともあるし、Evernote を使ったこともあったかもしれない。書き出す時点である程度話す順番や流れが頭の中にあるので、書き出した後のテキストを色々こねくり回したりはあんまりしない。今回もほとんどアウトラインを並べ替えなかった。なのでここはツールはなんでもいいと思うけど、話の構造（大見出し→中見出し→小見出しみたいな階層とか、話題の順番とか）を把握するためにインデントできること・インデントの変更が柔軟なのは結構重要なポイントだと思っていて、ここが遅いと思考を妨げるので創造性にマイナス。Workflowy（というかアウトライナー）はインデントの操作も楽なので、その点で相性良いツールだとは思う。
テキストの段階で話の構造がだいたいできたらスライドに書き写していく。スライドは「とにかく字をデカくする」ことが一番重要だと思っていて、そのためには文字数が少ない方がいい。なので、アウトラインを見ながらコピペしたり、要約・短縮しながら手で書き写していく。これは単なるコピペ作業ではなくて、この過程が最初の推敲でもあるので自動化・省力化はしていない。この時点で収まりが悪い話題は捨てることもあるし、逆に膨らませてページを多く割くこともある。基本的にページタイトル + ネストした箇条書きというフォーマットで、箇条書きのネストは三段まで、を基本ルールとしている（でかい字でネストを深くしすぎると醜くて読めない）。この段階ではネストさせる枝が空だったり、タイトルしかないページもある（そういうページは大抵、話題自体がイマイチなので手が止まって書けない、ということが多い）。
ほぼ全ての話題（のタイトル）のページができたら、ページをめくりながら内容をパラパラと見て、話のつながり・展開に不自然なところがないかチェックして、適宜スライドの順番を入れ替えたり、できるページから箇条書きのネストを深めて（= 具体的な内容を書いて）いったり、というのを延々繰り返す。と同時に、時間配分のことも頭に入れて取捨選択を考え始める。昔は何ページくらいのスライドを作ればいいか？の目安がわからず悩んだこともあったが、いつのタイミングだったか、実は単純に計算できることがわかってそれ以来ここで悩んだり苦労したりすることが減った。
その秘訣とは：「スライド一枚につき 30 秒〜 1 分換算で、それをトークの受け持ち時間で割る」だけ。20 分トークだったら、一枚 1 分なら 20 ページ、30 秒なら 40 ページ。これは実際にストップウォッチで時間を計りながら読む練習をやると一目瞭然なのだけど、スライド一枚 30 秒というのは実はかなり短い。別の単位でいうと、ゆっくり喋ると一センテンス喋るのに 10 秒前後かかるので、30 秒だとせいぜい 3 センテンスしか言えない。早口で 5 センテンスいければいい方。ページタイトル（そのページの主題）を読んで、箇条書きが三つあって、それぞれにネストしたアイテムが一つずつあって、とかだと文字を読んでるだけで時間を使い果たしてしまう。
これは発表する上でとても重要なことだけど、スライドの文字を読み上げるだけなら口頭で発表する意味はない。参考資料を用意した上で、みなまでは書いてない「意見」や「知見」を語ることに意味があり、聞く価値がある。だから本題であるそちらにちゃんと時間を使いたい。すると書いてある文字は所要時間の半分で読み上げられる程度の分量で抑えたい。むしろ書いてある分量に対して倍の時間がかかると見積もっておくのが妥当。結論、20 分のトークで 20 ページなら確実に時間内に収まる（がよほど一枚ずつが充実してないとだいぶ時間が余る）、ので 30 ページ前後で作っておくとページごとの実測所要時間が多少ブレてもちょうどいい感じに収束する（し、時間が足りなくなって駆け足になってもどうにか格好がつく範囲内でまとめられる）。
で、テキストをスライドに起こすと大抵はページ数オーバーになり、つまり時間に対して話す内容を詰め込みすぎだとわかるので、テーマとのつながりが薄い話題や前後の話題との流れに無理がある話題などを捨てて、想定理想ページ数に収束させていく。ただし、どうしてもこの話題は外せない、というのだけ残った結果何ページかオーバーしてしまうということもあり、そういう場合に無理に削るとそれはそれでストーリーラインがおかしくなってしまうので、早口で頑張るとかページごとに濃淡をつける（じっくり喋りたいページをいくつか選んで、それ以外は浅めにする、例えば書いてある文字すらろくに読まずすぐ次のページへ行くとか）、などの工夫で乗り切る（のだと心に誓って練習を頑張る）。
このプロセスを何度か（渾然一体としたプロセスなので、何を持って一回と言えるのかも微妙なのだが）やると、完成度が上がってきて「読んでてしっくりくる」感じになるので、ここらでテキストとページ割りの編集はひと段落して、図とか写真とかビジュアル要素を（必要な場合は）用意して差し込む作業を主にやっていく。これをテキスト編集と一緒にやると、脳的にも手的にも違う能力を要求される作業なのでだいぶ効率が落ちることを経験で学んだ。なので図が必要なページは画像の代わりに単色の矩形オブジェクトを配置して「ここにこんな感じの図を入れる」などテキストのプレースホルダーを書いておく、などで保留にしておき、ひと段落したタイミングで順番にまとめてやっていく。
ここまで来ればほぼほぼ完成形に近いスライドが出来上がるので、脳内リハーサルをやる。いきなり本番さながらで通しでやろうとしても無理で、なぜかというとここまで編集作業ばかりやってきて脳のモードが「内向きのアウトプット」になっているから、だと思う。発表は「外向きのアウトプット」活動なので、モードを切り替えないといけない。そのために、まずは適当なスライド一枚だけ、とか、数ページ続けて、とか小さい単位でリハーサルする。選ぶ候補は、一番言いたいことについて述べているスライド・パート。なぜなら本番でその部分をこそ一番上手に喋りたいわけだし、その話題について一番たくさん考えてきているはずなので、喋る内容には事欠かないはず。あとは言葉がちゃんと繋がって出てくるようになるまで練習する。
「脳内」リハーサルなので、ちゃんとハキハキ喋らなくていい。ブツブツ・ボソボソでもいいし、囁くような感じでもいい。でも、口を動かさないで完全に脳内だけでやろうとすると練習にならないので、厳密には「脳内」ではない。口を動かした方がいい理由は、思考の速度を喋りの速度で律速しないといけないから。脳内で思考するだけだと速すぎて、話すべき話題以外のことにもどんどん発想が進んでいってしまうので、スライドの練習をしてたつもりが全然違うことを考え始めて数分経っていた、なんてことになる。
そんな感じでパートに分けて練習していくと、なんとなく全体通して話せそうな感じになってくるので、全体を通してボソボソ練習してみる。ここで話題のつながりや展開に違和感があれば手直しし、文言がいまいちなら手直しし、図や写真がイマイチなら手直しし、、、と、納得いくまで・時間の許す限り推敲する。この時点でもスライド一枚全然違う内容に入れ替える、なんてこともあるし、そのくらいなら問題ない。逆に、全体的にしっくりこない、とかだとそもそもテーマに対してストーリーラインがあってないとか、個別の話題のチョイスがあってないとか、根深い問題を示唆していそうなので、その資料を下手にいじくり回すのはやめてもう一度テキストに書き出すところとかから仕切り直す方がいいかもしれない。あと、この段階ではストップウォッチで時間も測って、通しでしゃべると何分かかるのか実測して感触を掴む。
で、これでもう手直しは不要だろう、という状態になったら最後に一回、二回くらい時間測りながら通してリハーサルする。これより前の段階では、時間に収まらなければ削る・余れば盛る、などの手直しプロセスとセットだったけど、この段階ではスライドの修正ではなく話者の喋りの方を時間に合わせる形で調整していく方がいい。全体的な喋りのスピードを速く・遅くしようとか、濃く・薄く扱うスライドを決めにいくとか、思い切って「ここは飛ばします」と言うことにしてしまう、とか（当日喋らないことを決めているスライドであっても、資料の完成度という点では無いと困るはずなので、後で公開することを見越して削らず残しておく）。で、永遠に完璧にはならないので、腹を決めて本番に臨む（逆算で、この最後の練習は前日とか当日？とかにやるのも覚悟が決まる）。
書き忘れてたけど、スピーカーノートについて。自分の場合はスライドを「テーマとキーワードの掲示」のために使っていて、あくまで自分が喋る内容が主役であるというスタンスなので、当日のノリや雰囲気でアドリブなども入れられるなら入れていきたい（前の発表者の話題に引っ掛けて何か上手いこと言ってウケを取るとか）。なので読み上げるスクリプトをバッチリ書いておく、というのはしばらく前からやっていない（かつてやったことも多少あった気がするが、結局途中で読み上げるのはやめちゃった気がする）。なのでスピーカーノートには、スライドに書いてないけど触れたい内容をメモしたりしている。ただし、喋りたい内容の本題は大体頭に入っているし、スライド上の文字から連想できもするのでノートに書いてもあまり有用ではなくて、主題と少しズレるけど余裕があったら話したい小ネタとか例とかを書いたりしている。
要は「重要な内容はスピーカーノートに書くな、頼るな」ということで、というのもプレゼンというのはトラブルがつきもので、会場のディスプレイと繋ぐとどう頑張っても「プレゼンター表示モード」でスライドショーを開始できなくてスピーカーノートが一切見れない！なんてことが普通に起こる。ひどい場合だと自分のノート PC からはまったく映像出力できなくて、急遽 PDF ファイルをエクスポートして転送して他の人のノート PC を借りてプレゼンする、なんてことすらある。スピーカーノート頼みだとそういうトラブルのときにピンチに陥る。理想的には、スピーカーノートの内容も含めて練習ですべて頭に入れてしまって、本番では全部覚えてる・思い出せるという状態に持っていけると盤石。
発表資料を作るプロセスをダラダラと書いていたら長くなったので、ストーリー性については手短に。というか、ここは正直全然ちゃんとロジカルに考えられていなくて、せいぜいロジカルシンキングでいうピラミッド構造を意識しよう、くらい。メインテーマに対して中心的な話題が三つ、各話題についてサブの話題が三つ、みたいなのは奇しくも onk さんのと似た構造だけど、これはやはり 3 という数字がいろいろ収まりが良かったり、それこそ色々なフレームワークなどでもそうなっているから似るべくして似たところはあると思う。
Reject Con のスライドでは「今日話すこと」ページに書いた中心的な話題が 4 つになって、ちょっと収まりが悪いのが個人的にイマイチだった点。と思ったが、これフラットに並べてあるから 4 アイテムに見えるけど「サポートエンジニアの仕事とは」は背景についての導入説明・前座であって残りの三つが本題なのだ、という見方をするとやはり 3 アイテムだった、ともいえる。
人の思考を垣間見るのは面白いし、自分の思考を言語化するのも面白いですね。
