event-feedback

イベントのフィードバック

参加者、登壇者、スポンサー、そしてハッカソンの場合はメンターや審査員など、参加した人たちからフィードバックを集める方法を設計し、実施します。調査票、配信チャネル、タイミング、回答率を高める工夫、回答者に返す内容を担当します。他の人が行動に移せる調査結果をまとめて締めくくります。

振り返る対象は、あくまで参加者です。 samber/dev-event-organizer-skills@event-debrief は運営チーム自身の振り返りを行い、その側から境界を示しています。このスキルが集めるのは参加者からの意見であり、その要約は 「ここへのインプットであり、方向が逆になることはない」 とされています。

こちら側でも同じです。イベント後の検証は行わず、チームの分析もしません。

すでに担当が決まっているものが、ほかに4つあります。それらのために情報は集めますが、判断はしません。

兄弟スキル	担当範囲
event-market-fit	需要の判定です。参加者が 実際にしたこと（再参加率、更新率、満席になったか）を扱い、参加者の 発言 とは混同しません。調査結果は定性的なインプットの1つとして渡し、実施可否の判断はしません。
event-continuous-improvement	複数回にわたる傾向です。このスキルがまとめるのは1回分の調査結果です。昨年との比較は、意図せず範囲に含めてしまいやすいものです。
event-speaker-experience	登壇者に何を、いつ届けるか、つまり送付内容を担当します。このスキルは、評価を得るための調査票、つまり質問を設計します。
event-sponsor-fulfillment	スポンサー向けにROIレポートを作成します。このスキルはスポンサーから評価を集めます。方向は逆ですが、時期は同じ週です。

現場で実際に公開されている情報

運営者向けガイドでは、この取り組みをそれぞれ一行で紹介しています。DevOpsDaysは「アンケート調査は任意ですが、強く推奨します」としています。MLHは「イベント後のアンケートを参加者とスポンサーにメールで送る」としています。どちらも調査票の設計には触れていないため、質問項目、タイミング、回答率の目標は、このスキルで決めます。

イベント業界の調査エコシステムでは、実際のサンプル数に基づく回答率の範囲、アンケートの長さによる影響、満足度の基準が公開されています：references/response-rate-evidence-and-timing.md。コミュニティも調査結果を公開しており、WordPress、KubeCon、MLH、PyCon、Write the Docsなどがその例です：references/publishing-and-findings-handoff.md。

質問の作り方は、顧客開発インタビューから学べますが、その手法の半分はそのまま適用できません。守るべきルールは2つです。誘導しない表現にすること、そして「仮にどうするか」ではなく「実際に何をしたか」を尋ねることです。これらのルールが引き出すことを目的としていた購入の意思表示は省きます。イベントはすでに終わっており、販売するものは何もありません。

インタビュー

一度に質問するのは1つにし、可能な場合は選択式にします。質問6〜8があるのは、以下のメニューが効果の出る速さ、持続性、労力の点で大きく異なるためです。これらを確認せずに、デフォルトをユーザーに代わって選ぶことはできません。

1. どのような形式で、参加者は何人ですか。**イベントはすでに開催されましたか、それともまだ開催日を計画中ですか。**後半の回答によって、収集チャネルを丸ごと利用できるかどうかが決まります。
2. 実際に存在する役割は何で、誰の意見を聞く必要がありますか。まずどの役割が存在するかを聞いてから、誰の意見を聞きたいかを尋ねます。
3. これらの回答をもとに、どのような決定をする必要があり、誰が決定しますか。決定に結び付かない質問は、ステップ4で削除します。
4. 匿名性についてどのように約束しましたか。また、実名の人物のパフォーマンスを評価する内容はありますか。回答によって、調査方法とチャネルの両方が変わります。
5. 各役割の人にどのように連絡できますか。また、連絡先情報はどのように収集しましたか（登録、チケット販売、スポンサー契約、バッジのスキャンなど）。必要なのはリストだけではなく、同意を得た根拠です。
6. 調査結果を誰かの手に渡す必要があるのはいつですか。その日付が、このスキルの期限です。
7. これは単発ですか、それとも定期開催ですか。比較対象となる前回開催時の回答率はありますか。公開の総括はすでに予定されていますか。
8. 労力の上限はどのくらいですか。イベント終了後に使える時間、読む人と分析する人、当日の進行をまだ変更できるかどうかを確認します。
9. 予算のおよそ何割をスポンサーが負担していますか。

