startup-pitch-contest

スタートアップ・ピッチコンテスト

大規模なテクニカルイベント内で開催する、デモデー、スタートアップショーケース、ピッチコンペティションなどのピッチコンテストを設計し、運営します。以下を扱います。

• 誰がステージに立つか。
• ステージに立った後、何をするか。
• 誰が、何を基準に審査するか。
• 審査員は、見たばかりの企業に対して、その後どのような行動を取れるか。
• 優勝者が実際に何を受け取るか。

ビルドフェーズなし

ハッカソンでは、イベント中に組み立てられ、審査員が会場で実際に確認できる成果物を審査します。一方、ピッチコンテストでは、参加者が到着する前から存在し、全員が帰った後も存続する企業を審査します。この違いは、すべてのセクションに次の3つの影響をもたらします。

1. 結果を左右する要素のほとんどは、持ち時間の中では確認できません。 samber/dev-event-organizer-skills@hackathon-judging は、「最も配点の高い評価基準が、審査員が持ち時間の中で実際に確認できるものか確かめる」よう読者に指示しています。この指示をここで適用すると、ピッチの評価基準の大半が成り立たなくなります。トラクション、リテンション、利益率、チームの経歴は会場の外にある世界についての主張です。そのため、審査の課題は当日の観察ではなく、応募内容との照合による検証になります。
2. 準備状況はイベントではなく、応募者に属する要素です。 ハッカソンなら、追加の開発時間を設けて未完成のプロジェクトを完成に近づけることができます。しかし、応募締切からステージに立つまでの間に企業の準備状況を高めるものは何もありません。そのため、候補者リストの質を左右するすべての要素は、応募者選考の段階で決まります。
3. ここでは、開発作業やその会場、メンターの手配は一切行いません。 ビルドフェーズがないため、引き継ぎも不要で、それを担当する関連スキルもありません。

担当範囲と、すでに決まっていること

• ブロックはあなたの担当ではありません。 samber/dev-event-organizer-skills@event-format-selection が時間枠の形を決め、samber/dev-event-organizer-skills@event-schedule-design が公開済みのグリッドにそのブロックを配置します。あなたはそのブロックの_中で_設計し、セッションを移動させてはいけません。
  • フォーマット選択のデモ構成メニュー（展示テーブル、ステージでのピッチ、動画のみ、2ステージ）は、イベントで制作したプロジェクトを発表するハッカソンチーム向けに作られており、スタートアップのピッチコンテストには言及していません。
  • 以下のピッチ形式は、ここで独自に提案するものであり、合意済みではありません。そのことを発表時に伝えてください。
• 採点の計算はあなたの担当ではなく、再導出してはいけません。 samber/dev-event-organizer-skills@hackathon-judging は、審査員の時間予算に関する問題を一般的な形ですでに解決しています。全チームを審査できる上限、チームあたりの審査範囲の計算式、3つの配分区分、実現可能性の判定基準は、すべて同スキル独自の審査員配分リファレンスに記載されています。
  • そのスキルを開いてリファレンスを読み込み、独自の数値を入力して、回答を利用してください。
  • 意味が変わる入力は1つだけです。ハッカソンのチームあたりの数値は、実地での引き継ぎ時のセットアップと入れ替えに大きく左右されますが、連続したステージブロックにはそのような作業はありません。計算式を使い、入力値を測り直してください。
  • 全体の調整方法は references/pitch-block-and-rubric.md に記載されています。
• 創業者と投資家の1対1ミーティングはあなたの担当ではありません。 samber/dev-event-organizer-skills@event-b2b-matchmaking が担当しており、ピッチコンテストが発展しがちな構成をすでに「ミーティング用の一角があるカンファレンスではなく、創業者と投資家のために厳選した1日」と表現しています。ピッチは審査員に向けた発表であり、ミーティングは予約されたペアの面談です。そちらに案内し、ここでは予約の仕組みを作らないでください。
• 賞金の構成は、おそらく適用されません。 samber/dev-event-organizer-skills@hackathon-cash-prize は全編を通じてハッカソンを対象としており、賞金の媒体メニューも、あるハッカソン主催者の賞金ガイダンスに基づいています。デフォルトでこれを参照しないでください。
  • 基準値、フォーム名、通貨額を明示しないという方針は引き継がれ、以下でも採用しています。
  • その振り分け方針も引き継がれ、以下でも採用しています。

このスキル内でも、このスキルを基に作成するものの中でも、以下を明示してはいけません。

• ピッチの長さ。
• 登壇枠の数。
• 審査員の人数。
• 応募数。
• 採択率。
• 賞金額。
• 株式の割合。

この7つは、つい適当に作っても問題なさそうに感じる数量ですが、ひとたび作られた数字は、それに付けられた但し書きよりも長く残ります。公表済みの数値で例外となるのは1つだけです。DevOpsDays の主催ガイドによると、ピッチイベントへの参加にあたって、通常は旅行や休暇の手配に少なくとも4～6週間を要します。

