event-team-structure

イベントチームの構成

カンファレンス、ミートアップ、ハッカソンなど、定期開催される技術イベントを支える常設チームの組織設計を行います。各回の開催の_間_に存在する体制、すなわち、誰がどの権限を持つのか、新しいオーガナイザーがどのように加わるのか、リーダーがどのように引き継ぐのか、そしてボランティアの活動を有償の仕事に切り替えるべきタイミングを設計します。初回開催のチーム編成を再検討することはありません（それは samber/dev-event-organizer-skills@event-first-edition の担当です）。開催当日のボランティア要員の計画も行いません。

以下の既定値の大部分を左右する比較事例があります。DjangoCon US と DjangoCon Europe は同じ親財団のもとにありながら、正反対の設計を選びました。US は常設の法人を維持し、Europe は開催回ごとに新たな主催チームを立ち上げました。そして、常設法人の設計のほうが、実証的に見てもより安定していることが分かりました。事例の全記録は参考資料にあります。

コミュニティ主催と企業主催

イベントの所有者によって、選択肢は変わります（同じ区分は samber/dev-event-organizer-skills@event-market-fit と samber/dev-event-organizer-skills@event-growth-strategy でも使われています）。

• コミュニティ主催 - ボランティアが主導し、チケットとスポンサーから資金を得ます。以下の選択肢はすべてそのまま適用され、説明されている実践もこのタイプに基づいています。
• 企業主催 - イベントはマーケティング施策であり、企業が法人、予算の所有者、雇用主です。法人に関する選択肢はなくなり、有償雇用への移行条件は人員枠の申請になります。一方、意思決定権、役割の分類、後継者育成、燃え尽きに関する内容は、社内チームにも引き続き当てはまります。戦略面（目標、予算の所有者、成功指標）は samber/dev-event-organizer-skills@corporate-event-strategy に委ねてください。

ハイブリッド型も一般的であり、正当な形です。主催者に、有償の勤務時間を使ってイベント運営に携わる企業の従業員が含まれるコミュニティ主催のイベントが該当します。雇用主の利害が異なる場合、それを参加の妨げとせず、管理すべき緊張関係として明示してください（後継者育成と燃え尽きに関する参考資料を参照）。主催者自身の商業的利益、たとえばフリーランスのサービス、スタートアップ、製品も、同じ緊張関係をさらに身近なものにした例です。以下の利益相反条項は、どちらにも適用されます。

ヒアリング

一度に質問するのは1つだけにし、できるだけ選択式にします。以下のメニューは効果が出るまでの時間、持続性、労力に大きな違いがあるため、質問7～9を設けています。デフォルトをユーザーに代わって選ぶことはできません。

1. これまでに何回開催し、参加者数はどのくらいで、予算はおおよそいくらでしたか？（規模によって、組織形態の選択肢と有給スタッフ採用の判断基準が変わります。）
2. コミュニティ主催ですか、それとも企業主催ですか？コミュニティ主催の場合、主催者の中に、雇用主から給与が支払われる勤務時間にイベントに取り組んでいる人はいますか？
3. 現在のチーム体制を教えてください。何人いて、どの役割に担当者が決まっており、どの役割が「誰かが引き受けたら担当する」状態ですか？
4. あなたも含め、担当者が決まっている各役割について、その人が明日いなくなった場合、次回の開催でその担当領域を引き継げる人はいますか？（これは代替要員の把握であり、このスキルの中核となる診断項目です。）
5. 現在、イベントはどのような法的形態で運営されていますか？何もない（契約を個人名義で締結）、傘下組織または財政スポンサーがある、あるいは独自の法人を設立している、のいずれですか？
6. あなた自身と各リードにとって、運営は今も楽しいですか？（一人ずつ直接尋ねてください。）どこかで「いいえ」という回答があれば、それは気分の問題ではなく、構造上の兆候です。
7. 構造を変更しなければならない期限はありますか？次の会場契約の前に法人が必要、あるいはリードの誰かが担当する最後の開催が迫っている、といった事情はありますか？（期限が近ければ、法人設立や人材育成の仕組みよりも、二人体制のルールや運営規約といった、すぐに実施できる段階を優先します。）
8. 次回の開催に向けた一時的な対応ですか、それとも複数年にわたる組織の恒久的な設計ですか？（長期的に積み上げていくことが目的なら、独自法人の設立や貢献者を育成する仕組みといった、時間のかかる段階を優先します。）
9. 労力の上限はどの程度ですか？主催者が費やせる時間、法的書類作成への許容度、業者への依頼や初めての採用に使える予算を教えてください。また、デフォルトでは考慮されない資産はありますか？たとえば、傘下に入れる親財団、メンターになってくれる過去の主催者、すでにリードのように活動しているボランティアなどです。
10. イベントは一つの単位として運営されていますか？それとも、それぞれ独自のCFPを持つ並行トラックや複数の都市で運営されていますか？また、コミュニティは、独立した地域コミュニティによる任意のネットワークに参加していますか、または参加を検討していますか？（後半の質問に「はい」と答えた場合、以下のピアネットワークのセクションに進みます。）
11. あなた自身も含め、各主催者は運営を通じて何を得ていますか？サービスの見込み客、人脈、学び、孤立感の軽減、楽しさなどです。対象者に商業的な利害関係を持つ人はいますか？（回答は、燃え尽き防止のガードレールと利益相反条項に反映されます。）

