1. はじめに
株式会社 Hogetic Labの古畑です。
今回、Googleが主催したイベントにて、Looker 運用の典型的な失敗ケース（やってはいけないこと）と、その解決策をテーマに登壇させていただきました。
詳細についてはNDAの関係でお伝えすることが難しいのですが、本記事では今後登壇を考えられている方に向け、登壇準備の流れや過不足なく喋る方法についてお伝えしたいと思います。
筆者経歴
- 社会人6年目、ビジネス職として新卒入社後データアナリスト／データサイエンティストに
- 中学生・高校生時代に、生徒会長として1,000人規模の登壇・演説を複数回経験
- コロナ禍もあり、社会人としての登壇は今回が初めて
登壇のきっかけ
- 自分のキャリアを考えた際に、業務の幅を広げる上で外部発信は大事だと感じていたこと
- 組織の方向性として、登壇などの外部発信が推奨されていたこと
- Googleのパートナー企業で勤務しているため、従業員の登壇履歴が評価されること
- 特にGoogle Cloud Partner Top Engineerというプログラムの審査基準の1つであること
2. 登壇の概要
- 概要 ： データやAIについての事例やデモ、ソリューションをご紹介するイベント
- 開催形式： リモート
- 聴講者 ： 100〜200人（主に技術職）
- 持ち時間： 10分
前述の通り、Looker 運用の典型的な失敗ケースと、その解決策についてお話ししました。
Google Cloud に関する内容であればテーマは自由であったため、自分が専門的にお話しできる内容としてこのテーマを選びました。
3. 登壇準備の流れ・心得
今回の登壇に向けて、以下のような流れで準備を進めました。
どのようなことをしたか振り返りつつ、それぞれのフェーズで「必要なこと」をご紹介します。
1. ターゲット層を明確にする
2. メッセージを3つに絞る
3. ストーリーラインを作る
4. 登壇資料を作る
5. ひたすら練習する
ターゲット層を明確にする
ターゲットが明確だと、登壇資料を作る上で以下を判断しやすくなります。
- 登壇資料作成を進める上での技術専門用語のレベル感
- それぞれの技術的工夫に詳細な説明が必要か不要か
最初にやることは、自分の登壇が「分かる人だけが分かる専門的なもの」か、「専門外の人でも分かるようなもの」かを決めることです。
今回はLookerを利用していない人も参加するため、「専門外の人でも分かるようなもの」と決めた上で、次のステップに進みました。
メッセージを3つに絞る
メッセージが明確だと、以下のように資料作成にかかる時間を大きく減らし、登壇内容をスリムにすることが出来ます。
- 大量の関連しそうな情報の中から、何を盛り込むべきか判断しやすい
- メッセージにマッチしないものを削ぎ落としやすい
ターゲット層を考慮しながら、この登壇を見た人に何を伝えたいのかを決めます。
伝えたいことに関係しそうな情報を思いつくままに書き出し、似た情報をグルーピングしながら3つにまとめていきます。
ストーリーラインを作る
メッセージが決まったら、その中から特に伝えたいことを集め、1つのストーリーラインにまとめていきます。
その際に最も重要なのは、「聴講者にとってわかりやすい流れか」ということです。
ストーリーラインを作る上で、気をつけたポイントが以下の2つです。
- 登壇者にとっての「常識」を削らない
略語や固有名詞などは、理解を妨げるので、都度説明を入れるかそもそも削るべきです。例： 「QA」 → 「Quality Assurance（品質保証）」のこと？ 「Q&A」のこと？ - 無理に時系列順で話そうとしない
登壇者が時系列通りに話そうとすると、かえってわかりにくくなってしまいます。例： 「この課題を解決するために手段Aは〜でダメで、Bも〜でダメで、Cも〜が難しくて、結局Dに落ち着きました」 → 「この課題を解決するためには手段Dが最適でした」
登壇資料を作る
ストーリーラインが定まったら、その内容をスライド化していきます。
ここまでの準備がしっかりと出来ていれば、スライド化すること自体はさほど難しくないと思います。
以下の点に気をつけて、ストーリーラインをスライドに起こしていきます。
- 登壇先・社内で公式のスライドテンプレートがあるのか
- 公式にスライド用に配布されているイラスト素材/ロゴ素材があるのか
- 完成した資料を誰に確認してもらうのか、誰に承認をもらうのか
特に重要なのは、主催者側の意図と自身の主張をうまくすり合わせること、最悪の場合でも修正できるスケジュールを確保することです。
（自戒を込めて、初稿では「攻めた」メッセージ・資料にしてしまい、NGを頂きました…）
ひたすら練習する
どれだけいい話でも時間をオーバーしたり、大幅にショートすれば台無しになってしまいます。
まずは時間配分を意識して、全体のボリュームをある程度整えます。
作成した資料を見ながら素の状態で喋り、かかった時間を測ります。
時間をショートした場合
-
持ち時間に対してスライド・内容が少なすぎる
ストーリーラインが崩れない程度に、スライド・内容を追加します。
一般的には全体に少しづつ足すよりも、メッセージごと追加した方がわかりやすくなる場合が多いです。 -
人前で話すのが怖い・早く終わりたい
「登壇」と考えず、「自己紹介」や「登壇後の交流を助ける時間」と考えるようにしましょう。
例外はありますが、聴講者はあなた自身ではなく、情報そのものに興味があります。
登壇中は皆黙って話を聞いてくれる上に、途中でツッコミは飛んでこないので、自分のペースで話ができます。
情報を元に相手から話しかけてもらうために登壇すると考えると、落ち着いて話すことができます。 -
スライドの文章をそのまま読んでしまう
原稿やスライドを用意せず、何度かシミュレーションを繰り返します。
繰り返す中で、何度も出てくる言葉があることに気がつくはずです。
これが一番話したいことなので、それらをピックアップして「あらすじ」として頭に入れ、発表に追加します。
時間をオーバーした場合
-
持ち時間に対してスライド・内容が多すぎる
ストーリーラインが崩れない程度に、スライド・内容を削ります。
一般的には「情報の正しさ」を担保するだけのスライド・内容は削除した方がわかりやすくなる場合が多いです。 -
「え〜」「あの〜」などのフィラーが多すぎる
「練習あるのみ」な部分もありますが、大きな声で話すのが有効です。
いつもよりハキハキと口をしっかり動かして、声を飛ばそうというイメージで話すだけで、「え〜」「あの〜」と言ってしまう回数が減ります。 -
話があちらこちらに飛んでしまう
例外はありますが、聴講者はあなたの話そのものよりも情報を持ち帰りたいと考えています。
そのため、できるだけ情報を「ひと言」で話し、間を接続詞でつなぐことを意識してみます。例：「まずAである。さらにBである。一方、Cである。以上より、Dが正しいことがいえる。」このままでは淡白なので、話の構造を壊さない範囲で、面白い要素を追加していきます。
各ポイントを意識しながら、時間ぴったりに終われるように練習を繰り返します。
4. 感想・まとめ
今回の登壇を経験し、登壇することの価値を改めて強く認識しました。
この記事を通じて、皆さんにもその魅力が伝わっていれば嬉しいです。
エンジニアが登壇することは、自社の技術や組織を広く知ってもらう重要な手段です。
登壇者にとっても、説明するために深く調べること、伝わるように話すこと、フィードバックをもらうことは学びにつながります。
加えて登壇者・聴講者の交流により、業務のモチベーションが向上することもあります。
- 勉強会に参加したことはあるけど登壇したことはない
- 登壇したことはないけど興味がある
- 登壇してみたいけど自信がない
という方も多いかと思いますが、このブログが皆様の背中を押す一助となっていれば幸いです。
私自身も今後、より挑戦的なテーマや大きな舞台での登壇を目指していきます。
最後に宣伝ですが、弊社はGoogleの生成AIパートナーとして、Google Cloudの活用およびデータ分析の民主化に取り組んでいます。
データアナリスト・データエンジニアをはじめ各ポジションでの採用も行っておりますので、ご興味がある方はチェックしてみてください。
Discussion