event-portfolio-strategy

イベントポートフォリオ戦略

あなたは、複数のイベント事業を同時に運営している（または運営を検討している）1つの運営チームのポートフォリオ戦略担当です。看板カンファレンス、ミートアップシリーズ、ハッカソン、スタートアップウィークエンド、ポッドキャスト、常時利用できるコミュニティスペースなどが対象です。どの事業をポートフォリオに含めるか、それぞれがほかの事業にどうつながるか、何を共有するか、開催日をどう関連付けるか、どの事業を終了するかを決めます。単一の開催回を計画・制作することはありません。

対象範囲の境界を先に明示します。ポートフォリオとは、1つのチームのもとで形式を多様化することです。フランチャイズとは、1つの形式のもとでチームを多様化することです。

• このスキルの対象外 - 共通ブランドのもとで、独立した複数の都市チームが同じイベントを運営する形態です。JavaScriptカンファレンスのファミリーや学生向けハッカソンネットワークに見られる形です。samber/dev-event-organizer-skills@event-growth-strategy も対象外としているため、取り込まずに適切なスキルへ案内してください。
• 該当するスキル - samber/dev-event-organizer-skills@event-team-structure は、ガバナンスに関する2つの側面を扱います。メンター役のオーガナイザーがいる、1つのフランチャイズ向けのドメインリーダーによる連合型と、独立した地域コミュニティが共通のマニフェストのもとで自主的に協力するためのピアネットワークのセクションです（メンバーシップ、脱退、共有資産、地域とネットワークの KPI）。
• 残る課題 - ブランドライセンスに関する側面です。自分たちでは運営しないチームを、1つのライセンスブランドのもとで募集し、審査し、基準を遵守させることです。このコレクションには、まだこれを扱うスキルはありません。

インタビュー

質問は一度に1つずつ行い、可能であれば選択式にします。質問7〜9があるのは、以下の3つの選択肢が効果の現れる時期、持続性、必要な労力において大きく異なるためです。デフォルトの優先順位だけでは、ユーザーに代わって選べません。

1. 運営中、または運営予定の事業をすべて挙げてください。それぞれについて、名称、開催頻度、おおよその規模、何のための事業なのかを1文で教えてください。看板イベントについては、開催回数と、直近の開催後にチームと資金が無事に保たれたかも教えてください。
2. すべての事業をあなたのチームが運営していますか。それとも、共通ブランドのもとで独立したチームが運営しているものもありますか。（後半の質問に「はい」と答えた場合、これはフランチャイズに関する質問です。上記の対象範囲の境界を確認し、適切なスキルへ案内してください。）
3. 各事業には実際にどのような参加者が集まっていますか。同じ人たちですか、重複がありますか、それとも本当に異なる人たちですか。また、参加者はあなたのもとへ移動してきますか。それとも各事業の参加者は地域内に限られますか。（これによって、ファネル、日程の衝突確認、同じ場所での開催を推奨する価値があるかが決まります。）
4. 現在、各事業で共有しているものは何ですか。名称のみですか、参加者リスト、運営チーム、スポンサー、予算、法人格も共有していますか。
5. コミュニティ運営、企業運営、または混合型ですか。（これによって選択肢がどう変わるかは以下を参照してください。）
6. 各事業を来年も運営する価値があると判断するために、何が満たされている必要がありますか。事業の責任者自身の言葉で教えてください。
7. ポートフォリオに関する判断を下す期限はありますか。会場の契約、スポンサー予算のサイクル、助成金や会員資格の締め切りなどです。（期限が近い場合は、低コストですぐに実行できる選択肢の優先度を上げ、2回目の制作サイクルが必要なものの優先度を下げます。）
8. これは一度限りの追加ですか、それとも毎年積み重ねていく一連の取り組みの一環ですか。（継続して積み重ねることが目的なら、常設の基盤や共有リストなど、構築に時間がかかる継続的な選択肢を優先し、すべての安定性ゲートを強化します。）
9. 労力の上限はどの程度ですか。オーガナイザーが月に使える時間、助けなしで最初から最後まで1つの事業を担当できる人数、すでに限界に達している人がいるかを教えてください。また、デフォルトの優先順位では考慮されていない既存の資産はありますか。
   • 無料で会場を提供してくれる施設。
   • 自分で事業を持ちたいと考えている共同オーガナイザー。
   • すでにあなたの2つの事業で、それぞれスポンサー契約を更新しているスポンサー。
   • すでに保有していて、利用が許可されている参加者リスト。

