はじめに

ハッカソンは徹夜してナンボだという価値観がある。
それらの考え方は別に間違っているわけではない。

ハッカソンの語源を考えても「マラソン＋ハック」であり、マラソンのように体力の限界を競うものであったのだろう。

しかしハッカソンに参加したい人にとってのハードルに「苦しいものだ」というイメージがあることも事実である。

知り合いをハッカソンに誘った時に「月曜の仕事に響くからハッカソンへの参加は遠慮するわ」「ハッカソンって一度出たことあるけどめちゃくちゃきついからいやだ」といわれて断られるのは、もはやあるあるだろう。

苦しいイメージの根元にあるのは、「徹夜」だと、私は考える。

ハッカソンの発展、ひいては若手エンジニアの技術力向上のために「ハッカソン≠徹夜」であるということを声を大にして言いたい。

ということで「徹夜」しないを裏テーマに、qiitaハッカソンに参加した結果を共有する。

※注意
書き終わって気づきましたが、「課題解決型」のプロダクト前提で書いてしまったので、「ゲーム型」のプロダクトを作りたい場合は適宜読み替えてください。

前提

徹夜しないという裏目標を達成したハッカソンがどのようなものだったか、まず前提を共有。

どんなハッカソンだった？

基本情報はこんな感じです。

Qiita主催のハッカソン
テーマ「オープン」
技術的制約なし
（睡眠時間が0だと仮定した場合）開発時間は27時間
発表時間3分
二人チームで、エンジニアは一人

80組も参加する、かなり盛り上がったハッカソンでした。
他のハッカソンと比較して、1人参加のエンジニアの数が多いのが印象的でした。

また、テーマの「オープン」が非常に難しく、開発時間も短いため、途中棄権者もちらほら見られる、ハードな大会だったと感じます。

チーム構成

デザイナーさんと組んでの2人チームでした。エンジニアは自分1人です。

また自分はモバイルアプリエンジニア(KotlinとFlutterメイン)なので、ウェブは本職ではありません。
その状況で完成させるというのはなかなか難易度の高いことでした。

何を作った？

「飲み会から帰りたいけど、なかなか帰るタイミングが掴めない」という課題を解決するためのLineボット「そろそろかえりますか」を作りました。

事前に帰りたい時間を登録しておくとLINEグループに通知が来るので、「自分からではなく誰かに促されることで帰る」という自然な流れで帰るためのプロダクトです。

アーキテクチャ

クライアント側はLIFFというフレームワークとLineアカウントです。
サーバー側はCloud FunctionsとFirestoreというよくあるハッカソン構成です。

結果は？

予選通過できました。
やった！

このあと本戦に出場します！

徹夜しない戦略

前提が長くなったがここから本題。
今回実施した徹夜しない戦略は次の三つである

とにかく寝る
寝れない原因をできるだけ消す
設計後に方針転換のタイミングを設ける

とにかく寝る

いきなり精神論だが、一番大事なのはこの覚悟だ。

ハッカソン経験者なら、いや徹夜経験者なら、徹夜中にふとこう思ったことはないだろうか？

「眠すぎる。今寝て、朝やったほうが効率が良いのでは？」と

締め切りが近づいている状況や、「寝たら負け」という謎の価値観によって、この考えを言い訳だと打ち捨ててしまう人が多いが

普通にこの考えは正しい。

徹夜して作ったところでろくなことは無い。

コードの行数は増えるかもしれないが、発表本番でバグの起こるクソコードを量産しているだけである。

冷静になろう。

寝れない原因を消す

仕事で徹夜することは少ないのに、ハッカソンではよく徹夜してしまうのはいくつかの原因がある。

以下で詳細を述べる。

余計なものを作る

余計なものとは、発表しても評価されないものだ。

こういうものに時間を取られると、いとも簡単にタスクが増えて徹夜する羽目になる。

どんなに頑張って開発しても、発表では5秒しか触れられなかったり、下手したら発表内では全く触れられない場合もある。

こういうものは思い切って切る勇気が必要だ。

余計なものかどうかをどうやって判断するの？

実装しようとしている要件が必要なものかどうかは、以下に当てはまるかで考えよう。

価値提供のコアになっているか？
プロダクトの最大のウリなのか？

価値提供のコアとは？

価値提供のコアになる要件とは、発表やデモで確実に触れられるプロダクトのメインだ。

例えば「ねこ派だけのSNS」を作るなら
SNSの投稿機能、一覧表示機能あたりがコア機能だろう。

それ以外の機能はコアではない。

プロダクトの最大のウリとは？

ここで大事なのは「最大」のウリであるということである。

よくある発表の流れとしては完成したプロダクトの中からいくつか「ウリ」を抽出して、優先度順に発表に詰め込むという流れだろう。

普通の開発ならそれでも良いだろうが、徹夜しないためには工夫をした方が良い。

「ウリ」は一本に絞ろう。

その「ウリ」はアイデアやチーム次第で変わる。
突き詰めたUXかもしれないし、堅牢なセキュリティかもしれない、先ほどの例に出した「ねこ派だけのSNS」であれば、いぬ派を排除するための機能なんかがそれに当たることもある。

大事なのは、一つに絞ることだ。

複数の機能やウリがあることは良いことだが、短い発表時間の中で全てを完全に説明し尽くすのは至難の業だ。

もし最大の「ウリ」がそれ単体では弱いと感じるなら、
別のアイデアにならないか考えることも必要かもしれない。

よく知らない枯れていない技術を避ける

枯れた技術とは、実務で使われ始めバグがへり、ドキュメントが充実している技術のことである。

枯れてない技術とは、その逆で、新しく発表された技術やドキュメントがまだ不十分な技術である。

ハッカソンの場だと、実務ではまだ使えない新技術を使ってみたいという欲求が出てくるので、新技術に手を出しがちである。

しかし初めて触るタイミングをハッカソンにするのはやめよう。

「新技術を試すことができるのがハッカソンの魅力」だと考えているなら事前に最低限の学習をしよう。

事前の学習を終わらせていないなら、素直に枯れた技術を使おう。
枯れた技術を使うことでも学習効果はある。

寝れない原因を消すことについてまとめ

寝れない原因を消すことについては、長くなってしまったのでまとめる。

設計し始める前に「要件を絞る」
設計時に「よく知らない枯れていない技術を避ける」

設計後に方針転換のタイミングを設ける

最後だ。
今までのハッカソンで寝れなくなった時には共通点があった。
それは、アイデアが固まった後、すぐに個人作業に分かれたことだ。

チームで開発しているならよくあるだろう。

「アイデアは決まったから、役割分担してあとは個人作業で！」
「3時間くらい経ったら状況共有しよう」
的な流れ

これは結構リスキーだと感じる。

実際に設計や、少しだけコードを書いたタイミングで、おそらく何かしらの不安が出てくるだろう。

しかし、「個人作業が始まっているし、もしかしたら杞憂かもしれない」という楽観的な考え方でみんなの手を止めて話すことではないかもしれない。

ようやく走り始めた爽快感は気持ちが良いが、方針転換できる最後のタイミングを逃すことは避けるべきだ。

おわりに

ここまで読んでいただきありがとうございます。

今回は「ハッカソンで徹夜しない」ということをテーマに書いたので、生産性向上や工数見積もりのテクニックなど、ハッカソン固有ではないものについては触れていません。