めも

メモ.

覚書・説明・論文紹介・発表資料の作成の仕方の確認

エンジニアであってもなくても、READMEなどの機能を最低限説明するドキュメント、論文紹介などの勉強会資料、サーベイや自分用の覚書など、資料作りは多くある。 正直自分の作る資料が自分以外にはわかりづらいと思うことが多いので、これから変えていきたい。

過去の関連記事

学会の発表とかのスライドを書くまえに調べた内容だったと思う。

paper.hatenadiary.jp

場合分け

資料の目的

  • 資料の形式
    • README: マークダウン
    • スライド: パワーポイント
  • 説明の形式
    • 知りたい人が勝手に読む:README
    • 勉強会:スライド・資料を見ながら口頭で説明
  • 資料を見るひと
    • 初心者・その分野の専門家・一部知識があるひと...
    • 人によってつまづきやすいところ、知りたいこと、何を知れば納得できるかが異なる

なんのための資料か

  • 状況把握
  • 方針立案
  • 報告・提案
  • 作業記述 (Kindle版 位置No.245, エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方 Kindle版, 開米瑞浩)

これは、以下の書籍の内容から引用しました。他の場所でも、この文献を参考にしている箇所があります。

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方

資料作りのための用意

資料を作るために、資料に載せる情報を整理する。

分類ラベル・単純ラベルをつけてみる (参考:Kindle版 位置No.316, エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方 Kindle版, 開米瑞浩):

ラベルをつけて事例を分類、それぞれの事例について考える範囲を明確に決めることで見落としの発見・新しい分類の発見に繋げる。複数の事例に共通する内容を見つけて一般化する。

研究や開発の場合、一度資料に載せる内容を決めると、それに必要な補足や実験結果が見えてくる。 そこから実験結果などを追加して、結果に対する考察、さらに考察を検証するための実験...と続いていく。

聞き手・資料の読み手について理解する:

聞き手が何を知りたいか、聞き手が精通しているものは何か、どのような言葉や例えならば理解してもらいやすいかを理解する。

発表資料の順番の整理

発表資料に載せる内容を決めたところで、聴講者が理解しやすいようにスライドを並べる・まとめに繋げるためのシナリオを考える必要がある。

エンジニアのためのプレゼン技術研究会 - connpassでの資料)

デザインへの配慮

最後に、スライドの内容と順番が決まったところで、スライドの見栄えや配色などを必要ならば修正する。

ところで、研究室などでスライドのフォーマットが決まっているときはそれを無理に変える必要はないと思う。

あくまで伝わる・わかりやすいならなんでも良く、見てる人が見慣れたフォーマットならばそれに越したことはない。

www.slideshare.net

ocw.kyoto-u.ac.jp

京都大学のOCWでは、実際のスライドを修正しつつ説明をする内容になっている。そして論文など誰でも見られる形での資料の場合、バリアフリーへの配慮を忘れないこと。例えば、棒グラフの色を全てベタ塗りにすると色盲の人はその見分けがつかない。なので棒グラフに模様をつける(ハッチング)時がある。

matplotlibの棒グラフに模様をつける(ハッチ)例

READMEの書き方例

READMEについては、色々な方が「いいREDMEの書き方」なるものを公開している。

gist.github.com