こんにちは！ひさふるです！
先日、Tokyo Flutter Hackathonというハッカソンに参加してきました。
最終的に、チーム"アジャイルビギナーズ"として1位を獲得することが出来ました！
(出場メンバーは私のほか、@k_ohmikawa、@8mitsuboy、@oudon0216で参加してきました。)
今回は、このハッカソンをどのような戦略で戦い、どうやって1位を獲得したのかをお話したいと想います。
ハッカソンの内容とテーマ
最初に、簡単にハッカソンの概要について説明します。
今回参加したTokyo Flutter HackathonはFlutterを用いたハッカソンです。
と言っても厳しいルールは無く、概ね以下のようなルールとなっています。
- Flutterを用いる以外は特に技術的な制限は無し
- 審査は資料提出 + プレゼン + 実機審査
- 今回のテーマは"みゃく" (当日発表)
とにかくFlutterを用い、テーマに関連したアプリケーションを作成すれば良く、アプリのプラットフォームや方向性は問われません。
そのため、アプリの配布形態から実装した内容まで、非常にバラエティに富んだ大会となりました。
大切な前提
今回は、ハッカソンで勝つための戦略を主に紹介していきますが、勝つことだけがハッカソンでは無いと思っています。(1位や入賞だけに価値があるわけではないということは、運営側からも言及されていました。)
どのようなアプリであってもそれぞれに価値があると思いますし、ハッカソンとして短期間でアプリを作り上げる体験自体に価値があると思っています。
あくまで我々が取った1つの戦略であり、これ以外の開発方法を否定する意図はありません。
勝つための戦略①：アイデア出しを妥協しない
昨今は生成AIによるコーディングが普及したため、今までよりもコーディングにかかる時間を削減できるようになりました。
機能だけならAIに指示を出すだけでも実装が可能になった現在では、ハッカソンはアイデアソンとしての側面も強くなりつつあります。
誰もが強力な実装力を手にできる今、他人と差をつけるためには妥協せずアイデアを考えることが何よりも重要となります。
コーディングでは差がつかない。アイデアを妥協せず差をつけよう！
ハッカソンのアイデアで重要な3+3+1要素
では問題は、どのようなアイデアを出すかです。
ハッカソンで勝つためには、当たり前ですがハッカソンの評価基準や審査員の方が求めるものをよく理解しておく必要があります。
その上で、多くのハッカソンで共通して評価される要素が次の7要素だと思います。
- アプリの核となる3要素
- 解決したい課題
- 想い
- テーマ一致度
- アイデアの良さに関わる3要素
- 独自性
- 将来性
- マネタイズ
- 高度な技術の活用
それぞれの要素を順に説明します。
アプリの核となる3要素
まず、解決したい課題と想い、テーマ一致度はそのアプリの方向性と本質的な価値を決定づける最も重要な要因だと考えています。
この3要素はそれぞれが独立しているわけではなく、相互に関連していることも考慮しなくてはなりません。
具体的には、
テーマから連想される課題を設定 ⇒ なぜその課題を解決したいか、という想いを考える
という流れで課題と想いに一貫したテーマ性を持たせることが大切で、この考えを核として持つことはハッカソンの定石であるとも言えるでしょう。
〜 アプリの核となる3要素 〜
テーマから連想される課題を設定 ⇒ なぜその課題を解決したいかという想いを考えることで、課題と想いに一貫したテーマ性を与える
アイデアの良さに関わる3要素
上記3つがアプリの核となる要素なのに対し、将来性、マネタイズ、独自性はアイデアの良さに関わる要素であると言えるでしょう。
まずは独自性ですが、この3要素内では最重要です。
ハッカソンはビジネス価値も評価されますが、ピッチコンテストでは無いので、本当にお金を儲けられるかよりも既存のアプリケーションには無い発想が盛り込まれているかの方が評価対象になることが多いと感じています。
仮に売り物として欠陥を抱えているプロダクトだとしても、今までに無いアイデアで既存プロダクトと差別化できていることを優先すべきです。
その一方で、本当にお金を儲けられるかは重要では無いものの、お金を出しても良いと思えるプロダクトになっているかは重要な観点の1つです。ここでは、この観点をマネタイズと表現しています。
アプリの抱えている欠陥には一旦目を瞑り、アイデアの可能性に最大限価値を発揮できたとして、それに自分はお金を払う気になるか、は一度考えるべきでしょう。
また、そのお金を払っても良いと思える理想状態を、いかに審査員にもイメージさせるかがプレゼンのカギになります。
そこに加えて、将来性があるとより良くなります。ここでの将来性は、ハッカソンなので実現しきれなかったけど、ビジネス観点でも活用事例としても発展性があるよと言えることだと思います。
ここで、将来性がテーマ一致度と想いに繋がると最高です。将来性はプレゼンの最後に語ることが多いので、そこでもう一度テーマと自分たちの想いに絡めて今後の発展を語れると、一貫したテーマを持ちながらもプロダクトとして未来を想起させられます。
〜 アイデアの良さに関わる3要素 〜
・独自性：プロダクトの欠点より新規性を優先
・マネタイズ：アイデアの理想形において、お金を払っても良いと思えるか
・将来性："テーマ"と"想い"に関連付けて、アプリの可能性を語る
高度な技術の活用
これはもう説明不要ですが、皆さんが普段の学業や業務で培ったスキルを見せつけてください。
1つだけコツがあるとすれば、引き出しを多く持っておくことでしょうか。
1つの領域だけに特化させるのではなく、どのようなテーマやアイデアに決まっても対応できるような、柔軟で幅広い知識の方が役立ちそうですよね。
私たちの場合の具体的
私たちは、"動画をアップロードするだけで自動的に説明画像付きの手順書を生成してくれるアプリ"のマニュマニュを作成しました。 (名前の読みづらさは...まあご愛嬌ということで...)
これを先程の要素に当てはめて整理すると、以下のようになります。
- アプリの核となる3要素
- テーマ一致度：「みゃく」⇒ 脈々と過去から未来へ途切れることなく流れる継承
- 解決したい課題：熟練の技術や現場の「暗黙知」は人が辞めると途絶えてしまう
- 想い：業務を脈々と次世代に伝えたい
とりあえず、全部埋まりましたね。次に、具体的なアプリの機能は以下のようになっています。
これを"アイデアの良さに関わる3要素"として整理すると...
- アイデアの良さに関わる3要素
- 独自性：説明画像付きのマニュアルを動画アップロードだけで生成できる
- マネタイズ：ChatGPT等では出来ない高クオリティのマニュアル自動生成は需要あり
- 将来性：PC作業から工場・厨房などの実務作業まで幅広い応用が可能
こうなりますね。これに加えて高度な技術の活用を考えると、
- 高度な技術の活用：裏ではGemini3やNano Bananaなど最新のモデルをフル活用
という観点もあり、全ての観点が網羅出来ていることがわかります。
勝つための戦略②：AIフル活用で開発を効率化
実際の開発では、言うまでもなくAIの活用がカギとなります。
私たちの取った戦略
最初に私たちの開発手法をご紹介します。
今回は、KIROを活用したSpec(仕様)駆動開発をベースに、そこにVibeコーディングを組み合わせました。
第一段階：Spec駆動開発
今回採用したKiroは、Spec(仕様)駆動開発を行うためにAWSが開発したIDEです。
仕様駆動開発は最初に仕様を固め、それを正としてAIにコーディングをさせるという手法です。
AIを用いた開発においてはプロジェクトの背景情報を整理してAIに与えることが重要であり、またVibeコーディングでは悪く言えば行き当たりばったりな開発になることが多いため、仕様を固めて安定した開発ができる仕様駆動開発はAIと相性が良く一定の評価を得ています。
(一方で仕様を最初に決めるのは当たり前だからそんなに特別な開発手法じゃないだろって意見もちょくちょく見かけます。それはマジでそう。)
そして、ハッカソンにおいては、
- 最初に仕様をガッチリと決めるそれを"正"として開発するので、その後の認識にズレが起きにくい
という仕様駆動開発の強みが大きく働きます。
特に、今回のチームは同じ会社で働く同期で構成されているものの、担当する案件はバラバラなので、当然技術スタックや普段の開発手法もバラバラでした。
そのギャップを埋めるため、最初に仕様駆動開発で認識合わせと最低限の開発のベースを一気に組み立てることで、そのあとのズレを最小限に抑え開発の効率化を図りました。
第二段階：並列でVibeコーディング
第一段階の仕様駆動開発で最低限動作するベース(MVP)が完成すると、そこからはUIの修正や機能の追加、プロンプトの調整などを並列で行いました。
このときは各々が使い慣れたAIコーディングツール(Claude Code、OpenAI Codex、Cursorなど)を使ってVibeコーディング的に開発を行うことが出来たので、開発速度を落とさずに進めることが出来ました。
無理に同じAIコーディングツールを使おうとせず、KIROで基盤を整えた後に普段から使い慣れたコーディングツールを使えたのも、この開発方法の良いところだったと感じています。
今回の開発方針の評価
全体的な感想から述べると、AI駆動開発による恩恵は非常に大きいものの、まだ我々も仕様駆動開発等に不慣れなところもあり問題点も目立ちました。
良い点としては上記の通り、仕様駆動開発⇒Vibeコーディングと遷移し、無理に開発スタイルやツールを共通化しないことでそれぞれが最大限のポテンシャルを発揮出来たことです。
反省点としては、以下のような点が挙げられます。
- 仕様駆動開発での待ち時間が長い
- 仕様を決め、KIROが開発してる間は基本その様子をずっと見ていましたが、実行だけで2時間ほどかかったため、途中から片手間で発表資料作成などをしていました。今回は上手くいったから良かったものの、2時間待って出来たものが役に立たないものだとハッカソンでは致命的です。検証可能・動作可能な適度な大きさにタスクを分解しこまめに実装し、途中途中で確認することが重要だと感じました。
- 仕様の策定でミスがあった
- KIROはユーザーからのプロンプトをもとに仕様の策定までやってくれますが、ここで若干のミスがあったため躓きました。具体的には各ページの仕様は網羅的に記載されていたものの、特定のアクションを取ったときのページ間の遷移が未定義で、最後まで実装されず仕舞いといったことがありました。
このように、特に仕様駆動開発において仕様駆動開発自体が抱える問題や、我々の仕様駆動開発に対する理解度の低さから発生する問題も多く、まだまだ勉強・改善が必要だと感じています。
最終的に出来たものと、AIプロダクトに対する想い
今回の私が勝手に抱えていた裏テーマとして、人間の入力は最小限に、AIのアウトプットの価値は最大限にというものがあります。
まず作成したプロダクトという文脈では、インプットは動画のみという限られた入力に対して実用的なマニュアルを生成することを心がけました。
現在のAIプロダクトはユーザーの言語能力(=プロンプト能力)にアウトプットの質が左右されることも多く、そのようなプロンプトはChatGPTとの差別化も困難になってきます。
人間の入力は最小限に、AIのアウトプットの価値は最大限にを達成できるプロダクトこそが、ChatGPTとは違う独自の強みを持つプロダクトになってくると思っています。
また、AI駆動開発の文脈においては、ハッカソンという限られた時間の中で人間が入力する情報は最小限にしつつ、生成されるコードの量や質を最大化することも意識しました。
まだまだ仕様駆動開発の方法など、私の経験やスキルが足りなかった部分も多数ありますが、今回1位を取得できたことはこの意識付けがある程度有効に働いたことの証明だと感じています。
おわりに
今回は先日参加したハッカソンで考えていたことを言語化して、私自身振り返ってみました。
読み返すと至極当たり前のことのようにも思えますが、ハッカソンは落ち着いて振り返っている余裕なんてなかったので、自分の中で反省する良い機会となりました。
皆様によって有用な記事となったかわかりませんが、これを読んで少しでもハッカソンに挑戦してみたい！と思っていただけたなら幸いです。