event-learning-expedition-design

イベント学習エクスペディションの設計

自分の参加者を他者の建物に連れていき、その組織の実務をプログラムとして体験してもらいます。ここから二つの判断が生まれます。このスキルが扱うのは、その二つだけです。指示できないホストにアジェンダのどの程度を委ねるか、そしてホストが参加者に何を見せ、何を実際に行わせるかです。

まず読むこと：対象範囲は名前から想像するよりずっと狭いです

「学習エクスペディション」はイベント形式全体を指すように聞こえます。しかし、このコレクションではそうではありません。そうであるかのように扱うと、姉妹スキルがより適切に提供する助言まで、ここで受け取ることになります。

この形式に含まれると考えられる要素の大半には、すでに担当スキルがあります。それぞれのスキルは、このスキルよりも詳しく扱っています。

• 一つのアジェンダで複数の会場を回ること。 新しい仕組みではありません。samber/dev-event-organizer-skills@event-venue-sourcing のリファレンスファイルに結論があります。複数会場のイベントは「会場ごとにこのシート全体を一度ずつ適用し、それに会場間の移動時間と、各会場につき一人の明確な担当者を加える。そこまでは単純な拡張です」。シートはそちらを参照してください。
• 移動手段と参加人数の問題。 samber/dev-event-organizer-skills@event-hospitality は、会場外への遠足を、何もしないことよりも低く評価しています。「移動手段、別の建物独自の規則と保険の要件、そして移動手段が出発した後では訂正できない参加人数が伴うのは、そのうち一つだけです」。この論拠はそのまま当てはまります。例外は、プログラムではなく交流を目的とする夜の訪問です。それはこのスキルではなく、あちらのスキルが扱います。
• 行動規範が送迎バスやホストの施設内にも適用されるかどうか。 適用範囲の条項は samber/dev-event-organizer-skills@event-code-of-conduct が担当します。そのリファレンスファイルには、MLH が「すべてのハッカソン会場、ハッカソン関連の交流イベント、ハッカソンが提供する交通手段、イベントに関連するオンラインでのやり取り」を対象としていると記録されています。また、「シャトルは会場でも交流イベントでもありません」と指摘しています。会場と車両を伝え、条項を持ち帰ってください。
• 移動中のケータリングと、一緒に移動するすべての業者。 サービス形式については samber/dev-event-organizer-skills@event-hospitality、契約については samber/dev-event-organizer-skills@event-vendor-sourcing を参照してください。
• 誰を招待するか、そしてその理由。 samber/dev-event-organizer-skills@business-event-formats を参照してください。形式の段階では顧客との関係性を深める形式が位置づけられ、コンプライアンスの軸では、ここでよく用いられる仕組みが示されています。「承諾された招待を、相手に失礼となる形で撤回することはできません。また、招待はあなたの方針より先に、ゲスト自身の贈答品および贈収賄防止方針の対象となります」。プロトコル上の義務を持つ指名ゲストについては samber/dev-event-organizer-skills@event-vip-management、ジャーナリストについては samber/dev-event-organizer-skills@event-press-relations を参照してください。
• 訪問を記録し、そこから何かを公開すること。 マスターファイルを通じて samber/dev-event-organizer-skills@event-production を参照し、次に samber/dev-event-organizer-skills@event-content-repurposing を参照してください。権利に関するゲートは、あなたにも適用されます。「沈黙は、許可ではなく、禁止を意味します」。
• イベントの目的、費用、測定方法。 samber/dev-event-organizer-skills@corporate-event-strategy を参照してください。認識の変化やパイプラインへの影響は、あちらのスキルにおける目標と測定の用語であり、あなたのものではありません。

残るのは構造上の事実が一つだけです。そして、それは現実に存在します。 このコレクションのほかのすべてのケースでは、第三者が会場かコンテンツのどちらかを提供します。

