Eyes, JAPAN Blog > 【ハッカソン初心者必見】ハッカソンに出て気づいた三つのこと

【ハッカソン初心者必見】ハッカソンに出て気づいた三つのこと

Tetsu Kan

この記事は1年以上前に書かれたもので、内容が古い可能性がありますのでご注意ください。

code-1785541_1280
爆速Railsエンジニアの韓です。

先日はFukushima Hackathonが開催されまして、私はEyes, JAPANの社員でありながらもハッカソンのプレイヤーとして参加してきました。

実はEyes, JAPANに所属していながらも私自身ハッカソンには初参加で緊張と興奮が入り混じった感じで参加しました。

で、私は最高に優秀なアルバイトスタッフ三人と私で4人チームを組んで出場しました。

最終的には賞は残念ながら獲得はできませんでしたが、個人的には色々学ぶことは多かったです。(チームのアルバイトスタッフももし学んだことがあれば嬉しいです!)

今回はその大きく学んだ3つを取り上げたいと思います。

機能を絞る

lens-1209823_1280
ハッカソンは一泊二日でした。アイデアソンから始まり、そこからチーム分けをして、チームで話し合いながらプロトタイプを製作していくという段取りでした。
しかし、今考えてみると一泊二日で作れるような簡単なアプリケーションではなく、私たちはかなりチャレンジングなサービスを作っていました。
確かにこれはこれで学んだことはありましたが、タイムリミットを考えると機能を絞り、完成させることを目的にすればチームとしての最後の達成感は共有できたと思います。
これは普段のサービスでも言えることで自己満足での機能実装は技術力向上にはいいかもしれませんが、実際顧客に自分たちの使ってもらう際にはまずは機能を絞るべきと痛感しました。
今回のハッカソンでも最終プレゼンの際は私たちは分野をまたぎすぎる大きいプロトタイプの開発に挑戦していたので、やや内容が発散した感じは否めません。
プレゼンの聴衆にかかわらずユーザーに一言でズバッと言えるような機能をまずは作ることを学びました。

メンバーの適材適所を考える

ice-hockey-659838_1280
このハッカソンのチームの構成としては、私はRailsしか触れないので自動的にサーバーサイドを担当しました。一人のアルバイトはブロックチェーンとアプリ連携の実装、一人はアマゾンダッシュボタンの通知機能の実装、一人はクライアントサイドの担当という割り振りになりました。
このチーム配分に関しても反省はあります。というのも、しっかりと開発する前に誰がどのような担当をどこまでやるか意思統一するべきでした。
ごく当たり前のことと思われますが、私があまりにも一泊二日というタイムリミットが厳しいと思ったためにすぐ作業に取り掛かろう!という焦燥な行動を取ってしまったため特にチーム担当については軽くしか話し合いませんでした。
ましてや自分たちのメンバーはすごい恵まれたことに全員がエンジニアで全員が普段から知っているメンツであったので、しっかりと個々の能力が最大限に配置できるポジショニングをすればよかったと反省しています。
特にハッカソンではチームでやっている分、自分のやりたいことよりも自分ができることを優先して作業するものだと感じました。

自己管理能力の大切さ

alarm-clock-1193291_1280
ここが一番言いたいことなのですが、自己管理が大切だとすごく感じました。先ほどの項目にも書いたのですが、自分の中で意味不明な焦燥感に駆られて、スタートダッシュにかなりの力を使いました。
このせいで二日目はかなり体調が優れなくて、ろくに集中もできませんでした。
ここもちゃんとメンバーでスケジューリングをして、いつまでにここまで完成させようとか、ここまで完成しなかったら諦めよう、とかを話し合い、しっかりと休憩する時間をみんなが取れればよかったと今思います。
普段の生活にも通づる話ですが、健康体で長く集中して作業できる状態を維持するようにできるのは自分しかいませんので、ちゃんと計画立てて自己管理をすることを学びました。

最後に

今回のハッカソンはその時じゃないと使えないことではなく、普段の仕事や生活に活かせる学びも多くて、個人的にはいい経験になったと思います。
しかし、次何かこういうイベントがあれば、この反省を生かして、賞を獲得しに行きたいです!!

  • このエントリーをはてなブックマークに追加

Comments are closed.