イベント形式と参加者を一堂に集められる機会

採用を重視するイベントやベンダー主催のイベントでは、スポンサー向けモジュールに、採用パイプラインに関する質問（面接への移行率や採用者1人あたりのコストなど）を追加します。コミュニティイベントでは、デフォルトでこれらを含めてはいけません。これは条件付きモジュールの1つであり、スキル全体にわたる分岐ではありません。

それ以外では、企業の購買担当者と趣味のミートアップ参加者に、同じタイミングで同じ言葉を使って同じ内容を尋ねます。実際に出力を変えるのは、次の2つの軸です。

• 形式によって調査方法が変わります。ハッカソンのアンケートでは、カンファレンスの基本項目に加え、チーム編成、メンターの対応状況、審査の公平性、ツールの品質、プロジェクトの継続に関する項目を追加します。これらは、学術的なハッカソン調査で主要な測定項目として扱われています。ミートアップなら、通常は質問を1つと自由記述欄を設けるだけで十分です。
• 参加者を一堂に集められる機会がまだあるかどうかによって、回答率を数ポイントではなく何倍も変えるチャネルが決まります。クロージング全体会、セッション終了後の休憩、デモデーでは、参加者全員が同じ会場に集まり、体験が新鮮なうちに回答できます。参加者が分散している場合、そのような機会はなく、メールの工夫でその差を埋めることもできません。メールをチャネルとする場合、event-attendee-email-sequencesが送信メールの文面と送信間隔を担当し、このスキルが担当するのは質問項目だけです。

ワークフロー

1. インタビューを実施します。開催日がまだ決まっていない場合は、まずチャネルの段階を選びます。この選択には、ほかの段階にはない期限があります。
2. 質問集ではなく、判断から始めます：Q3 の判断ごとに、その答えによって判断が変わる質問を書きます。残ったものが調査票です。それ以外は好奇心にすぎず、長さの段階に到達するための最も手軽な方法です。
3. 形式に合わせた質問セットを選びます：形式ごとの基本セットに、実際に存在する役割（Q2）向けのモジュールを追加します。セット、自由回答と選択式のバランス、記入例付きのペアについては、references/question-sets-by-format-and-role.md を参照してください。
4. 深さの段階に合わせて削ります：根拠となる判断が明確でない質問はすべて削除します。非常に短い調査票は、長い調査票に比べて回答率の中央値を2倍以上に高めます（利用可能な最大規模の調査）。このトレードオフをユーザーに伝えます。
5. チャネルを決める前に匿名性を設定します（§ 匿名性と自由記述）。匿名性によってチャネルの段階が除外されるため、先に決めます。
6. 24～48時間以内に調査を実施し、数日後にリマインダーを送ります。技術イベントでは実務家の間で強い合意がありますが、対照試験はありません。実施間隔については、references/response-rate-evidence-and-timing.md を参照してください。
7. ハッカソンでは、2つ目の調査票を今のうちに計画します：メインの調査はデモデーに実施し、1～2週間後にチームが作業を続けたかを尋ねる短いフォローアップを別途実施します。最初の調査を遅らせるのではなく、2つ目の調査を行います。
8. すべての調査結果に回答率を併記します。 回答を1件でも読む前に、役割ごとに回答率を算出します。その後に続くすべての数値は、この確度を引き継ぎます。
9. 結果はスコアではなく、調査結果として読み取ります。 自由記述を件数付きのテーマに分類し、満足度と再参加意向を決して平均しないでください。
10. 選んだ段階で、回答者に結果を共有し、フィードバックの輪を閉じます。次回の開催につながる唯一の手順です。
11. 調査結果を引き継いで終了します：全体の要約は event-debrief に、定性的な分析は event-market-fit に、登壇者ごとの資料は event-speaker-experience に、スポンサーの評価は event-sponsor-fulfillment に引き継ぎます。

ハーネスに永続メモリがある場合は、開催回ごとに次の内容を記録します。

• 実際に使用した調査票。
• チャネルと送信日。
• 役割ごとの回答率。
• 主な数値。
• 件数を添えたテーマ。
• 匿名性について約束した内容。
• 回答者に返した内容。

