QAをやめて、QAをはじめる──欠陥検出0件が続いた組織で、品質保証の重心を3回動かした話

こんにちは。Ai Workforce事業部でQAグループのマネージャーをしている山本です。

最近、週次スプリントのテストでバグが見つからなくなりました。

テストの運用は続けているのに欠陥が検出されない。年初から春にかけては検出があったのに、5月下旬以降は欠陥検出0件のリリースが続いています。

QAチームとしては喜ぶべき話のはずです。でも、正直に言うと落ち着きません。

なぜなら、本番のインシデント報告がなくなったわけではないからです。今起きている問題の中心は、環境差分や設定、運用、基盤、外部サービスとの連携といった、従来の確認型テスト（仕様通りに動くことを確かめるテスト）では拾いにくい領域にあります。報告された問題には一つひとつ対応し、再発防止までのサイクルを回しています。ユーザーへの影響が大きい障害が増えている、という話ではありません。それでも、リスクの中心がテストの外側にあるという事実は残ります。

課題が消えたのではなく、リスクの場所が移った──そう捉えると実感に合ってきます。

テストでバグが見つからなくなったとき、QAチームは何をすべきなのか。入社からの10ヶ月をリアルに振り返りながら、この問いへの今の答えを書いてみます。

入社後10ヶ月でやってきたこと

2025年10月：テストの前に観測からはじめた

私は2025年10月に、Ai Workforce事業部の一人目QAエンジニアとして入社しました。

当初から、将来的には人が繰り返し実行する確認型テストは圧縮し、自動化やAI駆動のテスト基盤に寄せていく前提で考えていました。

ただ、実際に最初に手を入れたのは、テストではなくて、インシデント対応の運用です。

既存のマニュアルを運用に耐えられる形に改修し、重大度の定義や報告フローの統一、対応履歴の集約、ポストモーテム（振り返り）の運用などを整えていきました。

理由はシンプルで、本番で何が起きているかが見えなければ、どんなQA体制が正しいのかを判断できないからです。戦略は観測なしに設計できません。振り返れば、これが最初の重心移動でした。テストではなく、まず観測に重心を置いたのです。

一つ断っておくと、この時期にインシデント報告の件数が増えたのは品質が悪化したからではありません。事業のフェーズが移行するタイミングでもあり、それまで開発者が個別に対応していた事象もインシデント報告として記録し始めたためです。

見えるようにしたから、見えた。それだけのことですが、すべてはここから始まりました。

2025年12月：検出の網を厚くした

可視化されたインシデント報告が示していたのは、新機能への欠陥混入と、既存機能に潜む欠陥の顕在化でした。事業のフェーズが進み、これらを許容できなくなってきたことを受けて、12月には実装後〜リリース前に欠陥を見つけるためのテスト活動を一気に厚くしました。

機能テスト・回帰テスト・ストーリーテスト（受け入れ条件をシナリオ化したテスト）といった確認型のテストに加えて、探索的テストも行いました。ステージング環境では、既存の主要フローを定期的に確認するテストも実施しています。

PRやスプリント単位で必要な確認をかなり厚めに回して、開発者側のテストと一部重複するような設計にしました。また、社外のパートナーにも協力してもらいリソースを確保しました。

一時的にスピードの低下や重複確認を許容してでも、まずは検出の網を厚く張るという判断です。

また、この時の設計ドキュメントには初めから、本番流出を防いでいる間にプロセスを改善し、問題が収束したら過剰なテストは圧縮してAI駆動に移行する、という趣旨の出口条件も書いていました。

これが2回目の重心移動──観測から、検出へ。

2026年春：検出が減っていった

検出の網は機能していて、1月から3月前半までは、テストでリリース前に修正すべき欠陥を検出していました。

変化が見え始めたのは春です。3月後半から欠陥検出0件のリリースが混じり始めて、4月上旬や5月中旬に一時的な検出を挟みながら、5月下旬以降は検出0件のリリースが続きました。6月は確認型テストのシナリオを252件実行して、欠陥検出は0件でした。

テストの運用は続けていたので、少なくとも「テストを減らしたから見つからなくなった」というだけでは説明できません。

12月に出口条件を書いたときは、QAチームがプロセスを改善し、その結果として欠陥が減っていく展開を想像していました。ところが、実際に起きたことは少し違っていて、ある週の品質分析をしながら「また0件。これは私たちの成果と言っていいのだろうか？」と立ち止まりました。

