event-official-social-program

イベント公式ソーシャルプログラム

決めるのはひとつだけです。イベントが公式の交流機会をいくつ開催し、それらを互いにどう配置するかです。1回だけにするか、別枠でもう1回設けるか、複数回のテーマ別トラックにするか。それがすべてです。

samber/dev-event-organizer-skills@event-hospitality は、単独の交流機会がどのようなものかをすでに決めます。以下の項目をここで再検討することはありません。

• その形式
• 食事
• 飲み物
• アルコールに対する方針
• 対象者
• 開催場所
• 参加費
• 開始時刻と終了時刻

すでに決まっていることと、その決定者

隣接する領域はほかのスキルが担当しているため、このスキルの範囲は限定的です。優先順位を付ける前にこのセクションを読んでください。必要な答えが以下に含まれている場合、使うべきスキルはこれではありません。

• 個々の交流機会の形式は、全面的に samber/dev-event-organizer-skills@event-hospitality が決めます。
  • そのメニューは「夜のイベントやソーシャルプログラムを実施するかどうか、またどのような形式にするか」を決め、効率性に基づいて形式を順位付けします：venue-based mixer > formal dinner with a programme > no organised programme > offsite excursion or activity。
  • この順位を付け直したり、名称を変えたり、対抗する別のメニューを作ったりしてはいけません。
  • 各交流機会の形は、そのスキルの回答に従って一覧に反映してください。交流機会ごとに、そのメニューを実行します。
• 交流機会をゼロにする選択も、そのスキルの担当であり、あなたの担当ではありません。上記のメニューには「no organised programme」が含まれています。また、そのスキルは、どちらを選んだ場合でも回答を公開するようすでに指示しています。開催を告知しなければ、参加者がホストのいないバーに向かうためです。したがって、このメニューで選べる最小数は交流機会1回です。正直な答えが「まったく開催しない」なら、そのスキルがすでに答えを出しているため、こちらで付け加えることはありません。
• 交流機会ごとの概要は、そのスキルのリファレンスファイルで指定されています。
  • 担当者
  • 「対象は全参加者か、それとも一部の参加者か」
  • 「場所と、その場所がアクセスのしやすさを考慮して選ばれたかどうか」
  • 「参加者にかかる費用」
  • 「食事と飲み物」
  • 「開始時刻と終了時刻」
  • 「家族も参加できる夜のプログラム」として示されているアクセス上の配慮事項
  • 以降、交流機会ごとにこれらを記入してください。ここに挙げた項目をこのスキルで再定義することはありません。
• アルコールに対する方針は、そのスキルがイベント全体について一度だけ決定します。交流機会ごとに方針を変えることはできません。
• 第三者が運営するサテライトイベントは samber/dev-event-organizer-skills@event-side-event-coordination の担当です。同スキルは、その側から境界を明確にしています。ホスピタリティの夜のイベントは主催者が提供するもの、サテライトイベントは許可するものです。あなたの一覧には、イベント自身が運営するものを記載します。完成した一覧をそのスキルに渡し、承認の調整に使うカレンダーとして参照させてください。
• 招待制や特定のゲストを対象とするホスピタリティは samber/dev-event-organizer-skills@event-vip-social-program の担当です。すべての参加者が参加できる交流機会の一覧はあなたの担当です。同じ夜に開催されても、招待が必要なディナーは対象外です。
• 公開スケジュールは samber/dev-event-organizer-skills@event-schedule-design の担当であり、同スキル自身の言葉では「公開スケジュールの作成までが範囲」です。重複を避ける要件を同スキルに渡してください。自分で時間枠を設定したり、変更したりしてはいけません。
• どのアクセス上の配慮を設けるかは samber/dev-event-organizer-skills@event-accessibility-inclusion が決めます。対象となるのは「物理、感覚、食事、経済、デジタルアクセスに関する配慮」です。その内容を独自に作ってはいけません。公開された内容に照らして、交流機会の一覧を確認してください。

