event-sponsor-value-proposition

イベントスポンサーの価値提案

各スポンサーが何を必要としているかを把握し、パッケージ化、価格設定、提案を行う前に、技術イベントが実際に提供できる価値を明確にします。スポンサーはイベントの価値を自力では把握できないことがよくあります。イベントとスポンサーの適合性は、提案資料の中で前提とするのではなく、ヒアリングを通じて見いだします。

• 成果物：スポンサーセグメントごとに価値提案の文を1つ作成し、すべての主張を裏付けとなる事実で支えます。成果物は、samber/dev-event-organizer-skills@event-sponsor-prospectus（提案資料）と samber/dev-event-organizer-skills@event-sponsor-pricing（料金表）に引き継ぎます。
• 対象外：パッケージの階層化、価格設定、営業活動、契約書の作成、提供状況の追跡。これらは関連する別のスキルで扱います。
• 対象範囲：主に1日または複数日のカンファレンスです。他の形式では、同じ方法でスポンサーシップを販売する場合に限り、この考え方を適用します。
• スポンサーが購入するもの：スポンサーにとって、参加者は実質的にプロダクトであり、スポンサーは適格なオーディエンスへのアクセスを購入します。アクセスとは、会場での存在感と会話の機会であり、参加者名簿ではありません。連絡先データが共有されるのは、参加者が自ら提供した場合に限ります。また、コミュニティ主催のイベントでは、名簿として共有することは決してありません（「コミュニティ主催とベンダー主催」を参照）。
• 境界線：スポンサーシップで購入できるのは、配置とアクセスであり、講演枠、審査結果、プログラムやロードマップへの影響力ではありません（DevOpsDays主催ガイド：「スポンサーがプログラムに食い込む手段を買えるようにしてはなりません」）。

以下の各順位は、絶対的なルールではなく、あくまでデフォルトです。状況や実行する人によって変わります。ヒアリング後に、この主催者について把握した情報をもとに順位を付け直してください。以下の要因は、いずれもデフォルトの順位を覆すことがあります。

• 既存の参加者データパイプライン
• 継続参加するアンカースポンサー
• 実績のない初開催
• 同意を得たリード情報の取得が可能なベンダー主催イベント
• 地域の採用市場の冷え込み（Q11）

インタビュー

質問は一度に1つずつ尋ね、できるだけ選択式にしてください。質問7〜9があるのは、以下のメニューでは成果が出るまでの時間、持続性、労力が大きく異なるためです。既定の優先順位をユーザーに代わって選ぶことはできません。

