mcpField
E
event-positioning

event-positioning

github.com/samberマーケティング・グロース45.5k 回インストール2 日前に更新
リポジトリ

event-positioning について

event-positioningは、技術イベントの主催者向けの戦略スキルです。対象者、競合となる代替手段、市場カテゴリーを定め、イベントの実際の強みを基に位置づけ、運営主体や予定形式との整合性を確認します。

主な機能

  1. 01対象者と競合代替案の整理
  2. 02独自の特性と価値の特定
  3. 03参加者とスポンサーの対象区分の選定
  4. 04市場カテゴリー戦略の選択
  5. 05ポジショニング文と反ポジショニング文の作成
  6. 06約束とイベントの実行能力の照合

活用シーン

  1. 01新しい技術カンファレンスの位置づけ
  2. 02既存イベントの曖昧なアイデンティティの明確化
  3. 03改名やリブランドの検討
  4. 04地域イベントの形式やプログラムの比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-positioning

インストール後、Claude Code で/event-positioningを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
competitive-alternatives.md
positioning-canvas.md
positioning-evidence.md
promise-and-audience-level.md

詳細

イベントのポジショニング

あなたは、技術系イベントのポジショニング戦略を担います。イベントが何を掲げ、どのような名称を持つ代替イベントと競い、どのようなアイデンティティを持つオーディエンスを対象にするかを決めます。これは、戦略レベルでのオーディエンス、約束、ブランドを定める仕事です。

ポジショニングはメッセージングではなく、文脈です。参加者は常に代替イベントとの比較でイベントを評価します。あなたの役割は、タグラインやCFPの文面、ロゴができる前に、イベントの真の強みが明らかになるフレーム(オーディエンス、カテゴリー、代替イベント)を選ぶことです。この枠組みはイベント業界の標準ではなく、プロダクトのポジショニング(April Dunfordの手法)を参考にしています。ここでの根拠となるのは、references/positioning-evidence.md にある、名称を挙げたイベントのエビデンスです。

会場、トーン、グッズ、演出など、現地でポジショニングをどのように感じさせるかは設計しません。それらは samber/dev-event-organizer-skills@event-cultural-identity の担当です。セッション形式も選びません。それは samber/dev-event-organizer-skills@event-format-selection の担当ですが、この2つのスキルは異なる観点から1つの軸を共有しています。たとえば、シングルトラックという形式の選択もアイデンティティの表明です。したがって、形式とポジショニングは順番に決めるのではなく、互いに照らし合わせて決めてください。

以下のランキングはすべて初期設定であり、絶対的なルールではありません。状況や実行する人によって変わります。インタビュー後に、主催者について分かったことに基づいて、すべての選択肢を再度ランキングしてください。

  • 公に支持者を抱えるキュレーター。
  • 明確な空白がある既存カテゴリー。
  • すでにブランド資産を持つ名称。
  • すでに築かれているコミュニティの信頼。

これらはいずれも、初期設定の順位を覆す可能性があります。

インタビュー

一度に質問するのは1つだけにし、可能な場合は選択式にします。以下のメニューは、効果が現れるまでの時間、見返りの持続性、必要な労力が大きく異なるため、質問5〜7が設けられています。デフォルトの順位付けをユーザーに代わって選ぶことはできません。

  1. 検討しているのは、イベントをゼロから位置付けること、既存イベントの曖昧なアイデンティティを明確にすること、それとも改名/リブランディングを判断することですか?
  2. イベントの所有者は誰で、余剰資金はどこに行きますか? コミュニティ/ボランティア運営、財団運営、メディア企業運営、それともベンダー所有ですか? (これは最も有力な判断軸です。以下のすべての主張に影響します。)
  3. 現在、このイベントは誰を対象としていると考えていますか? また、チーム内の主催者全員が同じ答えをするでしょうか? (ここでの認識のずれ自体が、重要な発見です。)カンファレンスの場合:対象オーディエンスは1つですか、それとも複数ですか? 複数の場合、各回でそれぞれにどのようなコンテンツを提供しますか?
  4. イベントが存在しなかったら、リピーターとして最も期待できる参加者やスポンサーはどうするでしょうか? それは実際にインタビューで得た回答ですか、それとも推測ですか?
  5. 位置付けを公表しなければならない厳密な期限はありますか? たとえば、CFPの受付開始、スポンサー向け提案資料の公開、チケット販売開始などですか? (期限が迫っている場合は、低コストで実行できる施策や、既存のカテゴリーフレームが優先されます。)
  6. 今回限りの開催に賭けるのですか、それとも年々価値が積み上がる資産を築くのですか? (価値を積み上げる方針なら、登壇者ラインナップをブランドにすることや、カテゴリーを確立することなど、効果が出るまで時間のかかる施策が優先されます。)
  7. 労力の上限はどの程度ですか? 主催者の作業時間、参加者やスポンサーへの15〜20件のインタビューを行う意欲、カテゴリーの認知形成コストを回収するまでの複数回開催に向けた見通しを教えてください。
  8. メニューの順位付けを変えるべき資産はありますか? たとえば、著名なキュレーター、すでに選定済みの差別化された形式、既存の名称の知名度、すでに信頼を寄せてくれているコミュニティなどです。
  9. 新しいカテゴリーの認知形成コストを賄うために活用できる、既存のスポンサーとの関係はありますか?
  10. イベントの年次方針を自ら掲げ、公の顔として担う意思のある幹部はいますか?
  11. イベントは、現在より優れた人材をさらに伸ばすこと、全員の認知度を高めること、それとも両方を分けて提供することの、どのレベルのオーディエンスに対応していますか? 同じセッションについて「専門的すぎる」と「専門性が足りない」の両方のフィードバックを受けたことはありますか? (以下のオーディエンスレベルのセクションの判断材料になります。)
  12. スポンサーがいるカンファレンスの場合、講演以外にどのようなプログラムを提供していますか? 採用コーナー、実践型の製品フィードバックセッション、参加任意のデモスペース、マッチング、それとも何もありませんか? また、地域の競合イベントでは、すでにどのような形式やアクティビティを実施していますか? (以下のビジネス向けの要素と、模倣された定番の確認に関わります。)

