event-community-building

イベントコミュニティの構築

定期開催する技術イベントについて、次回開催が迫っていない数か月間に、イベント独自の参加者コミュニティを活性化します。対象はプロダクトでも常設のミートアップシリーズでもなく、開催回のサイクルです。重視する成果はただ一つ。「この人が次回も参加し、そのうちの何人かが仕事仲間を連れてくること」です。

場は引き継ぎますが、選びません。samber/dev-event-organizer-skills@event-portfolio-strategy が、継続的な交流の場をチームの資産として持つべきかを判断します。その答えが「はい」であれば、運営方法を決めます。交流の場を資産に追加する、または資産から外す提案は決して行わず、その提案はそちらに戻してください。

次の3つを作成します。

• 開催の合間の運営ペースと、明確な担当者。
• 参加者を次回も参加する人へとつなげる仕組み。
• 主催者が離れても残るコミュニティ資産の、文書化された引き継ぎ。

境界線

再定義せず、7つの境界をそのまま引き継ぎます。各領域の境界については、references/sibling-boundaries.md を参照してください。

兄弟スキル	境界線
event-comms-channels	1回の開催におけるチャンネルのライフサイクルを担当します。あなたは、終了後もチャンネルを継続すると決まった場合の開催間の運用を担い、次回の準備開始時に有効なメンバーリストを引き渡します。名簿、振り分け、終了処理を再設計しないでください。
event-volunteer-experience	ボランティア同窓生向けのループ（リスト、お礼、候補者フラグ）を担当します。あなたの対象は、ボランティア以外のすべてのメンバーです。同窓生チャンネルは、2つ目の場を作らず、あなたの交流の場の中のセグメントとして運営してください。
event-portfolio-strategy	交流の場をそもそも設けるかを判断します。会場、スケジュール、講演者名簿が必要になった交流の場は、そちらに戻してください。
cross-event-promotion	外部向けの施策を担当し、あなたは内部向けの施策を担当します。交流の場でパートナーイベントを紹介するのは、あなたが提供するコンテンツであり、仲介する取引ではありません。
event-cultural-identity	どのような語調にするかを定めます。あなたはそれを実行し、閑散期だからといって、より落ち着いた雰囲気を新たに作らないでください。
event-growth-strategy	イベントを拡大するかどうかを担当します。参加継続率が健全であれば、その情報を event-market-fit に渡してください。あなた自身が成長に関する提案を行うことはありません。
event-code-of-conduct	会場と同じ行動規範があなたの交流の場にも適用されます。担当者を明記し、方針や報告先はそちらに案内してください。

引き継ぐ成果物は3つ。そのうち担当するのは1つだけ

1. チームと意思決定権 - event-team-structure（チャーター、予備管理者）。
2. 運用上の学びの記録 - event-continuous-improvement（特定の担当者に依存するリスクの軽減）。
3. コミュニティ資産 - プラットフォーム、メンバーリスト、アーカイブ、招待リンク、継続の判断。以下のメニュー3を参照。これ以外に該当する項目はありません。

引き継ぎを3つに分けるのは、このスキル独自の構成です。最も目立つ項目の担当者が、残りも引き継いだものと思い込まないようにするためです。

event-team-structure の6〜12か月という期間は、リーダーの役割を対象としており、プラットフォームのアカウントは対象外です。資産独自の期間は、チームの判断で設定してください。

4つの汎用メカニクスは samber/developer-relations-skills にあります

このコレクションは、製品や定期開催のミートアップシリーズにおける汎用的なオンラインコミュニティ運営のノウハウを扱います。独自に考え直すのではなく、推奨して再利用してください。

ニーズ	スキル
プラットフォーム／会場の選定、立ち上げ、実施可否の判断、終了	developer-community-launch
健全性指標、コントリビューターの導線、ダッシュボード	developer-community-health
モデレーションポリシー、段階的な対応、モデレーター名簿	developer-community-moderation
無報酬のチャンピオン／アンバサダーの設計、募集、特典	developer-champions

このコレクションの developer-meetup-program は、「プログラムが一晩の開催を超える」段階になると、ここに独自の案内を返します。参加者から共同主催者へと進む段階的な仕組みは、定期開催のミートアップ向けに作られています。メニュー 2 では、その形を1回の開催サイクル向けに再構成します。

