概要

カンファレンスなどの登壇イベントでCFPを提出することがあるが、自分がどのようにCFPを書き上げ、提出しているかについてポエムを書いておく。

これまでの実績

過去CFPを提出した回数が7回、採択率は100%（うち1件は諸事情により辞退）であった。

登壇したイベントは、PHPのカンファレンスとGoのカンファレンスで、PHPのカンファレンスのほうが登壇回数が多い。

cf. https://speakerdeck.com/bmf_san

正直なところ、登壇を始めた初期の頃の発表内容やCFPについては不甲斐ない部分が多々あるのだが、ここ最近はだいぶ自信がついてきたので、一家言残しておくかと思った次第である。

自分流CFPの書き方

CFPを書く前に・・

CFPを書く前までにいつもやっていることを整理しようと思う。

登壇目的を考える

登壇することで自分が得たいものは何か？が決まっていると登壇のモチベーションになる。

自分にとっても聴衆にとっても価値が見いだせそうなことであるかどうかという観点を意識している。自分にとってのメリットだけ考えて、CFPの採択によって聴衆にとっても価値があると評価された、と考えるやり方でも悪いとは思わないが、色んな視点で考えておいたほうが発表テーマの幅も広がって自らが得られるものも増えると思っている。

登壇するイベントを決める

自分が過去参加したイベントであれば雰囲気やテーマなどにイメージを持ちやすいと思うが、そうではないイベントの場合は、過去の開催模様を調べたり、実際にイベントに参加してみたほうが良いと思う。

どういうテーマ、レベル感の発表があるのか、聴衆の特徴やスポンサー企業等はどんな感じか？といったことを知っておくと、実際に登壇するときにいくらか自信を持つことに繋がると思うので、割と大事な下準備だと思っている。

自分は過去の経験もあって登壇して人前で話すということに全く緊張しない、むしろ楽しめるのだが、こうした事前の調査を済ませておくことがメンタリティの保全にも繋がっているからという側面はあるように思う。

イベントのスケジュールを入念に確認しておく

これも当たり前の話ではあるのだが、CFPが採択されてもスケジュールが合わない、なんてことになってしまうと悲しいので、スケジュール調整を事前に済ませておけると良い。

CFPの書き方

CFPを提出する時点で発表のイメージが概ね出来上がっている、というのが自分的な取り組み方かもしれない。

CFPを書き始める時点で、発表テーマのアウトラインがある程度整理されていて、スライドを書き始めることがほぼできる状態になっている。

人に依るだろうが、自分の場合は、”ネタ”が先に用意されていて、「このネタは発表できそう」というものが見えてから登壇を検討する、というのがいつもの流れになっている。（キーワードからネタを作って、登壇準備する、みたいなケースとかあると思う。登壇駆動的だったり、それに近かったり。）

自分がどういうステップでCFPを提出しているか順を追って説明していく。

ネタを用意する

ネタがないと何も始まらない。

興味・関心に基づいてプライベートで行っていたことをそのままネタにすることもあれば、特定の技術に関連してネタを考えるところから始めることもあるが、殆ど前者の場合が多い。

ブログを書く

CFPを提出するのにブログを書くとはなんぞやといった感じかもしれないが、自分にとってこのプロセスが非常に重要である。

ブログを書く≒CFP書けた、スライドできたも同然に近い。

ブログを書き上げておくことで、ネタを発散させることができるため、CFP執筆もスライド作成もスムーズに進めることができる。

ただのメモ書きではなくて、構成をちゃんと考えてブログを執筆しておくことが重要。

CFPを書く

ブログを書いてからCFPを書く、というのが自分のやり方になっている。

いきなりCFPを書くのではなく、書くために色々な整理をする。

ここ最近はmiroを使って整理している。

下図のような感じで整理している。

自分がCFPを書き上げるために用意しているフォーマットはこちら。

