こんにちは、野村です。
大学の学部生で、主に情報工学を学んでいます。
先日、友人と初めてハッカソンに参加しました。
学んだことがたくさんあったので、記事にして残しておきたいと思います。ハッカソンへ参加する人に向けて再現性高く書いたので、参考にしてもらえると嬉しいです。
私のチームは「わらび餅キング」という名前で参加させていただきました。結果を言うと、予選で開催地賞を頂きましたが、決勝進出はできませんでした。
本記事では、ハッカソンの概要と作成したアプリについて説明した後で、開発に使ったツールや手順について述べ、最後に発表会について書いています。
GDGoC Japan Hackathon とは
GDGoC というのは、Google for Developers の学生向けコミュニティーの名称です。そのコミュニティーが、全国の大学生を対象として開催したのが今回のハッカソンになります。
私自身、GDGoC の存在を知らず、ハッカソンも未経験でしたが、大学の近くで開催されるということで、友人を誘って参加してみました。
作成したもの
「感性で繋がる提案アプリ」として、作品提案アプリとマッチングアプリを作成しました。
開発のきっかけ
友達と集まったときに映画を観たり、音楽を聴いたりしようとしても、全員が興味のある作品ってわからない。そんなときに、複数人の感性の情報を元にして作品を提案してくれるサービスがあったら良いな、というところから開発を始めました。
アプリの仕組み
各ユーザの感性は、 YouTube から高評価動画を取り込んだ上で、 Embedding の技術を使ってベクトルの形で取得します。
- 作品検索：ユーザの感性ベクトルに近いベクトルを持つ作品を提案します
- マッチング：感性ベクトルが近いユーザ同士をマッチングさせます
発表後、他のチームに感想を聞いたところ、大半の人が「使ってみたい」と言ってくれました。初めてのハッカソンでしたが、自分が欲しいと思っていたものを形にできたことが嬉しかったです。
次章の体験記では、アイデア出しから発表までにやったことを時系列順に紹介します。
体験記
1. キックオフ＆勉強期間
今回のハッカソンは、始めの3週間が勉強期間、ラスト1週間が開発期間でした。
勉強期間中は開発が禁止されていたため、アイデア出しや技術調査などできることを進めておきました。
1.1. はじめにチームで話すこと
はじめにチームで話し合うべきことリストです。
初日のアイデアソンの際に紹介されました。メンバーの向く方向を一緒にしておくのは結構重要なことだと感じました。
# 重要な5項目
各々の役割 ... リーダーを決める
なぜやるのか ... 参加した目的
ハッカソン後 ... 終わった後にどうしたいか
成功の定義 ... どうなったら成功か
決め方 ... チームの最終的な意思決定をどうするか
# 場合によって
使える時間（h/w）
スキル
意見の共有には Figma を用いました。
1.2. アイデア出し
アイデア出しは次の流れで進めました。
個人でブレスト → メンバーに共有 → 全員で深堀り
アイデアの共有には stitch を活用しました。
stitch とは、プロンプトからアプリの UI を作成してくれる Google のサービスです。
アイデアと一緒に UI イメージを共有することで、目指している雰囲気を伝えることができます。ぜひ使ってみてください。
議論するうえで大事だと思ったことをまとめておきます。
- 議事録を取る
- 引っかかりはその場で質問して解消する
- 否定と提案をセットにする
- 全員の意見を聞く
1.3. 機能整理
1週間という短い開発期間の中で、どの機能を実装するのか検討しました。
- 必ずやること、実装したい機能
- やらなくて良いこと、できたら実装する機能
上記の2軸を設定し、ブレスト形式で付箋にアイデアを書き出しました。その後、話し合いながら機能を整理し、最終的なリストを作成しました。
1.4. デザイン作成
実装する機能がまとまったため、それぞれの機能をどのように配置し、画面遷移をどうするのか決めました。各メンバーが stitch を使ってそれぞれの理想とするUIを作成し、持ち寄りました。
実際にやってみて、デザインの作成に全員が取り組む必要はないと感じました。デザインの得意なメンバーがいる場合にはこのステップは不要かもしれません。
ただし、アプリの雰囲気や大事にする価値観について、メンバーと意見を合わせておくことは重要だと思います。
1.5. 技術調査
調査が必要な技術をリスト化して割り振り、それぞれで調べました。
メンバーが4人だったので、次のように割り振りを行いました。
- ユーザの情報を取ってくるAPI周りについて
- 取得した情報のフィルタ処理について
- 取得したデータのベクトル化について
- データを保存するデータベースについて
2. 開発期間
私のチームでは、開発経験の有無に関わらず各々が触ってみたい技術を担当しました。それぞれがやる気を持って取り組めたため、結果的にこのような役割分担をして良かったと思います。
私は触ったことがなかった Flutter を担当してみました。
2.1. フロントエンド（Flutter）
私が担当したフロントエンドについて、どのように開発していったか紹介します。
今回の開発で初めて Flutter を使いました。そのため、主に Vibe Coding で開発をしていきました。
以下の流れで開発することで、コードをほとんど書かずに Flutter 上で動く状態を構築できました。
UIのイメージ → stitch (html) → Gemini → flutter (dart)
UIイメージの具体化から html への出力までは Google の stitch が行ってくれるため、非常に頼りになります。そこから Dart への変換や Flutter の基本的なファイル構成については、 Gemini に聞きながら進めました。
3. 発表日（予選）
東北ブロックには、参加チームが12あり、その中から1チームだけ決勝に行けるというルールでした。
UI、技術、スライド、どれもそれなりに作れたと思っていましたが、他のチームの発表を聴き、技術力の高さと伝え方の上手さに驚きました。冒頭でも書きましたが、私のチームは開催地賞をいただいたものの、決勝には届きませんでした。
他のチームのプレゼンを見ていて感じたことを挙げます。
必須
- 評価項目をプレゼンに明示している
決勝に行くために
- 使用場面が明確で審査員と学生の両方に刺さるプロダクトである
- プロダクトとプレゼンに一貫性がある
アーキテクチャ図については公式のフォーマットに倣っているところが多くありました。
決勝には行けなかったものの、他のチームの学生からアイデアの種が良いねと言ってもらえました。 Embedding の技術を使っていることにも興味を持ってもらえたようでした。
↓ 実際に発表会に行ってみて良かったことです
- 普段は会えない他の大学の学生や企業の人との繋がりができる
- 次に繋がるイベントの情報が手に入る
振り返り
1. 良かったこと
開発期間中は各自の予定が詰まっていたものの、タスクの分担、短期間での成果の確認、話し合う時間の確保をしたことで、大きな問題なく開発を進められました。振り返ってみると、全員がそれぞれの役割を持って走りきれたと思います。
- 対面で集まって開発をしたことで、議論と疑問の解消がしやすかった
- 各々のやりたいことをタスクにしたことで、それぞれが自主的に取り組みやすかった
- GCPを使った開発経験のあるメンバーが居たことで、技術的な問題が解決しやすかった
2. 改善したいこと
発表での伝え方について
- プロダクトを2つ作ったため、審査員に成果物が伝わりづらかった
- テーマに対する答えをスライドに明示していなかった
などなど ...
今後やりたいこと
機会があれば他のハッカソンにも出てみたいと思います。今回作成したアプリも継続して開発していきたいと思います。
以上です！
もし参考になったら「いいね」押してくださると嬉しいです！
ここまで読んでいただきありがとうございました。
記事内のコンテンツについて
GDGoC Japan Hackathon のロゴや広報物は、「ロゴ及び広報物使用に関するガイドライン」に基づいて、参加者として使用しております。その他のコンテンツについては「わらび餅キング」の著作物です。