攻略法

3日間タイムマネジメント戦略

タイトル：3日間タイムマネジメント戦略
詳細：DDASH Hacksの3日間（2/23〜25）の実質開発時間は約15時間。Day3 11:30のパワポ提出から逆算したDay別の行動ガイド、時間配分の黄金比率（開発45%/パワポ25%/アイデア設計15%/バッファ15%）、書類審査（約20チーム→8〜10チーム選抜）を突破するためのパワポ作成タイミング、成果物タイプ別のタイムライン、よくある失敗パターンと対策を解説。
作成者：山本新
目的：3日間の限られた時間で最大の成果を出すための時間配分と行動計画を理解すること
ターゲット：全員。特にハッカソン初参加で時間の使い方がイメージできない人

title: 3日間タイムマネジメント戦略｜DDASH Hacks 2025
description: DDASH Hacksの3日間（実質約15時間）で最大の成果を出すための時間配分と行動計画。Day3パワポ提出から逆算したスケジュール、開発45%/パワポ25%の黄金比率、成果物タイプ別タイムライン、よくある失敗パターンと対策を解説。

DDASH Hacksの運営協力をしているCraftStadiumの山本です。
本記事では、DDASH Hacksに臨むにあたって役立つ情報を共有します。
なお、本内容は教員や審査員による公式な見解、または監修を受けたものではありません。

この記事の3行まとめ

3日間は長いようで短い。「何を作るか」より「何を捨てるか」が成果を左右します
Day3のパワポ提出（11:30厳守）から逆算してスケジュールを組みましょう
開発だけに没頭せず、パワポの質に全体の25%の時間を確保するのが勝ちパターンです

まず知っておくべきこと

実質の開発時間

スケジュールを見ると「たっぷり時間がある」と感じるかもしれませんが、実際に開発に使える時間を計算してみましょう。

日程	開発可能な時間帯	実質時間
Day1（2/23）	13:00〜18:00、19:00〜20:00 （午前はオープニング＋アイデアソン）	約6時間
Day2（2/24）	09:30〜12:00、13:00〜18:00、19:00〜20:00	約8.5時間
Day3（2/25）	09:30〜11:30 （提出締切まで）	約2時間

合計：約16.5時間。ここから休憩や集中力の切れる時間を引くと、実質14〜15時間程度です。

DDASH Hacksの審査の流れ

ここが超重要です。DDASH Hacksは参加チーム数が多いため、全チームがプレゼンできるわけではありません。

Day3 11:30  パワポ提出（全チーム必須）
     ↓
11:30〜13:00  書類審査（審査員がパワポを評価）
     ↓
約20チーム → 8〜10チームに選抜
     ↓
13:00〜15:30  最終発表（選抜チームのみ・発表9分＋質疑3分）

つまり、パワポの出来が書類審査を突破できるかどうかを決めます。どれだけ素晴らしい分析やアプリを作っても、パワポで伝わらなければ審査員の目に留まりません。「開発が最優先、パワポは最後でいい」という考えは危険です。

時間配分の黄金比率

ハッカソンで成果を出しているチームに共通する時間の使い方です。

活動	比率	時間の目安
アイデア設計・データ調査	15%	約2.5時間
開発・分析作業	45%	約7時間
パワポ作成	25%	約4時間
バッファ（トラブル対応・休憩）	15%	約2時間

「パワポに4時間？多すぎない？」と思うかもしれません。でも審査基準を見てください。5項目のうち「プレゼンテーション（5点）」が独立して存在し、他の4項目もパワポの説明を通じて評価されます。実質、パワポ＝あなたのチームの成果そのものです。

Day別の行動ガイド

Day1（2/23）— 方向性を固める日

午前：アイデアソン（10:30〜12:00）

ここで焦って「すごいもの」を考えようとしないでください。大切なのは以下の3つを決めること。

誰の・どんな課題を解決するか（1文で言えるレベルまで絞る）
どのデータを使うか（具体的なデータセット名まで特定する）
成果物の形式（ダッシュボード？Webアプリ？分析レポート？）

この3つが決まれば、午後からすぐ手を動かせます。逆にここが曖昧なまま開発を始めると、Day2で方向転換する羽目になります。

午後〜夜：開発スタート（13:00〜20:00）

Day1の午後にやるべきことの優先順位です。

データの取得と中身の確認（最優先・30分以内に着手）
データの前処理・クリーニング（欠損値の処理、フォーマット統一）
基本的な集計・可視化でデータの特徴をつかむ
ここまでの結果を元に、アイデアの方向性を微調整

Day1の罠： 「環境構築に3時間かかった」はよくある失敗です。事前準備期間（2/11〜22）のうちに環境は整えておきましょう。詳しくは「事前準備チェックリスト (外部リンク)」を参照してください。

