| name | techtalk-maker |
| description | 技術発表の資料(CFP応募文, スライド)を作成するスキル。3フェーズで進める。最初に想定オーディエンス層と一番持ち帰ってもらいたいことをブレストして合意する。次にフォーマットの持ち時間から逆算してアウトラインと時間配分を決め合意する。最後にスライドを書く。10分以下では主題を1つに絞り起承転結を作らない、自己紹介ページを作らない、1枚に複数メッセージを詰めない、引用や初出用語は実在ページへリンクするといった規律を強制する。CFP応募時はabstract, description, motivation相当の文章も生成する。
トリガー: "技術発表の資料", "登壇資料を作りたい", "プレゼン資料を作って", "LT資料", "techtalk", "CFP応募", "プロポーザル", "発表スライド作って", "techtalk-maker"
使用例: techtalk-maker
|
技術発表資料作成スキル
技術カンファレンス, 勉強会, 社内発表向けの資料を、ユーザーとの合意を取りながら段階的に組み立てる。CFP応募の応募文と本番用のスライドの両方をスコープに含む。
全体の流れ
3つのフェーズで進める。各フェーズの終わりに必ずユーザーと合意を取ってから次へ進む。途中で前提が変わったら、ためらわず遡って合意し直す。
- 入口の確認。CFP応募か発表確定済みか、持ち時間、スライド形式を聞く。
- フェーズ1。想定オーディエンスと持ち帰ってもらいたいことをブレストして合意する。CFP応募ならabstractに文章化する。
- フェーズ2。フォーマットから逆算したアウトラインと時間配分を合意する。CFP応募ならdescriptionとmotivationに文章化する。
- フェーズ3。スライドを書く。
途中ですべてを抱え込んで一気に作らない。フェーズ1で得た「一番持ち帰ってもらいたいこと」がフェーズ3の主題スライドの軸になるため、ここを曖昧にしたまま進むと後で巻き戻しが大きい。アウトラインを飛ばしてスライドから書き始めると、時間配分が破綻して書き直しになる。
入口の確認
最初に次の3点を確認する。
- CFP応募か発表確定済みか。応募ならフェーズ1,2の合意内容をabstract, description, motivationの文章に落とす必要がある。確定済みなら計画メモだけでよい。
- 持ち時間。10分以下かそれより長いかでフェーズ2,3の制約が変わる。質疑応答の時間が別にあるかも確認する。
- スライド形式。指定がなければslidevをデフォルトとする。Markdown駆動でgit管理しやすく、speaker noteの記法が標準化されているため。pptx, Google Slides, marpを指定された場合はそれに合わせる。slidev以外の作法は
references/other-formats.md を参照する。
ここで得た情報は、以降のフェーズで参照しやすいよう短くまとめてユーザーに復唱する。
フェーズ1 オーディエンスと持ち帰りの合意
このフェーズで決めるのは2つだけ。想定するオーディエンス層と、一番持ち帰ってもらいたいこと。この2つはフェーズ2のアウトライン構成とフェーズ3の主題スライドを直接決めるため、曖昧なまま先に進むと後で必ず作り直しになる。
ブレストの進め方
ユーザーから発表テーマと文脈を聞いたら、両方の候補を複数挙げてユーザーに選んでもらう。一案だけ提示して合意を取ろうとしない。比較対象がないとユーザーは判断材料を持てない。
オーディエンス層は、職種だけでなく前提知識の濃度まで言葉にする。Webバックエンドエンジニアだけでは荒い。Webバックエンドエンジニアで、TypeScriptは書けるがRustは未経験、のように何が既知で何が未知かまで踏み込む。発表中の前提説明をどこまで端折れるかが変わるため。
持ち帰ってもらいたいことは、聴いた直後に行動か思考が変わる単位で書く。「Rustに興味を持ってもらう」は弱い。「Rustのライフタイムを"値の借用期間"として捉え直す視点」のように、聴衆が翌日同僚に話せる粒度まで具体化する。
合意の確認
両方が決まったら、想定オーディエンスは〇〇、一番持ち帰ってもらいたいことは△△、という形でユーザーに復唱し、明示的なOKを取る。OKが出るまで先に進まない。「だいたいよさそう」では危ない。
CFP応募の場合
応募サイトのabstract欄相当の文章を、合意内容から書く。多くのカンファレンスはabstractに100〜300字程度の文字数制限を設けるため、まずユーザーに制限値を確認する。確認できない場合は150字前後で書く。
abstractには持ち帰ってもらいたいことを必ず入れる。聴く価値を選考委員と参加者に伝えるための文章であり、ここが抜けると採択されにくい。
フェーズ2 アウトラインと時間配分の合意
ここで決めるのはアウトラインの各ブロックと、それぞれの時間配分。
フォーマットから逆算する
持ち時間から逆算する。スライド1枚あたりの目安は30〜60秒。5分なら5〜10枚、10分なら10〜20枚、30分なら30〜60枚程度の範囲に収める。
1枚あたり30〜60秒を前提に置くと、各スライドが短いメッセージで済むため、1枚1メッセージの規律が自然に効く。逆に「1枚2分」を前提に置くと、1枚に複数の主張を詰める誘惑が出てきて、聴衆が画面を読む時間と発表者の話す時間が衝突する。
持ち時間が10分以下の場合の制約
10分以下では次を厳守する。
- 主題は1つの話題に絞る。起承転結や序破急で構成しない。10分では「承」や「破」に入る前に持ち時間が尽きるか、各段が削られて主題に厚みが出ない。1つの主題を深掘りする方が、聴衆の持ち帰り効果が高い。
- 自己紹介は省くか一言にする。専用のページを作らない。speaker noteに、冒頭で名前と所属だけ口頭で言う、とだけ書く。1分の自己紹介ページは10分枠の10%を食い、本題の枚数を1枚以上削ることになる。
持ち時間が10分超の場合
起承転結や序破急の構成も使ってよい。ただし主題は依然として1つに絞る方が持ち帰り効果は高い。複数主題にする場合は、それぞれに独立した持ち帰りを設けず、上位の1つに統合する。
アウトラインの書き方
各ブロックをリストで書き出す。1ブロックにつき1行で、ブロック名と狙い、配分時間、想定スライド枚数を続ける。
- 問題提起 なぜキャッシュ無効化が難しいか. 1分, 1〜2枚
- 主題 無効化はwrite側に寄せる. 1分, 1枚
- 具体例 コードで示す. 2分, 3〜4枚
- まとめ 主題の再掲. 30秒, 1枚
合計が持ち時間に収まることを確認し、ユーザーに合意を取る。アウトラインはMarkdownテーブルにしない。テーブルは編集が重く、後でブロックを足し引きしづらい。
CFP応募の場合
description欄とmotivation欄に文章化する。
- descriptionは、アウトラインの各ブロックを散文に展開する。聴衆が辿る思考の道筋が伝わる粒度で書く。
- motivationは、なぜこの発表をこのカンファレンスでするかを書く。発表者の動機(何に困った, 何を発見した)と、聴衆にとっての価値(何が学べる, 何が変わる)の両面を入れる。
文字数制約があれば先に確認する。
フェーズ3 資料作成
合意済みのアウトラインと時間配分に沿って、スライドを書く。
主題スライドを最初に置く
最初のスライド(タイトルの直後)に「一番持ち帰ってもらいたいこと」を書いた主題スライドを置く。聴衆にこの発表の到達点を最初に渡すため。終わってから「で、結局何が言いたかったの?」となる発表は、主題が最後にしか出てこないことが原因のことが多い。
例外として、持ち時間が5分未満の場合のみ省いてよい。5分枠は前置きを置く余裕がないため。
デザインの規律
最初からデザインに凝りすぎない。テーマの選定や色のチューニングに時間を使うと、内容の改善時間が削られる。
ただし最低限の整えはする。崩れた見た目は内容の説得力も削る。良い例と悪い例は references/design-discipline.md を参照する。
- 見出しと注釈の上下を揃え、行頭の左右も揃える。
- 色数は1〜2色程度に絞る。3色以上にすると、強調が分散して何が大事か伝わらない。
- 文字サイズは16:9のHD解像度(1280x720px)で本文24〜28px、見出し30〜36px相当をキープする。これより小さいと後列から読めない。
- フォントは標準的なゴシック体1つに統一する。装飾フォントは見出しでも避ける。
- Markdownベースのスライド(slidev, marp)では、日本語と半角英数字の間にスペースを入れない。"URL パス"ではなく"URLパス"、"3 秒"ではなく"3秒"と書く。slidev/marpはCSSで字組を制御するため、ソースに空白を入れると本番表示で逆に間延びする。半角英数字どうしの間("TypeScript 4.1"のようなバージョン表記)は通常通り。speaker noteや配布資料側の散文も同じ規則に揃える。
1枚1メッセージ
1枚に複数のメッセージを詰めない。要点だけスライドに残し、詳細はspeaker noteに逃がす。
聴衆はスライドを読みながら発表者の話を聞く。1枚に箇条書きが7つ並ぶと、3つ目を読んでいる間に発表者は5つ目を話していて、両方を取り逃がす。
slidevなら本文の末尾に<!-- ... -->でspeaker noteを書く。Marpなら同様にHTMLコメントで書く。pptxなら発表者ノート欄に書く。具体的な書き方は references/slidev-template.md を参照する。
表よりも箇条書き
箇条書きで書ける情報は箇条書きにする。Markdownテーブル(| ... | ... |)を使うのは、2つの軸の対応関係(機能の有無マトリクス, 言語ごとの構文比較など)を見せたいときだけにする。
理由は2つ。Markdownテーブルは編集が重く、列幅を揃えるためのスペース調整がgit diffを汚す。スライド表示でもテーブルは横幅を取りやすく、本文サイズが小さくなる。1次元のリストはどちらの問題も起こさない。
悪い例: 機能の単純な並列(項目と一言説明だけ)をテーブルにする。
| 機能 | 説明 |
|------|------|
| A | xを行う |
| B | yを行う |
良い例: 同じ情報を箇条書きで書く。
- A xを行う
- B yを行う
引用と初出用語のリンク
資料を公開した際に参照できるよう、引用や初出の用語は定義先のwebpageへリンクする。
リンクはその用語や引用が登場したスライド本体の該当行に都度貼る。末尾の「参照」「References」「参考リンク」スライドにまとめない。Slidevもmarpもspeaker noteは本番投影では表示せず、公開後の閲覧者にも届かないことが多い。スライド本体に直接リンクが乗っていないと、後から読み返した人がたどれない。
リンクはMarkdownのリンク記法[テキスト](URL)で書く。生のURL(https://...をそのまま貼る)にしない。リンク記法ならスライド表示でリンクテキストだけが見え、視覚的に整う。生URLは長く、レイアウトを崩す。
speaker noteにURLを書かない。speaker noteは発表者しか見ない場所なので、URLを置いても聴衆も公開後の閲覧者も辿れない。URLを参照したいなら必ずスライド本体の該当行に[テキスト](URL)を置く。speaker noteには文章のキーワードだけ書く。
ただし架空のページにリンクしない。これは絶対に守る。LLMが生成したそれっぽいURLは存在しないことがほとんどで、公開した瞬間に資料の信頼が崩れる。リンク先は以下のいずれかから取る。
- ユーザーが提示したURL。
- WebFetchやWebSearchで実在を確認したURL。
- 公式ドキュメント(MDN, RFC, 言語やフレームワークの公式サイト)で実在が明らかなURL。
不確実な場合はリンクを付けず、参照名だけ書く。「Wikipediaの〇〇の項」のような曖昧な参照より、論文タイトルと著者名と年のような検索キーになる情報を残す方が、聴衆が後で辿れる。
末尾スライドの作り方
最後のスライドは主題の再掲かまとめにする。聴衆が最後に持ち帰るのは最後に見た画面なので、ここで主題を1分以内で読み上げて締める。
「Thank you」「Q&A」「ご清聴ありがとうございました」「謝辞」「質疑応答」だけのスライドを作らない。情報密度がゼロでスライド枠と発表時間を消費するだけになる。
質疑応答の時間は別にあっても、専用スライドは要らない。まとめスライドのまま司会または発表者が口頭で「ご質問があればどうぞ」と促す。想定質問と回答メモはspeaker noteに置く。
参考リンクが多くて本文中の都度リンクで散らかると感じる場合も、独立した「参考リンク」スライドにまとめるのではなく、まとめスライドの下に3〜5行の小さなリストを添える形にする。スライド本数を増やさない。
speaker noteの書き方
speaker noteには次を入れる。
- スライドに書かなかった詳細と背景。
- 話す順序や強弱の指示(ここは少し溜める, 速めに通す)。
- 想定質問と答え。
- 自己紹介を省略した場合、冒頭で口頭で言う一言。
出力先と形式
slidevをデフォルトとし、slides.md という単一ファイルに書く。---でスライドを区切り、<!-- -->でspeaker noteを書く。詳細なslidev作法と推奨frontmatterは references/slidev-template.md を参照する。
pptxやGoogle Slidesを指定された場合は、ファイル名やフォーマットをユーザーと相談する。Markdown形式で構造を先に書き、ユーザーがそれを当該ツールへ転記する流れにすることが多い。詳細は references/other-formats.md を参照する。
反復改善
書き上げたら、フェーズ1の「一番持ち帰ってもらいたいこと」と主題スライドが一致しているか確認する。ずれていたらアウトラインから巻き戻す。
時間配分が現実的かは、声に出して読み上げる検証が一番確実。各ブロックの所要時間が想定の±20%以内に収まることを確認する。
仕上げに proofread-ja を当てる
生成した成果物(slides.md, outline.md, abstract.md, description.md, motivation.md など)に対し、最後に proofread-ja スキルを順に適用する。
proofread-ja は日本語文章の表記を整えるスキルで、日本語と半角英数字の間の余分なスペース、記号の使い方、句読点、装飾的な太字や鉤括弧の濫用などを直す。techtalk-maker が "発表の構造と規律" に集中する一方、proofread-ja が "文章としての表記" を担う、と役割を分ける。
各ファイルに対して proofread-ja を呼ぶ。proofread@ja <ファイルパス> のような形でユーザーから明示依頼を受けてもよいし、スキル末尾で順次適用してもよい。proofread-ja の規則がここで個別に追従不要になるため、techtalk-maker 側で表記の細部を書き並べる必要は無い。
参照ファイル
references/slidev-template.md slidevの推奨frontmatter, スライド区切り, speaker noteの書き方references/design-discipline.md フォントサイズ, 色数, 整列, 1枚1メッセージの良い例と悪い例references/other-formats.md pptx, Google Slides, marpを指定されたときの作法