ワークフロー

1. インタビューを実施してから、組織図ではなく、誰が何を決め、誰が誰を支えているのかという、実際に機能している現在の体制を描きます。両者の食い違いが、通常は発見事項になります。
2. まず法人のあり方を決めます（下のメニューを参照）。意思決定権限、採用、財務の継続性はすべて、法的に誰がお金を保有し、契約に署名できるかにかかっています。法人のあり方を決める前に体制の形を決めても、砂上の楼閣になります。
3. 意思決定権限の形を選びます（下のメニューを参照）。常設層が担う決定（資金、契約、法務、CoC のエスカレーション）と、運営チームが担う決定（プログラム、ロジスティクス）を書き分けます。これは、持続可能なイベントに共通するパターンです。Q10 で独立したコミュニティによる自発的なネットワークが示された場合は、下記のピアネットワークのセクションに沿ってネットワーク層を別途設計し、イベント自体の体制に組み込まないでください。
4. 常設の役割分類を整えます。プログラム、スポンサーシップ、財務、ロジスティクス／会場、マーケティング、ボランティアの各機能リードに加え、CoC チームを設けます。各役割について、明確な境界、つまり、その役割が「引き受けない」ことを明記した1段落の役割範囲を作成します。企業の組織設計を参考にした妥当性チェックとして、構造にもう1層必要になる前に、調整層が担当するリードの数はおよそ5～8人です。イベント規模ごとに見られるチーム人数はガバナンスのリファレンスに記載されています。samber/dev-event-organizer-skills@event-planning-timeline のトラッカーで、すべての計画タスクのタグフィールドに使われているものと同じラベルセットを使います。タスクと担当リードには共通の用語を使い、誰かが別の命名体系から読み替える必要がないようにします。同じ作業で、下記のセクションにある利益相反条項を憲章に追加します。
5. 下記の優先順位付きメカニズムを基に、インタビューの Q4 で作成したバス係数マップから後継者計画を策定します。バス係数が1の役割は、特にリードも含めて、いつかではなく今回の開催で対策を講じます。
6. バーンアウトを防ぐガードレールを設けます（下記のセクションを参照）。これはウェルネスの助言ではなく、バックアップ、境界、作業負荷の上限、実効性のある年次確認を含む体制です。
7. 公表済みの基準に照らして、有償採用のゲートを実施します（下のメニューを参照）。これは一度きりの判断ではなく、毎回の開催で繰り返し適用するゲートです。
8. チームの意見が実際に分かれた場合（法人化するかアンブレラ組織に加わるか、交代制にするか継続するかなど）は、提案の前にブレインストーミングモードに入ります。トレードオフと推奨案を含む候補設計を2～3案提示し、質問は一度に1つずつ行い、セクションごとに設計の妥当性を確認します。フレームワークの出力を黙って提示してはいけません。
9. 常設チームの設計を提示し（「評価」の下にある体制）、明示した周期で見直します。EuroPython Society は、負荷のバランスを整えるため、設立から7年後に自らの体制を再編しました。ガバナンス設計は見直し可能な成果物であり、創設時に定めて変更しない憲章ではありません。

ハーネスに永続メモリがある場合は、以下を記録します。

• 選択した法人のあり方と意思決定権限の形、および却下した選択肢。
• 役割憲章と、利益相反の登録簿。
• バス係数マップ、各対策と担当者、各オーガナイザーが明示した復帰時期。
• ピアネットワークのメンバーについては、マニフェスト、会員条件、共有資産とその所有者。
• 有償採用ゲートの判定と、その根拠となった基準の証拠。
• 各開催におけるチームの健全性に関する回答。

次回開催のレビューは、今回のイベント固有の履歴を出発点とします。

法人の位置づけ

順位付け（既定の順位であり、法則ではありません）。インタビューを踏まえて順位を付け直します。

• 契約締結の期限が迫っている場合は、期限内の法人化よりアンブレラ方式を優先します。

• すでに所属している親財団があれば、アンブレラ方式の負担はほぼゼロです。

• 複数年にわたる機関の委任がある場合は、自前の法人を優先します。

• 労力：own non-profit entity > fiscal sponsorship / umbrella > no entity

• 価値（契約能力、財務の継続性、運営者の責任を保護する仕組み、運営者が交代しても存続すること）：own non-profit entity > fiscal sponsorship / umbrella > no entity

