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

# はじめに

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

先日、2024年9月21日(土)-22日(日)で開催された [QiitaHackathon 2024](https://qiita.com/official-campaigns/hackathon/2024) 予選に参加した、レポート記事になります。

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

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



# 今回作成したサービス

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

![Qiitaハッカソン2024_akanai_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/47006178-6b0f-46f7-6acc-871887ef83da.png)

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

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

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

![Qiitaハッカソン2024_akanai_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/6ad942d3-0a40-73e5-b2f8-f53aa3a5a0f9.png)



# 技術構成

![Qiitaハッカソン2024_akanai_3](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/9a17c8ae-60f4-ddf3-e21b-45f2e4a820f3.png)

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


<!-- 判定ロジックに機械学習を使っていれば追記する -->


# 今回のハッカソンについて

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

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

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



# サービスを開発するにあたってのポイント

今回作成したサービスでの開発における重要なポイントは以下の3つになります。
1. スマホが表になったことを検知する
2. スマホが表になったことを別の端末に伝える
3. 表になった端末を検知したら音を鳴らす

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

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


## 1. スマホが表になったことを検知する

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

![Qiitaハッカソン2024_akanai_4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/8c15603e-4b7f-231f-a34d-ef8ca0cc34dc.png)


## 2. スマホが表になったことを別の端末に伝える

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

![Qiitaハッカソン2024_akanai_5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/c5490674-a2b5-d14a-c4db-02a028846aa6.png)


## 3. 表になった端末を検知したら音を鳴らす

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

![Qiitaハッカソン2024_akanai_6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3897727/8c6d7b99-0e54-5709-a638-2cdb0522ee4c.png)


## 過去の経験を活かすことの何が良かったか

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

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

- 実現可能なセンサーについて調査する
- 対象の値を利用可能なAPI・フレームワークを調査する
- API・フレームワークのドキュメントをみて実装する

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

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


# 次の開発に向けて考えていること

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

その理由の一つが、「過去の資材がハッカソン用の汚いコードだった」ことです。
具体的には
- 必要なものと不必要なものを切り分ける
- 数年前のバージョンが指定されていたので、最新のバージョンにアップデートする
- 汎用性のない実装になっていたため、Socket.IOを使った非同期処理の実装はある程度作り直し

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

そのため、例えば
- 加速度センサーであれば使いやすいようにカスタムフックにする
- Socket.IOを使った非同期処理の実装であればサーバは使い回しでも動くように調整する

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



# 終わりに

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

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