そうすれば、次回は新たに考案するのではなく、比較可能な調査票から始められます。そして、回答率は比較対象となる2回目の数値が並ぶまでは、まったく意味を持ちません。

以下のランキングはすべて標準設定であり、絶対的なルールではありません。状況や実施者によって変わります。制約によってある段階が選択肢から外れる場合は、そのメニューの軸となる項目からも削除してください。順序に残った段階は読者の意識にも残り、スコープとして戻ってきます。

このイベントについてすでに把握していることをもとに、3つすべてのメニューを再評価します。

• 開催中に会場内アンケートをすでに実施しているチームなら、ほとんどコストをかけずにチャネルメニューの最上位の段階を利用できます。
• 参加者が1つの Slack コミュニティのメンバーであるイベントなら、これらの段階では想定していないチャネルを通じて参加者に連絡できます。
• すでに2回調査結果を公開している主催者なら、3つ目のメニューで利用が進んでいない選択肢は、新しいプロジェクトではなく、すでに習慣として定着しています。

回収チャネル

回収率の高い順に並べたメニューです。設定や調整にかかる手間あたりの実際の回収数を示します。価値の根拠は測定された数値です。

• メールアンケート：回答率 10～30％。
• 会場内での回収：回答率 40～60％。
• インセンティブ：メールの回答率がおよそ1.5倍に上がります。
• 会場内での完了率：85～95％。回答率とは別の数値で、回答を開始した人のうち最後まで完了する人の割合です。

チャネルの比較には回答率のみを使います。出典、サンプルサイズ、ベンダー調査と研究調査の区分については、references/response-rate-evidence-and-timing.md を参照してください。引き継げるのは個別の数値ではなく、比率です。

• 手間（設定、当日の調整、賞品の管理）：メール＋リマインダー＋インセンティブ > 会場内での回収 > メール＋リマインダー > メール1通
• 価値（回収数、および記憶が新しいうちに回収できること）：会場内での回収 > メール＋リマインダー＋インセンティブ > メール＋リマインダー > メール1通
• 効率：メール＋リマインダー > 会場内での回収 > メール1通 > メール＋リマインダー＋インセンティブ
• コンプライアンスコスト（審査の発生、匿名性の放棄）：メール＋リマインダー＋インセンティブ > メール1通 == メール＋リマインダー > 会場内での回収

価値と手間の評価は一致しません。インセンティブは、チャネルを変更するよりコストがかかる一方で、得られるものは少ないです。会場内での回収は、インセンティブより回答率がその範囲の両端で高く、手間も少ないため、インセンティブの段階を完全に上回ります。効率の順位もこれに応じています。

それでも効率ではメール＋リマインダーが首位です。予定した送信を1回追加するだけで、無料で効果を上げられます。この効果を、回答者ではなく完了者を数える完了率の85～95％と混同しないでください。

コンプライアンスコストは手間と同じではありません。抽選形式のインセンティブには、回答に識別情報を付ける必要があり、氏名がわかる登壇者への匿名評価が、恒久的にひも付けられてしまいます。メールの2つの段階でリスクが同じなのは、露出が送信回数ではなく送信先リストにひも付くためです。匿名コードを使った会場内での回収が、最もコストを抑えられます。

• メール1通 - イベント後、登録者リストに1回送信します。
• メール＋リマインダー - 数日後にリマインダーを1回送り、必要な場合でも最後のリマインダーは1回までとします。それ以上送っても回答は増えず、疲労を招きます。
  • 一般向けリストの代わりに、または併用して、回答者がすでに参加している小規模グループのチャネルを通じて送信します。たとえば、プロジェクトチーム専用のチャットや、トラック専用のチャネルです。参加者同士のチャネルには信頼感やイベントの共有記憶がありますが、面識のない相手への一斉送信では、それらをゼロから築かなければなりません。また、これは追加の段階には当たりません。依頼は1回だけ行い、送信経路を変えるだけです。これはこのスキル独自の慣例であり、上記の出典付きの範囲と並べるための測定値ではありません。
• メール＋リマインダー＋インセンティブ - 賞品の抽選です。イベントに特化した賞品は、一般的なガジェットより効果的です。
• 会場内での回収 - セッション終了時のコード、全体会での呼びかけ、デモデーのフォームなどです。進行表に1行加える必要があります。

