スクフェス三河のプロポーザルのフィードバックと採択に関わって、思い浮かべたこと🐱
はじめに
今回、スクフェス三河のプロポーザルのフィードバックと採択という貴重な体験をしました。
本稿では、せっかくの体験をしたので、採択が終わったこの時点で、感じたこと・思ったことをふりかえって共有したいと思います。
※この記事は、かとう個人の感想として書いたものであり、運営を代表したものではないことを予めご承知ください。
プロポーザル採択のプロセスについて（おさらい）
スクフェス三河でも、RSGTと同様にConfEngineを使ったオープンプロポーザル制を採用しています。川口さんがRSGTの採択プロセスについて詳しく書かれた記事がありますが、基本的な流れは同じです。
- プロポーザル募集期間：ConfEngineでプロポーザルを公開募集
- Like投票期間：参加者がアカウント作成してLike投票
- 運営委員による採択審査：Like数を参考にしながら、カンファレンス全体のバランスを見て採択を決定
- 採択通知：採択・不採択の連絡
特に重要なのは、「Like数が多いから通過、とは限りません」という点です。運営委員がわいわいと議論しながら、プロポーザルのテーマがカンファレンスのテーマにあっているか、全体の流れや、ゆとりあるスケジュールになっているかどうか、様々な観点から採択を決めていきます。
スクフェス三河特有の点として、採択の際にはスクフェス三河のConceptに立ち返って判断しています。
- 「ものづくりを実践している人たちの新しい挑戦が生まれる場」
- 「情熱を持ってプロダクト開発や組織運営に携わる人たちが交流し、次への活力を生み出します」
- 「自ら手を動かし挑戦する人同士が背中を押しあいながら、ともに未来を作っていく」
といった理念に合うかどうかを大切にしています。
運営委員の気持ち：2週間以内の採択通知を目指したい
運営委員としては、プロポーザル締切から2週間くらいで採択通知をしてあげたいという気持ちがあります。
これにはいくつかの理由があります。まず、講演資料の準備には相当な時間がかかります。採択が決まってから講演当日まで、スライド作成、内容の整理、練習と、どれも丁寧にやろうとすると時間が必要です。
また、特に伝統的な企業にお勤めの方の場合、社内での承認プロセスが複雑で時間がかかることもありえます。上司への相談、部門での承認、場合によっては会社としての正式な許可取得など、社内プロセスがなかなか進まないケースも珍しくありません。実際、過去そうした社内プロセスで苦労されている講演者の声を聞いています。
さらに、いろんな事情で講演者の都合により辞退される場合もあります。その時は別の方にお願いすることになりますが、その別の方にとっても準備時間は同じように必要です。補欠の方にも十分な準備期間を確保してあげたいのです。
幸い、今年のスクフェス三河では、実際に2週間以内で採択通知を送ることができました。運営委員のメンバーの半分が翌週のスクフェス大阪に出かけることもあったので、スケジュール的にはタイトでしたが、何とか間に合わせることができました。
採択する側になってあらためて痛感した ネタバレになるくらいにプロポーザルに盛り込むことについて
プロポーザルを審査する側に回って、あらためて痛感したことがあります。それは「ネタバレになるくらいに詳細をプロポーザルに盛り込む」ことの重要性です。
従来より、天野さんよりプロポーザルについての記事で「全部ネタバレするくらい書いてください」とフィードバックしていると書かれていますし、えわさんも同様の記事で「Abstractはネタバレするくらい具体的に書く」ことの重要性を語られています。この点について、採択する側の視点から改めて考えてみたいと思います。
まず野中郁次郎先生のSEKIモデルでいうところの「内面化： 身体で覚える 形式知 →暗黙知」、つまりわたし自身の体験から得られるあなた自身の体験が何より大事だと、個人的には思っています。
よくあるパターンとして、「○○について勉強したことをまとめて発表します」というプロポーザルがあります。もちろん学習成果を共有することは素晴らしいのですが、よほど専門的に深く勉強していないと、もっと専門的にやっている人が既にいるものです。
一方で、「わたし」ならではの経験、あなたが実際に感じたこと、そこから得た気づきは、あなた自身のオリジナルです。どんなに専門的にやっている人でも、あなたの体験そのものにはかないません。
ただし、自分にとっての「ネタ」（言い換えると経験のまとめ）が、他の人にとっても「ネタ」になりうるかは、ダイアローグを通さないとわかりません。逆に言うと、ダイアローグを通して、自分にとっての「ネタ」がみんなにとっての「ネタ」になりうるのです。
プロポーザルをセッションの設計図（ソース）と考えてみてみましょう。
オープンソースの精神で考えると、ソースは全部見せて、世のため人のため役に立ちそうか第3者にみてもらった方が、その経験のまとめ（＝設計）が役に立つかはっきりしてきます。自分にとってのネタ（＝ニーズ）は何か、ひいては他の方にとってのネタ（＝ニーズ）が何か、はっきりしてくるメリットもあります。
このプロセスは、まさにオープンソースの開発過程そのものではないでしょうか。
また、経験したことを参加者に追体験してもらうワークショップ形式も大歓迎です。むしろ、体験を共有する手段としてワークショップは非常に有効じゃないかなーと個人的には思っています。
今回使ったフィードバック用プロンプトについて
今回のスクフェス三河では、フィードバックを行うにあたって、生成AI(LLM)のプロンプトを用いました。
このプロンプトには、先ほど述べた「ネタバレになるくらいに盛り込む」という観点を含め、良いプロポーザルの条件を整理して組み込みました。具体的には以下のような方針です：
- ポジティブなトーンでの建設的な提案：批判的ではなく、プロポーザルの価値を認めた上での改善提案
- より具体的な内容や実例の追加提案：抽象的な表現を具体的なエピソードに変換する提案
- 本番のネタバレレベルの詳細情報の追加推奨：参加者にとって明日から使える知見の充実
実際にフィードバックした結果、提案したご本人より知っている事実や体験を共有してもらい、「これって参加者にも役立つ話じゃね」と共感できた事例がいくつか出てきました。もちろん、ご本人は事実や感覚・体験はご自身のものなので当然なのかもしれませんが、それが実は他人にはわかり得ない貴重な情報になり得るのです。
共有してもらってはじめて「応援したい」気持ちになったプロポーザルもいくつかありました。
で、今後、プロポーザルを出す前に、フィードバック用プロンプトをかけて一度ふりかえってみるとよいかもしれません。
ということで、今回使ったフィードバックのプロンプトを公開します。
冒頭部分、「スクラムフェス三河実行委員です。プロポーザルありがとうございます。以下、生成AI(LLM)からのアドバイスですが、ご参考になれば幸いです。」がスクフェス三河固有の部分なので、適宜編集して（削って）もらってOKです。
アジャイルでよく言われる「検査・適応」が、プロポーザル提出の段階でも大事だと思います。まずはLLMと対話してもらうとより一層よくなると思うのです。
最後に：採択できなかったプロポーザルについて
今回採択できなかった講演でも、別のところだと通る可能性は充分あると思っています。特にフィードバックを受けて完成度が上がってきたプロポーザルについては、是非別のところに持っていって欲しいという気持ちになりました。
具体的には、10月に開催予定のスクラム祭りなど、他のカンファレンスでもプロポーザル募集があります。今回のスクフェス三河では採択に至らなかったとしても、そのプロポーザルが他の場所で花開く可能性は十分にあるのです。
プロポーザルを書くこと自体が、ご自身の経験や知見を整理する良い機会になります。そして、フィードバックを通じてより良いものに磨き上げていく過程は、きっと次の機会につながるはずです。
ぜひぜひ採択できなかったプロポーザルを他のところでリトライしてくれるとうれしいです。
最後に、採択・不採択に関わらず、プロポーザルを出していただいた皆さんの挑戦そのものが、「ものづくりを実践している人たちの新しい挑戦が生まれる場」というスクフェス三河のConceptを体現してくれていると思います。
本当にありがとうございます！
Discussion