こんにちは、チーフエンジニアの小松です！

私たちは「医療介護のあらゆるシーンを技術と仕組みで支え続ける」ことを使命とし、日々のサービス開発に取り組んでいます。
主力製品であるCAREBOOKシリーズは、医療現場のニーズに応えるクラウド型システムとして、多くの医療機関に導入されています。サービス開始から3年が経ち、おかげさまで多くのお客様からご期待をいただいている状況です。

しかし、プロダクトの成長とともに技術的負債や新たな課題も生まれてきました。ビジネスフェーズの変化やお客様からの多様な要求など、複雑な状況が絡み合い、新たな挑戦が必要となっています。
今回は、3Sunnyのエンジニア組織が現在取り組んでいる課題と、これから目指す姿についてご紹介します。

✏️この記事を書いた人　小松（チーフエンジニア）

フロントエンドの課題

3Sunnyが提供するシステムはサーバーレスがベースになっているものが多く、フロントエンドに処理が集中しています。そのため、課題の中でもフロントエンドの優先順位が高くなります。

フロントエンドフレームワークの移管（Vue.js→Next.js）

【課題】
・テスタビリティ
・パフォーマンスなどのコード品質
・レガシーコード

弊社のプロダクトのほとんどがVue/Nuxt系列で作成されています。
初期から存在するコードはコードベースが大きく、機能が疎結合になっていないため、置き換えが容易ではありません。テストがない部分も多く、仕様が不明確な「レガシーコード」になっています。
開発チームとして、技術的負債を返しつつ、Next.jsに移管していくことに決めました。
当初Vueを採用した状況と現在の状況が変わってきており、Vueである必要性が薄れてきています。この機会に、データベースを含めたドメインの整理を行い、品質と生産性の向上を目指します。

なぜNext.jsなのか

現在フロントエンド界隈で主流になっているフレームワークだからです（参考：State of JS 2023 フロントエンドフレームワーク）。

他の候補としてはNuxt、Remix等も検討しましたが、Next.jsはユーザー数が多く、知見も豊富に蓄積されています。日本語の情報も多く、過度なカスタマイズを避ければジュニアレベルのエンジニアが多くても開発・メンテナンスが可能と判断しました。

後述しますが、フレームワークは流行り廃りがあるものなので、フレームワークに依存しない設計も同時に進行していきます。最近、Next.jsに対する懸念（Vercelの動向やWeb標準に沿わない独自仕様など）もありますが、適切に活用すれば優れたフレームワークと考えています。
Vue系からReact系への移行は簡単ではありませんが、その過程でプロジェクト構成やアーキテクチャ、品質、デプロイ方法の見直しができ、現場メンバーのスキルアップにもつながると考えています。

フロントエンドにクリーンアーキテクチャ、DDDの導入

【課題】
・密結合な機能
・知識の分散
・テスタビリティ

一部プロダクトには既に導入済みですが、フロントエンドにDDD（ドメイン駆動設計）、クリーンアーキテクチャの考え方を導入しています。完全に原則に一致するわけではありませんが、サーバーレス構成との相性がよく、今のところうまくいっています。

サーバー側でDDDやクリーンアーキテクチャの経験がないフロントエンド専任メンバーにとっては難易度の高い挑戦になっていますが、適宜サポートしつつ進めています。
これを導入することでテスタビリティの向上、疎結合・高凝集なシステム設計に近づけることができます。フレームワークに依存しない設計にも関わっています。

パフォーマンス

【課題】
・Web Vitalsの劣化

ユーザー数、トラフィック数が多くなり、製品のパフォーマンスの劣化が気になるようになってきました。
通常のtoB、toCのWebサービスのお客様環境と比較すると、私たちのお客様環境は少し特殊な事情があります（セキュリティ要件が高い、通信速度が出ない仕組み、パケットロスが発生しやすいなど）。そのため、パフォーマンスや通信の不安定さに対する対応が必要になっています。
毎週Sentry等を使ってパフォーマンスのモニタリングを行っていますが、徐々に問題が可視化されてきています。

• ブラウザキャッシュを使ったパフォーマンス改善
• SSRなどを取り入れたPC負荷の軽減、コードベースの軽量化
• 処理をサーバーに寄せることで、クライアントPCにかかる負担を軽減

などに取り組んでいきます。

フレームワークに依存しない設計

【課題】
・開発コストの増大
・生産性の低下
・知識の分散

Next.jsやReactもいつか廃れ、別のフレームワークや言語が市場を席巻するかもしれません。
今の状況でNext.jsを導入するだけでは状況は変わらず、またいつか負債がたまり、フレームワークを移し直すことになります。

技術的負債が溜まっていくことは避けられない問題ですが、フレームワーク移管コストを下げる努力はできます。まずはなるべくフレームワークに依存しないように、ドメイン知識やプロダクトを横断した処理は一箇所に集約していきます。

• サーバー側にドメイン知識を寄せる
• プロダクト横断の共通基盤システムの構築
• npmパッケージ化などで共通の知識をモジュール毎に集約する

いずれも新しいプロダクトから少しずつ進行中ですが、一番大きくて古いプロダクトへの導入が遅れており、今後も改修を続けていきます。

アーキテクチャ大改修

今後は1つのプロダクトを成長させていくだけではなく、多くのユーザーに価値提供ができるようにしていくフェーズに入ってきました。プロダクトとしても特定のユーザーに向けた機能だけに集中するのではなく、さまざまな変化に耐えられる仕組み作りが求められます。
そのためには、現在の構成ではなく、よりドラスティックに構造を変化させ最適化していく必要があると考えています。

