前回書いた通り、DjangoCongress JP 2018にて発表しました。
DjangoCongress JP 2018
ただ、カンファレンスでの発表は未経験だったので、ゼロから準備をしました。
今書かないと忘れてしまいそうなので、発表するまでの準備を振り返ってみます。
なお、CfPを出した時点の、自分のスペックは以下の通りです。
- Blog書いているので、文章を書くのは苦にならない
- 話すのは苦手
- 勉強会でのLTは経験あるが、毎回やっても緊張が解けない
- 45分のトークは未経験
目次
- 長いのでまとめ
- CfP出すまで
- タスク洗い出しとスケジュール化
- 発表方法の調査
- プレゼン小道具の検討
- 一般的なスライド量の把握
- スライドの作成
- 発表の素振り
- あきらめた発表スタイル
- Marpについて
- 前日
- 当日
- まとめ
長いのでまとめ
- CfP・スライド・動画が公開されているPyCon JPの情報はありがたい
- 2012年〜2017年まである
- 発表資料作成は、Marpさまさま
CfP出すまで
社内のCfPネタ出しにて、sin_tanaka からMiddlewareネタでいけると言われました。
(ヾﾉ･∀･`)
と思ったのですが、ネタをもらったのに何もしないのは良くないと考え、CfPを提出することにしました。
とはいえ、CfPを書いたことがないのでフォーマットを探しました。
PyCon JPのサイトを見ると、プロポーザルリストがありました。
https://pycon.jp/2017/ja/proposals/vote_list/
そこで、PyCon JPのプロポーザルに従って、以下のプロポーザルを3/5に出しました。締切直前...
対象レベル： 初級 説明： Djangoでアプリケーションを作る際、全部のリクエスト/レスポンスをフックし、何か処理を行いたいことがあります。 例えば、全画面でログイン必須にするとします。この場合、全部のViewに対してデコレータ・Mixinを追加しても良さそうです。 しかし、その場合、同じような処理を複数箇所に書くことになります。その結果、新規作成やメンテナンス時の作業漏れにより、不具合が発生する可能性があります。 そうならないための仕組みとして、DjangoにはDjangoミドルウェアという仕組みがあります。これを使うことで、リクエスト/レスポンスをフックして、自分の処理を追加できます。 また、DjangoはWSGIに沿ったフレームワークのため、WSGIミドルウェアを使用してもリクエスト/レスポンスをフックできます。 そこでこのセッションではDjangoにDjango/WSGIミドルウェアを組込む例を示しながら ・なぜDjango/WSGIミドルウェアを使うのか ・Djangoミドルウェアとは ・WSGIミドルウェアとは ・WSGIとは ・ミドルウェアを複数組み込んだ時の動作順 ・ミドルウェアでの例外ハンドリング ・Djangoミドルウェア/WSGIミドルウェアの実例 などをご紹介します。 話せないこと： ・凄いDjango/WSGIミドルウェアを作って公開した経験や話 備考： 以前ブログに書いた内容を元に、最近のDjangoに追随した内容を予定しています。 http://thinkami.hatenablog.com/entry/2016/12/13/061856
その4日後、
の連絡をいただきました。驚きました。
タスク洗い出しとスケジュール化
ボーっと過ごしているとあっという間に本番を迎えそうだったため、タスクの洗い出しとスケジュール化を行いました。
弊社内のGitLabにリポジトリを作り、Boardを使ってタスク化しました。
今振り返ると、スケジュールを破ったものが多いですが、タスクの洗い出しができていたため、そこまで焦ることはありませんでした。
発表方法の調査
カンファレンスでの発表方法について、そもそもよく分かっていないことに気づきました。
そこで、PyCon JPのサイトを見たところ、過去の動画が公開されていました。
https://pycon.jp/2017/ja/schedule/
そのため、それらの動画を視聴し、流れや雰囲気などを確認しました。
また、合わせて近隣の図書館に出かけ、タイトルに プレゼン や 発表 と名前が付いている書籍を読みました。
乱読するうちに、発表は
- TEDっぽいの
- 企業間のコンペっぽいの
- 学会発表っぽいの
の3種類に分かれそうだと気づきました。
今回のDjangoCongress JPネタの場合、学会発表が一番近いだろうと感じました。
そのため、学会発表 と書かれているものについても読むことにし、最終的には20冊くらいになりました。
複数の書籍を読んだことで、どの書籍でも言われていることを中心すればハズレがなさそうとの実感を得ました。
当日も、「理系のための口頭発表術」をお守り代わりに持っていきました。
理系のための口頭発表術―聴衆を魅了する20の原則 (ブルーバックス)
- 作者: R.H.R.アンホルト,鈴木炎,I.S.リー
- 出版社/メーカー: 講談社
- 発売日: 2008/01/22
- メディア: 新書
- 購入: 11人 クリック: 144回
- この商品を含むブログ (62件) を見る
プレゼン小道具の検討
動画や書籍を見たり、軽くプレゼンの素振りをするうちに、プレゼン小道具がいるかもしれないと思い、検討してみました。
プレゼンター
動画を見るとプレゼンターを使っている方がいたため、どんな機能が必要か考えてみました。
スライド切替
スライド切替なしでもいけそうでした。
ただ、当日の緊張を考えると、スライドの進むボタンを押せばいいだけになるスライド切替器が欲しくなりました。
レーザーポインタ
スライドで説明している部分を指すのがあると良いかなと思いました。
ただ、当日の緊張を考えると、ポインタ位置がブレブレになり見づらくなるだろうと考えました。
そのため、今回レーザーポインタはやめておきました。
最終的に用意したもの
ロジクールの R400t です。
- 出版社/メーカー: Logicool(ロジクール)
- 発売日: 2014/01/31
- メディア: Personal Computers
- この商品を含むブログを見る
大きめで握りやすいのと、スライドを進めるボタンが押しやすそうということで選びました。
サポートOSにはMacの文字はありませんでしたが、ドライバをインストールしなくてもそのまま使えました。
R400tにはレーザーポインタ機能がありますが、前述の通りレーザーポインタは使いません。
そこで、指し棒を使えば、スライドで説明している部分を指せると思いました。
ただ、片方の手にハンドマイク、もう片方にR400tを持つと、手が足りません。
都度持ち替えすることも考えましたが、当日の緊張を考えると、持ち替える時にそれらを落とす可能性が高そうでした。
仕方ないので、指し棒は使わず、
- 位置を示す必要がないくらいまで、スライド中の情報量を減らす
- 減った情報量は、スライドの枚数を増やすことで、全体の情報量は変更しない
とスライド構成でカバーすることにしました。
時間配分表
時間厳守するために、何らかの方法が必要でした。
そんな中、以下の記事を目にしました。
岡山で「ITエンジニアの生存戦略」について話してきました #oso2018 - give IT a try
この中の「60分ちょうどで発表を終わらせるコツ」にて、時間配分表について書かれていました。
まさにこれだと感じ、自分も用意しました。
とはいえ、前日のホテルで気づいたので、ホテルのWindowsとプリンターを借りて出力しました。
そのWindowsにはOffice系のソフトが無かったため、ワードパットを使ってフォントサイズを調整しつつ、何とか出力しました。
なお、失敗したのは、時間配分表の書き方でした。
時間が増える形式で書いたものの、会場のプレゼンタイマーは時間が減っていく形式でした。
そのため、発表しつつ残り時間を計算するハメになりました。
一般的なスライド量の把握
45分の場合、どれだけ枚数を用意すれば良いのか分かりませんでした。
そこで、PyCon JPのトーク時間とスライド量を調べてみました。
その結果、自分の説明能力であれば80枚前後を用意すれば何とかなるという目安が得られました。
とはいえ、実際に書いてみたところ、最終的には105枚になってしまいましたが...
スライドの作成
PowerPointのようなプレゼンソフトにいきなり書いていく場合、全体像が見えなくて苦しむだろうと考えました。
そのため、Blogを書くような感じで
- 目次を作成
- 目次に従い、Markdownで内容を追加
という順で作業を行いました。
また、スライドの形式で見れば気づくことも多そうと考え、Markdownをスライド化できるMarpを使いました。
Marp - Markdown Presentation Writer
元データがMarkdownだったので、資料のページを入れ替えるなども楽でした。
なお、スライドを書いている時点では、Marpを使った発表は考えていませんでした。現時点(v0.0.12)では、プレゼンテーションモードが搭載されていないためです(pdf書き出しは可能)。
発表の素振り
1週間くらい前に、ひと通りのスライドができあがったため、発表の素振りを始めました。
スマホの音声レコーダーを使いながら、スライドを読み上げました。
その際、詰まったところや説明しづらいと気づいたら、随時、音声レコーダーを一時停止しつつスライドの修正を行いました。
最初の頃、読み上げとスライドの修正を別の時間でやろうとしたら、スライドの修正箇所を忘れてしまったこともあり、これはやってみないと分からないと感じました。
とはいえ、最初は読み上げるのが手間であり、積極的にやろうという気にはなりませんでした。
ただ、素振りを繰り返していくうちに、話しやすいスライドに修正されていくことに気づき、これは良いとの実感を得ました。
そのため、時間をみて素振り & 資料修正するようになりました。
10回を超えた頃からだいたい内容が頭に入り、長さがバラバラだった発表時間も安定するようになりました。
素振りの回数は発表の得手不得手により変わってくるかと思いますが、自分はこれくらいやらないとダメでした。
あきらめた発表スタイル
素振りを繰り返すと、自分にできることとできないことが大体わかってきました。
あきらめたスタイルは次のようなものです。
スライドの量を減らして、口頭説明多くする
元々アドリブが弱いため、口頭説明を臨機応変にやると失敗すると感じました。
そのため、スライドに内容をある程度書いて、あとは読み上げていくスタイルにしました。
とはいえ、素振りして何となく覚えてしまったものは、スライドから削除していきました。
落ち着いた語り口
緊張すると早口になるため、落ち着いた語り口にしようと考えていました。
しかし、どうやっても緊張がとれません。
そのため、時間配分表を見て、あまりに早い場合には軌道修正しようと考えました。
ウケを狙う
日頃できないものは無理なので、あきらめました。
Marpについて
今回はMarpで書き出したpdfを使いました。その経緯や対応は以下です。
プレゼンツールの選択(Marp & pdf)
だいたいの内容が固まった3日前くらいに、PowerPointなどのプレゼンツールに移植しようと考えました。Marpにプレゼンテーションモードが無かったというのもあります。
ただ、何も設定していないPowerPointだったので、フォントの用意やマスタースライドの調整など、移植するまでに時間がかかりそうでした。
そのため、Marpでスライドをpdf化し、Adobe Readerのフルスクリーン表示で発表することにしました。
Marpのテーマ変更
MarpのGaiaテーマを使うことで、パッと見、いい感じのスライドになりました。
ただ、MarpのGaiaテーマで気になったのは、ソースコードの背景が黒だったことです。
黒背景はターミナルっぽくて良いのですが、過去の知見より、会場の光量によってはスライドが見づらくなると感じました。
そのため、以下の内容でテーマを変更しました。
- 黒背景から、白背景へ
- バックのグラデーションをとりやめ
- 色数を減らすため、シンタックスハイライトを
sunburstからgithubへ
なお、Marpでのスタイル変更は、以下の記事が参考になりました。ありがとうございました。
また、変更したテーマは、Marpをforkして、ブランチ theme/thinkami の中に入れてあります。
https://github.com/thinkAmi/marp
前日
書籍「理系のための口頭発表術」に、「発表練習は前日夜にはやらない」と書かれていたため、前日朝を最後に練習はやめました。
社内Slackが資格試験で盛り上がっていたので自分も参加してみたり、フラフラ散歩していました。
当日
当日は、緊張のために食欲もそんなにわかないだろうと思い、ベーグルとゼリー飲料を持ち込みました。
その時間になると、案の定、緊張してました。そのため、食欲がありませんでしたが、飲み込みやすいものだったためお腹にものを入れることができ、空腹を避けられました。
この時間が一番緊張する...
— thinkAmi (@thinkAmi) 2018年5月19日
また、時間配分表のおかげで、前半遅れたのを把握できたので、後半調整できました。そのおかげで、1分くらい残して発表を終えました。ただ、質疑応答の時間が取れずに申し訳なかったです。
発表の結果については、前回の記事にも書きましたが、好意的な意見が多くてホッとしました。
まとめ
再掲となりますが。
- CfP・スライド・動画が公開されているPyCon JPの情報はありがたい
- 2012年〜2017年まである
- 発表資料作成は、Marpさまさま
めったにない経験ができて、とても楽しかったです。ありがとうございました。
