はじめに
ハッカソン…それはエンジニアのエンジニアによるお祭り…
齢30歳、20代で研いだ開発スキルと膨張した自尊心で「デキる奴」として入賞、あわよくば優勝をスマートにもぎとってしまおうと無鉄砲に突入しました。
結果……まあ、敗北を喫したわけです。
今考えると恥ずかしく黒歴史として葬ってしまいたいですが、会社の同僚から同じ失敗をする同志を増やさないようQiitaに後学として記事に残しておくことを薦められたので筆をとります。
この話を通して、同じ過ちを繰り返さないための考えと入賞するためのヒントをご紹介できればと思います。
PLATEAU Hack Challenge 2024 in Tokyo
参加したハッカソンです。
主催が国土交通省←なんかすごそう！
PLATEAUという地図データを使ったコンテンツを作成します。
事前レクチャーに当日はあらゆるジャンルに精通したメンターがいらっしゃり、フォロー体制が万全でした。
PLATEAUデータを全くわからない0の状態でも優しく教えてもらえる雰囲気でした。
初ハッカソンの自分でも安心して参加できる内容だったと思います。
実際、参加した半数以上の方がハッカソン初めてでした。
おすすめです。
ハッカソンで作成したプロダクト
見たことないGoogle Street Viewをつくろうというコンセプトで作成しました。
アート×Plateauデータを使って表現したい。
そこであえてエンジニア主導ではなくデザイナー主導でアートを活用したコンテンツをハッカソン内で実現できないかを目指しました。
触りたい方はこちらからDLできます(Win,Mac)→GithubのDLページ直リンク
今回の貴重な成功点として完成したことは良いことだと思っています。
失敗までの道筋
始まる前
大見えを切りまくりました。
上司に「入賞したら焼肉おごってくださいね。場所は…」。
同僚に「普段から地図開発をしている私の力を見せてきます」。
更に、会社のはからいで土日のハッカソンを業務として快く送り出してくれました。
当時はプレッシャーが私を強くするとか思っていた記憶…
チームづくりとテーマ
ハッカソンがはじまったら何が始まるか。
そうです、テーマ＆チーム決めです。
チームには団体枠と個人参加枠があり、個人枠の方はは即席でチームが組まれます。
(即席とはいえ、つくりたいテーマは一緒になるように運営がサポートはしてくれました)
私はというと「俺、一人でいけるっしょ？」
特に信念もなく隣の方のテーマに相乗りしました。
ハッカソン開始
開始後しばらくすると「あれ？なんか違う…？」と気付きました。
まるで知らない土地へ旅行に行き迷子になったような、そんな感覚に襲われました。
「最初の2時間で開発環境を構築して、次の3時間でプロトタイプを作って…」と計画していたものの、現実は甘くありませんでした。
気付いた時には、空は夕焼け。
計画通りに開発が進まない状況に焦る自分…。
「このアプリ、何がしたいの？」と自問自答し始めました。
そして1日目のハッカソンは終わってしまいました。
ハッカソン夜の部
未完成のアプリに震える私。始まる前に大見えをきった私。
フラッシュバックするあの時はまるで走馬灯。
徹夜で無理やり形にしようとする鉄人レースが始まりました。
持ち帰ってモクモクとアプリを形にする自分。
チームで始めた開発も夜の部は個人開発に近い形態になってしまいました。
ハッカソン最終日
アプリが完成したのは発表30分前。
急ぎで発表用資料をつくって発表です。
与えられた時間は各チーム5分のみ。
発表資料であるパワーポイントは2分だけ使用し残りの時間はつくったアプリを映そうという予定で始めましたが、発表資料が想定より内容があったため目的であるアプリを見せる時間が半分になってしまうアクシデント…
この失敗を上司に話した際のフィードバック
私の上司はハッカソンに自信のある方で入賞もしています。
その上司と相談したときのフィードバックに「そうか」と腑に落ちるキーワードを貰いました。
上司「我々入賞して、○○君入賞できなかった事についてどういった要因が考えられます？」
そこからこのキーワードです。
「事前の戦略性」
上司曰く、参加したハッカソンでは１日目終了したあと、全員で集まりなおし２日目の戦略を練り直したそうです。
部分的には、捨てて作り直したりとか大胆な方法も取ったり。
きっと1日前にも戦略をたてていたが、2日に向けて戦略を練り直したところがこの話に肝なのかなと私なりに感じています。
私への総評としては「誰と組まされるのかもわからん状況で”入賞する”は、若干無鉄砲だなと事前に思ってました」
ぐうの音も出ませんでした。
開発スキルだけを試す場ではなく、戦略性も試される場という視点が抜けていました。
この失敗から得た学び
要は正しく戦略をたてることです。
1.テーマや目的をもって参加する
やるべきことがわからないまま始まってしまうと、いろいろな障害が発生します。
- やることが定まらずに作業スピードが落ちる
- チームでの役割分担ができなかったり、得意でない領域を担当することになりチームに迷惑をかけることになる
- 何に焦点を当てて開発すればよいかわからなくなり、結果的に制作物のクオリティが下がってしまう
最初からテーマや目的がある人がたくさんいるハッカソンという環境で、始まる前から差が開いてしまうのはもったいないですよね。
2.事前準備はしよう
思い返すとイベント開催前でも準備できることがたくさんありました。
- ハッカソンの題材は決まっているため、開催前に題材の技術的な内容を調べて知っておく
- 開発ツールを決めておき、開発ツールの導入からビルドできる状態までの環境構築を済ませておく
- Githubのリポジトリをつくり、招待したらすぐにバージョン管理を行えるようにしておく
- チーム内のデータ共有用にGoogleDriveの共有フォルダを作っておく
- 事前にダウンロードできる開発データはすべてダウンロードしておく(会場のネットワークが不調になっても大丈夫にするため)
始まったらすぐ動けるようにしておくだけでも、かなりのアドバンテージを稼げると思います。
特に開発環境と開発データのダウンロード。ハッカソン当日には多くの人が同じwifiに接続する都合上、ネットワークの不具合が発生する可能性が高いと思います。
リスクを回避するうえで、ローカル環境で開発ができるようにしておくと不必要な不幸を回避できるかもしれません。
3.優先度を決め、必要なところに注力する
ハッカソンと通常の開発とで違う点として、ハッカソンの開発はプレゼンの時間に耐えれば大丈夫という点があると感じました。
私の参加したハッカソンの発表時間は5分でした。 逆に言えば、5分で発表できないものは発表できないです。
時間に合わせてコンテンツの規模を調整することで、必要な部分に集中して開発をすることができるはずです。
また、評価基準を明確に理解しないと、入賞の難易度があがります。もし、評価基準がわからない場合はハッカソン運営の方に聞けばきっと教えてくれるはずです。運が良ければ評価されやすい力の入れどころやコツが聞けるかも…
そういう意味では集めた情報を元に時間内に終わる道筋を考えることがハッカソンのスタートかもしれません。
いっそのこと、コーディングより先に発表原稿から作成するのもありだと思っています。
4.計画はあくまでけいかく。無理はしない。現実をみる
ハッカソンのタイトなスケジュール上、なるようにしからないです。
計画は何度も練り直すことができることをハッカソン当日も忘れないようにしたいです。
完璧なものをつくるのではなく、プレゼンで見せるものをつくるという視点で考えると解決できる道が見つかったりすると思います。
まとめ
いろいろと書きましたが、ハッカソンは良いイベントだと思いました。
失敗したけどこれだけ学びがあったのは凄いなーという感想です。
今後もハッカソンには参加していきたいと思います。
では、あなたは賢く戦略を立てて、ハッカソンの舞台で輝いてください！
PR
弊社ミックウェアでは、新規立ち上げの自社サービスとしてWEB3.0に向けた地図アプリの開発を一緒に行える仲間を募集しています。
エンジニアファーストな会社文化のため、土日のハッカソンに業務として快く送り出してくれる会社です。
興味をお持ちいただける方は、こちらまで！
【選べる働き方/賞与年4回】Unreal Engineを活用してデジタルツインの新サービス立ち上げを進めるエンジニアを募集