1. イベントはどちらのタイプですか。コミュニティ主導型（独立運営で、CFPを軸に構成し、スポンサー収入は費用回収に充てる）ですか、それともベンダー／財団主導型（ベンダー所有で、マーケティング予算があり、スポンサーを見込み顧客の獲得経路とする）ですか。これは誠実に約束できる価値カテゴリーの範囲を定めるため、メリットを提案する前に確定してください。
2. この提案の対象となるスポンサーセグメントを、1つずつ選んでください。製品へのフィードバックを求める買い手（DevRel／デベロッパーアドボケイトの肩書き）、採用目的の買い手（人材獲得／人事の肩書き）、ブランド目的の買い手（マーケティング／広報の肩書き）、またはコミュニティメンバーのスポンサー（コミュニティ内の実務者や創業者）ですか。セグメント分類と肩書きの手がかりについては、references/sponsor-segment-jtbd-worksheets.md を参照してください。
3. この特定のパートナーは、イベントに何を求めていますか。提案する前に尋ねてください。多くのスポンサーは、促されないとニーズを言語化できません。よくあるニーズをそれぞれ確認し、以下の価値カテゴリーに対応づけてください。雇用主ブランドの構築や採用（採用）、参加者への販売（ベンダー主導型の場合のみ見込み顧客の獲得、コミュニティ主導型の場合はブランド露出と、参加者が選ぶ製品に関する対話）、製品へのフィードバック（製品フィードバック）、ブランド認知（ブランド露出）、コミュニティへの貢献（コミュニティへの貢献）。どのカテゴリーでも誠実に提供できないニーズは、提供しない項目のリストに入れてください。
4. オーディエンスについて、どのようなデータがありますか。過去の開催回や登録フォームから得られた、職種・役職レベル・企業規模の構成、地域などの全体的なデータはありますか。印象ではなく、数値を確認してください（「どのような人が参加しますか？」は、DevOpsDaysのガイドによると、スポンサーが必ず尋ねる3つの質問のうち最初の質問です）。
5. どのような実績がありますか。開催回数、スポンサーの継続率、イベント後に実際に提供したスポンサー向けレポートはありますか。初開催なら実績はありません。その点を明示し、実績を捏造せず、proof-pointの参考資料にある代替案を使用してください。
6. このセグメントはイベントがない場合、現在どのような施策を行っていますか。大規模なベンダー向けカンファレンスへのブース出展、求人サイトへの広告掲載、ブランドキャンペーン、同じオーディエンスへのコールドアウトリーチなどです。現状を確認することで、イベントの価値が前提ではなく、明確になります。
7. スポンサー収入はいつまでに確定する必要がありますか。（期限が迫っている場合は、時間をかけて効果が積み重なるカテゴリーより、現地で効果が出るカテゴリー、つまり採用につながる対話や製品へのフィードバックが優先されます。）
8. このスポンサーとの関係は単発の販売ですか、それとも複数回の開催を通じて価値が積み重なる資産ですか。（継続的に価値を積み重ねることが目的なら、ブランドやコミュニティへの貢献といった、成果が出るまでに時間のかかるカテゴリーが優先されます。）
9. 証拠を集めるためにかけられる労力の上限はどの程度ですか。すでに保有しているデータ、アンケートを実施する余力、主催者が使える時間を確認してください。
10. この提案は、どの特定のスポンサーまたはスポンサー階層を対象に作成していますか。また、その見込み客自身のデューデリジェンス用チェックリストには、購買への影響力や役職レベルの構成に関する質問がありますか。
11. このセグメントの採用ニーズは現在どのような状況ですか。対象企業は現在、技術職の採用を進めていますか、採用を保留していますか、それとも削減していますか。スポンサーの多くは技術チームへの採用や販売のために費用をかけます。採用スポンサーは、採用が鈍化すると最初に離れます。市場が冷え込んでいる場合は、採用を主要な訴求軸から外し、人員を必要としない露出を優先してください。確認すべき兆候については、references/value-category-evidence.md を参照してください。

コミュニティ主催とベンダー主催

イベントの主催者によって、何を正直に約束できるかが決まります。samber/dev-event-organizer-skills@event-first-edition と samber/dev-event-organizer-skills@event-format-selection が主張するのも、同じ観点です。

• コミュニティ主催 - 参加者の連絡先リストが提供されたり販売されたりすることはなく、講演枠を購入することもできません（DevOpsDays の主催者向けガイドでは、どちらのルールも二度明記されています）。リード情報の取得は、参加者が自ら提供した場合に限られます。リード情報の代わりに正直に提示できるのは、集計された属性データです。正直に期待できる価値は、ブランド露出、実際の対話を通じた採用活動、技術に詳しく明確な意見を持つ参加者からの製品フィードバック、そしてコミュニティからの好意です。
• ベンダー／財団主催 - 参加者の同意を前提として、パイプラインの構築や、連絡先の詳細を取得できるリード情報の取得（バッジのスキャン）による価値を正直に提示できます。パイプラインという価値が成り立つのは、この主催形態に限られます。

各主張がどちらの主催形態を前提としているかを明示してください。コミュニティ主催のイベントでリードリストを約束する価値提案は、イベントの仕組み上提供できないメリットを過大に売り込むことになります。主催者自身が公開しているルールを読んだスポンサーなら、この食い違いにすぐ気づきます。

ワークフロー

