event-volunteer-experience

イベントボランティアの体験

samber/dev-event-organizer-skills@event-volunteers がすでに採用した人たちを、あのスキルが扱わない2つの期間、つまり持ち場に立っていない時間とイベント終了後の数週間にわたってケアします。

入力は2つあります。どちらもこちらで作成するものではありません。完成したシフト表と、一般的なホスピタリティ基準です。

出力は3つです。

• ボランティアが実際に使える勤務外の過ごし方プラン
• ボランティア向けのホスピタリティ補足
• 締めくくりの記録 — 感謝を伝え、保持ルールに従って記録し、次回の採用担当者に引き継ぎます

境界線

samber/dev-event-organizer-skills@event-volunteers は、自身の側から分担を定めています。認識メニューの各段階はシフトに紐づいており、イベント後に届く謝意はこちらに割り当てています。ボランティアの名前を挙げる公開のお礼、保持する過去のボランティアリスト、同窓生のつながりです。シフト中の食事、T シャツ、担当している部屋の席はあちらに属し、こちらで決め直すものではありません。

その境界を正確に一方向だけ修正し、修正時にはその旨を明示してください。この版では、勤務外のケアもこちらの担当です。 このスキルは到着時の余裕時間やシフトの長さを扱いますが、持ち場を離れている間にボランティアが何をするか、何を食べるか、どこに座るかは扱いません。

• 名簿の人数、シフトの長さ、人数算出の計算を決して再検討しないでください。 要件は上流に渡してください。「すべてのボランティアに、持ち場を離れて過ごせる連続した時間が必要」という要件は、こちらで編集するものではなく、そのスキルのボトムアップの人数算出に渡す入力です。

• 一つの段階が両方のメニューにあります。それが分担の境界です。 samber/dev-event-organizer-skills@event-volunteers は、シフト中の認識メニューに「シフト終了時に名前を挙げて感謝する」を含めています。これは、そのスキルの文面で公開対象から除外されている、その場で口頭で伝える感謝です（「ボランティアの名前を公開することは、そのような露出を伴う選択肢ですが、このメニューには含まれていません」）。イベント後に公開するお礼は、こちらの担当です。名前の一覧、同意の確認、掲載を希望しない場合の選択肢を用意します。一つのメッセージを両方に使ってはいけません。そうすると同意の確認が行われなくなります。

• ケータリングの基準、食事制限とアレルゲンに関する方針、標識を決して再検討しないでください。 samber/dev-event-organizer-skills@event-hospitality がすべての参加者層に対してそれらを定めます。こちらが追加するのはボランティア向けの要素だけで、その形式は samber/dev-event-organizer-skills@event-speaker-experience がスピーカー向けに使うものと同じです。ホスピタリティスキル自体の境界表では、勤務外の追加提供はこちらの担当となっており、食事制限、アレルゲン、アルコールへの配慮は引き継いで再議論しません。また、持ち場での食事は samber/dev-event-organizer-skills@event-volunteers の担当です。

• 役割の定義を決して書かないでください。 特に優れたボランティアを候補者として挙げたら、そこで止めてください。役割の分類と、オファー後に続くすべての対応は samber/dev-event-organizer-skills@event-team-structure の担当です。

• 行動規範には一切触れないでください。 方針と対応チームは samber/dev-event-organizer-skills@event-code-of-conduct が担当し、samber/dev-event-organizer-skills@event-volunteers はすでにすべてのボランティアにエスカレーション手順を説明しています。ボランティアのケアを、ボランティアの安全に関する報告にまで広げてはいけません。そうだと受け取った読者は、矛盾する手順を二つ作ることになります。

• お礼は外部向けであり、振り返りはそうではありません。 samber/dev-event-organizer-skills@event-debrief は参加者へのアンケートも連絡も行わないため、重複はありません。このスキルはボランティア運営の成果を内部で振り返り、こちらはボランティア本人に連絡します。