認証基盤の共通化

【課題】
・同じユーザーに別の認証情報が必要になることで体験の悪化
・プロダクト間のシームレスな体験の阻害

現状、認証システムがプロダクトごとに分かれています。
今後新しいプロダクト・商品の開発が進む度に認証基盤が増えると、同じユーザーでもサービスごとにIDとパスワードを使い分ける必要が出てしまい、体験の悪化につながります。

プロダクト横断の認証基盤を整えることで、ユーザー体験の向上と、ユーザー管理の煩雑さを一箇所に集約し運用コストを下げる狙いがあります。
また、認可の仕組みなどもプロダクトごとで思想が違う部分があるため、仕組みを揃えてまとめる必要があります。
具体的には、OpenID Connectの仕組みを使って認証基盤を統一していく想定です。

マイクロサービス/MSA

【課題】
・サービスを増やす際の開発工数の削減
・共通ロジックの変更コストの削減

共通基盤側のシステムは、マイクロサービスアーキテクチャを目指します。
すでにその方向で作っていますが、今後基盤側により責務が増えていくため、MSAの設計が重要になります。

境界をどこにするのか、トランザクションの管理、ロールバックの方法など。今後より複雑で難易度の高いアーキテクチャを作る必要があります。
今後増えるビジネス要件に耐えられるように、未来を見据えた設計をする必要があります。

マイクロフロントエンド

【課題】
・システムの依存
・リリースの影響範囲

マイクロフロントエンドの構成を作りたいと考えています。
現在のシステムは相互に依存しており、機能が密結合した状態になっているため、変更コストが高いです。いわゆるレガシーコードになっている部分も多く、かなり複雑で全体像を把握するのに苦労することもしばしばあります。

開発メンバーにバックエンドができる人材が少ないため、まずはフロントエンドを分割し、疎結合な状態にしていきたいと考えています。
この仕組みを作るには、インフラやサーバー側の開発も必要不可欠であり、現在のアーキテクチャを抜本的に変更していきます。

開発チーム

まだまだチームとして未熟であり、個人としてもチームとしても、プロダクト拡大に耐えられる強い開発組織になることを目指します。

開発効率の向上

まずエンジニアとしての永遠の課題である、開発効率・開発生産性の向上です。これはずっと向き合っていく問題だと思います。

まずは生産性を上げるために品質を上げます。
正確には、品質基準を上げ、品質担保を自動化・仕組み化します。
過去1年間、CI/CDの充実やテスト自動化、E2Eテストの拡充などに取り組んできました。特に変化させやすい新規プロダクトである程度の型が作れたので、主要プロダクトにも適用していきます。

特にリリース前テストやCI/CDに関しては、改善しやすく品質に直結する部分であるので、ユニットテストの拡充、コンポーネントテスト、インテグレーションテスト、エンドツーエンドテストなど自動テストを充実させるとともに、テストシナリオのブラッシュアップも行い、本質的な品質担保ができる仕組みづくりをしていきます。

開発プロセスの基盤構築と継続的改善

いくらコードを書くのが早くても、レビューで差し戻しがあったり、仕様を勘違いしていたり、バグが多かったり、手戻りがあれば全体として遅くなってしまいます。
なるべく手戻りをなくし、スピードと品質を両立していくために、開発プロセスのブラッシュアップも続けています。

例えば、設計に慣れていないメンバーも多いため、実装前に必ずマネージャーやリードエンジニアの設計レビューを受けてから実装に入ります。
実装前には必ずテスト設計をしてメンバー間のレビューを受けるなど、基礎的ではありつつもしっかりと仕組み化をして手戻りコストを減らしています。

この仕組みもまだまだ改善していきたいですし、メンバーの技術力やプロジェクトの性質によって変わってくるものだと思っているので、今後もチームが自律的に改善できるように開発プロセスの基盤作りをしていきます。

開発メンバーの技術力アップ

開発メンバーの技術力が低ければ、どれだけ仕組みでカバーしようとしても限界があります。
エンジニアという職業柄、個々のメンバーにも変化と成長が求められます。
私たちは、勉強会の実施や書籍購入支援はもちろん、メンバーにとって「少し難しいタスク」を提供し、業務の中で試行錯誤してもらっています。

短期的には開発速度が落ちるかもしれませんが、「簡単・簡易な実装」に逃げてしまうと当人も成長せず、チームとしても負債を残し、長期的な生産性の低下につながります。そのため、「簡単な方法」に妥協せず、将来を見越した設計・実装になるように相互レビューを行っています。

まとめ

今現在、3Sunnyという会社は大きな転換点にいます。
開発組織、プロダクトとしても基礎部分から手を入れて、次のジャンプアップに備えて基盤を整えています。
個人的には今最も大変で最も面白い時期なのではないかなと思っています。
特に、ある程度力をつけてきた若手エンジニアで、大きな企業・組織だとなかなか責任を取りにいけないとうずうずしている人にはいい環境だと思っています。

私たちと一緒にこの課題に取り組んでくれるエンジニアを求めています

ということで、自ら責任を持って会社の成長に貢献したいというエンジニアを求めています。若手エンジニアと書きましたが、若手じゃなくても歓迎です。興味を持っていただけたら、まずはカジュアルにお話をさせていただきたいです。

大きな転換点を一緒に乗り越え、医療従事者の方々の負担を減らし、一緒に医療業界を支えるプロダクトを作りましょう。