event-b2b-matchmaking

イベント向けB2Bマッチング

イベントに参加する2つの集団を、予約済みの1対1のビジネスミーティングへとつなぐ仕組みを設計します。プログラムを実施するかどうか、2つの側をどうマッチングするか、枠をどう予約・配置するか、スポンサー向けパッケージで正当に約束できるミーティング件数、予約のキャンセルをどう吸収するか、その後何を測定するかまで、一連の流れすべてを担当します。

まずは「実施しない」と判断してください。多くのコミュニティ技術イベントでは、実際にこの仕組みを実施しないのが正解です。「ミーティングプログラム自体を設けない」は、順位付けされた選択肢の中で、しばしば勝る下位の段階であり、主催者がまだ着手していない場合の仮置きではありません。プログラムを実施する価値があるのは、署名済みのパッケージにミーティング件数が明記されている場合、または、イベントが意図的に、廊下ですれ違うだけでは出会えない2つの集団を集めた場合に限られます。

名前が似ているだけで、別の仕事

samber/dev-event-organizer-skills@hackathon-team-formationも、メニューをマッチングと呼んでいます。しかし、これは別の仕組みです。両者を混同すると、誤った仕組みを実行することになります。

• ハッカソン参加者同士をマッチングし、1つの集団から開発チームを作ります。失敗すると、誰にも選ばれない参加者が出ます。
• こちらは異なる2つの集団（参加者とスポンサー、創業者と投資家、買い手とベンダー）を、予約済みのペアにします。失敗すると、約束した件数を達成できないスポンサーが出るか、同意していないミーティングに参加者が不意に連れ込まれます。

どちらの仕組みも、もう一方の代わりにはなりません。ピッチと参加希望者を募るラウンドでは件数の約束を果たせず、予約済みの枠を組んでもチームはできません。ハッカソンチーム編成に関する質問はそちらに案内し、ここでは対応を止めてください。

あらゆる場面で守る原則

してはいけないこと：

• ミーティング時間、枠数、充足率、無断欠席率を明示したり、引用したりしないでください。いずれも、ここで安易に作り出してしまいがちな数字であり、作られた数字は、但し書きよりも長く残ります。
• 別のイベントの前回開催時の数字を流用しないでください。このプログラムで使えるのは、主催者がこのプログラムで測定した数字だけです。

展示会の仕組みを引き継げるのは一部だけです。引き継げるのは、明示された2つの側、提示されたマッチング基準、上限のあるミーティング枠、確認の手順、そして実施件数と約束した件数の比較です。引き継げないものは4つあります。

1. 買い手と売り手という前提。 展示会の参加者は売り込みを受けることを期待して来場します。一方、開発者向けイベントの参加者は学ぶために来場し、依頼されていないベンダーとのミーティングを妨げと感じます。
2. 登録を連絡への同意とみなすこと。 大規模な商業展示会では、バッジの提示をマッチングへの同意として扱うことがよくあります。コミュニティイベントでは、スポンサーに提供するのは集計済みの参加者属性であり、氏名は決して渡しません（DevOpsDaysの主催ガイド）。
3. ミーティング専用日。 展示会のマッチングでは、スケジュールの大部分を専用の時間として確保します。開発者向けイベントでは、ミーティング枠はセッションを中心に組まれたスケジュールに加わるもので、競合があれば必ず優先順位が下がります。
4. ベンダーのベンチマーク数値。 マッチングプラットフォーム企業が公表する充足率やミーティング件数は、販売資料です。絶対に引用しないでください。そうしたベンダーの1社であるBrellaは、自社が示す業界平均20～30％に対し、高ボリュームの単一パートナーの無断欠席率は1.5％だと公表し、さらに、プラットフォーム全体のミーティング承諾率を38～40％と公表しています。どちらも、そのベンダー自身の顧客ベースから得た自社の数値で、自社製品の販売を目的として公表されており、独立した検証は一切されていません。これはベンダーのマーケティングに関する事実であり、このプログラムの計画に使える数字ではありません。