• 効率性：fiscal sponsorship / umbrella > no entity > own non-profit entity

• コンプライアンスコスト（審査が発生し、取り消し可能性が失われる）：own non-profit entity > fiscal sponsorship / umbrella > no entity - 法人化すると、定款、理事の受託者責任、年次提出書類、解消が難しい組織構造が必要になります。アンブレラ方式では、スポンサーとの契約や方針に拘束されます。「法人なし」では審査は発生しませんが、リスクは個人に移り、契約や責任は署名者が負います。

優越性の確認：3組の比較で、厳密な優越関係はゼロです。構造上そうなるよう設計されているだけで、それは合格を意味しません。 価値、労力、コンプライアンスコストはすべて同じ順位なので、すべての組み合わせで一つの仕組みが判断を妨げます。価値で上位の選択肢は、両方のコスト軸でも必ずより高コストであり、価値が同等以上でありながらコストが低い選択肢はありません。この確認では何も判定できません。順位付けの根拠は、以下に示す各段階の個別の論拠です。

• 法人なし - 契約がなく、資金がほぼゼロのミートアップ規模でのみ既定の選択肢となります。会場契約や5桁の資金の流れが発生した時点で、この姿勢はもはや低コストではありません。書類手続きをゼロに見せかけた、個人へのリスクです。最初の契約に署名する時点で、上の段階に移行してください。
• 財政スポンサーシップ／アンブレラ方式 - カンファレンスでの既定の段階です。親財団または財政スポンサーが資金を管理し、契約に署名し、あなたは運営を担います。DjangoCon Europeはこの方式で運営されています（Django Software Foundationが各開催回のチームにライセンスを付与します）。アンブレラ方式によってイベント自体は存続できますが、記録に残る開催地募集の苦労が示すように、それだけでチームの継続性が解決するわけではありません。アンブレラの条件に制約される場合、適切なスポンサーがいない場合、または機関からの委任が明確にある場合は、上の段階に移行してください。
• 自前の非営利法人 - 選ばれにくい選択肢です。価値は最も高いものの、効率性ではすべての比較で劣り、メニュー全体のコンプライアンスコストを負います。DjangoCon USとの比較を踏まえると、ボランティアの議長が交代しても存続する常設の501(c)(3)相当の法人とその理事会は、実証的により安定した設計です。イベントを創設者である運営者の後も存続させる意図がある場合は、この選択肢を優先してください。法人を設立した後の継続性の基準は、開催回を1回まるごと失った場合にも耐えられる規模の準備金です。

会社が運営するイベントでは、3段階すべてを格下げするのではなく削除してください。 メニュー全体とその軸の行を削除します。会社自体がすでに法人であり、選択肢を比較すると、すでに存在する法的主体の隣にボランティア主体の組織構造が再び現れるおそれがあります。意思決定権に進んでください。

意思決定権の構造

順位（デフォルトであり、絶対的な法則ではありません）。インタビューを踏まえて順位を付け直してください。

• 真に複数都市にまたがるイベント、またはフランチャイズ型のイベントでは、連邦型が優位になります。

• 小規模な単一ユニットでは、合意形成型を維持します。

• 順位は、分割型に収束する、長く続くイベントに基づいています。

• 労力（設営と調整）：理事会と運営チームの分割 > ドメインリード型連邦制 > 合意形成型委員会

• 価値（規模拡大に対する持続性。参加者300人から12,000人以上のイベントまで）：理事会と運営チームの分割 > ドメインリード型連邦制 > 合意形成型委員会

• 効率性：合意形成型委員会 > ドメインリード型連邦制 > 理事会と運営チームの分割

優越性チェック：3組、厳密な優越関係はゼロ――構成上は問題ありませんが、それは合格を意味しません。 価値と労力の順位は同じなので、3組すべてが同じ理由で不合格になります。持続性で上位の選択肢は、設営と調整に確実により多くのコストがかかります。それを覆す第3の軸は示されていません。

効率性の順位は、以下の論拠に基づくものであり、チェックに合格した結果ではありません。

• 合意形成型委員会 — 効率性で最も優れており、予算の線引きより下では適切なデフォルトです。単一の小規模チーム（およそ5人以下、ミートアップ1件、トラック1つ）が、役割の階層を設けずに全員で意思決定します。ただし、限界は明らかです。契約を担う人がおらず、すべての決定にグループ全体の注意が必要です。
• ドメインリード型連邦制 — 各担当領域（プログラム、スポンサー、A/Vなど）で実質的な権限を持つリードを置き、中央での調整は軽くします。公表されている最も純粋な事例は、明示的なフランチャイズとして運営されるカンファレンスブランドです。現地チームは完全に自律し、中央にいるメンター兼運営者1人だけが最低限のガードレールを担います。昇格条件はQ10に対応します。イベントが実際に複数のユニットで構成されていること、つまり独自のCFPを持つ並行トラックがある、または複数の都市で開催されることです。
• 理事会と運営チームの分割 — 選択肢として十分に検討されておらず、イベントが資金、契約、商標を扱う時点でデフォルトとなる構造です。常設の理事会／スタッフ層が予算、契約、法務、行動規範（CoC）のエスカレーションを担い、運営チームがプログラムとロジスティクスを担います。最も労力がかかり、効率性では最下位ですが、5つの独立した組織すべてで、大規模かつ持続的なイベントが最終的に収束した構造です。継続開催のカンファレンスでは、昇格条件をほぼすぐに満たします。効率性の順位に昇格を遅らせず、そのことを明記してください。

