JPHACKS 2024 Award Day完走した感想
概要
JPHACKS 2024 Award Dayは、全国8会場で同日・同時開催されたJPHACKS 2024 Hack Dayに参加したチームの中から、審査により選出された15チームが、審査委員からのフィードバックを受けて2週間の追加開発期間を経て、最終成果発表を行うイベントです。
2024年度は100チーム以上が参加していたそうで、その中からなんと私たちのチームが選ばれました！やったぁ！
というわけで、2週間の開発の中で感じたことや学んだことを書いていきます。
HackDayからのHackAwardまで
具体的な機能としては、
ポイントランキング
絵文字レコメンド
リマインド機能
これらを2日間でゼロから実装しました。
Award Dayの選出チームが発表され、その後すぐに二週間の開発が始まりました。
すぐにチーム内で集まり、今後の予定や実装方針を立てました。その中で議題に上がったのは以下の点です。
カスタム絵文字のラベル付の自動化をどうするのか
導入の簡易化
DBの再整理
ポイントの使い道
マルチプラットフォーム
そもそも、2日間での実装だったため、大規模化した際の設計や実装についてはあまり考慮できていませんでした。この課題をAward Dayまでに解消することを目指すことにしました。
また、Hack Dayにて、1年生や2年生がTypeScriptに慣れていなかったこともあり、あまり実装にコミットできなかったという問題点がありました。そのため、SupabaseのEdge Functionsではなく、Pythonを扱えるCloudflare Workersへ移植しようという案が出て、調査を行いました。
その結果、以下のような問題が判明しました。
Cloudflare WorkersのPython環境が標準ライブラリしか対応していないため、supabase-pyが使えない
パッケージがローカルでしか使用できない
動作が不安定、つまり未知数であり、突然の仕様変更に怯える必要がある
結論として、どうしても使うならAWS Lambdaという選択肢になりました。
んんん。
本来なら今後のスケーリングも考えると、ここでAWSに移行した方が良かったのですが、やはりHack Dayの成果を無駄にしたくないという気持ちが働いてしまい、結局Supabase＋Edge Functionsを使用し続けることになりました。
最初の1週間（2024/11/2(土)～2024/11/7(金)）
ここで行ったのが大規模リファクタリングです。コメント速度による順位しか想定しておらず、他の団体での利用を考慮したコードではなかったため、コードを一から見直す必要が生まれました。
見直した結果、保存する処理を全て一つのファイルに書いていたため、その機能を細分化し、別々のファイルに責務を分けました。
その上で、最初にキーワードによるポイント取得の処理を書きました。そこで一つ問題が生じました。
Edge Functionsで機能を増やすたびに環境変数が増えるの、やばくない？
その時は、Edge Functionsを追加するたびに、
〇〇EDGE_FUNCTION = "aaaaa" 〇〇EDGE_FUNCTION = "bbbbb"このように環境変数を増やしていました。
そこで、Edge Functionの環境変数を結合する関数と型を作成し、整理しました。
例として、
EDGE_FUNCTION_PATHS='{"order_points":"/addOrderPoints","keyword_points":"/addKeywordPoints"}'やったこと
一定時間内のリアクションでポイント付与
ファイル共有でポイント付与
メンションでポイント付与
各種保存処理の責務の分離
このように、ポイントに関する機能追加を中心に、コードのリファクタリングを行いました。
気合いの2週目（2024/11/9(土)～2024/11/15(金)）
この週も開発を進めました。まず、コードの責務の分離を行うとともに、ランキングポイントアプリ導入の簡易化について検討を始めました。
そこで浮かび上がった現状の問題点が以下の通りです。
Slack API関連の環境変数をenvファイルに追加している
導入の度に環境変数を設定する必要があり、他のワークスペースでの展開が複雑になる。
Slackアプリの公開について
Slackのマーケットプレイスで公開するには審査が必要で、導入が簡単になる一方でデータベースへの負荷やコストの問題が発生する。
他の環境での検証不足
現状の環境でのみ運用している場合、他のワークスペースでの動作確認が未完了。
このこともあり、Supabaseプロジェクトに複数のワークスペースのデータを保存するようにして、動的にSlackトークンとシークレットを取得し、DB上に保存する方針にしました。OSSでも良かったのですが、どの団体でも導入を簡易化したいということを考えると、この方針が良さそうでした。
💡 今考えると、残りの開発期間も踏まえてOSSのような形式で公開して、あとは自分たちで設定してくれという方針を取るべきだったのかもしれません。
そういうこともあり、DBを大幅に変更することが確定しました。
ハッカソン始まったな。
なので、そこから新規DB設計を待つ間に並行して他の作業を行うことになりました。文字を装飾するコマンドを作ったり、サーバーを立ち上げるためのserver.tsを実装したりしていました。
また、ランキングコマンドの実装においても、モーダル形式で表示した方が良いのではという案が出て、実装の検証もしていました。
DB設計が完了したのは、発表まで残り1週間となった11月10日（日）です。
それに合わせて、既存のコードを全て新しいDBに対応させるようにし、workspace_idといった新しい依存関係も増えたため、その対応に一日費やすことになりました。ただ、DBを変更したことでより機能の追加がしやすい環境になりました。
新DB対応後は、質問機能を実装したり投票機能を作成しました。これはSlackにありそうでなかった機能で、個人的に欲しかったので作成しました。
質問機能
質問を送信すると、チャンネル内の誰かが回答してくれる
投票機能
投票を作成（内容、画像、日時、投票項目を設定可能）
締め切り日時になると自動的に結果が表示される
ここから、コミュニケーション活性化という当初の目的からずれ始めた気がします（自戒）。
他にも、日中の人間が稼働している時間中にDMにBotが質問を勝手に飛ばし、回答するとそれが「ランダム質問コーナー」といったチャンネルに質問の回答が表示される機能等も作りました。
これに関しては、意外と知られていないこの人の意外な秘密が知れるという点では、今回のコミュニケーション活性化のテーマにマッチしていたと思います。
こういった機能の実装以外にも、コードの役割をより明確に分離したり、非同期処理周りの調整等を行っていました。
この週にあったこと
大学のテスト・講義
他ハッカソンのキックオフイベント
研究室の打ち合わせ
内閣府プロジェクトの北陸SIPホームページ改善
開発のアルバイト
こういったこともあり、時間が微妙に捻出できない中、いろいろ実装しました。
前日（2024/11/16(土)）
金沢から東京へは当日の朝に向かっても間に合わないため、前泊することになりました。
なので、新幹線等の移動中にもREADMEを書いたりしていました。
宿先に着くと待っていたもの、それは…
水瀬いのり
そうはならんやろ。
開発もしつつ、東京も楽しみました。
決戦の当日（2024/11/17(日)）
決戦当日深夜24:00。
何を思ったか、私は以下のことを思いました。
スレッドの自動要約機能あったら便利じゃね？
Notionの議事録要約機能もあったら便利じゃね？
深夜テンションだったことと、既存の機能ではあまり自信が持てなかったこともあり、この機能を作ることにしました。
当日に急に実装する内容としてはかなり無茶であり、コミュニケーションの活性化とはかなりずれている機能です。
この時、すでに自分の中で『ぼくの考えた最強のSlackBot』を作ろうとしていたのかもしれません。これは、本当に反省点です。
ただ、睡眠を犠牲に機能自体は実装することができました。
Notion要約機能
これは、学生プロジェクトでNotionの議事録を書く際に使用するために作りました。MTGの内容を、議事録を見るまでもなく、なんとなく把握できます。
スレッド要約機能
これは、個人的にはかなり便利な機能だと思って開発しました。スレッドが10件以上になると、AIが自動的に議事録の内容を要約して、スレッド上とチャンネル上に内容を投稿します。これは全自動なので、ユーザーが特に意識することはないです。
山本が実装したものは大体ここにあります。
完成後は、おでんを食べて仮眠しました。（すやすや）
こういった機能も提げて、いざ当日会場に向かいました（1時間仮眠）。
Hack Award(2024/11/17(日))
当日、民宿を出る際に衝撃の事実が決まりました。
山本がデモの部分を発表する
嘘だろ…。
そう思いながら、会場に向かいました。
会場は広い…。
午後からポスターセッションもあったので、その準備もしつつ本番の発表が始まりました。
周りのレベルが非常に高く、今まで参加してきたハッカソンの中でも一番だと思います。
AIが自動で音声学習して、その人の声を外国語にした上で動画にするプロダクトだったり、Three.jsを用いた折り紙のプロダクト…。
どれも同じ学生が開発しているとは思えないものばかりです。
いよいよ自分たちの番…。
さあ、本番だ…。
最初の導入は完璧でした。
しかし、デモの段階で…。
動かない…だと。
原因は、サーバーが停止していたことでした。
ハッカソンの魔物はここにも潜んでいたか。
その場では、Expoで実際に見てもらいたい、SlackBotの極致を見てもらいたいと言いましたが、内心は大焦りです。
発表後はかなり落ち込んでいましたが、なんとか切り替えてExpoに臨みました。
発表ではデモが動かなかったため、プロダクトの魅力を十分に伝え切れなかったので、なんとか挽回しようと思いました。せめてブースに来ていただいた方には、その魅力を伝えたい。そういう思いで熱弁しました。
結果発表
個人的には、あまり自信がありませんでした。本当に自分の全てを出し切れたのか、説明しきれなかった部分はないか…。
不安の中、どんどん結果が発表されていきます。
すると、聞こえました。
kz_2403 JUST DO IT
なんと、Timee様の企業賞を頂きました。
一人ひとりの時間を豊かに「はたらく」を通じて人生の可能性を広げるインフラをつくる
というビジョンにマッチしていたのが主な要因でした。
実際、自分たちもプロジェクト内の意思決定等に関する無駄な時間を減らし、コミュニケーションを活発にしたいという目的がありました。
感想
プロジェクトとして
今回のプロジェクトを通して、いくつか良かった点がありました。まず、テーマが共感しやすいものであり、問題の当事者が自分たちや他の学生組織であったことが大きかったです。そのため、取り組む意義を強く感じながら開発を進めることができました。
また、定期的なミーティングを開催し、日報を毎日全員に書いてもらうことで、進捗の確認を客観的に行うことができました。これにより、チーム全体の状況を把握し、必要なサポートや調整を迅速に行えたと思います。
さらに、レコメンド機能や保存処理全般、DB設計など、役割分担を明確にして効率的にタスクを進めることができました。それぞれの得意分野を活かしながら、チームとしての力を最大限に発揮できたのではないかと思います。
しかし、一方で反省すべき点もありました。まず、風呂敷を広げすぎてしまったことです。機能の調整や精度向上よりも、機能拡張にリソースを割きすぎて、当初の目的から逸れてしまいました。これは完全に自分の問題です。また、フィードバックに囚われ、Slackの問題点を改善する方向に比重が重くなり始めました。例えば、Slackのスレッド機能でスレッドが長いと追うのが大変だったり、投票機能が煩雑だったりといった点です。
さらに、チームメンバーそれぞれの得意技術に偏りがあり、TypeScriptをよく扱える人が2人しかいなかったため、主要機能の実装が一部の人に偏ってしまいました。これにより、チーム全体での開発効率が低下してしまったと思います。
振り返ってみると、コミュニケーション活性化が目的だったはずなのに、気づけば『僕の考えた最強のSlackBot』を作ろうとしてしまっていました。この点は大いに反省し、次に活かしたいと思います。
実装面での感想
実装面においても、いくつか良かった点がありました。まず、責務を分けたことで、他の関数でもコードを使い回しながら基本的な機能を実装することができました。一度、データ保存・表示までの流れを図で書いたことで、データの流れが理解しやすくなったのも大きなメリットでした。
また、デバッグ用のコンソール出力を書いたことで、どこでエラーが発生しているのかを把握しやすくなりました。さらに、Slack APIに慣れていくにつれて、徐々に実装スピードが上がっていったのも良かった点です。
一方で、反省すべき点も多くありました。まず、SupabaseのEdge Functionで行う処理と、Slack APIのハンドラーで行う処理の区別が曖昧だったことです。また、Denoの仕様確認が甘かったため、Axiosに対応していないことに気づかず、fetchでデータを取得する必要がありました。また、VSCodeの拡張機能周りでエディタが壊れるようになってしまいました。
さらに、緊急で機能を仕上げていった為、DBに質問等を保存せず、サーバー内のメモリでデータを保持・処理していたため、サーバーに負荷がかかってしまっていました。その結果が、デモの失敗に繋がっています。
また、生成AIの活用は非常に便利である一方、前処理をしっかり行わないと期待しない結果が出力されるため、注意が必要だと感じました。
今回の開発を通じて学んだこととして、DenoはNodeと異なる点が多いということがあります。importも環境変数の読み込みも異なり、DenoとNodeが共存している開発環境は過酷でした。また、Supabaseの型生成周りでは、Supabaseから型を自動生成できるのが便利でした。さらに、アジャイル開発では変化に強いDB設計が必要だと実感しました。
反省点としては、実装する機能に対する工数見積もりが甘かったことがあります（深夜テンションでコードを書いていた）。Renderを信用しきれず、sleepを解除する外部APIが動かなかった場合にサーバーが動かないという問題もありました。
最後になりますが
色々と問題点もありましたが、自分自身にとってとても良い経験をたくさん得ることができました。
JPHACKSは、開発もさることながら、気付きも得られる場所だと思います。
実際に作ったプロダクトを多くのプロのエンジニアの方々に客観的に評価してもらう機会は滅多にありません。
本当に良い開発イベントでした。
関係者各位に感謝を申し上げたいと思います。
