緑はそれ自体では何も意味しません
CIが緑です。それで何が分かったのでしょうか。
この問いに答えられない緑が数多くあります。通ったという事実だけがあり、通過が何を保証するのかを文として持っている人はいません。この状態でのテストはリリース手順の関門であって、判断の根拠ではありません。関門は通れば忘れられますが、根拠は事故が起きたときに再び取り出されます。
違いはリリース直後に現れます。障害が出れば誰かが必ず問います。これはテストで捕まえられなかったのか。このとき「その領域はもともと検証範囲の外でした」と答えられれば組織は次の決定ができ、「捕まえるべきでした」しか言えなければ同じことが繰り返されます。
存在は示せて、不在は示せない
この分野の出発点は、Edsger Dijkstraが1970年の「Notes On Structured Programming」に残した一文です。プログラムのテストはバグの存在を示すのには使えるが、不在を示すのには決して使えない、というものです。
この文はしばしばテスト無用論と誤読されますが、まったく逆です。テストは証明の道具ではなく証拠を集める道具だという意味です。証拠はどれだけ集めたかではなく、何についての証拠かが重要です。ですからテストを設計する仕事は本数を増やす仕事ではなく、どの主張を裏づける証拠を集めるかを選ぶ仕事になります。
第1回で、判定を実行する仕事は自動化され、判定を設計する仕事は残ると書きました。テストはその文の最もきれいな実例です。良いテストを選ぶのは高く、そのテストを一万回回すのはタダです。
各テストに信頼の一文を付ける
実務へ移す最も安い方法が一つあります。テストごとに一文を付けることです。これが緑なら、私は何を心配しなくてよいのか。
例 — テストに付ける信頼の一文
test_refund_exceeds_payment_is_rejected
-> 決済額より大きい返金がデータベースに記録されることはないと信じてよい
test_order_service_returns_200
-> (文が書けない) これが緑でも心配が減る項目がない
二つめのようなテストは思ったより多くあります。実行はするが何も主張していないテストです。こうしたテストは無いより悪い。本数を埋めて安心させ、その安心の上で判断が行われるからです。
一文を付けていくと副作用が一つ生まれます。同じ文が複数のテストに付くのが見え、それは重複であり、逆にどのテストも付いていない重要な文が見えてきます。その空席が次に書くテストです。
カバレッジが測るものと測れないもの
カバレッジは有用で、しかしよく誤読されます。カバレッジが測るのは、テスト実行中にその行を通ったかです。その行の結果を検査したかではありません。
アサーションが一つもないテストもカバレッジを上げます。例外が出なければ通るからです。だからこの数字は上方向にはほとんど意味を持たず、下方向にだけ意味を持ちます。二十パーセントなら確かに足りないという情報がありますが、九十パーセントという数字に安全だという情報はありません。
もっと使える信号は別にあります。直近の障害が通ったコード経路にテストがあるか、取り消せない動作にテストがあるか、そして不安定なテストが何本あるか。最後のものが特に重要です。たまに赤くなるテストがあると、人は赤を無視することを学び、その学習はそのテストだけに留まりません。
検証しないと決めたものを書く
この記事で最も実行しにくく、最も価値のある項目です。何を検証したかではなく、何を検証しないと決めたかを書くことです。
すべてを検証することはできないので、どのチームもすでにこの選択をしています。ただ暗黙に行っているため、誰もその選択を検討しません。明示的に書くと三つのことが起きます。
一つめ、事故が起きたとき、それが既知のリスクだったのか未知のリスクだったのかが区別できます。二つめ、リスクを取る決定が個人の判断からチームの決定へ上がります。三つめ、検証しない一覧を人に見せると反発が出て、その反発が本当に重要な項目を教えてくれます。
形式は単純でかまいません。今回の変更で検証したもの三行、検証しなかったもの三行、検証しなかった理由一行で十分です。
判定基準のない領域
いま最も難しい領域は正解表のない側です。検索結果の品質、推薦の適切さ、生成されたテキストの有用さ。ここでは合否に分かれるテストが使えません。
このとき必要なのはテストではなく判定の設計です。三つの軸があります。
まず基準セットです。人が判定した事例を集めて固定したセットにしておきます。大きくなくてよいが、難しく争いのある事例が入っていなければなりません。易しい事例ばかり集めると、何を変えても点数が動きません。
次に代理指標です。測りたいものが測れないので隣のものを測ります。このとき必ず一緒に書くべきなのは、この指標がどうすれば騙せるかです。騙す経路を先に書いておかないと、いつかその経路で指標が上がり、誰も気づきません。
最後は標本レビューです。自動判定が不可能な部分は、定期的に人が標本を見ます。ここで重要なのは良いものを見ることではなく無作為に引くことです。選んで見ても何も学べません。
手を動かす
今週、自分が最近書いたテストを五本開いて、それぞれに信頼の一文を付けてみてください。書けないものが一本でも出れば、それがこの記事で最も重要な発見です。
- SLO・エラーバジェット計算機 — 安定性を目標ではなく予算として扱うと、どれだけ検証するかが計算問題になります。
- 論理トレーニング — 必要条件と十分条件を区別する練習が入っています。テストが何を保証するのかを正確に言うのと同じ構造です。
通じない場合もあります。要求が毎週変わる探索段階で厚いテストを敷くと、テストが変更を阻む壁になります。この段階では取り消せないものにだけ検証を付け、残りは空けておくほうがよい。検証の密度はコードの重要度ではなく、取り消しコストに従うべきです。
続けて読む
- このブログの関連記事: PoCはなぜ本番にたどり着けないのか — 成功基準、セキュリティレビュー、引き継ぎ
高いまま残る技術シリーズ
参考資料
- Edsger W. Dijkstra 引用集 — Wikiquote — プログラムのテストはバグの存在を示せても不在は示せないという一文の出典は1970年の「Notes On Structured Programming」(EWD249)です。2026-08-15閲覧。
- 信頼の一文、明示的な非検証一覧、判定設計の三つの軸は上記資料にあるものではなく、この記事で整理した手順です。
현재 단락 (1/36)
CIが緑です。それで何が分かったのでしょうか。