先日、de:code 2018 で登壇してきました。
de:code 2015 から登壇させていただいており、気づいたら 4 年連続で登壇しているのですね。
Tech Summit も含めると6 回ぐらいこの規模のイベントに登壇させていただいたことになるようです。
de:code2018で登壇させていただきました。 を見て、自分の場合の、de:code のようなイベントで登壇をさせていただいている際に準備している内容を書いてみようかと。
情報の収集
de:code や Tech Summit は海外で実施された大規模イベントの日本国内版というような位置づけもあるかと思いますので、該当のイベントで関連するセッションを確認していきます。
channel 9 を見て該当しそうなセッションの情報を収集します。
私の場合、SQL Server / SQL Database を担当させていただく機会が多いので、PASS Summit の開催時期と近いタイミングでは、PASS Summit の情報も確認するようにしています。
スライドのノートの利用
登壇時には、
- デモ用端末
- スライド用端末 (プレゼン用端末)
の 2 台が用意され、中央に「投影されている内容と同じ画面が表示されているモニター」が準備されています。
スライド用端末については「発表者ツール」を使用することができますので、私の場合、ノートに次のような内容を記載しています。
上から
- そのスライドの発表の時間
- カウントダウン式で、そのスライドの発表の時間
- カウントアップ式で、そのスライドの発表の時間
を記載するようにしています。
登壇時にはタイマーを用意してくれるのですが、そのタイマーはカウントダウン式のケースが多いので、カウントダウン式でどの時間であれば、そのスライドの発表時間の問題がないかを把握できるようにしています。
カウントアップ式については、自宅でランスルー (本番を想定した通しでの発表練習) する場合、カウントアップ式のストップウォッチで実施しているので、それが把握できるように記載しています。
まぁ、目安時間書いていても、今回 10 秒ぐらいオーバーしたんですが…。
他にもランスルーをしていて、
- 話すことを忘れてしまうことが多い内容
- ポイントとして話すことが重要な内容を単語で記載
しておくようにしてあります。
ランスルーを何回かやっていると「自分が喋ることを忘れてしまうことが多い内容」というのが出てくるのですよね。
それについては、ノートの記載しておくようにしています。
あとはポイントとして話す必要があるものは「用語や短文」で記載しています。
全文書いてもいいのですが、ノートが全倍表示されないこともありますので、最小限の情報にするようにしています。
私の場合、ランスルーは 4 ,5 回ぐらいやるようにしているのですが、回数をこなしすぎると喉にダメージが来ますので、ランスルーの回数はほどほどに。
最近、スピーカーをする機会が多いのでですが、その中で
- 抑えておいてもらいたいポイントとなる内容については抑揚をつけて話してもらいたい
というご意見をいただくこともありますので、内容によってはこの辺も気を付けた方がよいのかもしれないですね。
私の場合、「抑揚なくフラットに話してしまっている」「いつもとは違うペースで話すのでイントネーションが通常とは異なってしまうことがある」というのが問題となっており、改善点であるのはわかっているのですが、講師業を専門に実施しているわけでもないので、中々修正する機会がないですな。
スライドの発表時間の把握
各スライドに発表時間の目安を書くため、私の場合は二パターンでスライドの発表時間を計測しています。
- スライド単位で実際に声を出して発表し、時間を計測
- 全体を通して実際に声を出して発表し、時間を計測
音読でスライドを流すと、実際の発表時間との差が大きくなる (音読だとペースが速いですので) ので、実際に声を出しながら発表する内容のリハを行っています。
スライド単体でやった場合と、全体を通しながら実施した場合では、スライドの切り替え等のタイムラグがありますので、最初はスライド単位で発表した内容で記載をしておき、そのあとに、全体を通したランスルー時に取得した時間で捕捉をしています。
スライド単位で発表した結果、時間が足りなくてお蔵入りスライドなども出てくるので、
- Appendix に追加するスライド
- 「参考スライド」とし、途中に置いておくが当日は軽く流すスライド
- お蔵入りとし削除するスライド
の整理を実施しています。
スライドを進める中で話の流れをブロックしそうなものについては、Appendix に移動して、話の流れの中であったほうがよいスライドについては、参考と記載して残しておき「他にもこういうものがありますが、これはスライドが公開された後にご確認ください」とし、「そういう情報もあることだけ紹介し、後日確認してもらう」というスタンスで進めています。
ランスルーを実施する環境
ランスルーを実施する環境ですが、
- デモ環境を実施する端末
- スライドを表示する端末
- スライドを表示する端末に接続されたサブディスプレイ
があると、本番相当の環境になるかと。
スライドを表示する端末については、サブディスプレイを付けておいた方がよいかと。
発表者ツールって、1 台でデモを含めてプレゼンをするとき、デモの画面を写すのが面倒で、使用しないケースがあるのですよね…。
発表者ツールの使い方に慣れる意味でも、スライドを表示する端末はサブディスプレイがあった方がよいかと。
発表をするときは、自分の背後にスクリーンがあるので、発表者ツールを使用した場合、
- スライド内のペンでの書き込み
- スライドの一部の拡大表示
は「発表者ツール側」で実施することになると思いますので、簡単に使い方は覚えておいた方がよいかと。
(と書いておきながら、毎回使い方忘れるのですが)
当日はデモ環境とスライドを表示する端末をスイッチャーで切り替えながら進めていくのですが、画面を切り替える際は、
- 「デモ画面に切り替えます」「スライドに戻ります」と声に出す
- 実際に投影されているものと同一の内容を表示しているディスプレイを確認する
というような癖をつけておいた方がいいのかなとも思います。
切り替え忘れる / うまく切り替わっていないことが、ことちょいちょいありますので、切り替えのタイミングと操作を意識的に声に出す / 確認するようにしています。
デモ環境の作成場所
デモ環境ですが、Azure で Nested VM が使用できるようになって以降は、デモ環境は Nested VM 上に構築するようにしています。
私の場合、複数台の SQL Server を用意する必要があるのですが、特殊なハードウェアは必要ありませんので、仮想マシンが実行できれば大体は何とかなるのですよね。
デモ用の端末上に構築した場合「何らかの理由で再起動が発生した場合に環境の起動が必要」ということがありますので、デモ用の端末はコンソールのみに使用して、実際のデモ環境は外部に合った方がよいかと。
リハーサルでデモ用の端末がうまく投影できない場合に、再起動してみるというようなことがあると、自端末上にデモ環境を構築していると、デモ環境の起動も必要になってしまい、面倒ということもありますので。
ネットワークは無線ではなく、有線を使うようにしているので、今のところネットワークの不通はなくデモを実施できていますね。
デモ用端末の準備
デモ用の端末は自分の端末を使用しているのですが、次の 2 点は実施するようにしています。
自分の端末でデモを実施していると SNS 連携の通知やブックマーク、入力履歴で変な事故が起きるのも嫌ですので、デモを実施する際に使用する専用のユーザーを準備するようにしています。
通知系はプレゼンテーションモードでブロックできるケースもあるかと思いますので、実施前には有効化しています。
あとはリハーサルの時に
- スライド / デモ環境の文字を最後列から見ることができるか
の確認もするようにしています。
私の場合、
- SSMS
- クエリエディター
- クエリのグリッド表示
- PowerShell ISE
- Visual Studio Code
- コマンドプロンプト
- メモ帳
あたりが、デモで使用するツールなので、これらのツールについて、フォントサイズの調整を行っています。
リハーサルは登壇前日に実施することになり、夜なべして修正することになるので、どちらも調整しきれずに、後ろの方の方には諦めてもらうしかないかなということも多いですが…。
また、デモについては
- キー入力を必要とする箇所を極力減らし、コピー & ペーストか、スクリプトでの実行で進められる
ようにしておいた方がよいかと思います。
キー入力で戸惑うとデモの時間で押してしまうことがありますので。
あとは、
- ランスルー後にデモ環境を初期状態に戻す手順
についてのメモを用意しておいた方がよいかと。
私の場合は、
- 起動しておくツール
- ツールの状態 (開いておくソリューション / URL のメモ)
- 初期状態に戻すためのクエリ / コマンド
を記載するようにしています。
ツールを起動するのも地味に時間がかかりますので、デモの開始時には使用するツールは起動済みの状態にするようにしています。
ということで、私の場合、こんな感じで自室にこもりながら、独り言のようにランスルーをしながら準備を進めていたりします。