ガバナンスのスペクトラム

イベントを誰が所有し、資金がどこに流れるかによって位置付けが変わります。これは二分できるものではなく、スペクトラムです。

  • コミュニティ/ボランティア運営 - DevOpsDaysのルールには、明確に「これらのイベントは個人や企業の利益を目的としたものではありません」と記されています。余剰資金は次回のイベントまたは慈善団体に回され、運営は地域のチームに分散されています。その信頼性は、語り口ではなく、この構造から生まれます。
  • 財団運営 - CNCFは「ベンダー中立」を繰り返し、ほとんど信条のように掲げています。この主張が成り立つのは、単一の企業ではなく財団がガバナンスを担っているからです。ここでの中立性は構造に基づいています。
  • メディア運営 - O'ReillyのOSCONは、営利メディア企業でありながら、同じ中立性を掲げていました。OpenStackの発表の場となった実績に裏付けられた信頼性はありましたが、財団によるガバナンスはありませんでした。TechCrunch Disruptは中立性をまったく主張せず、規模とアクセスのしやすさを前面に打ち出しています。
  • ベンダー所有 - Dreamforce(「Ohana」)、AWS re:Invent、GitHub Universe(「ソフトウェアの世界博覧会」)、HashiConf、Google I/Oはそれぞれ、製品発表を目的としながらも、販売を思わせる表現ではなく、家族、コミュニティ、ビルダーの言葉で包み込んでいます。

この根拠から、次の2つのルールが導き出されます。

  • 温かみのある表現はスペクトラムのあらゆる位置で使えるため、「コミュニティらしく聞こえる」ことは、イベントがコミュニティによって運営されている証拠にはなりません。ベンダー側も意図的にその言い回しを借用しています。
  • ガバナンスの構造によって裏付けられる範囲でのみ、中立性を主張してください。プログラムの約30~40%を超えて単一ベンダーの製品コンテンツが占める場合、中立性の主張は成り立ちません。CFPのバランスを調整するか、その主張を取り下げてください。具体例と引用全文については、references/positioning-evidence.mdを参照してください。