samber/dev-event-organizer-skills@event-venue-sourcing では、会場を用意し、そこをあなたが満たします。samber/dev-event-organizer-skills@event-side-event-coordination は、他者が自らの目的で開催するイベントを扱います――「あちらのスキルでは夜のイベントをあなたが提供しますが、こちらではあなたが許可するイベントが対象です」。

この場合、ホストはその両方を提供します。つまり、ホストが辞退すると、再予約できる会場を失うのではなく、プログラムそのものがなくなります。 このコレクションで扱っているものに、その内容はありません。主催者でも、スポンサーでも、ベンダーでもないホスト組織が、参加者に何を見せ、何を繰り返し伝えることを許可するかについては、何も扱っていません。このコレクションが前提とする同意の流れは、主催者から登壇者へ向かうものであり、会場を提供した組織に向けた分岐はありません。

この2つの判断以外の質問はすべて、上記の責任者に回し、そこで止めてください。このスキルが短いのは、この2つの判断だけを扱うためです。

このスキルに基づいて作成する成果物に、数値を作って記載してはいけません。拠点数、グループの規模、説明の長さ、準備期間、ホストの承認にかかる時間は、ホストが提示するものです。作り出した数値は、それに添えた但し書きより長く残ります。制約は定性的に説明し、ホストに確認してください。

このスキルは、法的な基準値、管轄区域、書式、文書の名称、金額について何も定めていません。これは、賠償責任については samber/dev-event-organizer-skills@event-side-event-coordination が、賞金に関する法令については samber/dev-event-organizer-skills@hackathon-cash-prize が定めている恒常的な方針です。アクセス姿勢の段階は姿勢を表すものであり、法的文書を表すものではありません。必要な書類の名称を決めるのは、法律顧問です。

ヒアリング

一度に質問するのは1つだけにし、可能な場合は選択式にしてください。両方の選択肢にある各条件は、どの質問に対応するかを明示しています。そのため、何かを順位付けする前に、これらに答えてください。

1. ホスト組織は、参加者を受け入れることに書面で同意していますか。それとも、誰からも同意を得ていない形式のアイデアですか。同意がある場合、何か条件が付いていましたか？
2. 参加者が現地にいる必要があるのはなぜですか。スライドでは見せられないもの、つまり現場、ホール、ハードウェア、規模、障害などがあるからですか。それとも、人々との交流や会話が主な魅力ですか？
3. 参加者自身の疑問は何ですか。特定の技術的な質問があり、名前の挙がったエンジニアに詳しく質問できるのでしょうか。それとも、組織の日々の運営について知りたいという体験的な質問でしょうか？
4. ホスト内の窓口担当者は誰ですか。その人は同僚の時間も確保できますか。それとも、自分の時間しか約束できませんか？
5. ホストから、立ち入り区域、顧客名、撮影ルールなどの制限が提示されていますか。その制限はホストを代表して発言する人から示されたものですか。それとも、ホストが何を望むかについてのあなた自身の推測ですか？
6. 参加者リストは事前に確定しており、人数も把握できますか。それとも、当日まで参加を受け付けますか？
7. イベント後の確認対応を、誰が名前を挙げて担当しますか。また、その人はイベント後、どのくらいの期間対応を続けますか？
8. 労力の上限と日程を教えてください。最初から最後まで担当できるのは何人ですか。準備期間はどれくらいありますか。ホストに中止されても、どの程度まで対応できますか？
9. 既定の順序では考慮されていない既存のものはありますか。候補となるホストとの継続的な関係、ホストに雇用されている主催者、過去の開催回での訪問、または、いずれかとの締結済みの契約などですか？

以下の2つの順位付けは既定のものであり、絶対的なルールではありません。状況や実行する人によって変わります。何かを推奨する前に、Q9の回答を踏まえて順位を付け直してください。候補となるホストの内部で働く主催者なら、冷たいアプローチをカレンダーへの招待に変えられるため、既定の順位で選ばれた段階よりも、その段階が上位になります。