1. インタビューを実施し、軸（Q1）と1つのセグメント（Q2）を決めます。
2. ディスカバリー：実際の見込みスポンサーを相手にQ3を実施します。求人広告から推測するのではなく、通話または短いやり取りを行います。相手が述べたニーズをその人自身の言葉で書き留め、それが対応するカテゴリーも記録します。この組み合わせが、ステートメントが満たすべきイベントスポンサーとの適合性を示します。
3. 誠実さを最初に確認：提供する内容を作成する前に、このイベントで「提供しない」ものを書き出します（DevOpsDaysは、パッケージを説明する前にスポンサーへ「参加者リストなし、購入できる枠なし」と伝えるという、公開されている主催者のパターンに従っています）。提供できないカテゴリーは今すぐ削除します。「後で検討」として保留したカテゴリーは、デッキにいつの間にか再登場します。
4. 以下の価値カテゴリーのメニューからリードカテゴリーを選びます。ディスカバリーで見つかったニーズを共同リードにします。
5. オファーと活動の一貫性：計画中のプログラムに、掲げるすべてのカテゴリーに対応する活動があるか確認します。採用なら採用コーナー、製品フィードバックなら実地のフィードバックセッション、販売なら参加者が自ら選んで訪れるスタッフ常駐のデモスペースです。講演だけのプログラムは、ビジネス向けの要素があるプログラムよりスポンサーへの説得力に欠けます。講演だけでは、スポンサーが購入するものをほとんど提供できないためです。他のイベントのやり方を模倣するのではなく、その要素を設計します。すでにイベントが飽和している都市では、他のどのイベントも実施していないスポンサー活動そのものが差別化要因になります。ポジショニング：samber/dev-event-organizer-skills@event-positioning。活動の形態：samber/dev-event-organizer-skills@business-event-formats。スポンサー活動はCFPプログラムの対象外にします（「境界」を参照）。
6. references/sponsor-segment-jtbd-worksheets.mdを使って、この1つのセグメントについて、JTBDの6項目テンプレート（誰が／なぜ／導入前の状況／方法／導入後の状況／代替案）を埋めます。セグメントを混ぜて1つのステートメントにすることは決してありません。
7. 「方法」の各主張に、以下の手段メニューから選んだ証拠を添えます（収集の詳細：references/proof-point-instruments.md）。証拠による裏付けがあるか、まだ目標段階かを各主張に明記します。明記のない主張は裏付けがあると受け取られ、架空の内容としてデューデリジェンスで問題になります。
8. references/proof-point-instruments.mdの価値方程式チェックを使ってドラフトを評価します。これはドラフト作成後の評価基準であり、記入するための構成ではありません。
9. 戦略成果物であるため、セクションごとにユーザーの確認を得ます。セクションごとに明示的な承認を得て、全体をまとめて一度に承認してもらうことは避けます。セグメントを追加するたびに、手順2と4〜8を繰り返します。
10. ステートメントと証拠一覧を、samber/dev-event-organizer-skills@event-sponsor-prospectusおよびsamber/dev-event-organizer-skills@event-sponsor-pricingに引き渡します。

ハーネスに永続メモリがある場合は、セグメントごとに次の内容を記録します。

• ディスカバリーで述べられたニーズと、それが対応するカテゴリー
• 選択したリードカテゴリー
• 提供しないものの一覧
• 各主張の証拠の状態（裏付けあり／目標段階）
• 次回開催までに収集する必要がある証拠

プロスペクタス、価格設定、アウトリーチの各作業は、価値を示す説明を再導出するのではなく、この記録を起点にします。

価値カテゴリの主軸

特定のセグメントにおいて、どのカテゴリを提案の主軸にするかを決めます。ランキング（デフォルトであり、絶対的なルールではありません。Q7〜Q9および極に照らして並べ替えてください）。