以下の各メニューの順位は、すべて初期設定であり、絶対的なルールではありません。すでに把握している情報に照らして、4つのメニューすべてを順位付けし直してください。次の要素があれば、初期設定の順位は覆ります。

• 登録フローですでに収集している、オプトイン方式のプロフィールフォーム。
• 独自のターゲットリストを持つスポンサー。
• すでに契約済みの会場枠。
• すでにシフトに配置されているスタッフ。
• 前回開催時の予約件数と実施件数の記録。

インタビュー

一度に一つずつ質問し、可能であれば選択式にします。質問9〜11は、以下のメニューで労力、取り消しやすさ、効果が出るまでの時間が大きく異なるために設けています。これらのデフォルトは、ユーザーに代わって選べません。

1. 署名済み、またはドラフト段階のスポンサー向けパッケージに、すでに会議番号が記載されていますか？記載されている場合、それは決定事項ではなく、実施すべき入力です。
2. 別々に招待する対象者が実際に二つのグループいますか？それとも、スポンサーがその中にいる一つの参加者グループですか？
3. 何組のミーティングを想定していますか？一人で覚えていられる程度の少数ですか、それともそれ以上ですか？
4. 各側について、どのような構造化データをすでに保有していますか？また、そのデータはどこから得たものですか。登録情報、オプトインフォーム、スポンサーのターゲットリスト、それとも何もありませんか？
5. 各側は実際に何に同意しましたか？スポンサーから連絡を受けること、ディレクトリに掲載されること、どちらも同意していないことのいずれですか？意図した内容ではなく、各側が目にした文言に基づいて答えてください。
6. ミーティングは物理的にどこで行われ、その場所の管理者は誰ですか？
7. 公開済みのタイムテーブルのどこにミーティング枠がありますか？また、その枠はすでに確定していますか？
8. ミーティング枠の間、ミーティングエリアにスタッフは配置されますか？それとも無人で運営しますか？
9. 予約受付を開始しなければならない期限と、スケジュールの変更を終えなければならない期限は、それぞれいつですか？
10. 単発ですか、それとも定期開催ですか？このプログラムの前回開催について、測定済みの数値を保有していますか？
11. 労力の上限はどの程度ですか？予約期間中と当日の主催者の稼働時間、そして料金を支払っているスポンサーにミーティングを提供できないと伝えるための政治的な信用の上限を教えてください。

ワークフロー

1. このプログラムを実施するかどうかを決めます（Q1、Q2）。番号が決まっていない、または実際に二つの対象者グループが存在しない場合は、そのことを伝えて終了します。
2. 変更できないものを書き出します：署名済みの会議番号、公開済みのタイムテーブル、各側が目にした同意文言、フロアプラン、会議室の予約枠。矛盾がある場合は、該当事項を管理する関連プログラムに引き継ぎます。
3. 適切なマッチング方式を選びます。フォームを書く前に、マッチング基準を一文で書き出してください：references/matching-and-slot-mechanics.md。
4. **何かを収集する前に、同意の扱いを確定します。**ディレクトリの公開後に遡って対応することは、ここで取り消せない唯一の誤りです。
5. スケジュール方式を選び、渡されたタイムテーブル内にミーティング枠を配置します。セッションに重ねてはいけません。
6. パッケージを販売する前にまだ間に合う場合は、割り当て数に関する約束の方針を決めます：references/quota-commitment-and-evidence.md。
7. 無断欠席への対応を決め、スケジュールを公開する前に、各ペアについて双方の確認を取ります。
8. ミーティング概要を一つ公開します：マッチング基準、枠の配置、予約方法、予約枠を欠席した場合の扱い、当日の担当者として指名された主催者一名。
9. ミーティング枠を運営し、各ペアについて、予約済み、実施済み、空き、代替済みのいずれかを記録します。
10. 結果を汎用レコード一つとして後続の担当先に引き継ぎます。スポンサーごとの追跡と更新レポートは、event-sponsor-fulfillmentの担当範囲であり、ここでは構築しません。