デフォルト：メール＋リマインダー。 Q1で当日までまだ計画中であること、形式上参加者を一堂に集める機会があること、Q8で進行表にもう1行加えられることが示されている場合に、会場内での回収に切り替えます。3つすべてが条件です。

優先度の低い選択肢：インセンティブ - 手間とコンプライアンスコストでは最下位、価値では2番目です。Q7で過去の回答率が範囲の下限以下であり、かつ当日がすでに終了している場合に限り、選択肢に加えます。

Q1でイベントがすでに終了しているとわかった場合は、会場内での回収を削除し、次回開催用に記録します。匿名性が必要な場合は、インセンティブの段階を削除します。抽選には身元情報が必要ですが、匿名性とは両立しません。

計測の深さ

選択肢のランキングです。設計と分析にかける時間あたりに、実際の行動につながる知見を得られる順です。ここでの順序はすべて判断に基づいています。回答率と長さのトレードオフは測定されています。

• 労力（作成、役割ごとの実施、精読と分析）：役割別の完全な調査票 > コア＋1つの役割別モジュール > 短いコア > 1問だけの簡易調査
• 価値（回答によって実際に変わる意思決定）：役割別の完全な調査票 > コア＋1つの役割別モジュール > 短いコア > 1問だけの簡易調査
• 効率：短いコア > コア＋1つの役割別モジュール > 1問だけの簡易調査 > 役割別の完全な調査票

この順序を裏付ける優越性チェックはありません。価値と労力が同じ順序なので、どの段階も一方だけを逸脱することはなく、チェックでは何も検出されません。構成上きれいに見えるだけで、チェックを通過したわけではありません。したがって、効率の順序そのものが、次の3つの主張に基づいています。

• 短いコアなら、長さに関する根拠が許す最大規模のサンプルから、イベント全体の評価が得られます。
• それより上の段階では、分析コストが数倍かかる一方、より少ない人数から、より限定的な回答が得られます。
• 回答率への悪影響は労力と効率に及びますが、価値には及びません。

ここではコンプライアンスコストの軸を設けていません。懸念されるのは自由記述に含まれる第三者の個人データであり、段階ごとに増えていくのではなく、最初の自由記述式の質問で一気に発生します。軸を設けると、同順位を順序として装うだけになるため、§ 匿名性と自由記述では代わりにルールとして扱います。

• 1問だけの簡易調査 - 評価を1問、自由記入欄を1つ。数十人規模のミートアップに適しています。
• 短いコア - 3〜5問：満足度／再参加意向、コンテンツに関する質問を1つ、運営に関する質問を1つ、「何を変えるべきですか」という自由記述を1つ。
• コア＋1つの役割別モジュール - 全員にコアを実施し、意思決定上の価値が最も高い単一の役割（スポンサーの更新、登壇者の再登壇と紹介など）にモジュールを追加します。
• 役割別の完全な調査票 - すべての役割に個別の調査票を用意し、ハッカソン向けの項目（チームの力学、メンター、審査の公平性、ツール、継続）と、それとは別の成果追跡調査も加えます。

デフォルト：短いコア。 次回開催までに特定の役割が担うべき意思決定をQ3が示している場合は、役割別モジュールを1つ追加します。Q1がハッカソンを示している場合は、完全な調査票に移行します。ハッカソン向けの質問は、ほかでは扱えないためです。

候補から外れやすい選択肢：役割別の完全な調査票 - 価値と労力では最上位、効率では最下位です。昇格条件（Q1またはQ9に基づく）：ハッカソンであること、またはスポンサーが予算の大半を負担していること。

Q2でスポンサーがおらず、正式な登壇者一覧もない場合は、役割別モジュールと完全な調査票を削除します。存在しない役割向けのモジュールは、丁寧さを装うだけで何も生みません。

匿名性と自由記述

どの段階が選択肢から外れるかに関わるため、配布方法を決める前に判断してください。

約束すること：

• 審査の公平性、メンターの質、インクルージョン、または特定個人のパフォーマンスについて尋ねる場合は、必ず匿名性を有効にしてください。 これは倫理上の理由ではなく、仕組み上の理由です。審査員に自分の名前を読まれると思った参加者の評価は、使いものにならないからです。
• 匿名と秘密保持は、異なる約束です。 どちらを約束するのか、調査票自体に明記してください。