以下の順位付けはデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わります。すでに把握している情報に基づいて順位を付け直してください。以下のいずれも、デフォルトの順位を覆す要因になります。

• ソーシャルトラックが参加者にとって来場の主な理由となる開催回
• 追加の手配なしで利用できる2つ目の部屋が会場にある場合
• ひとりのチームメンバーが、いつの間にかすべてを担当している場合

インタビュー

一度に質問するのは一つだけにし、可能であれば選択式にします。質問6〜8があるのは、各段階で労力、持続性、効果が出るまでの時間に大きな差があるためです。どれを標準にするかを、こちらでユーザーに代わって決めることはできません。

1. samber/dev-event-organizer-skills@event-hospitality で、開催形式とアルコールに関する方針はすでに決まっていますか？ そうでなければ、まずそちらに進んでください。その答えが出るまでは、このスキルでは何も順位付けしません。
2. 実際に開催候補となっている、独立した公式の交流イベントはいくつありますか？ 2つ目を求めた人がいるのですか？ それとも、最初からそうだと思い込んでいたのですか？
3. アクセシビリティの基準では、どのような対応をどの程度まで確約していますか？ 確認してください。対応内容を勝手に作り上げてはいけません。
4. 複数のイベントが同じ時間帯に開催されますか？ それとも、公開済みの時間割の中で、それぞれ別の枠を設けますか？
5. 2つ目以降の各イベントに、名前の挙がっている担当者はいますか？ 全体の一覧についてではなく、イベントごとに答えてください。
6. 労力の上限はどの程度ですか？ ボランティアの作業時間、2つ目以降のイベントに割り当てる予算、2つ目の部屋や会場はありますか？ また、前回の開催で何が残りましたか？
7. 1回限りの開催ですか？ それとも、交流イベントが参加者の再来を促す理由の一つとなる、継続開催ですか？
8. 各イベントの会場を確保し、アクセシビリティに関する説明を公開しなければならない期限はいつですか？ このメニューの順位付けで基準にするのは、イベント開催日ではなく、それらの期限です。

イベントの構成

イベントが公式に開催する交流イベントの数と、それらが重複するかどうかです。以下の各段階では、各イベントの形式は samber/dev-event-organizer-skills@event-hospitality のメニューから選び、イベントごとに1回ずつ実施するものとします。

ここでの価値は対象範囲、つまり、イベントの構成の中に参加できて、参加したいと思えるものを見つける人の数です。

メニュー、その4つの評価軸、そこに付随するすべての条件は、このスキルが独自に構成したものであり、実践を測定したものではありません。順位は絶対的な規則ではなく標準的な案として扱ってください。Q2、Q5、Q7によって順位は変わります。

• 労力（担当者の指定、会場や部屋の確保、アクセス経路の確認、説明の公開）：テーマに沿った複数アクティビティのトラック > 別枠で開催する2つのイベント > 1つの交流イベント
• 価値、対象範囲：テーマに沿った複数アクティビティのトラック > 別枠で開催する2つのイベント > 1つの交流イベント
• コンプライアンスコスト（レビューの発生、可逆性の消費）：テーマに沿った複数アクティビティのトラック > 別枠で開催する2つのイベント == 1つの交流イベント
• 効率性：1つの交流イベント > 別枠で開催する2つのイベント > テーマに沿った複数アクティビティのトラック

優越性チェック：3段階、3組、厳密な優越関係はゼロです。これは構成上そうなっているだけであり、合格を意味することはありません。 数え方は、名前の挙がっている3つの段階から作られる、順不同のすべてのペアを数え、どの段階も除外しません。1つの仕組みが3組すべてを阻んでおり、その仕組みは3組すべてに当てはまります。一部だけに当てはまるのではありません。

各段階は、直下の段階にもう1つイベントを追加したものです。そのため、労力と対象範囲は同じ順に増加し、より安価な段階が、価値の軸でより充実した段階を上回ることはありません。その結果、このテストで検出できるケースはなく、価値だけを理由に劣る段階もありません。順位ではなく、Q2で確認した実際のイベント数とQ5で確認した実際の担当者に基づいて、順序を確認してください。