この3つは組織の階層を表しています。一方、チームが「誰に影響力を与えるか」（創設者の権限、役割に基づく権限、現在の活動状況）を議論している場合は、後継者選定の参考資料にある、オープンソースのガバナンスから借用したリーダー選定の視点を使ってください。借用した視点であることを明記し、イベント業界の事実として扱わないでください。

独立コミュニティのピアネットワーク

上記のメニューとは別に、複数の独立した地域コミュニティが協力する、3つ目の複数ユニット型があります。多くの場合、1つのテーマを複数の都市で展開し、協力することを選びます。ブランドの所有者も、ライセンスも、拒否権を持つメンターもいません。これはドメイン主導の連合体（1つのイベント）でも、フランチャイズ（ライセンスされた1つのブランド）でもありません。見分ける基準は、あるチャプターが明日離脱しても、自分たちの名前をそのまま使えるかどうかです。使えるなら、それはピアネットワークです。

ネットワーク層は、次の順序で設計してください。

1. 共有する短いマニフェストを書く ― ビジョンと価値観を共有し、実施方法は地域に任せます。規模、手段、背景は都市ごとに異なります。2分で読める長さにしてください。それより長いものは、フランチャイズ契約を別の形で表したものです。
2. 参加を任意とし、書面での脱退手順を定める ― 脱退するチャプターが保持するもの（名前、リスト、資金）と、返還するもの（共有ツールへのアクセス）を明確にします。
3. 最低限の拘束力あるルールを定める ― すべてのメンバーが自ら設定し、守るべき少数の約束です。候補として、マニフェストの価値観、担当チームを明記したチャプターごとの行動規範、後述の利益相反条項があります。
4. まず共有する資産を2～3個選び、それぞれに担当者を置く ― 報告されたメニューから、優れたトークのフレームワーク、スピーカー向けコーチング、スピーカーバンク、ピッチバンク、共通ツール上の会場バンク、イベント形式ごとのプレイブック、ワーキンググループ、コミュニケーションの自動化などを選びます。
5. 地域ごとの KPI とネットワーク全体の KPI を分ける ― それぞれ2～3個に絞り、すべてに担当者と、それを前進させるアクションを設定します。候補を絞る方法は samber/dev-event-organizer-skills@event-continuous-improvement に記載されています。
6. 決定しない限り共有しないものを列挙する ― 資金、ブランドの使用、参加者リストなどです。これらはそれぞれ、開始前に決定を記録する必要があります。
7. ネットワークレベルで法的組織形態の問題に答える ― ネットワークについて、各チャプターとは別に、上記の組織形態メニューを検討します。報告された課題は、地域の活力を損なわずに資源を相互共有することです。資源を共有しない間は、ネットワーク組織を設けないのがデフォルトです。
8. 地域の連携役を確保する計画を立てる ― 報告された課題として最も多かったのは、共同主催者を見つけることでした。ある単独の主催者は4～6人の連携役を求めていました。また、ハッカソンやミートアップの終了時に公開で協力を呼びかけたところ、その場で新たな主催者を獲得できた例もあります。バス係数のマップを参考に、独自の連携役の目標を設定してください。

共有資産の表、マニフェストのテンプレート、メンバーシップの条件、法的組織形態のトレードオフについては、references/peer-network-and-organizer-incentives.md を参照してください。

利益相反条項

規約では現在、雇用主の利益を扱っています。これを、すべての主催者自身の商業的利益にまで広げてください。

• 参加者同士のビジネスを歓迎する ― 採用、フリーランス、パートナーシップを歓迎し、イベントがそれらを促進することもできます。
• 自己の見込み客開拓を動機とすることを禁じる ― 主催者は、主に自分自身の見込み客を開拓するためにイベントを運営しません。
• 創設時の文書に明記する：「ビジネスは結果であり、目標ではない」。この考え方は、ステージ上での商用デモを禁止するピアネットワークのマニフェストにも適しています。
• 開示する ― 各主催者は、雇用主、自社またはフリーランスのサービス、スポンサーとの関係を、チームが閲覧できる登録簿に記載します。
• 議決から外れる ― 自分自身のトーク、雇用主のトークやスポンサーシップ、自分が利害関係を持つベンダーに関する決定には関与しません。
• 独立性を保つ ― コミュニティを特定の1社に結び付けません。

