お気持ちの表明

思考を雑に外出していきます

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

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


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

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

STARSで大枠決める

saiyo.employment.en-japan.com

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

スライドの落としこみ

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

pain/gainの共有

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

具体的な問題対処

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

どう対処するのか

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

付録

  • 本筋からズレるけど紹介したいことなど、あれば書く
    • 公式ドキュメントとか、抽象化したコードの具体コードのgistのリンクとか

説明や文章についての制約

個人的に縛りをつけておくと整えやすい。

実例集

GitHubの自己紹介 とか、 最近のスライドとか とか

以下は直近このノリで書いたもの speakerdeck.com