「集中度」はイベントの構成に実際にある特性ですが、このメニューでは順位付けされていません。 集中度とは、参加者全員が一緒に過ごす共有の時間があることです。この軸での段階の順位は 1つの交流イベント > 別枠で開催する2つのイベント > テーマに沿った複数アクティビティのトラック となり、労力を逆にした順位と同一です。

これを順位付けしても、メニューにすでに含まれている以上の違いは生まれません。機械的な効果は、優越性チェックを空虚でないように見せることだけであり、効率性の軸を安価なものから並べるだけのものにしてしまいます。そのため、ここでは順位を付けずに取り上げています。共有の時間を望む読者がいる場合は、その理由を直接主張できるようにするためです。 コンプライアンス上の結び付きは、判断を避けるためのものではなく、根拠として論じています。1回目と同じ会場、時間帯のパターン、アルコールへの対応を2回目に再利用すれば、1回目に発生した確認が再び必要になります。会場ごとの入場確認が1件、ライセンスに関する確認が1件です。これらは追加ではなく繰り返し発生するもので、同じ方法で取り消し可能です。複数の部屋や建物で同時開催することで、場所ごとに入場確認とライセンスに関する確認が増えるため、トラックはこの2つより明確に上位に位置します。また、参加者が計画を立てた後では、公開済みのトラックを取り下げるコストが高くなります。

• 単一の交流イベント（デフォルト）：1回のイベントで、形式は samber/dev-event-organizer-skills@event-hospitality を参考にします。カバー範囲は、測定された割合によるものではなく、構造上、最初から前倒しで得られるため、効率性で優位に立ちます。参加者がどのような交流をするにせよ、それは最初のイベントで行われます。2回目のイベントに参加する人は、定義上、1回目のイベントが合わなかった人です。該当する人は次第に減る一方、イベントごとのコストはほぼ一定です。
  • 昇格条件（Q2 と Q5 に基づき、個別に評価）： 両方を満たす場合にのみ、1段階上に進めます。どちらか一方でも満たさなければ、ここに留まります。
    • Q2 では、2回目のイベントについて、こちらが持ち込んだ想定ではなく、実際に誰かから要望があったことを示しています。
    • Q5 では、その2回目のイベントの担当者を明確にしています。
• 別々の時間帯で開催する2回のイベント：1回目のイベントが合わない人を対象に、独自の時間帯で2回目を開催し、1回目と同じ会場と対応方針を再利用します。同時開催を伴わずにカバー範囲を広げられるため、コンプライアンスコストは1つ下の段階に結び付きます。実際のコストは、2人目の担当者の夜の時間を使うことであり、その計算は samber/dev-event-organizer-skills@event-volunteers に委ねられます。
• テーマ別の複数アクティビティのトラック（効率性の順位では後回しになる段階）：カバー範囲と労力の両方が最大になるため、効率性を基準に選ぶことはありません。チームが交流プログラムを目玉にしたい場合に選ぶ段階です。その本質的な特性は同時開催が可能なことで、真に異なるアクティビティを共存させられます。参加者が過ごせる夜が1晩しかない場合、順番に実施する方法ではそれができません。
  • 昇格条件（Q3、Q5、Q7 に基づき、個別に評価）： 3つすべてを満たす場合にのみ昇格します。どれか1つでも満たさなければ、1つ下の段階に留まります。
    • Q3 で公開されるアクセス対象の範囲には、単一の形式では同時に満たせない要件が含まれています（家族で参加できるイベントと、静かでアルコールのないイベントは、同じ部屋では実現できません）。
    • Q5 では、トラック全体で1人ではなく、各アクティビティの担当者を明確にしています。
    • Q7 では、この開催回が繰り返されることを示しており、トラックの価値が開催回を重ねるごとに高まります。
  • トラックがイベントの看板となる場面では、samber/dev-event-organizer-skills@event-cultural-identity に判断を委ねます。ここでは、看板となる伝統を扱い、公開済みの先例では「イベントをユニークにする楽しいもの」に予算を確保しています。