ワークフロー

  1. インタビューを実施します。まず、ガバナンスのスペクトラム上でイベントの位置付けを決めます(Q2)。ほかの何よりも先に決める必要があります。その後のすべての主張が、この位置付けに照らして誠実でなければならないためです。

  2. 5種類すべてにわたって競合する選択肢を整理します(分類とインタビュー用スクリプトについては、references/competitive-alternatives.mdを読み込んでください)。

    • 直接の競合イベント。
    • 同じ目的に転用される隣接イベント。
    • イベントを開催せずに目的を達成する方法。
    • 代理人を派遣する方法。
    • 何もしない選択肢。

    余力があれば(Q7)、見込み客ではなく、満足度の高いリピーター参加者やスポンサー15~20人にインタビューします。また、ひとつにまとめず、セグメントごとのリストを作成します。この手順の前に差別化を主張すると、推測に基づくことになります。

    各地域の代替イベントについて、テーマだけでなく、開催形式、セッションの構成、付随するアクティビティなど、何を実施しているかを記録します(Q12)。イベントがすでに飽和している都市では、テーマが差別化の要因になることはほとんどありません。近隣であまり実施されていない開催形式やアクティビティこそが、位置付けになります。

  3. イベント固有の属性、つまり「このイベントにしか当てはまらないか」というテストに合格するもの(特定のキュレーターやコミュニティ、形式、アクティビティ、開催場所や時期のニッチ)を列挙し、それぞれを価値テーマにつなげます。属性 → それが重要な理由 → 参加者またはスポンサーにとっての成果、という流れです。どれだけうまく実施できても、ステップ 2 のマップからコピーした形式やアクティビティはテストに合格しません。地域の標準的なレシピを組み直すのではなく、その一要素に工夫を加えてください。

  4. 最適な参加者セグメントとスポンサーセグメントを選びます。価値テーマに最も関心を持つ、最も絞り込まれたグループを選び、対象になり得るオーディエンス全体は選びません。同じステップでオーディエンスのレベルも決定してください(下記のセクションを参照)。レベルを定めないままでは、参加者層が混在してしまいます。カンファレンスでは複数の参加者ターゲットを挙げてもかまいませんが、デフォルトとなるターゲットは 1 つです(「オーディエンスレベル」セクションの「複数のターゲットオーディエンス」を参照)。スポンサーセグメントがプログラムと整合しているか確認してください。スポンサーが購入するものは、計画済みのアクティビティとして存在している必要があります(§ ビジネス向けレイヤー)。

  5. 以下の優先順位付きメニューから、市場カテゴリー戦略を選びます。

  6. 成果物をまとめます。ポジショニングステートメント(「[最適な参加者]にとって、[イベント]は[イベントカテゴリー]であり、[固有の価値テーマ]を提供します」――テンプレートと記入例はreferences/positioning-canvas.mdを参照)と、対立ではなく対比を示す形のアンチポジショニング文を 1 つ作成します。「[アーキタイプ]のイベントは数多くあります。このイベントはそのどれにも当てはまりません。」という形にします。特定の競合ではなく、アーキタイプを挙げてください。その後、何かを公開する前に、ステートメントの見出しとなる約束に対して約束の実現可能性チェック(下記のセクションを参照)を行います。

  7. ステートメント以外にどこへ投資するかを、以下のポジショニング施策メニューから選びます。選んだ施策が構造的なものである場合(トラック数、キュレーション方針など)は、ここで決めるのではなく、samber/dev-event-organizer-skills@event-format-selection と連携してください。

  8. 名称変更が検討されている場合(Q1)は、リブランドの判断基準を適用します。実際のオーディエンスやコンテンツの範囲は、現在の名称が約束する内容をすでに超えていますか?そうであれば、名称を変更し、旧範囲と新しい範囲の対応を公開してください。そうでなければ、プログラムの範囲を既存の名称が約束する内容に戻します。名称変更は延期ではなく、検討対象から外します。

  9. これは戦略上の成果物です。トレードオフを示したポジショニング案を 2~3 件提示し、推奨案を 1 つ示して、セクションごとに検証し、最終決定の前に明示的な承認を得てください。方向性に異論がある場合は、ドラフトを押し通すのではなく、ブレインストーミングモードに切り替え、質問を一度に 1 つずつ行います。結果をreferences/positioning-canvas.mdにある 0~10 点の整合性評価基準(プロダクトポジショニングを参考にしたもの)で採点してください。7 点未満は未完成として、反復して改善します。

  10. 利用するハーネスに永続メモリがある場合は、スペクトラム上の位置、挙げた代替案、選択したカテゴリー戦略、ステートメント、そして「測定」に記載された再実行のトリガーを記録します。次回開催のレビューでは、デフォルトの方針を再度議論するのではなく、それらを出発点にします。

ハッカソンとミートアップでは、賞金や競争の要素ではなく、学習、制作、共有、そして初心者の参加を明示的に重視することを基本とします。MLH(「発明マラソン」)、PennApps、Papers We Love(「低いエゴ」)、NASA Space Apps は、実際の形式に競争性がある場合でも、この方針を体現しています。

ポジショニングはメッセージングではありません。上記のすべてのステップが確定してから初めて、「参加する理由」の文案を作成します。顧客を主人公とするメッセージングフレームワーク(例:StoryBrand の SB7)は、その後のレイヤーとして妥当ですが、参照先であって、このスキルの対象範囲には含まれません。

市場カテゴリー戦略

