generated at
プレゼンテーション
事前準備から終わった後にいたるプレゼンテーションに関する全行程が苦手なので良かったこと・悪かったことをメモしていく

いろんなものを参考にしているが鵜呑みにせず自分が良いと思うものを取り入れていく

準備
とにかく安心するためにやれることをやる。プレゼンは準備で質が決まる
スライドの完成は準備完了ではない
一週間前に資料ができている
練習
3回は通しで練習する、発声するとベター
人に聞いてもらってフィードバックをもらえると良い
知見のある人
間違いを指摘してもらう
知見のない人(こっちが聴衆ターゲットであることが多い)
知的好奇心をくすぐられたかどうか
過不足ないか
前提を共有できているか
当たり前のことを説明しすぎていないか
内容
まず何よりも先に「誰に」「何を」伝えたいかを決める
誰に
聴衆、ターゲット、すなはちどんな人に聞いてもらいたいかを明らかにする
「あ、自分のことだ」と思ってもらうことで関心が向く
あまりにありきたりなターゲット設定(「全エンジニア向け」etc.)は逆に"薄い"と思われる
何を
話すこと、話さないことを明らかにする
2トラック以上で進行するイベントの場合、聴衆には裏番組を聞きに行く権利がある
最初の時点で「あ、違うな」と思ったら移動してもらうのも優しさ
「それでも残る」という選択をした人の満足度を上げる
残るという選択をさせることで「この選択は正しいはずだ」という確証バイアスも働くかもしれない
ネタ
面白ネタは無理して入れない
発表者が話す内容に対して知的好奇心を持って面白そうに話せばそれで十分
あるコミュニティでしか通じないハイコンテクストな話は避けたい
権利関係
ライセンスをチェックする
止めといた方がいいやつ
アニメネタ
漫画ネタ
見せ方・デザイン


発表直前
ハッシュタグを確認する
資料を事前にTwitterで放流しておく
細かい字やコードは後方では見えない可能性が高いので参照してもらう
可能なら待ち時間にアイスブレイクする
タイムテーブルを無視して始めたと思われないようスタッフに許可を取る


発表
最初に必ず聴衆の反応を見る
「こんにちは」でもなんでも良い
「こんにちは」に発声して返事してもらうことは期待しなくてよい
発声するのめんどくさいので強制されるといらっとすることもある
一回聴衆をちゃんと見て冷静になる
ずっとPCを見つめたままの発表にならないように
「喧嘩するときは相手の靴を見ろ」
言い訳・ネガティブ発言は避ける
「資料つくったばっかで…」
「当たり前のことですが…」

LT
時間がもったいないのでWe're hiringしない
自己紹介
時間がもったいないのでしなくて良いと思う
流れが不自然でない限り自己紹介は最後にする
開始時点では聴衆は自分に興味ない
LTの内容が良かったときだけ関心を持ってもらえる

発表後
ハッシュタグを頼りにtogatterでまとめる

参考
ストーリー作り
問題提起、問題の分解、個々の考えられる解決法・実際にやったこと・途中で出会った問題、それぞれの問題に共通していた特性、ふりかえりとまとめ
>最後の「それぞれの問題に共通していた特性」がアハ体験になるような、事実を積み上げていったら新たな発見があった!という構成が書いていて/聞いていてテンションが上がる。問題や解決法の再定義とか、つまりどういうことか、とかが決まるとカッコイイ。*7
> この流れが好きなのは、聞き手の脳内モデルと一致しやすいと思っているから。聞き手が知っている、想定できる解決策から開始して、思ってなかった着地点に連れて行かれる。着地点はいいワーディングになっていてインパクトが残る。