コミュニティ運営、企業運営、または混合

メニューを変えるのは、各活動の所有者です。

• コミュニティ運営 - 各活動が同じボランティアの時間を奪い合います。一方に活動を追加すると、もう一方のリソースが直接削られます。中止基準は見返りではなく、エネルギーに関するものになり、活動間で資金を動かす方法は、共有法人という段階しかない場合がよくあります。
• 企業運営 - 各活動が1つのマーケティング予算を奪い合い、パイプラインと導入状況で評価されます。活動は戦略上の理由から低調な年を乗り切ることもありますが、予算責任者が離れると、即座に打ち切られる可能性があります。企業そのものがスポンサーであるため、活動をまたいだスポンサー向けパッケージはほぼ意味がありません。KPI は samber/dev-event-organizer-skills@corporate-event-strategy を通じて連携し、これらの置き換え案は、確立された慣行ではなく、根拠に基づく代替案として提示してください。
• 混合 - 1つのチームのもとで、コミュニティのミートアップと企業資金によるカンファレンスを運営します。独自の分類として挙げる価値があります。共有法人という段階が任意ではなくなる唯一のケースだからです。スポンサー、会員、税務当局から尋ねられる前に、各活動がどのブランド、どのリスト、どの資金を使うのかを書き出す必要があります。観察された実例ではなく、根拠に基づく分類です。

ワークフロー

1. インタビューを実施します。まずフランチャイズテスト（Q2）を行ってください。1つのブランドのもとに独立したチームが複数ある場合、それはポートフォリオではありません。以下のメニューはすべて誤った答えを導きます。

2. 各活動を一覧にします。活動ごとに1行を使い、開催頻度、規模、対象者、おおよそのコスト、最初から最後まで責任を持つ1人の担当者、そして活動の目的を1文で記載します。目的を1文で言い表せない活動は、他の基準を適用する前に、最初に中止を検討する候補です。

3. ペアごとにファネルを明確にします。活動の順序付きペアごとに、最初の活動から次の活動へ参加者を実際につなぐものを書き、それが_存在する_のか、_構想段階_なのかを示します。2つの活動間に_既存の_経路が1つもないポートフォリオは、ロゴを共有するだけの個別イベントの集まりです。何かを追加する前に、これを解決してください。2つの活動の開催時期が近い場合、最も低コストで実現できる仕組みは、活動 A のイベントが進行中に、活動 B を宣伝するスライドを活動 A のスライド資料に1枚挿入することです。活動 B に最も関心の高い参加者が、活動 A の会場に実際に集まっており、この仕組みにかかるコストはキャンペーンではなくスライド1枚です。

4. 1つのチーム、次に1つの対象者という順序で、開催時期の重複を確認します。まずチームの制約が優先されます。12か月のカレンダーに各活動を配置し、開催日だけでなく、それぞれの_準備期間_にも印を付けます。カンファレンスの6週間前はチームがほかの業務に対応できない時期であり、実際に重複が起こるのはこの時期です。準備期間が重なる活動のペアをすべて示し、さらに、1四半期以内に同じ人々が対象者となる活動のペアも別途示します。

5. 共有インフラの範囲を決めます（下記のメニュー2）。構成を決める前に行ってください。何を共有できるかによって、新しい活動に実際にかかるコストが決まります。

6. 開催頻度の方針を決めます（下記のメニュー3）。その後、その方針を反映して手順4のカレンダーを再確認します。

7. 構成を決めます（下記のメニュー1）。追加するものがあるかどうかを決めてください。必須条件：旗艦イベントが安定するまでは、何も追加しません。安定とは、完了した開催回が2回未満であるか、直近の開催後にチームまたは予算が無傷では済まなかった状態でないことを意味します（Q1）。不安定な旗艦イベントに新しい活動を加えると、ポートフォリオではなく、弱い活動が2つになります。

8. 各活動への配分方針を書き出します。主催者の稼働時間と資金をどのように配分するか、また、一方のリソースが削られたときに何が最初に目に見えて破綻するかを記載します。これはチームが自ら答える質問のセットとして扱い、公式として扱わないでください。

   • どの活動が最初に担当者を失いますか？
   • 参加者が最も早く気づく品質の低下は、どの活動で起きますか？
   • スポンサーが実際に費用を払っているのはどの活動ですか？

   資金のモデリングは samber/dev-event-organizer-skills@event-budget に回してください。

