【技育CAMPハッカソン参加レポート】懸垂記録システムで努力賞を頂いた話

2025/06/25

はじめに

先日、6月10日から22日にかけてオンラインで開催されたサポーターズ主催の「技育CAMP2025 ハッカソン Vol.5」に参加してきました！

本記事では、私達が開発したプロダクトや、ハッカソンを通じて得た学びを記録として残したいと思います。

なぜ参加したのか

サポーターズのハッカソンのざっくりとした特徴は以下の通りです。

オンライン開催
ビギナー向け
特定のテーマなし
2週間弱の開発期間
年齢制限あり（25歳以下）

参加ハードルが低く、初心者や学生でも参加しやすいと思います。ただし、近年のIT分野では学生の技術力インフレが進んでおり、明らかに初心者でないチームも多く見受けられました。また、就活に向けたスキルアップや、チーム開発経験を積むために参加する人が多く、特に修士1年生の参加者が目立ちました。

かくいう私も、研究室のメンバーと一緒に「チーム開発の経験を積む」ことを目的に参加しました。

開発したプロダクト：「懸垂王」

私達のチームは「懸垂記録システム」を開発しました。その名も「懸垂王」です。

実際に動作している様子は以下の動画でご覧いただけます。

物体検出を用いてリアルタイムに懸垂をカウントする様子

懸垂回数を可視化するダッシュボード

課題と解決案

開発メンバーの多くが「肩こり」に悩んでおり、その対策として「懸垂マシン」を導入しました。これで万事解決と思いきや、重大な問題が発生しました。それは、継続するのが非常に難しいということです。

そこで、懸垂回数を可視化することでモチベーションの向上を図ることにしました。さらに、継続する上で如何にユーザの負担を減らすかを考え、物体認識技術を用いて懸垂回数を自動でカウントするシステムを開発しました。

主な機能

モチベーションを高めるダッシュボード

日々の懸垂回数や過去のデータとの比較をグラフで可視化
物体認識による懸垂回数の自動カウント

Raspberry Piに接続したカメラでユーザーの動きを捉え、YOLOが懸垂回数を自動でカウント

開発チームと技術スタック

研究室メンバー4人で参加しました。それぞれの得意分野を活かして、以下の役割分担で開発を進めました。

フロントエンド (2名): Next.js
インフラ (私): PostgreSQL, Ubuntu Server, Docker
AI/ハードウェア (1名): Python, Raspberry Pi

最終的なシステム構成は以下のようになりました。

初めてのインフラで苦労したこと

今回は研究室内での利用を想定して、サーバやDBを研究室で運用することにしました。そのため、Ubuntu Serverの構築や、Docker Composeを用いたコンテナ化、ルータの設定など、インフラ周りの作業に触れる事ができました。初めての挑戦の中での苦労や学びを記録として残します。

ルーター設定ミスでネットワークダウン

研究室ではYAMAHAのRTXルータを使用しており、DHCPやNATの設定をCLIで行う必要がありました。その中で、NATの設定を誤ってしまい、研究室のネットワークが一時的に使用不能になるというインシデントを起こしてしまいました。具体的には、WAN側に設定するはずのディスクリプタをLAN側に設定してしまい、外部との通信ができなくなってしまいました。

幸いsaveコマンドを実行する前だったので、再起動することで事なきを得ました。今後は、saveコマンドを実行する前に、動作確認を徹底することを心がけます。

複雑なSQLとの格闘

フロントエンド側の負担を少しでも下げるために、PostgreSQLのVIEW機能を活用することにしました。しかし、時系列データを生成する段階で、想定以上に時間を取られてしまいました。始めは、ログデータをそのまま集計するだけで済むと考えていましたが、これでは歯抜けのデータを生成してしまい、ダッシュボードの表示に支障をきたすことが分かりました。そこで、LEFT JOINとgenerate_seriesを駆使した複雑なSQLを書く必要がありました。この経験を通じて、バックエンドの責務としてデータを扱いやすい形に整えることの難しさを痛感しました。

結果と学び

最終的に、私たちのチームは「努力賞」をいただくことができました！目標としていた優秀賞には届きませんでしたが、チームの頑張りが形として認められたことは、素直に嬉しかったです。

このハッカソンを通じて、技術的な成長はもちろん、チーム開発における重要な学びを得ることができました。

チーム開発における「統一」の重要性

開発が進むにつれて、チーム内での微妙な"ズレ"が大きな影響を与えることを実感しました。

コーディング規則やディレクトリ構成のばらつき
API設計における理解の違い
データベースのスキーマ設計の不一致

これらが原因で、予期せぬコンフリクトや手戻りが発生し、開発の遅れに繋がりました。開発を始める前に、細かいルールまでしっかりと合意形成しておくことが、いかに重要かを学びました。

今回、システムの中心となるサーバーやDBを担当したことで、プロジェクト初期段階での詳細な設計が、後工程にどれだけ影響を与えるかを身をもって知りました。曖昧な部分を残しておくと、後の工程で首を絞めることになりかねません。この経験は、今後の開発において必ず活きてくると思います。

【余談】デバッグのたびに筋トレ

私達が題材にしたものが「懸垂」であったため、カウント機能のデバッグを行うには実際に懸垂をする必要がありました。バグが出るたびに筋トレ、という肉体的にもハードな開発でした💪。

今後の展望とまとめ

今後は、

QRコードを用いた位置補正機能
目標達成時のSlack通知機能

などを追加し、さらに実用的なシステムにしていきたいと考えています。作ったきりで終わらせるのではなく、実際に研究室で使ってもらい、フィードバックを得ながら改善を続けていく予定です。

今回のハッカソンは、技術的な挑戦とチーム開発のリアルな難しさ、そしてそれを乗り越える楽しさを凝縮したような、非常に密度の濃い2週間でした。

これからハッカソンに参加する方へ

コードを書き始める前に、チームで「設計」と「ルール」について徹底的に話し合う時間を作りましょう！

この記事が、これからハッカソンに挑戦する方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました！

おまけ：ハッカソン後の打ち上げ

ハッカソン終了後はピザを食べました！