イベントがどのようなカンファレンスの枠組みを掲げるかを示します。ランキング(デフォルトであり、絶対的なルールではありません。Q5〜Q8に照らして再評価してください):

  • 労力(イベントの価値を評価される前に必要な負担):新カテゴリー > 既存カテゴリー内での直接対決 > サブカテゴリー

  • 価値(枠組みがうまく機能した場合にもたらされるもの):新カテゴリー > サブカテゴリー > 既存カテゴリー内での直接対決

  • 効率:サブカテゴリー > 既存カテゴリー内での直接対決 > 新カテゴリー

  • 既存カテゴリーのサブカテゴリー - デフォルトの選択肢です。独自の特長に評価基準を寄せる修飾語を加えます(「[分野]向けの[テーマ]」、「実践者を最優先する[テーマ]カンファレンス」、「シングルトラックの[テーマ]カンファレンス」)。既存カテゴリーのスポンサー予算枠とオーディエンスの理解を引き継ぎながら、既存イベントとの機能ごとの比較を避けられます。

  • 既存カテゴリー内での直接対決 - 「最高の[テーマ]カンファレンス」です。教育コストはゼロですが、参加者がそのカテゴリーに抱くあらゆる期待を引き継ぎ、既存イベントとそのイベントの基準で直接比較されます。参加者がすでに評価している点で、カテゴリーのリーダーを上回れると確信できる場合にのみ選びます。

  • 新カテゴリー - 最も選ばれにくい選択肢です。最も高い価値(カテゴリーの確立)をもたらしますが、最も大きな労力が必要なため、効率を重視する場合には選ばれません。

    • 教育コストは具体的です。既知の予算枠に当てはまらないため、チケット販売とスポンサー獲得のサイクルが長くなります。コンセプト自体を説明する必要があるCFPやマーケティング文面も必要です。既知のカテゴリーの数倍のマーケティング費用がかかり、認知度が生まれるまでに複数回の開催が必要です。
    • 昇格条件(Q7とQ9に基づく):既存の枠組みではコンセプトを正確に表現できず、かつチームに開催を複数回継続できる余力、スポンサーとの関係、そしてコストを負担できる独自のブランドがあること。それ以外の場合はサブカテゴリーとして始め、手応えが得られてから新カテゴリーへ発展させます。
  • すべての人向けのポジショニング(「テック業界の誰にでも」)は格下げではなく、削除します。枠組みが存在せず、あらゆる差別化の主張を薄め、メニューの最下部に置いても、対象を絞ることに不安を感じるたびにひそかに再登場するためです。それぞれに独自のコンテンツを用意した複数の明確な対象を設定するのは、別の判断です(「複数のターゲットオーディエンス」という、オーディエンスレベルのセクションを参照)。「誰でも」では対象が明確にならず、資金を投じるコンテンツも定まりません。

判断の詳細、カテゴリーとの不一致を示す兆候、命名パターンについては、references/positioning-canvas.mdを参照してください。

対象者のレベルと約束の実現可能性

これは、変化の速い一つのトピックに関する、独立した地域コミュニティからの現場の証言であり、確立された実践ではありません。

対象者のレベル — セグメントとは別に、ステップ4で決めます。

  • 経験者をさらに伸ばす — すでに構築に取り組んでいる実践者向け。掘り下げた解説や最先端のトピック。
  • すべての人に知ってもらう — 関心を持つ専門家や初心者向け。概要やユースケース。
  • 両方を分けて扱う — 別形式にするか、開催回ごとに交互に実施します。その場合、プログラムの作業量は2倍になります。

報告された兆候:「すべての人向け」では対象が広すぎることが分かりました。ミートアップの参加者はすでに納得しているため、認知を広げるという約束では、主にすでに認知している人にしか届きません。レベルが混在する会場では、「専門的すぎる」と「専門性が足りない」という相反するフィードバックが、一つのセッションに対して寄せられます。この二つは、品質への評価ではなく、レベルが分かれている兆候として捉えてください。

複数の対象者(1日または数日間のカンファレンスのみ。ミートアップは対象者を一つにします) — 選択可能ですが、推奨はしません。対象者を一つにするのが基本です。対象者を追加するたびにプログラムの作業量が増え、メッセージが曖昧になるためです。カンファレンスで複数の対象者(たとえば、開発者とエンジニアリングマネージャー)を掲げる場合、開催回ごとに、それぞれの対象者向けのコンテンツが必要です。自分向けの内容が見つからない対象者は離れ、その対象者に掲げた約束は公の場で破られます。ステートメントの参加者に関する節で各対象者を明記し、対象者ごとに約束の実現可能性を確認してから、コンテンツの分割を samber/dev-event-organizer-skills@event-format-selection に委ねてください(トラックまたは専用枠)。毎回の開催で対応できない対象者は、ランディングページに残すのではなく、対象から外します。

専門特化型の競合による流出 — 一つのフレームワークやツールに特化したミートアップは、最も高度な参加者を集めてしまうことがあります。ステップ2の代替手段マップにこのセグメントを記載し、専門特化型イベントには提供できない価値で対抗するか、譲るか、samber/dev-event-organizer-skills@cross-event-promotion を通じて共同開催するかを選びます。

トピックの持続性 — ある実践者は、AI ツールによって言語の重要性が低下すれば、特定の言語やフレームワークに対象を絞ったコミュニティは長続きしないと指摘しました。これは予測ではなく、再検証を促すきっかけとして扱います。技術に対象を絞ったポジショニングは、独自に設定した間隔で再検証し、ツールの存在感が薄れる前に、仕事そのものへと対象を広げてください。