ワークフロー

1. インタビューを実施し、Q1から始めます。誰も「はい」と言っていないなら、形式を設計しているのではなく選んでいる状態です。その選択は samber/dev-event-organizer-skills@business-event-formats の担当です。
2. 先に進む前に、上記のスコープセクションに該当するものはすべて対象外にします。「学習のための視察を企画したい」として持ち込まれる案件の多くは、どちらのメニューに進むこともなく対象外になります。
3. 最初のメニューを順位付けする前に、Q2とQ3をもとに価値の軸を定めます。これは samber/dev-event-organizer-skills@business-event-formats が独自の形式ラダーで使う仕組みなので、改めて導き出すのではなく、そこから引き継いでください。
4. ホスト依存度の方針を選び、順位付けの前に除外ルールを適用します。
5. アクセスと再現性の方針を選び、順位付けの前に除外ルールを適用します。
6. ホスト向けブリーフを作成します。参加者が何を理解するために来るのか、ホスト側の人々に何をしてもらうのか、参加者に何を共有してよいと伝えたのかを明記します。ホスト側の社内承認が始まる前に送付してください。承認後ではありません。
7. 次の項目を、担当先を明示して引き継ぎます。
   • 会場と移動手段は、スコープ条項のため samber/dev-event-organizer-skills@event-code-of-conduct に引き継ぎます。
   • 会場ごとの要件シートは samber/dev-event-organizer-skills@event-venue-sourcing に引き継ぎます。
   • 交通、ケータリング、参加人数は samber/dev-event-organizer-skills@event-hospitality と samber/dev-event-organizer-skills@event-vendor-sourcing に引き継ぎます。
   • 記録するものはすべて samber/dev-event-organizer-skills@event-production に引き継ぎます。
   • 目標と測定は samber/dev-event-organizer-skills@corporate-event-strategy に引き継ぎます。
8. ホストに何かを約束したり、参加者に公開したりする前に、各決定を検証のために提示します。ホストの承認プロセスは後戻りできない地点です。ホスト側の人々が予定を確保した後に変更すると、損なわれるのはあなたのカレンダーではなく、ホストからの信頼です。

ハーネスに永続メモリがある場合は、どのホストがどんな条件で承諾したか、合意したアクセス方針と合意した人、制限事項の一覧を記録してください。ホストとの関係は、この形式が生み出す唯一の持続的な資産であり、次回の開催で文書から再構築できない唯一のものです。

ホスト依存度の方針

どの程度アジェンダが、あなたに対する義務を負わない組織に依存しているかを示します。4つの段階があります。

• 自分たちの会場に招くホスト代表者：すでに自分たちで管理している会場にホスト側のエンジニアを招いて話してもらいます。現地訪問はありません。
• ホスト主導の単一ホスト訪問：ホストのもとを訪れ、訪問者に見せているものを案内してもらいます。
• アジェンダを交渉する単一ホスト訪問：参加者が見る必要のあるものを指定し、それに合わせてホストに準備してもらいます。
• 複数ホストを巡る行程：複数のホスト組織を順に訪問します。

価値の軸は2つあり、実際に互いに相反します。だからこそ、このメニューを順位付けする前にQ2とQ3に回答する必要があります。

• 労力（断る理由のないホストを確保し、スタッフに説明し、各サイト間を移動し、出発前に人数を確定し、各サイトで付き添いを付け、ホストが1者撤退した場合に再構築すること）：multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room
• 価値、場所 — 現地で聴衆が目にするもので、講演では再現できないもの：multi-host circuit > one host site, negotiated agenda == one host site, host-led > host representative in your own room
• 価値、適合性 — 聴衆自身の疑問に、聴衆の用語で、質問をぶつけられる相手が答えること：one host site, negotiated agenda > host representative in your own room > one host site, host-led == multi-host circuit
• コンプライアンスコスト。ホスト側で発生する審査 — 訪問者の審査、サイトの安全講習、ホスト独自の機密保持および顧客データに関する規則 — と、聴衆がホストの建物に立ち入った時点で取り消せなくなること：multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room
• 効率性、労力あたりの場所。Q2で物理的な対象が挙がったときに使う順序：one host site, host-led > one host site, negotiated agenda > multi-host circuit > host representative in your own room
• 効率性、労力あたりの適合性。Q3で具体的な技術的疑問が挙がったときに使う順序：host representative in your own room > one host site, negotiated agenda > one host site, host-led > multi-host circuit

