はじめに
ハッカソンの4人チームでPM担当になり、ボコボコにされた話です。最終的に60チーム中11位でファイナルステージに進出したものの入賞できませんでした。PMとしての反省点、ハッカソンとしての反省点を語ります。
この記事で学べること
- 初心者中心のチームでハッカソンに挑戦した実体験
- Web開発経験が少ないチームが直面した5つの課題
- AI時代のチーム開発で気をつけるべきポイント
- ハッカソンで成果を出すための具体的なTips
参加したハッカソンの概要
東京AI祭という生成AIを使ったアプリ開発で競い合うハッカソンに参加しました。およそ100チーム200名のエントリーがあり、我々のチームはファイナルに進出し、下記の成果物を提出しました。制作期間は1ヶ月です。
簡単に言うと「ストーリーテリングに基づく動画を生成してくれるアプリ」です。裏側でAIエージェントやMCPサーバーを組み合わせることで、高品質なプロンプトを担保し、動画生成を実施します。
チームメンバー
下記のメンバーで参加しました。
- 私：データアナリスト（3年）Python
- Aさん：データアナリスト（2年）Python
- Bさん：AIエンジニア（0.5年）Python
- Cさん：バックエンドエンジニア（0.2年）Python
Pythonに技術スタックが偏っていますが、アプリ作れそうな気がしますよね？
ちなみにここでいうPythonは、Web開発のPythonではなく、データ分析や機械学習の文脈でのPython経験です。
さて、地獄が始まります。具体的にどんな事件があったのでしょうか。
開発における反省
時系列順に5つの事件がありました。それぞれ見ていきましょう。
1. あれ? Web開発できる人いなくね?
まずハッカソンのキックオフイベントがありました。そこでハッカソン参加者と交流し、実際にチームを組みます。私は30人くらいとお話して、技術力が高い人ではなく、一番性格が良さそうな人4人と組みました。この選択は「良かったこと」で話しますが、とても英断だったと思っています。
しかし問題がありました。チームを組んだ4人のスキルセットが、みんな同じような分野に偏っていたのです。そして下記の問題点が浮かび上がります。
「Web開発できる人いなくね?」
特に下記の知見を持っている人がいませんでした。
- フロントエンド
- クラウド
- Docker
とはいえ私もバイブコーディング（AIアシストコーディング）でAzureで簡単なRAGチャットボットくらいは作ったことがあったし、今はバイブコーディングもあるし余裕だろって思ってました。
やっておくべきだったこと
技術スタックがバランスの良いメンバーで組む
反省点
メンバー間で技術スタックが偏りすぎていた
2. Gitってなんですか?
さて開発をスタートしようと思った矢先、こんな問題が出てきました。
私以外チーム開発未経験。
「Gitって使ったことあります?」って聞くと1人しか使っていませんでした。使っている1人もadd、commit、pushの3つを使っているレベルで、コンフリクトなどの対処方法は知らないという状況でした。
まあ知らないなら教えればよいということで、ここは私がGitの講習を3人向けに開催しました。概念とプルリクエストが投げられ、コンフリクトの解消もなんとなくできるレベルまでハンズオンで教えました。これでやっと開発できますね。
「調べてね」でも良いんですが、せっかくチーム開発しているので、関係性を構築する目的でも一緒に手を動かしました。
やって良かったこと
必要最低限の知識はメンバー間で共有する
教えながら関係性を構築する
3. 初心者のバイブコーディングでコードが終わる
さてGitを使えるようになりました。
現代はバイブコーディング時代。Gitが使えれば誰でもアプリ作れるよね? Claude Codeに頼れば良いよね?
フルボッコにされました。
バックエンドをBさんに任せていたのですが、彼がClaudeに盲信状態になってしまい、リポジトリのコードが終わりました。ある日pullしたら100個のファイルが流れ込んできました。
最終的に彼がコードを理解したことでバックエンドは動作するようになりましたが、私が事前にAIを使ったコーディングの注意点を伝えておくべきでした（個人開発ならOKですが）。
コード間の依存関係もわからず、私も読む気をなくしてしまいました。今思うとこの時点で一度作ってきたコードを捨てて、理解のあるコードをゼロから書くようにするべきでした。AI時代は一度作ったコードを捨てる選択も寛容になるべきです。
個人的には、バイブコーディングは自分が実装したことがある領域、基礎知識がある領域でない限り使わないほうが良いと思っています。
やっておくべきだったこと
バイブコーディングの使い方についてチームで認識を揃えておく
カオスになったコード群は捨てることも考える
理解していないコードは使わない
反省点
自分の知らない領域のコーディングは理解しながら実装する
4. Azureデプロイの沼
さてバックエンドが動くようになり、フロントエンドもなんとか完成しました。ここまで7日くらいかかりました。この後Azureにデプロイするだけです。
まずはAIに聞きながら、フロントエンドはAzure Static Web Apps、バックエンドはAzure Functionsをメインに構成することにしました。初心者でもいけそうな構成だし、以前も経験があったので余裕だろって思ってました。
全然デプロイできませんでした。
フロントエンド→バックエンドの認証を通すのに苦労して2週間くらい費やしました。フロントエンド担当のCさんとバックエンドのBさんで連携しながら、AIを使いながらなんとか解決しました。
ここでの反省点は、Azure Functionsの奥の深さを舐めていたところです。デプロイの設定にも5種類くらいあり、それぞれに微妙に仕様の違いがあり苦しみました。実はAzure Functionsを使わなくてももっと簡単に実装する方法は、よく調べたらありました。しかしアーキテクチャを安易に決めてしまったことが反省点です。
まあここは正直、経験の浅さによるものもあるのかなと思います。
やっておくべきだったこと
本当にこのアーキテクチャが最も簡単なのか考える
反省点
いろんな実装パターンを考えるべきだった
失敗したときのプランBも考えるべきだった
5. 7000円コストしているんだが?
あるときAzureのコストを監視していると、1日で7,000円コストしていました。原因を探ってみるとSQLサーバーがコストしています。なんとなく何が起きたのかわかったのですが、実装したCさんに話を聞いてみます。
私「SQLサーバーのデプロイってどうやりました?」
Cさん「Claude CodeからCLIでデプロイしました」
私「デプロイしたときの細かい設定を教えてもらっても良いですか?」
Cさん「……知らんす」
現場でエンジニアしている人からしたらありえないことですが、未経験の人はこういうことが起きます。原因はご想像の通り、VMが立ち上がりっぱなしだったことです。
これは3のバイブコーディングの話と似ていますが、AI時代にエンジニアになった人には要注意するべきでした。
やっておくべきだったこと
ミスするとコストがかかってしまう領域は有識者が巻き取る
反省点
AI時代にエンジニアになった人の実装には気を配る
ハッカソン的な反省点
プロダクトのインパクトが弱かった
作成したプロダクトが世の中に与える影響力への考慮が足りていませんでした。
入賞していた作品は、技術力が弱くても社会的なインパクトが大きければ評価されていました。審査員の人が実際に価値を感じるのか? に重きが置かれている印象でした。多くの人が課題に感じやすい分野を課題設定すると良いのかなと思います。
私たちのプロダクトはアート業界を対象にしていて、特定のドメインに特化しすぎていました。もちろんこれはハッカソンの性質によるところではありますが。
入賞していたチームとの差分は、ここが一番大きかったように感じますね。
反省点
プロダクトの刺さる人が限られていた
中間指標から差分を考える
このハッカソンは100チーム中、30チームがセミファイナルに到達し、15チームがファイナルに進出します。セミファイナルの時点で順位を発表してくれました。これを活かすべきでした。
結局、セミファイナル上位のチームとファイナルで入賞したチームは相関していたので、セミファイナルの時点で上位のチームと何が差分があるのか考えるべきでした。「なんとなくプロダクト改善すれば順位上がるんじゃね?」は安直すぎました。
反省点
途中経過がわかるのであれば、上位のチームと差分を考えるべき
質問には回答するだけではダメ
このハッカソンは発表4分、質問1分の計5分が割り振られていました。正直、私たちのチームは発表はやりきったと思っています。
しかし質問がイマイチでした。質問されたことへの回答しかできていなかったのです。質問は回答に答えるだけではなく、自分たちがアピールしたいポイントを追加で補足することも考えるべきです。もちろん相手が興味を持ってもらえるように。
反省点
質問はアピールする場所
（個人的に）やって良かったこと
朝会を開催した
ハッカソン期間中はメンバーには7:30から朝会に参加してもらい、下記の3点を共有してもらいました。
- 昨日やったこと
- 現在詰まっているところ
- 今日やること
私が都度技術アドバイスをしていました。これによりメンバーがどこで詰まっているのかわかり、サポートすることができました。またコミュニケーションを取ることで関係値構築にもつながりました。
また作業するときにはSlackのハドルミーティングをつなぐようにして、少しでも多くの時間を過ごせるように心がけました。
やってよかったこと
毎日話す時間を作る
プロダクトバックログを作る
Notionのプロダクトバックログのテンプレートを使い、メンバーのタスクを管理しました。URLさえ知っていれば編集できるので最高でした。
性格の良い人とチームになる
ハッカソン期間は長いです。皆さんの周りにも技術レベルは高いけれど気難しい人はいませんか? そういう人と組むのも技術的には勉強になるかもしれませんが、ストレスフルな開発体験になってしまいます。
コミュニケーションの量が学びの量にもつながると思うので、楽しい人と開発すると良いと思います。せっかく休日の時間を使っているのですから。
サービスを使ってくれた人がいること
実際にサービスを使ってくれた人がいました。これはファイナルに進出した15チームの中で2チーム（私の記憶だと）しかできていなかったことなので、大きな成果だと思っています。サービスを使ってもらえるために地道に営業したのも良かったです。
まとめ
AI時代のチーム開発では、AIツールの適切な使い方をチーム全体で理解することが重要です。特に、理解していないコードは使わない、コスト発生領域は有識者が管理する、といった基本原則を守る必要があります。
また、ハッカソンでは技術力だけでなく、プロダクトの社会的インパクトや訴求力が評価の大きな要素になります。中間評価がある場合は、それを活用して戦略を見直すことも重要でしょう。
何より、長期間のハッカソンでは、チームメンバー間の良好な関係性が継続的な開発の鍵となります。技術スタックのバランスも大切ですが、一緒に楽しく開発できる仲間と組むことで、困難な状況でも乗り越えられる力が生まれるのだと実感しました。