以下の各ランキングはすべてデフォルトであり、絶対的なルールではありません。インタビューの後、すでに把握している情報を基に4つのメニューすべての順位を付け直してください。次のいずれかに該当する場合、デフォルトの順位が覆ります。

• 主催チームにファンドのパートナーがすでにいる。
• イベント開催前から続いているアクセラレーターとの関係がある。
• 募集開始前に、招待によって登壇枠の半分がすでに埋まっている。
• ステージブロックを拡大できない。

インタビュー

一度に質問するのは一つにし、可能な場合は選択式にします。以下のメニューによって質問4〜6と9〜10が有効になります。それ以外で、その内容を把握できる質問はありません。

1. コンテストは公開済みのプログラムにすでに記載されていますか。また、企業がそのステージに登壇する方法について、すでに何が公表されていますか。何かを設計する前に確認してください。公表済みの参加経路は約束であり、出発点ではありません。
2. 登壇企業の対象を、数ではなく企業の段階で表すと、プロダクト開発前、最初の顧客を獲得済み、またはトラクションを得て資金調達中のどれですか。誰がそれを決めましたか。また、応募者が読める形でどこかに記載されていますか。
3. コンテストが使うのはグリッドのどの枠ですか。その枠はすでに確定していますか。また、何社の参加を見込んでいますか。
4. 審査員は誰ですか。役割を挙げてください。現役の投資家、事業運営者、顧客、スポンサーの代表者、イベントが地域または公共部門の使命を担う場合は地域または公共部門の代表者です。投資家の審査員については、それぞれのファンドが参加企業の段階に投資していますか。また、審査員か観客かを問わず、誰が登壇するかを理由に招待された人はいますか。
5. 優勝者が実際に受け取るものを項目ごとに挙げてください。それぞれについて、どの当事者が提供しますか。また、書面で確約されていますか。
6. 賞品に、資金、転換証券、またはいかなる形態の株式も含まれていますか。含まれている場合、その資金を提供することがコンテストの目的ですか。それとも、いずれにしても開催されるコンテストに付随する賞品ですか。
7. コンテストの一部にスポンサーが付いていますか。また、署名済みの契約によって、スポンサーが登壇者や優勝者の選定に意見できるようになっていますか。
8. 会場は録画・配信されますか、または報道関係者に公開されますか。応募者には応募前にそのことが伝えられていましたか。
9. 今回限りの開催ですか。それとも、来年も適用できるルールが必要な継続開催のコンテストですか。募集要項と選考基準はいつまでに公開する必要がありますか。
10. 労力の上限はどの程度ですか。応募受付期間全体で主催者に必要な作業時間、応募書類を読む人、優勝者への提供を約束した第三者への確認を担当する人を教えてください。また、企業を推薦する指名済みの紹介者など、初期設定を覆す根拠となる既存のものはありますか。

ワークフロー

1. インタビューを実施します。何かを設計する前に、すでに公開されている内容（Q1）と、渡されたブロック（Q3）を読みます。
2. ファネルより先に賞品を決めます - samber/dev-event-organizer-skills@hackathon-cash-prize が自らの領域について主張しているのも、同じ順序です。優勝者が何を受け取るかによって、誰が応募するのか、どの審査員が参加するのか、そして弁護士が構成を確認する必要があるかどうかが決まります。
3. メニューからファネルを選び、フォームを作成する前に、公開する応募経路を一文で書き出します。項目一覧はreferences/application-and-slate-mechanics.mdにあります。
4. 応募締切前に、募集要項で評価基準とその配点を公開します。samber/dev-event-organizer-skills@hackathon-judging は、その理由をそのまま使える一文で述べています。「非公開の配点は、誰も応募していないコンテストを採点することになります。」
5. メニューからプレゼンテーション形式を選び、次に samber/dev-event-organizer-skills@hackathon-judging の配分計算から、数値ではなく計算方法を参考にして、ブロックが実際に応募者一覧を収容できるか確認します。
6. 審査員が確認できる内容に基づいてルーブリックを作り、観察可能な項目と、申告に基づく項目を分けます。両方の一覧と、肯定・否定の採点例はreferences/pitch-block-and-rubric.mdにあります。
7. メニューから利益相反ルールを決め、応募書類を一件でも見る前に、採点前ではなく、すべての審査員に説明します。全段階の一覧とスポンサーに関する難しいケースはreferences/investor-conflict-and-prize-policy.mdにあります。
8. 以下の3つのゲートを実施します。いずれかに該当した場合は、受賞者の発表前に、弁護士または確約した当事者が構成を確認します。
9. ブロックを実施します。事前に用意した一覧から発表し、samber/dev-event-organizer-skills@hackathon-judging が定めるものと同じコンテストの進行手順を明示します。すなわち、誰が異議を申し立てられるのか、価値あるものが移転する前に終了する期限、そして実際に変更できる内容です。
10. 項目ごと、当事者ごとに、発表した内容と実際に提供された内容を記録し、その先へは何も引き渡しません - 賞の締めくくりはあなたの責任です。