場所の == には理由があります。ホスト主導の訪問も、交渉で決めた訪問も、聴衆を実在する1つの建物の中に案内します。そして、この軸が測るのは建物です。そこで何を見せるかは異なりますが、それはもう一方の軸が扱うことです。

適合性の == にも理由があり、しかもゼロではなく同じ水準での同等性です。聴衆が1者のホストを見る場合でも、複数者を順に見る場合でも、ホスト主導の議題はホスト主導の議題です。つまり、巡回によって場所は増えても、誰かの疑問に対する答えが良くなるわけではありません。この同等性は、割り算すると成り立たなくなります。適合性が同じで労力が明確に多いなら、適合性効率は明確に劣ります。だからこそ、この順序では巡回がホスト主導の段より下になり、同じ位置にはなりません。

ここではコンプライアンスも、労力の段階と一段ずつ対応しています。これを認め、別のシグナルであるかのように提示するのはやめましょう。どちらも、他者の組織にどれだけ深く入るか、そしてその組織がいくつあるかに応じて増加します。この軸を残すのは、実際にリスクがあるためです。ホストの審査や講習の要件はホストが決めるものであり、こちらから交渉して緩和することはできません。ただし、労力の軸がすでに示していること以外は何も区別しません。

優越性チェック：4段階、6組、厳密な優越関係はゼロ。 6組すべてを網羅するには2つの仕組みが必要で、片方だけでは半分しか網羅できません。

• 相反する価値軸によって阻まれる組（3組）： 自分たちの部屋とホスト主導、自分たちの部屋と巡回、交渉で決めた訪問と巡回。それぞれ、場所で優位な段階は適合性で劣ります。
• コストだけによって阻まれる組（3組）： 自分たちの部屋と交渉で決めた訪問、ホスト主導と交渉で決めた訪問、ホスト主導と巡回。それぞれ、優位な段階は両方の価値軸で優れており（後の2組では片方が同等）、労力とコンプライアンスのコストはそれでも明確に高くなります。

これで6組すべてを説明できます。

2つの価値軸は、互いに完全な逆ではありません。同等になる箇所が異なるため、このチェックは構造上の当然の結果ではなく、実質的な情報をもたらします。

• 1か所のホスト施設、ホスト主導 ― デフォルトです。 最小限の調整で「実際にそこにいた」という実感を得られ、ホストが誰かを集めずに承諾できる段階です。Q3で参加者の疑問が具体的で、かつQ4で同僚の時間を確保できる窓口担当者が特定された場合は、交渉する議題として優先してください。 どちらも必要で、片方だけでは不十分です。具体的な疑問があっても、社内で取り次ぐ人がいなければ、期待を込めた標準ツアーになるだけです。

• 自分たちの会議室にホストの代表者を招く。 適合性に対する効率が最も高く、コストもほとんどかかりません。Q3で疑問が技術的かつ具体的と示された場合は、これが誠実な提案です。そのようにはっきり伝え、セッションで対応できる話のために出張を計画するのではなく、このスキルをここで終えます。Q2でスライドでは見せられない実物が特定された場合は、この選択肢からも、上記のすべての軸の行からも削除してください。 講演は現場に立つことの小規模版ではありません。削除した選択肢を最下段に残すと、あとでコスト削減の手段として復活します。