インタビュー

一度に質問は1つにし、可能な限り選択式にしてください。メニューを提示する前に、7～9個の質問をしてください。メニューごとに効果が出るまでの時間、持続性、労力が大きく異なるため、ユーザーに代わって既定値を選んではいけません。

1. イベントは年1回以上開催されていますか。また、これまでに何回開催しましたか？
2. 定常的なコミュニティの場はすでにありますか。どのプラットフォームを使っていますか。それは前回の開催で使ったチャンネルから引き継いだものですか、それとも独立して開設したものですか？（利用する場が決まっていない場合は、まず event-portfolio-strategy に案内してください。）
3. 現在の管理者は誰ですか。名前の決まった個人、持ち回りの役割、あるいは誰もいない状態でしょうか？プラットフォームのアカウントは誰の名義で登録されていますか？
4. 登録簿はありますか（event-cultural-identity）？ない場合は、まずそちらに案内し、暫定的なものにはその旨を明記してください。
5. 対象者は1つの都市、1つの地域、あるいは複数の地域から集まっていますか？複数都市にまたがる場合、あなたが一緒に運営していない人が運営する地域グループはありますか？
6. 開催の合間に対象者とのつながりを保つものは何ですか。告知リスト、アーカイブ、ポッドキャスト、それとも何もありませんか？
7. 実施期限は決まっていますか。次回開催の告知、運営者の退任前の最後の月、プラットフォームの移行などです。
8. 特に開催がない時期の労力の上限：制作をしていない時期に継続的な時間を確保できるのは誰ですか。また、モデレーションのために資金を受けている人はいますか？
9. 単発ですか、それとも積み重ねを前提としていますか。次回の開催はすでに予定されていますか。また、その前にチームの交代が見込まれますか？
10. 既定の想定から外れる資産はありますか。既存のチャットスペース、現在も有効な同意を得ているメンバーリスト、社内のライター、再開可能なアーカイブなどです。
11. イベントを後ろ盾となる法人はありますか。また、誰がどのアクセス権を持つかを提示できる必要がありますか？

以下の順位はいずれも既定値であり、絶対的なルールではありません。Q10の回答を踏まえて3つのメニューすべての順位を付け直し、どの回答によってどの順位が変わったかを述べてください。

開催のない時期に対応できる人

以下のすべてのメニューを左右する回答が1つあります。それは、何も制作していない時期に誰が対応できるか（Q8）です。業者が運営するイベントでは、静かな時期も職務に含まれる担当者がいます。ボランティアチームの場合は、開催を終えて休息中の人たちがそのまま担当者です。

両者で推奨内容が異なる場合は、どちらを想定した推奨なのかを明示してください。この区分はこのスキル独自の実務モデルであり、業界標準ではありません。

ワークフロー

1. インタビューを実施します。Q2（対象となる場が未決定）またはQ4（レジスターが未決定）に該当する場合は中止し、適切な窓口に案内します。
2. そのエディションですでに決定した内容を確認します。event-comms-channels で縮小・終了したチャネル、継続したチャネル、その条件を確認します。縮小・終了が終わった時点から始めます。
3. レジスターは所与のものとして扱います。エディション間の 表現 のみを書き、オフシーズンの語り口が新しいものに曖昧化せず、レジスターに照らして監査可能な状態を保ちます。
4. 投稿頻度の方針（メニュー 1）を選び、閑散期の担当者を明記します。担当者が明記されていない場合、それは未決定の休眠状態です。
5. 変換の仕組み（メニュー 2）を選び、ボランティアではないメンバーを対象にします。ボランティア向けの作業は event-volunteer-experience に案内します。
6. 地域グループに手を加える前に、エンゲージメントとガバナンスを分けます（§ 地域グループ）。ここでは、気づかないうちに一線を越えやすいためです。
7. メニュー 3 の引き継ぎを、誰かが離れるときではなく、今すぐ記述します。メンバーリストの管理者と保持に関する決定を改めて明記します。
8. この場の目的と、目的ではないものを公開します。明示されていない役割は、サポートチャネル、求人掲示板、または沈黙へと変わっていきます。募集の依頼はそれでも届くため、誰でも投稿できる場ではなく、範囲を限定した窓口を 1 つ用意します（§ 募集の依頼）。
9. 立ち上げ時に、最新のメンバーリストを次のエディションのチャネル設計に引き継ぎます。誰が参加し、どのような同意に基づき、誰に連絡できるかを伝えます。
10. 計画を、投稿頻度、変換、地域向けの方針、引き継ぎの順にセクションごとに提示し、メンバーに見える内容を変更する前に、それぞれの承認を得ます。

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

