- はじめに
- 背景
- QAプロセスと、その「成熟度」とは？
- 最初に始めたこと
- 最初の失敗
- 最初の失敗からの改善
- 振り返り
- 子育てにも通じる点
- 書籍で紹介されているアプローチと比較して
- 今後の課題と展望
- 最後に
はじめに
アソビューでQAリーダーをしている渡辺です。
リリーススピードを重視している開発組織において、品質改善のためのプロセス改善をどう実践し、推進していけば良いか、悩むことはありませんか？（私自身も、まさにその一人です）
今回のテックブログは、品質向上/維持に関連する開発プロセスの成熟度（※以降、QAプロセス）を向上させるため、各開発チームリーダーやQAエンジニアと連携しながら施策を進めた際の振り返りとなります。
実践してみて、思い通りにいかなかったことも含めて率直に書いています。
- QAプロセス改善に取り組みたいけど取り組んでいないQAエンジニア
- QAエンジニアとの関わりに悩む開発リーダー / エンジニア
上記のような方々が、今後プロセス改善を実践する上で、少しでも参考になれば幸いです。
背景
まず、現在のアソビューにおけるQAを取り巻く状況をご説明します。
品質担保がシステムテストに偏重している
開発チームごとに差はあるものの、エンジニア間のコードレビューは行われており、局所的ですが単体テスト（UT）や結合テスト（IT）[1]も実施しています。
しかし、不具合傾向を分析[2]した結果、設計段階での影響分析や考慮不足に起因する不具合や、UT/ITといった初期段階のコードベーステストで防げるはずの不具合が多いことが分かりました。
これらの不具合もシステムテスト[3]で一定検出はできていますが、実装に起因する不具合をホワイトボックスの観点ですべて検出するのは現実的ではありません。
そのため、実装起因の不具合が本番環境に流出しやすい状況にありました。
また、システムテストでは、顧客にとっての利便性の低下や、エッジケースにおける重大な問題の検出もまだ十分とは言えない状態です。
「シフトレフト」で品質を作り込みたい
シフトレフトとは、要件定義や設計といった上流工程から品質を重視し、早期に欠陥を発見・修正することで、後工程での手戻りやコスト増大を防ぐ考え方です。
前述の課題から、システムテストの負荷が増大し、テストがボトルネックとなってリリース遅延を招きやすい状況でした。
UT/ITで検出できる不具合はそちらで検出し、システムテストの全体ボリュームは少し減らしつつ、重大な障害につながりかねないエッジケースのテストを拡充したい。
さらには、顧客から見た利便性悪化をもっと検出できるような、これまでとは異なる観点のテストへと進化させたいと考えてました。
テストだけでなく、要件定義や設計の段階で検出できる問題は、早期に潰しておきたいという思いもあります。
特に、負荷やパフォーマンスといった非機能要求は、後工程で問題が発覚してもすぐに対応できないケースや、機能面でも既存仕様への影響把握が不十分だと大きな手戻りコストが発生することがあります。
現在のQA体制
過去ブログ：
開発とQAの円滑な関係性の構築のために - asoview! Tech Blog
でも紹介しておりますが、
現在、アソビューではQAチームという独立した組織はなく、QAエンジニアが各開発チームに所属しています。
以前は、ステージング環境でのブラックボックステストの設計・実行がメイン業務であり、テスターに近い役割でした。
しかし、約1年前にチーム編成が見直され、開発エンジニアとQAエンジニアが協働して品質改善活動に取り組んでいくという方向性については、すでに合意が取れています。
図：1年前のQA方向性提示（プロダクトが成熟期に当たる2チームで共有）
QAプロセスと、その「成熟度」とは？
「QAプロセス」と聞くと、QAエンジニアが主体となるテスト活動をイメージされがちですが、この記事では「開発プロセス全体の中で、品質の向上・維持に結びつく一連のプロセス」を指します。
そして、チームがそのプロセスを自律的に遂行できる能力の度合いを「QAプロセス成熟度」と表現しています。
今回の改善活動では、このQAプロセスと成熟度レベルを定義し、測定することにしました。
その背景とねらいは以下の通りです。
現状（As-Is）とあるべき姿（To-Be）の可視化
品質のシフトレフトを実現するために、まず現状を可視化し、どのプロセスに課題があるかを明らかにすることで、改善を進めやすくするため。チーム間の連携促進
共通の指標を設けることで、自チームの成熟度が低いプロセスについて、他チームに相談したり、施策を共有したりしやすくするため。
このQAプロセス成熟度を向上させることは、開発生産性の指標であるFour Keys（特にMTTRや変更失敗率）の向上・維持にも繋がると考え、施策をスタートしました。
最初に始めたこと
CTOとの1on1で方向性を確認しながら、まず以下の3点から着手しました。
- 成熟度のプロセスレベル定義と、対象チーム選定
- 開発チーム内QAと、開発チームリーダーへの共有
- As-Is（現状把握）とTo-Beの設定
最初の失敗
まず、定義したプロセスレベルとAs-Is/To-Beについて開発チームリーダーやマネージャーに共有したところ、早々にいくつかの壁にぶつかりました。
チーム内の状況のばらつき
プロセスレベルの一部は、QAエンジニアが主体的に動く前提で定義していました。
しかし、スクラムチームにQAエンジニアが不在のケースもあり、定義をどう扱えば良いか分からず、アクションに繋げにくいという問題がありました。「QAのためのプロセス」という誤解
例えば、受け入れ基準（Acceptance Criteria）の作成は、設計・実装段階での品質作り込みが目的です。
しかし、導入が進んでいないチームでは「QAのテストのために必要なもの」という誤解が生じ、本来の目的が伝わっていませんでした。全体像とゴールの見えにくさ
どのプロセスレベルの向上から手をつければ良いのか、全体像やゴールまでのステップが分かりにくく、アクションに繋げにくいという指摘を受けました。「最高レベルを目指すこと」への懐疑
全チームが最高レベルに達することをゴールとしていましたが、「それが本当にプロダクト品質の向上に繋がるのか？」と懐疑的なチームもありました。
これは、かつてCMMI[4]で言われた「最高レベルの達成が、必ずしも顧客満足度に直結するとは限らない」というジレンマに似た状況だったのかもしれません。
過去の職場の経験から、チーム横断の施策がすんなり進まないことは分かっていました。
ただ、その当時は組織文化がアソビューとは異なり、親会社からのトップダウン指示と現場の乖離が大きい状況でした。
さらに、全く別のプロダクト／プロジェクトでの横断施策であり、しかも受託開発案件だったため、うまくいかないのは当然ともいえる背景がありました。
今回は意見を受け入れやすいアソビューの開発文化であり、同じ事業会社の関連性の高いプロダクト間での施策だったため、正直なところ「以前よりはスムーズに進むだろう」と少し安易に考えていました。
この反応は想定外でした。
ただ、これは各チームが自律的に課題と向き合っていることの表れだと感じました。
また、特定のチームの意見を元に、最初は抽象的だった基準を具体化しHow-To寄りに修正すると、他のチームからは「かえって自チームのやり方には合わない」という声が上がるなど、一つの正解がない難しさも痛感しました。
最初の失敗からの改善
これらの失敗を受け、上長であるCTOと相談しながらレベル定義をアップデートしました。
表1：QAプロセス成熟度 - アップデート概要
| アップデート概要 | 理由（なぜ？） | ねらい |
|---|---|---|
| QA主体のような表現を避ける | 開発とQAの分断を避けるため。 | チーム全体で品質を担保するプロセスであることを明確化する。 |
| How-Toから「課題・目的」ベースへ | How-Toの提示は、チームが自律的に考える機会を奪う可能性があるため。 | レベルごとに「達成しない場合の課題」と「達成目的」を明記し、チームに合ったやり方を選択できるようにする。 |
| 最高レベルを「必要最適限」に見直し | 全チームにとって最高レベルが本質的な課題解決に繋がるとは限らないため。 | どのチームでも達成効果が見込める「共通で品質に影響する最低限のレベル」に設定し直す。 |
表2：QAプロセス成熟度 - プロセス定義とレベルの一例（アップデート後）
（◯◯◯：一部情報をマスキングしてます）
| 開発プロセス | QAプロセス | レベル | 課題 | 目的 | プロセスレベル状態定義 |
|---|---|---|---|---|---|
| 要件定義 | 要件・仕様レビュー | 1 | していない | ||
| 2 | 要件/仕様レベルの不具合の手戻り | 追加・変更仕様と既存仕様の不整合を早期に発見 | 開発者のみでやっている状態 | ||
| 3 | 案件別の顧客利用時の問題の本番流出と運用コスト | 顧客利用時の仕様不備、利便性低下を早期に発見 | 多角的視点を入れて顧客の声を元に要件・仕様策定をしている状態 | ||
| リリース基準 | 1 | していない | |||
| 2 | 機能面の不具合の本番流出 | 機能面の品質問題がない状態でリリースする | ◯◯◯ | ||
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| 設計 | 設計レビュー | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ |
| ： | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| 実装 | コードレビュー | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ |
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| UT, IT実行 | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ | |
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| QA | システムテスト | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ |
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| その他 | 不具合分析・改善活動 | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ |
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ | ||
| 顧客からのFB対応 | ◯◯◯ | 1 | ◯◯◯ | ◯◯◯ | ◯◯◯ |
| : | ◯◯◯ | ◯◯◯ | ◯◯◯ |
また、開発チームリーダーと何度も認識合わせを実施したり、具体的に以下の2つの行動をしました。
特定チームへの個別アプローチ
あるチームでは、設計レビュー以前に「影響範囲の確認」自体が難しく、それが不具合の原因となっていました。
そこで、XDDP派生開発プロセス[5]の考え方を参考に、アジャイル開発、かつWebサービス開発に馴染むような具体的な設計プロセスを検討し、リーダーに提案しました。
当初の施策定義からは少し外れますが、チームごとの課題に向き合った解決策を目指した行動は、少し信頼関係の構築に繋がったかもしれません。課題/目的ベースで根気強く認識合わせ
再定義したプロセスについて、開発チームリーダーとの読み合わせを重ねました。
疑問に答えつつ、いただいたフィードバックを元に持ち帰り検討する、というサイクルを繰り返し、最終的に成長期のプロダクトを持つチーム以外とは目的やゴールについて合意形成をすることができました。
もちろん、品質改善はQAプロセス成熟度の向上だけではありません。
SET（Software Engineer in Test）が主導するテスト自動化基盤の整備や、各チームが自律的に進めるアジャイル改善、SREチームと連携したSLO改善など、開発組織全体で連動し協力しながら取り組んでいます。
このQAプロセス改善施策は、それらの活動の中で「まだ足りていない視点を補うもの」であり、正直なところ、まだ伸びしろのある状態です。
顧客にとっての品質は常に変化します。その変化を追いかけながら、チーム横断での改善を継続していきたいと思います。
振り返り
チーム横断で施策を進めるには、各プロセスレベルが「どのチームにとっても品質改善に繋がる」ように、抽象と具体のバランスを適切に設定する必要がありました。
まず、開発チームリーダーの納得を得られない限り、チーム全体を巻き込むことは困難です。
そのためには、各チームの現状（As-Is）を深くヒアリングし、その上で成熟度を上げることが改善に繋がるようなプロセスを設計し、それを丁寧に説明し続ける必要がありました。
今回、プロダクトの成熟度が異なる複数チームで施策を推進しましたが、最後まで納得を得るのが難しかったのは、成長期のプロダクトを持つチームでした。
一方、成熟期のプロダクトを持つチームとは、何度も対話を重ねることで、最終的に施策に納得いただくことができました。
成長期に当たるプロダクトからは、プロダクトの成熟度もそれぞれ異なるため、抽象度の高い品質方針を提示してもらう方がチームが自律して改善を進めやすいという意見もいただきました。
そのような中で、なぜこのチーム横断で共通施策が必要なのかは納得していただくまで話しあう必要があり（詳細はここでは触れませんが）、最終的にはCTOも同席いただき、CTOからも施策について直接メッセージをいただきながら、開発チームに納得いただきました。
子育てにも通じる点
私には3人の子どもがいますが、今回の経験は子育てと似ていると感じました。
年齢も性格も興味関心も異なる子どもに、同じやり方を当てはめてもうまくいきません。
それぞれの年齢、性格を踏まえ、個人の思考や興味を深く理解した上で、それぞれに合った接し方が必要になります。
プロダクト開発チームもチーム毎に状況や課題が異なります。
それぞれのチームの背景や課題を深く理解し（解像度を高め）、その上で共通項を見つけ出し、チームの特性に合ったアプローチや説明を個別に行う必要がある点は同じでした。
当初、私は「まず特定のチーム（QAプロセス改善の必要性が一番高いチーム）の現状のプロセスと課題を深く理解し、このチームの解決策につながるプロセス設計から入り他のチームにも横展開するアプローチを取りました。
しかし、やはりチーム毎に状況や課題が異なるため、「各チームの現状のプロセスと課題をしっかり理解した上で、抽象度を一つ上げてチーム毎の共通項を洗い出した上で、チーム特性にあったアプローチや説明をする」
という方向性に途中から変えていきました。
これにより、最初に施策展開した時よりも合意が得やすくなりました。
書籍で紹介されているアプローチと比較して
品質リーダーに向けた書籍「LeadingQuality」には、プロダクトの成熟度と、それに合わせた品質に対するアプローチは常に進化させていく必要があるとあります。
また、品質文化醸成のためにまず最初にすべきこととして、「誰を味方につけるかを知り、関係者それぞれのモチベーション、目的、恐れているものをそれぞれ理解した上で、チーム同士・メンバ同士の共感を生み出して連携と相互理解を深めること。」とあります。
今回、私に欠けていたのはまさにこの視点でした。途中からこのアプローチを意識することで、状況が改善していったことを考えると、この書籍で語られるアプローチの重要性を身をもって証明した形になったと感じています。
今後の課題と展望
今後の課題として以下を検討したり、推進していくことで、プロダクト品質改善における全体の最適化が進んでいくのではないかと感じています。
事業目標をブレークダウンしてプロダクト品質向上 / 維持の視点に落とし込んだ時に何ができるのか、何を求められているのかを自問し、チームとの対話を重ねながら行動していきたいです。
QAエンジニアとしては、テスト以外で貢献できることは増えてきましたが、できていないこともまだまだ沢山あります。
タスクに没頭してこの大局を見失わないよう、気を引き締め、プロダクト品質の改善 / 維持に繋がる行動を続けていきたいと思います。
最後に
アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく
各職種のエンジニアを募集しています。
ご興味ありましたら、カジュアル面談からエントリーいただきたく、よろしくお願いします！
脚注
参考文献
