event-date-selection

イベント開催日の選定

技術イベントのスケジュール調整アドバイザーとして、開催日を選定します。参加者が実際に参加できる曜日、季節や各種カレンダーを踏まえた開催可能期間、避けるべき、または意図的に連携すべき競合イベント、会場が対応できる候補日程、そして開催日を公表するタイミングを決めます。

このスキルは、開催日が公表された時点で終了します。関連する3つのスキルとの境界は次のとおりです。

• 開催日の決定後にさかのぼって予定を組む作業は、samber/dev-event-organizer-skills@event-planning-timeline が担当します。
• 競合イベントを、そもそもイベントを開催すべきかどうかを判断するための 需要 の指標として分析するのは、samber/dev-event-organizer-skills@event-market-fit が担当します。ここでは、同じカレンダーを 日程調整上の制約 として扱います。
• 会場の選定は、samber/dev-event-organizer-skills@event-venue-sourcing が担当します。このスキルでは、開催日と会場を一体の決定事項にするための、空き状況の確認と交渉だけを利用します。

祝日と季節性に関するガイダンス

記憶や一般的なルールをもとに、祝日カレンダーを作り上げてはいけません。MLH と DevOpsDays のガイドによると、祝日が参加者に与える影響は異なります。MLH の記録では、一般には休暇中の参加が減る一方で、短い大学の休暇期間は週末開催の単発イベントへの参加率を 高める 可能性があり、文化的な背景によっては祝日が「より多くの人を集めるすばらしい機会」になるとされています。季節性は、事実として断定せず、ユーザー自身の過去の開催実績と照らして検証すべき仮説として扱ってください。

references/audience-calendars.md には、カレンダーのカテゴリを確認するためのチェックリストと、日付を作り上げることなく特定の年の各カテゴリを確認する方法が記載されています。ウェブを閲覧できない場合や、ユーザーからカレンダーを提供してもらえない場合は、日程に問題がないと断定せず、確認が未完了であると伝えてください。

参加者が基準にするカレンダー

このスキルで最初に決める、最も重要な点は、参加者がイベントに費やす時間を、誰が管理しているかです。

• 勤務時間を基準にする参加者（仕事の一環として参加する社会人）— DevOpsDays の開催ガイドでは、平日開催を明確に推奨しています。「DevOps は人々の仕事の一部であり、週末は通常、家族と過ごして活力を取り戻すために使われます」。週末開催では、この参加者に仕事のために個人の時間を使ってもらうことになり、職場ではなく家族との時間と競合します。
• 個人の時間を基準にする参加者（学生、趣味で活動する人、副業プロジェクトに取り組む人）— MLH のハッカソン開催者向けガイドでは、メンバー向けイベントは週末開催が 必須 とされています。最も早い開始時刻は金曜の夜、最も遅い終了時刻は日曜です。また、優勝者の発表に「締めくくりの実感」を持たせるため、日曜の午後に終了する形が推奨されています。ここで平日開催にすると、授業、試験、アルバイトと重なります。

制約が正反対なので、同じ判断でも既定の選択肢は逆になります。2つの条件を平均してはいけません。混合した参加者向けに金曜と土曜を組み合わせる妥協案は、それぞれのルールの悪い部分を取り入れることになります。学生に休みを取れない勤務日と、社会人が仕事を休んでまで使おうとしない個人の日です。参加者が実際に二分される場合は、どちらを主な対象としてイベントを設計するのかを選び、その理由を明示してください。その判断は samber/dev-event-organizer-skills@event-positioning が担当します。

時間帯：夕方の枠から排除される人

開催日の種類だけでは、時間帯は決まりません。平日の夕方は、勤務時間に合わせて参加する人には空いているように見えますが、介護や育児を担う人が参加を断念する時間帯です。

• 主催者の報告によると、夕方のイベントでは主に育児のために女性の参加が減り、経験豊富な実務者も家庭の事情で夕方の参加を見送ることがあります。
• 同じ報告では、開催枠を昼間やランチタイムに移した場合や、テーマの幅を広げた場合（プロダクトをテーマにしたカンファレンス、人事系のミートアップと共同開催したワークショップ）に、女性の参加割合が上がったとされています。
• どちらも測定された効果ではなく、報告として扱ってください。性別や介護者であるかどうかを同意のうえで収集している場合は、自分たちの登録データと照合してください。

