0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

伝わる発表資料の作り方

Last updated at Posted at 2024-12-26

こんにちは、おのぽんです。

資料作りをしていると、「どうすればわかりやすい資料を作れますか?」と聞かれることがあります。

PHPのカンファレンス系で過去4回ほど登壇させていただいた際の、おのぽん流の資料作りのポイントを紹介します。

過去の発表資料はこちらです。
https://speakerdeck.com/onopon/tesutokodoshu-itemimasenka
https://speakerdeck.com/onopon/php-src-debug-maniyuaru
https://speakerdeck.com/onopon/coderevieweegaqiu-merarerukoto
https://speakerdeck.com/onopon/codereviewergaqiu-merarerukoto

特にLT(5,6分程度)や20分くらいまでのものであれば網羅できるかなと思うので、参考にしてみてください💡

今回は過去の資料の中でも、自信作である「CodeReviewerが求められること」を題材に紹介します。

1. 伝えたいことを1つに定める

僕は資料を作るとき、まず「何を伝えるべきか」を1つに絞っています。
いつも起承転結を意識して全体のストーリーを考えるのですが、この起承転結の「結句」にあたる部分を先に決めてしまうイメージです。

「結句」(=伝えたいこと)をまず先に決めてしまい、肉付けするような形でどんどん資料を展開していき、説得力を高めるような資料作りを心がけています。
5分LTにおいては伝えたいことが1つでも伝わればOKですし、20分前後の発表においても、多くて2つくらい伝えられることが伝われば良いと思ってます。
ここで大事な要素を3つ4つ5つとたくさん書き並べてしまうと、「結局何が一番伝えたいことだったのだろうか?」と聞いてる側に何も伝わらない資料になりかねません。

そのため僕は 伝えたいことを最低限に留め、その伝えたいことを最大限に伝わるような工夫 をしています。

例えば、PHP Conference 2023において発表した「CodeReviewerが求められること」というスライドにおいて、僕は「今日からできる!Revieweeから求められるコードレビュー術」というスライド1枚を伝えるために62ページの資料を展開しました。

image.png

伝えたいことはこの1枚でしたが、「なぜこのレビューがRevieweeから求めているか」などを順を追って紹介することで、最後の伝えたいことの説得力を高めてまいりました。

2. ゴールはなるはやで伝える

ゴール(この発表でどこまでお伝えしようとしているのか)を先に伝えることで、なぜこのセッションを発表しているのかが明確になり、聞き手に安心感を与えます。

※ ゴールは伝えますが、結論はここでは伝えません

ゴールがない資料は聞き手からするといつ終わるかが見えなくなってしまい、どこまで集中して聞けば良いのかがわからない状況となり、聞き手の不安や疲弊に繋がりかねません。
(出口の見えない暗いトンネルを歩き続けるのと、出口の光が差し込む暗いトンネルを歩き続けるのとではどちらが安心して歩くことができますか?)
ある程度のアイスブレイクが済んだら、ゴールを明言してしまいましょう。

今回の題材の中では、8枚目にセッションのゴールを視聴者に伝えております。
image.png

3. アジェンダを挟む

こちらもゴールを明確にするのと同様で、聞き手に安心感を与えます。
特に20分という時間は、発表者はあっという間に感じても、視聴者にとっては退屈に感じるタイミングもあるでしょう。眠くなるタイミングもあるかと思います。
ゴールのお話と同じように、アジェンダがなくなってしまうと話の流れが迷子になってしまったり、視聴者が大事なことを伝えるタイミングで集中できない状況になる可能性があるので、1ページだけ挟んでおくようにしています。

題材の中でもゴールを伝えた次のページでアジェンダを挟んでいます。

image.png

4. 発表時に定義を揃える

起承転結の「起句」の部分で発表したい題材の定義を紹介し、発表者と視聴者の認識を揃えるようにしています。
そうすることで、その後展開していくスライドにおいて、視聴者がついてきやすくなり、伝えたいことを伝えやすい状態を作ることができます。

題材の中では、「そもそもコードレビューはなぜするのか?」だったり、「Reviewerに必要な心構え」を紹介しています。
image.png

image.png

5. 発表するにあたり努力したことを発表する際は、どれだけ頑張ったかを視覚的に伝える

僕は何か作ったものを発表したり、調査したことを発表したりするのですが、その際やったことなどは起承転結の「承句」にあたる部分で発表していきます。
題材の中では、インタビューを行ったので、概要を説明してからインタビュー結果の考察をまとめていく流れを作りました。

image.png

ここで「苦労や開発の裏話を話しすぎないようにする」ことを心がけています。
「CodeReviewerが求められること」では、エンジニアにインタビューを行い、それらをKA・KJ法を用いて要点をまとめていくという作業を行いました。

この作業はとにかく一番時間がかかりましたし、発表した内容以外にも話せることはたくさんありましたが、すべて割愛しました。
なぜかというと、極論視聴者は僕の苦労話には興味がないからです。
タイトルが「CodeReviewerが求められること」なのに対し、インタビューの苦労話はだいぶ話が脱線してしまいます。
(「エンジニアへのインタビューの苦労話」というタイトルであれば思う存分語っても良いと思いますが、おそらくプロポーザルは不採択となるでしょう笑)

あくまで視聴者に伝えたいことを伝えることが目的なので、そこから脱線する話題や、割愛しても十分伝わる内容であれば容赦無く割愛してしまいます。

しかし、どれだけ大変だったんだよということを伝えたいのも事実。
このタイミング以外で伝えるポイントはないので、視覚的に「これだけ頑張ったよ!」や「これだけ大変だったんだよ!」ということが伝わるようにしておくと、発表の流れの中でスムーズに紹介できます。

題材の中では、「どれだけ大変な作業かが少しでも伝われば」という思いで、KA法とKJ法の実際の様子を表現しています。

image.png

image.png

6. 結句の説得力を増やすための武器をたくさん用意する

起承転結の「転句」では、いかに結句の自分が伝えたいことの説得力を高めるかだけを考え、資料展開していきます。
題材の場合は、インタビュー結果より考察を述べながら、レビューの具体例を紹介しつつレビューコメントを残す際の大事なポイントを1つずつ紹介していきました。
そして最後の結句ですべてのポイントをまとめて1枚のスライドで紹介しています。

image.png


こうした流れを経て、伝わる資料作りを心がけています。
整理すると、僕の作成する資料は大体下記の作りになっています。

  • タイトル
  • アイスブレイク
  • 本セッションのゴール
  • アジェンダ
  • 起:言葉の定義を揃える
  • 承:なぜ発表しようとしているかのモチベーションを語る
  • 転:結句で伝えたいことの説得力を高めるための準備を行う
  • 結:伝えたいことを1つか2つに絞りまとめる。スライド作成する際の一番最初に決める

この流れで資料作成を行うと、Xやその後のコミュニケーションの中で、「比較的伝えたいことが伝わっているなぁ」と感じることが多いです!

少しでも参考になる点があると嬉しいです☀️
最後までお付き合いいただきありがとうございました!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?