アジャイル/スクラムコミュニティでは、RSGT2023をはじめ、公募制のスクラムフェスが定期的に開催されるようになり、プロポーザルを書く機会や見る機会が段々身近なものになってきました。
それに伴い、「プロポーザルを書いてみたい！」という素敵な方々も増えてきていますが、そうした方々から「プロポーザルってどう書けばいいの...？」「プロポーザルを書くハードルが高い...」という話をよく聞くので、そういった話を聞いたときに何か参照できるものがあるといいなあと思い、記事にしてみることにしました。*1
自分はプロポーザルを書くスペシャリストだというわけではないのですが*2、今年1年で11個プロポーザルを出したり、プロポーザルのフィードバックが行われる現場に10回以上立ち会ったりと、プロポーザルについて考える機会にはそれなりに恵まれているのかなあと思ったので、以下に自分なりの考えを整理していきます。
記事の注意点/前提事項
- Confengineを用いた公募制カンファレンスを想定しています。
- 記事を書いている人の経験が、スクラム/アジャイル系のカンファレンスに偏っています。
- セッションの内容や魅力をうまく伝えるためにどうすると良いか？という部分に主眼を置いているので、採択されやすくなるかどうかは関係があまりないです。(セッションの内容を正しく記載した結果、実行委員会の求めているものとのずれがはっきりする場合もあり得ます)
プロポーザルを書くときに意識すると良いこと(項目別)
Title
以下のいずれかのパターンでタイトルを検討します。
自分の場合は、もしセッション内で多くの人が目を引くようなキーワードや極大値/極小値があるならば2のパターンを軸にタイトルをつけ、特にそういう要素がないのであれば、1のパターンでタイトルを組み立てています。
また、以下は注目を集めたくてついついやりがちですが、セッションを聞いた人/話す人双方に取って不幸なことになりかねないので、注意です。
- 主語の大きさが不適切(「全人類に捧げる〜」や「誰もが必ずなれる〜」...)
- 用いられている単語の解釈の仕方によってセッションの価値が大きく変わる(「大規模開発」と書いているが、人によっては大規模とは思えないような人数での開発の話だった...)
- セッションで話す内容とミスマッチが発生している(タイトルで参加者が興味を持ちそうな単語を入れているがセッションではその内容が主題ではない)
Abstract
自分の場合、以下のいずれかのスタイルで記載します。
- セッションの要約を記載します。誰に向けたセッション(=Target audience)でどういう内容(=outline)を何を目的に話すのか(=Learning outcome)、という形式で記載することが多いです。
- (セッションで解決したい)あるあるな事例や問題意識が強くもたれるような事例を冒頭に書きます。その後、そのような事例の誤った解決策や誤解されがちなポイントを記載し*5、セッションで提言する解決策や問題を乗り越えるまでの過程/実践したプラクティスを記載します。
- セッションにまつわるストーリーを記載します。ストーリーの構築例はさまざまな書籍で触れられているので割愛しますが、自分の場合は、「印象的な事件→解決を試みるもうまくいかなかった話→掴めたきっかけ→掴めたきっかけを糧にして問題を乗り越えた」という形式で書くことが多いです。なお、このスタイルをとる場合は、セッションで話す具体的な内容がぼんやりとしがちなので、outlineで構成を詳細に書くなどといった工夫があると良いです。
他にも、自分はやったことがないですが、セッションで話すポイントを時系列で全て書き切ってしまうのも手だと思います。
また、パターンの使い分けは、カンファレンスの色*6を見ながら決めていきます。
最後に、やってしまいがちですが注意したい内容を書きます。
- 「ヒントになれば幸いです」「もしかすると〜が持ち帰れるかもしれません」「〜の元となるアイデアを紹介します」といった保険の文言(セッションを聞いた参加者の学びに貢献しない内容)を記載してしまう。
- 話す内容だけが記載されていて、参加者がどういうアウトカムを得られるのかわからない。
- 押し付けが強く、読んでいる人の思考を無理やり制御してしまう記述になっている。(「〜は誰しもが問題だと思うでしょう」「〜が良くないのはいうまでもありません」「〜という経験は誰しもがしたことがあると思いますが〜」...といった記述)
- 複雑な専門用語や、一部の人しか知らないような業界用語が多用されている。
- コンテキストの記載が薄い。(どういう状況下の話なのかや、どんな出来事が問題意識になっているのかが不明瞭になっている。本やスライドをオマージュした内容なのに、オマージュ元が省略されていて、知っている一部の人しかわからない)
- 今後実践しようと思っていることや自身の願望が、実践したものだったり実際に発生したことのように書かれている
Theme/Track/Category
この部分は、セッションの実行委員会が意図を込めてカテゴリを作っているはずなので、悩むようであれば一旦出した後に、実行委員会に対してフィードバックを求めてみましょう。(向こうからコメントしてくれる場合もありますが笑)
また、どういう意図でカテゴリーを作っているのか紹介しているカンファレンスの場合は、事前に説明されているスライドや動画を見ておくことをお勧めします。
例えば、スクフェス新潟であれば以下のスライド/動画でカテゴリーに込められた想いや、どんなプロポーザルを期待しているかが丁寧に説明されています。
Session Type
素直にセッションのタイプを入れます。
昨今のカンファレンスはオンライン/オフラインのハイブリッド形式のことが多いので、ワークショップセッションの場合は、Abstractなどプロポーザルのどこかしらにオンラインonlyを想定しているのか、オフラインonlyを想定しているのか、ハイブリッドを想定しているのかを記載しておきましょう。
Duration
基本的には素直にセッションにかかる時間を入れれば良いのですが、ほとんどの場合採択後に修正ができない部分なので、これまでに出した自分のプロポーザル(なければ他の人のプロポーザル)を参考にしながら、時間を相対見積もりしておきましょう。
大まかにトークスクリプトを作って、時間を計測しておけるとなお安全です。
Level
ここは正直あんまりどう指定したらいいのか明確な基準を持っていないのですが、これまでに出されてきたプロポーザルから、以下のようなイメージを持っています。
Beginner...発表分野について全くの未経験者や学び始めたての人を対象としたセッション
intermediate...発表分野の基礎知識は持っていてある程度実践もしているが、チームや組織をリードするような経験はまだ持ち合わせていない人を対象としたセッション
Advanced...発表分野を長らく実践している人をはじめとしたエキスパートの人を対象としたセッション
Executive...経営層など強い権限を持っている人を対象としたセッション
Co-Presenters
誤って別のアカウントの人をPresenterとしないように、正しく指定されているかプロポーザルをaddする前に本人にアカウント確認しておきます。
Target Audience
セッションを聞いて利益が出るAudienceをできる限り具体的に記載します。
likeを集めたいといったフォースが働くと、「全員」や「誰でも」というような対象が極めて広い記載にしたくなってしまいがちですが、参加者目線でみると本当に自分が聞いて役に立つのか分かりにくいですし、セッションのミスマッチも起きやすいので、避けておくのが無難です。(現場で使える何かを持ち帰ってもらうことよりも、とにかく場を盛り上げることを重視するようなセッションは例外)
Prerequisites for Attendees
セッションを聞く前にあると良い知識や、読んでおいて欲しいスライドがあれば記載します。
読まなくてもセッションを聞けるけど読んでおくとより楽しめるようなものがある場合も、書いておくと良いです。(単純に参加者がより楽しめるというのもありますし、セッションの内容を想像する手がかりにもなるので)
Outline/Structure
ここは、プロポーザルを出した時点で書けるだけ詳しく書いた方がいいです。(Abstractでセッションの具体的な内容をあまり書かなかった場合は特に)
セッションのネタバレになってしまうことを危惧する気持ちもわかりますし、自身も意図的に隠していた経験があるのですが、プロポーザルを選ぶ立場(参加者や実行委員会の方々)からすると、この内容が薄いとセッションの予想がしにくくてなかなか選びにくかったり、「聞いてみたけどあんまり自分には興味がない内容だった...」となってしまうリスクもあるので、できる限り詳しく書いておくのがベストです。
とはいえ、プロポーザル段階ではまだ決まっていないです、という状況も全然ありえると思うので、そういう場合は素直に「ここはまだ話す内容が決まっていないです」という旨を記載しておくと良いでしょう。(もしAcceptされた場合、当日までにはアップデートするのを忘れずに笑)
Learning Outcome
セッションを聞いた結果、参加者(Target Audience)にとってどんな学びがあるのかを記載していきます。
セッションを聞く前と聞いた後の差分をイメージして言語化すれば基本的には良いのですが、意外と落とし穴に陥りがちな項目なので、以下に落とし穴に落ちてしまったパターンを書いていきます。
- 「hogeできるようになる」と記載してしまう。hogeができるようになった結果、参加者がどのような利益を得られるのか？が省かれている(セッションの効果が参加者に委ねられている)
- 「勇気を得られます」「元気が出ます」「〜をやりたくなります」と記載してしまう。勇気は学ぶものではないので、勇気を得た結果、Target Audienceがどのような行動変容を起こせて、それが具体的にどのような利益につながるのか？を書けるとベスト。
- アウトプットが書かれている(〜が聞けます、〜が知れます...)
Slides, Video, Links
セッションで話す予定の内容と重複する文献やスライドがあれば貼っておきます。
また、以前のセッションの続編で話をする場合も、過去のセッションのスライドや動画のリンクが貼ってあると親切です。
Requirements
ここは項目の説明の通り、発表にあたって必要な機材や会場レイアウトを記載しておきます。
Tags
何か他者の目を引くようなキーワードがある場合はつけておくと良いでしょう。
他にも、すでに出されているプロポーザルのタグを見て、自分もつけられるようなものがあればつけておくと良いと思います。(すでに出されている自分以外のプロポーザルに興味を持った参加者がTagをクリックした場合に自分のセッションが表示されるため)
プロポーザルを書き終えた後の見直し
プロポーザルを一通り書いた後に見直す観点を、以下に書いていきます。
内容の整合性
まず、TitleとAbstractとOutlineを見て、書かれている内容が一貫しているかを確認します。
特に、Titleは目をひくようなものをつけがちになってしまいがちで、AbstractとOutlineの内容から乖離してしまうことが多いので注意します。(主語が大きくなってしまったり、タイトルで触れられている内容が主題ではなくセッションで興味をひきそうなポイントになってしまったり)
次に、Outline&AbstractとTarget audience、Outline&AbstractとLearning outcomeをそれぞれチェックします。(Outline&Abstractの内容が、Target audienceにとって有益な内容になっているか？Outline&Abstractの内容を聞くとLearning outcomeが得られるか？を確認します)
キーメッセージ
色々盛り込んだ結果、話したいことがブレてしまっている可能性があるので、セッションのキーメッセージは何か？というのを問いかけてみます。
ここでキーメッセージが出てこなかったり、キーメッセージの存在感が薄い場合*7は、今一度各項目の内容を精査していきます。
また、moriyuyaさんが実践されているエレベータピッチを書いてみることも良いチェックになると思うので、こちらもぜひ参考にしてみてください。
プロポーザルのチェックポイント。エレベーターピッチを書いてみる。書けなかったら準備不足。
— N_A / プロダクトマネジメントコーチ (@_N_A_) 2022年10月8日
有名なエレベーターピッチのテンプレート
— N_A / プロダクトマネジメントコーチ (@_N_A_) 2022年10月8日
1.新しい提案段階の向けの『アジャイルサムライ』のエレベーターピッチ
2.成熟期向けの『キャズム』のエレベーターピッチがある
プロポーザルをもっと上手に書けるようになるために
自身がプロポーザルを上手に書けるようになるのに貢献したことを、以下にまとめます。
とりあえずプロポーザルを出す
ここまで色々書いてきましたが、何よりもプロポーザルを一度出してみるのがお勧めです。
プロポーザルを実際に書いてみると、記載に悩みながらこういう時にはどうしたらいいのか？という知見が溜まってきますし、フィードバックをもらえて具体的な改善ポイントがわかるようになっていきます。
モブプロ
プロポーザルをみんながいる場で見てもらったり、誰かと一緒に書いてみると、自分では気がつけない視点が多数もらえて学びが深まるのでお勧めです。
仲の良い人や信頼がおける人にお願いしてみるのもいいですし、コミュニティで書いてみるのもいいでしょう。
定期的に開催されているコミュニティだと、分散アジャイルチームの会はプロポーザルの熟練者の方々が集まっているのでお勧めです。
プロポーザルが上手な人のプロポーザルを見る
プロポーザルが上手な人のプロポーザルを見てみましょう。
100%主観ですが、以下の方々のプロポーザルは見ておいて損がないと思います。(もちろん、プロポーザルだけではなくセッションも素晴らしいので、セッションや過去スライドを合わせてみることもお勧めします！)
プロポーザルへのコメントをみる
「Comments」でソートしてみて、プロポーザルに対してコメントがついているものがあれば見てみましょう。
大体の場合はプロポーザルに対するフィードバックコメントであることが多く、他者からの視点が確認できるという点で、参考になるコメントが多く発見できるはずです。
おわりに
色々書きましたが、とりあえずプロポーザルを気軽に出してみて、その上でより良くするために色々と試行錯誤をしていくのがお勧めです。
試行錯誤の過程で、本記事が役に立てば何よりです。
あと、よりDeepな記事をmoriyuyaさんあたりが書いてくれることを期待しています笑
*1:何よりも、プロポーザルを書くときに自身が見直すリファレンスが欲しいという気持ちがあります笑
*2:そもそもプロポーザルを書くスペシャリストという概念が存在するのか疑問
*3:スクラムのカンファレンスであれば、例えばレトロスペクティブ, スプリントレビュー...
*4:例: リリースまでに必要なテストケースを1/1,000に減らしたテスト設計技法の紹介, KPTを100,000回やってみた...
*5:特に記載するような誤解ポイントがなければ飛ばします
*6:keynote speakerが誰でどんなことを話すことが想定されるか？他のカンファレンスと比較した時にどのような特色があるか？実行委員会の方々がどういったセッションを期待しているか...
*7:タイトルの内容から通り、単語として出てくる回数が少ない、OutlineやAbstractにキーメッセージが伝えるような内容が出てこない...