開示された見込み客獲得の利益は正当なものです。開示されていない利益こそ、この条項によって明らかにすべき利益相反です。

後継者の確保方法

ランキング（デフォルトであり、絶対的なルールではありません）。インタビューの内容を踏まえて順位を調整してください。

• 退任するリードの最終担当回が決まっている場合は、育成した後継者への引き継ぎを最優先にします。

• 有給スタッフやしっかりした理事会がいるイベントでは、長期在任の代わりに計画的な交代を選べる場合があります。

• 労力：貢献者から意思決定者へのパイプライン > 計画的なリーダー交代 > 6～12か月かけた育成型の引き継ぎ > 文書化された規約＋共有管理者アクセス > 2人配置ルール

• 価値（継続性の保護）：貢献者から意思決定者へのパイプライン > 計画的なリーダー交代 > 6～12か月かけた育成型の引き継ぎ > 2人配置ルール > 文書化された規約＋共有管理者アクセス

• 効率：2人配置ルール > 文書化された規約＋共有管理者アクセス > 6～12か月かけた育成型の引き継ぎ > 計画的なリーダー交代 > 貢献者から意思決定者へのパイプライン

• 2人配置ルール - デフォルトの方法です。名前の付いたすべての役割に、次回開催時にその領域を担当できるバックアップを明記します。FOSDEMでは、問題発生時に備えてバックアップを確保するため、各開発ルームにマネージャーを2人配置しています。労力はほぼゼロです。今週実施しましょう。

• 文書化された規約＋共有管理者アクセス - 役割、担当範囲、参加経路、意思決定権を文書にまとめ、すべてのアカウント、ドメイン、ソーシャルメディアを個人所有から移行し、少なくとも1人のバックアップ管理者を設定します。複数のイベントを運営する組織では、すべてを1つの共有受信箱にまとめるのではなく、連絡先を2層に分けます。組織自身の継続的な業務と共有ツールには常設のチーム用アドレスを使い、イベント固有の広報にはイベントごとの別アドレスを使い、そこに各主催者のエイリアスを設定します。すべてのイベントのメールも受信する共有アドレスは、この段階で取り除こうとしている、担当者1人に依存するリスクそのものを、受信箱に移しただけです。透明性についての議論も同様です。閉鎖的に見えるリーダーシップは、その正当性を支える敬意を寄せるテックコミュニティの人々に、派閥のように映ります。

• 6～12か月かけた育成型の引き継ぎ - 活動中のボランティアから後継者を選び、期間を明確に定めて引き継ぎます。6～12か月という目安は、ミートアップ主催者への調査に基づいています。ミートアップ規模では、リードがこの期間で燃え尽きるため、ほぼ必須です。

• 計画的なリーダー交代 - 期間を定めたリードの役割を、設計上の仕組みとして交代させます。適用するなら、組織の知見を保持する常設の継続性レイヤー（理事会またはスタッフ）の上でのみ機能します。KubeConでは、財団スタッフのもとで、有給の共同議長を開催回ごとに交代させています。このレイヤーなしで交代制を導入したのが、DjangoCon Europeの事例です。チーム全体を交代させた結果、開催地の募集で繰り返し問題が発生しました。

• 貢献者から意思決定者へのパイプライン - 活用が進んでいない選択肢です。活動中の貢献者が年ごとに投票権を獲得できる、常設の段階的な仕組みを設けます。最も価値が高い方法です。将来のリーダーを継続的に育成しますが、運営するための常設の仕組みも必要です。開催地やリーダーの交代がある複数年にわたる組織には、この方法を推奨してください。EuroPython Societyは、開催地の変更で組織の知見を失った後、まさにこの仕組みを構築しました。

常設の継続性レイヤーがない場合は、計画的なリーダー交代を順位を下げるのではなく、選択肢から削除してください - 組織の知見を保持する理事会もスタッフも、財政スポンサーもいない場合です。選択肢の一覧からも、上の軸の記述からも削除してください。これはパイプラインの低コスト版ではありません。DjangoConの比較で敗れた側の方法であり、交代のたびに前のチームの知見が失われ、1年後には開催地の募集に失敗します。

一覧の末尾に置くだけでは公平な選択肢に見え、公平性を理由に採用されてしまいます。

オンボーディングのヒントは、MLHの主催者向けガイドからです。新しい主催者を迎える際は、参加者向けに検討中のミニイベントをチームビルディングの演習として実施しましょう。

少しずつではなく、突然大勢が加わることを想定してオンボーディングを計画してください。あるチームは、運営担当者1人から約15人にまで増えました。新しいメンバーが来る前に役割一覧を作成し、新メンバー1人につき既存の主催者を1人割り当て、期限付きで範囲を限定した最初のタスクを任せてから、担当者不在リスクのマップを再作成してください。チェックリストは、ピアネットワークのリファレンスを参照してください。

有給雇用の判定基準