• 投稿頻度の方針と担当者。
• 計画した内容に対して実際に投稿した内容、および担当者が投稿できなかったすべての月。
• 変換の仕組みと、それに沿って移行した人。
• 各エディションの開始時と終了時のメンバー数、およびその同意の根拠。
• 引き継ぎ文書とその日付。
• 却下したすべての段階。

投稿できなかった月は、次のギャップにおける投稿頻度の判断材料になります。却下した段階を記録しておくことで、次の主催者がこれらすべてをゼロから再検討せずに済みます。

メニュー 1 - 開催間の運営ペースの方針

次回の開催が迫っていない期間に、コミュニティをどの程度運営するかを示します。「次の告知時にも参加者が残っていること」と「コミュニティが今も活動しているように見えること」は異なる指標であり、どの段階も両方で最高にはなりません。この段階、評価軸、順序は、このスキル独自の設計です。

• 価値、熱量（次の告知時にすぐ行動できる状態にある参加者――早期購入、呼びかけへの応答、口コミでの情報拡散）：継続的・高頻度 > 継続的・低頻度 > 定期的な発信 > 休眠状態だが開放
• 価値、堅牢性（約束以上のことを提供することがないため、コミュニティが放置されているように見えないこと）：休眠状態だが開放 > 定期的な発信 > 継続的・低頻度 > 継続的・高頻度
• 労力（閑散期に継続して必要となる時間、モデレーションの負荷、開催を終えたばかりの人々にかかる燃え尽きの負担）：継続的・高頻度 > 継続的・低頻度 > 定期的な発信 > 休眠状態だが開放
• コンプライアンスコスト（必要となるレビューと、失われる可逆性）：継続的・高頻度 > 継続的・低頻度 > 定期的な発信 > 休眠状態だが開放
• 効率性：休眠状態だが開放 > 定期的な発信 > 継続的・低頻度 > 継続的・高頻度

どの段階も他の段階を支配しません。これはチェックの結果ではなく、設計上そうなっています。堅牢性は熱量と正反対です。段階を上げるほど約束が増え、その約束をチームが守れなくなるリスクが、堅牢性を損ないます。

コンプライアンスコストは実際に発生します。常設のコミュニティには、継続的な行動規範上の責任が伴います。また、参加者リストは、それが収集された開催を終えた後も保持されます。

休眠状態は最低限の運営であり、何もしないことではありません。保持するリストには担当者を明確に定め、保持に関する判断を行う必要があります。その判断は法律顧問に委ね、管轄区域や期間は指定しないでください。各段階の具体的な成果物については、references/cadence-and-content-shapes.md を参照してください。