開催日タイプとあわせて、イベントの開催枠（午前、ランチ、午後、夕方）を記録し、誰が参加できなくなるかを明記してください。避けられない夕方開催の負担を軽減する措置（託児、介護者向けチケット）は、samber/dev-event-organizer-skills@event-accessibility-inclusion に振り分けてください。

定期シリーズ：日付だけでなく開催枠もローテーションする

単発イベントでは、開催枠は1つです。月次または四半期ごとのシリーズでは、_パターン_が決まります。パターンが固定されると、毎回同じ人が参加できなくなります。

• 毎週火曜の夕方に固定すると、スポーツクラブ、親権に関する取り決め、毎週の講座など、火曜に定期的な予定がある人は参加できなくなります。各回の参加者が少ないようには見えません。該当する人はどの回のデータにも現れないため、参加者の減少に気づけません。
• ある月次シリーズでは、同じ曜日と時間を2回連続で使わず、形式もローテーションしていました（夕食会、ランチ、仕事帰り、講演、自由参加のセッション）。数年にわたり、安定した参加者数を維持したと報告されています。
• ローテーションにより、習慣として定着しにくくなります。「第1火曜」と覚えていた常連も、毎回の告知を確認しなければならなくなります。その負担は開催枠を固定するのではなく、告知で補ってください。

ローテーションパターンの選択肢。このスキルが独自に構成したものであり、順位付けされた選択肢ではありません。

• 固定枠 - 曜日と時間を1つに固定します。習慣化しやすい一方、その枠に予定がある人は継続的に参加できません。会場が提供する枠が1つだけの場合は、妥当な選択肢です。
• 曜日をローテーションし、時間は固定 - 曜日の予定が重なる人を分散できますが、夕方やランチに参加できない人の問題は残ります。
• 曜日と時間をローテーション - 曜日と時間の両方の予定の重なりを分散できます。形式のローテーションとも自然に組み合わせられます。形式は samber/dev-event-organizer-skills@event-format-selection とあわせて決めてください。

インタビュー

質問は一度に1つずつ、可能な場合は選択肢形式で尋ねます。まず質問1から始めます。他の条件を検討する価値があるかどうかを判断する前に、開催日のタイプを決めるためです。質問4〜6があるのは、以下のメニューが効果の現れる速さ、持続性、労力の面で大きく異なるためです。既定の順位をユーザーに代わって選ぶことはできません。

1. 参加者の時間を誰が負担しますか。勤務時間中の社会人、プライベートの時間を使う学生や趣味を楽しむ人、あるいはその混合ですか。（他の何よりも先に、平日か週末かを決めます。）
2. 参加者はどこから来ますか。1つの都市、1つの国、それとも複数の国や文化圏ですか。（カレンダーの確認範囲と、深度メニューで不足している段階を繰り上げるかどうかが決まります。）
3. すでに決まっていて、変更できないものは何ですか。共同開催の基準となるイベント、予約可能な時間帯が1つだけの会場、スポンサーの会計年度、学期などですか。（固定の制約があれば、候補期間を生成する前に候補から除外できます。）
4. イベントを開催しなければならない日、または開催期限はありますか。（厳格な期限があれば、すぐに効果が出る段階の優先度が上がり、最も早い告知のきっかけを迫られる場合があります。）
5. 単発のイベントですか。それとも、価値を積み重ねていく毎年の資産の1回分ですか。（継続開催のイベントでは、参加者が開催時期を予想するようになるため、定着した時期の価値が高まり、告知済みの日程を撤回する代償もはるかに大きくなります。）
6. 日程調整にかけられる労力の上限はどの程度ですか。作業に使える時間と、決定前に相談できる人数を教えてください。
7. 資金を扱う手段は整っていますか。チケット販売、決済処理、資金を受け取れる法人などですか。（これは好みの問題ではなく、告知するための前提条件です。以下を参照してください。）
8. メニューの優先順位を変えるべき資産はありますか。過去の開催日と参加者数、会場との継続的な関係、すでに調整対象となっているエコシステムの基準日、チームがカレンダーをすでに把握しているコミュニティなどですか。
9. 希望する開催期間は他と競合していますか。別のイベントや予約に先を越される可能性はありますか。
10. これは定期シリーズ（月次、四半期ごとなど）の1回分ですか。また、現在は固定の曜日と時間に開催していますか。（§ 定期シリーズを適用するかどうかが決まります。）
11. 予定している時間帯はいつですか。午前、昼食時、午後、夕方のいずれですか。その時間帯に、対象者のうち誰が介護や育児の責任を担っていますか。（§ 時間帯を参照してください。）