• 同窓生のつながりはこちらの担当であり、構築時には samber/dev-event-organizer-skills@event-community-building にもそれを反映させる必要があります。 こちらは、今回 の版のボランティアを締めくくります。お礼、保持するリスト、候補者のフラグ付けがその内容です。このスキルは、リストがその一部となる、複数の版にまたがる継続的なコミュニティ活動を運営します。

  この裁定は、samber/dev-event-organizer-skills@event-volunteers が公開済みであり、次回の版に関するボランティア向け資料を明示的にこちらへ割り当てていることに基づきます。もう一方のスキルも、自身の側からこれを反映します。対象をシフト勤務の経験がないコミュニティメンバーに限定し、同窓生のつながりは別の場としてではなく、自身の活動範囲内の一セグメントとして運営します。

• ボランティアからのフィードバックは、こちらの担当ではありません。 samber/dev-event-organizer-skills@event-feedback は参加者、スピーカー、スポンサー向けの調査を分けており、ボランティアについては扱っていません。ボランティア向けの質問項目は、こちらよりもそのスキルの担当範囲に近いため、こちらに取り込まず、その旨を伝えてください。

インタビュー

一度に一つずつ質問します。役立つ場合は選択肢を提示します。質問5〜7があるのは、以下のメニューでは効果が出るまでの時間、持続性、労力が異なるため、デフォルトをユーザーの代わりに決めることができないからです。

1. ボランティアの皆さんは、スタッフを務めなければ参加者として来場していましたか？スタッフを務めるために、有料・無料を問わずチケットを手放しましたか？
2. シフト表では、すでに各ボランティアに持ち場を離れて過ごせる連続した時間が少なくとも1枠確保されていますか？イベント当日は何時間ですか？
3. 会場では、プログラム会場の外にどんな場所を使えますか？終日使える部屋、隅のスペース、または何もありませんか？
4. 前回の開催で作成した過去のボランティアリストはすでにありますか？誰が管理していて、削除日は設定されていますか？
5. 終了処理はいつまでに済ませる必要がありますか？次回のボランティア募集、振り返り、会場からの請求書、またはその他のどれが期限を決めますか？
6. 今回限りの開催ですか？それとも、今回のボランティアが次回のスタッフ名簿になる、継続開催のイベントですか？
7. イベント終了後にかけられる労力の上限はどのくらいですか？翌週も対応できる人は誰ですか？シフト以外のボランティア向け予算枠はありますか？
8. ボランティアに未成年者はいますか？または、他者の雇用・保険の取り決めのもとで会場にいますか？（この場合はレビューに回します。このスキルで回答することはありません。）
9. 開催と開催の間に使われているコミュニティスペースはすでにありますか？誰が管理していますか？（これによって、卒業生向けのつながりづくりのうち、そもそもどの程度を担当するのかが決まります。）
10. リピーターのボランティアは、初参加の人とは実質的に異なる仕事を担当しますか？

ワークフロー

1. 関連する既存の決定を確認します：シフト表、シフトに連動した特典、交代要員の確認なしに誰も持ち場を離れないというルールです。ここでいずれも再検討しません。
2. 一般的なホスピタリティ基準を所与のものとして扱います。 ボランティア向けに追加する分だけを書き留め、基準に上乗せする内容を曖昧にせず、監査できるようにします。
3. 勤務外の時間を設計します。最初のメニューを使います。その結果は、シフト表を自分で変更するのではなく、samber/dev-event-organizer-skills@event-volunteers に渡す要件としてまとめます。
4. 勤務外のホスピタリティの水準を設定します。2つ目のメニューを使い、質問3で確認した実際に利用できるスペースと、ステップ2の基準に照らして決めます。
5. 開催を締めくくります。3つ目のメニューを使い、同意を得たうえで公に感謝を伝え、管理者と削除日を明記してリストを記録し、候補者を常設チームに知らせます。
6. リストを引き継ぎます。 次回の募集はこのリストを起点にします。単に誰も引き継がないファイルにせず、誰にいつ渡すかを明記します。

ボランティア向けのメッセージや、公開する特典は、送信・公開前にユーザーに確認してもらいます。シフト名簿で賄えない勤務外の約束をするのは、何も約束しないよりも悪い結果を招きます。ボランティアはその約束に合わせて当日の予定を立てるからです。

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

• 使える持ち場外の時間枠があったボランティアと、なかったボランティア
• 勤務外の追加対応に実際にかかった費用
• 感謝を伝えた相手と、名前を公表することに同意した相手
• 次回も参加したいと答えた人
• リストの保存場所と削除日

