入賞するハッカソンデモ動画の作り方

審査を突破するハッカソンデモ動画の作り方。2分間の構成、リスクのある工程の事前収録、どこでも再生できる書き出し設定を解説します。

入賞するハッカソンデモ動画の作り方

睡眠4時間で48時間かけて作り上げたプロジェクトが、たった2分の動画で評価されます。この動画は形式的なものではありません。オンラインハッカソンの多くでは、審査員が実際に見るのはこの動画だけです。提出物の半分は音声のない不安定な画面キャプチャなので、きちんとした録画をするだけでコードを見られる前から一歩リードできます。

締め切りまで1時間しかなくても、プロジェクトの価値をきちんと伝えられるデモ動画の作り方を紹介します。

1. まず提出ルールを読む

録画を始める前に、ルールページで必須要件を確認しましょう。ほとんどのハッカソンでは次の点が指定されています。

  • 最大の長さ — 通常2〜3分で、審査員は本当に制限時間で視聴をやめます
  • 形式 — MP4はどこでも受け付けられます。ファイルではなくYouTubeやVimeoのリンクを求めるプラットフォームもあります
  • 公開設定 — ログインが必要な非公開リンクは失格の理由になります
  • 内容の要件 — スライドではなく実際に動作するアプリを見せることを求めるイベントもあります

最初のテイクの前に、書き出し設定をルールに合わせておきましょう。アップロード容量の上限に引っかかって午前3時に書き出し直すのは、最後の1時間の最悪の使い方です。

2. 2分の台本を書く

2分はおよそ300語分です。即興で話す余裕はないので、流れを先に書き出しましょう。

  • 0:00〜0:15 — 課題。 初対面の人にも伝わる一文。チーム紹介も「発表できて嬉しいです」も不要です。
  • 0:15〜0:30 — 解決策。 何を作り、誰のためのものか。
  • 0:30〜1:30 — デモ。 実際のプロダクトが実際に動く様子。
  • 1:30〜1:50 — 内部構造。 技術的に面白い判断を1つだけ簡潔に。
  • 1:50〜2:00 — 次のステップ。 今後の方向性を一言で。

最もよくある失敗は、背景説明に45秒使ってデモを駆け足で終わらせることです。審査されるのは作ったものです。早く画面を見せましょう。

3. 録画前にデモの状態を整える

ログインフォームの入力やコールドスタートの待ち時間ほど、テイクを無駄にするものはありません。まず舞台を整えましょう。

  • ログインを済ませ、最初のカットに必要な状態にアプリを合わせておく
  • 現実的なデータを用意する — 「test test test」やasdf@asdf.comは未完成な印象を与えます
  • 関係のないタブをすべて閉じ、通知を片付けて集中モードをオンにする
  • ブラウザとエディタのフォントサイズを大きくする — 審査員はノートPCやスマホで見るかもしれません
  • 遅いエンドポイントは事前に温めて、最初のリクエストがコールドスタートにならないようにする

Dockや壁紙、他のモニターが映り込まないよう、全画面ではなくウィンドウキャプチャを使いましょう。

4. 一発撮りではなく分割して録画する

46時間目に完璧な通し撮りができるというのは幻想です。台本のセクションごとに短く分けて録画し、あとでつなぎましょう。失敗しても2分ではなく30秒を撮り直すだけで済みます。

分割録画は実際の待ち時間を飛ばすのにも役立ちます。「送信」のクリックまで録画して止め、処理が終わったら結果画面から再開します。90秒の処理待ちをまるごとカットすれば、デモは不誠実ではなくテンポよく見えます。

レート制限のあるAPIや不安定なデプロイなど、本当に不安定な工程は動いているうちに早めに録画し、そのクリップを保管しておきましょう。

5. 自分でナレーションを入れる

マイク音声を録音し、デモに合わせて話しましょう。審査員はBGMだけの無音キャプチャよりも、ナレーション付きのデモを一貫して高く評価します。クリックごとの意図を追えるからです。

ナレーションを活かすコツ:

  • 会場の床ではなく、できるだけ静かな部屋で録音する
  • 自然だと感じるより少しゆっくり話す — 興奮していて寝不足です
  • クリックする前に、これから何をするかを口に出す
  • 母語でない言語なら、台本を書いて読み上げてまったく問題ありません

徹夜で声が枯れていても、とにかく録音しましょう。不完全なナレーションでも、ナレーションなしよりずっと良いです。

6. スタイルではなく分かりやすさのために編集する

後処理は審査員の役に立つものだけに絞りましょう。

  • 各セクションの前後の無音をトリミングする
  • ボタン、入力欄、ログ出力などの小さなUIを小さい画面でも読めるようにズームする
  • セクション名や使用技術を示すテキストオーバーレイ
  • イントロとアウトロだけウェブカメラのPIPを使い、プロダクトを隠さずに顔を見せる
  • プラットフォームが対応していれば字幕を追加 — 審査員は最初は音を出さずに見ることが多いです

アニメーションのイントロ、街のドローン映像、ナレーションと競合するBGMは省きましょう。どれも点数にはなりません。

7. 書き出しとアップロードの確認

1080p、30FPS、H.264のMP4で書き出しましょう。この組み合わせなら、どの審査プラットフォームやブラウザでも変換トラブルなく再生できます。

完了と言う前に:

  • 音声を出して、最初から最後まで通しで1回見返す
  • 認証情報、非公開トークン、個人的なメッセージが画面に映っていないか確認する
  • ローカルではなく提出ページからアップロードして再生できるか確認する
  • リンクが公開されていて、アカウントなしで見られるか検証する

提出チェックリスト

  • 長さがルールに数秒の余裕をもって収まっている
  • 最初の15秒で課題を提示している
  • 尺の半分以上で実際のプロダクトが映っている
  • デモのデータが現実的に見える
  • ナレーションを録音済みで聞き取りやすい
  • 重要な操作に小さい画面向けのズームを適用
  • 秘密情報や通知が映っていない
  • 1080p MP4で書き出し、アップロード後に確認済み

提出しよう

ハッカソンで勝つチームが、最も多くコードを書いたチームであることはほとんどありません。90秒でアイデアを明確に伝えられるデモを作ったチームが勝ちます。台本を書き、分割して録画し、自分で説明し、一度見返せるだけの余裕をもって書き出しましょう。

そのあとは、少し眠ってください。