過去の経験を活かして効率よく(?) 開発を進めたハッカソンの話

Posted at 2024-10-05

はじめに

こんにちは！
大学時代の同期メンバーでよくハッカソンに参加しているチーム「サトリラボ」と申します。

先日、2024年9月21日(土)-22日(日)で開催された QiitaHackathon 2024 予選に参加した、レポート記事になります。

今回のハッカソンでは 今まで参加してきた過去ハッカソンの資産 にかなり助けられました。
ちゃんと残しておいてよかった！！

本記事では、過去の経験がどのように役立ったかを記していきます！

予選のテーマは「オープン」。
このテーマに対して私達はスマホを開かせないアプリ「akanai」を作成しました。

気を散らせないためにスマホをロックするアプリはすでに様々ありますが、そのどれもが結局自分が妥協してしまうとスマホを触れてしまうという構造的な課題を抱えています。

もちろん全くスマホを触れなくなると緊急時に困るので仕方ない部分はありますが、これでは心の弱い自分達はついついスマホを弄ってしまう…

そこで、本アプリでは誰かがスマホを開いたら、チームみんなのスマホから音がなり、あえて迷惑がかかるようにようにしました。自己責任ではなくチームみんなのために…という気持ちでスマホを開かせないようにする点がポイントです。

ネイティブアプリの開発にはExpoを、非同期通信にはSocket.IOを利用しています。

今回のハッカソンでは「オープン」というなかなか広いテーマでした。
ハッカソンには慣れていたのですが、今回は思うように考えがまとまらずプロダクトのコンセプトが決まるまでにかなり時間がかかってしまいました。

最終的には「オープンさせない = 開かせない」がなかなかおもしろいのでは？という結論に至り、スマホを開かせないようにするサービスの開発が決定したのですが、いつもより開発時間が大幅に短くなってしまいました…

しかし！ ここから過去の経験を活かして一気に巻き返し、なんとか決勝に進むことができました！

今回作成したサービスでの開発における重要なポイントは以下の3つになります。

より具体的には、デバイスのセンサーを使ってスマホの表裏を検知し、かつリアルタイムでほかの端末に値を送信する必要があり、なかなか骨の折れる実装です。

いったいどうしたものかと悩んでいたところ、過去のハッカソンのコードを残していたこと が救いの手となりました。
「普段の開発で使えるといいよね〜」という淡い期待から、過去の資産をすべて共同のGitHub Organizationに保存していたのです。

以前参加していたハッカソンで「スマホのオモテウラで、声をかけていいかどうかのステータスをみんなに公開する」という機能を加速度センサーを利用して作成したことがあり、少し修正して解決！

上記と同じサービスでSocket.IOを使ってリアルタイム通信を行う実装があったため、今回のサービス向けに調整し解決！

更に別のハッカソンで「リモートで乾杯をする」というサービスを開発したことがあり、「乾杯音」を鳴らす実装も行っていたためそのまま流用、こちらも解決！

今回の方法で良かったポイントは、開発したいものと近い実装を過去に偶然行っていたことです。
これによって、技術選定の時間を大幅に減らすことができました。

例えば、今回の必須機能である「スマホが表になったことの検知」の実装も、情報がなければ

といった流れで開発することになりますが、やり方が分かっているので調査の必要がなく、「本当にこの方法でうまくいくのだろうか？」と悩む必要もありません。

実装しているコードがどのように動くのかもある程度わかっているので、設計ミスによる出戻りや思わぬ落とし穴にハマらなかったところも良かったかと思います。

実のところ、以前の実装を流用した割には事前に想定していたよりも時間がかかってしまいました。

その理由の一つが、「過去の資材がハッカソン用の汚いコードだった」ことです。
具体的には

といった作業が発生してしまいました。

そのため、例えば

といったように、うまく実装できた箇所は切り分けて再利用可能な状態で保管しておくことで、より扱いやすく・より汎用的に使えそうです。
次回以降のハッカソンではなにか新しい発見や実装をした際はなるべく体系化して整理するクセをつけたいところです。

「普段から作ったものをきちんと整理して保管しておき、再利用可能な状態にしておくこと」の大切さを改めて学んだハッカソンとなりました。

皆さんも、もしハッカソンに参加する機会があれば「うまくいったところはなにか・今後使えそうな実装がどこか」を振り返ってみてはいかがでしょうか！