日程制約の確認レベル

累積式です。各レベルには、それより下のレベルも含まれます。優先順位（標準的なものであり、絶対ではありません。Q2を最優先に、またQ6とQ8を踏まえて順位を見直してください）。

• 労力（日程を決められるようになるまでの時間と、相談が必要な人数）：複数地域の記念日確認 > 競合イベントの調査 > 対象者のカレンダー確認

• 価値（参加を守れる度合い。告知後に誤りを取り消せない度合いで重み付け）：対象者のカレンダー確認 > 競合イベントの調査 > 複数地域の記念日確認

• 効率：対象者のカレンダー確認 > 競合イベントの調査 > 複数地域の記念日確認

• 対象者のカレンダー確認 - 最低限の確認です。前のセクションで説明した曜日の種類に加え、対象者自身が所属する機関のカレンダーを確認します。表にある選択肢の中で、1時間あたりの価値が最も高い確認です。曜日の種類を誤ることは、参加者数に対する単独で最大の失敗であり、しかも避けるためのコストはかからないからです。

  • 学生が対象の場合：MLHのガイドでは、試験、大学の休業期間、主要な学内イベントが挙げられています。
  • 社会人が対象の場合：同等のものは、勤務先の四半期末と、参加者の子どもが通う学校の休暇です。

• 競合イベントの調査 - 対象者のカレンダー確認のほうが効率面では上位ですが、推奨される標準の確認です。この確認では、対象者の外部で発生する唯一の失敗、つまり別のイベントが開催日と重なり、参加者がそちらに拘束される事態を、構造上見逃してしまいます。調査には1〜2時間かかり、その大半は見つかった候補を一つずつ確認する時間です。この失敗を検知できるのはこのレベルだけです。Q3によって日程がすでに外部要因で固定され、調査結果がどのようなものであっても変更の余地がない場合に限り、省略できます。

• 複数地域の記念日確認 - 十分な検討が行われにくい選択肢です。意味のある割合の参加者が移動してくる地域すべてについて、国民の祝日、宗教上の記念日、学校のカレンダーを、その年の実際の日付で照合します。上記の価値の順位では、対象者が単一地域にいると暗黙に仮定されているため、効率の面では常に下位になります。このレベルは、その仮定を検証するためのものです。Q2で単一地域ではないとわかった時点、または同じ都市に異なるカレンダーに従うコミュニティが含まれる場合は、すぐに優先度を上げてください。カテゴリのチェックリストはreferences/audience-calendars.mdにあります。具体的な日付はこのスキルには含まれていません。

Q3によって単一の日程が外部要因で固定され、自分たちの管理下では何をしても変更できない場合、対象者のカレンダー確認より上位のレベルはすべて降格ではなく削除してください。メニューと上記の軸の行の両方から削除します。 調査結果が判断を変えられないなら、それはより安価な確認ではありません。判断に結びつかない確認です。メニューに残しておくと、固定された日程で最も対策に使う必要のある時間を消費します。すでに把握している競合は、このメニューの確認レベルに戻すのではなく、samber/dev-event-organizer-skills@event-risk-managementでハザードとして扱ってください。

競合イベント：制約であり、好機でもある

競合イベントが必ずしも致命的とは限りません。そう考えてしまうと、分野で最も役立つ日程調整の手段を捨てることになります。

• 競合の回避 - DevOpsDays の主催ガイドでは、分野全体のカレンダーを確認することを、主催者一人の参加者数を守るためだけでなく、分野全体での「負荷分散」と位置付けています。まず正確な開催日を検索し、次にその前後を含む週全体を確認します。同じ週のイベントは、日程が重なっていなくても、旅費、休暇日、登壇者を奪い合います。テーマに関係のない大規模な地域イベントも確認の対象に含めましょう。テーマに関係なく、会場、ホテルの部屋、交通機関、地域の人々の関心を占めるからです。
• 相乗り - 同じガイドでは、これを意図的な前向きの戦略として挙げています。同じ都市で別の大規模イベントの直前または直後に開催すれば、参加者は一度の移動で両方に参加できます。これは通常の考え方を逆転させるものです。近隣の大規模イベントは、開催時期を避ける理由ではなく、むしろその時期に近づける理由になり得ます。
• エコシステムの基準日 - MLH のガイドでは、自らの主催者カンファレンスを、サブ分野全体が日程を調整する固定日として扱っています。自分のエコシステムにおける同様の基準日を見つけ、意図的に避けるか、連動させるかを決めましょう。