• 休眠状態だが開放（デフォルト） - 運営を停止し、アーカイブと参加者リストはそのまま保持し、次の準備期間までコミュニティが静かな状態になることを、日付入りのお知らせで一度だけ告知します。労力はほぼゼロで、コミュニティが公に失敗することもありません。お知らせのテンプレートと発信計画はリファレンスに記載されています。前回の開催で全体コミュニティと並行してチーム別またはプロジェクト別のサブチャンネルを設けていた場合、それらも全体アーカイブに統合せず、そのまま保持してください。戻ってきた参加者は、自身のプロジェクト専用のチャンネルを再び開いて進捗を確認します。全体チャンネルではその代わりになりません。
• 定期的な発信 - 担当者が実際に続けられる頻度でダイジェストやスポットライトを発信し、それ以外は行いません。Q1 が年 1 回以下で、Q8 に閑散月に継続して時間を割ける人が挙げられている場合に昇格します。両方を満たさない場合は、3 か月目までに運用が止まります。
• 継続的・低頻度 - 常設のプロンプトとスレッドを設けます。ライブセッションやサブチャンネルは設けません。Q6 で参加者をつなぎ止めるものがないとされ、Q9 で複利的な効果が見込まれる場合に昇格します。
• 継続的・高頻度（維持困難な段階） - ライブセッションを定期開催し、サブチャンネルを設け、モデレーションをほぼ常時行います。次のすべてを満たす場合に限り昇格します。Q10 でコミュニティがすでに参加者の主な居場所とされていること、Q8 に予算が確保されたモデレーターの体制が挙げられていること、Q9 で複利的な効果が見込まれることです。さらに一歩進むと、定例ミートアップシリーズになります（これはあなたのものではなく、developer-meetup-program の対象です）。
• 削除する場合は、降格ではなく削除： 開催ごとにコミュニティを閉鎖し、新しく作り直すことです。休眠状態のように見せかけるだけで、参加者リストとアーカイブを失います。event-comms-channels では、開催が一度限りで、リストを活用できる次回開催がない場合に限り、エクスポート後に削除する方法へ移行します。
• 条件付きで削除： Q8 で担当者が誰もいないとされている継続的・高頻度の運営です。モデレーション担当者のいない常設コミュニティには、対応者不在の行動規範上の責任が伴います。

Christopher Allen のコミュニティ規模に関するしきい値が適用されるのは、2 つの継続的な段階に限られます。休眠状態のアーカイブや参加者リストには適用されません。参加者リストはグループではなく、蓄積されたデータです。数値とその適用範囲については、references/cadence-and-content-shapes.md の § サイズのしきい値を参照してください。

メニュー 2 - 参加者を再参加する人へとつなげる

ボランティアではないメンバーのみを対象とします。価値を測る軸は 2 つです。幅は再び参加する人の範囲、深さは手元に成果物を携えて参加する人の範囲です。段階、軸、順位は、このスキル独自の構成です。

• 価値、幅（前回の参加者のうち次回に登録する人の割合）：単発の再参加促進の働きかけ > 地域コホートの育成 > 構造化された参加の段階 > 仕組みなし
• 価値、深さ（次回に活用できる何かを生み出すメンバーの数。講演、レビュー、ホスト役、継続的な口コミなど）：構造化された参加の段階 > 地域コホートの育成 > 単発の再参加促進の働きかけ > 仕組みなし
• 労力（調整、継続的な担当、可逆性）：地域コホートの育成 > 構造化された参加の段階 > 単発の再参加促進の働きかけ > 仕組みなし
• 効率：単発の再参加促進の働きかけ > 構造化された参加の段階 > 地域コホートの育成 > 仕組みなし

ここでも、どの段階も他を支配しません。また、軸によってその状態が成り立っているのであり、確認してそうなったわけではありません。3 つの実質的な段階では、幅と深さは互いに反対の動きをします。一方、「仕組みなし」は、最も労力が少ない一方で、両方の価値軸で最下位です。

コンプライアンスコストの軸はありません。どの段階でも、参加者リストを通じて連絡します。このリストの同意管理は、すでに event-attendee-email-sequences が最初から最後まで担っているため、別の同意管理を設けるのではなく、その義務を引き継ぎます。残るリスクは 1 つです。公開されるステータスマーカーに個人名が含まれるため、誰かの名前を出す前に同意を得てください。これは、event-volunteer-experience が感謝を伝える際に設けている条件と同じです。

