はじめに
UbieでQAエンジニアをしているMayです。Ubieは「テクノロジーで人々を適切な医療に案内する」をミッションに、AI問診エンジンや医療プラットフォームを提供しています。
本記事では、toCサービスの基盤システム刷新プロジェクトにおけるQAプロセス、特にテスト戦略とリリース計画に焦点を当て、開発の裏側を紹介しています。
このリプレイスは、既存機能の維持と品質確保が最重要課題でした。そこで前編では、クロスファンクショナルなスクラムチームで、①リスクストーミングによるリスク可視化、②テストレベルと責務の定義による品質保証体制の構築、③段階的リリース計画とMVP開発による早期の技術課題解決、といった戦略を立てるまでを解説しました。
後編では、その実践と振り返りをお伝えします。
今回開発したシステム構成とユーザー
今回開発したシステムは、大きく分けて管理画面とバックエンドシステムの2つのコンポーネントから構成されています。
管理画面は、社内ユーザー（オペレーターや開発チーム）がコンテンツを管理するためのインターフェースです。様々な条件に基づいて表示内容を定義し、この管理画面から登録・編集します。
バックエンドシステムは、管理画面から登録された情報に基づき、ユーザー（生活者）の状態をリアルタイムに判定する役割を担います。ユーザー情報と登録された条件を照らし合わせ、適切なコンテンツを返却します。この際、バックエンドシステムは既存の複数のPHRシステムから情報を参照します。
効果測定のため、データはBigQueryに連携され、BIツール（Lightdash）での可視化や分析に活用されます。これにより、施策の効果検証や改善を継続的に行うことが可能となります。
戦略の実践
品質特性シナリオとパフォーマンス検証
基盤システムはUbieのtoCサービス全体に関わるため、様々な品質特性を考慮した実装が必要です。そこで、開発の初期段階で品質特性シナリオを作成し、どのように検証するかをリストアップしました。
パフォーマンスについては、将来的なサービス拡大を見据え、現在のアクセス数に加えて2年後に予想されるアクセス数を参考に目標値を設定しました。
- レスポンスタイム: 90%tileの利用者に対して○○ms以内にレスポンスを返却する
- 処理能力: XX rps を安定して処理できる
目標とするパフォーマンスを実現するために、現実的なデータパターンを模倣した大量のダミーデータを用いて、検証を実施しました。テストツールにはk6を採用し、段階的にアクセス数を増加させるシナリオを実行、レスポンスタイム、エラー率、リソース使用率などの指標をGrafanaで可視化しながら、ボトルネックとなる箇所を特定・改善しました。合わせて、Open Telemetryを導入しオブザーバビリティを高めることで、どこがボトルネックになるのか判断しやすいよう整えました。
新旧比較テスト
今回の開発はtoCサービスの大通りとも言える部分のリプレイスであり、リリースによってユーザーの体験を損ねたり、収集しているデータに不整合が生じないようにしなければなりません。
一方で、このシステムで取り扱うデータは、多岐にわたる条件やコンテンツを組み合わせることができ、パターンは無限に存在します。全てのパターンを網羅したテストは現実的ではありません。そこで、既存システムで実際に配信されているデータにフォーカスを絞り、新旧システムでふるまいに差異が起きていないかどうか検証することにしました。
本開発ではリリーストグルを採用しており、新システムのコードは常に本番環境にデプロイされていました。一般的なリリーストグルと異なり、ユーザー自身が画面上でアクセス先のシステムを切り替えられる仕組みを実装したことで、より柔軟な検証が可能になっていました。この仕組を利用し、本番環境で実データを用いた比較検証を行いました。具体的な手順は以下の通りです。
- データ移行: 新システムの本番環境に、既存システムからデータを変換・移行します。
- 新旧システムへのアクセス: ブラウザを複数用意し、片方は新システム、もう片方は旧システムにアクセスするように設定します。
- 目視による比較検証: 両方のシステムに同時にアクセスし、表示内容を目視で比較検証します。
ケースごとに確認する箇所や操作方法が異なったため、テストの自動化はおこなわず、チームメンバーで分担して手動で実施しました。見逃しがないよう、ダブルチェックも行いました。
二段構えのE2E自動テスト
基盤システムのリリース後も、継続的な機能追加や改修が行われるため、リグレッションテストの効率化は欠かせません。そこで、管理画面とtoCサービスのそれぞれに対してE2E自動テストを導入しました。
管理画面は基盤システム開発のチーム内で開発・運用しており、システムの責務や構成もシンプルです。そこで、プロダクト開発エンジニアが実装・メンテナンスしやすいよう、OSSでスクリプトベースのPlaywrightを用いたE2E自動テストを構築し、CIに組み込みました。データの登録・更新・削除といったCRUDに関わる部分を中心に実装しています。
一方、toCサービスは基盤システム以外にも様々なシステムと連携しており、既存環境ではmablによるリグレッションテストの仕組みが運用されています。そこで、既存のリグレッションテストのスクリプトをベースに、新システムに対応するテストに修正・拡充をしました。こちらは、QAエンジニアが主体となって実装しました。
mablでのテストケース作成においては、以下の点を意識しました。
- ユニットテストとの役割分担: 既にユニットテストで担保できている範囲は、mablのE2Eテストに含めず、重複を避けることで、テストの実行時間短縮とメンテナンス性の向上を図りました。
- テストデータによる効率化: テストデータのバリエーションを増やすだけで、複数のテスト観点をカバーできる場合は、積極的にmablのE2Eテストに組み込み、効率的に網羅率を高めました。
これらのE2E自動テストは、リリース後も継続的に実行しており、安心して追加開発を行えるような環境が提供できています。
リリースの準備
明確な基準によるリリースの判断
開発ボリュームも大きく関係者も多いプロジェクトだったため、内部・外部の要因が重なって、リリースの予定がずれこんでしまう、という問題が発生しました。そこで、「いつまでに、どの機能までが、どのような状態になっていればリリース可能なのか」を明確にするため、リリース判定基準をリスト形式で定義しました。
このチェックリストを用いて、関係者全員でリリース可否を判断しました。1回目の判定時には、いくつかの項目が満たされずリリース延期という結果になりましたが、2回目の判定時には、チーム全体で課題解決に取り組み、全ての基準をクリアすることができました。
リリース判定基準を明確に定義したことで、スケジュールに関する認識のずれをなくし、客観的な判断材料に基づいてリリース計画を進めることができました。
安定稼働を支えるモニタリング体制
リリース後の安定稼働のため、システム監視とメトリクス監視の2つの観点からモニタリング体制を整備しました。
- システム監視
エラー発生率やレスポンスタイムなど、サービスの重要指標に閾値を設定。grafanaダッシュボードで全員が確認できる状態を用意しました。また、閾値を超えるとslackに通知をする仕組みも整えました。 - メトリクス監視
BIツール（Lightdash）で、データ移行後のプロジェクトへのアクセス数を可視化する専用ダッシュボードを構築しました。これにより、サービスの健全性を継続的に把握できる環境を整えました。
システム監視は私たち基盤チーム、メトリクス監視は基盤を使うサービス開発のチームで構築しました。リリースから24時間はこれらのダッシュボードを見守り、無事にリリースを終えることができました。
このモニタリング体制は、リリース後も継続的に活用され、システムの安定稼働に貢献しています。
チームでの振り返りとこれから
最後に、今回のプロジェクトを振り返り、チームで得られた学びを共有します。
バグ分析による振り返り
今回の基盤システム開発は、Ubieでは稀な長期プロジェクトとなりました。長期にわたる開発の中で、チーム全体で品質に対する意識を高め、様々な品質保証活動に取り組んできました。開発終盤には、チームのテストの技術力向上を目的として、簡易的なバグ分析に基づいた振り返り会を実施しました。
JIRAに登録されたバグチケットを分析した結果、管理画面に対する「データ保存・更新の不具合」が全体の約23%を占め、最も件数が多いことが分かりました。この分析結果から、「データ保存・更新」に関する基本的な機能を実装時点で担保できていないことを再認識しました。特に、「作成内容が保存されない」「編集内容が保存されない」といった、類似のバグチケットが複数発生していた点は課題として捉えています。今後は、仕組みや単体テストによる予防策を検討することで、このようなバグの発生を抑制していきたいと考えています。
テストと品質に関する考察
振り返り会では、バグの分析結果を踏まえ、「CheckingとTesting」「当たり前品質と魅力的品質」「継続的テスト」といったテーマについて議論しました。
「Checking」はルールや仕様に基づいた確認作業であり、自動化が容易です。一方、「Testing」は探索的に問題を発見するためのプロセスであり、より創造的な活動と言えます。開発チームとしては、「Checking」は可能な限り自動化し、「Testing」に人的リソースを集中することで、より効率的かつ効果的な品質保証を目指すべきであるという認識を共有しました。
また、「当たり前品質」を確実に満たすことの重要性を再認識しました。いくら魅力的な機能を開発しても、基本的な機能が正常に動作しなければ、ユーザーはシステムを使ってくれません。今回の開発では、「当たり前品質」の担保に時間がかかってしまい、「魅力的品質」の検証に時間を割くことができず、結果的に管理画面を使う社内ユーザーからのフィードバックを待つ形になってしまいました。後手に回ってしまったのは悔しさが残りました。
最後に、「継続的テスト」の重要性についても議論しました。テストは開発プロセス全体を通して、誰でも、いつでも実施できるべきです。開発者自身がコードを書いている段階から積極的にテストを行うことで、バグの早期発見・修正が可能となり、開発効率の向上に繋がります。今後も引き続き、テストを中心とした開発スタイルを取り、DevOpsのループを素早く回していきたいと考えています。
おわりに
今回のリリースが完了したことを全社に報告したところ、新幹線の線路交換に例えて成功を称えてくれるコメントをもらいました。
ユーザーや事業への影響を最小限に抑えながら、既存システムを新しい基盤に置き換えるという、プロジェクトの難しさと達成感を象徴する言葉であり、開発チームの一員として、大きな達成感を感じました。
今回は、Ubieにおける基盤システム開発を題材に、大規模プロジェクトにおける品質保証戦略の実践例を紹介しました。長期にわたる開発の中で、チーム全体で品質に対する意識を高め、様々なテストや品質保証活動に取り組んできた道のりを感じていただけたら嬉しいです。
Ubieでは、QAエンジニアはプロダクトの品質向上をリードする重要な役割を担っています。また、プロダクト開発エンジニアといった開発に携わるすべてのメンバーが、QA活動を行っています。今後もチームで、より高品質なプロダクトをスピーディーに世の中に送り出していきます。
今回の開発事例を通して、UbieのQAエンジニアの仕事に興味をお持ちいただけた方は、ぜひ採用ページをご覧ください。
また、QAエンジニアと二人三脚で品質向上に取り組むバックエンドエンジニアも絶賛大募集中です。
今回の事例で紹介した開発チームでは先日、Xのスペースで座談会も開催しました。録音が配信されていますので、チームの雰囲気を感じたい方はぜひこちらも聞いてみてください。
Discussion