自由記述について：

• 自由記述には人名が含まれます。 生の回答を誰が読むのか、氏名を挙げられた本人に何を伝えるのか、チーム外に決して出さない情報は何かを決めてください。event-speaker-experience が登壇者への情報共有ルールを定めます。行動規範に関する申し立ては、直ちに event-code-of-conduct の対応フローに移し、調査結果として扱ってはなりません。
• 公開への同意は、回答を集める際に得るか、まったく求めないかのどちらかです。 回答者が匿名になった後では、逐語引用について事後に同意を得られません。そのため、以下の公開段階は選択肢から外れます。
• 読む量が手に負えなくなったら、自由記述を構造化された選択肢に置き換えてください。 公開されている先行事例の1つでは、回答が2,867件に達した後にこれを行い、そのことも公表しています。

回答者とのフィードバックのループを閉じる

次回開催時の回答率と、それを生み出す信頼を、下書き作成と情報公開にかかる単位コストごとに順位付けしたメニューです。この仕組みは文書化されています。回答率を80％台、90％台に維持している実務者は、フィードバックには常に対応してきたことがその理由だと説明しています。参加者は、回答する価値があると信じているのです。

• 労力（下書き作成、レビュー、承認）：公開調査結果の投稿 > 「ご意見を受けて変更しました」ノート > 受領確認 > 何も返さない
• 価値（回答によって何かが変わるという信頼。これが次回開催時の回答率を左右します）：「ご意見を受けて変更しました」ノート > 公開調査結果の投稿 > 受領確認 > 何も返さない
• 効率性：「ご意見を受けて変更しました」ノート > 受領確認 > 公開調査結果の投稿 > 何も返さない
• コンプライアンスコスト（レビューが発生し、取り消し可能性が失われるコスト）：公開調査結果の投稿 > 「ご意見を受けて変更しました」ノート > 受領確認。何も公開しなければ、コストはかかりません。

価値と労力では、最上位の選択肢が異なります。公開調査結果の投稿ははるかに多くの人に届きますが、その大半はアンケートに回答していません。効果を生むのは、自分の回答によって何かが変わったと回答者が実感することです。そのため、「ご意見を受けて変更しました」ノートは、より低い労力でより高い価値をもたらし、両方の軸で投稿を上回ります。効率性でも、同様に上位に位置します。

何も返さない選択肢はコストがかからないにもかかわらず、効率性では最下位です。労力がゼロでも、見返りがゼロなら比率で勝つことはありません。

• 何も返さない - 調査結果はチームに共有されますが、回答者にはその後何も伝えません。
• 受領確認 - お礼と概要の数値を伝え、回答を読んだことを確認する短いメッセージです。
• 「ご意見を受けて変更しました」ノート - 受領確認に、対応中の調査結果を2～3件と、どのように変更するかを加えたものです。調査結果はステップ9の時点ですでにあるため、追加コストは数行分です。
• 公開調査結果の投稿 - 数値や傾向を公開します。できれば、アンケートの設計自体の問題点についても記載します。

デフォルト：「ご意見を受けて変更しました」ノート。 Q7の回答から、イベントが今後さらに複数回開催され、振り返りもすでに予定されていると分かった場合は、公開に切り替えます。公開と行動規範の承認はevent-debriefが担当します。あなたが提供するのはアンケート部分だけです。

優先度の低い選択肢：公開調査結果の投稿 - 労力とコンプライアンスコストでは最下位、価値では2位、効率性では3位です。アンケートに回答しない関係者に何らかの実績を示す必要がある場合に、優先度を上げます。

非公開またはNDAの対象となるイベント、あるいは収集時に公開の同意を求めていない場合は、公開調査結果の投稿を削除してください。その内容を公開する権利はありません。

定期ミートアップ：自動パルス調査、参加者のレベル分け、成果

これは現場の証言であり、確立された実践ではありません。