• 単発の再参加促進の働きかけ（デフォルト） - 前回の参加者に対して、次回の募集開始に合わせて、意図的な連絡を 1 回行います。リスト全体に届き、所要時間は 1、2 時間です。最上位である根拠は、測定結果ではなく、論じられた前提にあります。通常、次回に不足しがちなのは幅です。Q9 の効果が積み重なり、Q6 で既存の何かがすでに参加者を惹きつけていると分かったら、上位の段階に移行します。
• 構造化された参加の段階 - 参加者 → 常連 → 貢献者という明確なステップを設け、それぞれに参加方法と報酬を明示します（developer-meetup-program の段階を再適用したもの）。そのまま引き継げない点は次のとおりです。ミートアップでは毎月連絡を取るため、1 つの段階に 3 回の開催を要することがあります。年次イベントでは、年に 1 回しか直接の接点がないため、最初の段階より上の各段階は非同期でも進められるようにしなければ、誰も進みません。長く続いているイベントなら、過去の受賞者や際立った貢献者を記念回に参加者として招待することが、具体的な最上位の段階になります。卒業生を、イベントのコンセプトを形作る要素であると同時に、再参加を促す仕組みとして活用できます。卒業生を単なる連絡先リストとして扱うのではありません。
• 地域コホートの育成（育成が後回しにされがちな段階） - イベントの参加者自身によるグループを 1 つの都市で形成し、訪問の合間も関係を保ちます。最も労力がかかります（あなた以外に、継続して担当する地域の責任者が必要です）。Q5 で複数の都市から参加者が来ることが明確で、Q10 で意欲のある地域の担当者が挙がっている場合に、優先度を上げます。まず § 地域コホートを読んでください。
• 仕組みなし - 戻ってくるのは、覚えている人だけです。労力はほぼゼロですが、再参加もほぼありません。チームが決断しないまま行き着く段階です。まだ参加者リストがない初回開催なら、妥当な選択肢です。
• 削除し、決して降格しない： 登録者全員を自動的にメンバーに登録すること。会員数を見せかけだけ増やし、チケット販売時に得た同意を、許可されていない目的に使うことになります。
• 条件付きで削除： Q5 の都市が 1 つだけで、そこから参加者が他所へ移動しない場合の地域コホートの育成。その「コホート」は実質的にあなたの参加者であり、活性化はメニュー 1 の役割です。

メニュー以外の再参加を促す手段：トピックの領域を交互に変える

上記の各段階は、前回の開催回の参加者を対象にしているため、メニューが完璧でも、コミュニティが内向きになってしまうことがあります。あるシリーズでは、開催回ごとにトピックの領域を交互に変えていました（技術、マーケティング、人事、人に関するトピック）。挙手による確認では、参加者のおよそ5人に2人が初参加者だと報告されています。

• これは新規参加者の割合（§ 測定）を高める手段であり、参加転換の段階ではありません。以前の参加者を呼び戻すのではなく、新しい人を呼び込みます。
• コスト：特定の領域を目的に来た常連は、その領域以外の開催回を欠席するため、新規参加者の割合が上がる一方で、継続参加率が下がることがあります。
• トピックの境界は samber/dev-event-organizer-skills@event-format-selection で、コミュニティの雰囲気は event-cultural-identity で定め、交互に変えてもアイデンティティが変わったと受け取られないようにします。

地域コミュニティ：エンゲージメントの側面のみ

event-portfolio-strategy は、ブランドライセンスの側面に真正の課題があると述べています。「自ら運営していないチームの採用、審査、基準の徹底」です。event-growth-strategy も、分散型フランチャイズモデルを自らの対象範囲外としています。独立したチャプターのネットワークを統治する方法については、samber/dev-event-organizer-skills@event-team-structure の「独立したコミュニティのピアネットワーク」を参照してください。

エンゲージメントの側面だけを担います。自分たちのイベントの参加者で構成される地域グループを運営し、次の参加まで関心を保てるよう、自分たちの雰囲気と場を維持します。ブランドの使用を誰に許可するか、独立して運営されるチームをどう審査するかという話になった時点で、その課題領域に踏み込んでいます。そのことを伝え、そこで止めてください。

このスキル独自の判定基準は、これによって、運営チーム以外の誰かがあなたの名前でイベントを開催することになりますか？ なる場合は、ガバナンスの問題であり、このスキルの対象外です。チームが引き続き管理するチャットのサブスペース、地域別スレッド、またはメーリングリストの区分であれば、エンゲージメントの問題であり、このスキルの対象です。

公開されているチャプターモデルでは、両方の側面がひとまとめになっているため、手作業で切り分ける必要があります。実際の切り分け例は、references/returning-participant-ladder.md をご覧ください。

採用関連の依頼

主催者からは、「誰かを紹介してもらえませんか」「採用したい人に心当たりはありませんか」といった依頼が絶えず寄せられると報告されています。対策せずにいると、常設の場が求人掲示板になってしまいます。これはワークフローのステップ8が警告する逸脱です。

