現場のリアル物語①: 2012年の仕様書と失われたエビデンスたち

私は現場でのポジションはテスト担当。具体的には、現在稼働しているETL¹のバージョンアップに伴う単体テスト²。
「FTP³で置く → SQL⁴流す → 実行 → 照合 → スクショ」で終わる……はずだった。

でも現実は、仕様書は風化し、エビデンスは消え、定義はズレ、正解が見えない。
その結果、テストは「確認」じゃなくて「推理」になり、最後は「本番っぽいもの」に近づけながら祈ることになる。

最初のミッション「単体テストを完了せよ」

依頼内容はシンプルだ。

• サーバにFTPクライアント（GUI⁵）でファイルを置く
• DBにSQLを投入する（SQL自体は書くけど、投入はGUI）
• ETLを実行する
• 出力を照らし合わせる
• スクショを撮る
• 仕様書を直す
• エビデンスを揃える

やることだけ並べると、優しい世界に見える。

環境に入った瞬間、空気が変わる

開始して最初に当たる壁がこれだった。

• 仕様書が2012年ぐらいに作られた「古の仕様書」（今と動作違うやん…）
• テスト内容によっては、肝心のエビデンス自体が存在しない（正解どれ？）
• いつかの日に仕様が勝手に変わっていて、過去のテストデータが使えない（全部作るん？）
• テーブル定義がどこかで変わっていて、環境によって定義が違う（データ壊れた？不具合？）

ここから先は、単体テストという名の「探索」になる。絶望。

敵はバグじゃない。「真実がない」

テストデータを通すと、当然のように違う結果が出る。
でも、それが何を意味しているのか分からない。

• バージョンアップのせいで発生した不具合なのか
• データが古くなって意図せず失敗するのか
• 今までのルール自体を変える仕様変更なのか
• 過去に“わざと変えた”テーブル定義変更の影響なのか

ここで、さらにややこしくなる要因が重なる。

• 設計書が既にどこかへ行ってしまい、何が正しいか判断できない
• 本番に合わせれば良さそうなのに、本番環境を直接確認する方法がない
• 本番環境を触れるクライアント担当者が忙しくて捕まらない
• 過去の仕様書やテストの内容が雑で、そもそも何が正しかったのかさえ曖昧

この世界のボスは“不具合”じゃない。参照点の喪失だ。

仕様書のテストが適当すぎて、心が折れる

テスト項目が雑だと、「何を証明したいのか」が曖昧になる。
曖昧なまま照合して、差分が出た瞬間にこうなる。

• 過去と比較して「違う」ことだけは分かる
• でも「どちらが正しいか」が分からない
• だから「直すべきか」「仕様として扱うべきか」が決められない
• 結果として、手が止まり、時間だけが溶ける

生存戦略「条件を先に整える」

だから最近は、いきなり過去のテストデータを通さない。
普通は最初に通して「変わらないこと」を確認して良いはずなんだけど、ここは土台が壊れてる。

先に“参照点”を固定する。いわば、テスト開始前のチュートリアル。

1. 古の仕様書を眺める（いまの前提条件を把握する）
2. 現行の設計でどうなる予定かを確認する（期待値の再構築）
3. テーブル定義と合致しているか確認する（参照点を作る）
4. そこまでやってから、恐る恐るテストを進める

そして最後に、祈る。全力で。

終章：クリア条件を、少しだけ現代に寄せる

結論はこれ。

やることが簡単でも、正しさの基準が壊れていたら難しい。
必要なのは根性じゃなくて、「今の正」を作り直す作業だ。

• 仕様書（風化しているなら、更新して“今の正”に寄せる）
• 定義（テーブル定義を参照点として固定する）
• テストデータ（使えないなら作り直し、由来と前提を残す）
• エビデンス（欠損があるなら欠損として扱い、代替根拠を残す）

真実がないなら、真実を作るしかない。
この世界は簡単じゃない。でも攻略本は自分で作れる。

…いや、そもそもこんな乱雑な環境、アカンやろ!!ww

用語メモ（脚注）