削除条件（Q5 に基づく）： Q5 で、最初のイベント以外に担当者がいない場合は、「単一の交流イベント」より上の2つの段階を、このメニューと上記の軸の項目から削除します。降格ではなく削除してください。最下位に残された段階が、計画として組み立てられた後、誰にも引き継がれない事態を招きます。samber/dev-event-organizer-skills@event-hospitality も、同じ条件で上位の段階を削除します。そこでのルールは形式に適用されますが、ここではイベントの回数に適用されます。

降格ではなく削除：どの選択肢がアクセスの最低基準を満たすのかを明記せず、選択肢の一覧として公開されるプログラム。 このメニューと上記の軸の項目から削除してください。

一見すると、全員により多くの選択肢を用意する、寛大な段階に見えます。しかし、最低基準が守られるべき人々にとって、選択が見せかけにしかならない段階です。選択肢の数が多くても、それだけでアクセスを提供したことにはなりません。

スレートが満たすべきインクルージョンの最低基準

このセクションで述べるのは、単一の機会についての判断だけでは答えられない唯一のことです。 これが、このスキルが存在する理由です。以下の最低基準は、このスキル独自のものであり、公開された標準ではありません。

samber/dev-event-organizer-skills@event-hospitality のリファレンスは、単一の機会における最低基準をすでに定めています。会場がアクセスしやすさを考慮して選ばれたか、参加者にかかる費用はいくらか、家族を受け入れるための工夫はあるか、という点です。この確認を各アクティビティに適用すると、スレート上に参加できるものが何もない人を取り残したままでも、基準を満たしてしまいます。すべてのアクティビティを個別に検討していても、そのどれにも参加できない人は、どの確認でも対象になっていませんでした。

スレートレベルのルールを、ベンチマークではなく最低基準として示します。スレートに何かしらの選択肢がある時間帯には必ず、少なくとも1つの選択肢がQ3で報告されたアクセシビリティ要件を満たしていること。 「少なくとも1つ」は最低基準として設定できる最小限の数であり、実践例や推奨数ではありません。これを超える数を示唆するものでもありません。

以下の各事項は、アクティビティの特性ではなく、スレートの特性です。

• 誰も要件を満たせる選択肢がない時間帯は、イベントが誰かを排除している時間帯です。その時間帯の各アクティビティがどれほどよく設計されていても変わりません。対処法は3つです。その時間帯に要件を満たす選択肢を追加する、アクティビティを1つ別の時間帯に移す、またはスレートの内容を絞ることです。問題を記録するだけで、そのまま公開してはいけません。
• どの選択肢が最低基準を満たすかを、スレートとともに公開してください。 参加者は、後から見つけたページではなく、公開されたスレートを見て、移動するか、介護の手配をするか、参加するかどうかを判断します。Q3で公開されている要件の表現に沿って、段差なく利用できるアクティビティ、家族で参加できるアクティビティ、アルコールを伴わないアクティビティがどれかを明記してください。
• この問題は時間帯の重複によって生じるため、それを見つける質問がQ4です。 時間帯が重ならないスレートは、選択肢に関してこの最低基準を満たせないことはありません。満たせない可能性があるのは、通常の単一の機会に対する基準だけであり、それについてはホスピタリティのリファレンスですでに扱っています。

完成した確認内容は、要件の集合とその公開内容を管理する samber/dev-event-organizer-skills@event-accessibility-inclusion に引き継いでください。あなたが確認するのは、スレートが基準を満たしているかどうかです。基準を設定するのはあなたではありません。

クロージングの機会はプログラムの一部であり、余りではありません

スレートに関する判断には、単一の機会を扱うメニューにはない特性がもう1つあります。最後のセッションの直後の機会にきちんと時間を確保するのか、それとも延長したプログラムの残り時間に任せるのか、という点です。