• 範囲を限定した告知の時間 — 各対面の集まりの冒頭に設ける短い枠で、「仕事を探している人はいますか。フリーランサーや採用したい人を探している人はいますか」と尋ねます。目的と時間制限をあらかじめ明示し、その後は終了します。依頼を受け付ける場を設けつつ、残りの時間は依頼に費やさずに済みます。
• 常設の場では、誰でも自由に投稿できるようにするのではなく、開催サイクルごとに日付入りのスレッドを1つ固定し、同じ仕組みを設けます。
• 枠の長さは自分で決めてください。報告には記載されていません。
• イベントチーム自身の採用や、スポンサーの採用活動に関する権利については、samber/dev-event-organizer-skills@dev-event-hiring に案内してください。

メニュー 3 - コミュニティ資産の引き継ぎ

プラットフォーム、メンバーリスト、アーカイブ、招待リンク、そしてそれらに付随する保持の判断です。チーム（samber/dev-event-organizer-skills@event-team-structure）でも、学習ログ（samber/dev-event-organizer-skills@event-continuous-improvement）でもありません。詳しくは「引き継ぎで移行するのは3つの成果物、そのうち自分のものは1つだけ」を参照してください。

段階、軸、順序は、このスキル独自の構成です。引き継ぎの形そのものは、隣接する組織運営の実践を踏襲したものであり、イベントデータに基づいて測定したものではありません。

• 価値、復旧可能性（認証情報、記録の所有権、メンバーリスト、およびその保持の判断のすべてが、現在も関与している存命の人物として明示された担当者の手に渡ること）：完全に手順化された移行 > 所有権とアクセス権の移転を文書化 > 引き継ぎ期間を設けた後任者の指名 > 非公式な引き継ぎ
• 価値、運営の継続性（変化を経ても、その場の雰囲気と常連が保たれること）：完全に手順化された移行 > 引き継ぎ期間を設けた後任者の指名 > 所有権とアクセス権の移転を文書化 > 非公式な引き継ぎ
• 労力（時間、定常的なプロセス、そして誰かが作り上げたものの引き渡しを求めるために費やす政治的資本）：完全に手順化された移行 > 引き継ぎ期間を設けた後任者の指名 > 所有権とアクセス権の移転を文書化 > 非公式な引き継ぎ
• コンプライアンスコスト（引き起こすレビューと、その結果損なわれる可逆性）：完全に手順化された移行 > 引き継ぎ期間を設けた後任者の指名 > 所有権とアクセス権の移転を文書化 > 非公式な引き継ぎ
• 効率性：所有権とアクセス権の移転を文書化 > 引き継ぎ期間を設けた後任者の指名 > 完全に手順化された移行 > 非公式な引き継ぎ

ここでも、どの段階もほかを圧倒しません。軸の線はその理由を3つ別々に示していますが、どれもメニューに合格したという判定ではありません。

1. 復旧可能性と運営の継続性では、2つの中間段階の順位が入れ替わります。
2. 手順化された段階は、両方の価値軸と労力のすべてで最上位です。
3. どちらの中間段階も、両方の価値軸では非公式な段階に勝り、コストだけで劣ります。

「継続性」を復旧可能性と運営の継続性に分けると、見かけ上の同点が崩れます。引き継ぎ期間があれば雰囲気を受け継げますが、プラットフォームの登録名義が退任者のままになる可能性は残ります。アクセス権の移転を文書化すれば、その復旧可能性を正確に確保できます。

ここでのコンプライアンスコストは、メニュー 1 のものとは異なります。引き継ぎとは、認証情報が別の人の手に渡り、メンバーリストの保持に関する判断を黙って引き継ぐのではなく、改めて明示しなければならないタイミングです。非公式な段階が最下位にあるのは、理由を誤っています。レビューを引き起こさないため、誰にも割り当てられないまま、行動に関する義務が存続するからです。