順位（デフォルトであり、絶対的な規則ではありません）。面接の内容に照らして順位を付け直してください。

• 6桁の予算があり、チームが疲弊している場合は、より安価な段階を飛ばして雇用を優先します。

• 資金がない場合、選択肢は体制の再編だけです。

• 労力：有給スタッフを雇用する > ベンダーに外注する > ボランティアを続けて体制を再編する

• 価値（年間を通じた計画の負担を軽減し、組織の継続性を確保する）：有給スタッフを雇用する > ベンダーに外注する > ボランティアを続けて体制を再編する

• 効率：ベンダーに外注する > ボランティアを続けて体制を再編する > 有給スタッフを雇用する

• コンプライアンスコスト：有給スタッフを雇用する > ベンダーに外注する > ボランティアを続けて体制を再編する - 雇用契約または委託契約の審査と、継続的な雇用主としての義務が発生します。ベンダー契約の場合はそれらより少なく、新たな契約がなければ何も発生しません。

優越性チェック：3組を比較し、厳密な優越関係は0件です。構造上のみ問題がない状態であり、これで合格とはなりません。 価値、労力、コンプライアンスコストはいずれも同じ順序になっているため、単一の仕組みがすべての組み合わせを阻みます。より多くの負担を軽減する段階は、両方のコスト軸で厳密に劣ります。コンプライアンスコストは労力の順序をそのまま繰り返しているだけで、順位を変えないため、こちらも何も解決しません。

以下の比率を根拠に議論してください。チェックでは、どの比率も確認できていません。

• ボランティアを続けて体制を再編する - 基準未満の場合のデフォルトです。負荷を再配分し、後継者育成の選択肢を活用し、雇用に至らない資金面の手段（謝礼、費用の補填）を使います。参加者500人未満のイベントは、常にボランティア運営を続けます。
• ベンダーに外注する - 文書で確認された中間案です。誰も雇用せず、ボランティアの理事会がプロのイベント管理やホテルとの契約業務を依頼します。課題が組織の継続性ではなく、実行能力にある場合は、この案を優先してください。
• 有給スタッフを雇用する - 十分な資金が与えられていない選択肢ですが、公表されている基準では優先されます。参加者がおおむね数千人規模、または6桁の予算があり、イベント運営が年間を通じた負担になっている場合です。記録された事例では、大規模な組織が代わりに上級のエグゼクティブディレクターを雇用した1件を除き、最初の採用はすべてイベントコーディネーター／マネージャーです。EuroPythonではまずパートタイムで採用されており、コミュニティマネージャーを採用した事例はありません。採用後も、プログラムとコミュニティのリーダーシップはボランティアが担います。この判定基準で雇用が決まったら、samber/dev-event-organizer-skills@dev-event-hiringが評価基準、求人票、面接プロセスを作成します。このスキルの役割は、判定までです。

Q9でベンダーへの依頼も採用も資金的に不可能とわかった場合は、有給雇用の2つの選択肢を降格するのではなく、削除してください。 上記の選択肢メニューと各軸の説明から削除します。その場合、体制の再編だけが選択肢となり、それを正直に伝えることが答えです。

予算のないチームの計画に採用案を残しておくと、誰も計画していない資金調達プロジェクトとして持ち上がり、その間も、軽減するはずだった負荷はそのまま残ります。

この判定基準の背景にある適性テストは、スタートアップの人員配置から借用したものです。スポンサーとの関係、財務の継続性、認証情報の管理など、開催回をまたいで組織の知識を引き継ぐ役割は、無給かつ不安定な状態に置くと大きく損なわれます。一方、短期的な専門業務は、ボランティアが担うか、ベンダーに委託します。

バーンアウトを防ぐ仕組み

ここでいうバーンアウトは、ウェルネスの問題ではなく、組織構造の問題です。構造がバーンアウトを無視した結果、イベントが 終了してきた からです。参加者1,600人のカンファレンスでは、6人の中心運営者が責任を持って担い続けられなくなった業務が、閉会の挨拶で具体的に列挙されました。また、愛されていたコミュニティカンファレンスは、チームが疲弊した年に幕を閉じました。入手できる最良の調査データでは、およそ3分の1のミートアップグループが1人の運営者だけで成り立っています。つまり、小規模な場合には、バス係数1が 通常の状態 です。

以下を、常設の仕組みとして導入してください。

