かれこれ N 年エンジニアとして働いていますが、今まで社員の一員とした社外に発表するという機会はあまりありませんでした。 しかし、今年は仕事として社外に発表を行う機会に2回ほど恵まれました（1回は準備まで終わったのですがある理由で中止となってしまいましたが...) 上記のような経験はあまりなく、発表を聞く人が満足してもらうように気をつけたことについていくつか感じた事があったので忘れないようにメモしておきます。 なお、 パワポの使い方 とか 発表資料の中身の話(技術的な話） ではないのでご注意下さい。
実施した発表の内容・前提
自分が今年やった(やる予定)だった発表の内容や前提条件になります。 この内容を踏まえての気づきとなります
- 会社の社員として発表する場合の話（個人で所属を明かさず発表する、というものではない）自分が所属する部署も明かす
- 自分の所属する部署が社外発表をすることはあまりない。別のある部署は社外発表をすることが多い
- 発表することは技術的な話
- 時間としては 30分前後の発表を想定
- 発表タイトル及び発表概要は事前に決めて告知する必要がある
- 発表を聞く人は自由参加なのでタイトル及び発表概要を把握した上で自主的に発表を聞きに来てくれている（無理やり発表を聞いている人はいない）
- 発表の目的は発表を聞いた人が「この発表良かった」と感じて頂けること（製品を売りたいとかではない）
気をつけたポイント
大きく分けて「準備編」「スライド編」として分けてみました。
準備編
どのような場合に満足・不満足となるか考える
「実施した発表の内容・前提」で書いたように今回は発表を聞く人は 自分で良さそうと感じて自分の発表を聞きにきてくれる という状況でした。 その為、ある程度発表自体には興味がある、という前提で考えています。
その上で どのような場合に不満足となるか を考えます。 例えば以下が挙げられると思います。
- 自分が想像していた発表内容と違っていた(例:A について聞きたかったのに A の説明が全くない・少ししかなかった)
- 発表内容は合っていが自分が想像していたより簡単すぎる/難しすぎる
- 発表内容の質が低い(誤字脱字・見にくい、正しくない内容など)
- etc
最後の「発表内容の質が低い」については今回の記事から除外としますが、ざっくりいうと 聴講者が想定した発表と差分がある 時に不満足となると思われます。
聴講者が発表を聞くか聞かないか判断する材料は「発表タイトル」「発表概要」「発表者の情報（名前、部署など)」ぐらいしかありません。 その上で選んで聞きに来てくれるということは聴講者の中で「きっとこんな話をしてくれる」という期待があるわけです。 そこと実際の発表にギャップが有ると不満となってしまう可能性があると考えています。 そのギャップが生まれないように配慮する事でなるべく多くの人が満足できる発表にする事ができると考えます。
どのような人が発表を聞こうとするか考える
自分が発表を聞く側なら 何を期待して自分の発表を聞こうとしているか というのを考えると資料作成時の参考になると思います。
今回自分が発表する予定だった例だと以下の前提が非常に重要だと考えました。
- 会社の社員として発表する場合の話。自分が所属する部署も明かす
- 自分の所属する部署が社外発表をすることはあまりない。別のある部署は社外発表をすることが多い
上記の通り、今回の発表では部署名を明かしており、自分の所属する部署はあまり社外発表をする事がない部署でした。 その為、聴講者は 私の所属する部署らしい発表 を聞きたいと考えました。
別の部署は社外発表をすることが多く、発表内容も素晴らしいです。 その前提で自分が他部署と似たような発表をしても全くおもしろくないと考えます。 また、聴講者もそのような発表は期待していない、と考えます。
上記を踏まえると発表では 自分の部署ならではの発表をする 事を気をつけるようにしようと考えました。また、上記方針を決めた後は、より分かりやすいように発表タイトルにも自分の部署らしい文言を入れることで差別化を図りました。
最初は とにかく良い資料を作らなきゃ と慌ててしまいましたが、上記のように差別化するポイントが明確となると次の段階である どのような発表にすべきか という道筋が決まり、とても役立ったと感じます。
発表タイトル・発表概要を適当に決めない
聴講者は基本的に事前に発表の内容は見れません。 今回の自分の場合もそうでした。
その為、発表タイトル・発表概要は適当に決めず、何回も何回も考えて決めました。 決める際に考慮したことは以下になります。
- スコープの小さい固有名詞をなるべく書く
- 想定聴講者を書く(発表レベルを伝える)
以下より詳細を記載します。
スコープの小さい固有名詞をなるべく書く
聴講者がどのような話をするか具体的にイメージできるようになるべくスコープの小さい固有名詞をなるべく書くように心掛けました。
もう少し具体的に説明します。 例えば「コンテナ運用の知見」という発表タイトルがあったとします。 この場合、聴講者はいろんな想像が出来ます。
- A さん:Kubernetes の運用の知見かな。運用回りとなるとログとかデプロイの話かな
- B さん:(自分の好きなコンテナオーケストレーション)の運用知見かな。トラブルシューティングの話とか聞きたいな
上記のような状況で A さん向けの発表だったとすると B さんは想定した発表と違うので不満足となってしまう可能性が高いです。 上記のような齟齬がないようにするにはなるべくどんな発表をするのか分かりやすくなるように スコープの小さい固有名詞 を使う事が大切だと思います。
例えば先程の発表タイトルを「EKS でのログ運用の知見」とします。これによってコンテナオーケストレーションは EKS(Kubernetes)を使うこと、主にログ周りの話である事が明確になります。この場合 A さんは自分の想定してた話を一部含むので有益そうな発表であるということが分かると共にデプロイ周りの話はなさそうである、という事も事前に理解出来ます。また、B さんは自分の想定した発表とは違いそうだという判断が事前に出来ます。
また、必要であれば「EKS での flunetd によるログ運用の知見」というようにする事でさらにスコープを小さくすることも出来ます。どこまで絞って書くのか、必ず絞り込むべきかというのはケースバイケースだとも思いますが、なるべく聴講者との齟齬をなくしたいということであれば話すことが想像しやすい発表タイトルのほうが無難ではないか、と考えます。
想定聴講者を書く(発表レベルを伝える)
発表といっても色々なレベルのものがあると思います。
- 初心者向けの発表で概要から丁寧に説明する
- 上級者向けで概要などは分かっている前提で発表する
これも聴講者と発表者に齟齬があると不満足となる可能性がある要因だと考えます(初心者向けの発表だと思ったら上級者向けで聴講者が理解できない、上級者向けの発表だと思ったら簡単すぎたetc)
そうならないようにタイトルや発表概要で想定する聴講者の情報を出せると良いと思います。初心者向けの発表であれば [初級]、[入門] というラベルをタイトル文頭に付ける方法などが考えられます。これによって明確に初心者向けの発表であることを伝えられます。
ただ、逆に上級者向けの場合には [上級] というタイトルを入れるの自分の調べた範囲でははあまり見受けられませんでした。また、実際に書くと 何をもって上級なのか が人によって違うのでこちらも齟齬が生まれる可能性があったり、実際には聞いて欲しい想定聴講者でも尻込みして聞いて頂けないなどの可能性もあると考えます。
上記のような場合には想定読者が発表タイトルや発表概要から想定読者やレベル感が読み取れるようにすると良いのではないかと思います。 例えば先程例に挙げた「EKS でのログ運用の知見」だとすると初心者向けではなく、Kubernetes や EKS の基本的な説明はないのではないか、という想像ができます。また、併せて発表概要が書けるのであれば この発表は既に EKS を使って既にアプリケーションを運用されている方向けの発表となります と書けばよりレベル感や想定聴講者も分かるのではないかと思います。また、後ほど書く 前提条件を書く という事も併せてやると良いのではないかと思います。
スライド編
以下よりスライドでどのような事を気をつけたかを記載します。 書いた後に気づきましたが、発表の概要説明が書けるのであればこちらに含めてしまうというのも有益ではないかと考えます。
前提条件を書く
発表スライドでは最初の方で前提条件を書くのも効果的だと思います。 先程例に挙げた「EKS でのログ運用の知見」だとすると以下などが考えられます。
- 前提:コンテナや Kubernetes、EKS の基本的な内容を習得されていることを想定しています
上記のようにすることで発表内容が中級者以上向けの話である事が分かり、コンテナや Kubernetes、EKS の基本的な内容について説明を書かない前提でのスライドとなっている事を明示できます。 残念ではありますが、もし条件に合致しない聴講者がいたとしたらこのタイミングで席を立って頂くことで他の有益な発表を見て頂く、という事が可能です。
また、併せて上記スライドでは既に書いた 想定聴講者を書く(発表レベルを伝える) と同様の情報を改めて記載して、発表を始めたタイミングでも発表者の想定している聴講者を改めて説明出来ると親切ではないかと思います。
発表のゴールを書く
上記前提条件と併せて 発表を聞いた後に聴講者がどうなることを期待しているか というのを書くようにすることも効果的だと考えます。 これには2つの意味があると考えています。
- 聴講者と発表者のゴールを共有する
- 発表者のスライド作成時の指標とする
前者については今まで説明してきたような「発表者と聴講者の差分をなくす」というものに該当します。 後者については 発表者側のスライド作成や修正を行う際にゴールがぶれないこと を想定しています。
技術向けのスライドですが、調べたことや知見は全て書こうと考えて長くなってしまいがちだと思います（少なくとも自分はそうです） そうなった場合、必要ない部分を省く作業や本当に発表内容がゴールと合っているか、という確認が大切であると考えます。 その際に予め発表のゴールを決めておくと楽です。 どこを残してどこを省くかというのは 上記ゴールと合っているか という事で決められるからです。 有用な情報でもゴールと合っていないければ意味のない情報となることもあるのでその時は思い切って省いてしまうことも大切だと考えています。
