はじめに

この記事はメドレー夏のブログリレー 2025 22 日目の記事です。

メドレー医科診療所プロダクト開発室 AI推進グループの桶谷です。

AI推進グループでは、「AIで “医師” と “エンジニア” の生産性を最大化する」というミッションを掲げ、医師の皆様に向けたAIソリューション（「ゼロ距離医療」の実現）と、社内エンジニアの生産性向上（「CLINICS 10x」）の両輪で様々な施策に取り組んでいます。取り組みの全体像はこちらの記事で詳しく紹介しています。興味のある方はぜひお読みください。

その中でも「CLINICS 10x」では、従来の10倍の速度で機能リリースを実現するための様々な取り組みを進めています。 10倍のリリーススピードを実現するには、単に開発を速めるだけでなく、リリースの品質担保、特にQAの効率化とバグの早期検知が極めて重要になります。 CLINICSは多くの医療機関で利用される基幹システムであり、不具合発生時の影響をいかに局所化し、迅速に修正できる体制を築くかが大きな課題でした。

そこで、10xリリースの土台作りとして、まず「ライブラリ更新」のリリース戦略見直しに着手しました。今回はその取り組みの中から、CLINICSを開発しているチームで導入した、ライブラリ更新を分離する新しいブランチ戦略についてご紹介します。

※ ライブラリ更新：本記事ではMinor、Patchレベルの更新を指します

想定読者

リリースプロセスに課題を感じている人
開発チームと連携して品質保証の仕組みを改善したい人

なぜリリース戦略を見直したのか

CLINICS は多くの医療機関で利用されている診療所向けクラウド型電子カルテシステムです。医療機関向け SaaS として提供される一方で、電子カルテ、予約管理、会計、オンライン診療など診療所の基幹業務を一手に担う「基幹システム」として機能しています。日々の診療に直結する業務を支えるため非常に高い安定性と信頼性が求められます。サービスの性質上、ひとつの変更が「受付 → 診療 → 会計」といった一連の業務フロー全体に波及する可能性があるため、品質保証の重要性は非常に高いです。

その品質保証の範囲も単なる UI 動作の確認にとどまらず、業務フローの整合性、データ整合性、権限や監査、請求（算定）ロジック、可用性といった多岐にわたる領域に広がります。しかし、いくらテストを厚くしても、あらゆる組み合わせを事前に網羅するのは現実的に困難であり、検証漏れのリスクを完全に排除することはできません。そのため、リリース設計においては差分を小さく保ち、影響範囲を限定し、原因を切り分けやすくする工夫が不可欠となります。

さらに技術的な背景として、CLINICS は Rails モノリスに複数の SPA を内包し、バックエンド、フロントエンド、一部インフラを単一リポジトリ（モノレポ）で集約的に管理・運用しています。1つのリポジトリに Rails、React、Next.js、Node.js といった技術スタックが同居しており、依存関係は論理的に分離されているものの、ライブラリ更新の頻度は高く、変更の影響範囲も広大になりがちでした。

こうした背景と課題から、まずは機能とライブラリのリリースを分けることで、変更差分と影響を最小化しようと取り組みました。

従来のリリースプロセス

CLINICSでは、master（本番環境相当）/ develop（開発統合）/ release-candidate（次回リリース候補のコードフリーズ） の3ブランチ構成を基本に運用しています。従来は「機能追加」と「ライブラリ更新」を毎週火曜日の定常リリースにまとめて実施していました。具体的には、各 feature ブランチや deps（ライブラリ更新）ブランチを develop に順次マージし、木曜日に develop から release-candidate を作成してコードフリーズ。このrelease-candidate 上で QA を実施し、翌週火曜日に master へまとめてリリースするというフローです。

AS-ISリリースフロー図

図を見て分かる通り、Git Flow をベースに開発、リリースを実施しており、全ての変更が毎週火曜日の定常リリースに集約されていました。この方法ではプロダクトの成長とともに、以下の課題が浮き彫りになりました。

不具合発生時の原因切り分けが難しい：不具合が生じても、それが新機能によるものかライブラリ更新によるものか特定に時間がかかる
品質担保コストの増大：ライブラリ更新は予期せぬ副作用を生むことがあり、機能追加と同時に行うことで QA の範囲が広がり、テストや検証に必要なコストが増大していた

リリース時の差分が大きいと、一見些細なライブラリ更新であっても、医療現場の業務フローに予期せぬ不具合を引き起こし、診療や会計といった基幹業務に影響を及ぼすリスクがあります。実際にも、ライブラリ更新と多様なデータ状況など複数の要因が重なれば、一部の医療機関で「会計処理が停止する」といった業務に直結する問題が発生する恐れがありました。こうした事象は、医師やスタッフの負担を増やすだけでなく、患者体験にも直結してしまいます。