• 各イベントの終了後に、パルス調査を自動送信します。 自動化によって、同じ調査手段を同じタイミングで送れるため、各ミートアップの数値を比較できます。主催者が送信を覚えておく必要もありません。チームが満足度を2～3個のKPIの1つとして維持した場合に限り、結果を samber/dev-event-organizer-skills@event-continuous-improvement のKPI候補リストに反映します。
• 参加者のレベルが混在している場合は、レベルに関する質問を1つ追加します。 レベルが混在する会場では、同じセッションについて「専門的すぎる」と「専門性が足りない」という矛盾したフィードバックが返ってきます。「あなたにとって、これは：易しすぎる／ちょうどよい／難しすぎる」という選択式の質問と、回答者自身のレベルを尋ね、その2つを照合します。回答者のレベルと連動する差があれば、それは samber/dev-event-organizer-skills@event-positioning に関するオーディエンスのレベルの知見であり、登壇者の質に対する評価ではありません。
• 成果については、パルス調査ではなくフォローアップで尋ねます。 プロジェクトの開始、コラボレーション、会社の設立、就職などの成果が現れるのは、数週間から数か月後です。ハッカソンの1回の開催から、少なくとも1社が生まれることもあります。ハッカソンのフォローアップ（ステップ7）や、「その後どうなったか教えてください」という継続的な質問で尋ね、回答を samber/dev-event-organizer-skills@event-continuous-improvement の成果ログに引き継ぎます。
• アンケートは、影響を測る方法の1つにすぎません。 チーム向けアンケートと参加者向けアンケートのどちらで影響を判断すべきかについて、主催者の意見は一致しませんでした。アンケートの読み取り結果は、あくまで1つの入力情報として引き継ぎ、影響の最終判定として提示しないでください。

インタビューの回答に基づく再順位付け

各メニューについて、どの回答によってどの選択肢が動いたかを明示し、黙って順番を入れ替えないでください。3つすべてのメニューについて、Q1～Q8の回答との詳しい対応を確認するには、references/interview-answer-reranking.md を参照してください。

見落としやすい変更が2つあります。

• 数日以内に決断が必要な場合（Q3）は、Q1独自の条件に当てはまらなくても、会場内での記録が優先されます。
• すでに振り返り記事の公開が予定されている、継続的な効果のあるイベント（Q7）では、公開用の調査結果記事が優先されます。これが唯一の条件です。

失敗パターン

• 質問集から作り始める。 もっともらしい質問を10個用意すると、誰も活用を担わない回答が10個集まり、回答率が半減します。まず、意思決定から始めてください。
• 仮定の質問をする。 「ワークショップの日に参加したいですか？」では想像を集め、「どのセッションに参加しましたか？」では実際の行動を集められます。質問の表現は活かしつつ、購入の意思を引き出すために加えられた要素は取り除いてください。
• すべてを1つのスコアに平均する。 満足度、再参加意向、運営は、それぞれ異なる問いに答えるものです。混ぜ合わせると、誰も説明できない数値になります。
• 12件の回答を最終評価として読む。 回答率が低い場合、通常は参加者が無関心だったのではなく、回収方法に問題があったことを意味します。
• 1週間後にメールを送る。 24～48時間以内に送るという点では意見が一致しています。時間が経つほど、回答率は下がります。
• 匿名性を約束して、懸賞抽選を実施する。 抽選には本人確認が必要です。調査を始める前にどちらかを選んでください。
• 自由記述の苦情を、名前が挙がった本人にそのまま渡す。 登壇者に何を伝えるかは event-speaker-experience が担い、申し立ては行動規範の対応フローが担います。どちらも、直感だけで転送すべき調査結果ではありません。
• 情報を集めても、報告を返さない。 影響が積み重なる失敗です。何も知らされなかった回答者は、翌年は回答しません。
• レベルの差を平均する。 「専門的すぎる」と「専門性が足りない」を平均すると「ちょうどよい」になり、参加者のレベルが定まっていないことが見えなくなります。報告する前に、レベルに関する回答と回答者自身のレベルを照合してください。
• ミートアップのパルス調査を手作業で送る。 誰かが覚えていなければならない調査は、送信が遅れたり、送られなかったりします。その結果、シリーズ内での比較可能性が失われます。送信を自動化してください。
• ハッカソンをカンファレンスと同じ方法で調査する。 チーム編成、メンター、審査の公平性、ツールがハッカソン形式の本質です。カンファレンス向けの基本的な質問だけでは、ケータリングしか測れません。

測定

