プレゼンテーション資料を脳死で6割作るためのワークフロー

社内メモに書いてたのをコピペ

他者に対してのPresentationをすることは稀によくあります。
登壇、ブログ、職務経歴書、etc

資料に落とし込む時、「資料の設計」をどう設計するかを悩みがち。
自分がやっている資料作りのフレームワークを共有します。

STARSで大枠決める

職務経歴書は「STARS」というフレームワークを使って書くのがおすすめよ。

・Situation :どんな環境で
・Task :どんな任務を持ち
・Action :自分は何を実行して
・Result :結果どうだったのか
・Self-Appraisal :振り返ってどう思うか

中でも「Self-Appraisal」をしっかり書くと書類通過率変わるよ。
— moto (@moto_recruit) 2021年5月31日

saiyo.employment.en-japan.com

これにつっこめば大体の資料の大枠ができる。
大枠できたら、必要な情報をできるだけ最小限の文章で記述することをがんばる。

スライドの落としこみ

テキストにしても、だいたい一緒。

pain/gainの共有

どういった問題意識があるのか
問題を解決すると、どういった良いことが起こるのか

具体的な問題対処

何を対処するのか
元気がある範囲で図解する
- こちらから投げる情報源として「スライド」「声」と情報源がある
- スライドは「図解で大枠のイメージを伝えて、文章で補足するイメージ」で書く
  - 紙芝居ぐらいのノリ
- 声は「スライドの説明を副音声」というイメージでしゃべる
  - スライドの内容を「読み上げるだけ」で十分
  - スライド単体で情報源として成立しているものに対して、補完的に使うぐらいの気持ち

どう対処するのか

コードで具体例を示す場合は、全文のせず抽象化したコードもどきを提示する。
- 見せておきたいコード以外は ... などで省略する。
- 具体的に書きすぎると、聴衆は読解に専念してしまう。
コードの説明は基本的にしない。
- 「こんなかんじです！気になる人はあとで見てください！」程度。
- その場で聞いても完全に理解できないし、抽象化されたコードなので、あとで各自見てもらうほうが効率がいい。

付録