3 ポイント 投稿者 GN⁺ 2024-06-15 | 1件のコメント | WhatsAppで共有
  • 技術発表では背景説明が必要だが、冒頭で聴衆を引きつけ損ねやすいため、まず 問題の状況 を見せてから文脈を補う構成のほうが効果的
  • この手法は Lawrence Block の文章術の助言のように、自然に書いた最初の部分と2番目の部分を入れ替えて 緊張感のある場面 を先頭に置くやり方
  • 背景を先に説明する発表は、すでに知っている人には繰り返しであり、知らない人にはまだ聞く理由が足りず、集中力が落ちることがある
  • JIT ベースの仮想マシン最適化の例では、性能プロファイル、改善しそうに見えるコード変更、実際にはより遅くなったデータを先に見せ、その後で JIT・最適化・アーキテクチャ を説明する
  • 冒頭で解きたくなる問題を投げかけると、プログラマーは自然に解法を探そうとし、その後の説明を追う動機が生まれる

問題を先に見せる発表構成

  • 技術発表には通常、文脈設定 と解決すべき問題提示の両方が必要
  • ただし背景説明から始めると、発表序盤の引き込みが弱くなる
    • すでに背景を知っている聴衆には繰り返しの情報になる
    • 背景を知らない聴衆には、まだ理解しようとする動機が生まれない
  • Kent Beck の方法は、発表資料を望む順序で作成したあと、最初の2枚のスライドや2つの段落、2つの章を入れ替えること
  • Lawrence Block の Telling Lies for Fun and Profit から持ってきた手法
    • 物語を自然に書くと、第1章は主人公紹介、第2章は事件の展開になる
    • 2つの章を入れ替えると、主人公が危険にさらされた場面から始まる
    • 緊張感が生まれたあとで人物紹介が来るため、読者にはその人物を知りたくなる理由が生まれる

JIT 最適化発表の例と聴衆の反応

  • JIT コンパイルベースの仮想マシン最適化の発表なら、通常は JIT 化、性能チューニングの基本であるパレート、現在のマシンアーキテクチャを先に紹介する
  • しかし、ホットスポットを減らす一般的な最適化が全体性能をむしろ低下させたり、一見問題なさそうな変更が大きな改善を生んだりすることもある
  • 2枚目のスライドから始める構成では、1枚目のスライドに判断材料をすぐ配置する
    • ホットスポットが見える 性能プロファイル
    • 改善されそうに見えるコード変更
    • 最適化が失敗しただけでなく、システムをさらに遅くしたことを示すデータ
  • その後で JIT、最適化、アーキテクチャの説明を入れると、背景を知っている聴衆もミステリーの答えを待ちながら追ってくれ、背景を知らない聴衆にも集中する理由が生まれる
  • プログラマーは問題が提示されると解決しようとする工学的反応を示すため、発表の冒頭で一緒に解く問題を投げかける構成は効果的