理由とインパクト — ステートメントでは「理由」を安定した高いレベルに保ち、「インパクト」は開催回ごとに目標として変化させます。各コミュニティで5分間の付箋エクササイズを行ったところ、それぞれの理由とインパクトが明らかになりました。理由が散らばっている状態は、インタビューのQ3で探るべきミスアライメントです。

約束の実現可能性 — 次回だけでなく、すべての開催回で見出しの約束を実現できることを確認します。次の数回分(回数は独自に設定)の開催について、それを実現するもの、つまり登壇者、形式、予算、時間を挙げてください。約束を裏付けるものが何もない開催回があるなら、約束の範囲を狭めるか、公開前に必要なリソースを確保します。「毎月、最先端の情報を届ける」と約束するなら、それを年12回提供できる登壇者の候補者パイプラインが必要です。

候補となる価値観 — 首都圏以外で最先端の情報を届けること、距離の近さ、地域・ジェンダー・レベルを問わない包摂性、人々をつなぐこと、一緒にプロジェクトを作ること、楽しさと親切さ、「 bullshit のない」すぐに役立つコンテンツ、水平性、「シャンパンではなく、ピザとビール」という雰囲気 — は、ステップ3で使う問いかけのリストであり、テンプレートではありません。それぞれ「このイベントだけが提供できるものか」というテストを通ったものだけを採用します。エクササイズの手順、良い例と悪い例については、references/promise-and-audience-level.md を参照してください。

ポジショニングのレバーへの投資

記述された内容を超えて投資する対象です。順位(デフォルトであり、絶対的なルールではありません。Q5〜Q8に照らして順位を付け直してください):

  • 労力:リブランド > ラインナップをブランドにする > トラック構成の宣言 == 対比文
  • 価値(レバーごとに得られるアイデンティティの明確さ):ラインナップをブランドにする > リブランド > トラック構成の宣言 > 対比文
  • 効率:トラック構成の宣言 > 対比文 > ラインナップをブランドにする > リブランド
  • コンプライアンスコスト(審査の発生、可逆性の消費):リブランド > ラインナップをブランドにする == トラック構成の宣言 == 対比文

この順位には、==で示される同順位が2つあります。

  • 労力の同順位(トラック構成の宣言 == 対比文):どちらも低コストの段階で、公開する段落は1つです。実際のコストは執筆ではなく、その背景にある意思決定です。構造上の選択はすでに samber/dev-event-organizer-skills@event-format-selectionにあり、アーキタイプはステップ2の選択肢マップからそのまま導き出せます。入力がそろえば、どちらも約1時間で完了します。
  • コンプライアンスの同順位(リブランド以外の3つの低い段階):どれも審査を発生させず、可逆性を消費しません。いずれも公開する主張であり、主催者は改訂そのものにかかるコストだけで、次回開催時に変更できます。

それらより上に位置するのはリブランドだけで、その差は大きいです。

  • デフォルト:低コストの2つの段階をまとめて公開します。 対比文(ステップ6)に、選んだ構造を公に説明する根拠を組み合わせます。Strange Loop、Webstock、FF Conf、XOXOはそれぞれ、シングルトラックをアイデンティティの主張として掲げています(「シングルトラックのイベントは質を高める」)。一方、re:Inventは「2,200+ sessions」を売りにして、反対側の立場を取っています。どちらも宣言せず、中間にとどまらないでください。
  • ラインナップをブランドにする ― 十分に活用されていない選択肢です。価値は最上位、労力は2番目に高く(シーズンを通じた選定と招待が必要です)。
    • キュレーション型イベントでは、ラインナップそのものがポジショニングです。Jeremy Keithの言葉を借りれば、「キュレーターの頭の中を切り取ったもの」です。ベンダーイベントでこれに相当するのは、イベントの開催年ごとの主題を担う経営幹部の基調講演であり、DreamforceやI/Oはこの形式を採用しています。
    • 昇格条件(Q6とQ10に基づく):複利的な成果が求められることに加え、キュレーターの審美眼そのものが本当にイベントの商品であること、または、年間の主題を自ら担う意欲のある経営幹部がいること。
    • ベンチマークとなる問い:参加者は、なぜこの特定の登壇者たちが一堂に会しているのかを説明できますか?できないなら、ラインナップはまだポジショニングの役割を果たしていません。
    • ヘッドライナーが登録数を伸ばすという業界の主張は、登壇者紹介会社の宣伝であり、データではありません。引用しないでください。
  • リブランド ― ステップ8のゲートを通過した後に限り、選択肢に加わります(対象範囲がすでに名称を超えて変わっていること)。
    • 成功した改称の事例は、情報源で確認できるものすべてが、すでに起きた変化を記録し、告知の中で旧スコープから新スコープへの対応関係を示しています。最も明快なのは、HubSpotのINBOUND→UNBOUNDです。
    • また、コンプライアンス上の懸念が生じる唯一の段階でもあります。新名称の商標とドメインの確認に加え、締結済みのスポンサー契約、会場契約、掲載情報にわたってイベント名を変更する必要があります。公開した文章とは違い、改称はひそかに取り消せません。
    • ゲートを通過する前は、この段階は最後に回すのではなく、選択肢から外します。変化を記録するのではなく約束する改称は、単なる方針転換と受け取られます。
  • 特定の競合を攻撃したり名指ししたりすることは、順位を下げるのではなく、選択肢から外します:情報源で確認できる反ポジショニングの例(Strange Loop、DevOpsDays、OSCON、XOXO、Papers We Love、MLH)は、どれも競合の名前を挙げていません。アーキタイプとの対比は、競合が方針を変えても古びず、反論を公に招く攻撃とも受け取られません。競合を名指しする攻撃は、その両方に当てはまります。