募集を公開する前に、設計の各セクション（賞品、ファネル、形式、ルーブリック、利益相反ルール）を順に提示し、確認を受けます。公開された募集要項は、それに合わせて会社の1カ月の予定を組み替える創業者への約束です。

ハーネスに永続メモリーがある場合は、公開した応募経路と評価基準、各賞品項目とそれを確約した当事者、申告された審査員の利害関係すべて、そしてその後、実際に提供された項目を記録します。

選考ファネル

4段階：

• 主催者による招待：主催者がすでに知っている企業から応募者一覧を作ります。

• 公募、単一の審査パス。

• 公募、スクリーニング面談あり：応募者一覧を確定する前に実施します。

• 指名された紹介者による推薦：ファンド、アクセラレーター、またはコミュニティのリーダーがそれぞれ企業を推薦し、主催者が集まった候補から選びます。

• 労力（実施期間中の主催者の作業時間、審査パス数、公募を継続するために必要な宣伝活動）：open plus screening call > open single pass > nomination > curated invitation

• 価値、応募者一覧の質（審査員と聴衆がその場に残って話を聞きたいと思うプレゼンテーション）：open plus screening call > nomination > curated invitation > open single pass

• 価値、パイプラインの広さ（自力では決して見つけられなかった企業）：open plus screening call == open single pass > nomination > curated invitation

• コンプライアンスコスト（それによって発生する審査と、失われる取り消し可能性）：open plus screening call > open single pass > nomination > curated invitation

• 効率：open single pass > nomination > curated invitation > open plus screening call 幅広さの == は、判断を避けるために主張しているのではなく、適用範囲を基準にすると固定されます。適用が認められる対象は誰かによって幅広さが決まり、どちらのオープンな段階もまったく同じ対象に開かれているためです。二度目の審査で候補者リストは絞られますが、対象範囲が広がることはありません。この軸では二つの段階は真に等しく、その他のすべての軸で異なります。

ここでコンプライアンスの軸は現実的で、見落としやすいものです。すべての応募者が非公開企業に関する資料を提出します。募集範囲が広く、資料を読む人が増えるほど、管理責任が重くなり、取り下げられる範囲も狭まります。審査担当者に回覧された資料を、後から回収することはできません。スクリーニング通話は、創業者がフォームで尋ねた以上のことを話し、しかも何を話したか記録が残らない段階であるため、この軸で最も高い位置にあります。

優位性チェックを再導出すると、組み合わせは6通り、厳密な優位関係はゼロです。その理由は、2つのグループに分けると6通りすべてを説明できます。

• 4通りの組み合わせ、つまりスクリーニング段階と他の3段階のそれぞれとの組み合わせ、および指名と厳選招待の組み合わせは、通常の理由で成り立ちません。価値で上回る段階は、労力とコンプライアンスの両方で厳密にコストが高くなります。
• 残りの2通りは、2つの価値軸が実際に食い違うため成り立ちません。オープンな単回審査と指名、オープンな単回審査と厳選招待です。ここでは、オープンな段階は幅広さで上回る一方、候補者リストの質では劣るため、どちらの段階も両方の軸で少なくとも同等とは言えません。

構成上の理由からのみ、問題はありません。このチェックでは何も見つからず、効率性の判断は以下の根拠に基づいています。

• オープン応募、単回審査 - デフォルト。 すでに好感を持っている企業を招待するのではなく、コンテストを開催する理由そのものを、審査1回で実現できます。弱点は隠さず明示しています。面識のない応募者を書類で審査する方法は、創業者がステージに立つ様子を予測するうえで、利用できる方法のなかで最も精度が低いため、候補者リストの質では最下位に位置します。
• 指名された紹介者による推薦。 紹介者自身の評価も推薦する企業にかかっており、応募対象は主催者の知人リストより広くなります。
  • 昇格条件、Q10に対応： 実際に推薦してくれる、指名された紹介者がすでに存在すること。
  • 何もない状態から単独の開催回向けに構築すると、この段階は割に合わなくなります。応募が1件届く前に、募集と説明のコストが発生するためです。
• 厳選招待。 すべての軸で最も低コストですが、1位ではなく3位です。その理由は明確です。コンテストを開催しなくても主催者が作成できた候補者リストであり、この仕組みはその名が約束するものを何も付け加えません。
  • Q1で一般公開の登壇応募ルートがすでに告知されているとわかった場合は、この選択肢のメニューと、上記の各軸の記述から削除してください。 募集を行ってから、候補者リストを自分の知り合いで埋めることは、このスキルで最も異議を唱えられやすい行為です。