• 1か所のホスト施設、交渉した議題。 ホスト側に社内オーナーを置くことを条件に、具体的な疑問に答える選択肢です。Q4で同僚の時間を確保できる窓口担当者が見つからない場合は、この選択肢からも、上記のすべての軸の行からも削除してください。 その担当者がいなければ、交渉した議題をより安く実現できるわけではありません。このメニューで最悪の組み合わせである、ホスト主導の選択肢に会議を加えたものになります。

• 複数のホストを巡る行程 ― 実質的に選ばれない選択肢です。 場所としては最上位で、コストの両軸でも最上位ですが、効率のどちらの指標でも選ばれません。優先する条件はQ9とQ8に対応し、それぞれ独自の役割があります。

  • Q9：候補となる複数のホストと継続的な関係があること。これにより、追加の訪問先への連絡が、初めての相手への打診ではなく、既存の相手への電話で済みます。
  • Q8：1か所のホストが取りやめても、その日の計画が崩れないだけの余裕があること。

  どちらの条件も同時に満たす必要があり、片方だけでは不十分です。余裕もないまま初めての相手への打診に頼る行程は、移動を予約したあとに1か所が取りやめるだけで、プログラム全体がなくなる唯一の組み合わせです。

アクセスと再現性の方針

ホストが参加者に見せるものと、その後、参加者が何を繰り返し話せるか。4段階あります。

• 公開可能：制限はありません。参加者は自由に撮影、記述、発言できます。

• 明示された基本ルール、書面なし：主催者が定めて公開し、参加者が了承するルールです。たとえば、撮影禁止エリアを指定する、個人名を挙げて発言しないなどです。誰も書面に署名しません。

• 参加者ごとの書面での誓約：各参加者が入場前に、ホストの条件に従って書面に署名します。

• ホストが管理し、主催者経由で確認：参加者は自由に見学し、あとで公開したいものがあれば、ホストがあなたを通じて確認します。

• 労力（ホストの法務部門との交渉、署名の回収、入口で拒否する人への対応、イベント後も続く行列の管理）：ホストが管理し、主催者経由で確認 > 参加者ごとの書面での誓約 > 明示された基本ルール > 公開可能

• 価値、アクセス ― ホストが実際に見せる意思のある範囲：参加者ごとの書面での誓約 > ホストが管理し、主催者経由で確認 > 明示された基本ルール > 公開可能

• 価値、持ち帰れる情報 ― 誰にも確認せずに参加者が持ち帰り、活用できるもの：公開可能 > 明示された基本ルール > 参加者ごとの書面での誓約 == ホストが管理し、主催者経由で確認

• コンプライアンスコスト（発生する確認作業と、失われる可逆性を考慮）：参加者ごとの書面での誓約 > ホストが管理し、主催者経由で確認 > 明示された基本ルール == 公開可能

• 効率、労力あたりのアクセス：明示された基本ルール > 参加者ごとの書面での誓約 > 公開可能 > ホストが管理し、主催者経由で確認

• 効率、労力あたりの持ち帰れる情報：公開可能 > 明示された基本ルール > 参加者ごとの書面での誓約 > ホストが管理し、主催者経由で確認 アクセス順序は一つの主張に基づいていますが、その主張には今も実質的な異論があります。その主張とは、ホストが何を見せるかは、参加者が入室する時点でホストが負う残余リスクの大きさに左右される、というものです。誓約書は、誰かが何かを見る「前に」その場を拘束します。それによって実際に開示の範囲が広がります。一方、事後審査の仕組みでは、一度見たものが知られてしまうことを防げないため、より厳格に感じられるにもかかわらず、開示の範囲は狭くなります。

この主張に関係する見解は二つあり、正反対の方向を指しています。

