ハッカソン負け方講座〜経験談編〜

この記事について

この記事はハッカソンの負け方講座の各論編です。この記事では自分が負けたハッカソンについてのケーススタディを通してハッカソンの負け方についてお話できたらと思います。

ハッカソンの負けの振り返り(ケーススタディ）

100program

結果：決勝戦敗退

作ろうとしたもの：習慣化アプリケーションと時間可視化デバイス

まず初めに僕がリータをした一番最初のハッカソン形式のプログラムで2ヶ月間の時間あありました。まず初めにかなり習慣化についてメンバーからかなり大量の意見が出ました。そして作ったアプリとしては時間をボタンだけで示すことができるアプリケーションを作りました。かなりプレゼンテーションが得意なメンバーがいたためそのメンバーの助言で予選は突破したが決勝では一つも賞を取れずに惨敗した。

原因分析

• メンバーに技術力が足りない
• やりたいことが多すぎる
• 体験が決まっていない。何をユーザーにさせたいかがわからない。
• 理論的には良いが、それがユーザーに一発で伝わらない。
• デモが完成していない。

これがかなり大事で、メンバーのやりたいことが多すぎて「何を作るのか」と「ユーザーにとってどのような体験を与えるのか」ということを考えられていなかった。理論的な部分が先行しすぎてUI/UXに心理学的な要素を入れたがそれが技術不足で作れるところまでいけなかった。

jackHack2024

結果：賞なし

作ったもの：詐欺詐欺パニック

jack Hackでデモは完成した。（ほとんど先輩のおかげ）そしてかなりの人に遊んでもらえてかなりできそうでできないゲーム性がすごく評価された。しかしながら結果は惨敗。

原因分析

• デモは完成
• しかしながら、「使いたい」が評価基準だったためかなりの人に遊んでもらえたが敗北

ハッカソンは基本的に「勝ちに行くのか」「楽しみに行くのか」でハッカソンの仕方がとても変わってきます。今回は負けの分析なのでなぜ負けたかを考えることにしましょう。このハッカソンではオーディエンス投票を採用していました。オディエンス投票の場合にはどのような観点で評価するのかを考えるべきです。最終的な評価指標は今回は「どれだけ使いたいか」というところで「日常的にどれだけ使えるか？を投票する側が考えた部分が大きいです。このようにオーディエンス投票の場合には先に何が評価基準かということを考えてアイディアを出すと勝ちやすいプロダクトになります。

100program

結果：予選敗退

作ろうとしたもの：学習管理のためのポモドーロアプリケーション

前回の反省を活かして「技術力が強い」メンバーをリクルートして再度EdTechに挑戦した。学習の最適化を目指したアプリケーションを作成しました。しかしながら「アイディア」が強いが何を作りたいかなどの仕様書が明確にならず、メンバーがなんとか形になるものは作ってもらったがどんなものを作りたいのかということが明確になっておらずうまくチームメンバーに作りたいもののアイデイアを伝えることができませんでした。さらに自分がリーターとしてチーム運営したのにも関わらず最終発表は自分が別のハッカソンに出ていたために出場できず他の人に任せてしまいました。

原因分析

• 自分が最終プレゼンにいない
• メンバーのやる気がない
• 自分が作りたいものが明確でない。
• 自分がやりたいことが理論的すぎて、ユーザー体験として何がしたいのか？その先にどのようなTechがあるのかを明確に考えられていない。
• メンバーの技術力に対して、圧倒的に自分の技術力が足りない。
• 自分の時間がない。（メンバーに対して目的を共有できるだけの時間がない）
• 何をやりたいかどんなものを作ることが最終的なゴールなのかを具体性を持って話をすることができない。

ハッカソンのプレゼンテーションにおいては基本的にリーダーもしくはそれに準ずるだけのプレゼン力を持ったチームメンバーに行ってもらった方が良いです。これはなぜかというとリーダとチームメンバーの場合に熱量が違うという部分があります。やる気がない場合や無理やりプレゼンさせると上手いプレゼンのアウトプットは生まれない。基本的にチームメンバーでもアイディアを考えた人のレベルのプレゼン資料を作ることは難しいです。そしてメンバーに対してゴールを共有していなかった点はかなり反省すべき点でそれがないことでチーム全体としての方針が立たず実装したかった機能が消えていきました。そしてメンバーとの技術力の差があったためメンバーをうまく使うことができず継続開発する予定でしたが最終的にチームは崩壊しました。

技育キャンプ

結果：敗退

作ったもの：github battle community

チームは即席チームで作成しました。即席チームなのにも関わらずアイディアもすぐに決まりどのように作成するのかも決定してかなり好調に進んでいました。そして最終発表日にもコードをリファクタリングすることができるくらいかなり余裕がありほしい機能もどんどん作ることができました。

• 開発はかなり好調
• 開発のデモもdeploy
• アイディアも刺さる人には刺さる
• → 何が悪いか
  • 体験として一発で目にみえるわけではない。
  • 持続的に使ってもらう形だからその体験をプレゼンで話せなかった。
  • 基本オーディエンス賞なので、オーディエンスが欲しいと思ったものが必要で、インパクトがプロダクトに足りない

ハッカソンのオーディエンス賞のみだったので基本的に強いプロダクトに全て吸われてしまいます。基本的に技育キャンプはオーディエンス賞なのでインパクトを持ったプレゼンやその内容と課題感を確実に共有する必要があります。この部分は開発がうまくいったとしても「どんなものがよりよりプロダクトであるか」というのはかなり重要です。良いプロダクトであっても評価されないこともあります。これは最終的には運であることがあります。

とある名古屋のハッカソン

結果：惨敗

作ったもの：kokorobakari

アイディアソンから考えた。割り勘というなかなかよくある課題に対してFinTech的な解決策を行うことができるのではないかと考えてお金を共有するアプリケーションを作ろうとした。

原因分析

• アイディアは面白い。しかし、ビジネスとして成り立たせることができない。
• ユーザーヒアリングが非常に少ない。ヒアリング量とアイディアの質があまりにもよくなさすぎる。（どんなユーザー価値・社会課題などが解決できるのかわからない。）
• ビジネス側の大会なのか？そうでないか？（面白いものが評価されるか？）研究が評価されるか？を明確に分けて、出すところを考えないといけない。
• FInTechは素人がやるには厳しすぎる。
• 基本マッチングとか、データベース使いました〜だけどかはまじで避けるべき
• そうゆうのやるなら技術力とヒアリング力でかなり押し切るべき
• メンターは基本使えないものだと思ったほうがいい。自分たちが面白いと思ったものを作るべき。

メンターに対してかなり答えを要求してしまった。基本的にビジネス側のメンターは自分の会社以外のアプリケーションの概要などには興味がなく、「どのようなセグメント」の人が「どのようなニーズ」があるのかということをすごく気にします。つまりそのプロダクト自体に価値があるかよりもそれはマーケットに受け入れられるのか？そしてそれは使えるのかは二の次でニーズがあるのかとか顧客イメージみたいなところにかなり主眼が置かれます。このようなことがわかっていないとビジネス側のメンターとの齟齬が発生します。そしてFinTechは素人が手を出す分野ではありません。やめましょう。

とある企業のハッカソン

結果：惜敗

作ったもの：夢ステップ

3日のハッカソンで作成しました。夢を支援というお題に対してかなり支援を明確に打ち出して作成しました。開発もそこまで悪くはなかったが環境構築部分で難儀なことになってしまいました。

原因

• アイディアは面白いしかしインパクトに欠けるアイディア
• 評価基準を見ていなかった。
• やりたいことは明確だが態度が良くなかった。
• プレゼンよりも内部ロジックを見られた（初めて内部コードが大事なハッカソンにきた）
• 自分のやりたいことをそのまま貫き通したハッカソン
• 自分がやりたいことをとにかく愚直にやるハッカソンで、技術的な挑戦をとにかくしたと思い込んでいる。
• 審査基準としてかなりコードを見られるハッカソンだったためにコミットやメッセージある程度の開発量がなかった
• スライドデザインは全く評価されないのにも関わらずそこに注力した

このハッカソンについてはかなり賞に近かったハッカソンでした。かなり自分としては開発もプレゼンもなかなかうまくいったのだがなぜか賞が取れなかったハッカソンでした。この後に技術の人からのフィードバックとして「スライドのインパクトは凄かったがプレゼンの順番が悪かった」「個人賞はgithubのコミットとロジックで見る」とか言わました。そもそも僕らが目指していた方向性と賞が取れるという基準がマッチしていないことが問題でした。ここから先に賞を得ることを考えるならなんとなくでも確実に賞の方針は確認しておきましょう。そしてリーダーをする際にはチームメンバーとのコミュニケーションを大切にして何をやりたいかの目標を明確化しましょう。

とあるSNS作成

結果：チーム爆散

作りたかったもの：SNS

とにかく技術専攻で面白いSNSを作りたかった。ゲーミフィケーション的なアプリケーションを作りたいというリーダのもとで3ヶ月くらい作り続けました。しかしながら技術選定が非常に難しかったことや知らない技術のオンパレードでさらに理論が先行してしまいどうしてもユーザーバリューなどについてリーダとうまく折りが合わず最終的にチームが爆散しました。

• リーダーのやりたいことがわからない。
• 何を作ればいいのか？何をやればいいのか？の責任が分散しすぎて何もできない
• やったことに対しての評価が何もない。
• やりたいことと理論が先行しすぎていて誰も理解ができない。
• 社会問題を幅広く捉えすぎている。そのプロダクトが解決できるのは一つに絞る方がいい
• SNSというかなり陳腐なアイディア（SNSほど難しいものはない）
• Aiコーディング主導で、よくわからないことを言う。
• 話し方が非常によろしくない。
• 意見が対立すると大変、何がしたいのか？どうしたいのか？ユーザー価値は一体なんなのか？を考えるべき、
• そもそもアプリが社会現象になる規模のものはなかなか作れない。
• 日記とかSNSとかは、全てが完成されなければ私たちは不可能
• 社会実装手順が意味不明
• チームビルディングが失敗している

このプロジェクトについてはかなり色々なチーム運営におけるアンチパターンが相当あると考える。社会課題に対してアプローチするのは良いのだがそのユーザー価値や何がしたいのかどう解決したいのかが願望なだけだとそれは基本的に解決策とは言えない。そしてそのようなふわふわした解像度が低いままプロダクトに落とし込もうとするとメンバーからの信頼も得られず何もできないで進捗が生まれずチームとしての雰囲気が悪くなる。このようなチームビルディングは避けるべきである。

ある企業のハッカソン

結果：敗北

チームメンバーの課題感と作りたい機能があったのでそこから考えた。チームメンバーの課題感優先で作り、デプロイまで行けたがうまく良い賞を取れませんでした。

• 欲しい機能を作りすぎた
• 価値をどのように生み出しているのかということがわからない伝えきれない
• 自分たちが何をやろうかということがむずかしい
• アイディア発想として、ソリューションから考えたのは非常に良くなかった。基本的にはソリューションから考えるのはあまりにもよくないことになる。

このハッカソンがかなりビジネス側の人が審査していた。そのためにアイディアとしてソリューションから考えました。しかしながら、ソリューションは最終的にビジネス的にそれが妥当性を評価されました。そのために、このようなビジネスを求められるようなハッカソンではプロダクトアウト（技術的なところとか新たな価値創造とか）をするよりも明確な課題感から出発したほうが良いです。

最後に

ここまで「負け方」についての記事を読んでいただきありがとうございます。まとめると課題感プロセスとアイディア創造プレセスそして具体化フェーズに至るまで様々な点に負けるための要素があったと思います。体験してみなければわからないことは非常に多いですがこの記事が負けを分析する上での何かしらの役に立てれば幸いです。