9. 各プロパティについて、追加・終了の基準を事前に日付入りで定めます。チーム独自の基準として、指名した指標、下限値、その値を下回る回が連続何回に達したら終了を話し合うかを記載します。プロパティの不振が始まってから書いた基準は、基準ではなく交渉です。基準に達したとき、話し合いで選べる誠実な結論は2つです。日付を決めて、どちらかを選ぶ必要があります。

   • 構成を変更する - 日付を定めたテストとしてのみ行います。変更内容を1つ指定し（形式、曜日、長さ、テーマ、対象者レベル）、実施回数を固定し、動かすべき指標を定め、最後に継続か終了かを決める日付を設定します。まず samber/dev-event-organizer-skills@event-market-fit で需要を確認します。誰も必要としていない仕事は、構成を変えても解決しません。
   • プロパティを終了する - 終了を告知し、その対象者を存続するプロパティへ案内します。

   低迷する2つのプロパティが同じ対象者を共有している場合は、統合する（構成メニュー）ことが第3の選択肢です。それ以外の選択肢、たとえば「様子を見る」ためにもう1回開催することは、失敗モードで示されている緩やかな衰退です。

10. チーム内で構成の判断に意見の対立がある場合は、推奨を提示するのではなく、ブレインストーミングモードに切り替えます。

    • トレードオフと推奨を添えた、ポートフォリオ構成案を2つか3つ提示します。
    • 質問は一度に1つずつ尋ねます。
    • 次に進む前に、計画の各セクションを検証します。

    チームがセクションごとに検討していないポートフォリオ計画を出してはいけません。

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

• 各目的の文と担当者を含む、プロパティの一覧。
• 存在するものと構想段階のものを明記した、ファネルの経路。
• 選択した共有インフラの段階と、採用しなかった段階。
• ケイデンスの方針と、リソース配分の方針。
• 日付を含む、追加・終了の基準すべて。

来年のポートフォリオ判断は、一般的な事例ではなく、このチーム独自の履歴をもとに始められます。

ポートフォリオの構成

セットに何かを追加するかどうかを判断します。以下の順位は既定値であり、絶対的な規則ではありません。

• 労力（時間、調整の必要性、取り組みに終了時期があるかどうか）：独立した第2の形式 > 低頻度の小規模形式 > 定期メディアプロパティ > 同時開催の追加企画 > 継続性を保つ場
• 価値（開催の間隔を越えて引き継がれる対象者と、旗艦企画では届かない対象者）：独立した第2の形式 > 低頻度の小規模形式 > 継続性を保つ場 > 定期メディアプロパティ > 同時開催の追加企画
• 効率：継続性を保つ場 > 低頻度の小規模形式 > 同時開催の追加企画 > 定期メディアプロパティ > 独立した第2の形式
• コンプライアンスコスト（審査が発生するか、取り消し可能性が失われるか）：独立した第2の形式 > 同時開催の追加企画 > 定期メディアプロパティ > 継続性を保つ場。一般的なケースでは、低頻度の小規模形式に伴うコストはありません。会場を用意して自由に参加できるようにするだけなら、何の約束も生じません。

インタビューの内容を踏まえて順位を見直します。

• 締め切りが迫っている（Q7）場合、継続性を保つ場と同時開催の追加企画の順位を上げます。どちらも2回目の制作サイクルが不要な段階です。

• 継続的に積み上げていくことが求められる（Q8）場合、継続性を保つ場と低頻度の形式の順位を上げ、開催の合間には何も得られない同時開催の追加企画の順位を下げます。

• 共同主催者が独自のプロパティを求めている場合、または会場を無料で利用できる場合（Q9）は、独立した第2の形式を通常の順位より上げます。

• 継続の場 - デフォルトの段階です。各回の開催期間中だけに限られない、常時利用できる特性を1つ備え、次回まで参加者をつなぎとめます（チャットスペース、リスト、情報発信の場など）。立ち上げコストはほぼゼロで、開催回の合間に勢いが途切れる問題に直接対処する唯一の段階です。ハッカソンネットワークが、常時利用できる開発者コミュニティプラットフォームを獲得し、このパターンを実証しています。参加者の成果が次の参加者にとって「永続的で、検索可能で、役に立つ」ものになり、次の開催回へ引き継がれます。これを活性化するのは samber/dev-event-organizer-skills@event-community-building の役割であり、このスキルの役割ではありません。このスキルが判断するのは、_ポートフォリオに含めるべきかどうか_だけです。

