即席チームで優秀賞を取ったので、その方法を教える！！
即席チームで初めましての状態から約1週間。
サポーターズ主催のオンラインハッカソン（2日間開催）で、優秀賞を獲得することができました。
振り返ってみると、
これは勝因だったな
と思える行動がいくつかありました。
この記事では、
- 即席チームで何を意識すればいいかわからない人
- ハッカソンで結果を出したい学生エンジニア
に向けて、再現性のある形でその方法を共有します。
ハッカソンの概要
- 形式：オンライン開催
- 主催：サポーターズ
- 開催日：12月13日・14日（2日間）
- チーム人数：4名
- チーム編成：事前マッチング（1週間前にランダム決定）
全員ある程度スキルのあるメンバーでしたが、
全員初対面の即席チームでした。
先に結論：勝因だったこと
先に結論を書きます。
勝因はこの5つでした。
- 初日に「勝つための共通認識」を作った
- 審査員視点から逆算して戦略を立てた
- ミーティングを最小限にし、非同期で進めた
- 役割分担を明確にして自律的に動いた
- 期限から逆算した技術選定をした
初日の顔合わせでやったこと（ここが一番重要）
約1時間のGoogle Meet
初日は約1時間、Google Meetで顔を合わせました。
やったことはシンプルで、
- 趣味の共有
- 雑談
- 相互理解
いわゆる「アイスブレイク」です。
一見するとハッカソンでは無駄に見える時間ですが、
これは本当にやってよかったと感じています。
後半で意見を言いやすくなり、
指摘や修正も心理的コストなくできました。
ハッカソンに参加する目的を明確化
初日に必ずやったことがこれです。
今回のハッカソンで何を目指すか
結果、全員の目標が
「優勝を目指す」
で一致しました。
- 学習目的なのか
- 完成度重視なのか
- 受賞狙いなのか
ここがズレたまま進むと、後で確実に破綻します。
アイデア出し & 大まかな技術スタック決定
- アイデアを複数出す
- 実現可能性を見る
- 大まかな技術スタックを決める
ただし、ここでやりすぎた反省点もありました。
やらなくてもよかった／改善できた点
技術選定に議論だけで時間を使いすぎた
誰も詳しくない技術について、
- 「これ良さそう」
- 「いや、こっちの方が…」
と議論だけで時間を消費していました。
結果的に、
実際にプロトタイプを作ってから一気に話が進んだ
という経験をしました。
学び
- 議論だけで決まらないなら
👉 早めに実装する - ハッカソンでは
👉 コードを書くのが最強の意思決定
審査員視点から逆算した戦略
審査員は「大学生」
今回の審査員はサポーターズの大学生でした。
そこで、
- アプリのターゲットも大学生
- 「学生が共感できる課題」に寄せる
という方針を最初から決めました。
プレゼンは「記憶に残る」ことを最優先
プレゼン時間は2分間と短め。
技術の深い説明はほぼ不可能です。
そこで重視したのは、
- インパクト
- 記憶に残ること
具体的にやったこと
- 最初から最後までネタ画像を多用
- Zoomの背景を他チームと明らかに違うものに設定
- とにかく「覚えてもらう」ことを意識
チーム名も戦略の一部
地味に効いたと思っているのがチーム名です。
- エンジニア受けする
- ネタ的
- 学生エンジニアに一瞬で伝わる
という方針で決めました。
ミーティングは最小限に
ミーティング頻度
- 2〜3日に1回だけ
- それ以外はテキストコミュニケーション
使用ツールと運用
Notionを使って、
- 議事録管理
- タスク分担
- 役割の可視化
を行いました。
誰が何をしているか一目で分かるため、
ミーティング時間の削減につながりました。
役割分担は「明確かつ固定」
- 技術力が高いメンバーが中心となって役割を決定
- 事前に担当を明確化
- 途中で役割がブレることはなし
結果として、
- 各自が自分の作業に集中
- 「これ誰がやる？」が発生しない
即席チームでは特に重要だと感じました。
技術選定・デプロイ方針
1週間という制約を最優先
- デプロイが簡単
- 継続的にデプロイできる
- ハマりにくい
これらを重視し、Next.jsを採用しました。
新しい技術よりも
確実に動くことを優先した判断です。
振り返って思うこと
ハッカソン前は、
即席チームは不利
と思っていました。
でも実際は、
- 目的が揃っていて
- 進め方が設計されていれば
即席チームでも十分勝てると感じました。
まとめ
次にハッカソンに出るときは、ぜひ
- 初日に目的を揃える
- 審査員視点で逆算する
- 議論で詰まったら実装する
を意識してみてください。
この記事が、
次のハッカソンで悩んでいる人の助けになれば嬉しいです。