• オープン応募とスクリーニング通話 - 出番を奪われた選択肢。 候補者リストの質が最も高く、労力もコンプライアンスコストも最も高いため、効率性の観点から選ばれることはありません。一方で、フォームからはわからないこと、つまり創業者が会場の人々を惹きつけられるかを試せる唯一の段階でもあります。2つの昇格条件があり、それぞれ個別に根拠をたどっています。
  • Q3に対応： ブロックの時間は固定かつ短く、その時間内に登壇する候補者リストは長いため、質の低いピッチが1つあると、取り戻せないブロック時間の一部が失われます。
  • Q4に対応： 審査員または観客が、誰が登壇するかを理由に招待されています。候補者リストそのものが提供価値であり、その価値は実際の候補者と照らし合わせても損なわれないものでなければなりません。

オープンな段階のスケジュールは、samber/dev-event-organizer-skills@event-cfp-design の設計を引き継いでいます。早めに募集を開始し、イベントより十分前に締め切り、締め切りからイベントまでの期間に審査します。また、譲れない最低条件も引き継いでいます。採択された参加者が渡航を手配するために必要な、公開済みの準備期間です。この最低条件を下回る場合、オープンな段階は機能せず、候補者リストは招待制になります。基準となる情報、公開済みの数値、およびそれを適用できる範囲の制限については、references/application-and-slate-mechanics.md を参照してください。

ピッチ形式

4つの段階：

• ステージでのピッチのみ：固定枠で、質疑応答はありません。

• ステージでのピッチと審査員からの質問。

• ステージでのピッチと質疑応答に加え、ファイナリストとの非公開の詳細審査。

• 事前に採点する書面または録画での応募と、ファイナリストのみを対象とするステージでのピッチ。

• 労力（消費する枠の分数、審査員の時間、実施するラウンド数）：詳細審査 > 事前採点＋ファイナリストのステージ登壇 > ピッチ＋質疑応答 > ピッチのみ

• 価値、採点時に審査員が実際に得ている根拠：詳細審査 > 事前採点＋ファイナリストのステージ登壇 > ピッチ＋質疑応答 > ピッチのみ

• 価値、会場にいる人々が得るもの（イベントがこの枠の対象として集めた観客）：ピッチ＋質疑応答 > ピッチのみ > 事前採点＋ファイナリストのステージ登壇 > 詳細審査

• コンプライアンスコスト、発生するレビューと、それに伴う取り消し可能性の低下：詳細審査 > 事前採点＋ファイナリストのステージ登壇 > ピッチのみ == ピッチ＋質疑応答

• 効率性：ピッチ＋質疑応答 > ピッチのみ > 事前採点＋ファイナリストのステージ登壇 > 詳細審査

会場の軸があることで、この選択肢を決定可能になりますが、ほかの3つの軸とは逆の評価になります。ピッチ枠で創業者が原稿を読み上げないのは質問に答えるときだけであり、それが最も高く評価される理由です。事前採点と詳細審査はいずれも、観客が見に来たものを縮小するか、見えなくします。詳細審査は決定的な部分を完全に隠します。会場の人々はピッチを見たあと、見えない場所で決まった結果を聞くことになります。

コンプライアンスの == には議論の余地があります。どちらのステージ形式でも、同じ資料が同じ公開の場に提示されます。また、公開ステージでの質問への回答によって、そこでの発言の場合にはなかった管理責任が主催者に移るわけではありません。情報の露出を決めるのは会場が公開されていることであり、誰かが質問したかどうかではありません。

• 事前採点は、主催者が書面資料を受け取り、保管するうえ、誰がそれを読むのか、その後どう扱うのかを明示しなければならないため、どちらのステージ形式よりも上位になります。
• 詳細審査がこの軸で最も上位なのは、観客も記録もない場で機密情報を扱う唯一の形式だからです。

優越性チェック、再導出：6組を比較し、厳密な優越関係はゼロ、2つのグループに分かれます。

• 5組は、詳細審査または事前採点の形式を含む組み合わせです。2つの価値軸の評価が一致しないため、いずれも優越関係は成立しません。それぞれの形式は、根拠の面では優れていますが、会場が得るものの面では劣るため、両方の価値軸で少なくとも同等とはいえません。
• 6組目は有益な比較です。労力だけが優越関係を妨げています。ステージでのピッチと質疑応答は、コンプライアンスコストが同じでありながら、両方の価値軸でステージでのピッチのみを上回ります。ただし、必要な枠の時間が増えるため、完全な優越には至りません。

この結果が、より低コストの下位形式ではなく、現在の位置にデフォルトを置く理由です。

• ステージでのピッチと審査員からの質問 — デフォルトです。理由は、直前の優位性チェックで示したとおりです。
• **ステージでのピッチのみ。**最も低コストで、賞が称号とステージ上でのひとときである場合には誠実な選択です。
  • Q5で、賞によって第三者が何かを約束することになると分かった場合は、この選択肢メニューと上記の軸の行から削除します：紹介、面談、参加枠、資金などです。何の台本もない回答を聞かずに下された判断に基づいて行動するよう、関係のない第三者に求めることになります。