• 低頻度の小規模形式 - 同じブランドのもとで、旗艦イベントにつながる月例または四半期ごとのミートアップです。コミュニティカンファレンスの運営ガイドは、率直にこう勧めています。「地元のミートアップがない？ 問題ありません！ 始めましょう。四半期に一度でも、参加者が集まり始め、どんな人たちがいるのかがわかります。」継続の場に参加者が集まり、開催回の合間が依然として目に見えて閑散としているなら、そこからこの段階に進みます。最も価値が高い使い方は、独立したプログラムとしてではなく、研究開発と参加者獲得の場として活用することです。旗艦イベントのテーマに新たな関連性が生まれたらすぐに、実践的なセッションを開催します。すると、旗艦イベントの企画サイクルではこれほど早く見つけられないような、検証済みのコンテンツ案と、旗艦イベントに向けた関心の高い参加者の両方を、ミートアップで一度に生み出せます。

• 併設プログラム - 旗艦イベントと同じ会場、同じ日程で行う2つ目のプログラムです。ワークショップデーや、併設型の小規模サミットなどが該当します。このパターンでは、複数の共同ブランドカンファレンスをまとめ、会場、開催週、スポンサーを共有する地域開催イベントとして実施します。労力は限定的です。開催回ごとに追加するプログラムは1つだけで、新たな日程、会場、移動の判断も不要です。しかし、残りの11か月には何ももたらさないため、コストが低くてもミートアップより下位に位置します。

• 定期メディア企画 - 独自のペースで発信するポッドキャスト、ニュースレター、動画シリーズです。会場や地域の外にも届き、規模の上限はありません。コストが継続的にかかり、価値が積み重なるのも多くの号を重ねてからであるため、効率の面では併設プログラムより下位です。発信をやめた企画は活動停止と見なされるため、最初から始めなかった場合より悪い結果になります。リスナーが参加者に転換するかどうかは測定されていません。転換率を示す場合は独自に設定したものとして扱い、数値を断定的に提示してはなりません。

• 独自の日程で開催する独立した2つ目の形式 - 最も実施が難しい選択肢です。ハッカソン、スタートアップウィークエンド、2つ目のカンファレンスシリーズなどが該当します。メニューの中で最も価値が高い選択肢です。旗艦イベントでは構造上参加できない層（学生、初心者、聴衆ではなく開発者）に届き、スポンサーに販売できる機会も2つ目として生み出せるからです。一方で、まるごと2つ目の制作サイクルが必要になるため、効率を比べると毎回劣ります。次の3つをすべて満たす場合に限り、実施を検討してください。

  • 旗艦イベントが、安定した開催を少なくとも2回実施している。
  • 明確に異なる参加者層が、旗艦イベントの形式では対応できない企画を繰り返し求めている。
  • _別の人_が、最初から最後まで責任者を務められる。

  旗艦イベントの責任者が2つ目の企画も担当すると、両方の企画の質が落ちます。

重複する2つの企画の統合は、追加とは逆向きの構成変更です。上記の追加候補の順位付けの対象外です。ステップ9の「内容を変える」および「終了する」と競合するものであり、追加の各段階と競合するわけではありません。ステップ4で同じ参加者層を対象としていると判定され、どちらも参加者数が減少している2つ以上のミートアップ、または2つの小規模カンファレンスに適しています。企画を1つにまとめることで、分散していた参加者、ボランティアの時間、スポンサーとの対話を集約できます。次の3つをすべて満たす場合に限り、実施を検討してください。

• 重なるのはテーマではなく参加者です。参加記録やプロパティ間の参加率から、似た肩書きの人たちではなく、同じ人たちが両方に参加していることが分かります。
• どちらのプロパティにも、常連がそのプロパティを目当てに参加するような独自の魅力がありません。片方の参加者を呼び込んでいた理由を取り除いた統合イベントでは、その参加者を失います。
• 吸収されるプロパティの主催者が残り、統合後のプロパティで明確な役割を担います。自分のプロパティを持ちたがっていた共同主催者（Q9）がいる場合、通常は統合を避ける理由になります。失われるボランティアの力が、統合による節約を上回ることがあるためです。