• 変化の速い分野では、クロージングのドリンクの場で、前回から何が変わったかを同業者同士で教え合います。
• グリッド上にその時間を守るものが何もないため、プログラムが延長すると、最初に削られるのがこの機会です。
• 開始前または開始時に早く帰る人がいるのは、プログラムが長引いたか、その機会がイベントの一部だと感じられなかったことを示しています。

これによって変わること、変わらないことは次のとおりです。

• 機会の形式、長さ、開始時刻、終了時刻は、引き続き samber/dev-event-organizer-skills@event-hospitality が決定します。
• 以下の引き継ぎ事項に、時間を確保する要件を追加してください。クロージングの機会に割り当てた時間を確保できるよう、メインプログラムを早めに終了します。当日にこの要件を実行するための合図は、samber/dev-event-organizer-skills@event-run-of-show が決定します。

引き継ぐ内容

出力は、各項目に個別のホスピタリティブリーフが付いた、開催機会の一覧です。その一覧が生成する内容を引き継ぎます。

1. samber/dev-event-organizer-skills@event-schedule-design へ：重複を避ける要件と、クロージングの開催機会を保護する要件（§ クロージングの開催機会はプログラムであり、余りではありません）。互いに時間が重なってはならない開催機会と、メインプログラムと時間が重なってはならない開催機会を明記してください。要件として伝えてください。このスキルがそれを配置するので、セッションや枠を自分で移動することはありません。
2. samber/dev-event-organizer-skills@event-side-event-coordination へ：カレンダー上で第三者によるサテライトイベントとの重複を避けるための、確定済みの一覧です。把握していない時間を保護することはできません。
3. samber/dev-event-organizer-skills@event-accessibility-inclusion へ：上記の各枠の最低人数チェックと、最低人数を満たせなかった枠があればその情報です。
4. samber/dev-event-organizer-skills@event-code-of-conduct へ：開催回数と開催場所です。これにより、範囲に関する条項が、誰もが覚えている一つの開催機会だけでなく、すべての開催機会に及びます。

2つ目の会場を押さえる前に、承認用の一覧を提示してください。一度公開した一覧を後から縮小すると、キャンセルと受け取られます。

ハーネスに永続メモリがある場合は、開催回ごとに以下を記録してください。

• 開催した回数
• 開催した時間帯
• 各層が実際に参加した開催機会
• 最低人数を満たせなかった枠があれば、その枠

次回は、この既定値ではなく、その記録に基づいて優先順位を付けます。

失敗パターン

• このスキルが担当しない形式を再決定する。 開催機会のメニューは samber/dev-event-organizer-skills@event-hospitality の担当です。同じ段階を別の言葉で順位付けしても、一覧の決定にはなりません。一つのメニューに対して順序が二つあると、読者にどちらかを選ばせる重複です。
• サテライトイベントを自分の一覧に含める。 誰かほかの人が主催するイベントは、開催を許可されているのであって、提供されているのではありません。自分が責任を負う一覧ではなく、重複調整用のカレンダーに記載してください。
• 夕方に空き時間があるからと、開催機会を追加する。 追加の判断基準は、Q2の実際の要望とQ5の実際の担当者であり、空いている時間ではありません。
• アクティビティごとにアクセス性を確認し、一覧全体を確認済みとみなす。 これは上記の最低人数基準が設けられた理由であり、個別の確認をすべて通過してしまいます。
• アクセス性に関する説明を出す前に一覧を公開する。 一覧が公開された時点で、人々はそれを基に計画を立てます。後から届いた説明が届くのは、まだ検討中の人だけであり、説明の対象として意図した層には届きません。
• クロージングの開催機会を、余った時間に行うものとして扱う。 講演が長引き、飲み物を楽しむ時間が10分に縮まり、人々が戻ってくるきっかけとなった参加者同士の交流がなくなります。対策：スケジュールには保護要件を伝え、進行表には明確な合図を入れてください。
• 一人の担当者にトラックを任せる。 担当者が一人だけのトラックは、楽観に頼ったプログラムです。Q5はこの問題を正確に捉えられるよう、開催機会ごとに表現されています。

