2025-04-30

医療プラットフォーム本部におけるSREグループの立ち上げ

はじめに

こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。

このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。

この記事では、以下の内容についてお話しします。

医療プラットフォームにおける SRE チーム立ち上げの経緯
医療プラットフォームの中核である CLINICS について
医療プラットフォーム SRE チームの組織体制と役割
医療プラットフォーム SRE チームとしての展望

医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。

なぜ、医療プラットフォームで SRE チーム立ち上げたのか？

医療プラットフォームの中核を担う CLINICS

医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。

その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。

また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。

CLINICS に求められる非機能要件

CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。

例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。

その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。

しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム）などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。

CLINICS を含む医療プラットフォームの成長に伴う技術課題

私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。

システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。

長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される
トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む
ライブラリ対応の優先度が下がり、 EOL 対応に追われている
アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない

また、これらの課題は、Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。

CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。

医療プラットフォーム SRE チームの発足

信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。

まずは、医療プラットフォームの中でも中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。

2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。

CLINICS の信頼性向上を目指した SRE の取り組み

ここからは CLINICS に対して現在行っている取り組みを説明します。

SRE チームの役割とミッション

CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。

前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。

目標 1: トイル排除と中長期課題へのシフト

課題:

日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする

主な取り組み:

既存インフラリソースの Terraform import を実施: 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。
定常的に発生する運用業務の自動化: CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。

目標 2: 改善文化の浸透

課題:

ポストモーテム文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。

主な取り組み:

ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。
アラート改善を定常的に回す仕組みの策定: 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。

目標 3: SLO による信頼性可視化

課題:

CLINICS の関係者が納得できる信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する

主な取り組み:

重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。
SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。

SRE チームにおけるその他の取り組み

上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。

事業成長を見越したキャパシティプランニング
システムのモニタリングによる事前の課題発見
障害対応プロセスの改善
インフラコストの削減
DB 等のパフォーマンス問題の改善
ライブラリ対応やセキュリティ対応の効率化
アーキテクチャとリリースフローの改善…など

SRE チームの取り組みの成果が実を結び始める

これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。

信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的としたSidekiq Proの導入など、信頼性向上にも取り組んでいます。

このように私たちの取り組みが徐々に成果を上げ始めています。開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。

医療プラットフォーム SRE チームとしての展望

ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。

医療プラットフォーム全体への SRE ノウハウ展開

CLINICS での知見を活かし、今後、Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。

CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。

プロダクトの拡充に対して柔軟に対応できる仕組みづくり

医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。

新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。

SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。

事業運営に関わる全関係者が納得する SRE 文化の醸成

SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。

SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。

まとめ：医療ヘルスケアの未来を支える SRE

医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。

SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。

何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？

興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 https://www.medley.jp/jobs/