ハーネスに永続メモリがある場合は、開催ごとに、使用したマッチング基準、予約されたペア数、実施されたミーティング数、空いた予約枠数、キャンセルした側、希望しないミーティングに関するすべての苦情を記録してください。実施済み数と予約済み数の比較は、このプログラムが計画に使える唯一の数値です。この数値を利用できるのは、実際に測定した後だけです。

マッチングの仕組み

ペアがどのように成立するかを示します。5段階あり、最初の選択肢が基本です。順位はデフォルトであり、絶対的なものではありません。Q2、Q3、Q4によって順位は変わります。

• 労力（セットアップ、予約期間中にペアごとに主催者が費やす時間、予定のある仕事か継続的な仕事か）：主催者による仲介 > スコア付きランキング > 相互オプトイン > オープンディレクトリ > ミーティングプログラムなし
• 価値、割り当ての確実性（明示された基準に基づいて具体的なミーティング件数を約束し、それを実現できるか）：スコア付きランキング > 相互オプトイン > 主催者による仲介 > オープンディレクトリ > ミーティングプログラムなし
• 価値、ミーティングごとの関連性（双方が同じミーティングをもう一度受けたいと思うか）：主催者による仲介 > 相互オプトイン > スコア付きランキング > オープンディレクトリ > ミーティングプログラムなし
• コンプライアンスコスト（このデータの収集と共有によって発生する審査、および取り消せない部分の少なさ）：スコア付きランキング > オープンディレクトリ > 主催者による仲介 > 相互オプトイン > ミーティングプログラムなし
• 効率：相互オプトイン > オープンディレクトリ > ミーティングプログラムなし > スコア付きランキング > 主催者による仲介

これらの順位のうち2つは断定ではなく議論の余地があり、すべてのペアの優位性チェック（10組、厳密な優位関係は0件）は、references/matching-and-slot-mechanics.md の「§ Ranking derivations」に記載されています。

• ミーティングプログラムなし（デフォルト）— ほとんどのコミュニティ主催イベントでは、これが適切です。会場内での交流や展示会場がすでにその役割を果たしています。Q1でミーティング件数が示されるか、Q2で別々に招待された2つの参加者層が確認された時点で、相互オプトインに移行します。
• 相互オプトイン — プログラムの運用開始後は、効率で最も優れています。双方が希望を提示し、双方がオプトインした場合にのみペアが成立します。
• オープンディレクトリ — 参加者が閲覧し、ミーティングをリクエストできるオプトイン形式の参加者リストです。低コストですが、価値とコンプライアンスの面で上位2段階に劣ります。ペアごとに選んだのは片方だけです。
• スコア付きランキング — 主催者が構造化されたプロフィールデータから適合度を採点し、順位付けされたおすすめを提示します。割り当ての確実性が最も高い方式です。収集するついでに、すでに双方から構造化され比較可能なプロフィールデータを取得している場合に移行します。
• 主催者による仲介 — 担当者が、提示された関心に基づいて手作業でペアを組みます。関連性と労力の面で最も優れています。想定されるペア数が、1人で把握できる範囲に収まる場合に移行します。
• 格下げではなく削除： 片方だけがオプトインしたペアは、すべて削除します。スポンサーに予約用のリストを渡すことになるからです。これは、予告なしのミーティングに関する苦情すべての原因となる仕組みです。

スケジューリングの仕組み

成立したペアが、どのように特定の日の枠になるか。順位付け（デフォルトであり、絶対ではありません。Q7、Q9、Q11 によって順位が変わります）：

• 労力（グリッドの作成、セッションとの調整による競合解消、参加者ごとのメッセージ数、公開後の変更可能性）：主催者割り当てグリッド > ハイブリッド > セルフサービス予約 > 予約枠なし
• 価値、達成された割当数（約束した数の会議が実際に行われ、相手が明示された条件を満たしていること）：主催者割り当てグリッド > ハイブリッド > セルフサービス予約 > 予約枠なし
• 価値、参加者の自律性（参加者が自分の当日の予定を自分で管理し、自分で選んでいない会議が予定に入ることがないこと）：予約枠なし > セルフサービス予約 > ハイブリッド > 主催者割り当てグリッド
• 効率：セルフサービス予約 > 予約枠なし > ハイブリッド > 主催者割り当てグリッド