• **事前採点付きの応募とファイナリストのステージ発表。**審査の一部をライブ枠の外に移します。これは、審査時間内に参加者全員を収められないという計算結果が出た場合に、samber/dev-event-organizer-skills@hackathon-judging が採るのと同じ手段です。その計算結果がそう示すなら正しい選択ですが、そうでない場合は得策ではありません。観客が見られる枠を、より少ない企業に費やすことになるためです。
• **ファイナリストとの非公開の詳細審査 — 選ばれにくい選択肢。**証拠の質、労力、コンプライアンスコストがいずれも最も高く、会場にもたらされるものが最も少ないため、効率性の観点では決して選ばれません。これを選ぶ場合は、応募締切前に、その存在と参加者を公表します。促進の条件は2つあり、それぞれ別に追跡します。
  • **Q6に連動：**賞に資金が含まれる場合です。その場合、公開ピッチでは、賞の正当化に必要な事実を確認できません。
  • **Q2に連動：**ピッチを行う参加者がトラクションをもとに資金調達を行っていると説明されている場合です。その場合、審査員は売上、継続率、顧客獲得コストなど、ステージ上の枠では示せない主張を評価するよう求められています。

投資家の利益相反

ここでハッカソンのモデルは破綻します。その形を変えずに再利用することが、このセクションで防ごうとしている誤りです。ピッチコンペティションの審査に関する実務者向けガイダンスは、同じ出発点となる考え方に収束しています。審査員は、自身の投資先企業、自身の所属組織のチーム、または過去に助言した相手を採点すべきではありません。しかし、ガイダンスは忌避の話で終わり、以下の3つの構造的な違いには触れていません。

samber/dev-event-organizer-skills@hackathon-judging の段階表では、チームとの親密さ、所属組織や競合組織との関係、スポンサーとの関係が扱われています。いずれも 結果 に対する利害であり、投票権をなくす採点からの忌避によって解消されます。この段階表でスポンサーに特化しているのは、上位の段階と、対応が難しいケースだけです。

投資家の審査員の利害は、構造的に3つの点で異なります。どれも忌避だけでは解消されません。

1. **利害の対象は結果ではなく、アクセスです。**審査員は採点するかどうかにかかわらず、企業を早期に見る機会を得ます。忌避しても投票権がなくなるだけで、その優位性は残ります。
2. **利害が逆方向に働くことがあります。**応募企業の競合企業に持ち分を持つ審査員は、その応募企業に 勝ってほしくない という利害を持ち、審査員がその企業の隣に立っている間に、その企業を平凡に見せたいと考える可能性があります。
3. **審査員自身にも守るべき義務があります。**パネルに参加する投資家は、自身の所属機関の開示規則や割り当て規則の適用を受けることがよくあります。そうした義務を解釈したり、果たしたりするのは、あなたの役割ではありません。審査員がそもそも参加を許可されているかどうか、書面で確認する理由になります。

4段階です。

• 明示されたルールなし。

• 採点時の忌避のみ：ハッカソン方式をそのまま適用。

• 忌避に加え、ピッチを行う企業への事前開示。

• 忌避と開示に加え、明示された連絡プロトコル：審査員がこのステージで知り合った企業に個別に接触するまでの待機期間を設け、接触する際は主催者を通すルートを定めます。

• 価値、企業や会場にとっての結果の信頼性：contact protocol > disclosure > recusal only > no stated rule

• 労力（利害関係の収集、審査員への説明、当日の追跡、その後のルールの適用）：contact protocol > disclosure > recusal only > no stated rule

• コンプライアンスコスト（発生するレビューと、それによって失われる取り消し可能性）：contact protocol > no stated rule > disclosure > recusal only

• 効率性：disclosure > recusal only > no stated rule > contact protocol コンプライアンスの軸は意図的に単調ではなく、その根拠は他の領域から借りたものではなく、この領域に固有のものです。

• 明示されたルールなしでは、イベント前のレビューは行われず、レビュー全体が最も後戻りしにくい時点、つまり審査員が自分たちで作成に関わったランキングをもとに企業に接触した後に先送りされます。いったん接触してしまえば取り消せず、企業はステージ上で起きたことすべてを、後から逆向きに読み解くことになります。

• 忌避のみは、実質的な選択肢の中で最も低コストの段階です。審査員向けの説明資料に一行加えるだけで、結果がまだ存在しないうちに採点者を交代すれば、見落とした関係をひそかに修正できます。

• 開示は、それより上位です。ピッチを行う企業に向けて発言した内容は、取り消せないからです。

• 接触プロトコルは、撤回が最も困難です。独立した専門家が自分たちの案件の流れをどう扱うかを主催者が取り締まると約束することになり、次回開催でそれを撤回すると後退と受け取られます。

優越性の確認、再導出：6組で、厳密な優越関係はゼロ。2つのグループに分かれます。