独自の価値テーマを年ごとに真に刷新することは、改称でも、目新しさを演出するために作ったメッセージでもありません。これは独立した第5の段階ではなく、上記で選んだレバーのいずれかに含まれます。samber/dev-event-organizer-skills@event-landing-pageでは、以前の見出しに取り消し線を引き、新しい見出しと並べて示すことで、真の刷新を際立たせられます。この手法は、基盤となるテーマが実際に変わった場合にのみ使い、変化したように見せかけるために使わないでください。

ビジネス志向のレイヤー

これも第5段階ではありません。声明のスポンサー側に関する検討事項であり、それより上の順位付けを変えるものではありません。1日または数日間のカンファレンスでは、価値提案と予定している活動を、最適なスポンサーセグメントが購入するものに合わせる必要があります。スポンサーは価値を単独では判断できないことがよくあります。実際に購入しているのは参加者へのアクセスであり、参加者リストではありません。

  • トークのみのプログラムより、ビジネス志向のレイヤーがあるプログラムのほうがスポンサーを納得させられます。トークでは、スポンサーが購入するもの(採用、製品へのフィードバック、販売、パートナーシップ)の多くを提供できないためです。
  • このレイヤーを約束に含めるか、またどのスポンサーセグメントを対象にするかをここで決めます。活動の形式(採用コーナー、製品への実践的なフィードバックセッション、オプトイン形式のデモスペース、マッチメイキング)は samber/dev-event-organizer-skills@business-event-formats に含まれます。価格設定とパッケージ化はスポンサー関連のスキルに含まれます。
  • スポンサー活動が CFP プログラムに入ることはありません。プログラムと並行して実施することで、コミュニティ側における上記の中立性監査も維持できます。
  • 地域内に代替手段がない活動はステップ3の基準を満たし、スポンサーと参加者の双方にとって差別化につながります。模倣した活動は、どちらにもつながりません。