達成された割当数の軸は、労力の逆順位と同じです。これは結論ではなく、注意を促すものです。選択肢を左右するのは自律性であり、スポンサー対応をする主催者が最も忘れがちな軸です。

ここではコンプライアンスコストの軸は適用されません。この選択肢では、マッチングと割当数の選択肢がすでに引き受けている以上のデータ収集や義務の引き受けはありません。references/matching-and-slot-mechanics.md の「§ Ranking derivations」に、全組み合わせの優越性チェック（6 組、厳密な優越関係は 0 件）があります。

• 公開済みの空き時間に対するセルフサービス予約 - デフォルトであり、効率性に最も優れた方法です。それぞれが空いている時間を示し、相手が予約し、主催者はその時間枠だけを公開します。参加者の当日の予定に入る会議はすべて、本人が選んだものです。Q1 で契約上の件数が示された時点で、ハイブリッドに切り替えます。セルフサービスでは会議を実施できますが、件数は保証できません。
• 予約枠なし - 紹介だけを行い、その後の予定は本人に任せます。労力ゼロで自律性を最大限に保てます。プログラムの目的が会議ではなく紹介である場合は適切な選択肢であり、グリッドに枠がまったくない場合でも成立する唯一の段階です（Q7）。
• ハイブリッド - 契約上の割当数に必要な枠は主催者が事前に割り当て、残りの枠はセルフサービスにします。件数を保証するための最小限の仕組みです。コストは、参加者が選んでいない枠が事前割り当て分になることです。そのため、事前割り当てされた各ペアは、予定に表示される前に承諾の手順を経る必要があります。
• 主催者割り当てグリッド - 主催者がすべての組み合わせと枠を作成し、それぞれが確認します。達成された割当数と労力で最も高く、自律性で最も低くなります。切り替え条件（Q2 に基づく）： 両方の集団が互いに会うことを目的として招待されており、どちらも会場に来る別の理由がないことです。
• 削除対象であり、順位を下げるだけでは不十分：本人の承諾なしに、誰かの予定に入れられる会議。 人々の時間を使って割当数を作り出す唯一の方法であり、割当数によって防ぐはずだった事態そのものを招きます。誰も承諾していない会議は、予定に入った時点ですでに無断欠席が決まっています。

割り当て数の確約方針

スポンサー向けパッケージで、誠実に約束できる内容です。確約の形を設計します。samber/dev-event-organizer-skills@event-sponsor-agreement が条項を作成し、samber/dev-event-organizer-skills@event-sponsor-value-proposition が、その特典を販売する価値がそもそもあるかを判断します。順位付け（デフォルトであり、絶対的なルールではありません。Q1、Q4、Q11 によって順位が変わります）：

• 労力（提供体制、確認すべき基準、ペアごとの追跡、そして費用を負担できる必要がある救済措置）：基準付きの件数保証 > 件数保証 > ベストエフォートの目標 > 面談の約束なし
• 価値、パッケージに付けられる価格（確実性に対して購入者が認める価値）：基準付きの件数保証 > 件数保証 > ベストエフォートの目標 > 面談の約束なし
• 価値、更新の持続可能性（当日の結果がどうであれ、イベント後もスポンサーに対して誠実な約束に見えるか）：面談の約束なし > ベストエフォートの目標 > 基準付きの件数保証 > 件数保証
• コンプライアンスコスト（書面による確約が引き起こす審査と、双方が署名した後に撤回できる余地の少なさ）：基準付きの件数保証 == 件数保証 > ベストエフォートの目標 > 面談の約束なし
• 効率性：ベストエフォートの目標 > 面談の約束なし > 基準付きの件数保証 > 件数保証

