天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

自分がプロポーザルを書く時に意識していること~2023年ver~

今日は、自分がプロポーザルを書くときに意識していることのupdate版を書いていきます。(以前の記事は以下です)

aki-m.hatenadiary.com

記事を書こうと思った理由

ちょうど一年前に上記の記事を書いたので、そこから一年経ってupdateした部分は更新したいなあと思ったのが理由です。

また、そのように思い至った背景としては、えわさんが上記の記事をポストしてくれていて、記事を書いてから一年経ったことに気がついたということがありました。

更新点

以下、前述したブログからの更新点を記載していきます。
なお、このような形式だとdiffが見られて自分は嬉しいのですが、記事を見る人の視点としては、一つの記事にまとめてほしいと思う人が多いと思うので、昨年書いた記事もそのうち更新しようと思います。

Title

大体は昨年と同じなのですが、Titleで参加者を引き付けようという仕掛けはここ最近だとあまり考えなくなりました。
一つのパターンとして、わかりやすい指標などをサブタイトルに入れることはありますが、そういった指標がないときは、無理にキャッチーなタイトルを狙うことなく、どんな話をするのかがはっきりと分かるようなタイトルを心がけています。

like数をもらうという観点だと、参加者を引き付けるタイトルが望ましいのは間違いないのですが、セッションに参加するかなやんでいる人にとってはタイトルのキャッチーさはミスリードになり得るため、Target Audienceとのマッチングが起きやすいようにシンプルなタイトルにすることも多くなりました。(例 : 「アジャイル開発で役立つセキュリティプラクティス」「JUnitで学ぶTest smells撃退法」「菅原道真スクラム」)

Abstract

昨年に書いた内容に加えて、以下の点に注意をするようになりました。

  • 冒頭には簡潔な要約を記載する
  • 問題意識を語るときには主語を自分にする

「冒頭には簡潔な要約を記載する」は、自分のセッションに興味があるのかないのかをプロポーザルを読んでくれた人がなるべく速く判断できるように注意するようになりました。
昨今は各地のカンファレンスでプロポーザルが増加傾向にある上、以前に比べて内容を詳細に記載してくれるプロポーザルが多くなったので、読み手のコストが上がっていると思っていて、そのコストを少しでも下げたいと思った点が、注意するようになった理由です。

「問題意識を語るときには主語を自分にする」は、あたかも世間でそれが問題になっているような記述をしてしまうことで、参加者の思考を奪ってしまうことが気になり、注意するようになりました。
昨年に書いたアンチパターンである「押し付けが強く、読んでいる人の思考を無理やり制御してしまう記述になっている」にならないように、より具体的な取り組みをし始めたと表現することもできるかもしれません。

Theme/Track/Category

選択の際に、昨年と意識することは変わっていません。

一方でTheme/Track/Categoryの活用方法には変化がありました。
具体的には、カンファレンスであまり出されていないTheme/Track/Categoryをstatisticsで確認して、そのTheme/Track/Categoryになるようなプロポーザルが出せないか考えることが増えました。

Session Type

昨年と意識している部分は変わっていません。

Duration

見積もりをするというのは変わっていないのですが、トークスクリプトを必ず作るようになりました。
この見積もりが外れると、参加者にとってデメリットが大きいと判断したのがその理由です。(話が薄すぎると参加者の貴重な時間を奪うことになりますし、濃すぎると情報過多すぎて共通理解が形成しにくい)

Level

昨年と基準としては大きく変わっていませんが、Advancedレベルは、その業界/分野の第一人者が聞いて発見になるような話にだけつけるようにしようと最近は思っています。

Co-Presenters

昨年と意識している部分は変わっていません。

Target Audience

具体的にどんな人が聞いてほしいのかペルソナを作ってから、そのペルソナを抽象化するというステップを踏むようになりました。
また、ペルソナに近い人が周囲にいる場合は、その人に対して事前に(=プロポーザルを出す前に)この話を聞いてみたいか確認するようになりました。

また、リーンスタートアップのCustomer Segmentsをイメージして書くようにもなりました。

Prerequisites for Attendees

昨年と意識している部分は変わっていません。

Outline/Structure

時間見積をする際にスクリプトがすでにできているので、そこに書いてある内容を包み隠さずすべて書くようになりました。

また、具体的に話をする内容ではなく、そこで話したい内容のタイトル/キーワードレベルに記載粒度は留めるようになりました。
これは、具体的に話をする内容をすべて書くと読み手のコストが高すぎるのと、プレゼンの準備をしていく過程で伝え方に変更があったりした際にlikeをしてくれた断面から齟齬が出そうなのがりその理由です。

Learning Outcome

昨年と意識している部分はあまり変わっていません。

考える過程には変化があって、まずさくっと書いてアンチパターンにハマって、そこからブラッシュアップを繰り返すようになりました。(元々は一回でひねり出そうとしていました)

ただ貼るだけではなく、なんで貼っているのかが分かる記載をするようになりました。

Requirements

昨年と意識している部分は変わっていません。

Tags

昨年と意識している部分は変わっていません。

プロポーザルを書き終えた後の見直し

昨年書いた部分に加えて、Abstractが90s以内に読めるか?は計測するようになりました。
前述もしましたが、昨今は各地のカンファレンスでプロポーザルが増加傾向にある上、以前に比べて内容を詳細に記載してくれるプロポーザルが多くなったのがその理由です。

プロポーザルをもっと上手に書けるようになるために

昨年書いた部分に加えて、普段から学んだことをプロポーザルにしたためる習慣をつけるようにしました。
結果的に、70件近くプロポーザルが溜まり、出したプロポーザル数も2倍近く増えました。

また、他人の話を聞いてそれをプロポーザルにまとめる活動もし始めました。2023年は、17件10人のプロポーザルを書きました。

やはり上手になるには数をひたすらこなすのが重要だと思っているので、この数を10倍にしていけるように、来年以降も何かしら数を増やす(実践機会を増やす)取り組みをしたいです。

最後に、プロポーザルの見本として、先日イベントでも絶賛されていて自分もプロポーザルの書き方という点でもめちゃくちゃ学びになるなあと感じたえわさんのプロポーザルを貼っておきます。

confengine.com