私自身ハッカソンの参加経験が少なく、他社のエンジニアとチームを組むのも初めてだったため、前日まではうまく立ち回れるか緊張していました。しかし、チームメンバーのおかげで良い成果物を作ることができ、楽しい時間を過ごすことができました。
チーム内にハッカソンの参加経験があるメンバーがおり、彼が提案してくれた進め方が「生成AI時代のハッカソンはどう戦うべきか」という視点でも多くの学びがあったので、そのプロセスと知見を書き残しておこうと思います。これからハッカソンに参加予定の方の参考になれば幸いです。
- 私たちのチームでの大まかな流れ
- 1. 最初に決めたこと：チームの方針
- 2. 当日のタイムスケジュールと作業フロー
- 3. より良い成果物を作るための進め方のポイント
- 4. プロトタイプの実装について
- 5. 実装・発表する上でのポイント
- まとめ
- おわりに
私たちのチームでの大まかな流れ
私たちのチームでは、実装そのものよりも「何を作るか」に重きを置き、以下のようなステップで作業を進めました。
- チーム方針決定: 最初にチームの方向性を明確にする
- 仮説立案: 課題仮説・ソリューション仮説を徹底的に考える（ここに時間をかける）
- 高速PDCA: 早い段階でプロトタイプを作り、フィードバックをもらう
- 本実装: 感触が良ければ仮説を確定させ、本実装へ移る
- 仕上げ: 各自で分担し、プロトタイプと発表資料を完成させる
それぞれの工程について、具体的に何を行ったのか紹介します。
1. 最初に決めたこと：チームの方針
ハッカソン開始の1週間前にオンラインですり合わせを行いました。自己紹介と併せて「チームとして何を大切にするか」を決めたのですが、このおかげで当日の意思決定がスムーズになりました。
私たちは以下の優先順位で軸を決めました。
- 自分たちが「本当に欲しい」と思えるプロダクトにする（ハッカソン後も使えるレベルを目指す）
- 個人の成長を意識する（未経験の技術や役割にチャレンジする）
- 各々のこだわりを入れる
- あわよくば賞も狙う
特に「自分たちが欲しいものを作る」という軸があったおかげで、途中で迷走せずに済みました。チームによっては「賞狙い」や「技術挑戦」が最優先になる場合もあると思います。最初にメンバー全員の認識を揃えておくのはオススメです。
2. 当日のタイムスケジュールと作業フロー
実際の作業配分は以下の通りです。実装よりも仮説検証に時間を割いていました。
Day 1
- 課題仮説の検討 (2時間)：誰のどのような悩みを解決するかを議論する
- 課題検証 (20分)：アンケート作成・公開
- 結果確認・仮説精査 (2時間)：実際にどんな悩みが多いかを確認し、仮説をブラッシュアップする
- ソリューション検討 (1時間)：悩みをどう解決するかを具体化する
- プロトタイプ作成[ver.1] (1時間30分)：検証用の簡易実装
- 仮説検証 (30分)：会場の人に触ってもらい、フィードバックをもらう
- 再検討 (1時間30分)：フィードバックをもとに課題仮説を練り直す
Day 2
- 全体再検討 (1時間30分)：ペルソナ・課題・解決策の最終調整
- プロトタイプ作成[ver.2] (1時間)：修正版の実装
- 仮説検証 (30分)：再度触ってもらい反応を見る
- 本実装・資料作成 (2時間)：役割分担をして作り込む
- 最終調整 (30分)：プロトタイプや発表資料のデザイン調整
- 発表
3. より良い成果物を作るための進め方のポイント
ハッカソンを進める中で、特に大切だと感じたポイントが4つあります。
① 生成AIの時代だからこそ、アイデアで勝負
今は生成AIのおかげで、ある程度のクオリティのプロトタイプを短時間で作れます。つまり、実装力や完成度だけで差別化を図るのは難しくなっています。実際、他チームのデモも非常にクオリティが高いものばかりでした。
そのため私たちは課題仮説とソリューション仮説の検討に時間を割き、企画の精度と質を高めることにしました。この時生成AIを活用するのも有効ですが、ありきたりな案になりがちなので各メンバーの実体験などをもとに考えるのが大切だと思います。
② 課題の洗い出しは「外部の声」も使う
課題仮説を立てる際、以下の2段階でアプローチしました。
- チームメンバー自身の悩みや課題感を出し合う
- 他チーム向けにアンケートを実施し、実態を調査する
自分たちだけで考えていると視野が狭くなりがちですが、外部の声（アンケート結果）を取り入れたことで「本当に解決すべき課題」を明確にできました。
③ 会場の人に触ってもらって軌道修正する
プロトタイプを作った後、会場にいたハッカソン関係者の方に触ってもらいました。
自分たちでは「完璧だ」と思っていたのですが、実際に触ってもらうと「ペルソナが不明瞭」「何がしたいアプリかわからない」といった率直なフィードバックをいただきました。これにより、早い段階で課題に気づいて軌道修正をすることができました。誰かに触ってもらって感想をもらうことは、ハッカソンにおいても質を高める上で有効な策だなと思いました。
④ コミュニケーションを躊躇しない
「これ言っていいのかな…」と遠慮すると、良いアイデアや重要な気づきを逃してしまいます。自分では何気ない発言でも、チームにとっては「それだ！」となる場面が多々ありました。アイスブレイク等で話しやすい空気を作ることは大切だと思います。
4. プロトタイプの実装について
実装には Gemini 等の生成AIを活用していました。プロトタイプ実装の主な流れとしては、
- 会場の人に見てもらうための簡単なプロトタイプを各自で実装する
- その中で最も良かったものを採用し、チーム内の GitHub リポジトリにアップロードする
- 画面ごとに担当者を決めて、各自機能追加や修正を実施する
という形でした。私は Gemini にコードを書かせましたが、要件定義書を作成・AIに読み込ませてエージェントに実装させているメンバーもいました。イメージしたものを即座に形にできるので生成AIって便利だなと改めて実感しました。
なお、今回チームでは画像のようなプロトタイプを作りました。学習を継続させることを目標としたアプリケーションで、学習したいトピックについてAIと対話しながら理解を深めつつ、やり取りをもとに学習内容をまとめた記事を自動で作成・投稿してくれる機能を実装しています。
5. 実装・発表する上でのポイント
ターゲットを広げすぎない
生成AIを使えばあれこれ機能を追加できてしまいますが、ターゲットがブレるとプロダクトの魅力も薄れます。「誰の・何の課題を解決するのか」を絞り込む勇気が大切です。
トリッキーな機能を一つ入れてみる
実用性だけでなく、審査員やオーディエンスの印象に残る面白さも重要だと思います。私たちは「記事のプレビューを見終わったら、5秒後に勝手にその記事が投稿される」という機能を持たせたのですが、審査時にこの機能を評価していただけました。実装する際は印象に残るような機能も持たせてみてください。
発表資料をWebサイト形式で作るのもオススメ
発表形式が自由であればですが、スライドではなくLPのようなWebページ形式で作るのも他チームと差別化できるのでオススメです。生成AIを使って Vercel + Next.js で作成しました。スクロールしながら概要を説明でき、デモにもスムーズに移行できます。
まとめ
今回のハッカソンでは以下のことを学びました：
- 方針を最初に決める：迷った時の判断軸を持つ
- WhyとWhatに時間をかける：AI時代だからこそ企画の質が問われる。なぜやるのか・何を解決するのかを明確にする
- 高速でPDCAを回す：作って見せて直す。このサイクルを早く回す
- 印象に残す：トリッキーな機能やWeb形式の資料で差別化する
技術的な実装コストが下がった今、「何を作るか」を考える時間にこそ価値があるのだと実感した2日間でした。「あわよくば賞」のスタンスで進めていましたが、結果的に準グランプリをいただくことができてとても嬉しかったです。他の会社のエンジニアの皆さんと交流できたこともいい刺激になり楽しかったです。
この記事が、これからハッカソンに参加される方のヒントになれば嬉しいです。
おわりに
オープンワークでは、こうした社内ハッカソンや外部イベントへの参加を推奨する文化があります。エンジニアとして成長できる環境に興味がある方は、ぜひ採用情報をチェックしてみてください！
