はじめに
こんにちは！神奈川県の大学に通っている mayukorin と申します．本日は，今年の夏に参加した Treasure というインターンのことについて書きたいと思います！Treasure については他にも様々な方が記事にしているのでぜひ見てみてください！
- Treasure2022に参加してきた
- Treasure2022に参加
- 「Treasure2022」企画への意気込みと概要について
- 過去最大規模のTreasureへ！インターン裏側奮闘記
- Treasure 2022で学生にFBしたこと
- Treasure2022参加記
- Treasure2022(CARTA HOLDINGSサマーインターン)に参加してきた
この記事で伝えたいこと
この記事で私が伝えたいことは以下の通りです．
- Treasure はどんなインターンなのか
- Treasure で開発したアプリについて
- Treasure 期間中どのように実装したか
- その後の継続開発でどのように改善したか
Treasure はどんなインターンなのか
株式会社 CARTA HOLDINGS さんが毎年夏に開催している，学生向けのインターンシップです．全部で3週間あり，最初の1週間ほどでバックエンド・フロントエンドなどの講義が行われます．そして残りの2週間ほどでチーム開発を行います．インターン全体の流れについては，同じチームだったけいちゃんの記事で詳しく書かれているのでぜひ見てみてください！
参加した感想
3週間全日程とても楽しかったです！大変なことも沢山あったのですが，とても充実していました！私はプログラミングを始めて2年半ほど経つのですが，私のプログラミング人生史上，ここまでの充実感を味わったのは Treasure 以外にありません！笑 それくらい自分の今ある力を全力で出せて楽しめたインターンだったなと思います！
なぜ楽しめたか
Treasure をなぜ楽しめたのか，要因は色々あると思うのですが，自分が思うに以下のような感じかなと思います！
- 開発するアプリをチームで一から決めるので，当事者意識をもって開発できる
- 前半の講義で学んだことを後半のチーム開発で活かすことができる
- サポートしてくださるメンターさんがとても頼りになり，挫折せず取り組むことができる
- 日報に対するコメントやTreasure期間中頻繁に行われる面談を通じて，自分自身のFBを沢山していただけるので，自分に今できていてこれからすべきことは何かなどが明確になりモチベーションが上がる
- Treasure 自体の雰囲気がとても明るく，開発で行き詰まっていても頑張ろうという前向きな気分になれる
これを見ていいなと思ってくださった学生さんは，是非来年の Treasure に応募してみてください！
Treasure で開発したアプリについて
私たちのチームは，筋トレをしたい人同士がリアルタイムでマッチングして，オンラインで一緒に筋トレできるサービス『Matchong』を開発しました．
なぜこのアプリを作ろうと思ったか
チームでどんなアプリを作ろうか考えていたときに，コロナ渦で運動する機会が減ってしまったという人多いよね.. という話になりました．そのような人が抱える課題として，「筋トレしたいけどジムだと高い，ジムに行くのが面倒な時もある，そもそもコロナでジムに行くのが不安，でも家で一人で筋トレするのはモチベーションが続かない」ということがありそうだよねと推測しました．そこで，自分の好きな時にオンラインで一緒に筋トレをする人がいれば，家での筋トレのモチベーションも保てるのではないかという話になり，『Matchong』を開発することに決めました！
『Matchong』の使い方
-
筋トレのメニューを選択する
-
あとは待つだけ
-
マッチョングした人と楽しく筋トレをしましょう！！
Treasure 期間中どのように実装したか
インターン中の開発期間は約5日間でした．どのように実装していったか，私が担当したところを中心に説明していきたいと思います．ここら辺の話は，同じチームだったえびくんの記事でも話しているので是非読んでみてください！なお，言語はGoとReactを使っています．
1日目
1日目は，『Matchong』の要であるマッチング部分のフローを設計しました．紆余曲折あり，以下のような設計方針になりました．
設計を決めるにあたり一番考えたのは，APIからフロントにマッチングしたことをどう伝えるか という部分です．チームで話し合った結果，以下3つの選択肢が出てきました．
- マッチングリクエストのタイムアウト時間をとても長くし，マッチングしたらAPIからフロントにレスポンスで返す
- フロントからAPIへ定期的にマッチングしたかどうかアクセスする
- マッチングリクエストの直前に WebSocketを開通し，フロントとAPI間で双方向通信を可能とする．マッチングしたら，APIからフロントにWebSocketを介して送る．
それぞれのメリット・デメリットは以下のような感じでした．
| 実装方法 | マッチングしたことを確実に伝えられるか | 同期性 | 実装コスト |
|---|---|---|---|
| 1 | △ | ○ | ○ |
| 2 | ○ | △ | △ |
| 3 | ○ | ○ | × |
これらを考慮し，私たちは3番の WebSocket を使った方法に挑戦してみることにしました！
WebSocket はチームのメンバーの誰も使ったことがありませんでした．しかもあと4日間しか残されていません．本当にこれで大丈夫なのか...少し不安がよぎりましたが，サポーターの方の 後は実装するだけじゃん というお言葉に背中を押され，今できることを全て全力でやろう！と決めて取り掛かることにしました！まず最低限として，このフローに該当する， 筋トレメニューを推したらマッチングできてビデオ通話を開始できる というところまで実装しきることを目標としました．
2日目
他のメンバーがAPI-Redis間のポーリング処理を実装してくれている間に，私は筋トレメニュー一覧を表示するエンドポイントの作成などを行っていました．
3日目
3日目は，私は WebSocket 周りの実装に取り掛かりました．以下のフロー図で説明していきます．
フロント側
- 筋トレメニューをクリックします．
- React の
useEffectを用いて筋トレメニューがクリックされたら，webSocketのコネクション確立のためのリクエストをwebSocketEndpointに送ります． - webSocket のコネクションが確立されたら，マッチングリクエストを送ります．
バックエンド側
webSocketEndpoint では，リクエストしてきたユーザーの webSocket のコネクションを保持しておきます．
具体的には以下のように，ユーザーのIDをキーとした map （webSocketClients）に，コネクション情報(conn)を保持しておきます．
また，webSocketClientsの一つ一つの要素には，コネクション情報(conn)の他に，チャネル（Send）も含まれています．このチャネルは何に使うかというと，Redis をポーリングしている Go ルーチン① から，マッチングしたことをwebSocketClientsに非同期で伝えるために利用します（以下図）．
Sendからマッチングしたというメッセージを取り出したら，コネクション情報(conn)を使ってwebScketを介してフロントにマッチングしたことを知らせます．なお，このときにroomIDも伝えます．roomIDは，この後のSkyWay で同じ部屋でビデオ通話する人をまとめるための ID です．
WebSocket 周りの実装を行うにあたり工夫した点
今自分が知りたい情報を重点的に理解するようにすることです．参考になる記事はたくさんありました1が，全て完璧に理解しようとすれば，4日間でサービスを完成させることはできないと思いました．そのため，実装するにはこの情報が絶対必要という部分だけ重点的に理解することを心がけました．例えば今回の場合，「webSocketのコネクション情報(conn)を使ってフロントにマッチングしたことを知らせる」という部分が重要かつ，どのように実装するか理解が足りていなかったため，その部分だけ様々な記事を読んだり，ライブラリのソースコードを見て使い方を理解しました2．
そしてなんとか webSocket 周りの実装を完了させることができました！
4日目
webSocket 周りの実装終わったし，後は本番環境で確認するだけだと思っていたのですが，なんとメンターさんから衝撃の一言が..
「このままだと本番では動かないかも 」
本番環境では複数のAPIサーバーを使っていました．そのため，現状の実装方法だとマッチングしたという情報を複数のサーバー間で共有できないため，マッチングしたのにAPIから伝えられないユーザーが出てきてしまうということです．．
この問題を解決するために，Redisのpub/subを使ってマッチングしたという情報を複数APIサーバー間で共有 することにしました．
普段，複数サーバーが動いている環境で開発をしたことがないので，このような問題が起こるということに全く気づきませんでした．実際に起きる前からその可能性に気付かれていたメンターさんは本当に凄いなと思いました．
その後は，本番環境で動作確認をして終わりました！
5日目
最終日は，Skyway を使った筋トレのビデオ通話の部分を担当していました．もともとメンバーがある程度は実装してくれていたのですが，レイアウトを整えたりなどしていました．
最後はなんとコードフリーズの2分前にデプロイをしました．なんとか，1日目に決めた最低限の目標である 筋トレメニューを押したらマッチングできてビデオ通話を開始できる というところまで実装し切りました！
発表
最後に発表を行いました！発表資料はこちらです！
結果発表
私たちのチームは，この『Matchong』で アイデア賞・チャレンジ賞 をいただくことができました！とても嬉しかったです！チーム全員で喜びました！
アイデア賞をいただけた理由
「コロナ渦という現在の時流に合っていて，UNS 3に沿った開発をできていたから．その UNS が伝わったので，みんなに面白いと思ってもらえたのだと思う」というフィードバックを審査員の講師の方にいただけました！
チャレンジ賞をいただけた理由
「自分たちが知らない技術に対してやったほうが良いという強い気持ちでチャレンジして時間がない中実装しきったのが偉い」というフィードバックを審査員の講師の方にいただけました！
今後の課題
一方で，いくつか課題点もいただきました．
- ユーザー側の，『Matchong』を使い始める障壁が高い
筋トレメニューを押すといきなり知らない人とマッチングするので，使い始めるのには勇気がいるのではないかというご指摘をいただきました．その通りだなと感じました．自分たちのチームは，どちらかというとマッチョングした後にどのように筋トレをみんなで行うかという部分に注目していました．このご指摘から，サービスを始める段階ではユーザーに使ってもらいたいと思ってもらうことに注力するべき であるということを学びました． - コードのリファクタリングが必要
WebSocketやRedisのポーリング部分のコードを全て同じファイルに書いてしまいました！これでは認知負荷が上がってしまうので良くないというご指摘をいただきました．おっしゃる通りだなと思います．
チーム内のFB
結果発表が終わった後は，チームでメンバーに対して FB を送り合いました！
下の写真は私に対して皆さんがしてくださったFBです．とても嬉しかったです！
Treasure 終わってみての感想
チームみんなで未知の技術に挑戦して短期間で実装しきることができたので，大きな自信につながりました！また，私のことを信じて WebSocket を任せてくれたメンバーに本当に感謝しています。メンターの方々もつきっきりでサポートしてくださり，本当にありがたかったです．一人でも欠けてしまったら，『Matchong』を完成できなかったと思います．
なぜ未知の技術に挑戦できたか
「『Matchong』で届けたい価値は何か」という部分がチーム全員で一致していたからだと思います．時間を言い訳にして，より簡単な技術で届ける価値を妥協したくないという思いがありました．また，技術的にも精神的にも大いに頼れるメンターさんがいるという安心感が大きかったと思います．
個人的な反省
もっとメンバーにタスクの共有をするべきだった と思います．5日目にビデオ通話の画面のレイアウトを整えていました．しかし，タスクの共有が疎かになってしまっていたせいで，自分が今何をやっているのかメンバーにきちんと伝わっておらず，大きな混乱を招いてしまったということがありました．結果的にレイアウトは全部は完成せず中途半端な状態でコードフリーズになってしまいました．．最初からタスクの共有を細かくしておけば，メンバーも巻き込めてレイアウトを完成できたかもしれないと思っています．
その後の継続開発
その後の継続開発では，いただいた FB を元に改善していきました．主に以下の点に取り組みました．
- 『Matchong』を使い始める障壁を低くするようにする
いただいた FB を参考にして，筋トレメニューの中で更に「ガチ」「ビギナー」というカテゴリで分けることにしました（以下写真）．このようにレベル別で分けることで，使い始める障壁を少しでも低くできたかなと思います． - コードのリファクタリング
WebSocketやRedisのポーリング部分のコードを全て同じファイルに書いてしまっていたので，どの関数にどの処理を書くべきか，この関数はどんな関心毎があるのかなどを意識して処理を分けて，コードのリファクタリングを行いました． - デプロイ環境を，AWSからVercel・Cloud Run に移す
Treasure 期間中にデプロイしていた AWS は使えなくなってしまったので，Vercel・Cloud Run に移しました．この作業は他のメンバーがほとんどやってくれました！
継続開発で個人的に意識していた点
Treasure 期間中の反省点として，「タスクの共有をもっとメンバーにすればよかった」ということがあったので，継続開発中はIssueなどで自分のタスクの進捗状況を細かく共有することを心掛けていました．そのようにしていると，メンバーが助けてくれたりしました．
また，コードのリファクタリングをどれにすればよいか，自分では決められないと思った時はその選択肢を図式化してどれが良いと思うか，メンバーに意見を求めるなどしました．
完成！！
完成版はこちらからアクセスできます！ぜひ使ってみてください！！
最後になりますが，Treasure はとても楽しいです！青春です！学生の方はぜひ来年のTreasureに申し込んでみてください！
-
以下の記事を参考にさせていただきました．
https://selfnote.work/20210410/programming/websockets-chat-with-golang-2/
https://zenn.dev/tady/articles/adcdc65617ae57 ↩ -
以下の部分などです．
https://github.com/gorilla/websocket/blob/v1.5.0/json.go ↩ -
UNS とは，User・Needs・Solution の略です．アプリのアイデア出しの期間では，このUNSをフレームワークとして利用していました． ↩