TL;DR
- 本記事はLTを行う為の心構えと、資料作成／発表準備に関する話です
- LTをする感覚は人によって違うと思いますので、これは所感です
はじめに
はじめに今回このような記事を書くに至った背景ですが、
先日オンラインで行われたAWS 10分LT会 - vol.3にて、
オンラインでは初めての登壇を致しました。
いわゆる30分程度の発表というのは過去にも何度もやって来ましたが、
実はLTの形式で発表するのは二度目で、
その一度目は社内の定例ミーティングで行ったものです。
それは別のQiitaの記事で簡易的にまとめてあります。
しかしながら、個人的な意見を申しますと、
30分を目安にプレゼンテーションを構築するより、LTの方が難しかったな…と
感じた部分が多分にありました。
そして「LTが苦手」という人が多いというのも分かったので、
何故そういう思想に至るのか、どうすればLTでより良く発表が出来るか、
という点について記載したいと思います。
何故LTを難しく感じるのか？
説明する時間が短いから
いわゆる30分程度の発表とLTで何が一番違うかと言えば、当然時間の問題だと思います。
自分が説明したいと思っている事に対して、大抵の場合は時間が足りません。
勿論レギュレーションによっては10分、15分という場合もありますが、
5分なんて言われたら目も当てられません。
流石に5分は短いと思うよ、正直。
以下の項目でも触れる事ではありますが、
「口下手なので…」と自分で自分を評価する人にとっては、
短時間の発表はハードルが高過ぎる、と感じる事は不自然ではありません。
私は演劇／舞台に携わっていた経験がありますが、
それであっても短時間で上手に何かを伝えるのは難しいと感じます。
時間が短ければ短いほど、難しいのです。
だからこそLTは難しいな、苦手だなと感じても、その考えは間違っていません。
長い時間の発表より短い時間の発表の方が、伝えるのは難しい。
対象者が不特定多数だから
これはどんな長さの発表で登壇しても同じことではありますが、
やはり不特定多数の人の前で発表するのは緊張するし、嫌ですよね。
こういう事が気にならない人は得意だし、気になる人は不得意だと感じる。
どうしたって不得意だと感じる人は、
発表は性格的に合わないな、と思うのは仕方の無い事です。
しかも大勢の傍聴者の前で、短時間の発表なのに詰まったら…
という心配は、当然抱えて然るべきだと思います。
知らない人の前で話すのが得意な人もいれば、不得意な人もいる。
また、対象が不特定多数の為、傍聴者のペルソナが絞り辛いという点も挙げられます。
例えばAWSの話をする際に、EC2やVPCの説明は必要なのか、
説明に必要なサービスを知っている前提で話して大丈夫なのか、
そういう不安も付きまとうので、
どこまで詳細に補足をした資料作成をすれば良いのか、悩むことになります。
説明したい内容を要約した説明が出来ないから
実は、ダラダラ喋るのは結構簡単です。
1から10まで、丁寧に話せば良いのです。
しかしながら、要約して話したり、説明するとした時、
何が要点なのか、どういう所を詳しく話すと効果的なのか、
事前に考えたり、練習したりしなければならなくなります。
正直、面倒ですよね。
垂れ流す方が楽なのです。資料作成も然り。頭の整理自体が面倒なのです。
説明の要約って面倒。
効果的なのは分かるけど、やらなくて良いなら取り掛かりたくない。
自分が効果的に理解して使える状態の知識なら尚更。
短時間での面白い発表にならないから
登壇したいと思った人は、当然いろんな発表を傍聴する機会もあると思いますが、
自分がやった／やろうとした発表が面白くならない、と悩んだことはありませんか？
当然発表の得意／不得意もあるし、テーマの選定も人によって違います。
発表の上手い人や、良いテーマを持っている人には勝てない…
と卑屈になる事もあると思います。
持っている人は持っている。でも、自分らしく発表したい。
賞賛されたい自己承認欲求はあるが、中々上手く行かないジレンマがある。
それでもLTをやるか？
ここまで面倒で、難しいと感じる事も多いLTですが、
でもやってみたい！とか、上手にやりたい！とか思う気持ちもあるのではないでしょうか。
実際に流行っているし、様々なITのシーンで自分もアウトプットしたい、
という気持ちはとても重要だと思います。
ここから先は、LTへの取り組み方等を、自分なりにまとめた部分を記載していきます。
私のLTの方針
私のLTでの基本的な方針を先に記載しますが、
「30分程度の発表で出来る内容を、規定時間にまとめて如何に聞かせるか」です。
私がLTをしよう！と思った時に感じたのは、
「30分あればもっと面白く、丁寧に発表出来るのに…」と感じたことです。
でもここで内容自体を削って時間内の分量に仕上げると、
ボリューム自体を削っているだけで、実態としては伝達量が下がっているだけでした。
内容が少なくなると、発表自体の価値が下がる。
中身が薄い発表は、やっぱり少し味気無く感じてしまいます。
LTにした事で、せっかく発表したい事の総量が減ってしまうのは、
LTで発表する事の価値自体を下げる事に繋がってしまいます。
なので、LTで必要な事は何かといえば、
「いかに時間単位の出力量を上げるか」という事に尽きます。
内容をなるべく削らない事で、価値をそのままに提供出来る。
その上で時間内に収まらない場合は、少しずつボリュームを減らすと良いと思います。
私は今回の発表では10分枠で発表を行いましたが、
作成時点で12分前後の発表でした。これくらいから調整すると良いと思います。
どうすれば良いLTに出来るか？
まずは発表自体の要点を抑える事が重要です。
これは、LTに限った話ではありません。普通に長時間で発表する時でも同じです。
話の目的を定める／プロットを作成する
自分はObsidianにメモとして残しています。
どんな形式でも良いので、まずはどういう話をしたいか、
適切な自分の中での発表のゴールを定めるのが良いと思います。
その後に、全体の構成をプロットとして書き上げます。
これは資料を作成する際に、必ず準拠しなければならない、
というほどガチガチに作成しなければならないものではありません。
実際にプレゼンテーション用の資料を作成する時には、
多少順番が前後したり、加筆したり、項目を削ったりして、調整して良いものです。
ただ、この段階で流れとして不適当な様に感じるのであれば、この時点で直しておくと、
まとまりが無い発表という物にはなり辛いのではないかと感じています。
大雑把で良いけど、後で自分の助けになるので、必ず初めに作っています。
LT向けのチューニング
ここからは、通常の発表資料とは違い、
LT向けにチューニングした場合の資料の作成／発表方法です。
要点と周辺の重みを付ける
まずはなるべく、事前にまとめたプロットを元に、要点を中心にして資料を作成します。
LTでは時間が短いので、全てを伝える事は到底不可能です。
なので、要点は特に重く、周辺は軽くなる様に仕上げていきます。
重みが平坦だと、どこが重要なのか理解出来る前に終わってしまう可能性があります。
適切に要点に重みを振る事により、目的をはっきりと伝える事が可能になります。
いらない説明はしている時間がありません。取捨選択を行います。
時間が短いので、伝えられる事と伝えられない事の切り分けを行う事は重要。
スライド1枚当たりの情報を減らす
情報が多いと、瞬間的に傍聴者はスライドを把握する事が出来ません。
これは出力を上げるという点においては致命的で、
要するにスループットが下がっている、という事です。
発表者はスライド1枚にかける時間を減らしたいのに、
傍聴者はもっと時間をかけて欲しかった、という事態が起きます。
なので、1枚のスライドを情報で一杯にするのは止めましょう。
困難は分割する。デカルトもこの様な事を言っていました。
1枚でパンパンなら2枚にすればいいじゃないか、と。
分かり易さ、読み易さを重視しましょう。
1枚で収まっていなければダメなんてルールはないはず。
そうでなければ、なるべくアニメーション等で、画面内のどこを説明しているのか、
上手く誘導してあげる事が大切です。人間の視線は動く物に反応します。
情報（文字）を減らす／画像で対応する
文字情報は正確ですが、傍聴者はそれを読まなければならないので、低速になります。
高速を目的とするなら、その情報が文字である必要はありません。
音声（発話）と画像（映像）の組み合わせの方が最速になるでしょう。
この辺りの考え方は、有名な記事であるなぜエンジニアが作る画面はダサいのか…?
の思想に近い部分があります。
下にリンクを載せておきますので、良ければ見てみて下さい。
文章を読まない
上記の点についての補足事項ともなりますが、
特にエンジニア向けのLTに参加すると感じる事で、
文字が多過ぎて読み切れない、発話に集中出来ないという場合があります。
逆に、書いてある文章を読み上げられても、
傍聴者が読んだ場合の方が早い、という事も良くあるでしょう。
つまり、文章を読み上げる事は意味がないのです。
伝えたいことの全てを、カンペの様に書きたい気持ちは分かります。
しかし、前の項目で書いた様に、情報は減らした方が良いので、
どうしても伝えたい内容のみ文章を記載し、必要なら読み上げるが適切かと思います。
カンペを書いてそれを読んでいるだけなら、発表者は不要になってしまう。
qiitaに書けば良くね？ってなるのは本末転倒。
発表練習をする
資料の作成が終わったら、とにかく発表練習をしましょう。
これは、普段開発をしている皆さんなら、
「テストの重要性」と言えば分かって頂けると思います。
意外とプログラムがプレゼンに置き換わったら、
テストをする事を止めていたりしていないでしょうか？
発表中に「あー」とか「えー」とか、詰まった経験はあると思います。
LTでは、そもそも時間が短いので、
詰まる事で時間を浪費してしまうのは非常に勿体ないです。
壁打ちのつもりで、発表練習をするのを怠らないようにしましょう。
淀みなく説明が出来る様になると、発表に掛かる時間が削減出来ます。
その分だけ伝えたい事を伝えるチャンスが生まれます。
発表の単位時間が短いのだから、それだけ練習回数は稼ぎやすいです。
傍聴者の時間を奪うくらいなら、まず練習してみて下さい。
練度の低い発表はすぐ分かる。でも洗練するのも、さほど難しくない。
練習をする事で、発表に足りない部分も補える可能性が高いです。
構成が悪いとか、ここはもっと厚く説明した方が良いとか。
必要なら録音／録画等もしてみて、事前に確認出来ると尚良いと思います。
おわりに
LTは登壇しやすい、登壇出来る機会が多いという点では、非常に良い文化だと思います。
その反面、LTで良い発表をしようと思うと、難易度が高い資料作成や
しっかりとした練習や準備が必要かと思います。
私は沢山の時間をかけてLTに挑みましたが、
でももっと軽い気持ちで参加しても良いものだとも思います。
登壇してみるチャレンジも必要だと思います。
それだけで価値のある物です。胸を張りましょう。
最後に、冒頭でご紹介した、私が登壇した資料を以下に載せておきます。
発表内で口頭にて補足している部分が相当に多く、
アニメーションを多用して、飽きさせない工夫をしています。
資料だけ見ても良く分からないという形になっているとは思いますが、
自分は作成した資料を後で見返しても有効である必要は無いと思っているので、
こんな形に仕上げました。
今後もQiitaでの投稿や、別のLTなども参加したいと思っているので、
良ければTwitterもフォローして頂けると嬉しいです。
最後までお読み頂き、ありがとうございました。