自社開発アプリケーション、進化の軌跡

@motoi_dev
はじめに
こんにちは!motoi です。年の瀬に迫り、今年を少し振り返りたく。今年、dev チームにとって大きなトピックの 1 つとして、自社開発アプリケーションであるパートナーズシップのメジャーアップデートを行いました。今回はそのことについて少し話したいと思います。
弊社プラスクラス・スポーツ・インキュベーション(以下 PSI)がすべて自社で開発を行った、スポーツクラブ様向けのプラットフォームサービスです。興味のある方はこちらを御覧ください!
自社開発アプリのメジャーアップデート
パートナーズシップは2021 年 5 月に初版がリリースされました。これを v1 とし、そこから v2、そして現在 v3 の開発が進行中です。それぞれについて、技術スタックを紹介しつつ、なぜそのメジャーアップデートを行ったのについて話をします。
v1
ざっと概要です。
-
開発期間
- 2020 年 10 月〜2021 年 5 月の約 8 ヶ月(デザインや仕様作成含めて)
-
リード開発者
- 2 人 (1 人、マークアップ中心にフロントエンドの最上層を担当、もう 1 人、バックエンドも含めてフロントエンドの下層部分を担当)
-
主な技術スタック
- Nuxt 2.0 (フレームワーク)
- TypeScript (使用言語)
- Firebase Hosting (ホスティング)
- Github Actions (CI)
- Firebase Authentication (認証)
- Cloud Functions for Firebase (バックエンド)
- Vuetify (デザインフレームワーク)
2020 年 4 月に発足したばかりだったので、最もとっつきやすいという理由だけで Vue 系の Nuxt を採用しました。そして上記のように、基本的にはすべて Firebase のサービスを採用しました。そしてちょうど 2020 年の秋頃だったか、GitHub と Firebase のインテグレーションが強化されたので、そのままそれを採用し、GitHub Actions でビルドしたものが自動的に Firebase Hosting を使ってホスティングされる形にしました。まだチームでの開発経験に乏しかった当時、PR 作成毎にプレビュー URL が作成されたときには、その便利さに 2 人して感動したのを覚えています笑。
正直今コードを見ると、リファクタリングしたい箇所が山程…。しかし、2 人しかいなかった dev チームだったので、よくリリースまで持っていけたと思います笑。
v2
さて、どんどんパートナーズシップの機能開発をしていく上で、以下の問題が徐々に出てきました。
- リファクタリングすべき箇所が多すぎて、新機能の開発毎に大きな負債を抱えていく一方だった
- 2 人が完全に役割分担をしていたので、特にバックエンドの領域において依存度が高く、カバーし合えていなかった
かつ、Vue はとっつきやすかった反面、ライブラリとの互換性やその独自性から、チームの開発力の向上に壁を感じていました。加えて、React 系の Next.js の進歩が目まぐるしいという情報が Twitter 等でも多く見られるようになり僕も相棒の goran も React が徐々に気になり始めていた時期でした。更に、他のプロジェクトなどに参加をしていると、React が触れる人は比較的短期間で Vue も触れるようになる反面、その逆は少し抵抗があるような印象を受けました。
以上の課題や背景から、フレームワークそのものを Next に刷新し新たなパートナーズシップを作ろう!という結論に至り、v2 の開発がスタートしました。
-
開発期間
- 2022 年 1 月末〜2022 年 6 月初めの約 4 ヶ月
-
リード開発者
- 3 人 + 外部パートナー 3 人
-
主な技術スタック
- Next 12.0 (フレームワーク)
- TypeScript (使用言語)
- Vercel (CI およびホスティング)
- Firebase Authentication (認証)
- Cloud Functions for Firebase (バックエンド)
- MUI (デザインフレームワーク)
React は今まで触ったことがなかった思想や設計だったので、初めはめちゃくちゃ勉強しました。慣れてくると Vue より扱いやすく、メンテナンス性も高いため、現在も基本的な開発案件では Next がファーストチョイスになっています。そして、Next でやるからには Vercel ということで、圧倒的に初期の時間的開発コストを削減できました。Next の API Routes を使わず引き続き Cloud Functions を使ったのは、Firestore をトリガーに関数を起動できる Cloud Firestore トリガーを使用したかったためです。こちらは、GitHub Actions を使って各環境へデプロイされるよう yaml を用意しました。
また、リード開発者がアップグレードされている点にもご注目ください。2022 年 1 月に入ってきた新卒が、既に React を触ったことがあったので、スムーズにプロジェクトに参画できました。また、優秀なパートナーさんにも協力してもらい、4 ヶ月という短い期間でリプレイスすることができました。特に大きな問題もなく v2 へと移行できたのは、dev チームそのものが進化しアップグレードされたからに他ならず、このプロジェクトを通しても自分たちの進化を実感することができました。
弊社では、制作案件も受けています。比較的中規模以上のサイト制作などは、Next.js で SSG を行っていますが、最近特に話題のAstroも現在導入を検討しています。
v2.5
v2 はその後、いくつかアップデートをしましたが、特に大きいアップデートが v2.5 でした。どうように実現したか、詳しくは別記事で書きたいと思いますので、ここでは概要にとどめます。
パートナーズシップのプロジェクトが進行するに連れて、本体とは切り離して開発をした方がよい機能が出てきました。そしてその機能をサブドメインにホスティングし、提供する形です。しかし、デザインの思想は本体と同じであり、共通で使用したいコンポーネントは多くありました。そこで、monorepo 構成を採用しました。
-
packages
- app (本体)
- common (共通コンポーネント)
- func1 (機能 1)
- func2 (機能 2)
- …
このように packages ディレクトリを新たに作成し、その中で機能毎に分けていくイメージです。中には使用する Firebase を分ける場合もあるので、その config の管理や、push した際の vercel のビルド処理の制御など複雑化したところはありますが、一度設計・設定してしまえば、非常に効率的な開発環境になりました。
v3
さて、今まさに開発を進めているのがこの v3 です。まだ開発途中なので概要にとどめますが、基本的な技術スタックは v2 とさほど変わりません。最も大きく変わる点は、 複数の Firebase プロジェクトを使った SSO(シングルサインオン) の実現です。
Firebase の Authentication には、標準的に SSO の機能は備わっておらず、複数の Firebase プロジェクトをまたいで認証情報を共有するには、少し工夫がいります。その工夫を現在開発しているというわけです。
思想自体はシンプルなのですが、具体の話となると非常に複雑なのでどこまで記事にすべきかまだ考えられていませんが、いずれ。
まとめ
今回は 2022 年を振り返り、弊社が最も力を入れているパートナーズシップの開発を振り返りました。よくここまでこれたなあ、と思いながら、チームのメンバーに感謝を感じる年の瀬です。来る 2023 年、「別記事で」と申し上げたところをちゃんと記事にすることを誓って…それでは良いお年を 👋