【第3回】「正解」が存在しないものをどうテストするのか——③本質要件とReference Oracle

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

③のオラクル問題は、②よりさらに深い

③本質要件とは、そのシステムが本当に実現したいビジネス上の目的・ユーザーの真の狙いのことだ。

②は「書けば書ける」ものが少なくなかった。だが③は、書こうとしても唯一の正解が定まらない。ビジネスの意図は文脈に依存し、関係者によって解釈が揺れ、現実は刻々と変わる（開かれた世界）。「この出力が正しい」と一意に言えないからこそ、テストの期待値＝オラクルが立てられない。これが③のオラクル問題だ。

では、正解が定義できないものを、どうやって検証するのか。本編では3つの経路で③に迫る。

経路1：書けるところは、先に書く（Shift Left）

まず、③の中でも形式化できる部分は、上流で形式化してしまう。これを最優先に置く。

• 仕様が③の本質（ビジネス意図）を正しく反映しているかを、ドメインエキスパートとともに評価する（テスタビリティ審査）

• 開発者・テスター・業務側が仕様策定の段階から共同で③を作り込み、「Why」を直接対話で体得する

• ビジネス意図を Given / When / Then の受入条件に落とし、検証可能にする（BDD：Behavior-Driven Development／振る舞い駆動開発）

ここで形式化できた分は、オラクルを持つ①の領域へ移り、機械的に検証できるようになる。③を丸ごと諦めるのではなく、まず「①にできる③」を最大化するのが起点だ。

経路2：正解の代わりに「正解を体現するもの」と比べる（Reference Oracle）

それでも形式化しきれない③が残る。ここで効くのが Reference Oracle という考え方だ。

明示的な期待値が立てられないとき、③を体現している"何か"を「正」とみなし、それと比べて妥当性を判断する。たとえば現行システムの挙動、本番データの分布や実際のユーザー行動、運用実績。これらを束ねて参照基盤にしたものを、本編では ドメインシステムデジタルツイン（DSDT）と呼ぶ。

「正しい答え」を書き下せなくても、「正しく振る舞っているもの」が手元にあれば、それを物差しにできる——これがReference Oracleの発想だ。マイグレーションで現行システムを正とするのは、その典型である。

経路3：最後は本番で確かめ続ける（Shift Right）

設計・テストで見切れない③は、最終的には本番が確かなオラクルになる。カナリアリリースやA/Bテストでリスクを抑えながら確認し、本番のテレメトリ（実運用データ）をテスト設計に還流させ、カオスエンジニアリングで継続的に揺さぶる。

ただし「本番で試す」という発想は、日本の業務システム開発ではそのまま受け入れられないことも多い。その場合の代替として本編が挙げるのが、本番投入前に本番相当の条件を手元に作って確かめるやり方だ。本番の業務サイクル（日次バッチ→月次締めといった一連の流れ）を再現・疑似再現するだけでなく、本番と同じトランザクション分布・ボリューム・頻度・並行処理で業務シナリオを流す。これをReference Oracleとして、業務全体が期待どおり回るかを検証する。流れだけを真似ても弱く、本番のデータパターン（偏り・組み合わせ・量）まで再現してはじめて、本番で実際に起こりうる事象を投入前に検証へ織り込める。本番そのものに頼り切らなくても、Shift Rightの狙いの多くは前倒しで取り込める。

最後に判断するのは、人間

これら3経路を尽くしても、③の最終判断はAIには委ねられない。AIはReference Oracleとの「差分」を検出できる。しかし、その差分が③の充足を本当に損なうのか——その見極めは、ビジネスのWhyを理解するドメインエキスパートの責務だ。AIに差分の検出を任せ、人は「それが重要か」を判断する。役割分担はここにある。

まとめ

③は、ひとつのテストでは決められない。①にできる分は先に形式化し（Shift Left）、できない分はReference Oracleと突き合わせ（DSDT）、残りは本番で確かめ続ける（Shift Right）。そして最後の判断は人間が引き受ける。正解が存在しない領域の品質は、「単一の正解を探す」のではなく、こうした層を設計して積み上げることで担保される。

次回（第4回） は、ここまで見てきた②③を実際に品質として作り込むための仕組み——AIに経験知を組み込む「QEハーネス」——を扱います。

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

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