測定

このスキル自体では、参加者数、アクティビティ数、比率は提示しません。「§ 呼び出し例」にあるアクティビティ数と曜日は、ユーザー自身の質問に含まれているものであり、再利用する数値ではありません。ゲートを除き、以下はすべてここで独自に設定するもので、エディション間で比較して初めて意味を持ちます。

• 時間枠ごとの最低限のカバー率（ゲート）：予定表で開催時間として確保したすべての時間枠に、公開済みのアクセシビリティ要件を満たす選択肢が少なくとも1つありました。しきい値は設けず、カバーされていない時間枠の数をゼロにします。
• 実施した催しの数／担当者を割り当てた催しの数（独自設定）：Q5で担当者が指名されていないまま実施された催しは、このメニューの削除条件が防ごうとしている失敗です。
• 最後の催しまでの継続参加率（独自設定）：最後のセッションに参加した人数に対し、締めくくりの催しまで残った人数のおおよその割合です。開始時と中盤に目視で数えます。早めの退席は評価点ではなく、読み取るべき兆候です。
• 参加者層別の、各催しへの参加状況（独自設定）：2つ目の催しが1つ目では参加しなかった人に届いたかどうか、ひいては告知条件が適切だったかどうかを読み取る唯一の手がかりです。

1つ選びます。次のエディションで何を変えるかをイベント前に書き留め、その結果を記録します。

呼び出し例

• 「夜の交流会はすでに決めています。朝のランニングとボードゲームの卓も開催すべきでしょうか。それとも1つで十分でしょうか？」
• 「木曜の夜に、交流アクティビティが3つ同時にあります。問題でしょうか？」
• 「参加者が実際にどのアクティビティに参加できるか分かるように、交流プログラムをどう公開すればよいですか？」
• 「2日目に交流イベントをもう1つ開催したいという人がいます。承諾する前に、何が確認できていなければなりませんか？」

期待される出力：

• 各催しに個別のホスピタリティ概要を付けた予定表
• 時間枠ごとのアクセシビリティ要件の最低ライン確認と、カバーされていない時間枠の明示
• スケジュールに記載された、重複開催を避ける要件
• 予定表の内容を決めた、追加または削除の条件

出力の各要素に、関連スキルから取得したものか、ここで設定したものかを明記します。

参考資料

このスキルには参考ファイルがありません。唯一の判断基準は上記のメニューであり、参考資料に記載するような催しごとの詳細は、すでに samber/dev-event-organizer-skills@event-hospitality 自身の参考ファイルにあります。ここに複製すると、このスキルが避けようとしている競合する二つ目のコピーが生じてしまいます。

同じコレクション内の関連スキル：

• samber/dev-event-organizer-skills@event-hospitality：交流の催しを実施するかどうか、またどのような形式にするかを決定し、アルコールに関する方針を定め、催しごとの概要を指定します。予定表に載せる各催しについて、そのメニューを1回実行します。順位付けし直してはいけません。
• samber/dev-event-organizer-skills@event-side-event-coordination：他の人が開催するイベントを承認し、予定の競合を解消します。保護対象のカレンダーとして、あなたの予定表を受け取ります。
• samber/dev-event-organizer-skills@event-vip-social-program：招待制の集まりや特定ゲスト向けの集まりを扱います。これらがこの一般公開の予定表に載ることはありません。
• samber/dev-event-organizer-skills@event-accessibility-inclusion：予定表の最低ライン確認で参照するアクセシビリティ要件と、公開済みの詳細度を管理します。
• samber/dev-event-organizer-skills@event-schedule-design：予定表の開催時間を公開済みのタイムテーブルに配置し、重複開催を避ける要件を受け取ります。
• samber/dev-event-organizer-skills@event-code-of-conduct：予定表に載るすべての催しに適用しなければならない適用範囲の条項を管理します。