コンプライアンスにおける == は、ごまかしではなく、根拠のある同順位です。どちらも、主催者が履行または救済措置を提供しなければならない、双方が署名した件数です。そのため、どちらも同じ契約審査を引き起こし、署名後に撤回するのも同じくらい困難です。基準を追加すると、当日に確認すべき内容が変わります。これは労力の問題であり、同順位によって見えなくなる審査の問題ではありません。

価格の軸は、前のメニューとまったく同じく、労力の逆順で順位付けされています。このメニューの選択を可能にするのは、更新の持続可能性です。references/quota-commitment-and-evidence.md の「順位付けの導出」に、全組み合わせの優越性チェック（6 組、厳密な優越関係は 0 件）があります。

• ベストエフォートの目標 - デフォルトです。意図として提示する数であり、救済措置は伴いませんが、基準は記録しておきます。保証とは主張していないため、未達でも誠実さを保てます。Q1 で契約上の面談件数が指定され、Q4 で基準を確認するのに十分なデータを保持している場合は、基準付きの件数保証に引き上げます。
• 面談の約束なし - スポンサーは参加機会を得て、プログラムは本来の価値に基づいて進行します。更新の持続可能性が最も高い選択肢です。そもそも約束していないことは破れません。対応するメニューのデフォルトがこの段階なら、これを選ぶのが適切です。
• 基準付きの件数保証 - 明示した基準を満たす相手との面談件数に、定められた補填措置を加えます。価格と労力の両方の軸で最上位です。上記の条件を満たす場合に引き上げます。補填措置は、イベント終了後に実際に提供できるものでなければなりません。これは主催者が手遅れになってから気付く制約です。
• 件数保証 - 基準なしの単純な件数に補填措置を加えます。効率性では最下位であり、不誠実な形で達成するのも最も簡単です。空いている人をあてがえば、スポンサーは件数を得ても、求めていた相手には会えません。イベント後の評価は、何も約束しなかった場合より悪くなります。
• 削除対象であり、順位を下げる対象ではありません：基準も補填措置の明記もない、見込み客向け資料に掲載された面談件数。 裏付けのない件数は、不満を抱えたスポンサーの前で救済措置をその場しのぎで考えなければならない、同じ確約にすぎません。どの段階を選んでも、変わらない境界があります。スポンサーシップで購入できるのは掲載枠と参加機会であり、プログラムへの影響力ではありません。「スポンサーがプログラムに割り込む権利を買えるようにしてはいけません」（DevOpsDays の主催者向けガイド。このコレクションでは samber/dev-event-organizer-skills@event-sponsor-value-proposition が紹介しています）。面談枠は参加機会であり、登壇枠や審査結果、議題の一部になることは決してありません。

予約済みのミーティングにおける無断欠席への対応

確定した枠が埋まらなかった場合の対応です。優先順位（デフォルトであり、絶対的なルールではありません。Q8 と Q10 によって順位が変わります）：

• 労力（送信するメッセージ数、その時間帯に必要な受付スタッフの配置、そして自分で測定しておく必要がある率）：枠の過剰予約 > 待機者による補充 > 再確認とリマインダー > 何もしない
• 価値、確保できた割り当て枠（実際に行われた予約済みミーティング数と、約束した数との比較）：枠の過剰予約 > 待機者による補充 > 再確認とリマインダー > 何もしない
• 価値、相手側の体験（誰も空席のテーブルで待たされず、正しく予約した人も断られないこと）：待機者による補充 > 再確認とリマインダー > 何もしない > 枠の過剰予約
• 効率：再確認とリマインダー > 待機者による補充 > 何もしない > 枠の過剰予約

確保できた割り当て枠は、労力の逆と順位が完全に一致します。相手側の体験が判断の決め手となり、唯一意外なのは、何もしないほうが過剰予約より上位に来ることです。空席のテーブルは来場した一人をがっかりさせますが、予約の重複は、求められたことをすべて行った人を断ることになります。references/quota-commitment-and-evidence.md の § Ranking derivations に、完全な優越性チェック（6 組、厳密な優越関係は 0 件）があります。