• 労力（誠実に主張するために必要な証拠と提供の仕組み）：パイプライン > 採用 > プロダクトフィードバック > ブランド露出 == コミュニティへの貢献
• 価値（実際に提供された場合の、一般的なスポンサーにとっての見返り）：パイプライン > 採用 == プロダクトフィードバック > ブランド露出 > コミュニティへの貢献
• 効率：ブランド露出 > プロダクトフィードバック > 採用 > コミュニティへの貢献 > パイプライン
• コンプライアンスコスト（必要となる審査と、取り消しがどれほど難しいか）：パイプライン > 採用 > プロダクトフィードバック == ブランド露出 == コミュニティへの貢献

3つの同順位には、それぞれ根拠があります。

• 労力：ブランド露出とコミュニティへの貢献は、どちらも主催者がすでに持っている証拠から主張できます。前者は集計済みの属性データと可視性の提供枠、後者はコミュニティの実績と価値観です。一方、それより上位の項目では、新たな仕組み（構成データ、会話の形式、同意を得たデータ取得）が必要になります。

• 価値：採用要件の充足と、検証済みのプロダクト判断は、いずれも四半期内に得られる具体的な成果です。MLHの主催者向けガイドでは、スポンサーの主な動機3つのうちに採用とプロダクトフィードバックを並べて挙げていますが、順位は付けていません。

• コンプライアンスコスト：スポンサーに個人データを渡すのはパイプラインだけです。そのため、同意取得のフローとデータ保護の審査に加え、スポンサーによる再利用を契約で制限する必要があり、いったん渡した参加者の連絡先情報は回収できないため、取り消しもできません。採用では、ベンダー側の極に限り、この審査の負担が軽減された形で生じます。

• 下位3項目：主催者のシステムから名前を外すものがないため、ほぼゼロで同順位になります。単に差が明確でないだけではなく、実際に同等です。

• ブランド露出 - デフォルトの主軸です。イベントはデフォルトで認知のファミリーに属します（Phil LeggetterのAAARRRPマッピング）。これは慰めではなく、軌道修正です。このメニューが解決しようとしているのは、主な見返りが実際には可視性であるのに、あらゆるスポンサーシップをパイプラインとして売り込むという、不誠実なデフォルトです。セグメントのJTBDカテゴリと組み合わせ、共同主軸にしてください。

• プロダクトフィードバック - DevRel／アドボケイトの購入者に対する共同主軸です。技術に詳しく、明確な意見を持つオーディエンスからリアルタイムの反応を得られます（MLH）。現地で効果が得られるため、期限が近い場合（Q7）に前面に出してください。

• 採用 - 人材採用を目的とする購入者に対する共同主軸です。コミュニティ主催のイベントでは、オフィスアワーやスタッフ常駐のテーブルでの会話を通じて行い、スキャンしたデータを使うことはありません。その点を明示してください。降格条件はQ11を基準とします。セグメントで採用活動が鈍化している場合、採用予算は最初に削られるため、ブランド露出を主軸にし、採用は任意の共同主軸として位置付けてください。

• コミュニティへの貢献 - 一般的なスポンサーにとっての価値は低いものの、パイプラインとは異なる、実際の更新動機です。JetBrainsがPyCon USに協賛する理由として挙げているのは、コミュニティの支援、既存ユーザーとの交流、市場情報の収集であり、リードの獲得ではありません（PSFの提案資料にある推薦文。これは一社の判断理由であり、ベンチマークではありません）。昇格条件：スポンサーがコミュニティの会員から成る場合、またはエコシステムに戦略的に依存している場合です。スポンサーの連絡担当者自身が実務者であることも多いため、これはよくあるケースです（DevOpsDays）。その場合は主軸にしてください。

• パイプライン - 最も飢餓状態にある選択肢です。価値と労力の両方で最上位（同意を得たデータ取得の仕組み、アトリビューション、ブースのスタッフ配置が必要）であるため、効率を基準に選ばれることはありません。昇格条件：ベンダーまたは財団が主催するイベントで、同意を得たリード取得の仕組みがすでに整っており、かつスポンサーがパイプラインを明確な目的としていることです。

