この記事は MICIN Advent Calendar 2022 の21日目の記事です。
前回は水谷さんの「組織変化により初動１ヶ月で実施した5つのアクション」でした。
はじめに
私は株式会社 MICIN のオンライン医療事業部でフロントエンドエンジニアをしています。
今年の初めくらいから「curon お薬サポート」のサービスの開発に携わることになりましたが、
開発に携わっていくにつれ感じていた課題を、ちょうど今現在進行形で解決に向けて動き出せることになったので、今回はその話をさせていただきます。
まず MICIN で展開している curon のサービスブランドとしては、オンライン診療サービスの「curon (クロン)」と薬局向けサービスの「curon お薬サポート」と2つ存在し、それぞれに医療機関（薬局）向けのサービスと患者向けのサービスが存在しています。
| curon | curon お薬サポート |
|---|---|
| 医療機関向け（Web） | 薬局向け（Web） |
| 患者向け（App / Web） | 患者向け（Web） |
プロダクトが抱えていた課題
「curon お薬サポート」は、プロダクトがスタートしてから3年弱ほど経ち、当時開発していた人たちも異動してしまっていたりと、負債が溜まりつつある状況に陥っていました。
-
明確なデザイントークンが定義されておらず、各サービスに似たようなコンポーネントの実装がされてしまっている
-
UI 実装専任のチームが居るわけではなく、UIコンポーネントライブラリの選定もバラバラ、その時々で実装者に完全に委任されてしまっていた
- 実装に差異が出ており、サービス間のデザインの統一感が得られない
-
curon と curonお薬サポートでも選定されているフレームワークが異なり、学習コストやメンテナンスのコストが膨大
| サービス | 利用技術 |
|---|---|
| curon（医療機関向け） | Angular（一部 React ）+ MUI |
| curon（患者向け、Web） | Next.js + MUI |
| curon お薬サポート（薬局向け） | Create React App + Headless UI |
| curon お薬サポート（患者向け） | Create React App + MUI |
これらの各サービスに対して、専属のメンテナーが居るわけではなかったので、これらの負債に対して横断的な改善するための道筋が立てられていない状態でした。
再設計に関するアプローチ
そんななか、薬局向け curon お薬サポートの一部機能の本部薬局向けの機能を新たに作り直しすることになりました。
これを機に、curon のサービスブランドのあるべき姿、ユーザー体験、開発の進め方を再設計し進めることにしました。
curon サービスのデザイントークンの整理
まずは UI デザイナー主体でデザイン原則をまとめ、curon サービスとして持つべきデザイントークンの整備が行われました。
curon のデザイントークンからカラースキーマの抜粋
Monorepo 化
整理されたデザイントークンを1つのパッケージの要素とみなし、汎用的なコンポーネントとして提供しやすくすることと、今後他の関連サービスも同じ開発プロセスで進めやすくするために Monorepo での構成に。
テンプレートとしての PoC を作成
普段からフロントエンドの技術に精通していない方にとっては、ある程度コードベースのものがないと、想像しづらい部分があるので、1つ1つの説明はここでは割愛しますが、以下の選択肢からいくつかの組み合わせをピックアップして、 PoC を制作してエンジニア間で議論しました。
| フレームワーク | UI コンポーネント | スタイリング |
|---|---|---|
| Next.js | Chakra UI | Stitches |
| Remix | Radix UI | Linaria |
| Astro ( + React ) | Headless UI | vanilla-extract |
| Qwik ( + React ) | Emotion | |
| SolidJS | Styled Components | |
| Tailwind | ||
| CSS Modules |
不確定要素へ立ち向かう
アプリケーションの構成を考えたとしても、それが普遍的に今後も利用し続けられるとは限りません。
今後降りてくるさまざまな要件を見越して初めから全てに対応することは不可能に近いです。
そんななかで選定の指針を以下のように定めて進めてみました。
-
既存の実装から大きく逸脱しない形で進められること
-
必要最低限の構成であること
- 必要に応じて、フレームワークの追加やマイグレーションが容易であること
-
プロダクトチームとしての開発効率が向上すること
-
MICIN として利用実績が多く、キャッチアップが容易であること
2 と 3 に関してはある程度トレードオフな部分があるとは思いますが、
以上の観点を重視し、最終的には pnpm の workspace 機能を利用し、アプリケーションのベースとしては Next.js + Chakra UI の構成にすることにしました。
Next.js はアプリケーションの要件によって、SSR、SPA、SSG など柔軟に対応できることと、MICIN の他のチームでの利用実績が多いこと。
Chakra UI は今まで自前で作成していたコンポーネント群とインターフェースが似通っており、各アプリケーションで実装されていたコンポーネントのメンテナンスをする必要がなくなること。
pnpm の workspace 機能については、初手では豊富な機能を持っている turborepo や Nx などのフレームワークが必要にはならないが、それらへの移行がしやすいことが決め手となりました。
これから
これらの改善施策はまだ始まったばかりで、今回作っている構成をもとに一部機能から「curon お薬サポート」のプロダクトをリプレイスしていくスケジュールになっています。
現時点はまだまだ必要最低限のものしかないですが、今後の展望としては、デザイントークンのパッケージ化やデザインシステムの構築を行なって、他プロダクトにももっと展開しやすい状況を作れればと思っています。
今回は「curon お薬サポート」のプロダクト開発に焦点を当てた内容ではありましたが、今回の話とは別に各サービスのリリースプロセスに関しての改善も並行して行なっており、それはそれでまた別な機会にお話しができればと思います。
MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
Discussion