気づかないうちに、欠陥がテスト工程まで届きにくくなっているように見えたのです。

なぜ見つからなくなったのか

浮かれないための原則から確認させてください。ソフトウェアテストの技術者資格認定を行うJSTQBが示す、テストの原則にこういうものがあります。

テストは欠陥があることは示せるが、欠陥がないことは示せない。
（出典：JSTQB Foundation Level シラバス Version 4.0、p.18）

つまり、欠陥検出0件は「品質が完成した」ことの証明ではありません。実際にテストでの検出が0件だった6月も、本番側では環境差分や設定・運用に起因する問題が観測されていて、その結果をもとに改善を続けています。品質リスクがなくなったわけではありません。

話を戻して、では、なぜ従来のテストで欠陥が見つからなくなったのか。開発メンバーとも議論したところ、品質が改善した可能性を説明する仮説は、大きく2つに整理できました。

ひとつは、検証の実行点が上流に寄ったこと。3月頃からコードレビューでの指摘をルール化し、CI上のガードレール（自動チェック）へ移す取り組みが開発者側で進み、チェックの範囲も徐々に広がっていきました。それまではテスト工程で捕まえていた種類の欠陥が、コードがマージされる前に機械的に検出される。テストに届く前に除去されている可能性です。

もうひとつは、そもそも欠陥の混入自体が減っていること。開発に使うAIモデルの進化や、セルフレビューの定着によって、作り込みの段階で問題が入りにくくなっている可能性です。

一方で、都合の悪い仮説にも触れておきます。実装と同じコンテキストでAIがテストを作ると「通るテスト」しか書かれないのではないか──検出が減ったのは、品質が上がったからではなくて、テストが欠陥を見つける力を失ったのではないか、という確証バイアスの懸念です。ここは独立した観点での探索や、本番インシデントとの突き合わせを続けながら、今後も注意して見ていきます。

では、どの要因が、どれだけ効いたのか。現時点では、AIモデルの進化やセルフレビューと欠陥検出減少との因果関係を示せるだけのデータはありません。原因は仮説です。でも現象は観測です。数字として確かに起きているのは、確認型テストでの欠陥検出が減っているということ。

そこから私たちは、従来の確認型テストで拾いやすかった種類の欠陥が、テスト工程に届きにくくなっていると捉えています。

テストはコンテキスト次第

JSTQBのテストの原則には、テストはコンテキスト次第、という言葉もあります。

12月に検出の網を厚く張った判断は、当時の状況では正しかったと今でも思っています。観測を整えた直後で、リスクの全体像がまだ見えておらず、欠陥は実際にテストまで届いていました。

でも、状況は変わりました。テストの運用を続けても、追加で得られる検出の価値は小さくなっています。変わったのは私たちの信念ではなく状況の方です。

念のため強調しておくと、これは「従来型のテストはもう不要」という話では全くありません。レビュー指摘を自動チェックへ変換していくサイクルや、CI上のガードレール、セルフレビューの文化、本番の観測…こうした前提が揃っていない組織では、確認型テストは今も重要な防御線のはずです。テストの価値は、事業のフェーズと開発環境次第で変わる。私たちの状況では下がった、ということだけです。

そして、やることはテストをやめることではなく、品質保証活動のポートフォリオの組み替えです。

減らすのは、人が手で繰り返し実行する確認型のテスト。開発者・CI・ガードレールなどと重複している手動の確認です。増やすのは、CI上で自動実行される回帰テスト。そして、探索的テスト、仕様やユースケースへの批評、リリース後の観測設計といった、今はまだ人が価値を出しやすい領域です。

特に、未知のリスクを探しにいく探索的テストはリスクの移動先と相性がいいと考えていて、より明示的な仕組みとして設計し、試験運用を開始しています。

QAを直列化点にしない

組み替えを考えるうえで、体制の現実にも触れておきます。

今のAi Workforce事業部では多くのプロジェクトが並列で走っていて、すべてのプロジェクトにQAチームが張り付く形を取ると、大幅な体制拡充が必要になる見立てでした。

誤解のないように書くと、プロジェクトの中にQAチームのメンバーが入り込むこと自体を否定しているわけではなく、高リスクな変更やプロジェクトなど、QAチームが入る価値が高い場面は確かにあります。選択しなかったのは、全プロジェクトへの全面展開です。