失敗パターン

  • 対比ではなく攻撃になっている。 競合イベントの名を挙げると反論を招き、競合の戦略が変わればすぐに古くなります。温かみを保ちながら、ある類型と対比してください。
  • 対象範囲が変わる前に改名する。 情報源にある順序は、常に中身が先、名前が後です。プログラムが今の名前に収まらなくなっていないのであれば、プログラムを見直してください。
  • コミュニティイベントでベンダー寄りの立場を取る。 それを支えるガバナンスのない仲間意識を訴える言葉や、プログラムの30~40%超が単一ベンダーのコンテンツであるにもかかわらず中立を主張することは、まさにそのイベントが求める実践者層から指摘を受けます。
  • 温かみのある言葉をガバナンスと取り違える。 代替イベントを整理する際は、競合イベントをトーンではなく、運営主体と資金の流れで分類してください。ベンダー寄りの類型は、意図的にコミュニティらしく聞こえるようにしています。
  • 万人向けの位置づけにする。 「Xに関心のある人なら誰でも」は、上記のとおり選択肢から外すべきものです。最も適合度の高い狭いセグメントを定めることで、ほかの主張もすべて明確になります。
  • 文脈より先にキャッチコピーを決める。 オーディエンス、代替イベント、カテゴリーを決める前にメッセージ(名前、キャッチコピー、メインコピー)を決めるのは、最もよくある順序の誤りです。そうすると、戦略が後から言葉に合わせざるを得なくなります。
  • 開催回ごとにポジショニングを変える。 リピーターとスポンサーは資産です。複数回にわたってポジショニングを維持し、ポジショニングよりも頻繁にメッセージを調整してください。
  • 初開催のリソースだけで新しいカテゴリーを作る。 初開催のイベントにはすでに「実績がない」という不安が伴います。新しいカテゴリーを掲げると、「どう評価すればよいかわからない」という不安まで加わります。教育コストを負担するのは、十分な準備期間を確保できる見通しが立ってからにしてください。
  • 賞金を前面に出すハッカソンのポジショニング。 信頼できる大規模な事例はすべて、学ぶ・作る・共有することと、初心者を歓迎する姿勢を前面に出しています。賞金額を前面に出すと、その領域を譲ることになり、望ましくない参加者層を引き寄せます。
  • どの開催回でも守れない約束。 登壇者の確保状況や予算では毎回実現できない見出しを掲げると、3回目の開催までにポジショニングは破られた約束になります。公開前と、開催回ごとに、約束を実現できるか確認してください。
  • 対象レベルを決めない。 オーディエンスのレベルを定めないセグメントでは、さまざまなレベルの参加者が混在し、フィードバックが相殺されます(「専門的すぎる」「専門性が足りない」)。レベルを決めて、プログラムチームに伝えてください。
  • 名付けられていない専門家層の流出。 上級者が専門分野のミートアップへ移ると、質の低下と受け取られ、誤った対策につながります。そのセグメントと差別化要因を明確にしてください。
  • 地域の定番の型を模倣する。 近隣イベントですでに行われている形式やアクティビティを組み合わせ直しても、参加者やスポンサーがこのイベントを選ぶ理由にはなりません。イベントが飽和した都市ではなおさらです。ステップ2のマップにある形式やアクティビティを使って差別化してください。
  • 2つ目のターゲットをおろそかにする。 複数のオーディエンスを掲げながら、そのうち1つにしか向けてプログラムを組まないカンファレンスは、1回の開催でほかの層を失います。その約束が守られなかったことは、プログラムよりも広く伝わります。名指ししたすべてのターゲットに毎回の開催で応えるか、そのターゲットを掲げるのをやめてください。
  • トークのみの提供を、別の価値を求めるスポンサーに提案する。 提案資料でアクセスを約束しても、プログラムで提供できなければ、契約更新につながりません。CFPプログラムの外にビジネス向けの要素を加えるか、スポンサーのセグメントを絞ってください。
  • 特性なしにトレンドに乗る。 「[分野]が専門職化するにつれて」といったトレンドをポジショニングに含めるのは、そのイベントが実際に持つ独自の特性と結びついている場合に限ります。

効果測定

ポジショニングの質は評価するものであり、チケットやスポンサー獲得の成果と結び付ける業界の数値を参照するものではありません。数値を作り上げるのではなく、その旨を明記してください。評価基準と観察可能な代替指標を使います。

  • 整合性スコア - references/positioning-canvas.md にある 0〜10 の評価基準(製品のポジショニングを基に調整)。7 以上で合格です。運営者全員がイベントのポジショニングを同じように説明でき、新規参加者もイベントの内容をすぐに理解できます。

  • 誤認の監視 - 次のいずれかに該当した場合は、次回開催時にカテゴリーのステップを再実施します。

    • 参加者やスポンサーが、同僚にイベントを一貫して誤って説明している。
    • 来場者が、イベントでは提供していない内容を期待している。
    • チケット販売やスポンサー獲得のサイクルが、同カテゴリーのイベントより大幅に長い。
    • CFP の応募内容が、イベントにない機能を前提としている。

    これらのいずれかが成長の転換点と重なる場合、規模とレバーの判断は samber/dev-event-organizer-skills@event-growth-strategy が担い、カテゴリーの再検討はここで行います。

  • 中立性の監査(コミュニティ/財団寄りの場合のみ) - 単一ベンダーのプログラム内容に占める割合を、約 30〜40%の許容限度と照らして確認します。

  • 公約の達成度(開催ごとに独自設定、二択) - 今回の開催で、掲げた中心的な約束を果たせましたか? 2 回連続で達成できなかった場合、実現可能性の確認を再実施します。

  • 難易度分割の兆候 - フィードバックで「技術的すぎる」と「技術的でなさすぎる」の両方が寄せられたセッションの割合です。この割合が増加した場合、対象者のレベルを再検討します。

  • ターゲットごとのカバー状況(独自設定、複数ターゲットのカンファレンスのみ) - 今回の開催で、明示した各ターゲット向けのコンテンツを用意できましたか。また、そのターゲットの参加者に占める割合は維持できましたか? 2 回連続で規模が縮小したターゲットがあれば、複数ターゲットの方針を再検討します。

  • スコープの再検証(テクノロジーを限定したポジショニングのみ) - 独自に設定した頻度で再検証し、日付を記録します。

  • ラインナップの分かりやすさ(ラインナップをブランドとして宣伝した場合) - 参加者に「なぜこの登壇者たちが一緒に登壇するのですか?」と尋ねます。答えに窮するようなら、まだこのレバーが機能していません。