ステップ9のテストのように進めます。日付を定めた判断を行い、まず1〜2回合同で開催してから、両方を継続するか、統合するか、片方を終了するかを決めます。統合してもオーディエンスリストは統合されません。それぞれのプロパティのリストに、そのリストの同意条件に従って告知し、参加者が統合後のプロパティへの登録を選べるようにします（共有オーディエンスリストの段階）。ミートアップの運営チームが異なる場合、統合に伴ってチームも統合されます。ガバナンスについては samber/dev-event-organizer-skills@event-team-structure を参照してください。別々のチームのままで行う合同開催は、パートナーとの協業に当たり、samber/dev-event-organizer-skills@cross-event-promotion で扱います。

フラッグシップとの関係が告知されておらず、共有リストも相互プロモーションの経路もない、独自の名前で運営される2つ目のプロパティは、このメニューの最下位に置くのではなく、削除します。ポートフォリオの価値は、プロパティ間のファネルにあります。つながりのないプロパティは、相乗効果を一切もたらさずに、同じチームの時間をめぐって自社のフラッグシップと競合する別個のイベントです。最下位に置くと、共同主催者が独自ブランドを持ちたいと思った時点で、再び候補に戻ってしまいます。

共通インフラの深さ

プロパティ間で何を共有するかです。段階は累積的で、各段階はその上の段階を前提とします。以下の順位は既定のものであり、絶対ではありません。

• 労力（立ち上げ、調整、法務・同意に関する作業、可逆性）：1つの法人と予算 > プロパティ横断のスポンサー向けパッケージ > 共通チームとプレイブック > 共有オーディエンスリスト > ブランドのみの共有
• 価値（実際に機能するファネル経路、プロパティ間で動く資金、次のプロパティの負担を減らすもの）：共有オーディエンスリスト > プロパティ横断のスポンサー向けパッケージ > 共通チームとプレイブック > 1つの法人と予算 > ブランドのみの共有
• 効率性：共有オーディエンスリスト > ブランドのみの共有 > 共通チームとプレイブック > プロパティ横断のスポンサー向けパッケージ > 1つの法人と予算
• コンプライアンスコスト（審査の発生、可逆性の低下）：1つの法人と予算 > プロパティ横断のスポンサー向けパッケージ > 共有オーディエンスリスト > 共通チームとプレイブック。ブランドのみの共有にはコストはありません。

インタビューの内容に基づいて順位を調整します。

• コミュニティと企業が混在するポートフォリオ（Q5）では、資金の境界をまず明文化する必要があるため、共通法人の優先度を大きく上げます。
• 2つのプロパティと個別に契約を更新しているスポンサーがいる場合（Q9）は、プロパティ横断のパッケージの優先度を上げます。
• 厳しい期限がある場合（Q7）は、パッケージと法人の優先度を下げます。どちらも短期間では実現できない段階だからです。
• ブランドのみの共有 - 1つの名称、1つのビジュアルシステム、すべてのプロパティを掲載する1つのページです。労力はほぼゼロで、価値は最も低く、まさにその理由から効率性では2番目です。プロパティ間で認知をほぼコストなしに引き継げるためです。これは最低ラインであって、ポートフォリオではありません。
• オーディエンスリストの共有 - 標準となる段階であり、最も価値が高いものです。すべてのプロパティにまたがる1つのオーディエンス記録を用意し、どのプロパティに参加した人にも、別のプロパティについて案内できます。これこそがファネルです。これがなければ、ステップ3の道筋はすべて願望にすぎません。同意はプロパティごとに引き継ぐ必要があり、プロパティ間で共有されるものとみなしてはいけません。
• チームとプレイブックの共有 - 同じ運営メンバーと、行動規範、ベンダーリスト、会場との関係、テンプレートなどの運営資産を共有します。これにより、3つ目のプロパティを2つ目より低コストで運営できます。多くのチームが見落とすコンプライアンスコストも伴います。プロパティをまたぐ行動規範があると、あるプロパティでの出入り禁止が他のプロパティにも適用されます。これは初めて適用する前に文書化しておく必要があり、問題が起きてから書いてはいけません。ツールをプロパティ間で共有するようになったら、それぞれのストレージシステムの用途を明確にし、用途に合わなくなったものはすべてアーカイブしてください。写真は一か所、スライド資料と認証情報は別の場所に保管し、2つ目のプロパティが1つ目の場当たり的なフォルダーを再利用できると思い込んだせいで、あちこちに散らばったままにならないようにします。
• プロパティ横断のスポンサー向けパッケージ - 十分に活用されていない選択肢です。1回のスポンサーとの話し合いで、複数のプロパティを対象とする1つの契約を結びます。この段階はまだ検証されていません。同じ会場、週、スポンサー候補を共有する併設カンファレンスはありますが、それは複数のプロパティを対象とする1つの契約を結ぶこととは異なります。また、そのようなパッケージを販売する運営者も、それを求めるスポンサーも、確立された慣行ではありません。
  • パッケージを標準的な慣行として提示してはいけません。また、パッケージ価格を通常価格として提示してはいけません。
  • 同じスポンサーがすでに2つのプロパティで個別に契約を更新しており、パッケージが新たな関係を作り出すのではなく既存の関係を正式な形にする場合に限り、また、すべてのプロパティにわたる履行を1人が担当できる場合に限り、提案してください。
  • 最初のパッケージはテストとして扱い、個別契約に戻す場合の担当者を明記してください。価格設定は samber/dev-event-organizer-skills@event-sponsor-pricing に回してください。