理由は、単に人数やコストだけではありません。テストは仕様の理解が前提として必要です。並列に走るプロジェクトの仕様理解をQAチームが一手に引き受けると、QAチームが開発全体のボトルネック──流れを堰き止める直列化点──になり、スループットの上限がQAチームの理解速度で決まってしまいます。少なくとも私たちの状況では、追加の検出価値が小さくなっている活動を、人員増によって全プロジェクトへ展開する投資は成立しにくいと判断しました。

「QAチームもAIを使えば速くなるのでは？」と思われるかもしれません。使っています。テスト計画・設計・実行では、個々の作業は圧倒的に速くなりました。ただ、AIのアウトプットが正しいかを判断するには、結局人間の仕様理解が必要です。そのため道具として局所的に使うだけでは、QAチームが直列化点になりうる問題は解けませんでした。AIをより大局的に使う取り組みも始めていますが、今回の本筋からは外れるため、ここでは深掘りせず、次回以降のブログなどで共有できればと思います。

「価値を判断できる状態」を設計する

ここで、私がずっと考えてきたことを書かせてください。

まず前提として、QAチームは単独では品質を作れません。品質は、企画・仕様・設計・実装・リリース・運用・ユーザー利用という連鎖の中で作られます。その連鎖のどこにリスクがあり、どこに仕組みを置くべきかを問い続け、品質リスクと残存リスクを判断できる形で可視化することが、QAチームにできることでもあり、やるべきことだと考えています。

そして、品質は作り込むものですが、それが本当に価値を持つかどうかは、ユーザーの利用文脈の中で決まります。

「仕様通りに動くのか？」の確認が仕組みへ寄っていくなら、人間はその先──「この仕様は、本当にユーザーの価値になっているか？」に踏み込むべきです。

といっても、QAチームが「価値の検査人」になるわけではありません。それでは検査の対象が仕様から価値に変わっただけです。価値を確かめる主体はユーザーや現場であって、QAチームはそれが判断できる状態──基準・観測・証跡を設計する側に回ります。

いま進めているのは、たとえば「この機能が価値を出せているかは、リリース後にどの数字を見れば分かるのか」を、機能が世に出る前に関係者と決めてしまうことです。プロダクトへの期待を、後から検証・観測できる形に翻訳しておく、と言ってもいいかもしれません。受け入れテスト（リリース前の最終確認）も、QAチームが代わりに実行する確認作業ではなく、現場に近いメンバーが主体となって価値を確かめる場として設計し直しています。最初の重心だった「観測」へ、より高い解像度で戻ってくる話でもあります。

観測、検出、そして価値の検証へ。3回目の重心移動は、いままさに動かしている最中です。

QAをやめて、QAをはじめる

私がこれまで経験してきたソフトウェア開発の現場では、「QA」と呼ばれる役割が、製品の検査に近い活動を中心に担うケースもありました。テストを作り、実行し、仕様と実装のギャップを見つける。私自身そのような現場での経験も数多くありますし、「最後の砦として本番流出を防ぐぞ！」という気持ちは持ち続けています。

けれど、QAを標準的な意味に寄せて考えるなら、それは検査そのものではなくて、品質要求が満たされるという信頼感を作る活動です。仕組みを設計し、証跡を残し、リスクを見えるようにして、関係者が大丈夫だと判断できる状態を作ること。

テストでバグが見つからなくなったいま、私たちがやろうとしていることは、何か新しいことの発明ではないのだと思います。検査は、これからも品質保証を支える重要な活動です。そのうえで、QAという営みを人手による確認作業と同一視することを、私たちはやめる。検査の比重を状況に合わせて動かして、仕組みと証跡によって、関係者が品質を判断できる状態を作る。

その意味で私たちは、これまでのQAをやめて、あらためてQAをはじめていきます。

Ai Workforce事業部のQAグループは、少人数のチームで、この重心移動の真っただ中にいます。少人数だからこそ、テストを増やすかどうかではなく、どこに品質リスクがあるのかを毎回問い直しています。

10ヶ月で重心は3回──およそ3ヶ月に1度のペースで動いたことになります。少なくとも私たちの現場では、AI活用の広がりとともに、開発も事業も、状況が変わる速度は明らかに上がっています。

この先は、これまでの経験則では捉えられない、AI時代ならではの品質の問題も起きるかもしれません。だからこそ、重心をひとつの場所に固定せず、状況を観測し、判断し、動かし続けること。それ自体が、AI時代の品質保証の戦略なのだと思っています。次にどこへ動くのかは、きっとまた状況が教えてくれるはずです。