ハッカソンで結成されたチームで1年間開発を継続してきた

はじめに

どうも、エンジニア志望の理系大学生NMSです。
僕が現在所属しているチームは、ハッカソンで結成されたのですが、そこから開発を継続しており、今年の3月までの1年間継続開発してきたので、振り返りつつ、記録しておこうと思い、この記事を書きました。

謝辞

僕と一緒に開発してくれたメンバーには、感謝と敬意しかありません。
自分には無理だろうと思っていた、リーダー・マネージャーに対して興味・自信を持てたのは、このチームで継続してマネジメントができたからだと思っています。本当にありがとうございました！

開発してきたアプリ

HackathonRunner - Javaler

• ユーザーの技術レベルから、ハッカソン当日と当日までにすることを提案するWebアプリ
• ハッカソンに対する不安を解消することで、ハッカソンに参加したい・参加する人たちを支援する

時系列

昨年4月 ハッカソン参加

チーム結成

サポーターズ主催の技育CAMPハッカソン(オンライン)に参加し、そこで4人1組のチームが作られました。
ここで作られたチームが、1年間開発を継続してきたチームJavalerです。
参加したハッカソンについては、過去の記事に書いているので、そちらを御覧ください。

メンバーの技術力・開発経験(当時)

当時は、チームメンバー全員が初ハッカソン&初チーム開発でした。
チームメンバーそれぞれを簡単に説明すると、こんな感じになります。

• 僕: Java(Spring Boot)でWebアプリやAndroidアプリを開発し、公開したことがある大学4年生
• Aさん: Javaはある程度書けて、セキュリティ関連の研究をしている大学院修士1年生
• Bさん: Kaggle等のコンペに参加した経験や画像識別のモデル作成経験がある大学3年生
• Cさん: HTML/CSS, JavaScript, Java がある程度書ける高専3年生

役割分担(当時)

上記を見ると分かるように、みんなすごく優秀な人たちでしたが、ハッカソンで発表するような成果物に該当するようなものを作ったことがあるのが僕だけだったため、チームリーダーは僕に任されました。

• 僕: フロントエンド、バックエンド、マネジメント(ドキュメント、タスク等)
• Aさん: バックエンド、インフラ、発表スライド作成
• Bさん: デザイン、類似判定アルゴリズムを組み込む方法の調査・検討
• Cさん: デザイン、フロントエンド

使用技術・ツール(当時)

• アプリケーション
  • フロントエンド
    • HTML/CSS
    • JavaScript
  • バックエンド
    • Java
    • Maven
    • Spring Boot
• インフラ
  • Heroku
• バージョン/ソースコード管理
  • Git, GitHub
• ツール
  • Slack(チャット、運営が提供しているワークスペース)
  • Skype(ミーティング)
  • Googleドキュメント(ドキュメント, タスク等)
  • digrams.net(クラス図)
  • Figma(ワイヤーフレーム, アプリアイコン)
  • Visual Studio Code(フロントエンド)
  • SpringToolSuite4(バックエンド)

結果&継続開発の理由

当時は、アプリの診断機能のみを実装し、結果として努力賞をいただきました。
そして、他の方々から「今回欲しかった」「すごい実用的」「これはぜひ継続開発してほしい」といった声を頂いきました。
これらのことから、チームで話し合い、このアプリは今後も開発を継続していこうというふうに決めました。

昨年5~8月上旬 使用ツールの移行

この時期のアプリや使用技術・ツールの主な変更点はこんな感じです。

• チャット・ミーティングツールをDiscordに変更
• ドキュメントやタスクの管理をGoogleドキュメントからNotionに移行
• Bootstrapを導入して、レスポンシブ対応とUI改善
• Chart.jsを用いて、診断結果にチャートでスコアを表示する機能を追加
• 投稿の作成機能、一覧表示機能を追加
• データベースにHeroku Postgresを使用

昨年8月中旬 第1回オフ会

チームが結成したハッカソンはオンライン開催だったので、この時期までメンバー同士で直接会ったことが有りませんでした。
また、各メンバーの居住地がまあまあ離れていたので(全員違う都道府県)、気軽に会うこともできませんでした。
そこで、夏休みに僕が帰省するタイミングで会わないかと提案したところ、みんな「良いですね！」と言ってくれたので、第1回オフ会が実施されました。

普段しない話が色々できて楽しかったし、やって良かったなと思いました。

昨年8下旬~9月 技育展参加

この時期にHerokuの無料プランが廃止されるという発表がありました。
しかし、「やばい、移行しなきゃ！」とは考えつつも、目前に迫っていた技育展に向けての開発に追われていました。
というのも、チームとして当面の目標が「技育展に参加し、良い結果(賞獲得など)を得ること」だったので、インフラ移行よりも、機能開発やUI改善の方が重要と判断しました。

