ハッカソンアイデア は何をしますか？
私たちは、根本原因で現実の問題を解決するアイデアを構築します。それは特定の人物のためのものであり、問題が存在するという証拠に裏付けられ、洞察（通常のアプローチが失敗する中で、この解決策を機能させる非自明な事実）に基づいています。 小さくてシンプルなものは歓迎します。平凡なものは歓迎しません。 アイデアが正当な地位を得るのは、ハッカソンが終わってもなお重要であり、審査員がトラック名から推測できなかった場合のみです。
ハッカソンは審査基準、締切内、そしてデモモーメント（ビデオやライブデモの数秒間で、審査員がその動作を目撃し理解する瞬間）によって勝敗が決まります。 ハッカソンに関するすべての事実は、リンクを引用した公式ページから取得します。
手順
- ブリーフを読む。 公式ハッカソンページ、ルール、FAQ（リンクがない場合はユーザーに依頼）から、以下の情報をソースリンクとともに記録します。トラックと賞品、審査基準とその重み、必須またはスポンサー技術、参加資格と失格となるルール（チームサイズ、既存コード、地域、ライセンス）、提出要件（動画の長さ、リポジトリ、ライブデモ、レポート）、および残り時間を含む締切。 次に、ブリーフからは分からないことを最大3つの質問でユーザーに尋ねます。チームサイズとスキル、使える時間数、そしてユーザーが直接知識を持つドメインや、興味のあるトラック。 上記のすべての項目に引用値があるか、「未公開」とマークされた時点で完了です。 審査基準が公開されていない場合は、ハッカソンルーブリックで共通する4つの等しい基準（アイデアの独創性、技術的実装、潜在的な影響、デザインとプレゼンテーション）をフォールバックとして使用し、出力でその旨を明示します。
- 明白なリストを作成する。 リサーチの前に、ほとんどのチームがこのトラックと技術で提出するであろう10個のアイデアを書き出します。誰もが最初に思いつくようなアイデアです。 これらのアイデア、およびそれらの軽微なバリエーションは、ステップ5で削除されます。
- 現実の問題を見つける。 これが最も深いステップです。ここに最も労力を割いてください。 トラックとチームの直接知識が示すドメイン内で、人々が自分の言葉で問題を説明している場所にアクセスします。フォーラム、サブレディット、GitHub Issues、サポートおよびコミュニティスレッド、アプリストアのレビュー、専門家グループ、公の苦情、規制当局の報告書。 特に回避策に注目します。スプレッドシート、スクリプト、手動による二重入力、プリントアウト、グループチャット、機械の仕事をする有給アシスタント。各回避策は、人々が時間という対価をすでに支払っている問題を示しています。 それぞれの問題について、症状ではなく構造的な原因にたどり着くまで「なぜ」を繰り返します。 ノートに少なくとも10個の異なる問題があり、それぞれに特定の人物と状況、少なくとも1つの引用またはデータポイントとそのリンク、現在使用している回避策、根本原因が含まれている時点で完了です。
- フィールドをリサーチする。 このハッカソンまたはシリーズの過去の受賞者（Devpostなどのプロジェクトギャラリー）、スポンサーの最近のローンチおよび必須技術に関する表明された要望、そして今回のエディションにすでに提出された公開エントリーを読みます。 ノートに少なくとも5つの過去または現在のプロジェクトと、スポンサーの表明された優先事項がすべてリンク付きでリストされている時点で完了です。
- 生成し、厳しく選別する。 少なくとも20個のアイデアを書き出します。各アイデアはステップ3の1つの問題から構築されます。
各アイデアは次のものを明示します。人物と状況、証拠リンク、除去する根本原因、洞察、何をするか、デモモーメント、そして必須技術が解決策にどのように貢献し、それがなければ実現できないことは何か。
次に、各行に理由を1行添えて、以下の条件に該当するすべてのアイデアを削除します。
- 明白なリストまたはその軽微なバリエーションであるもの
- 特定の人物と状況を挙げられない、または証拠リンクがないもの
- 根本原因が残ったまま症状を治療するもの
- 薄いラッパーであり、必須技術やAIをフォームや検索ボックス、テンプレートに置き換えてもほとんど損失がないもの
- 誰もが最初に言うような洞察を持つもの
- 既存の製品、過去の受賞者、または現在の提出物と酷似しているもの（最も近いものを検索し記録する）
- ルールに違反するもの、または残りの時間とチームのスキルで実用的なデモモーメントに到達できないもの すべてのアイデアが理由とともに削除されるか保持され、少なくとも5つが保持された時点で完了です。保持されたアイデアが5つ未満の場合は、選別基準を緩めるのではなく、ステップ3に戻ってさらに問題を探します。
- 生存者をスコアリングする。 保持された各アイデアを、各審査基準について1～5でスコアリングし、ハッカソンの重みとスコアごとに1行の正当性を付けます。さらに、独自の3つの基準も加えます。深さ（証拠の強さと根本原因を除去する完全さ）、残り時間での構築可能性、デモの強さ。 加重審査スコアに深さを加えたものでランク付けし、同点の場合は構築可能性で順位を決めます。
- ショートリストを作成する。 トップ3について、以下を作成します。
- ピッチ：審査員が繰り返すであろう1文。
- 問題：人物、状況、リンク付きの証拠引用、現在の回避策、根本原因。
- 洞察：非自明な事実、そしてなぜ既存のツールがそれを見逃しているか。
- 近隣の類似品：見つかった最も近い既存製品またはプロジェクト、および具体的な違い。
- ターゲット：競合するトラックと賞品。
- スコア：ステップ6のスコア表。
- デモスクリプト：ビデオの最初の30秒で何が起こるか。人物の問題を示し、次にその除去を示す。
- カットライン：デモのために必ず動作しなければならないもの、およびあればよいもの。時間が足りなくなった場合に何を削るべきかチームが分かるように。
- 最もリスクの高い仮定：最も失敗しそうな技術的またはプロダクトの賭け、およびコミットする前にそれをテストする1時間以内のスパイク。
出力
ハッカソンごとに1つのファイルを docs/hackathons/<event-slug>.md に書き出し、以降の実行でその場で更新します。ブリーフとリンク、明白なリスト、証拠付きの問題ノート、フィールドリサーチ、削除理由付きの生成された全アイデア、スコア表、ショートリストを含みます。
セッションでは、ショートリストと締切を表示し、ユーザーに1つのアイデアを選ぶよう求めます。
チームがアイデアにコミットすると、審査員以外が使用する前に app-compliance スキルを通過し、showcase スキルが提出用のデモビデオとREADMEを作成します。