• 再確認とリマインダー - デフォルトです。予約時に明示的な承諾を得て、時間帯の前にリマインダーを送ります。無断欠席を吸収するのではなく減らす唯一の段階ですが、その代わりにメッセージを 2 通送ります。
• 待機者による補充 - 相手ごとの待機キューを用意し、当日に空いた枠へ繰り上げます。価値の両方の軸でデフォルトを上回ります。妨げとなるのは労力だけです。**昇格条件（Q8 に対応）：**時間帯にミーティングエリアのスタッフがすでに配置されていること。スタッフ不在では、キューに意味がありません。
• 何もしない - ミーティングの欠席は、欠席として扱います。割り当て枠の選択肢で約束なしと決まっており、Q8 でその時間帯はスタッフ不在とされている場合は、これが誠実な対応です。
• 枠の過剰予約 - 想定される出席率をもとに、枠数を超えてミーティングを予約します。確保できた割り当て枠と労力で最上位ですが、既存の問題を吸収するのではなく、新たな失敗パターンを生み出す唯一の段階です。**条件付きで削除（Q10 に対応）：**同じプログラムの前回開催で、予約数と実施数を測定した実績がない場合は削除してください。初回開催や、その他ほとんどのケースが該当します。samber/dev-event-organizer-skills@event-no-show-management にあるイベント単位の出席率の区分は、ここで扱う単位とは異なります。ここに流用することこそ、このルールが防ごうとしている具体的な誤りです。
• 降格ではなく削除：デポジット、放棄される特典、またはミーティングを欠席した参加者へのあらゆるペナルティ。 samber/dev-event-organizer-skills@event-no-show-management では、すでにデポジットに反対する根拠が示されています。ミーティング枠だからといって事情は変わりません。さらにここでは、参加者を招待した会話に値段を付けることになります。

失敗パターン

• 仕組みが面白いという理由でプログラムを実施する。 署名入りの数字も第2の参加者集団もなく、今ではミーティング枠が予約フォームと競合しています。対策：ワークフローのステップ1を実際のゲートにし、通常は「いいえ」と回答します。
• データを先に集め、共有ルールをあとから決める。 同意の範囲は、データの使い道を決めた時点ではなく、誰かがフォームを送信した時点で確定します。対策：収集前にQ5を確認し、相手が実際に目にした文言を読みます。
• 参加率や無断欠席率を引用する。 マッチングソフトウェアを販売する企業は、それぞれ独自の定義に基づいて、流通している数値を公表しています。対策：仕組みを正直に説明し、実施後に自分たちの実数を報告します。
• ミーティング枠を動かしてセッションを移動する。 グリッドの担当は samber/dev-event-organizer-skills@event-schedule-design であり、ミーティング枠はその中に配置されるゲストです。対策：枠の配置は所与のものとして扱うか、自分で解決せずに担当先へ依頼します。
• 対象者が異なる数字を提示する。 単純な人数を数える段階では間違えやすく、スポンサーは実施中ではなく事後に気づきます。対策：ベストエフォートの目標であっても、基準を書き留めます。コストはかからず、マッチング対象を決める助けになります。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment の役割を再構築する。スポンサーごとの追跡マトリックス、支払いゲート、更新レポートなどです。対策：こちらはミーティング概要と結果記録を1つずつ作成します。それらは別の場所でスポンサーごとに実施・報告されます。
• 予約済みミーティングの無断欠席を、イベント全体の無断欠席として扱う。 単位も参加者集団も異なり、対処法も別です。兄弟プログラムの数値を流用することはできません。対策：自分たちで測定します。

測定

以下はすべて独自に設定するもので、自分たちのプログラムの開催回をまたいだときにのみ意味を持ちます。