単一のイベント系列の公式ホームページだけでは、テーマや主催者をまたいだ情報を網羅できません。クラウドソーシング型の公開カンファレンスカレンダーである confs.tech は、この不足を補うツールの一例です。必須の依存先ではなく、すでに利用している主催者に情報が偏る点にも注意してください。調査手順と代替手段については、references/competing-events-and-announcement.md を参照してください。

一つの日程ではなく、複数の候補期間

日程を一つに決めてから会場に問い合わせるのはやめましょう。DevOpsDays のガイドでは、この実践を 「選択肢を用意する」 と呼んでいます。週や月によって空き状況は一様ではないため、複数の候補期間を用意して会場と相談します。「週の特定の時期のほうが、ほかの時期より対応してもらいやすい場合がある」からです。

日程と会場は一体として決めるものです。実現可能な候補期間を3つ用意して相談に臨めば、断られて終わるのではなく、交渉に移れます。制約の確認を通過した候補期間を3～5つ用意し、samber/dev-event-organizer-skills@event-venue-sourcing に渡して、空き状況に基づいて順位付けしてもらいましょう。

告知の開始条件

DevOpsDays ガイドにある、すべての段階に適用される厳格な条件です。**資金を扱う方法があると確認できるまで、開催日を告知してはいけません。**決済手段が整っていないことに後から気づいたチームは、日程を変更したり、開催を中止したりしています。これは好みではなく前提条件です。告知していない開催日はまだ変数ですが、告知した開催日は約束です。

優先順位（既定の順序であり、規則ではありません。Q4、Q5、Q8 にある継続的な会場との関係を踏まえて、優先順位を見直してください）：

• 労力（公開前に完了させる必要があることと、待つことで失われるリードタイム）：program-teased > venue-locked > money-ready

• 価値（後から撤回する必要のない、確保できるリードタイム）：venue-locked > money-ready > program-teased

• 効率：venue-locked > money-ready > program-teased

• 会場確定後の告知 - 既定の選択肢です。会場契約の締結と資金面の条件クリア後に公開します。撤回がほぼ不可能な状態にしつつ、利用可能なリードタイムをほぼすべて確保できるため、価値と効率の両方で最上位です。

• 資金準備完了後の告知 - 資金面の条件をクリアした時点で、会場契約の締結前に公開します。待ち時間を最小限に抑えて最大限のリードタイムを確保できますが、実際に撤回が必要になるリスクを伴います。会場枠の争奪が激しく、早期に押さえる価値がそのリスクに見合う場合（Q9）、または継続的な会場との関係（Q8）により、最終的な契約締結がほぼ確実な場合に選択してください。

• プログラム予告付きの告知 - 最も条件が厳しい選択肢です。告知に単なる開催日以上の意味を持たせるため、主要登壇者の確定、または CFP の開始まで待ちます。労力が最も大きく、失われるリードタイムも最も長いため、効率を比較するすべての場面で最下位です。開催実績のない初回開催で、無名のイベントが日付だけを告知しても誰にも響かない場合は、この選択肢の優先度を上げてください。ただし、これは文書化された規則ではなく、判断に基づくものです。samber/dev-event-organizer-skills@event-first-edition が立ち上げ条件を定めているため、これを前提にする前に確認してください。

**Q7 の資金面の条件をクリアしていない間は、3 つの段階すべてを降格させるのではなく、削除してください。条件をクリアするまで、選択肢の一覧と優先順位の行を削除してください。**これがこのスキルにおける唯一の厳格な条件です。この条件をクリアしていない状態で告知方法の一覧を優先順位付きで示すと、最も安価な選択肢なら今すぐ実行できるように見えてしまいます。これは、記録に残る中止の原因となった判断そのものです。開催日は内部で決定し、何も公開せず、資金を扱う手段が整った時点で選択肢の一覧を再掲してください。

告知後は開催日を維持し、代わりに範囲を調整します。その後の対応は samber/dev-event-organizer-skills@event-planning-timeline が定めています。

ワークフロー