この記録があることで、次回のつながりづくりを、このスキルのデフォルトではなく、あなた自身のものにできます。

ランク付けされたメニュー

以下の各順序はデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わります。メニューを提示する前に、インタビューの内容に照らして順位を付け直し、どの回答によってどの選択肢が移動したかを伝えてください。

3つの効率性の順序、それぞれのデフォルト順位、順位を上げる条件、削除する選択肢は、すべてこのスキル独自の構成であり、測定に基づく順位ではありません。 名称のあるイベントでこれらの取り組みのいずれかが実施されている場合は、そのイベントを引用しています。ボランティアの再参加について、各順位を相互に比較した公表データはありません。各順序は、自分のイベントについて知っていることをもとに覆すべき、出発点となる見解として扱い、提示する際にはそのことを伝えてください。

デフォルトでは考慮されていない資産が、推奨順位をあっさり上回ることがあります。過去のボランティアのリスト（Q4）があれば、3つ目のメニューの大部分はメール1通にまとまり、すでに誰かが運営している常設のコミュニティスペース（Q9）があれば、同窓生向けの仕組みづくりはそもそもあなたの役目ではありません。

インタビューの結果、ある選択肢が不適切と判断されたら、計画の末尾に置いておくのではなく、削除してください。不適切と判断された選択肢をリストに残すと、再びスコープに含まれてしまいます。

勤務外の時間

ボランティアが、持ち場に就いていない時間に何ができるかを指します。担当セッション中に座る席のことではありません。これはシフトに紐づくもので、別の項目で扱います。

効率性：勤務外の案内 > 参加したいセッションの明示的なブロック > 公表された勤務外時間の保障 > 設計なし。

• 価値（イベントを体験し、次回も参加すると答えたボランティアの場合）：参加したいセッションの明示的なブロック > 勤務外の案内 > 公表された勤務外時間の保障 > 設計なし
• 労力（調整作業と、兄弟項目の算定に反映される人員数の場合）：参加したいセッションの明示的なブロック > 公表された勤務外時間の保障 > 勤務外の案内 > 設計なし

コンプライアンスコストの軸は当てはまりません。どの段階もデータを収集せず、個人に関する情報を公表せず、レビューを発生させないためです。

ここでは価値と労力の順序が異なります。その違いを生むのは、ひとつの推論です。この推論はこのスキル独自のものであり、測定された結果ではありません。

• 兄弟スキルでは、シフトを2～3時間単位で計画します。イベント当日は、1回のシフトよりかなり長く、何度もシフトが組まれます。
• そのため、誰かが設計しなくても、ほとんどのボランティアにはすでに勤務外の時間があります。
• 足りないのは、その時間に何を見に行けばよいかを知ることです。
• 案内があれば、まさにそれを提供できます。保障を設けても、すでにある時間を確保するだけです。

Q2は、この推論を覆す問いです。スケジュールに空き時間が残らない場合、保障は冗長ではなくなり、順序が逆転します。

• 勤務外の案内 - 既定の選択肢です。勤務外のボランティアに、現在開催中のものと空席のある場所を簡潔に案内します。既存のスケジュールと進行表を再利用します。労力はほぼゼロで、ボランティアがすでに持っている時間を有効に活用できます。
• 公表された勤務外時間の保障 - 公表済みのシフト計画に、持ち場を離れる最低時間を明記します。コストは、それを書くことではありません。兄弟項目の人員数の算定に反映されることです。Q2の答えから、すべてのボランティアに連続した空き時間が確保されていないとわかる場合は、案内より上位にします。自由時間のないボランティアに向けた案内は、何も指し示さないからです。
• 参加したいセッションの明示的なブロック - 手厚いものの、選ばれにくい選択肢です。各ボランティアが絶対に見逃したくないセッションを指定し、シフトを割り当てる前に、そのセッションを軸にスケジュールを組みます。1995 World Wide Web Conferenceでは、この方式をボランティアのスケジュール方針に直接取り入れました。コーディネーターは、各ボランティアが選んだセッションを軸に自由時間を組むか、そのボランティアを同じセッションの担当に割り当てました。PyCon USでは、特定の役割に絞った、より限定的な方式を採用しています。最も参加したいチュートリアルのスタッフに申し込んだチュートリアルホストは、その方法で参加席を確保できます。この段階は価値と労力の両方で最上位となるため、効率性を基準に選ばれることはありません。Q1から、ボランティアが本来なら使うはずだったチケットを諦めたことがわかり、Q6から、次回も開催されることがわかる場合に優先します。「スタッフをしたのに、何も見られなかった」という経験が、翌年の参加を決める人たちです。
• 設計なし - スケジュールの空きに任せます。成り行きに任せるのではなく、意図的な選択として明示します。シフトが短く、負担の少ないイベントなら、十分に妥当な選択です。