• 単一の法人と予算 - すべてのプロパティを1つの法務・財務上の枠組みで扱い、収益のあるカンファレンスで無料のミートアップを相互補助できるようにします。これは現実的で、相互補助を適切に行う唯一の方法です。しかし、最も労力がかかり、選択肢の中で最も元に戻しにくいため、まだ必要としていないチームにとっては、効率性を競うあらゆる段階で最下位になります。

あるプロパティの参加者リストを、そのプロパティ固有の同意なしに別のプロパティのマーケティングに利用する選択肢は、格下げではなく、この一覧から削除されています。これは、最も価値の高い段階を最も安く見せる方法であり、プロパティごとに同意を取得することは、その段階の設計要件であって、コストのかかる追加オプションではありません。後回しにすると、ローンチ期限の1週間前に再び持ち上がります。

開催時期の調整

年間を通じて、各プロパティの日程がどのように関係するかを示します。以下の順位は標準的なものであり、絶対的なルールではありません。

• 労力：固定の複数年ローテーション > 同一会場での共同開催 > 季節ごとの波 > 基準日から間隔を空けて配置 > 場当たり的
• 価値（競合を避けて対象者に届けられること、そしてチームが年間を通じて持ちこたえられること）：基準日から間隔を空けて配置 > 同一会場での共同開催 > 季節ごとの波 > 固定の複数年ローテーション > 場当たり的
• 効率性：基準日から間隔を空けて配置 > 季節ごとの波 > 同一会場での共同開催 > 固定の複数年ローテーション > 場当たり的
• コンプライアンスコスト：会場を事前に確約する2つの方式でのみ発生します。固定の複数年ローテーション > 同一会場での共同開催。基準日から間隔を空けて配置、季節ごとの波、場当たり的な方式では、各プロパティが通常どおり契約するもの以外に、何も契約しません。

インタビューの回答を踏まえて、順位を見直します。

• 対象者があなたに会うために移動する場合（Q3）、あるいは共通の会場とスタッフで1つの設営のまま2つのプログラムを実施できる場合（Q9）は、いずれも、選択肢が限られがちな同一会場での共同開催を上位に押し上げます。

• チームがすでに限界に達している場合（Q9）は、季節ごとの波が有力です。回復のための期間を意図的に確保する唯一の方式だからです。

• 基準日から間隔を空けて配置 - 標準の方式です。まず旗艦イベントの日程を決め、その後、ほかのすべてのプロパティを均等な間隔で空き日に配置します。衝突を防ぎ、年間を通じて開催を継続するという、ポートフォリオの2つの目的を両立するうえで、最も費用のかからない方式です。主にカレンダー上の調整で済み、年に一度繰り返すだけです。

• 季節ごとの波 - プロパティを2つまたは3つの開催集中期間にまとめ、その間には意図的に静かな期間を設けます。ある財団は、年間を均等に配置するのではなく、四半期ごとの開催集中期間を設け、年間およそ67件のイベントを実施することで、この方式を示しています。小規模チームにとっての真の価値は、静かな期間を確保できることです。回復を予定に組み込む唯一の方式であり、自然に時間が取れることを期待するのではありません。

• 同一会場での共同開催 - 選択肢が限られがちな方式です。2つ以上のプロパティを意図的に同じ会場、同じ日程で開催します。規模が大きい場合は、旗艦イベントの地域版1回に、複数の共同ブランドのカンファレンスを同じ会場、同じ週にまとめます。移動の判断が一度で済み、設営もスポンサーへのアピール機会も1回で済むため価値は高いものの、すべてのプロパティで必要となるピーク時の人員配置を1つの週末に集中させるため、労力も大きくなります。対象者があなたに会うために移動する場合、または同じ予約と同じスタッフで、追加の設営なしに両方のプログラムを本当に実施できる場合は、この方式を上位にしてください。

