ハッカソンに全力で挑んで見えた、AI駆動でチーム開発を高速化した先の世界
はじめに
先日、次世代オートモーティブ生成AIハッカソン に参加させていただきました。
その結果、予選を勝ち抜き本戦に出場し、準優勝 させていただきました。
このハッカソンは3日間での開催でしたが、初日は夜だけ、最終日の開発は昼までという制約があり、実質 1.5日間程度 で自分のアイデアを形にしてプロダクトまで落とし込む必要がありました。
この短期間で、AIを使って最大限開発の生産性を上げつつ、実際に動くプロダクトとして形にするまでに、様々な気づきがありました。
- AI駆動開発で開発を高速化するにはどうしたらいいか？
- どのような問題が発生していくか？
- アイデアのピボットはどのタイミングで行うべきか？
- 最高速度で開発が進む中で、プレゼン担当とどうやって同期を取るか？
- コミュニケーションの仕方やコツは？
こうした課題に直面する中で、AI駆動開発で開発を高速化した後の未来 が少し見えた気がしています。
この記事では、開発を高速化される中、チームとしてプロダクトを売り出す時に開発メンバーはどのように振る舞うべきか、また開発時にどんな落とし穴があるのかをお伝えします。
同時に 「開発を高速化する」からこその弊害やマイナスの部分 もあると感じました。ハッカソンに全力で挑んだからこそ見えた、AI駆動でチーム開発を高速化した先の世界についてお話しします。
背景：プロダクトとチーム構成
作ったプロダクト
チーム名は 「ペーパードライバーズ」、プロダクト名は 「DriBuddy」 です。
ペーパードライバーが1〜2ヶ月で運転できるようになることを目的としたアプリを開発しました。
主な機能
- 音声対話アシスト：車に乗ると、エンジンのかけ方やガソリンの入れ方などを音声で教えてくれる
- マニュアル動画の再生：操作方法を動画で確認できる
- 練習ルート提案：苦手な操作（交差点、右折、駐車など）を選ぶと、近くで練習できる最適なルートを提案してくれる
チーム構成と役割
今回のハッカソンは、大きく 「ビジネスチーム」 と 「開発チーム」 に分かれていました。
僕自身はビジネスチームの一員としてアイデアを出しつつ、メインは 開発チーム として動きました。また開発チームにはもう1人エンジニアがいる状態です。
僕自身は、大きく 3つの役割 がありました。
- アイデア・企画ポジション：アイデア出し、どのような機能を作るか、プレゼンの構成や見せ方へのフィードバック
- PM的ポジション：開発のマネジメント、レビュー、技術検証、発表時の技術的質問への回答
- 開発者としてのポジション：フロントエンドの開発、バックエンドのRAG構築、諸々の関連バグの修正
この3つの役割を担いながら、AI駆動開発で感じたことをお話しします。
チーム開発での気づき
コンフリクトを発生させないように気をつける
一人一人が高速で動くので、コンフリクトを発生させないように気をつける ことが非常に重要です。
AI駆動開発では、従来の開発と比べて圧倒的にコードを書くスピードが上がります。そのため、複数人が同時に作業していると、あっという間に大量の変更が発生し、気づいたら変更分が全てコンフリクトして それまでの作業が全て無駄になった ということが起こりえます。
これを避けるために意識したのは以下のポイントです
- 機能単位でファイルを完全に分離する：同じファイルを複数人で触らないように、機能ごとにファイルを分けておく
- 随時、小さい段階でマージする：大きな変更をためこまず、こまめにマージすることでコンフリクトのリスクを減らす
- マージ後のブランチから新しいブランチを切る：最新の状態から作業を始めることで、変更差分を最小限に抑える
チーム開発であれば当たり前の動きではありますが、「ハッカソンだから」と放置せず、これらを徹底できるかどうかが、開発スピードを落とさないために重要だと感じました。
Git操作のミスに気をつける
Git の管理は、正しく行えるようにすることが重要です。
実際に起きた問題として、mainブランチから正しくブランチが切れておらず、直前のリファクタリングが全て打ち消されていた ということがありました。せっかく書いたコードが消えてしまうのは、精神的にもダメージが大きいです。
チーム開発に馴染みがない人は、Git操作に違和感があったり、うまくPushできないことがあります。特にハッカソンのような短期間での開発では、Gitのトラブルが致命的な時間ロスにつながります。
気をつけるべきポイント
- ブランチを切る前に、mainブランチが最新かどうか確認する
- 困ったらすぐにチームメンバーに相談する
作業のボトルネックをどれだけ早く解消できるか
Git 操作などで詰まっている人がいたら、その人が自分で調べるよりも、わかる人が教えた方が早い です。
もちろん勉強やスキルアップの観点では自分で調べて対応する方が良いのですが、開発スピードを最優先するなら、ボトルネックを早く解消することが大事です。
そのため、今の自分の作業を中断したとしても、チーム全体の生産性を高めるために、ボトルネックを解消できるようにフォローした方がいいです。
この時には、やはり 対面の方がコミュニケーションもしやすく 、かつ相手の顔色を見ながら説明できるので、開発スピードを最優先したいなら 対面や出社が重要 だと改めて感じました。これはハッカソンに限らず、普段の仕事でも同じことが言えると思います。
技術検証は同時並行で行う
開発する機能単位で分類できると、それぞれの編集対象ファイルを正しく切り出していれば、同時並行で作業したり実装しても問題ありません。
AI駆動開発の強みは、議論しながら同時に検証ができる ことです。「これってできるのかな？」という疑問が出たら、ミーティング中にClaude Codeを走らせて、別の議題で話している間に実装してみて、完了したら戻ってきて結果を共有する、という流れが可能になります。
従来であれば「一旦持ち帰って検証します」となっていたものが、その場で結論を出せるようになるので、技術検証のスピード感 がチーム全体の意思決定速度に直結します。
また、Claude Codeに実装させている間に、他のメンバーに技術や実装のコツを教えることもできます。開発は常に並行して進め続ける、という体制を作っておくと良いと思います。
実践のコツ：
- 検証用の作業ディレクトリを別で用意しておく（Git Worktreeが便利）
- 「とりあえず動くかどうか」だけを確認する最小限のコードで試す
- 結果はすぐにチームに共有して、次のアクションを決める
チームの意思決定について
全員が納得を持って作業できるか
ハッカソンは、プロダクトだけでなくプレゼンも含めて、初めて評価される ものです。
どれだけ素晴らしいプロダクトを作っても、プレゼンで製品の良さが伝わらなければ評価されません。逆に、プロダクトが多少荒削りでも、プレゼンで魅力を伝えられれば高評価につながることもあります。
だからこそ、開発チームとビジネスチームが 同じゴールを共有して、納得感を持って作業できているか が重要です。「自分はこう思うけど...」というモヤモヤを抱えたまま作業を進めると、最後に齟齬が生じます。
一方で「必ず誰かが決めないといけない」ことを理解する
しかし短期間のハッカソンでは、全員が100%納得する結論を出す時間はありません。誰かが決断を下し、チームがそれに従う という場面が必ず出てきます。
何かが決まった後に、それに対して何か思うところがあったとしても、一度決まったことには全力で取り組み続ける のが重要です。
意見の相違は必ず出ます。 「意見が違うのは当然」と理解した上で、徹底的に議論し、最終的に決まったことには後から文句を言わない。この姿勢がチームの結束を保つのかな？と思います。
また、意見を言うタイミングも重要です。決定前なら積極的に意見を出すべきですが、決定後は実行にフォーカスすることが大切です。ただし、実行した上でのフィードバックは常に出すべきです。「やってみたらこうだった」という情報は、次の意思決定に活かせます。
各自が役割を全うする
役割分担を明確にすることで、各自が自分の責任範囲に集中できます。曖昧なまま進めると、「誰がやるの？」「これは自分の仕事？」という無駄なコミュニケーションコストが発生します。
ここで重要なのは、「自分もチームの一員だ」 と全員が感じられているかどうかです。役割が決まっていても、「自分は言われたことをやるだけ」という受け身の姿勢だと、チームとしての一体感が生まれません。
各自が自分の役割に責任を持ちつつ、チーム全体の成功のために貢献する意識が大切です。
遠慮ではなく、配慮を
言うべき時は言う、でも 相手への敬意や尊重は忘れない 。
ここで、うまく伝えられるかが大事だと再認識しました。
こいつに言ってもわからない...ではなく、「相手の目線に合わせて話す」ことが重要です。
真剣になればなるほど、感情的になり、ストレートに伝えてしまう時もあります。ただ、この「配慮を忘れない」という前提を持っていれば、相手に合わせた伝え方ができて、より建設的な議論ができるようになると思います。
このちょっとした意識が、チームの雰囲気を大きく変えると感じました。
間に入れる人の存在が大事
バチバチした時でも「まあまあ」と間に入れる人がいたり、互いのコミュニケーションの橋渡しができる人が必要です。
逆にこの存在がないと、「あいつの言ってることはわからない」「なぜ的外れなこと言ってる？」みたいな話になり、そのままチームが崩壊していく可能性があります。
「俺はこう思う」「私はこう思う」だけではなく、相手がなぜそう思ったのか？ を拾った上で、自分の感情だけではなく、チーム全体から見てどうか？お客さんへの価値提供から見てどうか？という客観的な視点で判断したり伝えられると、より円滑なコミュニケーションができるのではないかと思います。
専門用語ではなく、チーム全員が理解できる言葉で会話することも重要です。
開発の進め方
優先順位を明確にして、積極的に機能を切り捨てる
全てをやり切りたいけど、ハッカソンでは時間の制約があります。
そのため 積極的に機能を切り捨てる 決断が必要です。
AI駆動開発では「これもできそう」「あれも追加できそう」とアイデアが膨らみがちです。しかし、時間は有限です。「あったら良いな」ではなく「これがないとダメ」 という機能に絞り込む勇気が必要だと改めて感じました。
優先順位の決め方：
- デモで見せる時に必須かどうか
- 審査員や観客に「おっ」と思わせるポイントになるか（今回のハッカソンでは「Wow」という驚きがテーマでした）
- 実装の難易度と時間のバランス
「やらないこと」を決めるのは、かなり重要な意思決定なので、意識できるといいと思います。
また、ここで迅速に決断することで開発が効率化され、余った時間で追加機能を開発できたりもします。
フロントエンドを先に作成する
ハッカソンでは 見た目が動いている ことが非常に重要です。バックエンドのロジックがどれだけ優れていても、デモで見せられなければ伝わりません。
そのため、まずはフロントエンドを先に作成して、全員の認識を一致させる「動くモックアプリ」 を早めに作ることをおすすめします。バックエンドはモックデータで仮実装しておき、後から本実装に差し替える形が効率的です。
理想は、Figma make のようなツールでざっくりとした機能や見た目を事前に共有しておくことです。
これにより
- 事前にゴールを明確化できる
- UIの部分に関してチームで認識を合わせられる
- 「思ってたのと違う」という手戻りを防げる
ここがブレてると、かなり手戻りが起こります。 最初の30分でUIのイメージを合わせるだけで、その後の開発効率が大きく変わります。
プレゼン・デモについて
台本は先に作成しておく
台本に関しては、先に作成しておいた上で、ざっくりイメージや練習はしておきたい です。
ハッカソンあるあるですが、最後にバタバタして練習時間が取れない、ということがよくあります。「開発が終わったら練習しよう」ではなく、開発と並行して台本を作成し、リハーサルの時間を確保 しておくことが重要です。自律的なAIを使えば、開発が動いている間に台本やスライドの準備もできたりします。
今回の予選では、発表5分前にスライドを作成し、質疑応答の準備時間はゼロで発表に臨みました。これはやめておいた方がいいです。。。笑
理想は、発表の1〜2時間前には「一旦全て完了している」という状態にすること。そうすれば、最後の仕上げや不測の事態にも対応できます。
発表でのイキイキさが大切
元気がなかったり、楽しそうじゃなかったりすると、聞いている側にも伝わってしまいます。プロダクトの良さは、発表者の熱量で何倍にも増幅されます。
発表では 「ありのまま」 で良いのかも、と思いました。完璧を目指しすぎて緊張するより、「自分たちが作ったものを見てほしい！」という素直な気持ちで臨む方が、聞いている人にも響くのかな？とも感じています。
むしろトラブルはつきものくらいの心構えで、デモで何か問題が起きても 「実際に動いているものを見せている」という自信 があれば、堂々と対応できます。
デモの見せ方を工夫する
今回のプロダクトでは、車への音声対話機能があり、以下のような質問に対応しました：
- 「ガソリンどうやって入れるの？」
- 「給油口どこ？」
デモの会話を、Siriのように自然なやり取り にできないか？どこまでクオリティを高められるか？を検討しました。
また、音声対話のところで日本語・英語に対応している点もアピールポイントでした。このように、プレゼンでのアピールに繋げられる機能をデモすることが重要だと感じました。
開発を高速化したときの弊害
高速で決めつつ、休む時は休む
AI駆動開発で全てが高速化した世界を体験しました。
常にやることが無限に出てきて 、一つ終わったら次、次が終わったらまた次...と、タスクが途切れることがありません。AIがコードを書いてくれる間も、次の仕様を考えたり、レビューしたり、別の機能の設計を進めたり。
ただひたすら機能追加することだけを念頭に、全てのタスクを「As Soon As Possible」で回すことになり、脳が常にフル回転している状態でした。
もちろん、ハッカソンには終わりがあるので、一時の集中で頑張れました。しかし、これを実務でも続けるとなると、本当にそのタスクが必要なのか？もっといい機能の実現方法はないか？ という視点が失われていく気がしました。目の前のタスクをこなすことに精一杯になり、タスクを評価したり、さらにいい価値を提供しようという気持ちが薄れてしまうのではないか、ということです。
また、AI駆動開発では 何を作るか、なぜ作るかの判断 が重要になるので、人間がボトルネックになります。
だからこそ、意識的に休憩を取る ことが重要だと感じました。15分でも休むことで、頭がリフレッシュされて新しいアイデアが浮かんだり、見落としていたバグに気づいたりします。
ただ開発を効率化するだけだと事業価値につながりにくいという話も最近よく聞きますが、ここと重なるように感じました。
超高速でコードが汚れていく
AI駆動開発では、機能がどんどん継ぎ足されていき、メンテナンスが追いつかなくなります。
「とりあえず動けばOK」で進めていくと、気づいた時にはスパゲッティコードの山ができています。後から「ここを修正したい」と思っても、どこに影響が出るかわからない...という状況に陥ります。
ハッカソンなら使い捨てのコードなのでそこまで問題にならないですが、それでも開発中に問題が発生していきました。
どれだけリファクタリングして崩壊を耐えられるようにするか？ が勝負です。
ここが見えるからこそ、以下を意識しました
- 空いた時間で設計を見直す：AIにコードを書かせている間に、全体の構造を俯瞰する
- クラスやファイルの分割を適宜行う：大きくなりすぎたファイルは早めに分割する
- コメントを残す：後から見返した時に、何をしているかわかるようにする
ハッカソンでは「動けばOK」という側面もありますが、最低限の可読性は保っておかないと、デバッグすらできなくなります。
AI駆動開発で高速化する上での心構え
知らない技術でも、積極的に取り組んでみる
以前は「この技術は触ったことがないから...」と避けていたものでも、今は生成AIがあるので 簡単なPoCは作れます。
AIに「〇〇を使って△△する方法を教えて」と聞けば、サンプルコードと解説が返ってきます。それを動かしてみて、うまくいけば採用、ダメなら別の方法を試す。このサイクルが非常に高速に回せるようになりました。
まずは試してみて、さらに技術を深掘りするもよし、「これは今回は違うな」と判断して別の技術に移るのもよし。
まずは試してみる姿勢が大切 だと感じました。触ったことのない技術でも、ぜひ一歩を踏み出してみてほしいと思います。
目の前の一つ目のアイデアに飛びつかない
人間は「自分が考えたアイデアは大事で、最高だと思いたい」生き物だと思います。
「これだ！」と思った瞬間、すぐに実装に入りたくなる気持ちはわかります。
でも、自分が「良い」と思っていても、それが本当にユーザーにとって価値があるかはわかりません。自分にとって都合がいいことしか見てない可能性 があります。実際のユーザーは別の課題を抱えているかもしれないし、すでに競合のサービスが存在しているかもしれません。
AI駆動開発では実装が速くなった分、アイデアの検証に時間を使える ようになりました。
そのため「とりあえず作ってみる」の前に、以下を考えてみるのが重要だと感じました
- このアイデアは誰のどんな課題を解決するのか？
- 競合や既存のソリューションとの違いは何か？
- 審査員や観客は何を「面白い」と感じるか？
客観的な視点を持つことで、より良いアイデアに磨き上げることができると思います。
改良を前提に取り組む
一旦PoCを作ったとしても、そのまま完成させるのではなく、ピボットが前提 になります。最初から完璧なものを作ろうとしないことが大切だと思いました。
実際に作ってみると
- 「思ってたのと違った」
- 「技術的制約があって思った通りにならなかった」
- 「実際に動かしてみたら、別の機能の方が面白そう」
ということは珍しくありません。
だからこそ、最初から「変わることが前提」 でコードを書くことが重要です。仕様変更に耐えられるように、モジュール化を意識したり、空いた時間でリファクタリングをしたり、コードの品質も維持しておく ことで、ピボットが必要になった時にスムーズに方向転換できます。
「せっかく作ったのに...」という気持ちは捨てて、より良いプロダクトのために柔軟に対応できる体制を作りましょう。
自分たちのプロダクトを信じる
AI駆動開発によって、開発自体は高速化できます。また世間でも言われている通り、簡単な機能であればすぐにコピーもできてしまいます。
だからこそ重要なのは、なぜそれがいいのか？なぜそのサービスが必要なのか？ をチームメンバー全員が心から信じられるかどうかかな？と思いました。
プロダクトを信じているからこそ、さらに改良するためのアイデアが次々と浮かんできます。そして、チーム全員が同じ方向を見てトップスピードで走ることができます。
この「信じる」という姿勢を忘れないことが重要 だと再認識しました。
余談ですが、本番発表の前日にチームミーティングを行った際、プレゼンの最後を締めくくるサービスのビジョンについて話し合いました。その時、チーム全員が同じ概念に目を向けて、一枚岩になって発表に取り組めたという経験がありました。
この「全員がプロダクトを信じる」という姿勢は、ハッカソンに限らず、受託開発をしている会社や自社サービスを提供している会社でも同様のことが言えるのではないか？と思います。
技術やスピードだけでなく、チームとしての信念 がプロダクトの価値を高めるのだと感じました。そして、それがそのままサービスの価値につながると思います。
まとめ
AI駆動開発によって、開発速度は劇的に向上しました。しかし同時に新たな課題も生み出したのかな？と思います。
ポジティブな面
- 技術検証のスピードが上がる
- 知らない技術にも挑戦しやすくなる
- PoCを素早く作れる
注意すべき点
- コンフリクト管理がより重要になる
- コードの品質が急速に低下しやすい
- 人間が疲弊するリスクがある
- チームコミュニケーションの重要性は変わらない
開発の高速化は手段であり、目的ではありません。チームとして良いプロダクトを作り、それを正しく伝えるためには、技術だけでなく コミュニケーション や チームワーク が不可欠だと思います。
今回のハッカソンを通じて、AI駆動開発の可能性と、それを活かすために必要な人間側のスキルについて、多くの学びを得ることができました。
ビジネス側の視点について
この記事では主に開発・技術側の視点でお話ししましたが、ビジネスチームのメンバーが「デザイン」「ピッチ」「デモ」に関してどのような意思決定をしていったかが、以下のnote記事にまとめられています。
もし興味があれば、ご覧いただけると嬉しいです。
おわりに
当日の発表では、審査員の方から厳しくも温かいフィードバックをいただき、これからも頑張ろうと改めて思いました。
最後までやり切ってくれたメンバーには感謝しかないです。
素晴らしい場を作ってくださった運営・スポンサーの皆様、的確なフィードバックをくださった審査員の皆様、そして共に挑んだ参加者の皆様、本当にありがとうございました！
最後までご覧いただきありがとうございました。
チームメンバー
Discussion