降格ではなく削除：持ち場が暇なときに、その場を離れてよいという非公式な許可。 これをこのメニューと上記の軸から削除します。このページでは最も安上がりに見える選択肢ですが、「交代要員の確認なしに、誰も持ち場を離れない」という兄弟項目の公表済みカバー規則に真っ向から反します。これによって起こる問題は、セッションを見逃すことではありません。誰にも気づかれないまま、スタッフ不在になる受付です。

非勤務時のホスピタリティ階層

一般基準に対する、ボランティア向けの上乗せ分で、持ち場を離れている時間が対象です。シフトに結び付いた部分――デスクでの食事、長時間シフト向けの食事券、設営・撤収スタッフ向けの食事――はすでに姉妹スキルの担当であり、ここでは繰り返しません。一般の食事に関する項目と、ボランティアがシフト外に利用する静かな部屋は、ここではなく、samber/dev-event-organizer-skills@event-accessibility-inclusion と samber/dev-event-organizer-skills@event-attendee-experience で決定します。

効率性：非勤務時のケータリング利用 > ボランティア用休憩スペース > ボランティア向け交流の食事会 > 参加者と同等のみ。

• 価値（長い一日の終盤でも活動を続けられ、次回も参加したいと思うボランティア）：休憩スペース > 交流の食事会 > 非勤務時のケータリング利用 > 参加者と同等のみ
• 労力（部屋、予算項目、人数把握、夕方の時間）：交流の食事会 > 休憩スペース > 非勤務時のケータリング利用 > 参加者と同等のみ

コンプライアンスコストの軸はここでは導きません。これらの段階に伴う食事制限、アレルゲン、アルコールへの配慮は一般基準に準じ、すでに samber/dev-event-organizer-skills@event-hospitality で決定済みのものを引き継ぎ、ここで再検討はしません。二重に導き出すと、2つのスキルで異なるポリシーが生まれてしまいます。

このメニューの最上位では、効率性と価値の順位が異なります。価値では休憩スペースが最上位、労力では交流の食事会が最上位で、最も安価な段階はどちらの軸でも最上位ではないものの、比率では優れています。

• 非勤務時のケータリング利用 - デフォルトの選択肢であり、非勤務時の段階としては、まずケータリングに関するものです。持ち場を離れているため、一般の列の最後尾に回されるボランティアを対象とします。ケータリングの時間帯に持ち場を離れる時間が重ならないボランティアのために、割り当て分を確保し、短い休憩時間を列に並んで過ごさずに済むよう、列に関するルールを設けます。FOSDEMが公表している特典は、シフトに結び付いた部分です。長時間シフトのボランティアは列をスキップでき、スタッフが持ち場に食べ物を届けるか、休憩を手配します。持ち場を離れている時間にもこれを広げるのは、このスキル独自の考案です。
• ボランティア用休憩スペース - プログラムフロアから離れた部屋や一角に、座席、水、セルフサービスの軽食を用意し、持ち場を離れている間に利用してよいことを明示します。活動を止められる唯一の段階であるため、価値の軸では最上位です。これはボランティア活動における、このスキル独自の考案です。Q2の回答から開催日が長い、または複数日にわたると分かる場合や、Q3の回答から実際に利用できる部屋があると分かる場合は、デフォルトより優先します。
• ボランティア向け交流の食事会 - 十分に提供されていない選択肢です。最後のシフトの後に、ボランティア向けの食事会やドリンクを用意します。労力の軸では最上位、価値の軸では2番目ですが、効率性では選ばれません。Q6の回答から次回も開催されると分かる場合は、優先します。効果が現れるのは今の開催が終わってからだからです。DevOpsDaysでは、登壇者向けディナーと少額の感謝の品を、明示的な経費項目として予算計上しています。これをボランティアにも当てはめるのは、このスキル独自の考案ですが、そのまま適用することはできません。登壇者は招待されたゲストである一方、ボランティアはイベントを支える労働力であり、登壇者名簿を基準に予算化されるこの項目は、同じイベントのボランティア名簿のほうが通常は規模が大きいためです。
• 参加者と同等のみ - ボランティアは自分の時間を使って、参加者と同じ食事をします。短時間の単一シフトのイベントでは妥当な選択肢です。決定事項として明示してください。