• 所有権とアクセス権の移転を文書化（デフォルト）- アカウント、管理者ロール、招待リンク、ドメイン、リストをすべて記載した書面を1ページ作成します。それぞれについて、現在と移行後の担当者、メンバーリストの所有者、保持の判断を記載します。半日で、実際に場を孤立させる唯一の問題を解消できます。
• 引き継ぎ期間を設けた後任者の指名 - 退任前に指名し、退任する所有者と並行して運営にあたります。Q7 で主催者の退任する最終月が示され、Q9 の影響が積み重なっている場合に昇格させます。引き継ぎ期間の長さは自分で設定してください。別の成果物である event-team-structure のリードロール期間を借用しないでください。
• 完全に手順化された移行（リソース不足の段階）- 手順書、アクセス権のチェックリスト、モデレーションロールの移転、承認済みの保持に関する判断を用意します。Q9 または Q11 に基づく昇格条件：計画的な交代がある場合、またはイベントが、誰が何を保有しているかを示す必要のある法人のもとで運営されている場合です。
• 非公式な引き継ぎ - その場にいる人が新しい主催者に説明します。労力はほぼゼロですが、復旧可能性もほぼゼロです。何もしないことで選ばれるデフォルトです。
• 削除し、決して降格させないでください： 退任する主催者の個人アカウントが記録上の所有者のまま、後任者を2人目の管理者として追加する方法です。最も安価なデフォルトの段階に見えますが、まさにその失敗例です。そのアカウントが閉鎖された日には復旧できません。

失敗パターン

• 担当者が明確でない開催ペースは、計画上は継続的に見えても、3か月目には放置されています。対策：Q8では、Menu 1の前に担当者を決めるか、判断によって活動休止状態にします。
• オフシーズンの声を作り上げる（「閑散期は基本的に私たちだけです」）。event-cultural-identityで解決します。アイデンティティは固定され、変わるのは表現だけです。
• フランチャイズに関する問い（「支部を始めるべきでしょうか」）を取り込むこと。これは、対象外だと明言している2つのスキルが扱うガバナンス上の問いです。対策：「§ 地域のコホート」にある1つの質問のテストを実施し、そこで止めます。
• 過去のボランティアがこの場にいるという理由で、ボランティア経験者への働きかけを再び行うこと。それは担当範囲外です。そのスキルが名簿、お礼、フラグ付けを担当します。
• リレー形式のミニイベントを設計すること。 タッチポイントに会場、スケジュール、または登壇者が必要になった時点で、それは event-portfolio-strategy が扱うイベントの特性です。
• メンバーリストを、決めるものではなく引き継ぐものとして扱うこと。 メンバーリストは、その版が終わった後も残ります。対策：初日に担当者と保持方針を決め、引き継ぎのたびに改めて確認します。
• 版ではなく、コミュニティの場を測定すること。 活気が増しても、再び参加するオーディエンスが増えたとは限りません。対策：このスキルの問いに答える数字として継続率を記録し、新規参加者の割合と併せて読み取ります。
• 常連に偏ること。 継続率が上がり、新規参加者の割合が下がっている状態は成功に見えても、コミュニティの場が内向きになっています。主催者の意見は分かれていました。安定したコアメンバーが新規参加者を「支え、つなげる」と考える人もいれば、同じ顔ぶれがあまりにも多いのは閉鎖性の表れだと考える人もいます。対策：どちらか一方の数字だけではなく、2つの比率の目標を自分たちで設定します。
• コミュニティの場が求人掲示板になってしまうこと。 採用や紹介の依頼は絶えません。対策：範囲を限定した窓口を1つ設け、最初に明示します（「§ 採用の依頼」）。採用側の依頼は samber/dev-event-organizer-skills@dev-event-hiring に振り分けます。
• 対応する余力のない空白期間にプログラムを組むこと。 イベント翌週のチームの意向ではなく、Q8への率直な回答に基づいて方針を選びます。

測定

ここでのすべてのしきい値は、業界ベンチマークではなく、自分で設定するものです。ギャップが始まる前にそれぞれを決め、データが届いてから決めることは避けてください。