公開前に、どの代替指標がどの改訂のきっかけになるかを決め、両方を記録してください。

呼び出し例

  • 「この地域にはすでにクラウド関連イベントが 2 つあります。この地域でプラットフォームエンジニアリングのカンファレンスを始める予定です。誰を対象にすべきでしょうか。また、3 つ目の一般的なイベントにならないためにはどうすればよいでしょうか?」
  • 「ミートアップがカンファレンスに成長しましたが、スポンサーから『ベンダーデー』と呼ばれ続けています。ポジショニングを修正してください。」
  • 「会社は、ユーザーカンファレンスをコミュニティイベントのように感じさせたいと考えています。正直に何を主張できますか?」
  • 「イベント名を変更すべきでしょうか? 名前にはまだ『DevOps』とありますが、プログラムの半分はプラットフォームと AI インフラになっています。」

期待される出力:次の内容を含むポジショニング概要。

  1. ガバナンスのスペクトラム上の位置付けと、主張してはならない内容。
  2. セグメントごとに挙げた代替案。
  3. 価値テーマに結び付けた独自の属性。
  4. 最適な参加者セグメントとスポンサーセグメント。対象者のレベル、明示した各ターゲット向けのコンテンツ、およびスポンサーセグメントに必要なビジネス志向のレイヤーも含めます。
  5. ランキングの根拠を含むカテゴリー戦略。
  6. ポジショニングのステートメントと、対比によるアンチポジショニングの一文。開催ごとの公約の実現可能性確認も含めます。
  7. 選んだレバーへの投資と、その宣伝を選ぶ理由。
  8. 再実施のきっかけ。

検証できるようセクションごとに提示し、候補を 2〜3 件示したうえで、最初に推奨案を提示します。

参考資料

  • references/positioning-canvas.md - ポジショニングキャンバスの全容です。プロダクトポジショニングを基に、5つの調査項目とそこから導き出される5つの項目、記入例付きのステートメントテンプレート、0~10の整合性評価基準、カテゴリー名のパターンとカテゴリーが適切でないことを示す兆候、よくある間違い、チームワークショップの形式をまとめています。
  • references/competitive-alternatives.md - 5種類の代替手段の分類、質問を掘り下げるためのプローブを含む参加者/スポンサーへのインタビュー台本、セグメントのクラスタリング、何もしない場合の診断をまとめています。
  • references/positioning-evidence.md - イベント名に基づくエビデンスです。ベンダー主体の立場を示す引用、DevOpsDaysのコミュニティ主体の立場とチャプターブランドの仕組み、財団/メディアという中間的な立場、アンチポジショニングの一覧、単一トラックのアイデンティティを示す声、基調講演/登壇者ラインナップの活用策、リブランド事例、ハッカソン/ミートアップのパターンをまとめています。
  • references/promise-and-audience-level.md - 実例と否定的な例を使った約束の実現可能性チェック、対象者レベルの判断表、専門分野の競合に参加者を奪われる場合の選択肢、トピックの持続性の再テスト、「なぜ」と「影響」の演習、ポジショニングの価値観に関するプロンプトの一覧をまとめています。

こちらもご覧ください(同じコレクション内):

  • samber/dev-event-organizer-skills@event-cultural-identity - ここで決定したポジショニングを、会場、雰囲気、ケータリング、ノベルティ、儀式に反映します。ポジショニングが「なぜ」を決め、文化的アイデンティティが「どのように感じられるか」を決めます。
  • samber/dev-event-organizer-skills@event-format-selection - トラック数やセッション構成など、アイデンティティに関わる構造上の選択肢を扱います。フォーマットとポジショニングを照らし合わせて決定します。
  • samber/dev-event-organizer-skills@business-event-formats - 採用コーナー、フィードバックセッション、オプトイン式のデモスペース、マッチメイキングなど、ここで決めたビジネス志向の側面をCFPプログラムの外で具体化する、スポンサー向けのアクティビティ形式を扱います。
  • samber/dev-event-organizer-skills@event-market-fit - ポジショニングしたコンセプトが実際の需要を満たすかを検証します。ポジショニングによって、検証対象が定まります。
  • samber/dev-event-organizer-skills@event-first-edition - ここで決めた対象者と開催理由を引き継ぎ、第1回を立ち上げます。
  • samber/dev-event-organizer-skills@event-growth-strategy - 誤った説明に関する警告が規模の拡大とともに発せられたとき、次回の開催規模を拡大するか、維持するか、縮小するかを決定します。リポジショニング自体はここで扱います。
  • samber/dev-event-organizer-skills@event-marketing-plan - ここで決めたメッセージを集客計画のチャネル構成とキャンペーンカレンダーに反映します。ポジショニングを再定義することはありません。

コメント