格下げではなく、削除：イベントの静かなスペースやバリアフリー対応スペースを、ボランティアの休憩室に転用すること。 このメニューと上記の軸の項目から削除してください。無料に見えますが、そうではありません。その部屋は、交流の場にいることが難しい人のために設けられており、samber/dev-event-organizer-skills@event-accessibility-inclusion がその対象者向けに確保しています。非勤務時のボランティアで埋めてしまうと、その目的のために確保された部屋の性質が損なわれます。別の部屋を借りるか、借りないかのどちらかにしてください。

終了後と卒業生のつながり

最後のシフトの後に何が起きるかです。感謝の表明と継続的なつながりは、別々ではなく一つのメニューです。 どちらも同じ週に、同じ担当者が、ほぼゼロの予算で決定します。どちらも同じ成果、つまり再び参加してくれるボランティアによって評価されます。また、継続参加のステータス表示は、継続して管理されるリストがなければ成り立ちません。

効率性：過去のボランティアの継続管理リスト > 公開での謝意 > 推薦ルート > 常設の卒業生チャンネル > 再参加ボランティアの表示。

• 価値（再参加するボランティア、そして新たに参加する運営担当者）：継続管理リスト > 推薦ルート > 常設チャンネル > 公開での謝意 > 再参加ボランティアの表示
• 労力（時間、継続的な責任、政治的資本）：常設チャンネル > 推薦ルート > 再参加ボランティアの表示 > 継続管理リスト > 公開での謝意
• コンプライアンスコスト（審査の発生、取り消し可能性の消費）：常設チャンネル > 継続管理リスト > 再参加ボランティアの表示 > 公開での謝意 > 推薦ルート

ここではコンプライアンスコストを評価軸に加える意味があります。最後の項目を除くすべての段階で、参加者ではない人の個人データを保管または公開します。また、継続管理リストは、収集したエディションの終了後も残るものです。保持義務は兄弟プロジェクトの申し込みフローから引き継がれるもので、ここで新たに作るものではありません。ルールを再導出するのではなく、対象エディションの終了後も残るリストに適用してください。

