更新（リニューアル）の通話を想像してください。クライアントは作業に満足しています。ところが、彼らは公正な疑問を1つだけ投げてきます。
「こちらの機能です。これはどんな要件から来たものなのか見せてください。そして、私たちの求めたことを実際に満たしていると証明するテストを。」
テストスイートがグリーンだと分かります。カバレッジが高いとも分かります。そして、実際には答えられないことに気づきます。すばやくでも、根拠をもってでもありません。テストが通ることは示せます。しかし、コードが仕様どおりのことをしていると示すことはできません。
そのギャップは昔はとても小さかった。AIによるコーディングの時代になって、それはいつの間にかあなたのコードベースで最も高価なものになり、ほとんど誰も計測していません。
グリーンビルドが「事実」ではなく「感覚」になった経緯
ソフトウェアの歴史の大部分においては、仕様（spec）・コード・テストはそれぞれ別の頭脳から生まれていました。ある人が要件を書き、ある人がコードを書き、テストは外部のチェックとしてそこに置かれていた。3つがきちんと揃って初めて、その合意には意味がありました。なぜなら、3つの独立した読み取りが収束したからです。
今では、同じモデルが仕様を読み、コードを書き、その場の息つきでテストまで書きます。要件を読み違えれば、コードが間違っているのと同じやり方で、テストもまったく同じ方法で間違っています。テストは通る。すべてグリーン。仕様は壊れているのに、画面はあなたが問題ないと告げます。
テストが通っていた昔は、それが独立したチェックとして「コードは正しい」と一致することを意味していました。今日それは、たいてい「モデルが自分自身と整合している」ことを意味します。あなたのグリーンスイートの多くは、AIが自分の宿題を自分で採点しているだけです。
残酷なのは、この問題を見つけるためにあなたが手を伸ばすあらゆるツールが、すでにその問題によって汚染されていることです。カバレッジはどの行が実行されたかは教えてくれますが、それが正しいことをしているかは決して教えてくれません。テストランナーはコードがテストに一致していることを確認しますが、今まさにそれが疑わしい対象になっています。リンターはスタイルをチェックする。チケットトラッカーはコードに触れません。各ツールは三角形の片側だけ読み、残りの2つを信じます。これまで意味があった唯一の相互チェック、すなわち2つ目の独立した読み取り――それをAIがちょうど削ってしまったのです。
だからあなたは「感覚」で出荷する。請求書は後から、別の誰かの環境で届きます。そもそもきちんと実装されていなかった業務ルール。3スプリント前に要件がズレ、そのまま古いグリーンのテストも一緒に持っていかれた結果。自信に満ちたチームを無言にさせる監査の問い。
まだ意味を持つ唯一の問い
これらすべてを生き残る問いは1つだけあり、チームが通常よく聞くものよりもずっと狭いものです。
この要件について、それを実装している「本物のコード」が存在しますか？そして、そのコードを実際に動かす「本物のテスト」が存在しますか？それはラベルで主張されるのではなく、証拠によって証明されているでしょうか。
すべての要件についてそれに答えられれば、恐れは部屋から抜け落ちます。自己矛盾（タウトロジー）では隠しようがありません。何かを「カバーしている」としか言わないテストは、それだけでは何も証明しないからです。高いカバレッジは弱い部分を埋もれさせることはできません。なぜなら、1つの気持ちいい平均を見るのではなく、要件を要件ごとに読み合わせるからです。ズレは、顧客が見つけた瞬間ではなく、整合が崩れた瞬間に姿を現します。そしてリニューアル通話の問いは、脅威ではなくなります。あなたが画面を向き直して指し示す「証拠の画面」になります。
問題は、通常のツールチェーンの中にはそれに答えるものがないことです。仕様・コード・テストが一致しているかを知るには、それらを別々のものとして読み、相互に照合する必要があります。ほとんどのチームが持っているツールでは、それはできません。
実際に見られるようになると何が変わるのか
これがDQAが存在する理由のすべてです。仕様・コード・テストを3つの独立した情報源として読み取り、要件ごとに、本当に整合しているかどうかをチームに伝えます。
その線――曖昧にできない部分――は「宣言」と「証明」の対比によって確かめられます。「このテストは要件をカバーしています」と言うテストは「宣言」されます。そして「宣言」とは、AIなら一日中で偽装できるものです。証拠によって「実装されている実コード」と「そのコードを実際に動かす実テスト」が存在する要件は「証明」されます。数えるのは証明だけ。これが、モデルが自分の宿題を採点してしまう状況に打ち勝つ唯一のルールです。
返ってくるのは、気分を良くするための別のパーセンテージではありません。単なるリストです。「完全に整合しているもの」「一部だけ整合しているもの」「実際の裏付けが何もないもの」を、最悪の順に並べます。平均によって隠れてしまうのではなく、最も弱い箇所が最初に見えます。
それによってリニューアル通話は別の会話になります。バージョン1は「後で折り返します」で終わり、Jiraの静かな慌ただしさが続く。もう一方は、あなたが画面を向き直して指し示すところで終わる。同じクライアント、同じ問い、まったく異なるビジネスです。
AIは今後数年のうちに新しいコードのほとんどを書いていくでしょう。それがリスクではありません。リスクは、2人目の人間が書いていたときと同じように、グリーンのテストをまだ信頼したまま出荷してしまうことです。
この時代を経ても評判を保って出てくる店は、AIを最速で取り入れたところではないでしょう。そうなるのは、どのコミットでも、どの要件が「実コード」と「実テスト」を背後に持っているのかを、はっきりと言えて、動揺せずにそれを証明できるところです。
では、あなたの最後のリリース。どの要件が実際に整合しているか分かっていますか？それとも、テストが通ったことしか分かっていませんか？
今月、3つの開発会社向けに無料のギャップレポートを実施しています。1つのリポジトリと1つの仕様を送ってください。どの要件が「証明されて整合」していて、どれがそうでないか、そして「カバーしている」だけのテストが実際には何も証明していないものはどれか、こちらから返します。売り込みなし、コミットなし。『gap』とコメントするかDMしてください。
