【第5回】品質は一つのテストで決まらない——信頼を層で積み上げる「多層バリデーション」

本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）

「何をテストするか」ではなく「信頼をどう積み上げるか」

多層バリデーションを、テスト項目のチェックリストだと思うと本質を外す。これは品質への信頼を、どの段階でどう積み上げるかの設計だ。

品質は、どこか一つのテストで「合格／不合格」が決まるものではない。仕様の妥当性から本番での価値まで、問いの異なる複数の層が連続し、少しずつ信頼を重ねていく。下の層は、上の層が築いた信頼の上に積み上がる。

4つの層は、それぞれ違う問いに答える

• Layer 1：仕様バリデーション——「作ろうとしているものは、正しいか」
  仕様そのものがビジネスの意図（③）を正しく反映しているかを、上流で確かめる。テスタビリティ審査、BDDによる受入条件化、設計書横断の矛盾検出、非機能要件の数値化。ここで②のうち形式化できる分を①へ引き上げておく。（→第3回のShift Left）

• Layer 2：生成コードバリデーション——「仕様どおりに、作られたか」
  ①設計書適合の確認。CI/CDに仕様準拠チェックを組み込み、アーキテクチャ制約をハーネス化する。AIが最も加速する層だ。

• Layer 3：振る舞いバリデーション——「仕様にない"当たり前"は、満たされているか」
  ②暗黙要件のカバー。前回のQEハーネスが主役になる層で、テスト技術チェックリストや非機能基準をガイドに、エッジケースの網羅や障害注入で確かめ、ミューテーション検証でテスト自体の有効性を測る。（→第2回・第4回）

• Layer 4：継続的バリデーション——「現実で、価値を生むか」
  ③本質要件の継続検証。Reference Oracle（DSDT・現行システム・本番データ）との比較、本番の業務サイクルを再現・疑似再現したテスト、カナリアリリースやカオスエンジニアリング。最後の安全網になる層だ。（→第3回のReference Oracle・Shift Right）

層は独立ではなく、つながっている

各層は切り離されていない。Layer 1の仕様バリデーションが後続層の前提になり、Layer 4で本番から得た学びはLayer 1へ還る。形式化できる②はLayer 1で引き上げ、しきれない②はLayer 3で、③はLayer 4で補う——という役割分担になっている。

ここにAI時代の見取り図がある。AIはLayer 1〜2（①）を劇的に加速する。だが品質はそこで終わらない。Layer 3（②）とLayer 4（③）を、QEハーネスとReference Oracle、そして人間の判断が担う。多層で見ると、AIの速度がどこに効き、人間の判断がどこに残るかがはっきりする。

まとめ

多層バリデーションは、「単一の正解を一回のテストで探す」発想から、「信頼を層で積み上げる」発想への転換だ。①はLayer 1〜2で、②はLayer 1とLayer 3で、③はLayer 1とLayer 4で——と、3軸の打ち手が層として連続して機能する。AIの加速を取り込みつつ、抜けやすい②③を構造として担保する。これが、品質を作り込むための全体設計である。

次回（第6回・最終回） は、この多層の設計を「誰が担うのか」——②③を統合し品質の成立に責任を持つ役割「QEアーキテクト」——を扱います。

▼連載の全体像と各回へのリンク（連載インデックス）

本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com