• 事前入場の文書を支持する見解。ただし、聞こえほど広い主張ではありません。 証券法では、訪問者が事前に秘密保持に同意している場合に限り、発行体は施設見学の際に重要な未公開情報を開示しても Regulation FD に抵触しません。これは事後に同等の効力を持つ仕組みがない法的許可です。このことは、事前の文書が開示を「許可」するかどうかを左右する証拠ではありますが、署名後にホストがより多く見せることの証拠ではありません。
• この順序に反対する見解であり、NDA が訪問者にもたらしたものについて記録された唯一の説明です。 工場見学の前に、撮影とソーシャルメディアへの投稿を禁じる規約に署名したエンジニアは、自分が見たものは、NDA に署名していない他の訪問者がすでに公開していた情報と何も変わらなかったと述べています。また、この合意の主な効果は、見せられたものではなく、訪問の価値に対する本人の感じ方を高めたことだとも述べています。

この順序は確定したものではなく、擁護可能なデフォルトとして扱ってください。ホストが実際に何を開示するかについての、最も直接的な証拠は逆の方向を示しています。両方の見解と、それらに併記された反例については、references/precedent-and-evidence.md をご覧ください。

要点 == は議論のあるものです。下位の二つの段階では、参加者は他者の許可なしに見たものを繰り返すことができません。違いは、許可を出す権限を誰が持つか、そしていつ出すかであり、参加者が自由かどうかではありません。

コンプライアンス == はゼロで議論されています。この軸の上位二つの段階は、どちらも文書や義務を一切生み出さないため、審査を発生させません。違いは何を話すかであり、何に署名するかではありません。

要点の効率性の軸では何も区別できないため、これを使うときはその旨を明示してください。 この軸は逆数の手間と順位が完全に一致するため、要点を手間で割っても順位は変わらず、この軸は最も安価なものを優先するだけになります。これは、順位付けが本来防ぐべき唯一の順序です。自由に繰り返せる要点が目的のすべてである場合には、これが正しい順序のままですが、誤りを見抜けないため、単独で姿勢を決めさせてはいけません。

優越性の確認：4段階、6組、厳密な優越関係はゼロです。 6組すべてを網羅するには、二つの仕組みが必要です。

• 価値軸の対立によって阻まれる組（5組）： オープンと基本ルール、オープンと誓約書、オープンと伝達された許可、基本ルールと誓約書、基本ルールと伝達された許可。それぞれ、アクセスで上位の段階は要点で下位です。
• 単一のコスト軸によって阻まれる組（1組）： 誓約書と伝達された許可。誓約書はアクセスで上位、要点では同等で、手間はより「少ない」ため、手間は優越を妨げません。妨げるのはコンプライアンスだけです。コンプライアンス軸を取り除けば、誓約書は伝達された許可を完全に優越します。

これで6組すべてを説明できます。

この確認がどれほど役立つかについて、正直に考えてください。アクセスと要点は、「テーマの性質上」ほぼ逆の関係にあります。ホストが多く見せるほど、参加者が繰り返せる内容は少なくなります。そのため、6組中5組は構造上阻まれており、この確認が情報をもたらすのは誓約書と許可の組だけです。読者が最も誤解しやすいのも、この組です。

• 担当者を明示した基本ルール――デフォルト。 会場側を安心させるのは、見知らぬ人々がそれぞれ書類に署名したことではなく、責任者として誰かが名指しされていることです。これは、確認書の作成費用のわずかな負担で会場側の協力をほぼ得られ、誰かが確認しなければならないものも生みません。 参加者が移動する前にルールを伝えてください。到着後に初めて知るルールは、プレッシャーのかかる状況で受け入れるよう求めるルールです。

• 記録を公開する。 安価で誠実であり、会場が自らのウェブサイトですでに公開している情報を示す場合には適切な対応です。Q5で、会場を代表して話す人が制限を伝えた場合は、この選択肢から、また上記のすべての軸の行から削除してください。 制限区域のある施設で記録公開の方針を掲げるのは、貸切バスが出発する前に破っているルールです。一番下に置いておくと、「波風を立てないようにしましょう」という話に戻ってしまいます。