1件のコメント

 
GN⁺ 2024-06-15
Hacker News のコメント
  • 数週間前、PyConで発表したとき、時間内に内容を収めるのに苦労し、結局、冒頭数分ぶんの導入を削った
    テーマへ徐々に入っていく部分や、なぜ自分にこの話をする資格があるのかという背景説明をなくして、いきなり最初の要点に入ったのだが、そこにいいジョークが入っていてうまく受けた
    テーマが十分に面白ければ導入を飛ばしていきなり本題に入ってもよく、ジョークを交えれば聴衆の注意を十分につかめるのだと学んだ

    • これは営業プレゼンでも重要
      会社の歴史から語り始める営業ピッチは本当に嫌いで、不思議なことに日本の大企業はこの点で特に最悪なことが多い
      各スライドごとに「次のスライドを読む理由を与えなければ、聴衆は席を立って出ていく」と考えるべき
      こちらが何を提供するのかまだ分からない状態なら、発表者の存在理由を正当化する必要はなく、結局のところ核心は発表者ではなく聞き手にある
    • 同意するが、名前や資格のような当たり障りのない退屈な部分から始めると、序盤の緊張状態でも話しやすいという利点がある
      そういう部分は大きくつまずきにくく、その間に体が温まって本編に入れる
      もちろん短いほどよく、だから最初の数文は単語単位で暗記しておくことにしている
      いちばん不安なときでも冒頭は確実にこなせて、その後はより自由に話せる
    • 長い導入は本当に嫌いだし、聴衆も短く入ってくれることに感謝する
      30秒くらいならいいが、数分は長すぎる。発表でも YouTube 動画でも同じ
      人々がそうする理由は分かる
      「この人には資格があるのか?」「文脈が分からない」といったリスクを減らそうとしているのだろうが、少しだけ勇気を出してすぐ核心に入ってほしい
    • 技術カンファレンスの発表なら、自己紹介スライドを見ると目がうんざりしてしまう
      こちらはすでにその発表を聞くことを選んでいるので、なぜ面白いのかを説明するのは、すでに信じている人に説教するようなもの
      ハッカー文化では、普通は資格証明より実力で人を判断するので、「ちなみに、これは私が作りました」くらいは挟めても、履歴書を読み上げるのではなく洞察で説得すべき
      すべての文脈でそうだというわけではなく、資格を非常に重視する聴衆もいる
      人々がその発表を自分で選んだのではないなら、十分な文脈も必要
      それでもたいていは、まず関心をつかみ、関心を得てから導入に戻るほうがよい
    • 文章を書くときも、導入部は自分にとっては残りの文書を書くために必要だが、書き終えると、その導入の内容が不要な決まり文句のようになることがある
  • 大学院時代に発表訓練をたくさん受け、指導教員がリハーサル中によくクイズのように練習させていた
    最初のスライドは、話していないときにしばらく表示しておく場所、本の表紙のようなものにすぎないと考えるべき
    たとえば司会者が「次の発表者は BlahBlah を扱います」と紹介したら、「ありがとうございます SoAndSo。私は Godelski で、次のスライド BlahBlah を扱います」と返す
    逆に「次の発表者は Godelski で、BlahBlah に関する研究を発表します」と紹介されたら、「ありがとうございます SoAndSo。次のスライド」で進める
    紹介がない場合も含めてバリエーションはあるが、要点は紹介者がすでに言った情報を繰り返さず、タイトルスライドから素早く離れること
    そのスライドは誰が何について話すのかだけを示す場所であり、聴衆にさらに伝える情報があるなら、そのスライドに留まってはいけない
    スライド構成や組み立てにはもっと多くの要素があるが一般化は難しく、ただし概要スライドは1秒未満しか見せなくてもかなり有用だと思う
    オンラインにスライドが上がるときには、より重要でもある
    発表用スライドは話すための補助として作るので、オンラインに載せるとうまく合わず、スライドノートを簡単に含められるとよい
    Google Slides では問題ないが PDF では難しく、beamer ならすでに可能か、可能にできそうなので、誰かが新しい慣行を押し進められそうだ

  • 私の技術発表はかなり人気があり、テーマに関心のない非技術職の人たちも社内でスライドを回覧している
    物語の構造が核心で、物語がなければ発表は面白くなりえない
    発表を作りながらスライドを何度も見返し、話の流れが自然か確認する
    発表中は多くの情報が画面に一度に現れないようにし、PowerPoint のタイムラインを使って、自分が話している間にスライドがゆっくり形成されるようにしている
    ほとんどホワイトボードを使っているように見えるようにしており、スライドをめくった瞬間に文字の壁が飛び出すのを好む人はいない
    文字だけのスライドを避けているわけではないが、自分の話や概念を伝える最善の方法であることはめったにないので、ほとんど使わない
    発表を作りながら、技術的すぎて退屈になっていないか、逆に非技術的すぎて退屈になっていないかも常に読み返す
    バランスが重要で、急に技術的に深く入りすぎなければならない場合は、次の数枚でまた引き上げる必要があり、その逆も同じ
    文字は少なくても手描き風のビジュアルを多用して概念を正確に説明しているので、印刷してもなお理解でき、知るべき内容を伝えられる
    最後に、どのアプリを使うかは重要ではない
    下手な芸術家ほど道具のせいにするものだし、私は PowerPoint を使っている。iPad Pencil 対応と完全なアニメーションタイムラインがあり、うまく使えばほとんど映画を作るレベルだからだ
    ただし主には、スライドをより小さな断片に分けるために使っている

  • 技術発表は常にネタバレから始める
    忙しい人や、単に自分の言うことを信じてもよい人は、最も重要な情報だけを得て、ほぼすぐに退出できる
    同意しない人や主張の証拠を見たい人は、そのまま参加し続ければよい

    • BLUF、つまり Bottom Line Up Front に似ている
      メモやメールでよりよく使われる表現だが、概念は同じ
      最後に何があるのかを先に知らせれば、背景説明がどこへ向かっているのかを人々は理解できる
      物語の背骨を書いてもよいが、虹の果てに爆発シーンがあることを聴衆に納得させたいなら、まず予告編を見せる必要がある
    • 製品デモで言われる最後のものを最初にやれという考え方とも合っている
      聴衆に報酬を「勝ち取らせる」必要はなく、いきなり良い部分へ進み、関心のある人のために残りを説明すればよい
      複数のデモレビューで出てきた内容もここにある: https://web.archive.org/web/20220126051034/https://www.secon...
    • 自分のブログ記事もすべてそうしている
      要約から始め、適切な場合はコピー&ペーストできる完全な再利用コードまで先に置く
      自分が他人に望むやり方なので、自分もそうしている
      自我は脇に置き、有用性を優先すべきだ
    • 重要な情報を伝えるときは、逆ピラミッド構造がほぼ常に良い
      なぜ気にするべきなのかを最初に言うことになり、あまり興味を引かない内容は後ろに回るので、時間を超過したり誰かが集中を失ったりしても、多くを取り逃がさない
      [1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
  • 発表版の “I’m okay, the bull is dead” と見ることもできる
    https://www.computerworld.com/article/1702433/i-m-ok-the-bul...

    • 文章の趣旨は理解するが、自分なら情報を少しずつゆっくり聞かされる、あるいはさらに悪く、こちらから聞き出さなければならないよりも、「車で雄牛をはねた。私は大丈夫だけど車は壊れた」と先に聞きたい
      そのような状況で人が落ち着けず、明確に説明できないのは理解できるが、ここではそういうケースではなかったように思う
      落ち着いているなら、相手のために何が起きたのかを10〜15秒で説明するほうがよい
    • 昨年、このテーマで大きな議論があった: https://news.ycombinator.com/item?id=37087459
    • BLUF、つまり要点を先に置くのと同じ原則だ
      結論と影響を先に述べ、その出来事に至った背景は後から埋めればよい
  • 技術発表にもやはり物語が必要だ
    標準的なストーリーテリング技法のように、関心を引く出来事、つまり発端となる出来事から始めるべきだ
    The Matrix は Trinity が捕まりかける場面から始まり、Bambi は母親が撃たれ、Star Wars は小さな船がレーザーを撃つ巨大な船に追われるところから始まる
    良い技術発表は良い物語構造に従う
    発端となる出来事、小さなクライマックスへ積み上げること、少し引くこと、クライマックス、結論という順序だ
    優れた技術発表者になりたいなら、良い物語の語り方に関する本を読むとよい

    • その技法で聴衆を怒らせないよう注意が必要だ
      たとえば「David は田舎のどこかにある3部屋の家で、犬の boopy と bloppy と一緒に暮らしている……」で始まる長すぎる記事は、すぐに閉じてしまう
      以前、コメディアンが行った素晴らしいプレゼン講座を受けたが、最も記憶に残っている助言は、発表を英雄叙事詩のように構成せよというものだった
      誰もが知っている構造だ。すべてが順調、悲劇が起きる、問題を克服する、祝う
      技術発表には合わないと思うかもしれないし、すべての発表がそうである必要はないが、思っているよりずっと頻繁に適用できる
      基本的に、問題を解決するものはすべてこの形で語れる
      ところがあまりに多くの発表が「X プロジェクトについて話します。これがスライドの概要です。では、X とは何でしょうか?」で始まる
      代わりに「私たちには Y をするものがたくさんありました。Z が来るまではうまくいっていました。次に大惨事が起きました。既存の解決策 A はこの場合まったく通用しませんでした。そこで X を作りました。しかし……のためにうまくいかず、そのため……する必要があり、ついにすべてが動作しました」のように語れる
    • Bambi は生まれる場面から始まり、母親は映画の中盤で死ぬ
  • 最初のスライドはテキストのない画像で始めることを勧める
    その画像は、番号のないタイトルスライドにあった発表テーマとは一見まったく関係がないものにすべきだ
    そうすると、人々はどんな説明がされるのか気になり、注意を向ける
    謎を解いた後で2枚目のスライドに移り、問題定義や研究課題を提示し、その後は一般的な構成である概要、方法、データ、実験、評価結果、議論と限界、要約、結論と今後の課題へ進めばよい
    ただし、これは口頭発表にだけ有効だ
    大手グローバル企業で主流の、もう一つの重要なスライドデッキの種類は、PowerPoint の発表と Word 文書の混合物に近い
    スライドはテキストで埋め尽くされ、デッキだけを見ても理解できるように作られ、発表用であるだけでなく、主にメールで回覧して読まれるために書かれる
    経営陣が発表を聞かずにスライドだけをざっと見ることができるため、良い発表を補助する良いスライドのルールを意図的に破っている

    • 技術論文にも似た助言が当てはまると思う
      少なくとも自分の分野であるコンピュータビジョンと機械学習では、最初のページに見栄えがよく、できれば自己説明的な図を大きく配置する
      PDF をざっと見る人の関心をつかみ、引き込む役割だ
      コンピュータビジョンでは通常、3D 再構成や物体検出が強調された画像のように、視覚的に魅力的なものを見つけられる
      あるいは、自分の手法がベースラインよりどれほど優れているかを示すグラフを使うこともできるが、数字の意味をよく知らない人にはあまり面白くないかもしれない
  • デモでは、ずいぶん前に良いところから始めるべきだと学んだ
    優れた監視ソフトウェアがあるなら、インストール手順、メトリクス収集の設定、フロントエンドを時系列データベースにつないだ過程から始めて、その後に以前はなかった見事なグラフを見せるべきではない
    代わりに、以前はなかった見事なグラフを先に見せて、そのグラフがなぜ有用なのかを説明すべき
    そうして全員が関心を持った後で初めて、その状態にどう到達したのかを時間をかけて見せればよい
    見事なところにたどり着くまでの長く退屈な過程から始まるデモをあまりにも多く見てきたし、むしろ見事なものを先に見せていればずっと良かったはず

  • 技術発表には天才的なやり方
    ただし小説やテレビ番組のような娯楽メディアでこれをやると、いつも興味が薄れる
    アクションシーンを理解するのに背景情報が必要ないなら、背景情報は丸ごと飛ばしてもよいと思う
    テンポを一気に上げた後、あまりにも早くまた何もない状態へ落とさないでほしい

    • ニュース記事、特にスポーツや政治の記事ではこの手法がよく使われる
      それでも物語の最も重要な部分を先に出しているわけなので、理由はある
    • 娯楽メディアでは、しばしば終盤のその場しのぎのように感じられる
      小説の展開が遅すぎて、テスト読者が面白いことが起きる前に読むのをやめてしまうので、編集者が「10章にある格好いい戦闘シーンを冒頭に入れて、この本が何をするのか見せよう」と提案する、という具合
      そのやり方がうまくいくことはめったにない
  • すべての文と段落を読んだが、元記事が何を伝えたいのかまだはっきりしない
    「導入部を飛ばせ」という意味なのか?
    私は発表を始めるとき、発表が何で構成されるかの短い概要を先に示す
    常に聴衆に合わせて内容を調整できるわけではないが、少なくとも冒頭で索引や要約版を渡しておけば、いつ集中し、いつ少しぼんやりしていてもよいかが分かる

      1. これから話す内容を話す
      2. 話す
      3. 話した内容をもう一度話す
        繰り返し強調する要点は2〜3個であるべきで、それ以上であってはならない
        そして私の一番の助言は、発表をより自然に聞こえさせたいほど、事前により多く練習しなければならないということ
        経験豊富な発表者なら、これらのルールをいつ、どのように破るべきかも分かるようになる
    • この記事の核心は、「問題の解法を理解させるために技術的背景を先に説明するのではなく、問題から始めよ。そして文脈や技術的背景は2番目に説明せよ」だと理解した
    • 結局、テキストの動機付けを発明したということ
      もちろん再発明だ