【デジカルチーム ブログリレー1日目】
こんにちは、デジカルチームでソフトウェアエンジニアをしている穴繁です。
長年開発を続けてきたサービスを運用していると、「そろそろアレもコレも新しくしたいなぁ…でもサービスは止められないし、どう進めたものか…」なんて頭を悩ませることはありませんか？
今回は、まさにそのような状況で私たちが実践した「開発を止めない段階的フロントエンドリプレイス」について、計画・技術・組織それぞれの側面から、本日から3日間にわたって連続してお届けしたいと思います。
その中でも、本記事では第1回 計画編として、このリプレイスをどのように計画し進めてきたか、その戦略的側面に焦点を当ててお話しします。
なぜリプレイスが必要だったか？
私たちが開発しているクラウド型電子カルテ「エムスリーデジカル」は2015年の提供開始から10年目を迎えました。プロダクトは着実に成長し、新機能開発や改善に継続的に取り組んでいます。一方で、長年の開発を経て、今日のフロントエンド開発で求められる生産性や品質向上に向けて見直すべき点も見えてきました。
例えば、初期に採用したレガシーなフレームワークやライブラリへの依存が一部残っていることはエンジニアチームとしての課題の1つでした。この課題に対し、私たちはメイン画面である受付・カルテ画面のReactへの段階的リプレイスに取り組み、最終的に全機能のリプレイスを完了することができました。
なぜ段階的？
まず、私たちが開発するエムスリーデジカルには、リプレイス戦略を決定する上で考慮すべき、次の特性があります。
- 画面構成の複雑性: メイン画面は受付・カルテ画面の2つに集約されており、1画面内に多くの機能が実装されています。そのため、一般的なWebアプリケーションに比べ、画面単位のリプレイスで発生する影響範囲・工数が大きいという特性があります。
- 継続的な機能開発の必要性: 診療報酬制度の変更への追従など、定期的な機能開発が求められます。そのため、リプレイスのために機能開発を長期間停止することは現実的ではありません。
- 高い信頼性要求: 日々の診療に不可欠なツールとしてクリニック運営を支えているため、システムの安定稼働が重要です。万が一の不具合が診療業務に与える影響は大きいです。
これらの事情を踏まえ、画面単位でのリプレイスには、長期化による継続的な新機能開発への追従難易度の高さや、ビックバンリリース時の予期せぬ重大な障害発生といったリスクがあると判断しました。
そこで、私たちはコンポーネント単位での段階的なリプレイスを選択しました。
リプレイス戦略の全体像
効率良く・高品質にリプレイスを進めるため、我々はまず、開発・デプロイ基盤の整備から着手しました。 その後、4ステップで段階的にReactへのリプレイスを進めました。
移行に入る前のSTEP0
基盤整備として、具体的に我々が取り組んだ取り組みは次の4つです。
- UI基盤の整備: 再利用性と一貫性を高めるため、Radix UIベースのReactコンポーネントライブラリdigikar-uiを整備しました。
- 開発環境のモダン化: 開発効率向上のため、pnpm workspaceを用いたモノレポ化を進め、関連パッケージ（デザインシステム、APIクライアントなど）を管理しやすくしました。また、型安全性を高めるためにFlowからTypeScriptへの移行を完了させました。
- テスト基盤の整備: 品質の担保のため、既存のJestによるユニット/結合テスト基盤をVitestへ移行するとともに、新たにPlaywrightを用いたVisual Regression Testing（VRT）環境を導入することで、テストカバレッジを拡充しました。
- デプロイ戦略の整備: 安全に本番環境へ届けるため、カナリアリリースの仕組みを導入し、影響範囲を極小化しながらリリースを進められる体制を整えました。
振り返ってみるとどの取り組みも重要でしたが、特にカナリアリリースの導入は最もやって良かったと感じています。現在7,000を超えるクリニックで利用されている本サービスにおいて、影響範囲の極小化は非常に有効でした。
段階的なReactへのリプレイス
上記で整備した基盤の上で、段階的なReactコンポーネントへのリプレイスを実行していきました。リプレイスは、影響範囲と複雑度を考慮し、次の順序で段階的に進めました。
- 小さな共通部品の移行: ボタンや入力フォームといった、アプリケーション全体で利用される基本的なUIコンポーネントのdigikar-uiへの移行に着手しました。
- 各種ダイアログの移行: 比較的独立性の高い各種ダイアログをReactコンポーネントに置き換えました。
- 受付・カルテ画面のUI部分の移行: 主要画面である受付画面やカルテ画面について、まずは表示に関わるUI部分からReactコンポーネントへの移行を進めました。
- メインロジックの移行: 最後に、画面のコアとなる複雑なビジネスロジックのReactへの移行を進め、主要機能のリプレイスを完了させました。
このようにして、初期の基盤整備から始め、段階的なリプレイスを実行し、安全なデプロイ戦略を組み合わせることで、開発を止めずにフロントエンドリプレイスを実現しました。
まとめ
本記事では、開発を止めない段階的フロントエンドリプレイスの実践シリーズの第1回として、私たちが直面した課題と、なぜ段階的なアプローチを選択したのか、その理由と移行計画の全体像についてお話ししました。
システムの安定稼働が優先される中で、開発を継続しながら技術的な刷新を進めるためには、周到な戦略が不可欠です。この第1回で、私たちのリプレイスプロジェクトの概要をご理解いただけたなら幸いです。もちろん、全体像だけを見るとスムーズに進捗したように見えるかもしれませんが、実際には地道で泥臭い作業も数多く伴いました。また、ここで紹介した戦略も、最初から完璧な形で存在したわけではなく、プロジェクトを進める中でチームメンバーと議論を重ね、試行錯誤しながら形作られていったものです。そうした中での工夫や苦労についても、後続の記事で触れられたらと思います。
次回、技術編では、実際に活用した技術や、その中で得られた知見をより詳細に紹介できればと考えています。
We are hiring!
私が所属するデジカルチームでは、クリニックの診療を支えるクラウド型電子カルテであるエムスリーデジカルを開発しています。 開発チームの紹介資料もありますので是非ご覧ください！
また、エムスリーではエンジニアを絶賛募集中です。 興味を持って頂けた方、カジュアル面談や採用へのご応募をお待ちしています。