1. インタビューを実施します。何よりも先に、対象者が時間を誰のために使えるか（Q1）を確定します。
2. その回答に基づいて開催日の種類を設定します。雇用主のために使う時間が対象なら平日、個人のために使う時間が対象なら週末とし、ルールの出典となったガイドも記録します。
3. 開催時期の範囲を定めます。ユーザー自身が過去に開催した同種のイベントと、対象者の所属機関のカレンダーをもとに、おおよその期間を仮説として提示します。季節の事実として扱ってはいけません。
4. 選択した深度の段階で制約の確認を行い、対象者自身のカレンダーから外側へと確認を進めます。確認できなかった行事は、問題なしではなく未確認として報告します。
5. 各候補日について、まずその日に開催される他のイベントを調べ、次にその週全体（月曜日から日曜日まで）を調べます。見つかったイベントごとに、明示的に回避するか、便乗するかを判断します。
6. 残った候補期間を3～5件提示し、そのすべてを会場の相談（「選択肢を得る」）に持ち込みます。予約状況に基づいて順位を決めます。
7. 資金面の条件（Q7）を確認します。満たされていなければ中止します。日程は内部で決定できますが、公表してはいけません。
8. 選択肢から告知のきっかけを選んで公表し、確定した日程を企画タイムラインの関連担当者に引き継ぎます。
9. セクションごとに進めます。まず開催日の種類とその出典を示し、次に各候補期間を、それぞれを却下した制約とともに提示し、その後に告知計画を示します。次へ進む前に、それぞれについてユーザーの確認を得ます。

使用しているハーネスに永続メモリがある場合は、選んだ日程と開催日の種類、対象者が時間を誰のために使えるかを示す区分、確認したすべてのカレンダーと未確認のまま残したカレンダー、見つかった競合イベントと基準となるイベントおよびそれぞれについての回避・便乗の判断、却下した候補期間とその理由、告知日を記録します。次回の開催日選定では、これらを再導出せず、このリストを出発点にします。却下した候補期間の理由は、後から再構築できない情報です。

失敗しやすい点

• 決済対応が整う前に開催を告知すること。 このスキルで唯一の絶対条件です。これを省いたチームは、開催を延期したり、完全に中止したりしています。開催日は、公開した瞬間から約束になります。
• 平日／週末のルールを、参加者のタイプをまたいで平均化すること。 さまざまな参加者に合わせた折衷の枠を選ぶと、どちらのルールにとっても最悪の要素を取り込み、どちらの層にも合いません。どちらの層を優先するか決めてください。
• 競合イベントがあれば自動的に致命的だと考えること。 便乗開催は実績のある手法です。同じ都市で大規模イベントに隣接して開催すれば、旅行者が1回の旅行を正当化でき、参加者が増えることがあります。イベントごとに判断し、反射的に避けないでください。
• 記憶を頼りに祝日カレンダーを作ること。 このスキルで最も起こりやすい失敗であり、上記の祝日に関するガイダンスがある理由です。太陰暦や太陽太陰暦に基づく行事は年ごとに日付が変わるため、自信満々に間違った一覧を作ると、読者が実際のカレンダーを確認しなくなります。
• 「学校の休みはすべて避ける」という一般ルールを適用すること。 記録されている詳細な知見によると、休みは一般に参加を減らす一方で、短い休みは週末の単発イベントへの参加を_増やす_ことがあります。休みの種類で決めつけず、個別の休みを確認してください。
• 会場に相談する前に開催日を1つに決めること。 空き状況の問題が行き詰まりに変わります。候補日を複数用意すれば、交渉の余地が生まれます。
• 自分たちのイベント分野のカレンダーだけを確認すること。 ある分野のホームページに載っているのは、その分野のイベントだけです。実際に参加者を引きつける競合イベントは、隣接分野や別の主催者から生じます。
• 定期シリーズの曜日と時間を固定すること。 毎回、同じ人たちが参加できなくなります。登録しなかった人は参加者データにも現れないため、損失に気づけません。対策：曜日と時間を入れ替える（§ 定期シリーズ）か、枠を固定する理由を記録してください。
• プロフェッショナル向けイベントは平日の夕方がよいと決めつけること。 コストがかからない枠のように見えますが、報告によると、介護を担う人（その多くは女性）や、家族のいる経験豊富な実務者が参加しにくくなります。対策：時間帯と、参加できなくなる人を記録してください（§ 時間帯）。
• 準備不足を取り繕うため、告知済みの日程を変更すること。 登壇者、スポンサー、参加者からの信頼を損ない、特に定期イベントでは（Q5）、単発イベントよりはるかに大きな代償を払うことになります。代わりに、実施範囲を縮小してください。

