より良いLT資料を作る時に心がけていること3箇条

この記事は登壇者 Advent Calendar 2017の21日目の記事です。

この記事ではより良いLT資料を作る時に心がけていることの中で特に重要だと思っていること3点について書こうと思います。

対象者が明確か

登壇する目的は人によって違うとは思います。アウトプットして成長するため、他の人に知ってもらいたいから、とりあえずドヤァって言ってみたい、など…。いずれの目的にしても、普段ペルソナを想定してプロダクト開発を行っているように、このLTは誰のためのもので、その人はどんな話だったら興味を持って聞いてくれるのかを考慮した上で作った方がより良い資料になると思います。

例えば同じiOSの勉強会でもオーディエンスに初学者が多いのか上級者が多いのかによって、前提の話がいるかいらないか、この単語を説明なしで使って良いのか悪いのかが変わってくると思います。そのような意味では、もし事前にわかるのであればオーディエンスの属性は把握しておいた方がいいと思います。私が失敗した事例としては、とある勉強会でSwiftLint（自分のプロジェクト内のSwiftコードがコーディングガイドラインに沿っているかどうかを静的解析してくれるライブラリ）について発表したのですが、冒頭でチーム開発をしている人がどれくらいいるか手を挙げてもらったところ、ほとんどいませんでした。つまりSwiftLintを使うメリットがあまりない人達ばかりで、ちょっと失敗したなーと思いました。

共感できる内容になっているか

例えば「なんかすごい機能が追加されたから紹介してみるよ」という内容のものは、おそらく単に紹介するだけでも興味を持ってもらえると思うのですが、「これをこんなアプリで、こんな箇所で使うと効果的だと思う」というユースケース、メリットを提示するとイメージしやすく、自分ごととして捉えてもらえるのではないかと思います。

他に、共感を誘うという意味ではジャパネット方式と私が勝手に呼んでいる方法が参考になると思います。身近な困りごとを例に出して「皆さんこんなことで困ること、ありますよね。そこで○○の登場です」のように困りごとを共有することで目線を合わせることができます。

見づらいスライドになってないか

最後は見た目の話です。見づらいと気が散ってしまうので最低限の体裁は整えておきたいです。よく話に上がるのは文字サイズ、文字色です。場合よっては会場の大きさによって文字サイズの微調整は必要かもしれません。特にコードに関しては小さく、見づらくなることがあると思います。どうしてもスライド上での調節が難しそうだったら登壇する前に資料を公開しておき、手元で見てもらうようにするのも一つの手だと思います。

あと単語の途中で改行が入らないようにすることも地味に気をつけてます。できるだけスラスラ読むことの妨げになるようなことは排除しておくべきかなと思うので毎回チェックはしてます。

最後に

LT資料を作るとき、上記に挙げたこと全てを常に満たしていなければならないということではありません。紹介する中身によって気にしなければいけないことは変わってくると思います。いずれにしても資料を作り終えたら一度俯瞰して「良い」資料になっているかはチェックするといいと思います。