はじめに
Luupに所属している、ぐりもお（@gr1m0h）です。
2025年7月、私が所属していたInfra/SREチームとQAチームが統合し、新たにQualityチームが発足しました。この体制変更は、品質保証とサイト信頼性エンジニアリングを統合的に捉える試みであり、従来の組織サイロを超えた挑戦だと考えています。
本記事では、SREチームのメンバーとしての視点から、私の考えを整理してお伝えします。QAとSREをどのように統合するか、そしてSREのプラクティスを用いて品質と信頼性を一貫して確保していくかについて説明したいと思います。
なお、本記事では以下の用語を次のように定義しています。
- 品質（Quality）: 機能要件が正しく実装され、ユーザーの期待を満たしている状態
- 信頼性（Reliability）: システムが継続的に安定して動作し、非機能要件を満たしている状態
- Production Readiness: 本番環境にリリースするために必要な準備が整っている状態
Quality チームとは
まず、Qualityチームについて説明します。2025年7月、Infra/SREチームとQAチームが統合し、Qualityチームが発足しました。統合前は、Infra/SREチームが本番環境の安定稼働や非機能要件を、QAチームが開発段階の機能要件テストや品質保証を、それぞれ担当していました。
この統合により生まれたQualityチームのミッションとビジョンは以下のとおりです。
まずはミッション（チームの存在意義）です。
Qualityチームは、Luupのプロダクト品質の理想的なレベルを主体的に定義し、その担保や継続的な向上にかかる人的・物的リソースや心理的負荷を戦略的に最適化することを目指します。開発初期の構想段階・リリース前の開発段階・運用段階に至るまで、一貫した情報の共有を行うことで、ユニットテスト・アラート設定・モニタリングといったエンジニアリング的アプローチとシステムテストなど探索的アプローチアプローチを統合し、戦略的に実行します。また、自動化テストの推進、効果的なログ設計、実環境テスト、さらにはプロダクト設計そのものへの品質保証の視点からの能動的な提案を積極的に行うことで、自律的かつ高品質なプロダクト開発環境の構築に貢献します。
次にビジョン（目指す姿）です。
Software部やプロダクト組織に関わるメンバーが、自信を持って迅速に開発でき、また問題の検知の迅速化や不具合やインシデントから学べる体制の構築によって、リリース時にも不安なくリリースできる体制を確立します。これの構築を最小で行うことによって、ソフトウェアを通じた体験をLUUP利用者や社内のツール利用者に対して、デリバリー速度と品質の両面から信頼される開発体制を目指します。
ただし、Qualityチームは発足したばかりで、段階的な統合を進めている段階です。現在は体制図上の統合に留まり、内部的にはSREチームとQAチームが分かれて活動しています。しかし、将来的には垣根をなくし、品質と信頼性を統合的に担保するチームを目指しています。
より大きなミッションを見据えたとき、SREとQA、2つのチームが同じ方向を向くことの重要性を強く感じました。その第一歩として、私はQAチームの社内インターンシップを実施し、2週間にわたってリグレッションテストやテスト設計などを実際に経験させてもらいました。この活動を通じて得た相互理解を土台に、両者の専門知識を掛け合わせ、効果的な品質・信頼性保証の仕組みを作っていきたいと思います。
SREの視点から見たQAとSREの統合
なぜQAとSREを統合するのか
QAとSREの統合は、以下のマトリクスで示される「品質保証の空白」を埋める活動だと考えています。
| 機能要件 | 非機能要件 | |
|---|---|---|
| Dev（開発段階） | ○（QAが担当） | △ |
| Prod（運用段階） | △ | ○（SREが担当） |
従来、QAは開発段階の機能要件を、SREは運用段階の非機能要件をカバーしていました。しかし、開発段階の非機能要件検証や運用段階の機能要件継続検証が不十分だったと感じています。そのため、Qualityチームでは、このマトリクス全体をカバーすることを目指しています。
このアプローチは、DevOpsにおける「Shift-Left」と「Shift-Right」[1]の統合に相当すると考えています。Shift-Leftは開発初期段階での品質作り込み、Shift-Rightは本番環境での継続的検証を指します。両者を統合することで、全ライフサイクルでの品質担保が実現できるのではないかと考えています。
統合的品質保証のアプローチ
では、この統合をどのように実現していくのでしょうか。私たちは、QA領域のアジャイルテスティング[2]とホリスティックテスティング[3]、SRE領域のProduction Readiness[4]とRelease Engineering[5]を組み合わせることで、開発から運用までの全ライフサイクルで品質と信頼性を一貫して担保できるのではないかと考えました。
まず、アジャイルテスティングは開発サイクル全体での継続的テスト実行を重視しており、イテレーションごとに品質を確認することで早期問題発見と修正コストの低減を実現すると考えています。一方、ホリスティックテスティングは、機能要件だけでなくセキュリティ、パフォーマンス、ユーザビリティ、信頼性など、あらゆる品質特性を包括的にテストし、ユーザーが実際に体験する品質を担保するアプローチです。
また、SREのプラクティスでは、Production Readinessが本番環境リリースに必要な準備状態（モニタリング、ログ設計、エラーハンドリング、ロールバック手順、セキュリティー対策、パフォーマンステストなど）を定義し、Release EngineeringとCI/CDが安全かつ迅速なソフトウェアリリースとデプロイを実現すると考えています。
これらのプラクティスを統合することで、私たちQualityチームでは以下のような活動を通じて品質と信頼性を担保していきたいと考えています。
- Production Readinessと自動チェックによる品質・信頼性担保：機能・非機能を網羅したチェックリストと自動検証による継続的な品質確保
- 不具合とインシデントの統合管理：開発段階の不具合と運用段階のインシデントを一元的に管理し、両者から学びを得る
- CUJを含む機能優先度とプログレッシブデリバリー：ユーザーの重要な体験（Critical User Journey）を中心にサービスの機能優先度を決定し、段階的なリリースで品質を担保
これらは、SREとQAが統合したQualityチームだからこそ実現できるプラクティスの集約だと考えています。それぞれについて詳しく説明します。
Quality チームでの具体的な活動
Production Readinessと自動チェックによる品質・信頼性担保
前述した品質保証の空白を埋めるため、Shift-Leftが重要になると考えています。
まず、私は品質担保の手段としてチェックの自動化を重視しています。
ここでチェックとは、定義された基準に対する検証を指します。テストやレビューは、このチェックを実現するための具体的な手段と位置付けています。
具体的なチェックの自動化については、CI/CDパイプラインに統合していきたいと思います。自動テスト、静的解析、AI支援コードレビューにより、定義された基準を満たさない場合は自動的に検知し、アラートを出します。そして重要なのは、アラート状態（＝定義された品質基準を満たさない状態）をタスク化することです。タスク化することで、対応が必要なものとして開発者・PdMが認識でき、PdMの目を通すことでビジネス的に何を優先するか（品質基準を満たすための対応を実施するか）判断できるようになります。また、対応しないという判断も明示的に記録として残るため、後から振り返ることも可能になります。
SREのプラクティスとして重要になるのがProduction Readinessです。これは、サービスを本番トラフィックに任せられるほどの信頼がある状態、その状態にするための考え方を指します。Production Readiness Checklistは、機能・非機能要件を定義するための内部的な指針として活用していければと思っています。ただし、開発者に直接意識させることはなく、Qualityチーム内で品質基準を整理する目的で使うことを考えています。チェックリストを開発者に押し付けるのではなく、自動化によって自然と品質基準を満たせる仕組みを作ることが重要だと考えているからです。
さらに、Shift-Leftの取り組みとして、開発初期段階から品質・信頼性の観点を組み込んでいきたいと考えています。
具体的には、PRD（Product Requirements Document）やADR（Architecture Decision Record）に対する自動レビューで対応することを考えています。Production Readiness Checklistの観点を持ったAIにレビューさせることで、設計段階から品質・信頼性の観点を組み込むことができると考えています。これにより、コーディング前の段階で問題を発見し、手戻りを減らすことができるのではないかと期待しています。
現在、この構想の実現に向けて、まず本番環境と開発環境の差異をなくす活動に着手しています。インフラ的な差異があることで、開発環境でのテストが本番環境の状態を正確に再現できないという課題がありました。そこで、Backendで利用しているCloud Run Functionsの最小インスタンス数を本番環境に合わせる取り組みを開始しました。ただし、コストを考慮して特定の時間帯のみインスタンス数を本番環境と同等にする処理を実装しています。
今後は、流量的な差異をなくすことに加えて、実際に自動テストを実施していく予定です。これらの取り組みを通じて、開発段階から本番相当の品質検証を可能にし、開発者がProduction Readiness Checklistを意識しなくても、自然と品質基準を満たすサービスを作れる仕組みの構築を目指していきます。
不具合とインシデントの統合管理
これまで不具合とインシデントはそれぞれQAチームとSREが別々のプロセスで管理していました。しかし、この分断により組織的な学習の機会を逃していたと感じています。
具体的には、不具合とインシデントの定義が曖昧で、QAチームが使っていた「不具合」とSREチームが使っていた「インシデント」の定義を整理しないと、Qualityチーム内、ひいては部内で会話が難しいという課題がありました。また、それぞれのライフサイクルがバラバラなため認知負荷が高く、分析も別々に行われていたため、どこが品質の低いWeakポイントなのかを組織横断的に把握できませんでした。
これらの課題を解決するため、不具合とインシデントの管理を統合し、組織全体で学習する仕組みを構築することにしました。まず、用語の定義から整理しました。何を重視して、それぞれをどう扱うかを議論するために、不具合は開発環境で発生したもの、インシデントはサービス提供に支障がある、またはUX（ユーザー体験）を著しく下げる問題・トラブルで、何らかの対応が求められるものと定義しています。インシデントは規模は関係なく、N=1でもユーザーに影響が出ているものを含みます。
現状では、不具合とインシデントの差分は発生環境のみです。しかし、今後はCUJなど機能優先度に基づいて機能的に分類し、QAチェック要否の優先度やインシデントの重篤度を判断していきたいと考えています。これにより、限られたリソースをより効果的に配分できるようになると期待しています。
また、不具合とインシデントのライフサイクルを定義し、それぞれのプロセスを明確化しました。
不具合のライフサイクル
インシデントのライフサイクル
インシデントについては、検知経路を「システムアラート」「問い合わせ」「開発環境でのテスト」の3つに整理し、重篤度判定の基準を明確化しました。CUJ関連のインシデントはHigh/Critical、hotfix不要な軽微なインシデントはLow、個別事象もしくは影響がないものはInfoと分類します。この分類により、対応優先度が明確になり、迅速な意思決定が可能になりました。
次のステップとして、不具合とインシデントの分析を一気通貫で行う仕組みの構築を計画しています。現在、インシデントの分析が十分にできていないという課題があります。そこで、不具合を管理しているGitHub Issueのデータとインシデントを管理しているWaroomのデータをBigQueryに送り、社内のBIツールで統合的に分析できるようにする予定です。社内のBIツールを活用することで、すでに分析可能なビジネスKPIなど他のデータと組み合わせることができます。
この統合分析により、品質の低い箇所を俯瞰的に把握し、Qualityチームの対応優先度を決定するためのインプットとして活用していきたいと考えています。また、不具合とインシデントの関連性を探ることで、開発段階で見逃した問題が本番環境でどのように顕在化するかを理解し、より効果的な予防策を講じることができるのではないかと期待しています。このような分析を通じて、組織全体での継続的な学習と改善のサイクルを回していきたいと思います。
CUJを含む機能優先度とプログレッシブデリバリー
Qualityチームとして、限られたリソースで最大の品質を実現するため、サービスの機能優先度を統一的に定義していきたいと考えています。
これまで、QAチームとSREチームがそれぞれ異なる観点で機能の重要性を判断していましたが、Qualityチームとして一貫した基準を持つことが重要だと考えています。
この機能優先度の中で最重要なものがCUJ（Critical User Journey）になるイメージです。CUJは、ユーザーがサービスを利用する際の一連の行動や体験の流れを指します。例えばLUUPであれば「アプリを開いてから車両を借りて、目的地まで移動し、返却するまでの一連のフロー」がこれに該当します。CUJはユーザーがサービスの価値を享受するために必須の機能群であり、ここに問題があるとサービスの存在意義そのものが失われてしまいます。
現在、QAチームが定義していた機能優先度表とSREチームがPdMと合意済みのCUJをマッピングする作業を進めています。この統合により、機能の重要度に応じた適切な品質保証アプローチを選択できるようになります。具体的には、CUJには最も厳密なテストを実施し、最重要な機能には自動化された回帰テストを、重要な機能には定期的な手動テストを、というように、やり方を変えて少ないリソースで最大の品質を出せるような活動を考えるための判断軸として活用していきたいと思います。
さらに、Progressive Deliveryの採用を計画しています。これは段階的にユーザーに機能を展開していくアプローチで、カナリアリリース、ブルーグリーンデプロイメント、フィーチャーフラグなどの手法を含みます。影響を最小化したうえで迅速にリリースすることで、問題が発生した際の影響範囲を限定できます。また、問題の切り分けが容易になることで、復旧時間（MTTR: Mean Time To Recovery）を短縮できます。ロールバックも容易になることで、リスクを最小化しながら高頻度リリースを実現できるのではないかと期待しています。
この活動は、ErrorBudget（サービスの信頼性と機能開発のバランスをとるための重要な指標）の考え方とも合致します。ErrorBudgetは失敗を許容する範囲を定量的に示すもので、100%の信頼性を追求するのではなく、ビジネス価値とのバランスを取ることの重要性を示しています。Progressive DeliveryによってErrorBudgetへの影響を最小化（リスクを最小化）できれば、より積極的に新機能開発にチャレンジできるようになります。
現時点では、Progressive Deliveryの導入はまだ計画段階ですが、まずは小規模な機能からカナリアリリースを試していく予定です。
これらの取り組みを通じて、品質を維持しながら、より重要な機能にフォーカスし、ユーザーに価値を素早く届けられる体制を構築していきたいと思います。
さいごに
本記事では、QAとSREが統合したQualityチームについて、SREの視点から考え方を整理しました。品質と信頼性は本来、連続的な概念であり、開発から運用までのすべての段階で統合的に担保していくことが重要だと考えています。
Qualityチームとしての活動はまだ始まったばかりですが、Shift-LeftとShift-Rightを統合したアプローチにより、従来の組織サイロを超えた品質保証を実現していきたいと考えています。
Production Readinessの自動チェック、不具合とインシデントの統合管理、CUJを軸とした機能優先度の定義とProgressive Delivery。これらの取り組みを通じて、開発者が自然と品質基準を満たすプロダクトを作れる仕組みを構築していきます。
Qualityチームの活動に興味がある方や、似たような課題を抱えている方がいらっしゃいましたら、お気軽に声をかけてください。品質と信頼性の統合的な担保について、一緒に考えていければ幸いです。
弊社のプロダクト開発やSRE、QA、使用技術に興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください！私のX(Twitter)アカウントでもDMを受け付けています。
副業や転職をお考えの方だけでなく、気軽に話を聞きたいという方も大歓迎です！
-
Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. ↩︎
-
Crispin, L., & Gregory, J. (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. ↩︎
-
https://janetgregory.ca/testing-from-a-holistic-point-of-view/ ↩︎
-
https://sre.google/sre-book/evolving-sre-engagement-model/ ↩︎
Discussion