• コミュニティ主催のイベントでは、パイプラインを降格させるのではなく、削除してください。降格したパイプラインの約束をメニューの最下部に置いても、範囲として提案資料に再び現れるからです。

実証ポイントとなる指標

「どのように」に関するすべての主張には、慎重なスポンサーが納得する証拠が必要です。デューデリジェンスのチェックリスト（参加者の構成、地域、実績、スポンサーの密度、プログラムの質）は、まさに回答を集めるべき項目です。順位付け（デフォルトであり、絶対ではありません。Q9 の上限によって順位は変わります）：

• 労力（収集と分析にかかる時間）：詳細な参加者アンケート > イベント後のスポンサー向けレポート > スポンサーの推薦コメント > 登録フォームの属性情報 > リピータースポンサー率 == プログラム内容の比率
• 価値（慎重なスポンサーが納得する可能性を高める効果）：詳細な参加者アンケート > 登録フォームの属性情報 > イベント後のスポンサー向けレポート > リピータースポンサー率 > プログラム内容の比率 > スポンサーの推薦コメント
• 効率：リピータースポンサー率 > 登録フォームの属性情報 > プログラム内容の比率 > スポンサーの推薦コメント > イベント後のスポンサー向けレポート > 詳細な参加者アンケート
• コンプライアンスコスト（発生する審査と、それをどれだけ取り消せないか）：詳細な参加者アンケート > 登録フォームの属性情報 > スポンサーの推薦コメント > リピータースポンサー率 == プログラム内容の比率 == イベント後のスポンサー向けレポート

2 つの同順位については、次のように説明できます。

• 労力：リピータースポンサー率とプログラム内容の比率は、どちらも主催者がすでに保管している記録（各回のスポンサー一覧と公開済みプログラム）を数える作業で、それぞれ 1 時間程度です。新たな収集は不要です。

• コンプライアンスコスト：アンケートも登録フォームの項目も個人データを収集するため、プライバシー通知、保管期間のルール、適法な根拠が必要です。ただし、アンケートでは職務や購買権限の詳細を尋ね、尋ねた事実を取り消すことはできません。一方、フォームの項目は次回以降に削除できます。氏名入りの推薦コメントには、引用元を明記した引用文についてスポンサー自身の承認が必要で、依頼があれば撤回できます。

• 下位 3 項目：どれも主催者がすでに保有する記録を集計して報告するため、新たな個人データの収集も、確認作業も、取り消すべきこともありません。そのため、すべて同率でゼロです。

• デフォルトの段階：リピータースポンサー率とプログラム内容の比率を今すぐ算出します（労力はほぼゼロです）。また、今期から登録フォームを変更し、役職・職位・企業規模を集計値として取得します。これは唯一、積み重ねられる指標です。各回のデータが将来の提案すべてに活用でき、コミュニティ主導のイベントにおけるリードデータの誠実な代替となります。

• 詳細な参加者アンケート（購買への影響力、ツールの導入状況、職位の詳細）：最も不足しがちな選択肢です。価値は最上位ですが、労力も最大であるため、効率の観点から選ばれることはありません。Q10 に基づく実施条件は、主要スポンサーや最上位枠のスポンサーを誘致しており、そのデューデリジェンスで購買への影響力について尋ねられる場合、または参加者構成に関する主張が価格を左右する、ベンダー中心のイベントの場合です。

• 初回開催：リピーター率も、レポートも、過去の属性情報もありません。ステートメントでは、代替指標であることを明記したうえで、主催者自身の実績、コミュニティの規模やエンゲージメントを示す証拠（ミートアップの参加者数、CFP の応募数）を使います。予測を実績として提示してはいけません。references/proof-point-instruments.md を参照してください。

失敗パターン

