この記事は アソビュー！ Advent Calendar 2025の17日目（表面）です。
はじめに
アソビューでプロダクト/チーム間の横断的な役割でQAエンジニアをしている渡辺です。
前回、開発、およびテストに関わるQAプロセスについて、チーム横断で行ったことを元にブログを記載しました。
（前回記事：思い通りにはならないチーム横断でのQAプロセス改善とその学び - asoview! Tech Blog）
しかし、プロダクト品質の観点で横断的な視点の取り組み例の投稿をしたことはなかったため、今回は、プロダクト品質（特に、当たり前品質）の観点で投稿させていただければと思います。
背景
アソビューにおける「顧客から見た品質」が良い状態とは？
過去、
アソビュー！サイトにおける利用時の品質ってなんだろう？ - asoview! Tech Blog
という記事を投稿させていただきました。
製品そのものの品質だけでなく、ユーザーが実際にサービス（予約・購入・体験）を使う場面で感じる「使いやすさ」「満足度」「安全性」などの品質も考慮し、顧客にとっての品質そのものを指したものです。
「顧客から見た品質」を軸に考えた時の課題
テストは仕様通り動いているからパスしてリリースしている。しかし、ユーザーがサービスを使う場面における「使いやすさ」「満足度」「安全性」について、いくつかの問い合わせがきているシーンは一定以上ありました。
開発 / テストしている直接的なスコープは問題なくても、顧客にとって大事な利用動線（既存の動線を含む）で開発時に不具合が混入し、テストスコープとしても漏れている。といったことが起きている状態でした。
また、BtoB向けの要件に合わせてテストをパスしても、BtoC向けには「当たり前品質」が満たせない、または「利用時の品質」観点ではデグレードが発生することがありました。
取り組み例1 - 横断での不具合分析
やったこと
このような課題を入社1年目より肌では感じていたものの、証明ができていない状態でした。
そのため、問い合わせ情報を元に、プロダクト横断で本番環境にて顧客から見て不具合/障害と思われる傾向の分析を、2023年頃より少しずつ行ってきました。
以下は、2023〜2024頃の分析の一例です。
当時の不具合分析では、分析軸別には以下のような結果がありました。
| 分析軸 | 結果 |
|---|---|
| エラータイプ別 | 外部サービス連携周りでの不具合傾向が多い |
| 品質特性(ISO/IEC25010) 別 | - プロダクト全体は相互運用性の問題発生の傾向がある - プロダクト別には発生する問題の品質特性の傾向が異なる |
| 原因別 | - 不明が一番多い - 原因に事象ベースが混在し、対策しづらい |
発生した事象についての傾向分析はしやすかったですが、発生した原因を掘り下げた傾向の分析は不十分でした。
また、チーム毎に分析しないと、具体的なアクションにつなげにくいFBもありました。しかし元々は、プロダクトチームでのQA業務の傍ら少しずつ自発的に始めたもので、チーム毎だと一人でできる量を超えるため、仲間を増やす必要がある状態でした。
横断的役割のQAエンジニアになってからは、チーム別に不具合分析を行えるよう、開発チーム内のQAエンジニアを支援しました。ただ、プロダクト毎に難易度も異なり、不具合分析に取り組めるリソース度合い、および経験も異なります。
そのため、支援する / しないの度合いはチーム別に変えました。
- プロダクトが成熟期になり影響範囲が広い
- 不具合発生率も高く、且つ対応リソースも不足している
- QAエンジニアが不具合傾向分析をしたことがない
に該当するサービスは支援を厚くし、サービスによっては自ら不具合傾向の分析を行いました。
なお、開発チームでQAエンジニアが不具合分析をした話は以下にも投稿記事がありますので、紹介します。
分析経験がなかった私が不具合分析に挑戦してみた話 - asoview! Tech Blog
2025年以降は、井上さんが一人目SETとして活動を始めました。
アソビューのプロダクト品質をエンジニアリングで改善する、一人目SETとしての活動と展望 - asoview! Tech Blog
現在は、支援の必要度が高いチームにおいて、リリース前のテスト情報も含めた不具合傾向の精度向上、および継続的な分析サイクルを整えるため、SETが中心となり分析に取り組んでいます。
JIRA、およびLookerStudioなどのツールも活用しながら、開発者を巻き込んで不具合収集 / 分析をしています。
不具合収集 / 分析にあたっては、SETが欲しい分析軸とQAエンジニアが欲しい分析軸を混ぜながら、SETと協働で開発チームで発生する不具合の傾向分析に取り組んでいます。
具体的には以下の分析軸になります。（一例）
表1：SET観点の一例 - プロセス別傾向分類
| 項目 | 選択肢例 | 対策例 |
|---|---|---|
| 本来検出したいプロセス | ・設計 ・実装 / UT / IT ・システムテスト ・パフォーマンステスト |
乖離があるプロセスにおいて、シフトレフトテストを推進 |
| 検出したタイミング |
表2：QA観点の一例 - 原因別傾向分類
（◯◯◯：一部情報をマスキングしてます）
| 項目 | 選択肢例 | 対策例 |
|---|---|---|
| 不具合原因 | エラーハンドリング・例外処理不足 | ◯◯ |
| 環境依存・設定ミス | ◯◯ | |
| 共通・個別APIの影響範囲ミス | ◯◯ | |
| キャッシュ管理ミス | キャッシュの更新タイミング・無効化ルールの明確化 | |
| 運用・リリース管理の問題 | - デプロイ前の検証強化 - カナリアリリースの活用 |
|
| UI/UXの問題 | ◯◯ | |
| ステータス・状態管理の不備 | - 処理失敗時のリカバリ設計を強化 - ステータスの一貫性を保つためのチェックを追加 |
|
| ◯◯ | ◯◯ | |
| ： | ： |
課題
プロセス別傾向については、シフトレフトテストできる余地が多いにあることは分析結果からも明らかになっています。
しかし、原因別傾向については、綺麗に傾向が分かれているわけではなく、対策の優先度が決めづらい状況はあります。
そのため現在は、個別の各論の本番障害/不具合の再発防止の運用が回るように、全てのポストモーテムへの参加から始めています。
プロダクト成熟期の主要2プロダクトについては、サービス利用数と影響範囲が大きいです。
それなりに件数も多いため、全ての事象でポストモーテムを行うのはコスト的にも負担が大きくなるため、全ての事象でポストモーテムをしているわけではありません。
そのため、ポストモーテムを開催しないものはEM、スクラムマスターと協働で、1件毎にしっかり事象と原因を確認し、再発防止の検討、再現性の低い不具合の扱いの検討などを進めています。
また、プロダクト成熟期の主要プロダクトを持つ2チームで、不具合事象/原因の確認をEM、スクラムマスター、SET、QAエンジニアで行っています。
似た原因の不具合も多いと感じることが多いですが、原因分類の粒度や選択肢が不十分でデータとしては可視化に至っておらず、
まだ関係者全員が納得できるレベルの言語化に至っていません。
関係者全員が納得感のあるレベルで言語化し、原因の分析軸の粒度や選択肢も合わせてブラッシュアップすることで傾向が見え、改善策の優先順位が決められるのではないかと感じています。
取り組み例2 - 不具合の重要度基準
やったこと
もともとSREチームが定義した重要度基準はありましたが、現場で判断しきれず、運用が形骸化しかけていました。
そこでCTOの助言を参考に、まずは「迷わず判断できる簡易基準」へ更新しました。しかし運用する中で、今度は「事象の重みが十分に汲み取れない」という壁にぶつかります。
そこで再考したのが、これまでの基準の良さを掛け合わせた新基準です。「1事象あたりの深刻度」という視点も加え、SREマネージャーと合意の上で全体適用しました。
この新基準は、重要度とアクション（再発防止期限や承認範囲）をセットにしました。
「重い障害ほど、早く確実に根治する」仕組みを作ることで、顧客への影響を最小限に抑えるのがねらいです。
時系列での重要度基準の変化を表にまとめると、以下になります。
| 時期 | 重要度基準 | 顧客への影響範囲 （時間軸 x 影響数） |
1事象当たりの深刻度 | 不具合管理対象 |
|---|---|---|---|---|
| 2021 | 最初の基準 | ◎（明確だが複雑） | なし | SLO |
| 2023 | 簡易基準 | △（簡易だが曖昧） | なし | 主要動線だが曖昧 |
| 2025 | 新基準 | ◯（曖昧さを軽減） | ◯（4段階） | 深刻度基準に沿う （3段階分を管理） |
（◎：具体的な基準（細部まで有）、◯：具体的な基準、△：抽象度高く、大まかな基準）
新基準で設けた「1事象当たりの深刻度」は、テストを含む開発プロセスでの品質作り込みの重みづけとしても活用されることを期待しました。
そのため、開発チームのQAエンジニアには、テスト観点やテスト密度を決める判断基準として参考にならないか、という対話をしました。
テスト観点にも活用されることで、開発チーム内のエンジニアまで浸透していくことを副次的効果として期待しました。
課題
「1事象当たりの深刻度」を追加したことで、QAエンジニアとしては不具合事象の重さが判断しやすくなりました。
しかし、開発チームからは、
- 重要度を判断する観点が増えた分、慣れるのに時間がかかる
- 深刻度については、一部内容が懐疑的に感じるレベルがある
と感じていることが、人によってある状態でした。
これにより重要度が判断されないことも出てきたため、重要度の判断は必ずしも新基準でなくても、チーム、または再発防止責任者が重要度を判断できれば良いとし、重要度判断で必要以上のコストがかからないよう、曖昧であっても運用が回ることを優先しました。
また、重要度が「軽微」のため、優先順位が下がり再発防止がずっと決まらないことも有りました。そのため、同一原因の不具合が再発して、今度は重要度が「重大」な不具合に繋がってしまう。ということもありました。
深刻度レベルについては、
- 開発チームがより納得感を感じるレベルに更新する
- もっと簡易的にしつつ、より具体発生する事象がイメージできる内容にする
- レベルを分けすぎない
などを検討していく必要性を感じています。
重要度基準と対策についても、現状課題を再整理し、またブラッシュアップする必要があると感じています。
取り組み例3 - CUJベースのSLO改善支援
やったこと
きっかけは、CPOとの対話でした。
SLO / エラーバジェット上は問題なし（グリーン）だが、顧客体験としては明確に「良くない状態」という 「指標と顧客体験のズレ」 への違和感がありました。
この課題意識を深掘りするため、CPO・CTO・SREマネージャーを交えて「各SLOが、顧客体験を正しく捉えているか」を検証することになりました。
結果、SLO的には問題ないと判断されてしまうが、実際には顧客にとって深刻な体験劣化が起きている状態が存在していました。
SLOとしては、以下の3つの構造的な問題もありました。
- SLO名と利用動線の乖離：名前からユーザーの動きがイメージしづらく、枯渇時の影響度が直感的にわからない。
- 動線の混在：一つのSLO内に、異なる利用動線のエンドポイントが混ざってしまっている。
- 重要項目の漏れ：ユーザー体験として重要なエンドポイントが、そもそもSLOに含まれていない。
この状況を変えるため、「より良い顧客体験・品質を正しく捉えるための指標」への転換をする方向性に決まりました。CPO・CTOとの議論を経て、まずは影響範囲が広く問題が起きやすいチームで「パイロット運用」から始める方針が決まりました。
事業側と合意済みの重要機能をベースに、当該チームのPdMが提示した主要シナリオをCUJ（Critical User Journey）として採用し、CUJを軸に、SLOの再構築を進めることになりました。
具体的な作業は開発とSREチームが連携して実施し、私は、課題整理や状況把握を行いながらプロジェクトを推進する役となりました。
課題
プロジェクト型の施策に近かったですが、通常の新規開発、エンハンス対応が多い中で、中々開発チームが本件に思うように時間が取れないことがありました。
また、同一SLO構成単位内に、異なる利用動線のエンドポイントが含まれている件については、MVCモデルのフレームワーク（Java（SpringBoot）など）で各機能が構成されている特性上、技術的に分離することが困難な単位もあり、これを強引に分離したらパフォーマンス負荷が増大する懸念もありました。
この技術的に分離が困難な単位は無理に分離せずでしたが、最終的には、以前より顧客体験に紐づくSLOの再構築が実現できました。
ただし、CUJベースで再構築したSLOはまだ数が多く、クリティカル度合いが重大なものと比較的軽微なものが混在しています。
これらを全て並列で監視する運用は負荷が高く、比較的軽微なものに時間を取られている間に、重大なものの対応が遅れるリスクがあります。
上司である自組織のマネージャーとも本件で対話する中で、顧客体験を全てSLOで守ることは最終的なゴールとしつつも、まずは本当に守りたい顧客体験に絞り、選択と集中を行いつつ運用を回せる状態にしていくことが必要と考えています。
横断QAとして目指す役割
開発チーム内に所属するQAエンジニアとの関係
開発チーム所属のQAエンジニアは、現場でインプロセスQAを実践する最前線の存在です。
一方で、個々のスキルセットを見ると「テスト設計・実行」の実務に特化している方も多く、プロセス改善や仕組み化までを一人で担うのはハードルが高い場合もあります。
そこで、前回記事にした「QAプロセス成熟度」の向上を現場だけで背負い込むのではなく、横断QAには、技術伝達やノウハウ面で不足部分を補完し現場のQAエンジニアが動きやすくなるよう支援していく役割が必要と考えています。
動きやすいための具体的な支援としては、
- PdM、EM、スクラムマスターと認識合わせ
- 各QAエンジニアに対してインプロセスQAの知見や事例の共有
- 開発チームへの当たり前品質の可視化による意思決定支援
などがありそうです。
QAエンジニアの具体的なQA活動を進めやすくし、開発エンジニアを含めたチーム全体にも働きかけながら自律的な継続的改善を支援することが横断QAとしての役割になると感じています。
顧客から見た当たり前品質を可視化するために
サービス利用時の顧客からの不満がなくなるようにするためには、開発チームでの自律的で継続的な改善が欠かせません。上長との壁打ちも重ねながら、横断QAとしては、以下の役割を担うことで、顧客の不満を解消するための支援をすることを目指しています。
- 指標定義 ：顧客が不満なく安心してサービスを利用するための重要な指標を定義する
- モニタリング ：定義した指標や不満なくサービスを利用できているかを、横断的にモニタリングする
- イネーブルメント/支援 ：各チームに対して、顧客の不満をなくすための施策や活動を横断的に支援する
まとめ
今回、プロダクト品質の観点で横断的に取り組んできたことを、アドベントカレンダーの記事を書くことで改めて振り返ることができました。
振り返ってみて、まだまだ課題が残っていて、伸びしろが大きい状態であることが再確認できました。
顧客にとって不満が発生しないサービスを目指して、引き続き横断QAの役割でできることをしたいと思います。
最後に
アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく
各職種のエンジニアを募集しています。
ご興味ありましたら、カジュアル面談からエントリーいただきたく、よろしくお願いします！