• 実施数／予約数（独自設定）— 次回の計画の基準となる、このプログラム唯一の数値です。ほかの数値で代用することはできません。
• 予約数／約束した数（独自設定、スポンサーごと）— ノルマの約束を達成したかを示す唯一の数値です。スポンサーごとに報告し、スポンサー間の平均値として報告してはいけません。
• 相互承諾率（独自設定）— 関連性を測るために利用できる、最も近い代理指標として、双方が承諾したリクエストの割合です。あくまで代理指標であるため、報告時にはその旨を伝えます。
• 空き枠数（独自設定）— 予約されたものの、誰も参加しなかった枠の数です。その1枠ごとに、無断欠席対応の段階が不十分だったことを示します。
• 望まないミーティングに関する苦情（ゲート）— 目標はゼロです。ゼロでない場合、本人の承諾なしに誰かのスケジュールへペアリングが追加されたことを意味します。参加者の行動ではなく、マッチングまたはスケジュール設定の段階における不備として扱います。
• 確認完了率（ゲート）— 公開スケジュールに掲載されたすべてのペアについて、公開前に双方が承諾していること。しきい値はなく、重要なのは未確認の件数がゼロであることです。

呼び出し例

• 「スポンサーから、エンジニアリングリーダーとのミーティングを15件保証してほしいと言われています。可能ですか？」
• 「スタートアップ20社と投資家10人を同じ日に招待します。ミーティングはどのように設定しますか？」
• 「コミュニティカンファレンスで、1対1のミーティングプログラムを実施すべきでしょうか？」
• 「予約したミーティングの半分が実施されませんでした。次回は何を変えればよいですか？」
• 「参加者リストを渡さずに、参加者とスポンサーをどのようにマッチングできますか？」

期待される出力：

• プログラムを実施するかどうかを、明確に「はい」または「いいえ」で示すこと。
• マッチングの仕組みを明示し、マッチング基準を文として記述し、同意の文言を示すこと。
• 指定されたグリッド内にミーティング枠を配置した、スケジュール設定の仕組み。
• 基準と、確約する場合は資金を用意できる埋め合わせ策を含む、ノルマへの対応方針。
• 無断欠席への対応段階。
• ミーティング概要を1つ、結果記録を1つ。

独自設定の要素にはすべてその旨を明記し、ミーティング時間、枠数、参加率、無断欠席率は一切記載しません。

参考資料

• references/matching-and-slot-mechanics.md - マッチング条件を文章化したもの、プロフィール項目の一覧と各項目の用途、同意文言のチェックリスト、実施手順書としてまとめた4種類のマッチングルールの形式、自分では管理していないグリッドに合わせたスロットブロックの作成方法、そして肯定例と否定例を並べた事例。
• references/quota-commitment-and-evidence.md - samber/dev-event-organizer-skills@event-sponsor-agreement に渡せる文言としてまとめた4種類のコミットメントの形式、各形式がイベント後にどのような負担をもたらすかを示した補填策の一覧、参加資格条件のワークシート、ミーティング概要と成果記録、そして測定項目の定義とカウントルール。

同じコレクションの関連資料：

• samber/dev-event-organizer-skills@event-sponsor-agreement - ミーティング数の割り当て条項とその救済措置を起草します。このスキルはコミットメントの形式を決めますが、文言は決めません。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment - 署名済みのスポンサーごとに履行と報告を行い、リード獲得の方針を担います。予約済みのミーティングがその代わりになることはありません。
• samber/dev-event-organizer-skills@event-booth-experience - 展示会場のフロアと、ブースへの自然な来場者流入を担います。予約・確認済みのミーティングとは別の仕組みです。
• samber/dev-event-organizer-skills@event-schedule-design - ミーティングブロックが組み込まれる公開済みのグリッドを担います。このスキルはその中にスロットを配置しますが、セッションは移動しません。
• samber/dev-event-organizer-skills@event-attendee-experience - 一般参加者の体験全体と、意図的に予定を入れない廊下での交流を担います。予約制のミーティングプログラムとは正反対の方針です。
• samber/dev-event-organizer-skills@event-sponsor-prospectus - 署名済みのミーティング数を掲載する文書を作成します。実際の資料を調査した範囲では、いかなる種類の保証条項も見つかっていません。この結果を踏まえ、このスキルでは、参加条件も補填策もない単なるミーティング数を「格下げ」ではなく「削除」としています。