• コミュニティ主催イベントで、見込み度の高いリードを提供すると約束する。 構造上、提供できません。リストもスキャンもできず、主催者自身が公開しているルールにも明記されています。代わりに、参加者の属性を集計した情報と、会話を通じた採用活動やフィードバックを得る機会を提供します。
• スポンサーになると、基調講演、審査結果、ロードマップへの影響力が得られるかのように示唆する。 強引な売り込みではなく、スポンサーが確かめた瞬間に崩れる虚偽の主張です。主催者向けガイドでは、交渉可能な追加特典ではなく、厳格なルールとして定められています。
• ニーズを推測して売り込み、ニーズの把握を省く。 スポンサーには、こちらから説明しない限りイベントの価値が伝わらないことが多いため、想定上の役割に基づく説明はありきたりに受け取られ、話が進みません。まず見込み客に対してQ3を実施します。
• トークのみのプログラムで、ビジネス上の成果を約束する。 アジェンダがトークだけなのに、採用、フィードバック、販売の価値を主張しても、スポンサーには現地でできることがありません。それぞれの主張を実現するアクティビティを追加するか、主張を取り下げます。
• 価値提案を特典リストにする。 ブースの広さ、ロゴの掲載位置、チケットの枚数はパッケージの内容であり、プロスペクタスに記載する項目です。価値提案では、このセグメントが、明示された代替案と比べてなぜ購入するのかに答えます。
• すべてのセグメントに同じ説明を使う。 1セグメントずつ作成するテンプレートが防ごうとしている、複数セグメント用キャンバスの失敗例です。「素晴らしいオーディエンスに素晴らしい露出を得られます」という曖昧な説明になり、予算を承認する担当者が社内で申請できません。
• 構成データなしに、オーディエンスの質を主張する。 慎重なスポンサーにとって、「シニアエンジニアと有意義に接点を持てます」という主張は、根拠がなければ、買い手側の注意点に当てはまる警告サイン（曖昧で検証できない参加者数）と見分けがつきません。裏付けとなるデータを集めるか、主張を取り下げます。
• ROIの数値やコンバージョンの基準値を捏造する。 このカテゴリには、引用できる数値はありません。DevOpsDaysは、数値を使わずに確信を伝える方法を示しています。「スポンサーが得る価値に比べて、価格は低いと考えています」――確信は示しつつ、捏造した数値は付け加えません。
• コミュニティからの好意を、埋め草のように扱う。 これはパイプラインとは別の、更新を促す要因として明確に挙げられています。実務者をスポンサーとする場合は、残りの段落に付け足す項目ではなく、主要なカテゴリです。
• 予算が厳しくなったときにスタッフ不要の選択肢を用意せず、ブースを中心に提案する。 ブースには料金に加え、スポンサー側のスタッフを何日も割く必要があります。採用が減速すると、採用を目的とするスポンサーが真っ先に離れ、ロゴやデジタルでの露出が引き続き売れる一方で、ブース中心のパッケージは停滞します。対策：共同で主軸にする項目を選ぶ前にQ11を確認し、すべてのセグメントのHowにスタッフ不要のブランド露出案を記載して、samber/dev-event-organizer-skills@event-sponsor-pricingで価格を設定できるようにします。
• スポンサー側の分母を無視する。 料金、ブースの設営、出張、スタッフの日数をすべて含めた総コストは、スポンサーが頭の中で計算する際の一部です。何も言わないより、明示するほうが信頼につながります。

効果測定

価値提案の表現を業界のコンバージョン率と比較して測定することはできないため、そのような数値を引用してはいけません。観察できるのは、その後のプロセスで得られる結果と、自分たちで設定する指標です。2～3個を選び、アウトリーチを始める前に、それぞれの結果を受けてどのように見直すかを書き留めておきます。