開発期間中に実装したもの

• 投稿の詳細表示機能、検索(フィルター)機能を追加
• 同じようなレベルの人の投稿を取得するHackathonRunner-Analysis-APIを構築
  • Python
  • Django
  • Heroku
• 構築したAPIを用いた機能を追加

結果

結果としては、賞を獲得することはできませんでしたが、審査員の企業や学生の方々から下記のようなフィードバックをいただけたので、アプリをもっと良いものにしていこうという開発意欲が高まりました。

フィードバック

1. ハッカソンとかって最初の参加がすごい大変だとおもうのですが、こういう支援アプリがあり、参加を促せると多くのチャレンジを支える形になっていいですね
2. 経験に対して成長のアドバイスが出てくるのはよいですね。ハッカソンだけでなくインターンなどにも応用できそうです。
3. メンバーのアプリ開発経験がそこまでないなかしっかりと完成しており、また熱量高くこれからも開発していくという姿勢が良いと思いました。これからの機能開発および発展を楽しみにしております！
4. すごい面白い発想だと思った！ハッカソン、でてみたいけどまだ自分も出たことなくて、そんな不安を解消してくれる画期的な作品だと思った
5. 文系から技術者を目指すものとしてとても良いシステムだと思った。
6. ハッカソンで普通に欲しい！
7. ハッカソン経験なしの人にとって大変助かるアプリです。診断結果に助言もいただき、似ているユーザーも推薦してくれることがいいです。
8. ハッカソンに限らず、何かの初心者から経験者になるために踏み出す一歩は中々難しく、その自分に合う一歩についての情報を調べることも大変だと思うので、使ってみたいサービスだと思いました。
9. 今ほしいと思えるような、ユーザーが第一でつかえる機能だったから。
10. 自分自身最も使いたいと思ったら
11. まさに痒い所に手が届く的な、純粋に使ってみたいと思うようなサービスだと思うから
12. ビビッてハッカソンへ参加する勇気が出なかったけど、これで参加できそう。
13. ハッカソンに参加するのは初めての人以外も久しぶりに参加する人にもあったらいいなと思った
14. 初ハッカソンで同級生との差を感じてメンタル死んだ人なので自分と同じレベルの人を探せるしくみがあることをもっとはやく知りたかった！
15. ハッカソンで一番大きな壁を取り除けると思う
16. 自分の技術力を測れるのが良い。
17. こういうのが欲しかった！！！！
18. ハッカソン初心者のための問題設定に興味を惹かれました！！外部APIの実装に関しても技術レベルが高いなと思いました！
19. 需要があるサービスだなと感じた。これからも是非開発を続けてほしい。
20. 私も昔ハッカソン支援のアプリを作りたいと思っていたことがあるので親近感が湧きました。かなりニーズがあるアプリだと思います。
21. チーム開発の真髄といった感じでした！
22. アイデアは面白く、実際に使ってみたいともいました。
23. 機能もしっかりしているし、ちゃんと理由があって使用言語を選んでいるのが伝わってきたため
24. 自分の技術力にあったハッカソンを提案するというのは、ハッカソン参加者ならではの発想が活かされた作品だと感じた。
25. 自分が使いたいという気持ちが非常に強かったからです。技術力が不安でハッカソンの参加を悩むことが多かったのですが、この作品を過去の自分が持っていたらより勇気が出ると感じました。
26. ハッカソンに特化したアプリはあまり聞いたことがなかったので、便利だと思いました
27. 今後ハッカソンに参加してみたい人にとても役立つ情報だった。
28. 開発経験の乏しいメンバーでやり遂げたと言っていたのに完成度がとても高かったので選んだ。自分が使いたいと強く思った。
29. 自分に最適なハッカソンを選べるという発想がいいなと思った。
30. 自分達の困りごとをうまく昇華させており、課題の着眼点が素晴らしかった。たくさんのユーザに使われることで最も進化が見込まれた。
31. 自分がハッカソン参加する時に欲しかったです！悩みを種にした活用性のある作品だと思います
32. 実際にハッカソンについて同様の課題を抱えたことがあり、あったら便利だと感じたため。また、利用者が増えることによって利便性がより向上するという観点で可能性があると感じたため。
33. 技育CAMPからの成長や、その背景に合ったコンセプトが良かった。

昨年10月 JPHACKS参加