• 4組、つまり接触プロトコルと残り3つの各選択肢、および開示と忌避のみの組み合わせは、通常の理由で成立しません。価値の高い段階ほど、労力とコンプライアンスのコストがともに厳密に高くなります。
• 残りの2組が示唆に富むもので、労力だけが理由で成立しません。開示は明示されたルールなしよりも、忌避のみは明示されたルールなしよりも、それぞれ価値とコンプライアンスの両面で優れています。どちらの場合も、ルールを書き留める手間だけが関係の成立を妨げています。

これをメニューの実際の結論として読んでください。最下位の段階は、ルールの安価な簡易版ではありません。コスト軸でも価値軸でも劣っているため、順位付けされるのではなく削除されます。

• 忌避と、ピッチを行う企業への開示の組み合わせ — デフォルト。 忌避のみは、利害が投票にある領域から持ち込まれたものです。ここでは利害が見学によって生じるため、忌避だけではハッカソンほどの効果はありません。開示には説明資料にもう一行、ブロックの前にスライド一枚を追加するだけで済み、実際に存在する利害に対処する最初の段階です。
• 採点に関する忌避のみ。 パネルが投資家ではなく、運営者や顧客で構成されている場合に適しています。対象外となるものを明確に伝えてください。
• 明示されたルールなし。 Q4でパネルに現役の投資家が一人でも見つかったら、このメニューと上記の軸の両方から削除してください。 ほとんどのピッチコンテストで削除されますが、運営者と顧客だけで審査するコンテストは現実にあり得る構成であり、仮定上のものではないため、選択肢には残されています。
• 接触プロトコル — 選ばれにくい選択肢。 価値、労力、コンプライアンスコストのすべてで最上位です。昇格条件は2つあり、それぞれ別個にたどられています。
  • Q6に基づく条件： 賞に資本や金融商品が含まれる場合、審査員自身の所属機関がすでに結果の当事者であり、非公式な経路を利用できたわけではありません。
  • Q9に基づく条件： 公開済みのルールでプロセスをすでに約束している、継続開催のコンテストです。samber/dev-event-organizer-skills@hackathon-judgingは独自の登録段階を昇格させる際に同じ考え方を使っており、ルールが公開された後は仕組みも同一です。

賞品と機会の構造

4つの段階：

• 表彰のみ：称号、ステージ上での瞬間、紹介記事。
• 確約された紹介：主催者または審査員が実際に行う、紹介先を明記した温かい紹介。
• 特定の第三者との確約済みの枠：パートナーとの面談、プログラムへの参加枠、一定時間のオフィスアワー。
• 賞品としての資本：投資、転換型の金融商品、または株式を伴う賞。
• 価値、受賞者が実際に活用できるもの：capital > committed slot > committed introductions > recognition only
• 価値、実現可能性（受賞者が告知されたものを、実際に受け取れるか）：recognition only > committed introductions > committed slot > capital
• 労力（確約を書面で取り付けること、第三者との調整、全員が帰宅した後に履行を催促すること）：capital > committed slot > committed introductions > recognition only
• コンプライアンスコスト、審査が引き起こす負担と、そのために失われる柔軟性：capital > committed slot > committed introductions > recognition only
• 効率：committed introductions > recognition only > committed slot > capital

ピッチコンテストの主催者が忘れがちなのが実現可能性の軸です。賞を約束する人は会場では熱意を見せても、3か月後には不在だからです。

• 表彰は、あなた一人でステージ上で実現できます。
• 紹介は、あなたが管理できる1通のメッセージです。
• 確約済みの枠は、他の誰かの予定次第です。
• 資金は、デューデリジェンス、書類、そして告知した本人が決定権を持っているとは限らない判断を含むプロセス次第です。告知された後に、結局実現しない可能性がある唯一の賞です。

これは、samber/dev-event-organizer-skills@hackathon-cash-prizeが機会の段階について独自に示している警告を、軸全体に広げたものです。同プロジェクトのカタログがそのまま全て当てはまるわけではありませんが、ここでも無関係ではありません。同カタログの機会の段階には、投資家の紹介とシード資金のピッチがすでに挙げられているため、以下の紹介の段階は共通する部分です。資金そのものは、同カタログに該当する段階がありません。

優越性の確認、再導出：6組を比較し、厳密な優越関係はゼロ、6組すべてを網羅する仕組みが1つ。

• 2つの価値軸は正確に逆の順序です。そのため、どの組み合わせでも、実用価値で上位の段階は実現可能性で下位となり、両方の軸で少なくとも同等となる段階はありません。
• どの組み合わせでもコスト軸には到達しません。この点は暗黙のままにせず、明記する価値があります。
• この仕組みをそのまま合格と見なさず、疑ってください。実現可能性は、逆労力および逆コンプライアンスと順位が同一です。そのため、コスト軸がすでに示す以上の差は生まず、確認を二重に無意味にします。それでも残すのは、実際のリスクを示しているからであり、何かを決定するからではありません。

以下の議論が、この順序の根拠です。