1. バックアップのいない役割を設けない（上記の2人配置ルール）。「一人で働く」ことは、孤立も含め、構造上バーンアウトの原因になります。
2. 役割の境界を文書化する。各リードの職務範囲には、その役割が引き受けない業務を明記します。「複数人分の仕事をこなす」は、見逃してはならない過剰な引き受けのパターンです。
3. 運営者ごとの業務時間の上限を定め、年に一度見直します。ミートアップ規模で公表されている目安は月4～8時間です。構造的に上限を超える役割は、担当者を鼓舞するのではなく、分割すべき役割です。
4. 毎年、各人を対象に、実効性のある「楽しさの確認」を行います。「運営は今も楽しいですか？」という問いに「いいえ」と答えた場合は、構造的な対応を取ります。範囲を縮小する、バックアップを加える、担当者に1回分の開催を交代してもらう、といった対応を、その回で実施してください。共感を示すだけでは不十分です。（samber/dev-event-organizer-skills@event-growth-strategyでは、同じ兆候を成長戦略の見直し基準として扱っています。この2つのスキルは、同じ指標を読み取っています。）
5. 前向きなフィードバックを意識的に称え、共有します。満足していても何も言わない参加者と、不満を大きな声で訴える参加者がいることで、運営者が感じる自分たちの影響力は偏ってしまいます。
6. 運営者一人ひとりが得ているものを明らかにします（インタビューQ11）。運営者が続けた理由には、フリーランス案件の紹介がありました。人目に触れるミートアップは、サービスを提供する人にとって大きな集客チャネルです。そのほか、ネットワーク、学び、孤立の軽減、楽しさも理由でした。バス係数の一覧に、各人が得ているものも記録してください。その価値が失われた場合（転職や、紹介を必要としなくなった顧客基盤など）は、早期に離れる兆候です。利益相反に関する条項に従う限り、案件獲得を目的とすることは正当な動機です。

事例の引用全文、調査の限界、オープンソースの類似事例については、後継者育成とバーンアウトに関する参考資料をご覧ください。

失敗パターン

• リード担当者が1人しかいない状態。 すべてが創設者を通じて進みます。調査では、ミートアップグループのおよそ3分の1がこの状態にあることが示されており、上記の解散事例はいずれもこの状態を経ていました。バスファクターマップ（インタビューQ4）は、担当者が離れる前にこの状態を把握するためのものです。
• すべてを交代制にすること。 固定の継続担当層を設けずにチーム全体を交代制にするのが、DjangoCon Europeの方式です。その結果、開催担当者の募集に繰り返し失敗し、あるチームは3回連続で開催を担い、後になって知識の穴を埋めることになりました。継続性を保つ層の_上に_交代制を設けるのは問題ありません。継続性を保つ層の_代わりに_交代制を設けることが、記録された脆弱性です。
• 閉鎖まで燃え尽きを放置すること。 最も明確な2つの事例では、チームの疲弊は終了前から明らかでした。そのうちの1つでは、すでに「少人数のボランティアチームにできることには限りがある」と警鐘を鳴らしていました。楽しめているかを確かめることが警告のきっかけです。「いいえ」という回答は、基準に達したものとして扱ってください。
• 最初にコミュニティマネージャーを雇うこと。 記録されている最初の採用者はイベントコーディネーターやマネージャーで、1つの事例ではエグゼクティブディレクターでした。コミュニティマネージャーを最初に採用した事例はありません。ボランティアチームを疲弊させるのは、年間を通じた運営上の負担であって、コミュニティの活気ではありません。最初にコミュニティマネージャーを採用すると、ボランティアがまだ楽しんでいる部分に予算を費やすことになります。
• 閉鎖的な仲間内だという印象。 不透明なリーダーシップチームは、技術系の参加者を持つ主催者の正当性を支える、コミュニティからの信頼を損ないます（この調査結果はオープンソースコミュニティに基づくものですが、まさにここで想定している参加者について述べています）。憲章に誰でも参加できる方法を明記するのが、手軽な対策です。
• 個人アカウントでイベントアカウントを管理すること。 ドメイン、ソーシャルメディア、チケット販売、銀行へのアクセスを1人が管理していると、イベント全体のアイデンティティが、気づかれないままバスファクター1の状態になります。今週中に、バックアップ管理者を設けて共同管理にしてください。
• イベントを主催者個人の営業窓口にすること。 主催者が自分の見込み客を探すことを主な目的としてコミュニティを運営すると、コミュニティの基盤となる信頼が損なわれます。対策として、利益相反に関する条項を設け、開示し、関与を控え、設立時の文書に「ビジネスは結果であって、目的ではない」と明記してください。
• 仲間同士のネットワークがフランチャイズ化すること。 マニフェストに必須の形式、開催頻度、スポンサー向け資料を増やしていくと、仲間同士の支援を求めて参加した支部を失います。対策として、拘束力のある最低限のルールは短く保ち、脱退方法を文書に記載してください。
• 中継役のいないネットワーク。 共通の資産が、地域の共同主催者の代わりになることはありません。主催者が1人だけの支部は、ネットワークが何を提供してもバスファクター1のままです。対策として、各支部に中継役の目標を設定し、各イベントの終了時に公開で協力を呼びかけてください。
• 組織体制を完成済みとして扱うこと。 EuroPython Societyは、業務負担の偏りとサイロ化を解消するため、設立から7年後に自らの組織体制を見直しました。定期的な見直しを予定に組み込んでください。誰も見直せない設計は硬直化し、誰も従わない組織図になってしまいます。

