はじめに
UbieでQAエンジニアをしているMayです。
Ubieは「テクノロジーで人々を適切な医療に案内する」をミッションに掲げ、医療機関向け、製薬企業向け、そして生活者向けに、AI問診エンジンや医療プラットフォームを提供しています。先日、月間1200万人を超えるユーザーが利用するtoCサービスを支える基盤システムについて、より拡張性の高いシステムへのリプレイスが完了しました。
2024年1月から新システムの開発に着手し、半年におよぶ概念設計を経て、8月からは実装フェーズに移行。度重なるリリース計画の見直しを乗り越え、2025年1月に無事リリースを迎えました。
本記事では、この長期プロジェクトにおけるQAプロセス、特にテスト戦略とリリース計画に焦点を当て、開発の裏側を紹介します。前編では戦略や計画を立てるまで、後編では、その実践と振り返りをお伝えします。
新基盤システム開発プロジェクトの概要
システム構成とユーザー
今回開発したシステムは、大きく分けて管理画面とバックエンドシステムの2つのコンポーネントから構成されています。
管理画面は、社内ユーザー（オペレーターや開発チーム）がコンテンツを管理するためのインターフェースです。様々な条件に基づいて表示内容を定義し、この管理画面から登録・編集します。
バックエンドシステムは、管理画面から登録された情報に基づき、ユーザー（生活者）の状態をリアルタイムに判定する役割を担います。ユーザー情報と登録された条件を照らし合わせ、適切なコンテンツを返却します。この際、バックエンドシステムは既存の複数のPHRシステムから情報を参照します。
効果測定のため、データはBigQueryに連携され、BIツール（Lightdash）での可視化や分析に活用されます。これにより、施策の効果検証や改善を継続的に行うことが可能となります。
開発体制
開発は8名のクロスファンクショナルチームで、1週間スプリントのスクラム開発で進めました。QAエンジニアはテックリードと協働し、テスト戦略・リリース計画の策定と推進を主導。スクラムマスターを兼任し、チームの活動や開発プロセス全体を円滑に進める役割を担いました。
チームは本開発のために組成されました。ドメイン知識を補うために、社内の有志者3名にもオブザーバーを担当してもらいました。
プロジェクトにおける課題とリスク
新基盤システム開発プロジェクトは、多くの課題とリスクを抱えていました。
まず、システムの特性に起因するリスクとして、以下のようなものが挙げられます。
- toCサービスの大通りとも言える部分で使われているシステムのリプレイスであること
- 収益の柱となっている事業と密接に関係する箇所のリプレイスであること
- 複数のシステムと連携しながら動くシステムであること
- 複数の種類のユーザーが存在すること
- これまで使っていた概念を新たな概念に転換していること
- 長期プロジェクトのためユーザーからのフィードバックが得にくいこと
また、プロジェクト推進体制に起因するリスクとして、以下のようなものが挙げられます。
- チームが立ち上がって初めての開発であり、開発に関するチームのナレッジが溜まっていないこと
- 社内の様々なチームと連携しながら開発を進める必要があること
- 新しい基盤システムでの拡張の展望が見えており、早期リリースが期待されていること
特に、プロダクトとして気をつけなければならないのは、toCサービスの大通りとも言える部分であり、収益の柱となっている事業とも密接に関係している部分のリプレイスであることです。そのため、既存機能と同等の機能を担保することはもちろん、リリースによってユーザーの体験を損ねたり、収集しているデータに不整合が生じたりすることがないよう、慎重に開発を進める必要がありました。
また、リプレイス後には私自身も心躍るような拡張の予定が見えており、早くリリースしたい気持ちでいっぱいでした。しかし、チームが立ち上がって初めての開発であることは、プロジェクトを円滑に進めるうえでの大きなリスクでした。メンバーそれぞれが素早く意思決定できるよう、チームでの認識を揃えることが必要不可欠です。
チームで品質を追求するための取り組み
リスクストーミングの実施
上記のような課題認識から、プロジェクトを円滑に進めるためには、潜在的なリスクを洗い出し、チーム全体で共有する必要があると考えました。
そこで、開発の初期段階で、チーム全員で集まって リスクストーミング のワークショップを実施し、リスクの可視化と優先度付けを行いました。
ワークショップの流れは以下のとおりです。
- アーキテクチャ図を作成する(10分)
開発対象となるシステムのアーキテクチャ図を、関係者全員で作成する - リスクを個別で特定する(10分)
各メンバーが、思いつくリスクを付箋に書き出します。優先度（高・中・低）で付箋の色を分けて書いていく - 図表上でリスクを収束させる(5分)
書き出した付箋を、アーキテクチャにマッピングするように張り出す - リスクを見直してまとめる(15分)
張り出した付箋について、全員で内容を確認し、優先度やリスクの共通認識を図る
付箋を優先度別で色分けしているため、アーキテクチャのどこにリスクが高いのか、ヒートマップのように視覚的で分かりやすい図ができあがりました。
挙がったリスクは機能面だけでなく、性能面や他システムへの影響、データやオペレーションまで多岐にわたりました。このワークショップを通じて、チームで以下のような成果を得ることができました。
- 共通認識の促進
アーキテクチャや潜在リスクについて、チーム全体で共通認識を持つことができました。 - 不安要素の可視化
各メンバーが抱えていた不安や懸念を共有し、可視化することができました。 - 優先順位の明確化
リスクの優先順位を明確にすることで、開発やテストにおける注力ポイントを絞り込むことができました。 - リリース計画への反映
特に、他システムとの連携部分におけるリスクを考慮し、段階的なリリース計画を策定する判断材料とすることができました。
ほんの1時間のワークショップでしたが、プロジェクトを円滑に進めるためのたくさんの材料が集まり、プロジェクトに対するチームの意思決定の礎となりました。
テストレベルと責務の定義
チームが組成されたばかりで開発プロセスが確立されていないという課題に対し、リスクストーミングとは別に、チーム全体のテストに対する共通認識を醸成することも重要だと考えました。
そこで、本開発におけるテストレベルを定義し、チーム内でのテストに対する認識を揃えることにしました。各テストレベルで担保すべき品質と責任範囲を明確にすることで、プロダクト開発エンジニアとQAエンジニアがそれぞれの役割を理解し、連携して品質向上に取り組めるようにすることを目指しました。
今回は、テストピラミッドとテストトロフィーの考え方をベースに、バックエンドシステムと管理画面システムそれぞれのシステム特性に合わせたテストレベルを定義しました。以下に示す表は、各テストレベルの目的、対象、主体をまとめたものです。今回構築する基盤システムは、管理画面とバックエンドの両システムおよび社内の各種システムと結合して成立するシステムですが、テストレベルの名称は自分たちが開発しているシステム目線で付けました。
| テストレベル | 目的 | 対象 | 主体 |
|---|---|---|---|
| 単体テスト | 個別レイヤーの品質担保 - 単一レイヤー内での機能検証（DBアクセスを含む） - 異常系シナリオの重点的な検証 - 本番環境での再現が困難なエッジケースのカバー |
各コンポーネント内の単一レイヤー | PDE |
| 内部結合テスト | レイヤー間連携の品質担保 - 複数レイヤーを跨ぐ機能の検証 - 開発者視点での正常系動作の確認 |
各コンポーネント内の複数レイヤー | PDE |
| 外部結合テスト | 外部インターフェースの品質検証 - クラウド環境での実動作確認 - パフォーマンス要件の検証 - モックを使用しない実環境テスト - コンポーネント間の連携検証 |
- バックエンドシステム, 管理画面システム間のインターフェース - パフォーマンス要件 |
- パフォーマンステスト: PDE - 機能テスト: QAE |
| システムテスト | エンドツーエンドでの品質検証 - ユーザーシナリオベースの検証 - 実際の業務フローの確認 - システム全体の統合検証 |
システム全体 | QAE |
（PDE：プロダクト開発エンジニア / QAE：QAエンジニア）
このように、テストピラミッドはバックエンドシステムのようにビジネスロジックが中心となるシステムに適しており、単体テストを基盤に、上位レイヤーのテストを絞り込むことで、効率的に品質を担保します。一方、テストトロフィーは、管理画面システムのようにユーザーが直接触れるシステムに有効であり、UIコンポーネントのテストに重点を置きつつ、E2Eテストを組み合わせることで、ユーザーの体験も意識した品質保証を行います。
テストレベルを定義することによって、チーム内での品質に対する取り組み方が明らかになりました。また、リスクストーミングの成果と合わせることで、どの機能のどこまで実施するのか、チームで会話がしやすくなりました。
質とスピードを両立するリリース計画
限られた開発期間の中で効率的かつ効果的にプロダクトを完成させるため、今回の開発では段階的にリリースする作戦を取りました。
それには、以下のような狙いがありました。
- 社内ユーザーのフィードバックを早く得ることができる
- 技術的な不確実性を早く取り除くことができる
- テストのスコープが区切りやすくなる
リリース計画はテスト戦略とも密に連携させました。
この図は、それぞれの箱でどのような機能をリリースし、どのようなテストを実施するかを示しています。
大きな流れとして、まず基盤システムで実現したい最低限の機能をピックアップし、MVP（Minimum Viable Product：必要最小限の機能を持つ製品）を構築します。一通りの実装・テストを行うことで、新しいアーキテクチャへの技術的な不確実性を潰します。また、MVP完成の時点で社内からのフィードバックを得ることで、後続の開発の手戻りも最小限に抑えることを期待しました。
MVP構築のあとは、配信コンテンツの拡充、ユーザーセグメント条件の拡充、プロジェクトマネジメント機能の拡充と並行して開発・テストを進めました。
それぞれのリリースの箱のには、どんなテストがあり、何を確認するのかを明らかにしました。テストの内容はチームで決めたテストレベルの定義をもとにしつつ、開発する機能の特性に合わせて、テストタイプを追加しました。例えば、以下のようなものがあります。
- リグレッションテスト：既存の挙動に影響ができていないか確認する
- オペレーションシナリオテスト：ユーザーストーリーに沿って操作して機能の不足を確認する
データ移行がバッチ完成し開発予定の機能が出揃ったところで、「データ移行テスト」と名付けたテストを実施しました。ここでは、管理画面を使用する各チームにデータの内容を確認してもらうだけでなく、データが入った状態で新旧のシステムでふるまいに差異がないかどうかの確認を行いました。
このように、リリース計画とテスト戦略を統合的に描くことで、開発とテストをインクリメンタルに進め、品質を担保しながらシステムを完成させることを目指しました。
まとめ
本記事では、Ubieの基盤システム開発を題材に、大規模プロジェクトにおける品質保証戦略の実例を紹介しました。長期にわたる開発の中で、チーム全体で品質に対する意識を高め、様々なテストや品質保証活動に取り組んできた道のりを感じていただけたら嬉しいです。
次回の記事では、これらの戦略をもとに行った具体的な事例に、赤裸々な振り返りを添えてお届けします。
Ubieでは、QAエンジニアはプロダクトの品質向上をリードする重要な役割を担っています。また、プロダクト開発エンジニアといった開発に携わるすべてのメンバーが、QA活動を行っています。今後もチームで、より高品質なプロダクトをスピーディーに世の中に送り出していきます。
今回の開発事例を通して、UbieのQAエンジニアの仕事に興味をお持ちいただけた方は、ぜひ採用ページをご覧ください。
また、QAエンジニアと二人三脚で品質向上に取り組むバックエンドエンジニアも絶賛大募集中です。
今回の事例で紹介した開発チームでは先日、Xのスペースで座談会も開催しました。リンク先で録音が配信されていますので、チームの雰囲気を感じたい方はぜひこちらも聞いてみてください。
Discussion