📝 はじめに

こんにちは、シュートです。

先日、初めて企業主催のハッカソンに参加しました。3日間、初対面のメンバー4人でチームを組んで、あるテーマに沿ったサービスを開発するという内容でした。

参加が決まったとき、正直かなり不安でした。ハッカソンの常連で優勝経験がある人、メガベンチャーのインターン選考に次々と受かっている人——そういう「レベルの高い人」が集まる場だと聞いていたからです。

実際に参加してみると、その不安は的中していました。周りには本当にレベルの高い人が多かった。 自分はチーム開発の経験も浅く、正直「ついていけるのか」という気持ちのまま初日を迎えました。

結果は、8チーム中3位でした。わずかながら賞金もいただきました。

以前の記事で「AIなしでは書けない」「成長できているか不安」という話を書きました。

https://qiita.com/Yamada040/items/a8230f78084612e4e9e1

レベルの高い人たちに囲まれながらも、意外と自分の実力が通用した場面がありました。この記事では、3日間の流れと、チーム開発で感じた気づき、そして自分が何にこだわって結果を出したのかをまとめます。

同じように「ハッカソン、レベル高そうで不安」と感じている方に、何かしらの参考になれば嬉しいです。

📅 3日間の流れ

まず、ハッカソンがどんな進行だったかを共有します。同じような形式のハッカソンに参加する方の参考になればと思います。

1日目: ドメイン知識のインプット + 方向性の議論

初日は、テーマに関するドメイン知識をインプットする時間から始まりました。今回のテーマは不動産投資に関するものだったので(具体的な内容は割愛します)、業界の構造や課題について講義やレクチャーを受けました。

インプットの後、チームで開発の方向性についての議論も始まりました。「何を作るか」の輪郭をこの時点である程度掴んでおく必要があり、初日から本格的な話し合いが始まった形です。

正直、「早くコードを書きたい」という気持ちもありましたが、後から振り返るとこのインプットと議論の時間がチームの議論の質を大きく左右したと感じています。ドメイン知識がないまま「何を作るか」を話し合っても、表面的なアイディアしか出てこなかったと思います。

2日目: チームの方向性決め + 中間発表

2日目は、1日目の議論を踏まえて、チームの方向性を確定させるところから始まりました。方針が固まったら実装に入り、その日の終わりに中間発表があります。中間発表では、方針と、その時点での開発の進捗を発表する形式でした。

ここが一番苦しかった時間です(詳しくは次の章で書きます)。

3日目: 最終発表

3日目は午前中に開発の追い込みを行い、昼から最終発表という流れでした。3日間という短い期間の中で、初日はインプットと議論に多くの時間が割かれるので、実質的な開発時間は2日目から3日目の午前までしかありません。

スケジュール感のまとめ

日程	内容
1日目	ドメイン知識のインプット + 方向性の議論
2日目	方向性の確定 → 開発 → 中間発表
3日目	開発の追い込み → 最終発表(昼〜)

短期間で「知識を得る → 方向性を決める → 作る → 発表する」を一気に回す必要があり、どの工程を圧縮しても質が落ちるという、なかなかタイトな構成でした。

😅 チーム開発で一番難しかったこと

3日間の中で一番苦しかったのは、コードを書くことではありませんでした。「何を作るか」を決めるプロセスです。

意見をすり合わせることの難しさ

チームは初対面の4人(学部生2人、院生2人)でした。それぞれが自分なりのアイディアを持って議論に入ります。

誰かがアイディアを共有する。それに対して自分の意見を話す。逆に自分のアイディアを共有すると、それに対してみんなが意見を返してくる。この繰り返しの中で気づいたのは、「良いアイディアを出すこと」より「全員の目線を合わせること」の方がずっと難しいということでした。

個人開発なら、自分が「良い」と思った瞬間にそれが正解です。でもチームでは、自分が良いと思ったアイディアも、他のメンバーには全く違う角度で見えている。それぞれの視点をすり合わせて、一つの方向に揃えていく作業に、想像以上に時間がかかりました。

「何を作るか」を決めることの難しさ

アイディア自体を出すことは、実はそこまで難しくありませんでした。難しかったのは、そのアイディアが本当に課題を解決できているのかを、細部まで考え抜くことです。

「面白そう」「需要がありそう」というレベルの合意はすぐに取れます。でも、

このアイディアは、テーマの課題を本当に解決しているのか
実装できる規模に収まっているのか
審査員に伝わる形にできるのか

こういった問いを一つひとつ検証していく作業は、話し合いというより地道な詰め作業でした。ここを甘くすると、後から「結局何を解決したいサービスなんだっけ」と迷子になります。実際、チーム内でもこの部分の議論に一番時間を使いました。

個人開発とは違う難しさ

個人開発では、実装力さえあればある程度のものは作れます。でもチーム開発、特にハッカソンのような短期間では、「何を作るか」を決める合意形成の速度と質が、そのままアウトプットの質に直結すると感じました。

技術力よりも先に、この部分でチームの差が出るのかもしれません。

🎨 自分がこだわった役割

方向性が決まった後、自分はフロントエンド開発を中心に担当しました。ただ、単に「画面を作る」だけでなく、2つのことに特にこだわりました。