測定

以下のしきい値はすべて独自に設定するものです。設計の公開時に宣言し、各回の開催時にそれに照らして監査してください。いずれも業界標準ではありません。

• 名指しされたすべての役割について、リードを含め、バス係数が2以上であるか、それを補うための有効な仕組みが存在します。
• 憲章が作成され、チームに公開されており、各役割の範囲、参加経路、意思決定権が明記されています。
• リードの後任者が特定されており、引き継ぎ期間は公開されている6〜12か月の範囲内です。
• 年1回の各人の満足度確認が実施され、すべての「いいえ」に対し、担当者を明記した構造的な対応が取られました。
• 有給雇用の判断基準が、公開済みのしきい値に照らして今回も再評価され、結論が記録されています。
• すべての主催者について、利益相反登録簿に最新の記載があり、復帰先が明記されています。
• ピアネットワークのメンバーの場合、マニフェスト、オプトアウトの手順、共有資産ごとの担当者が文書化されています。

このスキル自体の成果物として求められるのは、常設チームの設計です。各選択肢に「公開済みの慣行」「借用」「独自設定」のいずれかを明記し、却下した選択肢も示したうえで、以下を記載します。

• 組織のあり方。
• 意思決定権の構成と、常設事項と運営事項の文書化された切り分け。
• 役割の分類とバックアップ。
• リスクのある各役割の後継者計画。
• 担当者を明記した燃え尽き防止策。
• 利益相反に関する条項。
• 有給雇用の判断。
• コミュニティがピアネットワークに属する場合は、ネットワーク層。

バス係数のマップまたは防止策が欠けている設計は、未完成です。

呼び出し例

• 「カンファレンスを4回開催しましたが、今もすべての決定が私を通ります。チームをどのように構成すればよいでしょうか？」
• 「400人規模のカンファレンスに発展したミートアップのために、非営利団体を設立すべきでしょうか？」
• 「中核となる主催者2人が今回の開催後に離れる予定です。イベントが彼らとともに終わらないようにするには、どうすればよいでしょうか？」
• 「異なる都市で同じテーマのミートアップを開催する5つのグループが、誰もブランドを所有せずに協力したいと考えています。どのように仕組みを整えればよいでしょうか？」
• 「主催者の1人はフリーランサーで、クライアントの大半をミートアップ経由で獲得しています。これは問題でしょうか？」

期待される出力：測定の項で説明した常設チームの設計を、検証しやすいようセクションごとに提示します。現行の組織構成の診断、組織のあり方、意思決定権の構成、役割の分類、後継者計画、防止策、有給雇用の判断を含めます。

参考資料

• references/governance-case-records.md - 事例の記録です。具体例を挙げた3種類の意思決定権の形、常設組織と持ち回り制を比較する自然実験を含む6つのガバナンス事例、規模別のチーム人数のベンチマーク、初の有給スタッフ採用に関する根拠と基準をまとめています。
• references/succession-and-burnout-evidence.md - 引き継ぎの取り組みと6〜12か月の引き継ぎ期間を示す数値、運営者自身の言葉で語られた燃え尽きによる中止事例、限界を率直に示した調査の根拠、補足的な枠組みとして扱うオープンソースと企業の事例をまとめています。
• references/peer-network-and-organizer-incentives.md - 独立したコミュニティのピアネットワーク（適合性の確認、マニフェストのテンプレート、会員規約、共有資産の表、地域別とネットワーク全体のKPI、法的組織形態のトレードオフ、リレー）、利益相反条項、運営者へのリターンの対応表、参加者急増時のオンボーディングチェックリストをまとめています。

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

• samber/dev-event-organizer-skills@event-first-edition - 初回開催チームの 結成 を扱います。このスキルは、チームがすでにイベントを運営している段階から始まります。
• samber/dev-event-organizer-skills@event-growth-strategy - 成長の制約が人材層の厚さにある場合にこちらへ案内します。このスキルは、チームの拡大という施策で先送りされる分類と基準を提供します。
• samber/dev-event-organizer-skills@event-volunteers - 当日のボランティアスタッフ（人数、シフト、ブリーフィング）を扱います。このスキルの有給スタッフかボランティアかという問いは、当日のスタッフ数ではなく、常設のリーダーを対象としています。
• samber/dev-event-organizer-skills@event-run-of-show - 当日の役割と連絡チャネルを扱います。このスキルでは、開催回の間に活動するチームを扱います。
• samber/dev-event-organizer-skills@event-budget - エディションの赤字に備える準備金など、組織形態の選択肢が継続性のベンチマークとして参照するものも含め、資金面をモデル化します。
• samber/dev-event-organizer-skills@event-debrief - 疲労、不均等な作業負担、またはバス係数が1の役割が、各開催回の構造的な問題として明らかになる場所です。その改善策はここで扱います。