• 固定の複数年ローテーション - 数年前から開催枠を固定します。旗艦イベントを中国、北米、ヨーロッパで、毎年公表するサイクルに沿って開催地を変える方式がその例です。参加者やスポンサーが計画を立てやすい予測可能性が得られますが、そのメリットが生まれるのは、開催回数や地域が多い場合に限られます。また、チームの対応能力が変化した場合でも、事前に決めた予定を柔軟に変更できません。

• 場当たり的 - 方式を設けず、各プロパティの担当者が、準備が整った時点でそれぞれの日程を決めます。一見、自由に見えますが、実際はそうではありません。調整の手間がほぼゼロに見える一方で、発生する衝突によって対象者とチームに生じる損失は、回避できた調整の手間を上回るため、労力の少なさから想像するより費用対効果が低くなります。これは、以下に示す最初の失敗パターンです。

予約やスタッフを共有せずに、別々の会場で2つのプロパティを隣接する日に開催する方式は、このリストから除外します。最下位に置くのではなく、順位付けの対象外です。これは同一会場での共同開催が掲げる「1回の移動、1つの週末」という利点を、その実現手段なしに求めることになります。対象者には、どちらかを選ぶか、両方に参加するよう求めることになり、チームは48時間以内に2回の設営をすべて行わなければなりません。最下位に追いやっても、2人の担当者が同じ繁忙期の週末にそれぞれ別の会場を希望するたびに、また候補に戻ってきます。

失敗パターン

• 同じ四半期に、同じ対象者向けのプロパティが2つある。 8週間の間に、対象者には2晩分の時間も、チケット代を2回分払う予算もありません。チームにも、立ち上げを2回行う余力はありません。ステップ4のカレンダーはこの問題を防ぐためのもので、最もよく起きるのは日程そのものではなく、_立ち上げ_の重複です。どちらのプロパティも動かせず、両方とも参加者数が減っている場合、解決策は日程を2つ設けることではなく、プロパティを1つにすることかもしれません。構成メニューの「統合」を参照してください。
• 旗艦プロパティが安定する前に、別のプロパティを追加する。 ステップ7の安定性ゲートは、このスキルにおける唯一の厳格なゲートです。不安定な旗艦プロパティに新しいプロパティを加えると、弱いプロパティが2つと、疲弊したチームが残ります。しかも、機能していたのは旗艦プロパティのほうです。
• フランチャイズをポートフォリオとして扱う。 1つの共通ブランドのもとにある独立したチームには、採用、審査、分散した基準の徹底が必要ですが、ここにあるどのメニューもそれらには対応していません。早い段階でその違いを認識すれば、ガバナンスの問題に構成のロジックを適用してしまうのを防げます。
• 複数プロパティをまたぐスポンサー向けパッケージを、確立された慣行として売り込む。 最初のパッケージは、あくまで代替案を用意したテストとして提示してください。通常のやり方として紹介してはいけません。また、まとめた価格を市場相場として提示してはいけません。
• 終了基準を書かなかったために、プロパティが存続する。 プロパティが終わるのは参加者が少ないからではありません。話し合いの予定を誰も立てなかったからです。あらかじめ基準を定め、最低ラインと開催回数を明記しておけば、誰かの大切なものをめぐる言い争いではなく、意思決定につなげられます。
• 本当の問題はコンセプトの陳腐化なのに、終了基準に頼る。 旗艦プロパティの勢いが衰えたとき、それが必ずしもポートフォリオの問題とは限りません。プロパティとして廃止する前に、そのテーマや形式が単に新鮮味を失っただけではないか確認してください。逆の失敗は、ゆっくりとした漂流です。終わりを決めず、開催のたびに内容を微調整し続けるうちに、参加者が減っていくイベントにチームが疲弊します。内容を変えるのが妥当なのは、ステップ9に記載された期限付きのテストとして実施し、継続か廃止のどちらかで終える場合に限られます。新しい内容そのものは、プロパティ固有の形式を扱うスキルの範囲です。このスキルが判断するのは、そのプロパティが今も全体の一部としてふさわしいかどうかだけです。
• 継続的な交流の場が、いつの間にか4つ目のプロパティになる。 常時利用できる場に、責任者もモデレーション計画もなければ、見かけほど手軽な選択肢ではありません。行動規範だけが添えられた、担当者不在のプロパティです。
• ロゴの共有を導線と取り違える。 ステップ3では、それぞれの経路を_実在_または_将来的な構想_として記録します。4つのプロパティを並べたポートフォリオページは、実際に人がプロパティ間を移動しているかどうかにかかわらず、見た目がまったく同じだからです。

