1.
Five F’ing Questions
You Should Answer In
Your Proposals
Daisuke Maki @lestrrat (HDE Inc)
Rejectcon 2018
Sep 29, 2018

2.
CfPに応募する
プロポーザル内容で
語るべき事項5つ

3.
「書式」はまた別の話
https://blog.builderscon.io/entry/2017/05/09/090000

4.
•コンパクトに
•審査員と来客にわかりやすく
•カンファレンス趣旨に合ったものを
•自分独自の視点で
•自己紹介はしない
tl;dr

5.
1. あなたは誰？
(Who The F Are You?)

6.
これは引っかけ問題です

7.
自己紹介は一切いりません

8.
あなたの素性の説明は
主題に関係ある場合のみ
教えて下さい

9.
それ以外はマイナスばかり
• あまりにも同じ所属先の人が多いと、
それだけで落選
• 経歴による権威に頼って説明を省くと
プロポーザルが薄味になって落選
• 「もうこの人聞き飽きたなー」と
思われて落選

10.
必要性がないのに
自分の素性は書くなら
あくまで「おまけ」で！

11.
2. トピックは何？
(What is this proposal about?)

12.
きちんとプロポーザルで
トピックを伝えよう

13.
え、当たり前だろって？

14.
本当にある例

15.
「〇〇を使うコツ」
〇〇に関する話。〇〇を
うまく使いこなす方法を
語ります。

16.
「〇〇を使うコツ」
〇〇に関する話。〇〇を
うまく使いこなす方法を
語ります。タイトルで読んだから知ってる！

17.
「〇〇を使うコツ」
〇〇に関する話。〇〇を
うまく使いこなす方法を
語ります。
え、これで全て？！

18.
（というわけで）
当たり前じゃ無い

19.
（というわけで）
当たり前じゃ無い

20.
重要なのはタイトルと
最初の段落

21.
タイトルと最初の段落だけ
でも何がトピックなのかわ
かるようにしましょう

22.
5W（When/Where/Who/What/
Why)をタイトルと最初の
段落に込める

23.
「Go言語とつきあうコツ」
Go言語はジェネリックスが存在しない
ため非難されがちですが、コード生成
を使う事によりジェネリックス無しで
もフレキシブルなコードを記述するこ
とが可能です。本セッションでは
OpenAPIやstruct定義からコードを生成
する方法を紹介します
(必要ならさらに説明を続ける)

24.
「Go言語とつきあうコツ」
Go言語はジェネリックスが存在しない
ため非難されがちですが、コード生成
を使う事によりジェネリックス無しで
もフレキシブルなコードを記述するこ
とが可能です。本セッションでは
OpenAPIやstruct定義からコードを生成
する方法を紹介します
(必要ならさらに説明を続ける)
注：適当な例です

25.
「Go言語とつきあうコツ」
Go言語はジェネリックスが存在しない
ため非難されがちですが、コード生成
を使う事によりジェネリックス無しで
もフレキシブルなコードを記述するこ
とが可能です。本セッションでは
OpenAPIやstruct定義からコードを生成
する方法を紹介します
(必要ならさらに説明を続ける)

26.
何故タイトルと最初の段
落が重要なのか？

27.
その程度の量にまとめられな
い→自分が話そうと思ってる
主題が何かわかっていない
理由１

28.
最初の一文で読者の心をつか
めないと、その後の文章も読
んでもらえない
理由２

29.
審査員はなんとかがんばってわ
かりにくいプロポーザルも読み
ます

30.
が

31.
審査員はあなたのトピックに
ついては素人。観客も素人。

32.
当日の来客のほとんどはタイト
ルを眺めるだけです

33.
来客に理解してもらえな
いかも？と思われたら採
用されません！

34.
3. 観客が得られるものは？
(What can the audience take away from this talk?)

35.
「わかるだろ」と思って
も明確に何を得られるの
か書きましょう

36.
「Go言語とつきあうコツ」
Go言語はジェネリックスが存在しない
ため非難されがちですが、コード生成
を使う事によりジェネリックス無しで
もフレキシブルなコードを記述するこ
とが可能です。本セッションでは
OpenAPIやstruct定義からコードを生成
する方法を紹介します
(当然、もっとちゃんと書けばもっとわかりやすく書
けますが、これはサンプルです)

37.
当日の来客のほとんどはタイト
ルを眺めるだけです（2回目）

38.
本文はどれを見に行くか
迷った時、気になった時
にのみ読まれる

39.
その時に客が何を得られ
るのかを伝えるべき

40.
来客に理解してもらえな
いかも？と思われたら採
用されません！(2回目）

41.
4. 自分だからこそ語れるストー
リーか？（誰かと被る？）
(Is this a unique story?)

42.
例

43.
今回応募されつつあったプロ
ポーザルの傾向を見てて審査員
／運営スタッフが考えた事：

44.
「今回『マイクロサービ
ス』って書いてあるプロ
ポーザルは多分ほとんど
落ちるな…」

45.
流行り物・同じネタのプロポー
ザルは不利（同じ枠・客を奪い
合う）

46.
（が、流行り物だからこそ語り
たいというのもあるでしょう）

47.
ネタが被りそうだったら、「自
分にしか話せない視点」をわか
りやすく盛り込む！

48.
同じ題材でも自分だけの「視
点」から語ることによってグッ
とポイントがあがります

49.
5. カンファレンスの求め
るものと合ってる？
(Does my proposal fit the conference?)

50.
カンファレンス運営陣が求めて
るものをくみ取ろう

51.
https://docs.google.com/document/d/
1Cr0X3aBmZBOPp99Hj3FHCfVdRXpLxY51lvisM6hI9T4/edit

52.
builderscon → 基本、技術に
ついて語って欲しい
（基本エモい話は要らない）

53.
直接的な技術以外のトピックの
場合は語り方が重要

54.
builderscon → 「科学的な手
法」を使って語って欲しい
(仮説→試験→検証…)

55.
さらにコンテキストを共有する
ために余計に説明が必要かもし
れない

56.
builderscon → 何かの紹介で
はなく、過程を考察してほしい
(紹介はブログとかでやってほしい）

57.
どんなに良いプロポーザルでも
趣旨にあってないと採用できな
い！

58.
• あなたは誰（かは書かない）？
• トピックは何？
• 観客が得られるのはなに？
• 自分だけのストーリーか？
• カンファレンスの趣旨に合ってる？
recap

59.
おまけ

60.
タイトル

61.
×「〜の話」

62.
×「〜やってみた」

63.
× 小説・ラノベ風

64.
タイトルが全てではないが、
ふわっとしたタイトルは
たいてい自分が何について
話したいか決まっていない！

65.
The End