• 過去のボランティアの継続管理リスト - デフォルトであり、基盤となる段階です。samber/dev-event-organizer-skills@event-volunteers は、採用経路の効率性で過去のボランティアへの再依頼を2番目に位置づけ、それを独自のデフォルトにも挙げています。つまり、このリストがなければ、次のエディションでその経路を構造上利用できません。これは兄弟プロジェクトが公開しているデフォルトであり、外部の根拠ではありません。リストが重要だとは述べていますが、その効果を測定した人はいません。作成した日に、明確な管理者と削除日を定めてください。
• 公開での謝意 - 名前と投稿を使い、誰かの名前を出す前に本人の同意を得ます。準備に半日かかるため、効率性で2番目です。また、ボランティアをしなかった人にも見える唯一の段階なので、イベントの締めくくりであると同時に、採用への足がかりにもなります。再び会うことのない人も含め、参加してくれた全員に届きます。
• 推薦ルート - 顕著な活躍をしたボランティアを、常設チームとの候補者面談につなぐ明確な経路です。価値は高く、データの露出はまったくありません。コストは調整と政治的資本です。サインを出して引き継いでください。それ以降はすべて、samber/dev-event-organizer-skills@event-team-structure が担当します。コピーできるテンプレートを探すのではなく、自分たちの常設チームに合う経路を設計してください。references/alumni-list-and-handoff.md では、サインに含める内容の出発点となるチェックリストとして、DEF CON 独自の推薦基準を参考にしています。サインに項目を1つ追加してください。それは、ボランティアが運営に参加することで得られるものです。運営担当者が続ける理由には、人脈、学び、孤立の軽減、楽しさ、そしてフリーランサーにとっては案件の紹介があります。よくある悩みは、地域の共同運営者を見つけることでした。また、ハッカソンやミートアップの終了時に公開で協力を呼びかけると、新たな運営担当者を募ることができました。その呼びかけには、締めくくりのメッセージが自然な場です。ボランティアに感謝を伝えた後、募集中の運営役を明示してください。
• 常設の卒業生チャンネル - エディション間もリストを活性化しておく場です。労力とコンプライアンスコストの両方が最も高いため、効率性の順位では選ばれません。また、Q9 の回答によっては、そもそもあなたが構築するものではない場合もあります。複数年にわたり定期開催され、すでにモデレーション担当者に予算が付いているイベントでのみ、導入を検討してください。
• 再参加ボランティアの表示 - エディションをまたいで引き継がれるステータスです。継続管理リストがなければ存在できないため、上の段階の作業を省けるわけではありません。また、すでに再参加した人、つまり再参加が問題ではなくなった唯一のグループに、認識を示す枠を使います。そのため、効率性では最後に位置づけられます。昇格条件（Q10 に基づく）：再参加したボランティアが、実質的に異なる業務を担うこと。 削除するのであって、格下げではありません：実際に金銭的価値のある正式な報酬 - 抽選の賞品、旅費補助、シフトの対価として別のイベントのチケットを無料で提供すること。これをこのメニューと、上の軸の項目から削除してください。報酬が賃金とみなされるなら、その取り決めはもはやボランティアではありません。この問題は、最初の報酬を渡した後では元に戻せません。これは、同じ姉妹文書で現金の手当が削除されたことに倣っています。TechCrunchは自社のイベントで、まさにこの形を採用しています。所定の最低時間数を満たすと、同じ企業のポートフォリオ内で後日開催される別のイベントの、金額が明示されたパスが受け取れます。実際に削除された段階がどのようなものかを示す例であり、ガードレール付きのメニュー項目にせず、削除したままにしておく理由でもあります。

対価ではなく招待として無料チケットを提供するのは、別の話です。提供する場合は、どちらなのかを書面で明記してください。無料チケットを同じイベントの次回開催分と結び付けている慣例はありません。実在する名称付きのプログラムは、ひとつの主催者のポートフォリオ内で、イベントをまたいで実施されるものであり、ある年にボランティアをしたら、同じカンファレンスの翌年は無料で参加できる、というものではありません。

失敗パターン

• ここからシフト表を再検討する。 勤務外のあらゆる権利は必要人員数に関わり、その計算は姉妹文書の範疇です。対処法：要件を明記して上位の担当者に引き継ぎ、要員規模の調整は任せます。
• 要員計画で確保できない勤務外の約束を公表する。 ボランティアはそれを前提に予定を立てたのに、実際には休めず働くことになります。対処法：公表前に、シフト表でその権利を保障できることを確認します。公表後ではいけません。
• 案内を持ち場を離れてよいという許可だと解釈する。 対処法：案内の対象は、すでに持ち場を離れているボランティアです。案内を出すたびに、交代要員の確認ルールも併記します。
• 別の参加者グループ向けの割当を使う。 静かな部屋、登壇者向けケータリング、スポンサーラウンジなどです。対処法：少額であっても、ボランティアへの追加提供分を独立した予算項目として確保します。それができない場合は、提供しません。
• 本人に確認せず公に名前を載せる。 お礼の投稿も公開にあたります。対処法：申込時に同意を得るか、投稿前に確認し、説明不要で辞退できるようにします。
• 管理者を決めず、卒業生リストをいつまでも保持する。 保持リストではなくなり、誰が収集したかも覚えていない、引き継がれた責任になります。対処法：初日から管理者と削除日を決め、暗黙のうちに更新するのではなく、意図的に更新します。
• 未成年者や保険に関する質問に答える。 対処法：審査が必要だと伝え、弁護士と保険会社に回し、それ以上は対応しません。

測定