さらに昨今では、生成AIを活用した開発の加速によって、リリースごとに扱う差分はますます膨らみ、従来のリリースプロセスのままでは品質とスピードの両立が難しくなってきました。そこで、「CLINICS 10x」の思想に立ち返り、品質を確保しながらもスピードを失わないために、リリース戦略そのものを見直す必要があると判断しました。

新しいリリース戦略で実現したいこと

今回の取り組みで目指したのは、単なるリリース手法の変更ではなく、チーム全体が安心して開発・検証・リリースに取り組める体制を作ることです。そのために、次の3つを軸としました。

ライブラリ更新の安定化
- 不具合発生時に「ライブラリ起因」と即座に判断して対応できるため、機能変更と明確に切り分けてリスク管理が可能となる
- 不具合発生時にライブラリ更新だけを即時に戻せるため、初動対応を安全に行える
機能リリースの明確化
- QAは機能検証に集中でき、テストの粒度と品質が向上する
- リリースノートも「メンテナンス」と「アップデート」に分け、ユーザーに分かりやすく伝えられる
品質とスピードを兼ね備えた体制
- 小さな差分で安全かつ素早くリリースできる体制を確立
- 領域ごとの責任分担と確認項目を明確化し、安心して高速リリースを実行できる運用体制を整備

この取り組みには技術面だけでなく、事業部やQAチームとの合意形成も不可欠です。特に、カスタマーサクセス（CS）/サポートデスクは変更点の把握が不可欠である一方で、ライブラリ更新といった技術的変更が十分に共有されないままリリース差分が大きくなることに不安を抱えていました。そこで、週2回のリリース頻度増は「差分を小さく保ち、リスクを分離・局所化すること」を狙いとしていると説明し、リリースノートを「メンテナンス（ライブラリ）／アップデート（機能）」に分けて整理しました。結果として、関係部署からも「そのほうが安全で把握しやすい」と理解が得られ、スムーズに合意形成へとつなげることができました。

一方で QA チームも、従来はライブラリ更新と機能追加を同時に検証していたため、不具合が発生すると原因切り分けに苦労していました。こうした課題感もあり、「更新と機能を分けた方が効率的に品質を担保できる」という点で意見が一致しました。加えて、開発と QA が一体となって品質を高める文化がすでに定着していたことも後押しし、新しいリリース戦略をスムーズに取り入れることができました。

ライブラリリリースと機能リリースを分ける際のブランチ戦略

今回、新たに「ライブラリ更新専用のブランチ」を追加することで、ライブラリ更新を単体でリリースできるようになり、機能リリースと役割を分担した週2回の安定したリリース体制を実現しました。

曜日	リリース成果物	ブランチ
月曜日	ライブラリ更新	release-candidate-lib
火曜日	機能追加	release-candidate

この仕組みにより、ライブラリ更新と新機能追加という性質の異なる変更が互いに干渉せず、それぞれに適したテストと品質保証を行える体制を確立することができました。

AS-IS / TO-BE の比較

AS-IS（従来のリリースフロー）

AS-ISリリースフロー図

TO-BE（新しいリリースフロー）

TO-BEリリースフロー図

AS-IS では、機能追加（feature）と依存更新（deps）が develop に同居し、木曜日作成の release-candidate 上でまとめて QA を実施し、翌週火曜日に単一リリースしていました。TO-BE ではフローを2本に分離しました。ライブラリ更新は release-candidate-lib-next に集約し、同時に develop へ Reverse Merge することで、日常開発の中で早期に動作検証を行います。安定化した内容は月曜日に release-candidate-lib にて、ライブラリのみのリリースを実施します。機能追加については従来通り release-candidate を経由し、火曜日に本番リリースを行う形にしました。

新しいブランチ戦略におけるキーポイントとメリット・デメリット

今回の戦略で最大のポイントは、release-candidate-lib-next ブランチの新設です。

release-candidate-lib-nextブランチ

Renovate/Dependabot が作成するライブラリ更新 PR を release-candidate-lib-next に集約することで、翌々週にリリースされるライブラリ更新の成果物を対象に、長期回帰テストを継続的に実施できるようになりました。コードフリーズブランチを「ライブラリ用」と「機能用」に分離したこともポイントです。ライブラリ更新は回帰確認中心、機能追加は業務フローやユーザー体験検証中心といった形で、QA のスコープを用途ごとに最適化できるようになりました。加えて、ライブラリ更新を単独でリリースできるため、不具合発生時には原因の切り分けが容易になり、ライブラリのみを安全に Revert する対応も可能です。