回答率の数値は、イベント調査とベンダーのエコシステムから得られたもので、情報源は多様で大半が非公開です。基準値を設定するには十分信頼できますが、標準として扱うには不確かです：references/response-rate-evidence-and-timing.md。

2つの合格基準を設け、両方を満たすまで繰り返します。

• 担当者が決まっていない質問がゼロであること（実施前に確認するゲート）—すべての質問が、Q3で明示された意思決定と担当者に対応している必要があります。これは、このスキル独自の基準であり、判断によって設定したもので、測定されたことはありません。質問を一つずつ読み直し、担当者を割り当てるか、質問を削除してください。
• 回答率が公表済みの範囲の下限以上であること（実施後に確認するゲート）—メールではおよそ10人に1人、会場内ではおよそ10人に4人です。下限は公表済みの範囲の最低値を基準としているため、測定された基準値ではありますが、測定された合格基準ではありません。これを下回った場合は、調査の失敗とみなし、リマインダーを送る、調査票を短くする、チャネルを変更するといった対応を取ってください。参加者が無関心だったと解釈してはいけません。

目標ではなく、記録するシグナル：

• 役割ごとの回答率—全体でまとめた数値では、スポンサー6人のうち2人しか回答していないことが見えなくなります。
• 再参加意向—およそ3分の2を下回った場合は早期警告とし、傾向をevent-continuous-improvementに引き継いでください。
• 回答完了率と開始率—途中で回答をやめた箇所から、長すぎる、または曖昧だった質問がわかります。
• 回答者が返答を受け取ったかどうか、またその速さ—次回開催時の回答率を予測するうえで、最も有力な要因です。
• レベル分割の割合（レベルが混在する会場のみ、自己申告）—異なるレベルの回答者が同じセッションを「基礎的すぎる」と「高度すぎる」の両方で評価した割合です。傾向をevent-positioningに引き継いでください。

使用例

• 「会議が昨日終わりました。参加者アンケートには何を入れて、いつ送ればよいですか？」
• 「ハッカソンを開催しましたが、いつもの会議アンケートは合わないようです。代わりに何を聞けばよいですか？」
• 「参加者400人にメールを送りましたが、回答は18件でした。何が問題だったのでしょうか。まだ改善できますか？」
• 「講演者向けアンケートは参加者向けと別にすべきですか。それとも質問を増やすだけでよいですか？」
• 「自由記述の回答の一つに、特定の講演者への苦情が書かれていました。どう対応すればよいですか？」
• 「アンケート結果は公表すべきですか。結果が芳しくなかった場合はどうなりますか？」

期待される出力：

• 選択した深度に応じた規模の調査票。すべての質問が明示された意思決定に結び付いています。
• リマインダーの間隔を含む、チャネルと送信スケジュール。
• 匿名性に関する方針と自由記述の取り扱いルール。
• 回答率を併記し、件数を含めてテーマ別にまとめた調査結果。
• 回答者に何を返すかについての決定。
• デブリーフィング、需要、講演者、スポンサー関連の兄弟スキルへの引き継ぎ。すべての主張には、公表済みのエビデンスか、このスキル独自の判断かを明記します。

参考資料

• references/question-sets-by-format-and-role.md - 形式ごとの基本的な質問セット。ハッカソン向けの質問群、参加者・講演者・スポンサー向けのモジュールと募集状況に基づく条件分岐、選択式と自由回答のバランスに関するルール、匿名性のガイダンス、良い質問と悪い質問の例を含みます。
• references/response-rate-evidence-and-timing.md - 回答率と満足度に関するすべての数値と、その出典、サンプル数、信頼性の分類。送信時期に関する見解の一致点と、それが実証されていない理由、リマインダーの間隔、謝礼に関するエビデンスも含みます。
• references/publishing-and-findings-handoff.md - 公表されたレポートの先行事例とそのサンプル数、調査結果の要約形式、各受け取り先の兄弟スキルに引き継ぐ内容をまとめています。

全体を通じて言及されるその他の兄弟スキル：event-debrief、event-market-fit、event-speaker-experience、event-sponsor-fulfillment、event-code-of-conduct（上記の本文を参照）。また、会場内での記録を可能にする当日運営と、そのための一文を担当する samber/dev-event-organizer-skills@event-run-of-showも含まれます。