測定

以下の各指標は、すべて自己設定です。日程候補に参加目標を結び付けると、このスキルが拒む、でっち上げの祝日カレンダーと区別がつかなくなります。そのため、以下のゲートでは参加者数ではなく、意思決定を評価します。

日程を公開する前に確認するゲート（結果ではなく意思決定についての合否）：

• 開催日の種類が、対象者の時間の使い方に合っていること。その根拠としたガイドの名称も明記します。
• チェックリストにあるカレンダーの各カテゴリが、確認済みであるか、未確認と明示されていること。何も確認せずに問題ないと想定してはいけません。
• 競合イベントの調査では、すべての候補日について、正確な日付と同じ週を対象にしていること。隣接するトピックや別の主催者も調べ、自分のイベントの系列だけに限りません。
• 公開前に資金面のゲートを通過していること。
• 会場との協議に候補期間を少なくとも3つ提示していること。ただし、Q3 で期間を固定する外的制約が示されている場合を除きます。その場合のゲートは、期間を固定している要因と、それを変更できる人を記録することです。このスキルでは、期間を強制された場合に候補の生成を止めるため、候補期間を一律に3つ求めるゲートでは、この手順そのものに反することになります。

各開催回の間で以下を記録し、次回の日程決定の入力として使います。いずれも自己設定であり、前回の判断が正しかったことの証明にはなりません。開催回の間には、ほかにも多くの要素が変化するためです。

• 告知後最初の1週間の登録者数を、前回の開催回と比較します。
• 選択した開催日の種類に対する欠席率。
• イベント後のアンケートで、競合を理由に挙げた参加者の人数。
• 定期開催のシリーズでは、曜日と時間帯ごとの参加者数と新規参加者の割合。これにより、慣例ではなくデータに基づいて開催日をローテーションできます。新規参加者の割合は samber/dev-event-organizer-skills@event-community-building で定義されています。
• 同意を得て収集している場合は、時間帯ごとの対象者の構成（たとえば、女性の割合）。

呼び出し例

• 「来春、リスボンで働くエンジニア向けの2日間の DevOps カンファレンスを企画しています。開催日選びを手伝ってください。」
• 「学生向けハッカソンが、同じ都市で3週間後に開催される別のハッカソンと重なっています。日程を変更すべきでしょうか。それとも、両立させる方法はありますか？」
• 「会場から3月の候補期間を2つ、5月の候補期間を1つ提示されました。どれを選び、いつ告知すべきでしょうか？」
• 「月例ミートアップはいつも火曜日の夜に開催してきました。このまま続けるべきでしょうか？」

期待される出力：根拠となる情報源を添えた開催日の種類、却下した候補期間ごとに満たせなかった制約を示した優先順位付きの候補期間3〜5件、確認済みおよび未確認のカレンダーの明示的な一覧、見つかった各競合イベントについて、避けるか便乗するかの判断、そして前提となるゲートを添えた告知の実施条件。手順を示す例と、望ましくない例は references/competing-events-and-announcement.md にあります。

参考資料

• references/audience-calendars.md - 対象者タイプのルールとその出典、カレンダーカテゴリのチェックリスト、日付をでっち上げずに特定の年の各カテゴリを確認する方法。
• references/competing-events-and-announcement.md - 競合イベントを調査する手順と代替策、便乗、会場との「選択肢を得る」交渉、告知の判定チェックリスト、および否定的な対照例を含む具体例。

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

• samber/dev-event-organizer-skills@event-planning-timeline - このスキルが選んだ日付をもとに作成する逆算スケジュールです。
• samber/dev-event-organizer-skills@event-market-fit - 同じ競合イベントカレンダーを、スケジュール上の制約ではなく需要のシグナルとして読み取ります。
• samber/dev-event-organizer-skills@event-first-edition - 第1回開催の告知が守るべきローンチの判定基準と準備期間です。
• samber/dev-event-organizer-skills@event-venue-sourcing - 候補期間を受け取り、空き状況をもとに順位付けします。
• samber/dev-event-organizer-skills@event-positioning - Q1で意見が分かれた場合、イベントがどちらの対象者層を重視するかを決定します。
• samber/dev-event-organizer-skills@event-cfp-design - 公募の締切日は、このスキルが確定した日付から逆算します。