• 確約済みの紹介 - デフォルト。 この対象層に固有の価値があり、最初から最後まで提供を管理できる唯一の段階です。すでに同意している人の氏名入りリストを用意し、賞と併せて公表した期限までに、一人ずつメッセージを送ります。双方の同意が必要です。紹介を受ける側も、紹介されることに同意していなければなりません。
• 表彰のみ。 すべての軸でほぼ負担がなく、失敗ではなく正当な構成です。これは、現金賞を扱う同系列のプロジェクトが、表彰の段階について主張していることとまったく同じです。賞よりもステージ上での体験を目的とするコンテストでは、これが適切です。
• 第三者の名前を明記した確約済みの枠。 実質的な価値がありますが、そのコストは、あなたではない誰かが数か月後に何かをしなければならないことです。告知前に、担当者名と日付を明記して書面で確約を取り付けてください。そうしなければ、他人の意向を告知したにすぎません。
• 賞としての資金 - 後回しにされる選択肢。 実用価値は最上位、実現可能性は最下位、労力とコンプライアンスコストは最上位のため、効率性では選ばれません。
  • Q5で、いずれの当事者からも書面で確約を得ていないと回答された場合、この選択肢をこのメニューから、また上記の軸の行からも削除してください：賞が実現しないのは問題ですが、資金の賞が実現しない場合、その資金を前提に会社が意思決定をしていることになります。
  • Q6に連動した昇格条件： 資金を用意することが、もともと実施予定のコンテストに賞品を付けるのではなく、コンテスト自体を開催する理由であること。その場合、賞がコンテストの主目的となり、効率性は判断に関与しません。ただし、以下の最初のゲートは必ず適用されます。

3つのゲート

効率性ランキングは、これらの判断には関与しません。3つのゲートはいずれも好みではなく義務であり、労力と比較衡量するのではなく、対応を決定します。効率性で順序を付けるのは、残った項目だけです。

3つには共通点があります。それぞれ1つの聞き取り回答をきっかけに発動し、保護するタイミングが来る前に判断を確定する必要があります。Q6では発表前、Q7では応募締切前、Q8では該当するブロックの開始前です。

• Q6 - 資本、転換証券または株式を伴う賞。 賞の発表前に法律顧問へ相談してください。
  • このスキルでは、証券に関する基準値、投資法上の分類、免除の名称、通貨額を一切示しません。 これは、同じ理由からここでも採用している、samber/dev-event-organizer-skills@hackathon-cash-prize が自身の領域に適用する恒常的な方針です。投資の設計方法を主催者に伝える文書に、もっともらしい基準値を載せるくらいなら、何も案内しないほうがましです。
  • この兄弟スキルも別の方向から同じ境界にたどり着き、同じ地点で立ち止まっています。このような賞は「法域によっては、雇用または証券に関する規則に関わる可能性がある」と判断しています。
  • もう1つの該当する分類は、コンテスト法上の分類であり、同様に相談へ回します。つまり、開催地でその競技がスキルベースのコンテストとみなされるか、それ以外のものとみなされるかです。
• Q7 - 誰が登壇するか、または誰が勝つかについて、契約上の発言権を持つスポンサー。 これは利益相反の選択肢の段階ではなく、厳しいケースです。スポンサーが自社のトラックを審査する場合に samber/dev-event-organizer-skills@hackathon-judging が採る方法に倣い、発言権を購入した範囲に限定し、中立的な審査員を組み合わせてください。その採点を除外しても結果が変わらないかを確認し、応募締切前に審査体制を開示してください。
  • 交渉の余地がない点が1つあります。「スポンサーが登壇枠を買うことはできません。決して、絶対にです」（DevOpsDays 主催者ガイド）。
  • 投資家の前で行うステージ登壇も講演枠であり、販売するものではありません。
• Q8 - 応募者に事前告知されていない会場内での録画、配信、または報道。 これは後から取り繕えません。会場を録画しないか、すべての応募者に知らせて、該当ブロックの開始前に再同意を得る必要があります。ピッチステージでは、創業者が、自分で配信を管理できる発言をする機会は一度きりです。

失敗パターン