9月にエントリーした際は、JPHACKS参加時には技育展も終わっているので、HackathonRunnerはインフラ移行すれば、一段落するだろうという甘すぎる考えと、今のチームでハッカソンに参加してみたらどうなるんだろうという思いがありました。
しかし、10月上旬に参加が決まった際には、ほとんどのメンバーが学校などの予定と被り、満足な開発時間が確保できないというヤバい状況になっていました(汗)。
JPHACKSは過去に開発したプロダクトを活用するのが可能(開発期間中に作品をブラッシュアップした部分のみの評価)とのことだったので、HackathonRunnerをアップデートしていく方向に切り替えました。

開発期間中に実装したもの

とは言っても、開発時間がほとんどないという状況は変わっていないので、開発期間中に実装できたのは下記のものだけでした。

• チームメンバー募集の作成機能、一覧表示機能を追加

結果

ただ、チームメンバー募集機能のアイデア自体は悪くなかったので、自信を持って発表に挑みましたが(発表者はBさん)、結果は受賞ならずでした。
審査員や他のチームの方々からは、アプリそのものについての嬉しいコメントをいくつかいただきました。（中でも「JPHACKS(運営)に売り込めば？笑」みたいなことをおっしゃっている方が一番印象に残っています。）

昨年11~12月 インフラ移行開始

さて、技育展もJPHACKSも終わって一息つきたいところでしたが、
Herokuの無料プランが廃止されるので、急いで代替方法を調査・検討しました。

移行先

移行先の条件としては、主に以下があげられました。

• 無料プラン、無料枠があるPaaS(稼働時間や無料枠の日数制限ありも可)
• Javaのアプリ、PythonのAPI、RDBMS(MySQLかPostgreSQL)が構築できる

そして、上記の条件で調査・検討した結果、決定した移行先は、以下のとおりです。
いずれも無料枠の制限はあるものの、ある程度無料で使用できるため、制限を超えない範囲で使っていこうと考えました(アカウントを変えていく等)。

• JavaのWebアプリ(HackathonRunner): Azure App Service
• PythonのAPI(HackathonRunner-Analysis-API): Azure Functions
• RDBMS(PostgreSQL): Azure Database for PostgreSQL

アプリや使用技術・ツールの主な変更点

• ナビゲーションバーのUI改善
• 投稿一覧画面とチームメンバー募集一覧画面の追加
• ホーム画面のUI改善(投稿一覧画面とチームメンバー募集一覧をそれぞれ一部表示に変更)
• postテーブルのテーブル定義変更
• WebアプリをAzure App Serviceに移行
• データベースをAzure Database for PostgreSQLに移行

今年1月上旬 第2回オフ会

主に、技育展とJPHACKSのお疲れ様でした会という位置づけで、第2回オフ会を行いました。
ここで、各イベントの参加賞である賞金やノベルティグッズを共有しました。
また、初めてミーティングと開発作業を対面で一緒にやりました。
PCの画面を見せ合うのが、オンラインよりめんどくさかったですが、面白かったです。

今年1月中旬~3月 インフラ移行完了

この時期にようやくインフラの移行が完了しました。
アプリや使用技術・ツールの主な変更点はこんな感じです。

• 診断機能における質問項目・診断結果の文言改善
• 投稿フォーム画面のUI改善
• APIをAzure Functionsに移行

チーム開発終了

この4月からメンバーみんな学年が上がるので、就職活動や進学などで今よりも確実に忙しくなってしまいます。
そこで、残念ではありますが、今年の3月をもってチームJavalerによる開発は終了しようということになりました。
改めてにはなりますが、チームメンバーには心から感謝したいです。本当にありがとうございました。

やってみて良かったこと

毎週ミーティング

オンラインでしかコミュニケーションをとることができないので、できるだけ話し合う時間を取りたいと考え、私たちのチームは毎週ミーティングを行ってきました。
もちろん毎回全員が参加できるわけではないですが、基本的には3人以上でミーティングを行いました。
また、誰かが不参加の場合でも、議事録を作成しているので、それを見てもらうことで内容を把握してもらうようにしていました。
ミーティングの内容としては進捗報告がメインで、他には機能の仕様やデザインについて等の議論、困っていること・つまっているところの相談を行うといったものでした。

ブランチ運用・命名ルールの作成

最初はGitHub Flowを採用していましたが、GitHub Actionsによる自動デプロイを実装していく中で、自動デプロイされるmainブランチが、最新コードでもあるのはまずいという状況になりました。
加えて、featureブランチの命名がバラけていて、ブランチ名を見ても分かりにくいという事態になっていました。
そこで、独自のブランチ運用・命名ルールを(Git Flowを参考に)作成し、それに従って開発を行っていくようにしてもらいました。
ルールの改良も行っていますが、やって良かったなと思います。

あとがき

最後までご覧いただきありがとうございました。
少しでも良いと感じていただけましたらいいねしていただけますと幸いです。