• セッションタイトル
• イベント情報
• CFP
• 採択基準
• 話すこと・話さないこと
• 伝えたいこと
• キーワード
• アウトライン
• スライドのラフ
• 調査

このフォーマットを順不同で仕上げることでCFPが完成する。

このフォーマットの大元のネタは、昔勤めていた会社の先輩エンジニアに教わったものをある程度ベースにしているが、自分なりの手を色々加えている。

Go Conference 2021に提出した準備内容を例に、フォーマットについてそれぞれ解説する。

セッションタイトル

セッションのタイトルを書く。

ネタが用意できている、ブログが書けている時点でセッションタイトルは概ね定めることができるが、それらがまだの準備できていない場合は、仮のタイトルを先に決めておいたりする。

タイトルの考え方としては、一息で端的に発表内容のイメージが伝わるか？だけを考えている。コーディングするときに関数や変数の命名作業の考え方に近い。

イベント情報

イベントに関する情報を確認・記載しておく。

イベントタイトル・イベント日時・CFPを提出しようとしている登壇枠詳細などを記載。

CFP

提出するCFPの文章を書く。

他のパートが整理できたあとで書き上げることもあれば、先にラフに書き上げることもある。

CFPは文字数がある程度限られている気がするが、そうでなかったとしても、なるべく端的に書くように意識している。

採択する側にとって必要な情報を盛り込んでいれば、手短に書き上げれば良いはずと考えている。

自分は次のようなアウトラインでCFPを書き上げている。

• 何について話すか
• どういう人に対して話をしたいか、聞いてもらえると良さそうか
• 発表から得られる情報は何か
• 発表内容のアウトライン
• 補足資料リンク

採択基準

イベントの採択基準について確認・記載しておく。

大体のカンファレンスでは採択基準が設けられている。

これはレギュレーションなので、よく読んで確認しておく。

採択基準だけでなく、行動指針などもちゃんと読んでおくべきである。

話すこと・話さないこと

話すこと・話さないことを書く。

特に話さないことをちゃんと書いておくのが大事だったりする。一番伝えたいテーマを優先として、関連性の低いことを話しすぎてしまうと、内容が発散して伝わりづらくなるため、話す必要がないようなことを明確にしておく。

伝えたいこと

伝えたいことが何か書く。

いくつ書いても良いと思うが、1テーマにつき1つに焦点を当てるようにしたほうが内容はまとまりやすい。

キーワード

発表内容に関連するキーワードを拾い上げて書く。

これはアイデアを広げるためというよりかは、整理して要点を見つけるためにやるというニュアンスが大きい。

書き出してみるとこのキーワードが重要だというのが見えるので、それを元に伝えたいことや主張をまとめやすくなる。

裏を返すと、触れる必要がなさそうなキーワードも見えたりするので、エクササイズがてら書き出してみるようにしている。

アウトライン

発表内容のアウトラインについて書く。

これは書いたり書かなかったりする。ブログが仕上がっている場合は書かなかったり、仕上がっていない場合はブログを書くために書いたりする。

ブログが仕上がっている場合は、ブログの内容をベースにアウトラインを整理している。

スライドのラフ

スライドのラフイメージを付箋ベースで書く。

これはアウトラインからスライドにどう起こすかをイメージして書くのだが、最近はスライド作成ソフトを起動して、そちらでスライドを付箋代わりにアウトラインを作って、スライドを作っているので、やらなくても良かったりする。だが、やっておくと発表の流れを意識できるので、違和感や深堀りすべき箇所に気づいたりするので、やっておく価値はある。

調査

後で入念に調べておきたい、深堀りしておきたいこと等があれば書いておく。

サンプル実装を用意したり、技術検証をしたりといった調査事項等をまとめてメモしておく。

主張したいことの論理や事実確認等の確認事項なども書いておいたりする。

CFP例

実際に提出したCFP例を記載しておく。