• 継続率（自己設定）：ある回の参加者のうち、次の回に申し込む人の割合です。スキル固有の成果指標であり、event-market-fit に引き渡します。業界を横断した参考情報（Freeman の Ken Holsinger、Trade Show Executive、2025年）：「当業界全体の平均継続率は、かろうじて30％を上回る程度です」――あらゆる種類のイベントを含む数字であり、技術カンファレンスに限ったものではありません。想定より再参加率が低いことを示す根拠として読み、目標値としては扱わないでください。
• 初参加者の割合（自己設定、継続率の対抗指標）：ある回の参加者のうち、初めて参加する人の割合です。開会時に挙手してもらうか、登録フォームに「今回が初めてですか？」という項目を設けて集計します。この項目については、event-attendee-email-sequences の同意の根拠で既にカバーされています。長く続く月例シリーズの一つではおよそ3分の1、テーマ領域を交互に扱うシリーズの一つではおよそ5分の2という報告値があります。これらは2つのデータポイントとして読み、目標値としては扱わないでください。目標は、継続率に対する比率の範囲として設定してください。どちらか一方の数字だけでは、望ましくない参加者構成を促してしまいます。
• 開催間隔の維持（ゲート、二値）：選んだ方針に基づき、ギャップの間に予定した投稿数と実際の投稿数を比較します。これは、その段階が無理なく継続できたかを正直に判断する指標であり、次のギャップでの選択にも使います。2サイクル連続で実施できなかった場合は、規律の問題ではなく、段階を下げるサインです。
• リストの適正管理（ゲート）：ギャップが始まる日に、メンバーリストの担当者が明確に決まっており、保持方針が文書化されていることを確認します。これを満たせなければ、エンゲージメントの状況にかかわらず、コンプライアンス面で不合格です。
• 引き継ぎの準備状況（ゲート）：アクセス情報を記載した文書が存在し、日付が記され、各アカウントについて現職の担当者が明記されていることを確認します。誰かが退職するときではなく、定期的に確認してください。
• 段階の移行（自己設定、メニュー2の段階を採用する場合のみ）：段階を一つ進めたメンバーの人数です。少人数になるのが想定されるため、率ではなく人数を報告してください。この規模では、分母に意味がないためです。

合格基準は、満たされるまで反復して調整します。3つのゲートすべてを満たすことです。それぞれが、作成したリストと文書に照らして確認するものであり、外部ベンチマークがなくても使えるのはそのためです。

呼び出し例

• 「カンファレンスは毎年満席になりますが、Discordは11か月間、誰もいません。どんな投稿をすればよいでしょうか？」
• 「毎回、参加者の半数が初参加です。昨年の参加者に戻ってきてもらうにはどうすればよいでしょうか？」
• 「創設者が退任します。コミュニティのSlackは創設者個人のアカウントで管理されています。何をする必要がありますか？」
• 「ほかの3都市の人たちから、現地版を開催したいと繰り返し相談されています。こちらで承認してよいのでしょうか？」
• 「毎回、同じ40人が参加しています。健全な中核でしょうか。それとも内輪化が進んでいるのでしょうか？」

期待される出力：開催と開催の間の計画。次の項目を含めます。

1. 開催間隔の方針、その担当者、および採用しない段階。
2. 登録内容を基準にした差分として記述する、開催と開催の間における登録内容の表れ方。
3. ボランティアではないメンバーに対象を絞った参加転換の仕組み。
4. エンゲージメントとガバナンスの境界を明示した、現地開催の方針。
5. メンバーリストの担当者と保持方針。
6. 日付入りの引き継ぎ文書。
7. 自己設定のしきい値と3つのゲート。

自己設定のしきい値にはすべてその旨を明記し、計画全体をセクションごとに提示して承認を得てください。

参考資料

• references/sibling-boundaries.md - 各兄弟スキルがそれぞれ示す境界線と、その背景にあるより詳しい共通の論拠です。
• references/cadence-and-content-shapes.md - 各頻度段階における成果物の具体例、休止のお知らせ、実例付きのパルス計画と否定的な例、エディション間の登録情報の差分、エディション内のチャネル構成との両面からの境界表、規模のしきい値です。
• references/returning-participant-ladder.md - 再エンゲージメントのタッチポイントとエディションサイクルに合わせて再設定した参加段階の具体例、地域コホートにおけるエンゲージメントとガバナンスの分離と実例付きの分割、およびそれぞれの否定的な例です。
• references/community-asset-handoff.md - アセットの一覧、成果物の3つの区分、メンバーリストの保持に関する判断、日付入りの引き継ぎチェックリスト、個人アカウントに関する否定的な例です。

本文で参照している兄弟スキル：§ 境界線について を参照してください。