はじめてのハッカソン体験記
先日、はじめてハッカソンに参加しました。
Akindoさんが主催する東京web3ハッカソンのNFTセクションに、チームメンバー3人と4人構成での挑戦となります。
ハッカソンとは何か
参加してみて自分なりに感じたことですが、ハッカソンとは「限られた短期間でチームメンバーと困難に立ち向かうイベント」です。
これまで本格的な開発というものを上記条件でやったことがなかったので、非常にたくさんの学びを得ることが出来ました。
個人開発との大きな違い
これらは、一人で少しずつ進める個人開発とは一味違った経験になります。
限られた短期間：〆切が設定されている。
チームメンバー：意思疎通をしながら進める必要がある。
困難に立ち向かう：これは同じかもですね…笑
今回はそんなハッカソンで得られた学びを、これからハッカソンに参加しようかな？と考えている方々に少しでも役に立てばと思いこちらに書き残しておきます。
ハッカソンから得られた学び
〆切が本気にさせてくれる
まず一番最初に感じたことは、期日が設定されているとこんなにも人は集中力を高められるのか…ということでした。
今回のハッカソンは3週間。とはいえ最初の1週間はメンバー集めと顔合わせに時間を取られていたので、実際にコーディングは2週間弱（12日間）となりました。
限られた時間の中で何をどこまで作り込むか。スケジュール、タスク管理はもちろん、他のメンバーとの役割分担と進捗確認、詰まったらdiscordの通話で共有…。
まるで高校の文化祭準備(※)のような高揚感が、そこにはありました。
(※) 筆者は文化祭の準備を真面目にしてきませんでした。妹や弟の文化祭に参加したときにクオリティの凄さに驚嘆し、もっと青春を楽しめばよかったと後悔しています。
特に最後の二日間の集中力は、これまでのコーディング経験の中で最高レベルだったと思います。
時計の針が5個進むたびに「終了まであと〇〇分…ここの実装は諦めよう」「この仕組みを成立させるには、あの記述が必要だから、ここを調べて…」というように、1寸を惜しんで開発を進めることができたのは、とても大きな収穫でした。(※)
(※) 夏休みの宿題は7月中に終わらせる派だったので、〆切に追われる経験は人生の中でも希少な体験です。あ、大学受験で前日まで数学の過去問で大問の解き方が全然わからず絶望したときは追い込まれてましたね。
チームメンバーがとにかく心強い
今回のチーム構成ですが、バランスが絶妙だったと思います。
自分（一般人）：ファシリ、フロントエンド
Cさん（エンジニア）：バックエンド（コントラクト）
Sさん（デザイナー）：デザイン（figma）、スタイル（CSS）の実装
Tさん（PdM）：企画構成、提出資料の作成、デモ動画収録
4人中3人がコーディングできたのも、すごく有り難かった。
ハッカソンではスライドを成果物として提出するビジネスコンテストとは違い、
リポジトリ
ReadMe
デモ動画
を提出する必要があります。
そのため、とにかくコードを書かなければ提出物が出来上がらないのです。
これまで自分はWordPressのテーマファイル作成などでは一部共同作業で進めた経験はありましたが、本格的にチームを組んで一つの成果物をゼロから組み立てるのは初めてでした。
最初、一人で開発するよりも気を遣いながら進めるのは大変なのでは…？と思っていたのですが、それは杞憂でした。
それよりも、自分が進めているところ以外がどんどん進んで行くのが非常に爽快感でした。
developブランチをpullするたびに、プロダクトの完成度が高まっている
functionを呼んだだけなのに、データが取得されている（本当に感動）
いつもならおざなりにしていたデザインのレベルが段違い
トラブル原因を一緒に考えられるので、解決までの時間が早い
もう、すごい。
ただそれだけです。仲間っていいなと思いました。
（トラブル対応の時は本当にありがとうございました。）
5時間くらい詰まってた問題が解決がされた時の喜び。
— Keito | Papageno | Mentalhealth × Art × web3 (@k8keito) November 5, 2022
困難が人を成長させる
ハッカソン、もといコーディングの醍醐味といえば、謎のエラーとの戦いといえます。
何度叩いても出てくるあのエラーメッセージ。取得されないデータ。手掛かりが見つからずに過ぎゆく時間。
絶望しかありませんが、無事解決したときの解放感が、やめられない理由ですね。
今回も多分に漏れず、我慢の時間帯は最長5時間超に及びました。
とはいえ、それでいいのです。
トラブル対応をすると、問題解決力は明らかに向上するからです。
たとえエラーメッセージを読んだだけで解決しなかったとしても、
エラー前後で変更した箇所の比較
エラーメッセージで検索した記事/フォーラムから推定される問題の特定
類似する過去事例を検索するためのキーワード掘り起こし
というように、エラーに対する忍耐と特定力こそが、問題解決力の土壌づくりには必須なのですよね。
トラブルから学ぶ、財産は多い。
というのが改めてですが、今回の学びとして一番大きかったです。
トラブルから学ぶ、財産は多い。
— Keito | Papageno | Mentalhealth × Art × web3 (@k8keito) November 5, 2022
ハッカソン、やってよかったこと
プロダクトへの思いが、最高の仲間との出会いになる。
今回は仲間集めから始まったわけですが、本当にチームメンバーに恵まれました。
エンジニアのCさん：discordの募集掲示板をみてDMをくれた
デザイナーのSさん：twitterの投稿をみて連絡してくれた
開発の核となった二人は、いずれも当初想定もしていないところから連絡をくれました。そしてメンバー募集のために書いたnotionを読んで、「こんな物を作りたい」という思いを汲み取ってアイデアを出してくれたのです。
いいものを作ろうという思いが共通理解としてあったので、コミュニケーションも非常にスムーズに取ることが出来ました。すべてオンラインのやり取り出会ったのにも関わらず、です。
なので、ハッカソンで仲間を集めるところから始めるのであれば
なぜそのプロダクトを作りたいのか
誰の役に立つのか
社会にどんなインパクトを与えるのか
少し大げさなようでも、自分の思いをストレートに伝えることで、プロダクトに共感してくれる、とても素敵なメンバーに出会えるのではないかと思います。
ハッカソンに求めることについて、共通認識を持つ。
これはハッカソンのキックオフイベントでメンターの方がおっしゃっていたのですが、「甲子園を目指すのか、草野球で楽しくやるのか、共通認識を持っておいた方が良い」そうです。
開発にかけられる時間は限られているので、その中でどのクオリティを目指すのか、共通認識があることでズレがなくなるということなのでしょう。
今回はチームキックオフで、ハッカソンに求めることをメンバーに聞いてみいました。その結果出てきたのが以下です。
スキルの向上
solidityエンジニアとしての経験
メンターからの知見
短期間で成果物をつくる経験
手触り感のあるプロダクトづくり
web3でのつながり
別チームの人も含めて
「あ、それ確かに」と思える部分が出てきて、これを目指そうという部分が明確になったことで、気兼ねなく依頼をしたり、議論を交わしたりできるようになりました。
もう一回ハッカソンに出るなら…
枝葉の部分は全部切り落とせ、本当に最小限で良いから！
まず今回の反省点としては、プロダクトとして一番重要な機能が未完成のまま提出せざるを得なくなってしまったことです。
正直なところ2週間前にプロダクト計画を立てた時に、「これ本当に終わるのか…？」と思ってはいたのですが、もっと最小限からスタートするべきだったと思いました。
よくMVP！MVP！(※)という言葉を耳にしますが、そのMVPは本当に最小限なのか、よく考えたほうがいいと思います。
機能としては2つだけ、「表示」と「アクション」だけあればいい。
転職サイト：募集の表示とエントリ機能
ECサイト：商品の表示と購入機能
ブログ投稿：ブログの表示と投稿機能
絞り込み機能とか、お気に入り機能とか、そういうのは後で作ればいいんです。とにかく一度完成させて、そこから機能追加をしたほうが、精神衛生上よろしいですね。
如何に「MVP」としてシンプルに完成させるか、こだわっていきたいものです。
(※) MVP（Minimum Viable Product） = 実用最小限の製品のこと。エンゼルス大谷翔平のことではありません。
緊急Mission：機能とタスクを整理せよ。
続いて似たような話になりますが、優先度が本当に重要です。
プロダクトが成立するためにやるべきことは後いくつあるのか。
Must：無いとプロダクトが成立しない機能
Better：あるとプロダクトのクオリティが格段に上がる機能
Best：理想に仕上げるなら必要な機能
作成する機能は優先度を3つくらいに分けて、タスク化しておくべきです。
ちゃんと機能（function）はすべて羅列しておきましょう。
コミットの粒度と具体性が、エラー特定の鍵となる。
今回最大の同一エラー格闘5時間の原因は、呼び出すファイルが変わっていたことでした。
初めてフロントエンドとバックエンドを切り分けて作業していたことで、一人なら気づけたかもしれない変化に気づけなかったということですね。
その時の反省として、自分のコミットが大量に細かく切り分け過ぎていて、バックエンドのCさんによる重要なコミットを見落としてしまったことがあげられます。
このコミットは何の機能を追加したのか
どのタスクと対応しているのか
複数の機能追加が混ざっていないか
もしかしたら基本的なことなのかもしれませんが、githubのコミット一つとっても学びが多かったです。
一人で開発するときは
コミット名は適当で
コミットメッセージはなし、
複数機能を一緒にコミットしちゃったときも気にせずpush
がまかり通っていたのが、後から見返すと「？？？」となり、コミット解読に時間を取られてしまう原因となっていました。
基本を確実にこなすことが、急がば回れにつながるのですね。
最終日は予備日。スケジュール予定に入れてはいけない。
結局、最後のdevelopからmainへのプルリクをmergeしたのは最終日の23:59でした。納得いかないところも多数抱えながら、泣く泣くのmergeとなったのが、心残りです。
今振り返ると、機能全般はもっと早い段階で完成させておくべきでした。
焦るとミスも増えますし、提出が1分遅れてレビューすらしてもらえない、という最悪の事態すら考えられます。
それを避けるためにも、時間にはゆとりをもって開発に取り組むべきです。
最終日は
軽微な不具合修正
デザインのブラッシュアップ
機能のテスト
にとどめておくべきです。
最終日がなくても提出できるレベルにしておくことが、重要ですね。
またハッカソンに出たい！
終わりになりますが、今後もどんどんハッカソン参加の機会があれば出ていきたいと思いました。
個人的な成長ポイント
理解が深まった
useState / useEffect
hardhatのコントラクトとabi
props
アロー関数
next.jsのコンポーネント
valueとonChange
新しく使い方を学んだ
<Link>のasとhref
useRouter
e.target.value
{`xxx`}
エラー対応を覚えた
`execution reverted`
などなど、です。
意外と基本的なところがあまり理解出来てなかったんだな、と振り返れば思いますが、何事も基本が肝心。
Solidity側のエラーについてはほとんど瞬時に特定できてたので、「おお！自分いつの間にか成長してる！」と内心喜びながらエラー修正できてました。
コーディング、前に進んでいる感じがあるのが醍醐味ですよね。
ハッカソンで得たもの
機能 / タスク管理の重要性
スケジュール管理の重要性
エラー耐性と対応力
コミット管理の重要性
開発力の向上
最高のチームメンバー
あまりにも多くの財産を得ることができました。
終わりに
この記事を読んでハッカソンに出たいと思った、そこのあなた。
ぜひ、次は一緒にやりましょう。
一緒じゃなかったとしても、情報交換していきましょう。
Dev界隈の好きなところは、情報交換がOpenな文化です。
qiita, zenn, etc…惜しげもなくノウハウがいたる所に蓄積されているのは、マーケティングをずっとやってきた自分からすると感動の連続でした。
自分も、もっと皆さんの役に立てるように発信していきたいと思いますので、今後もどうぞよろしくお願いいたします。
この記事が気に入ったらサポートをしてみませんか？