• 初回通話での説明内容の網羅度（独自設定）：スポンサーとの通話では、価値提案の時点ですでに答えているべき3つの既知の質問――どんなオーディエンスか、なぜスポンサーになるのか、各レベルで何が得られるのか（DevOpsDays）――から話を始めます。「結局、何が得られるのか」で話が止まる場合は、Howが曖昧です。「誰が参加するのか」で止まる場合は、参加者の構成を示す裏付けデータが不足しています。
• 異議の記録（独自設定）：samber/dev-event-organizer-skills@event-sponsor-outreachにセグメント別の異議をタグ付けさせます。同じ異議が繰り返し出る場合、それは営業上の問題ではなく、そのセグメントの説明に欠陥があることを示します。
• 説明文の再利用（独自設定）：プロスペクタス、料金説明、アウトリーチでは、各説明文をほぼそのまま引用する必要があります。書き換えが必要になるなら、実際のやり取りに耐えられるほど具体的な説明ではありません。
• スポンサーの更新率で評価されるのは、提供内容、レポートの品質、関係性など、関係全体です。このスキル単独の評価指標ではありません。更新率は、samber/dev-event-organizer-skills@event-market-fit（兆候）と­samber/dev-event-organizer-skills@event-sponsor-renewal（追跡）の対象です。

呼び出し例

• 「300人が参加するコミュニティ主催のDevOpsカンファレンスに、スポンサーが付く理由は何でしょうか？企画書を作る前に、その理由を言葉にするのを手伝ってください。」
• 「ある開発ツールベンダーから、ハッカソンのスポンサーになることでDevRelチームが具体的に何を得られるのか尋ねられました。価値を伝えるストーリーを作成してください。」
• 「銀行の若手人材採用チームに、主要スポンサーとして協賛してもらえるよう働きかけています。採用面での価値提案は何でしょうか。また、まずどんな根拠が必要でしょうか？」
• 「今年はスポンサーの契約更新が減りました。既存の実務者スポンサー向けに、価値提案を作り直してください。」

期待される出力：セグメントごとに、「誰／なぜ／導入前／方法／導入後／代替手段」の6項目からなる価値提案文と、各主張を根拠あり、または今後の目標として分類し、その裏付けとなる測定手段を示した根拠一覧を作成します。「提供しないこと」の一覧を冒頭に明記し、各セクションを順に提示して検証できるようにします。

参考資料

• references/sponsor-segment-jtbd-worksheets.md - 6項目のJTBDテンプレートと、セグメント別ワークシート（製品フィードバック、採用、ブランド、コミュニティメンバーの購入担当者）、5種類のスポンサー分類、および肯定的・否定的な記述の作成例。
• references/value-category-evidence.md - カテゴリーの一覧とその背景にあるフレームワーク（DQLルーティング、AAARRRP、5つのROI目標）、スポンサーの動機と懸念の分類、主催者自身の言葉で示された誠実さの制約、善意を示す推薦の証拠、採用市場に連動するスポンサー需要について。
• references/proof-point-instruments.md - 双方向のデューデリジェンスチェックリスト、測定手段ごとの収集ガイド、初回開催時の代替手段、価値方程式の評価チェックについて。

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

• samber/dev-event-organizer-skills@event-sponsor-prospectus - このスキルの記述を、協賛プランと根拠を盛り込んだ企画書にまとめます。
• samber/dev-event-organizer-skills@event-sponsor-pricing - このスキルで明らかにした価値に価格を付けます。価値の主張が料金表の根拠となるのであり、その逆ではありません。
• samber/dev-event-organizer-skills@event-sponsor-outreach - 価値を売り込み、異議の記録を測定に関するこのスキルへフィードバックします。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment - 約束した内容を実現し、契約更新につながるイベント後レポートを作成します。
• samber/dev-event-organizer-skills@event-positioning - コミュニティとベンダーのどちらに軸足を置くか、このスキルが分岐する選択と、地域の他の選択肢の中でイベントを際立たせる方法は、ここで決めるポジショニング上の判断事項です。
• samber/dev-event-organizer-skills@business-event-formats - 主張する価値カテゴリーを現地で実現する、ビジネス向けのアクティビティ形式です。
• samber/dev-event-organizer-skills@event-first-edition - 実績がまだない場合を扱います。そこで設定される根拠の基準が、このスキルで初回開催時に用いる代替手段の参考になります。