• 参加者ごとの書面による誓約――出番の少ない段階。 アクセスとコンプライアンスの面では最上位で、労力の面では、仲介された許可に次いで2番目です。そのため、まとめの文では選ばれず、アクセスに関する文でも基本ルールが機能しなかった場合に限って選ばれます。適用条件はQ6とQ1にひも付けられ、それぞれ独自の重みを持ちます。

  • Q6：当日より前に確定している、範囲の限定された参加者リスト。ドアが開く時点でまだ確定していないリストをもとに署名を集めるのは、方針の問題ではなく、ドアでの対応の失敗です。
  • Q1：会場側の承諾に、これが条件として付いていたこと。

  どちらか一方だけではなく、両方の条件を満たす必要があります。どのような書面にするかは弁護士が決めることであり、このスキルでは指定しません。

• 会場側が管理し、主催者が仲介する許可。 イベント終了後も費用が発生し続ける唯一の段階です。Q7で、申請の受付を担当する人がいない、または申請が届く頃には担当を続けていない人が挙げられた場合は、この選択肢から、また上記のすべての軸の行から削除してください。 許可申請の受付が機能しないのは、会場側への約束を破ることと、参加者が書いたレポートが公開されず、誰も催促できないまま放置されることという、2つの失敗が同時に起きることです。

失敗パターン

• ホストが承諾する前日に企画すること。 Q1 はこれを防ぐためにあります。ホストがいない状態でフォーマットを決めるのは、フォーマット同士を比較して選ぶことになります。この判断は samber/dev-event-organizer-skills@business-event-formats が担当します。
• ホストを会場のように扱うこと。 会場が使えなくなっても、再予約する部屋が必要になるだけです。ホストがいなくなると、プログラムそのものがなくなります。ホスト こそが プログラムだったからです。 この違いを日程やデポジットに関するあらゆる判断に反映し、samber/dev-event-organizer-skills@event-venue-sourcing の「複数の会場と複数の日程を組み合わせて検討する」仕組みを決して流用しないでください。2人目のホストは1人目の代わりにはなりません。別のイベントです。
• ホストが明示していない制限を想定すること。 自分たちで秘密扱いにしてしまうことは、遠征で何も活用できる成果が得られない最もよくある原因です。Q5 で制限を誰が設けたのかを尋ねるのは、たいていの答えが「こちらでそう想定しました」だからです。
• 制限がないと思い込むこと。 これはその裏返しの失敗であり、より大きな損失につながります。samber/dev-event-organizer-skills@event-content-repurposing の権利確認には、そのためのルールがあります。 「何も言われていない場合は、許可ではなく禁止です。」
• ホストのマーケティングチームにアジェンダを書かせること。 ホスト主導の訪問が製品デモになってしまえば、ウェビナーを見るために足を運ぶことになり、参加者の時間を無駄にします。ブリーフの段階で、参加者が何を理解するために来るのかを明記し、その文に照らしてアジェンダを確認してください。
• 交通手段、ケータリング、または拠点ごとの要件シートをここで再検討すること。 この3つにはいずれもスコープの節に担当者が記載されています。また、どれもこのスキルで説明できる内容より、担当者のもとで扱うほうが適切です。
• 車両を忘れること。 スコープ条項には車両を明記する必要があります。samber/dev-event-organizer-skills@event-code-of-conduct の参照ファイルには、その理由が記されています。 「シャトルは会場でも、社交イベントでもありません」
• 数値を作り出すこと。 拠点数、グループの人数、準備期間、ホストの承認にかかる期間は、すべてホストが決めるものであり、あるホストの値を別のホストに一般化することはできません。ホストに確認し、その回答をホストの回答として記録してください。

測定

以下の各基準は外部のベンチマークではなく、すべて独自に設定したものです。提示する際は、そのことを明記してください。イベント全体の成否は samber/dev-event-organizer-skills@corporate-event-strategy の担当です。