• ハッカソンの利益相反ルールをそのまま持ち込む。 忌避は、スポンサーが結果に対して持つ利害に応えるものです。審査員がアクセスに対して持つ利害には応えません。そして、投資家である審査員が求めているのはアクセスです。
• 賞品を決める前に応募導線を設計する。 何を提供するかによって、誰が応募するかが決まります。応募導線を先に設計すると、誰も資金提供に合意していない賞のためのパイプラインを作ることになります。
• どの審査員も確認できない基準に重みを付ける。 トラクション、リテンション、利益率は、応募時に検証するか、まったく検証しないかのどちらかです。確認できるものがないままそれらに重みを付ける評価基準では、ピッチの自信を採点することになります。
• 第三者が書面で確約していない賞を発表する。 会場での熱意は本物ですが、確約ではありません。失敗は公になり、受賞者に及び、全員が帰宅したあとに起こります。
• スポンサーにピッチ枠を購入させる。 これは講演枠を購入するのと同じ取引であり、前述の公開済みの方針では例外なく禁じられています。
• 審査員の担当範囲の計算をやり直す。 その計算はすでに行われています。複製をもう一つ作ると、正確さを保つ対象が増え、間違える機会も増えます。
• 面談予約の仕組みを作る。 枠、確認、ノルマが設計に加わったら、それは別のスキルの仕事です。そちらに回してください。
• デモデーを、スライドが良くなっただけのハッカソンとして扱う。 開発フェーズがないため、何かを立て直す時間はありません。また、イベントで審査対象が改善されることもありません。
• 公開されていない技術的な好みで結果を決める。 主催者や審査員が、たとえば薄いラッパーより深いエンジニアリングを好むという個人的な思い入れを持っていると、それが公開された基準になっていなくても、誰が勝つかを左右します。公開された基準に合わせて最適化した企業が、知るよしもない基準に合わせた企業に負けることになります。

測定

合格基準（構造上の基準は1つのみ）：募集を公開する前に、以下の6項目すべてが空欄なしで文書化されていること。

• 登壇に至るまでの公開済みの選考経路。
• 重み付けを含む評価基準。
• ピッチ形式と、それが収まる時間枠。
• 対象範囲と対象外が明記された利益相反ルール。
• 各項目を確約した当事者を明記した賞の一覧。
• 3つのゲートすべてへの回答。

数が6になるまで繰り返してください。

その後に記録する価値のあるシグナルは、すべて独自に設定してください。

• 発表した賞品と、各当事者が実際に提供した賞品の比較。
• 申告された審査員の利害と、後から明らかになった利害の比較。
• チームの誰も事前に知らなかった企業からの応募数。これは、応募導線が招待者リストでは得られない何かをもたらしたかどうかを測る唯一の指標です。
• 当日に創業者が尋ねた質問のうち、募集要項で答えておくべきだったもの。

2つか3つを選び、それぞれがどのような改訂につながるかを書き留めてください。

この応募導線のモデルとなった募集から引き継がれる注意点が1つあります。応募者層の拡大はアウトリーチの仕事であり、審査の仕事ではありません。DevOpsDays の主催者向けガイドには「技術分野で十分に代表されていない人々は、CFP に応じる可能性がはるかに低い」とあります。公開募集だけでは、アウトリーチが届かなかった応募者層をカバーできません。

呼び出し例

• 「カンファレンスにスタートアップのピッチコンテストを追加します。企業が登壇するにはどうすればよいですか？」
• 「審査員のうち3人はベンチャーキャピタルの関係者で、1人はピッチした企業への投資を希望しています。何を文書に残しておくべきですか？」
• 「スポンサーが賞金を提供し、ピッチする企業を2社選びたいと言っています。可能ですか？」
• 「優勝者には、スポンサーであるファンドのパートナーとの面談が贈られます。発表前に何を合意しておく必要がありますか？」
• 「各ピッチの長さはどのくらいにし、枠に何社入れられますか？」

期待される出力：以下を含むコンテスト設計。

1. 各賞について、提供を確約する当事者と書面での確約状況を示した賞の一覧。
2. 公開する応募経路を一文で記載し、評価基準と配点を含めた選考プロセス。
3. samber/dev-event-organizer-skills@hackathon-judgingから取り入れた枠の計算方法と、ステージ向けに再測定した入力値を含むピッチ形式。
4. 観察できる要素と申告に基づく要素に分けた評価基準。
5. 対象範囲と対象外を明記した利益相反ルール。
6. 3つのゲートへの回答と、それぞれの振り分け先。
7. 発表とコンテストの進行経路。

公表前に検証できるようセクションごとに提示し、借用した要素と独自に設定した要素のすべてにその旨を明記してください。また、禁止されている7つの数量は、いずれも記載しないでください。

参考資料

• references/application-and-slate-mechanics.md - 一文で示す公開済みの応募経路、各項目の目的と保管責任の有無を記した応募フォーム項目一覧、募集要項における評価基準のテンプレート、選考面談とその限界、日程の基準点、公開経路のペア。
• references/pitch-block-and-rubric.md - 観察可能な要素と申告に基づく要素の切り分け、各評価軸の検証元を示した評価基準の例、samber/dev-event-organizer-skills@hackathon-judgingの配分計算式を再導出せずに適用する方法、同点時の優先順位、採点例のペア。
• references/investor-conflict-and-prize-policy.md - 審査員向け説明文の文面を含む詳細な利益相反の段階的対応、スポンサーの難しい事例、公開可能な文面で示した連絡手順、賞の確約チェックリスト、3つのゲートの振り分け手順、網羅的な不足事項の一覧。

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

• samber/dev-event-organizer-skills@event-run-of-show - ここで確定した形式に沿って、当日の進行を担います。