1. UI/UX と「審査員への見せ方」

ハッカソンでは、機能がどれだけ実装できているかだけでなく、それが審査員にどう伝わるかも評価に直結します。

同じ機能でも、UIが整理されていて操作の意図が一目で分かるものと、機能はあるけど何をするための画面か分かりにくいものでは、伝わる印象が全く違います。限られた発表時間の中で審査員に価値を理解してもらうには、**「説明しなくても伝わる画面」**を作る必要があると考えました。

具体的には、

情報の優先順位を明確にしたレイアウト
操作の流れが直感的に分かるUI
発表のデモで見せる画面遷移を意識した設計

こういった点を意識して、限られた時間の中でUI/UXの完成度を上げることに時間を使いました。

2. 内部品質へのこだわり

今回のハッカソンでは、内部品質(コードの品質)も評価項目に含まれていました。短期間の開発だとどうしても「動けばいい」というコードになりがちですが、そこにも意識的に時間を使いました。

具体的にやったことは、

主要な機能に対するテストの実装
実装が進む中で発生した重複や無駄なコードのリファクタリング

3日間という短い期間でテストやリファクタリングに時間を使うのは、正直リスクがある判断でした。その時間を新機能の実装に使えば、もっと多くの機能を見せられたかもしれません。それでも、「動くだけのコード」ではなく「読める・保守できるコード」を目指すという部分は譲りたくなかったポイントです。

このあたりの意識は、前回の記事で書いた「AIに頼りきらず、一つひとつ理解しながら進める」というスタンスとも繋がっている気がしています。

🏆 結果と評価されたポイント

3日間の結果、8チーム中3位という評価をいただきました。わずかながら賞金もいただき、正直かなり驚きました。

審査員からのフィードバックで、特に嬉しかったのは次の2点です。

1. 内部品質を評価していただけた

テストの実装やリファクタリングに時間を使った部分について、**「動くだけでなく、コードの品質まで意識できている」**という評価をいただきました。

短期間のハッカソンでは、動くものを見せることが最優先になりがちです。その中で内部品質にまで踏み込んだ点を見てもらえたのは、リスクを取って時間を使った判断が結果につながったということだと思っています。

2. アイディアの独創性を評価していただけた

チームで一番時間をかけて詰めた「何を作るか」の部分についても、独創性があるという評価をいただきました。

前の章で書いた「地道な詰め作業」——このアイディアが本当に課題を解決しているのか、細部まで考え抜いた時間が、独創性という評価に繋がったのだと思います。派手なアイディアより、課題に対して丁寧に向き合った結果が評価された、という感覚がありました。

レベルの高い人たちの中での結果

冒頭で書いた通り、周りには本当にレベルの高い人が多くいました。ハッカソンの常連で優勝経験がある人、メガベンチャーのインターン選考に次々と受かっている人。そういう人たちと同じ場で評価を受けて、8チーム中3位という結果を出せたことは、自分の中で一つの手応えになりました。

💡 気づき — 実力が通用したという手応え

冒頭で書いた通り、参加前は「ついていけるのか」という不安が大きかったです。実際、周りにはハッカソン優勝経験者やメガベンチャーのインターンに次々と受かっている人など、レベルの高い人が本当に多くいました。

その中で気づいたことがあります。

個人の技術力の高さと、チーム開発で成果を出せるかどうかは、必ずしも一致しない。

もちろん技術力がある人たちはすごかったです。実装のスピードも、知識の量も、自分とは差がありました。ただ、チームというものは技術力だけで成立しているわけではないと感じました。

課題を細部まで詰めて考える人
UIやプレゼンで伝わり方を意識する人
内部品質のような、目立たないけど大事な部分を担う人

こういった役割は、必ずしも「一番技術力が高い人」が担うものではありません。自分は今回、その中の一つを担うことができた。それが、8チーム中3位という結果につながったのだと思っています。

以前の記事で、「AIなしでは書けない」「自分は成長できているのか不安」という話を書きました。その不安は、今も完全には消えていません。でも今回のハッカソンで分かったのは、技術力の物差し一本で自分を測る必要はないということです。UI/UXへのこだわり、内部品質への意識、課題を丁寧に詰める姿勢——こういった部分も、ちゃんと評価される対象になる。

レベルの高い人たちに囲まれても、自分にできることで成果を出せた。この手応えは、今の自分にとって小さくない自信になりました。

🙌 おわりに

今回の気づきをまとめると、こんな感じです。

チーム開発で一番難しいのは、技術力より「何を作るか」を決めるプロセスだった
UI/UX、内部品質など、自分にできることにこだわって成果を出せた
技術力の高さと、チームでの成果は必ずしも一致しない

参加前は不安でいっぱいでしたが、終わってみると「レベルの高い人たちの中でも、自分にできることがある」という手応えを持って帰ってこれました。

ハッカソンは、技術力を試される場だと思っていましたが、実際はチームとしてどう課題に向き合うかを試される場だったのかもしれません。同じように「ハッカソン、レベル高そうで不安」と感じている方に、少しでも参考になれば嬉しいです。

初めてのハッカソン、いい経験になりました💪

最後まで読んでいただき、ありがとうございました！