合格基準（構造上の基準は1つのみ）： 参加者に行き先を伝える前に、以下の4項目すべてが空欄なく書面で揃っていること。

• ホストの承諾、およびそれに付随する条件。
• ホスト側の担当者として指名された人。
• アクセスに関する方針と、その方針の根拠となった制限事項の一覧。
• 参加者が後日何かを公開したい場合の対応担当者。

4項目が揃うまで改善を続けてください。どれか1つでも空欄があれば、それこそがこのスキルで検出する失敗です。

イベント後に記録する価値のある指標（すべて独自に設定）：

• ホストが撤回したかどうか、および撤回の予告期間。
• 実施したアジェンダが送付したブリーフと一致していたかどうか。
• 何人の参加者が何かを公開したいと申し出たか、および各人の待ち時間。
• ホストが再び受け入れてくれるかどうか。

最後の項目だけが、積み重ねることで意味を増す指標であり、誰も記録に残さない指標です。

呼び出し例

• 「イベント開始前に、カンファレンスの参加者をハイパースケーラーのデータセンターに案内したいのですが、どのように構成すればよいですか？」
• 「あるハードウェア企業から、コミュニティ向けの工場見学を受け入れると提案されました。承諾する前に、何を合意しておく必要がありますか？」
• 「参加者は、大規模なエンジニアリング組織が実際にどのように CI を運用しているのか見たいそうです。見学に行くべきでしょうか。それとも、その組織の人に登壇してもらうだけでよいでしょうか？」
• 「ホストから、入場前に全員に何かへ署名するよう求められています。これは一般的ですか。また、こちらにどのような負担が生じますか？」
• 「参加者は、サイト訪問で見たことをブログに書いてもよいのでしょうか？」

期待される出力：次の内容を含む視察概要書。

1. 振り分けリスト — リクエスト内で他のスキルに該当する項目と、そのスキル名すべて。
2. ホスト依存に関する方針。削除した段階と、それぞれを除外した理由を記載します。
3. アクセスと再現性に関する方針。その根拠となった制限事項の一覧も記載します。
4. ホスト向けの概要書。
5. 明示的な引き継ぎ事項。
6. 各選択について、その判断を覆す面談での回答。

ホストに何かを約束する前に、検証のため各セクションを個別に提示します。

参考資料

• references/precedent-and-evidence.md — ホスト先でのプログラムを実施したことが記録されている唯一の技術カンファレンス、同じ名称だがこのスキルの対象ではない形式、アクセス順序をめぐる賛否両方の根拠、ならびに、名称が挙げられた視察ツアー運営事業者が公表しているグループ規模、訪問先数、準備期間の範囲について確認してください。

コレクション内の他のスキルへの主な引き継ぎ先：

• samber/dev-event-organizer-skills@business-event-formats — この形式そのものが適切かどうか、また「エグゼクティブ・イマーシブ」と言う人が求めるアカウント深掘りの形式群。
• samber/dev-event-organizer-skills@event-code-of-conduct — ホストの敷地と移動手段を明記する必要がある適用範囲の条項。
• samber/dev-event-organizer-skills@event-hospitality — 交通手段、ケータリングのサービス形式、修正できない参加人数、そして訪問がプログラムではなく交流目的の場合の、会場外での夕方のイベント。
• samber/dev-event-organizer-skills@event-vendor-sourcing — 一緒に移動するあらゆる業者との契約。
• samber/dev-event-organizer-skills@event-production — 何かを記録する場合の、収録から公開済みマスターまで。
• samber/dev-event-organizer-skills@corporate-event-strategy — 目標、資金調達、イベントの測定対象として確約する内容。

上記の適用範囲セクションでは、会場要件、コンテンツの権利、VIP ゲスト、報道関係への対応に関する、さらに別の関連スキルへの振り分けを示しています。振り分けリストの全容はそちらを確認してください。