Day1の夜にやっておくと差がつくこと： パワポの骨格（タイトル・課題・解決策・データ・今後の展望）だけでもスライド5〜6枚分のアウトラインを作っておく。翌日以降、開発と並行して肉付けできます。

Day2（2/24）— 最も重要な1日

Day2は開発に集中できる唯一のフルタイムの日です。ただし、夕方からはパワポ作成を本格的に始めるのがポイント。

午前（09:30〜12:00）：開発の核心部分

メインの分析・機能開発に集中
「あったらいいな」は後回し、「なくてはならない」機能だけを作る

午後（13:00〜17:00）：開発の仕上げ＋チーム確認

15:00を目安に、一度チームで進捗を共有する
「今の状態で提出したら何点取れるか？」を審査基準5項目に照らして確認
足りない部分を優先順位をつけて対応

夕方以降（17:00〜20:00）：パワポ作成を本格スタート

ここからが勝負です。チーム内で役割を分けましょう。

開発担当：残りの実装・バグ修正を継続
パワポ担当：スライド作成に集中（1〜2名をここに充てる）

パワポに盛り込むべき内容（審査基準から逆算）：

課題設定：何が問題で、なぜデータで取り組む価値があるか
解決策：どんなアプローチで、何が独自なのか
デモ・成果物：スクリーンショットや画面キャプチャで具体的に見せる
データ活用：どのデータを、どう使ったか
実用性：誰が、どんな場面で使えるか
今後の展望：さらに発展させるならどうするか

Day2の罠： 「もう少しだけ機能を追加したい」という誘惑。17:00の時点で動いていないものは、Day3で完成する可能性は低いです。それよりパワポで「今あるもの」を最大限魅力的に伝える方が、審査では有利です。

Day3（2/25）— 仕上げと提出の日

Day3の朝はたった2時間しかありません。新しいことを始めるのではなく、磨き上げに全力を注ぎます。

09:30〜10:30：最終調整（開発＋パワポ）

バグ修正、データの最終確認
デモのスクリーンショットを最新版に差し替え
パワポの文言・レイアウト最終調整

10:30〜11:15：提出準備

パワポの最終版をチーム全員で確認（誤字脱字、スライド順序）
ファイル名・形式の確認
提出フォームの動作確認

11:15〜11:30：提出（バッファ込み）

11:30厳守です。ギリギリは事故の元
15分前の11:15には提出を完了させましょう
提出後は修正できないので、最終確認を怠らない

11:30〜13:00：書類審査中（待機時間）

この時間は審査員がパワポを評価しています
選抜された場合に備えて、発表の練習をしておくのがおすすめ
発表時間は9分＋質疑3分。パワポの内容を口頭で説明する練習をチームでやりましょう
昼食もこの時間に

13:00〜：選抜チームは最終発表

書類審査を通過した8〜10チームが発表
発表資料は提出したパワポと同じでも、別途作成してもOK
9分間で課題→解決策→デモ→今後の展望を伝えましょう

成果物タイプ別のタイムライン

チームの成果物タイプによって、時間の使い方が少し変わります。

分析レポート・ダッシュボード型

Day1午後〜Day2午前をデータ分析に集中し、Day2午後からパワポとダッシュボードの見た目を整える。「この分析で何がわかったか」のストーリー構成に時間をかけるのが勝負どころ。分析の深さを伝えるには、パワポのグラフや図の見せ方が命です。

アプリ開発型（Web/モバイル/ゲーム等）

Day1でMVP（最低限動くもの）の範囲を決め、Day2午前中にMVPを完成させる。Day2午後は追加機能ではなく、デモの安定性とパワポに振る。動かないデモの印象は最悪なので、安定して動く範囲に絞りましょう。

AI活用型

モデルの学習に時間がかかるため、Day1のうちに学習を回し始める。Day2はモデルの結果を元にアプリ・ダッシュボードに組み込む。AIの精度よりも「AIで何を解決したか」のストーリーが審査で重視されます。

よくある失敗パターンと対策

失敗パターン	対策
アイデアが決まらずDay1が終わる	昼食後の13:00までに必ず決める。完璧を求めない
機能を盛り込みすぎる	「パワポ6〜8枚で説明できる量」に収まるか常に確認
全員が同じ作業をしている	役割分担を明確に（開発/データ分析/パワポ作成/買い出しも重要です。）
Day3朝に新機能を追加しようとする	Day3は「磨く日」。新しいことは始めない
パワポが間に合わない	Day2の17:00には必ず着手。開発と並行で進める
パワポが開発メモみたいになる	審査員は専門外かもしれない。「初見の人に伝わるか」を基準に