Go Conference 2021/net/httpでつくるHTTPルーター自作入門

Goの標準パッケージであるnet/httpを使ってHTTPルーターを自作する方法についてお話します。net/httpを使った簡単なサーバーを起動するコードの読み解きから始めて、HTTPルーターの自作方法、アルゴリズムについて解説します。 優秀なルーターがOSSとして存在しているため、あまり自作するような機会はないかもしれません。しかし、自作を通して、net/httpや木構造への理解を深めることができるかと思います本LTはGoの入門者をターゲットとしてお話しします。

本LTの主旨となる資料を記載します。

## Github
- [github.com - bmf-san/goblin](https://github.com/bmf-san/goblin)

## ブログ
- [GolangのHTTPサーバーのコードリーディング](https://bmf-tech.com/posts/Golang%E3%81%AEHTTP%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)
- [URLルーティング自作入門 エピソード1](https://bmf-tech.com/posts/URL%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%87%AA%E4%BD%9C%E5%85%A5%E9%96%80%E3%80%80%E3%82%A8%E3%83%94%E3%82%BD%E3%83%BC%E3%83%89%EF%BC%91)
- [URLルーティング自作入門 エピソード2](https://bmf-tech.com/posts/URL%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%87%AA%E4%BD%9C%E5%85%A5%E9%96%80%E3%80%80%E3%82%A8%E3%83%94%E3%82%BD%E3%83%BC%E3%83%89%EF%BC%92)
- [Introduction to URL router from scratch with Golang](http://web.archive.org/web/20251207231313/https://dev.to/bmf_san/introduction-to-url-router-from-scratch-with-golang-3p8j)


## スライド
- [GolangでURLルーターをつくった](https://speakerdeck.com/bmf_san/golangteurlrutawotukututa)

Go Conference 2023/天下一HTTPRouter舞踏会

こちらは採択されたのだがどうしても調整のできない諸事情のため辞退させて頂いたイベントになる。本当に参加したかったという悔しさと運営の皆様方への申し訳無さが募ります。。。　このネタはまだスライドに起こしていない未発表作ではあるので、次回再チャレンジしようと思います。

Goには標準でルーティングに使える機能（マルチプレクサ）が用意されていますが、実際の開発では何かしらのHTTP Routerのパッケージを利用することが多いのではないかと思います。
私はHTTP Routerを自作しているのですが、自作パッケージと世に有るパッケージとの性能差を比較してみたくなりました。
そこでベンチマーカーを実装し、性能差の比較に取り組んでみました。
いくつかのパッケージをピックアップし、比較してみた結果とそこから得られた学びについてお話しようと思っています。

このLTでは次のようなアウトラインを考えています。
モチベーション
前提（性能比較における前提条件）
計測手法および計測対象
計測の結果
学び

「どのHTTP Routerがもっとも性能が出たのか？（俺調べ）」
「標準のマルチプレクサとの性能差は？」
「性能だけをHTTP Routerの選定基準として考えることができるのか？」
などといった疑問についての私なりの回答を示したいと思います。

// 以下はCFP本体ではなく、補足情報的な枠で提出したテキスト
この発表の本筋は、「天下一HTTP Router武闘会」という過去の発表に基づきます。
cf. https://speakerdeck.com/bmf_san/tian-xia-httprouterwu-dou-hui

こちらの発表で当初内容を整理しきれなかった部分を整理し、ブラッシュアップした内容を今回の発表テーマとして考えています。

 武闘会だと物騒で、武闘会2だと謎なので舞踏会にしてみました。

その他関連情報
https://dev.to/bmf_san/implemented-a-bench-marker-to-compare-gos-http-router-146p
HTTP Routerの比較についてまとめた記事です
https://github.com/bmf-san/goblin
自作しているHTTP Routerです

裏のテーマとしては、HTTP Router実装の面白みなんかも聴衆に伝わると良いかなとも考えています。

まとめ

自分がCFPを書くときのポイントというかコツというか要点としては、「ブログを書き上げておく」ことに尽きるかなと思う。

文章でアウトプットできていればプレゼンテーションの準備は6~7割くらい済んでいるというお気持ちでいる。

普段CFPを仕上げるときはこんな感じの流れで書いているが、回を重ねるごとにやり方がラフになったりするのだが、ブログを書くというとこの作業だけはマストで外さないようにしている。

CFPが採択されれば後は、流れに乗ってスライドを作ったり、煮詰めたりするだけなので、しなやかに作業を進めることができる。

多少形式ばったところはあるが、準備を怠らないことで作業はスムーズになるし、採択率も上がるのではないか（個人的主観）と思う。

そういえば過去一度だけ運営として採択側を務めたイベントがあるが、やはり採択側の気持ちになるというのも一定大事な点かなと思う。

所感

こういうビジネススキルみたいなものは勉強する余地があるなぁと常に思っているが、怠惰ゆえにやれていない...

伝え方一つで印象が左右されるようなものなので、磨きをかけた分のリターンは大きいと思ってはいるが、最近はChatGPTが良い師になってくれそうな予感がしている。

余談

CFPだけの話に留めようと思っていたが、余談を付け加えておく。

スライド作成で意識していること

登壇イベントのスライド作成で意識していることをいくつか整理してみた。

• まずラフに仕上げていく、とにかく先に手を動かす、詳細は少しずつ仕上げる。アジャイルっぽく
  • スライドを1枚ずつ完成させるようなやり方をするとウォーターフォールの罠にハマる
    • 大体手戻りしたり、全体感を見失ってスライドの流れがぶれたりする
• 文字を入れすぎない
  • プレゼンテーションの資料とはそういうものだと思う
  • たくさん文字書いても聴衆は読みきれないし、聴衆は話を聴きに来ている
• 素振りする
  • 時間を計測、本番と同じ環境（端末、発表方法等環境を合わせる）練習する
    • スライドの切り替えもちゃんと操作する、画面分割とかするならスピーカーノートがちゃんと見えるか？などもちゃんと確認する
    • 本番で手間取ると時間を無駄にしてしまう。。。 -1スライドあたり何秒の時間を使えるかざっくり確認しておくのも良い
• ボリュームは控え目にする
  • 15分の登壇であれば、12~3分程度で話しきれる量にスライド枚数や内容を絞っておくのがちょうど良かったりする
  • 緊張しなくともなんだかんだ話したいことが色々有ったりするとトークは伸びがち（練習不足とも言えるが..）
• スピーカーメモを書きすぎない
  • そのまま読み上げたら発表できるようなメモにしない
    • アナウンサーでもなければ棒読みになりがちw
• 話のつなぎ目で使う言葉を考えておく
  • トークの流れの中で、話が切り替わるシーンがあると思うが、そういうときにどうやってスムーズに次の話に進めるか、というのが自分は意外と悩んだりするので、言葉選びをしておいたりする
    • 良い言葉見つからないようなときは話の流れに改良の余地が有ったりするのでリファクタする
• 自己紹介スライドは質素にする
  • 登壇の目的やイベントによってはちゃんと書くべきであるというケースを除いては書き過ぎない。手短で良い。
  • 後夜祭などで誰かとコミュニケーションを取るためのきっかけとして戦略的に書く、という考え方もあるが、スライドが全部仕上がってから考えれば良い程度の優先度。
• 安易な冗談やギャグを盛り込まない
  • オフィシャルな場でやるトークは不用意に”ネタ”を盛り込まない。コストに見合わないリスクを背負い込む必要はない
    • 奇をてらった比喩とかも..
• レビューしてもらう
  • 個人の活動としては個人で完結させてしまうので行なわないことが多いが、業務の一環の場合などは他者のレビューを通すと良いフィードバックをもらうようにすると良い