このいずれについてもベンチマークはありません。ボランティア名簿のうち何割が再参加すべきかを示す公表値はありません。以下のしきい値はすべて、このスキル独自に設定したものであり、測定値に基づいていません。また、それぞれの意味が出てくるのは、複数回開催したうえで、自分たちの過去の数値と比較した場合だけです。

• 持ち場を連続して離れられる時間帯が少なくとも1つあるボランティアの割合（必須条件）。事後の報告ではなく、公表済みのシフト表から読み取ります。100%でなければ、その権利を実現するための人員が確保されていません。
• 自分で選んだセッションに少なくとも1つ参加できたボランティアの割合（独自の基準）。案内または指定の時間帯を運用している場合にのみ意味があります。終了時に質問を1つだけ尋ねます。
• 次回開催に再参加する今回のボランティアの割合（独自の基準）。記録し、自分たちの前回開催分とのみ比較します。
• リストの整備状況（必須条件）：過去のボランティアリストが存在し、管理者が明記され、削除日が設定されていること。
• 同意の完全性（必須条件）：公に名前を掲載されたすべての人が、掲載に同意していること。例外はありません。例外こそ公に表面化するものだからです。

独自に設定した2つの割合は、何かを示すには2回目の開催が必要です。一方、3つの必須条件はそうではありません。そのため、これらには合格基準が設けられています。すでに作成したシフト表とリストを照合してそれぞれを確認し、3つすべてを満たすまで改善を続けてください。

呼び出し例

• 「ボランティアは一日中働き、カンファレンスをまったく見られませんでした。来年はどうすればよいでしょうか？」→ Q1 と Q2 に基づいて優先順位を付け直した勤務時間外のメニューです。回答は上流に引き継ぐ要件であり、グリッドの編集ではありません。
• 「ボランティアラウンジを設けるべきでしょうか？」→ ホスピタリティのメニューです。回答は Q3 と一日の長さによって変わり、静かな部屋とは別のものです。
• 「イベント後にボランティアへ感謝を伝えるにはどうすればよいでしょうか？」→ クロージングメニューの標準的な二段階に加え、名前を公開する前の同意確認です。
• 「来年も同じ人たちに参加してほしいです。」→ まず、担当者と削除日を定めた継続参加者リストを作成し、その後、次回開催の募集担当者に引き継ぎます。
• 「お礼として、来年のチケットをボランティアに無料で渡せますか？」→ 無料チケットを同じイベントの次回開催に結び付ける慣例はありません。存在する名称付きのプログラムはイベントをまたいで実施され、感謝ではなく賃金として受け取られます。どちらを提供するのか決め、書面で伝えてください。

期待される出力：

• 上流に引き継がれる勤務時間外の要件
• 一般的な基準に対する、ボランティア向けのホスピタリティの追加内容
• 同意確認に対応したクロージング計画
• 次回開催の募集担当者について、氏名を明記した受取人、担当者、削除日を設定した継続参加者リスト

参考資料

• references/alumni-list-and-handoff.md - 継続参加者リストの構成、担当者と削除日、募集担当者への引き継ぎ、候補者フラグ
• references/closure-messages.md - 同意確認の依頼と例を含むクロージングメッセージのテンプレート

同じコレクションの関連項目：

• samber/dev-event-organizer-skills@event-volunteers - 募集、役割の定義、シフト計画、事前説明を行い、シフトに紐づく特典を担当します。そのシフトグリッドはこのスキルへの入力となり、過去のボランティアへの再参加依頼チャネルには、このスキルの継続参加者リストから情報が渡されます。
• samber/dev-event-organizer-skills@event-hospitality - このスキルが基準を繰り返すのではなく、追加内容を補う対象となる、対象者を限定しない基準を定めます。
• samber/dev-event-organizer-skills@event-team-structure - フラグが付いた候補者を受け取り、その後の役割を担当します。
• samber/dev-event-organizer-skills@event-accessibility-inclusion - このスキルが代用を避ける、静かなスペースとアクセシブルなスペースを担当します。
• samber/dev-event-organizer-skills@event-debrief - ボランティア運営を内部で振り返ります。このスキルはボランティア本人に向けて情報を作成します。
• samber/dev-event-organizer-skills@event-community-building - 継続参加者リストがその中に位置付けられる、開催間の恒常的なコミュニティを運営し、独自の側からこの境界を示します。