測定

以下の各しきい値はすべて自分たちで設定するものです。そのため、初年度の数値を見てから目標と呼ぶのではなく、あらかじめ各下限値を定めてください。

• プロパティ間の継続参加率 - あるプロパティの参加者のうち、12か月以内に別のプロパティにも参加した人の割合です。これがポートフォリオなのか、単なる寄せ集めなのかを示す唯一の数値です。各ペアの下限値を、年が始まる前に設定します。どちらも縮小している2つのプロパティ間で継続参加率が高い場合、それはマージの兆候であり、ファネルが成功しているという意味ではありません。
• 空白期間のカバー率 - 年間で、あらゆる種類のタッチポイントがない期間の最長日数です。継続性を担う仕組みの役割は、これを短縮することです。
• 単独オーナーのカバー率 - 最初から最後まで運営できる担当者が1人だけ明確に割り当てられているプロパティの割合です。担当者が0人のプロパティはすでに失敗しています。1人が2つを担当している場合、それはカレンダーでは捉えられない衝突です。
• 基準の文書化率 - 追加・終了の基準が紙面に記され、シーズン開始前の日付が入っているプロパティの割合です。

数値ではなく構造に関する合格基準が1つあります。一覧にあるすべてのプロパティに、目的を示す一文、明確な担当者、文書化された終了基準があること。例外は認めません。 3つのうち1つでも欠けているプロパティがあるポートフォリオ計画は、継続参加率がどのような数値であっても未完成です。

次の3つの問いは、チーム自身が答える必要があります。

• 配分と、最初に破綻するもの。
• 追加・終了の基準と、その理由。
• プロパティ横断のスポンサー向けパッケージを販売するか、求められているか。

ワークフローはその段階で数値ではなく問いのセットを提示します。架空の数値で埋めないでください。

呼び出し例

• 「毎月のミートアップと年次カンファレンスを運営しています。来年はハッカソンを追加すべきでしょうか？」
• 「カンファレンスは完売しますが、参加者はその後11か月間姿を見せません。これを補うプロパティは何ですか？」
• 「イベントが4つあり、チームは1つで疲弊しています。どれを終了すべきでしょうか？」
• 「2つのミートアップに、同じ縮小傾向の参加者が集まります。統合すべきでしょうか？」
• 「ミートアップ、カンファレンス、ポッドキャストをまとめたスポンサーシップを販売できますか？」

期待される出力：測定の項で説明したポートフォリオ計画を、検証のためセクションごとに提示します。

• 目的と担当者を記したプロパティ一覧。
• 実在か、構想段階かを示したファネルマップ。
• 衝突カレンダー。
• 選択した共有インフラの段階と、採用しなかった段階。
• 開催頻度の方針。
• 配分の方針。
• 構成の決定。
• 日付を含む、プロパティごとの追加・終了基準。

参考資料

• references/portfolio-case-record.md - 各段階の根拠となる、実際の複数プロパティのポートフォリオ3件。それぞれが実証していることと、実証していないこと、そしてチーム自身が決める必要がある3つの事項。
• references/inventory-funnel-and-kill-criteria.md - プロパティ一覧、ペアごとのファネルマップ、積み上げ式の衝突カレンダー、日付入りのレシピ変更テストを含む終了基準テンプレート、スポンサー向けパッケージのテストの具体例と、それぞれの悪い例。

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

• samber/dev-event-organizer-skills@event-format-selection - このスキルで追加を決めたプロパティの形式を選びます。
• samber/dev-event-organizer-skills@event-market-fit - 構成が新しいプロパティの存在を前提とする前にその需要を検証し、終了基準に達した際にレシピを変更する前に需要を確認します。
• samber/dev-event-organizer-skills@cross-event-promotion - 他チームが運営するミートアップとの合同イベントや相互プロモーションを扱います。チーム間の統合を試す合同開催回も含みます。
• samber/dev-event-organizer-skills@event-date-selection - ここで選んだ開催頻度の方針に沿って、各プロパティの実際の日付を選びます。
• samber/dev-event-organizer-skills@event-marketing-plan - このスキルで確定したカレンダーに沿って、プロパティごとの集客キャンペーンを実施します。