ajito.fm/23 を聴いて：「学びの話」「講演の話」

ajito.fm は VOYAGE GROUP の社内バー AJITO の名を冠したテック系 Podcast です。

今週公開された最新話の23回では、テストの伝道師で講演者としても知られる @t_wada さんが、プレゼンテーションや講演の作り方などについて話されていました。 こんなに価値のある情報を開けっ広げにしていいのか？！と思える内容だったので、個人的にその内容を文字起こししてみました。

（t_wada さんは既に何度かご登場されていて、金言がバンバン出るのは毎回なのですが。ぜひ過去回も聴いてみてください）

[https://ajito.fm/23/:embed:cite]

目次

• 学びの話

  • 新入社員研修
  • t_wada さんの学び方の変化
  • 「教える」ことから得られる学びは多い
  • 「教える」を避けるのはもったいない
  • 類似の情報であっても情報発信には価値がある
  • 「ゴミエントリー」にしない工夫

• 講演の話

  • 「技術選定の審美眼」
  • 講演の準備／資料の作り方とコツ
  • プレゼンテーションの基本
  • 聴く人の明日がどう変わるかに力を込めろ
  • 「PHP7 で堅牢なコードを書く」
  • 「PHP7 で堅牢なコードを書く」の作り方
  • 講演のコツ
  • 資料が独り歩きを始めても講演の目標が達成できるかまで考えたい
  • 「技術力の審美眼」は直前まで名前や構成を練ることに時間を使った

• 過去回

  • リンク

学びの話

新入社員向研修

• 春は新人研修の公演依頼をされることが多い

  • 一番多いのはプログラマ、エンジニアとしての心構え
• 「勉強の学び方を学ぶ」みたいなメタな話

• プログラマ・エンジニアとして生きる＝「ずっと勉強し続ける」ということ

  • 自由になる時間は年々減って行く
  • 学習自体を効率化できないと自分が積んでしまう時がやってくる

• どうやって効率的に学びを続けて行くか？

  • メタな視点だと「勉強の仕方を勉強する」
  • 教育学とかにヒントがある

t_wada さんの学び方の変化

• 「フィードバックサイクルをうまく構築して回せれば学びは上手く行く」 と経験的に気づいた

  • アウトプットするとインプットがよりやってくる
  • ブログ記事を書くとインプットがやってくる
  • 勉強会で発表すると、次のインプットやアウトプットに繋がって回って行く
• 世の中に出て発表とかを始めたら、それが自分の勉強になることに気づいた
• 経験的に学んだことを整理して「こうするとうまく学びが回るかもしれないよ」ということをやっている

「教える」ことから得られる学びは多い

• WEB+DB PRESS Vol.102 でペアプロの記事を書いた

• ペアプロで経験や技能の差があるとき、上の人にメリットはあるか？

  • すごくある。 教えてる側の方がずっと学んでる
  • 「教えることは最大の学びである」色んな人が言っている（ファインマンさんとか）

• 再整理してリフレーズしないと教えられない

  • 自分の知識の整理になる

• 大学受験のテクニックの一つ＝「塾の講師のアルバイトをする」

  • 知識が体系化されて再整理される

[http://gihyo.jp/magazine/wdpress/archive/2018/vol102:embed:cite] [asin:4006030053:detail]

「教える」を避けるのはもったいない

• “教える” と言うと「上から目線になっちゃう」と考えちゃいがち

  • 自分が分かること／知ってることを、話すとか、伝えるとかでいい
  • ブログエントリーでもいいし、Qiitaのエントリーでもいいし
  • 自分の言葉でアウトプットしてみる

• 「自分は教える立場にないレベルにない」という感情をセーブしたり捨てるのが大事

  • 実は自分が一番勉強になってるじゃん、というのを体験してほしい
• 自己評価の不思議な低さみたいなものは、アウトプットとインプットのループが回らないので勿体無いなぁと思っている

類似の情報であっても情報発信には価値がある

• 類似の情報があっても今日情報発信することには価値がある

  • ある OSS の作者が ver.1.0 のリリース時にブログ記事を書いたとする
  • 「何故作ったのか」「何を解こうとしているのか」とか、“なぜなに” は当人しか書けないかもしれない
  • もしそれが4年前のブログエントリーだったりとかしたら、いまこれ動くのか？

• 現代のソフトウェアを構成しているコンポーネントの数は多いので端々から壊れて行く

  • 皆が再体験するのではなく、小さな地雷みたいなのを除去してゆくエントリーには価値がある

• 論文の世界ではやっぱり新規性が大事。工学や実学の世界では実用性が大事。

  • もちろん、エンジニアリングの世界であっても一番先に情報を出すのは尊い
• 「今日では別の要素が出てきたので有用ではありません」という内容も有用
• なので 類似の情報であっても、それを世に出すことに後ろ向きにならないで欲しい

「ゴミエントリー」にしない工夫

• エントリーの信頼性を高めるには情報の抑え方が重要

• 例えば

  • 詳細はむしろ省略しないで記す
  • バージョン情報を明記する
  • ひとつひとつの再現可能性を意識する
  • 再現可能なステップを意識する

講演の話

「技術選定の審美眼」

• t_wada さんは、講演者としては再演の多い講演者

  • コミュニティでやったものの再演依頼が多い

• 新作の題材の決め方

  • どんなテーマのイベントかとか、ある程度の方向性がある
  • 自分の持ってること、話したいこと、テーマの整合性を付けつつ作って行く
• 講演していると再利用可能なページが増える

• 「技術選定の審美眼」は完全新作

  • 実際にかかった期間は年末から本番まで3ヶ月くらい
  • スライドの組み立て大変だったのでは？
  • 難産だったし、プレッシャーが高かった
  • 時々、新人研修で技術の進化の歴史は振り子のように見えて螺旋なんだよという話をする
  • これについてフォーカスして話してほしいという依頼を承った
  • ヤバい、テーマがとても大きい、失敗したときもリスクも高いなぁと
  • 螺旋の話と、devsumi 2018テーマ「変わるもの×変わらないもの」を主軸に
  • 技術の歴史というのはある周期で繰り返しているように見えても完全な繰り返しではなく、決定的な技術の変化とかを経て進化しているもので、ベテランには揺り戻しがあるように見える、という話
• 経験として、 やや背伸びした講演から得られる成長機会はとても大きい

[https://speakerdeck.com/twada/understanding-the-spiral-of-technologies:embed:cite] [https://event.shoeisha.jp/devsumi/20180215:embed:cite]

講演の準備／資料の作り方とコツ

• 完成品としての講演の中身は、本番直前のテンションでまとまって行くもの

  • 資料が出来上がるのは直前
  • 体感的には時間の8割はメモしている時間
  • 本番の3ヶ月前に依頼をもらったとして、ネタ集めの期間が2ヶ月半

• 公演資料を作るコツ＝「講演資料を作り始めないこと」

  • スライド作りに着手するのは早すぎても遅すぎてもいけない
  • 特に大きめの舞台で講演するときは、いきなりプレゼン資料を作り始めないのが大事
  • 考えるべきはテーマ設定とかメッセージ

• 発散フェーズが続く

  • simplenote に「デブサミ2018」みたいなノートを作って、何か思いついたものを全てそこに書いている
  • こんなことを喋れる、こんなことを喋りたい
  • 散歩してるときとか、本屋行ったときとかに思いつく
  • 体験として大きかったのは「大きめの本屋の技術書コーナー」
  • 古い本から新しい本まである、背表紙に技術の歴史が見える
  • イメージが湧く → ただひたすらメモを取る

• 発散からだんだん収縮させて行く

  • ネタをひたすら集めると同時に、構成・骨組みを考える
  • 大事なメッセージは何だろうか？
  • 聞いて下さるお客さんに一番伝えたいのは？
  • 持って帰って貰えるものは？
• 骨組みに合わせてパーツを当てはめて行く

• 自分に合った道具を使う

  • 最近はスマホでメモしているけど、以前はスケッチブックでマインドマップでメモを書いていた
  • ふとしたときに思いついたときに、スケッチブックが手元になかったりした
  • とにかくメモを収集できるデバイスに
  • すぐ忘れちゃう、基本的に単語だけ

[https://simplenote.com/:embed:cite] [https://atom.io/packages/markdown-mindmap:embed:cite]

プレゼンテーションの基本

• 参考にしてる本＝『スティーブ・ジョブズ驚異のプレゼン』

  • タイトルも表紙も信者くさくて人に勧めづらいけど、中身はとってもよい

• プレゼンテーションの基本＝「ストーリーを作る、一番大事な問いに答える」

  • 抑えていないとどんな綺麗な資料でも外れだし、抑えていれば文字だけでもいい
  • そういった抑えるべきところを抑えている本

• ディレクターズノートをいつでも見れるように書き出してあって、毎回穴埋めをする

  • ⇒ 各章の最後にあるその章のまとめみたいなもの
  • 第一章
  • 「構想はアナログでまとめろ」
  • 「プレゼンテーションソフトを開く前によく考えて流れを作ること」
  • 「アイディアは紙やホワイトボードに書く」

  • 「生き生きとしたプレゼンテーションとするため、以下の9要素からなるべく多くを取り入れること」

    • “ヘッドライン”
    • “ファッションステートメント”
    • “3つのキーメッセージ”
    • などなど
  • 「どのプレゼンテーションソフトを使うかではなく、どういうストーリーを作ってどう発表するかが一番大事だ」
  • 第二章
  • 「一番大事な問いに答える」
  • 「聞き手はなぜアイディアや情報・製品に注視を払うべきなのか自問する」
  • 「何故皆さんは自分の話を聞きに来る意味があるのかに集中しよう」
  • 「その選んだポイントを明快に伝えよう」

[asin:482224816X:detail]

聴く人の明日からがどう変わるのかに力を込めろ

• 技術の話をするのではなく、話を通じて聴く人の日々がどう良くなるか、どう改善されるか、何が大事なのか、何が嬉しいのか、といった立場に立って話をしよう

• 講演の度に毎回考え直す

  • 話せそうなことを羅列すると、ただ自分が知ってることが羅列された資料になってしまう

• 聞いた人がどうするのかが踏み込み不足になりがち

  • 聞いてもらえることによって、行動が変わるとか考えが変わるとか、何らかの影響をどう持って返ってもらうかに集中しよう
  • そういう観点で自分のメモ書きや資料を見直すと、ちょっと視点が違うとか足りないことに気づく
  • ディレクターズノートの穴埋めに立ち戻る

• 意識しないとどうしても忘れがち

  • 自分ができていることを整理して資料にまとめる、というのは魅力的で引力を伴うのだけど、もう一歩踏み込んで

• 何を伝えたいのかをよりシャープにするために、毎回穴埋めして作り直している

  • 今回の講演はキーメッセージができているかな？
  • この講演で明日は変わるだろうか？

「PHP7 で堅牢なコードを書く」

• 実際の「防御的プログラミング」とか「表明プログラミング」とか「制約による設計」という概念を対応付けて説明したい

  • ソースコードをある程度登場させたい

• 「実例としてのコード」と「理論やテクニック・プラクティス」が分けて書かれてしまっている事が多い

  • 「制約による設計」というのはこういう考え方である、は書いてあるけど、実際にはどう書くの？

• コードも合わせて読めるようにしたい

  • そこで、コードを十分に登場させながら、かつ書籍の引用を出典も含めて示しながら、全体を構成して行きたい

[https://speakerdeck.com/twada/php-conference-2016:embed:cite] [http://phpcon.php.gr.jp/2016/:embed:cite]

「PHP7 で堅牢なコードを書く」の作り方

• 「PHP7 で堅牢なコードを書く」の説明の仕方は、普段の雑誌とかの原稿の書き方と同じ

• 最初にテーマ設定がある

  • 「（賢明なソフトウェア技術者になるための第一歩は）動くプログラムを書くことと、正しいプログラムを適切に作成することの違いを認識すること」（M.A. Jackson）
  • これをグランドテーマとした

• 説明したい概念が多い

  • 「防御的プログラミング」「表明プログラミング」「制約による設計」
  • ある程度、説得力のあるサンプルコードが必要
  • サンプルがないと具体例として伝えにくい
  • サンプルコードは画面内に収めなければならない、という大きな制約がある
  • 時間的な制約もある

• 言えることはたくさんある

  • 喋らなきゃいけないことは古典から引用できるので多い
  • どうやって説得力のある形でパッケージングするかが大事だった
  • サンプルコードを何パターンも作って、どれが無理なく流れを説明できるか、枝刈りをして行った
  • 「サンプルコードが成長して行く」を講演の骨組みにして、それに説明を散りばめて行くことにした

• 結果的には SQL アンチパターンのより悪い形から始まってゴールに向かって行く構成になった

  • 「サンプルコードがだんだん良くなって行く様を追体験して、多くの人に理解してもらう」という方法が得意でよく用いる

[asin:4839921946:detail]

講演のコツ

• オープニングは重要

• 聴く人に自分事だと認識してもらうのが大事

  • 自分のことであるとか、持って帰れるものがあるとか、“あるある” と思ってもらう

• 一番最初に「なぜこの講演を聴く必要があるのか」を印象付けたい

  • 痛みを追体験してもらう／痛みを仮想的に体験してもらう

• PHPカンファレンスでは、いきなりクイズを出した

  • ひどいコードを見せて「実行時例外の原因になる可能性があるのはどの行でしょうか？」「制限時間は10秒です」
  • 強制的に目の前の問題に皆さんに集中してもらう効果

• 防御的プログラミングとかエラー処理がなされていないコードというのは、どんなコードでどういった痛みを伴うのか？

  • 経験のある人には分かるが、経験のない人は分からない
  • 最初の数分で「このひどいコードからこんなにエラーの可能性があるのか」を強制的に追体験してもらう
  • 一気に同じ船に乗ってもらう構成

• 感情面での揺さぶりというか、共感とか一種の強迫観念とか、そういったものを喚起することで自分のスライドに乗っかってもらう

  • あるあるとか、これはつらいとか
  • そういったいろんな感情がでてくる
• プレゼンの作り方ってあまり話さないし、あんまり自覚的にならない

[asin:462106603X:detail]

資料が独り歩きを始めても講演の目標が達成できるかまで考えたい

• 大舞台で話す場合、演者のパフォーマンスも含めてプレゼンテーション

  • プレゼンテーションを印象付けるのがとても大事
  • 大きな写真だけとか、文字だけとかのスタイルもある（ex. プレゼンテーションzen）
  • それは大舞台のその場にいる人に全ての価値を集中する、という講演と資料の設計
  • 今日のエンジニア・プログラマの講演／発表は本番だけじゃない

• 資料は基本的にオープンに公開されるもので、公開されたものは喋りと切り離されて資料だけが独り歩きする

  • 画像1個だけだと詰んでしまう
  • 「印象のよくわからない資料だな」と思われてしまう

• 勝負のときは少なくとも2つある

  • 「本番の壇上」と「後の資料公開」

• 資料が独り歩きを始めても講演の目標が達成できるかまで考えたい

  • きちんと情報を伝えられるか
  • 多くの人にとって考える切っ掛けになるか
  • 行動を変えるか

• 画や文字だけの資料は、場と演者が伴わないと情報が伝えられないので、公開資料には向かない

  • そういう資料を作りたいなら公開用資料は別途作りましょうという話になる

「技術選定の審美眼」は直前まで内容や構成を練ることに時間を使った

• 「技術選定の審美眼」はまだ「喋りがなくても」の段階まで達していない

  • 再演を経て改善されて行くもので、まだ発展途上

• 今回は普段使っている Keynote を使っていない

  • Keynote をバリバリ使ってるものと比べると、というのはある

• Markdown からプレゼンテーションを生成するツールを使っている

  • 直前まで難産したのもあって、ギリギリまで作り込まずに文字情報としての内容や構成を練ることに時間を使いたかった
  • Keynote を最後まで開かずに、メモ書きをだんだんまとめていってツリー構造にして
  • それをプレゼンとして生成して、ちょっと CSS を書いて
  • みたいな感じで本番に至った

過去回

[https://ajito.fm/23/:embed:cite] [https://ajito.fm/13/:embed:cite] [https://ajito.fm/6/:embed:cite]