こうした仕組みによって、品質保証の効率化と精度向上を実現しつつ、不具合対応の即応性も高めることができました。一方で、運用を進める中でいくつかの課題やトレードオフも明らかになってきました。

Reverse Merge の増加：release-candidate-lib-next → develop への取り込み頻度が上がり、特にコンフリクト発生時の解消コストが高い
ブランチ運用の複雑化：release-candidate-lib-next / release-candidate-lib の追加によって、運用コストや学習コストが増大
CI/テスト負荷の増加：候補ブランチごとに E2E が走るため、ジョブ数が増えて実行環境への負荷が高い(省力化や高速化に向けた改善は別途実施中)

これらの課題は認識しつつも、チーム合意のもと「医療に直結するプロダクトとして品質を優先する」という判断を取りました。その結果、リスクの局所化と原因特定の迅速化を両立し、週2回の安全なリリースを継続できる体制を確立できています。

QA チームによる品質担保の仕組み

ここからは、QA エンジニアの小島 (@Daishu) が、今回の改善における E2E テストを用いた品質担保の設計について紹介します。

E2E テストの実施体制

CLINICS では、QA チームが MagicPod を使って E2E テストを管理しています。

E2Eテストの役割

出典: 徹底解剖！医療業務システムのReactコンポーネント設計を基に作成

各ブランチでは、以下の頻度と目的で E2E テストを実行しています：

1. 開発統合 (develop) ブランチ
デイリーで E2E テストを実行し、デグレを検出します。テスト失敗時は原因を分析し、仕様変更による失敗の場合は MagicPod のテストシナリオを更新して対応しています。

2. リリース候補 (release-candidate) ブランチ
ウィークリーで E2E テストと手動テストの両方をフルスイートで実行してリリース可否を判定します。

新しいリリースプロセスへの対応

新体制への移行にあたり、QA チームの懸念や要望を開発チームに共有し、一緒に品質担保の仕組みを設計しました。

① deps マージタイミングの最適化

deps をマージするタイミングを変更したことで、問題の切り分けが改善されました。

	deps マージタイミング	特徴
旧	release-candidate ブランチカット前	• ライブラリ更新が翌週リリースとなる • 不具合検出の猶予がなく、問題切り分けに時間がかかる
新	release-candidate ブランチカット後	• ライブラリ更新のリリースが翌々週となる • 開発環境での検証期間を確保でき、問題の切り分けが容易になる

この変更により、deps 起因の問題を効率的に検出・対応できるようになりました。

② release-candidate-lib ブランチでの E2E テスト追加

前述の release-candidate-lib ブランチに対する E2E テストを追加しました。これにより、ライブラリ更新の品質を単独で検証できるようになりました。

リリースプロセスと E2E テスト

③ MagicPod ブランチ機能による UI バージョン管理

release-candidate-lib は前回リリース済みのコードをベースにしているのに対し、E2E テストは日々更新される最新の develop に合わせてメンテナンスされているため、そのままでは UI の差分でテストが失敗します。この問題は、MagicPod ブランチ機能で解消しています。

# 運用フロー
 1. 木曜日：E2E テスト完了時点で MagicPod branch を作成
    └─ ブランチ名: release-candidate-lib/YYYY-MM-DD
 2. 翌週木曜日：前週に作成した branch を指定して、E2E テスト実行
 3. テスト完了後：branch を削除して、次のサイクルに備える

MagicPod の定期実行機能では branch を指定できない仕様のため、GitHub Actions から API 経由で branch を指定して週次で自動実行しています。

GitHub Actions のワークフロー

以上、QA チームの視点から、新しいリリース戦略を支える品質担保の仕組みについて紹介しました。開発チームと共に設計したこの体制により、週 2 回のリリースでも効率的な検証と高い品質維持を実現しています。

まとめ

今回リリース戦略の見直しにより、CLINICS 開発チームでは「品質」と「スピード」の両立に向けて土台を築くことができました。不具合発生時の原因切り分けは迅速になり、QA プロセスも効率化されています。今後はさらに、フロントエンドとバックエンドを個別にリリースできる体制や、日中に安心してリリースできる仕組みの整備にも取り組んでいく予定です。これらの改善を通じて、より柔軟に、そして迅速に、ユーザーにとって価値ある改善を届けられる開発体制を目指していきます。