連載「業務SEのための仕様駆動開発」第3回

AIが書いたテストは全部通る。でも、安心できない

AIにプログラムを書かせると、それらしいコードがすぐに出てきます。テストもAIに書かせると、全部通ります。

それなのに、なぜか安心できない。そんな経験はないでしょうか。

その不安は、たぶん正しいです。問題は、AIにテストを書かせることではありません。書かせるタイミングと、渡す材料です。

結論：テスト仕様書は、実装の前に、AIに作らせる

テスト仕様書とは、「何をしたら、どうなれば合格か」を並べた一覧です。

私は、これを自分の手では書きません。AIに作らせています。 ただし、プログラムを作らせる前にです。

AIに渡す材料は2つです。

仕様：こう動くこと（目的確定メモや設計書に書いたもの）
やってはいけないこと：入力のチェックなど、もともと決まっている禁止事項

AIは、この2つを掛け合わせてテスト仕様書を作ります。

実装の後に作らせると、何でも通ってしまう

先に、タイミングの話をします。第1回で例にした「受注CSVを在庫システムに取り込む」仕組みで考えます。

この取り込みプログラムに、見出し行だけの空っぽのCSV（0件）を読ませると、エラーで止まってしまうとします。本当は「0件でした」と表示してほしいところです。

プログラムを作った後で、AIにテストを書かせるとどうなるか。私の経験では、AIはできあがったプログラムに合わせてテストを書きがちです。すると、「0件のCSVなら、エラーが出ること」を確かめるテストができてしまいます。今の動きをなぞっているので、テストは通ります。でも、欲しかった動きではありません。

プログラムより先に、仕様からテスト仕様書を作らせれば、こうはなりません。仕様に「0件なら『0件』と表示する」とあれば、エラーで止まるプログラムはテストで落ちます。

テストが確かめるべきなのは、「プログラムが、今のプログラムどおりに動くこと」ではなく、「仕様どおりに動くこと」です。だから、テスト仕様書は、プログラムより先に作らせます。

テスト仕様書は「仕様 × やってはいけないこと」でできている

次に、材料の話です。

業務システムには、たいてい「やってはいけないこと」が最初から決まっています。代表的なのは、入力のバリデーション（入力チェック）です。受注CSVの例なら、たとえば次のようなものです（仮の例）。

商品コードは、商品マスタにあるものだけ
数量は、1以上の整数
単価は、取り込みのときに直さない（修正は人が行う。第1回で決めた「今回やらないこと」）

仕様の「受注CSVを取り込む」に、これを1つずつ掛け合わせると、テストの行ができます。

仕様	× やってはいけないこと	→ できるテスト
受注CSVを取り込む	商品コードはマスタにあるものだけ	存在しない商品コードの行を混ぜる → その行は取り込まれず、行番号と理由が一覧に出る
受注CSVを取り込む	数量は1以上の整数	数量が0の行を混ぜる → その行は取り込まれず、行番号と理由が一覧に出る
受注CSVを取り込む	単価は直さない	単価が間違っている行を混ぜる → 単価は直されず、CSVのとおりに取り込まれる

仕様1つに、やってはいけないことがいくつも掛かります。仕様が10個、やってはいけないことが20個あれば、組み合わせはすぐに数十行になります。これを漏れなく並べるのは、人よりAIのほうが得意です。

特に、3行目のような「やってはいけないこと」は大事です。AIは親切なので、頼んでいない改善までしてしまうことがあります。仕様だけからテストを作ると、こうした余計な動きは見逃されます。

型：やってはいけないこと一覧のテンプレート

材料のうち、仕様は、第1回・第2回で紹介した目的確定メモと設計書です。もう1つの材料が、やってはいけないことの一覧です。

この一覧は、案件ごとに一から作るものではありません。業務システムなら、中身はどの案件でもほとんど同じです。一度作れば、使い回せます。 そこで、どの案件でも使う「共通」と、案件ごとに足す「この案件だけ」の2つに分けておきます。コピーして使ってください。

# やってはいけないこと一覧

## 共通（どの案件でも使い回す）

### 入力のチェック（受け付けてはいけない値）
- 必須：空欄を受け付けない
- 型：数値の欄に文字を、日付の欄に日付でない値を受け付けない
- 長さ：決めた桁数・文字数を超える値を受け付けない
- 範囲：決めた範囲の外（マイナス、0、上限超え）を受け付けない
- 存在：マスタにないコードを受け付けない
- 重複：同じデータの二重登録を受け付けない

### 権限
- 権限のない人は、実行も閲覧もできない

### データ
- 既存のデータを、断りなく書き換えたり消したりしない
- テーブル定義を変えない

## この案件だけ
- （例）CSVの中身の誤り（単価違いなど）は直さない。修正は人が行う
- （例）取り込みを実行できるのは、取り込み担当のアカウントだけ

「共通」は、最初から完璧にしなくてかまいません。まず作って、使ってみる。 テストやバグで足りないものが見つかったら、そのつど足していきます。案件を重ねるほど一覧が育ちます。前の案件で足したものは、次の案件では最初から入っています。

「この案件だけ」は、第1回の目的確定メモで書いた「制約」が元になります。

人が確かめるのは、材料のほう

AIが作ったテスト仕様書を、私が1行ずつ確かめることは、ほとんどありません。確かめるのは、材料のほうです。

仕様に、決めたことが全部書かれているか
やってはいけないこと一覧に、抜けがないか

材料が正しければ、掛け合わせはAIが漏れなくやってくれます。逆に、材料に抜けがあれば、テストにも同じ抜けが出ます。さっきの0件の例も、仕様に「0件ならどうするか」が書かれていなければ、テストには出てきません。テストを増やしたいときも、テスト仕様書を直接直すのではなく、材料を直して、AIに作り直させます。やってはいけないこと一覧に足したものは、次の案件でもそのまま効きます。

私の場合：テスト仕様がないと、区別がつかなくなる

私の経験では、テスト仕様をつくらずに進めると、バグが出たときに、それが仕様から来たものなのか、本当のプログラムのバグなのか、区別しにくくなります。

「どうなれば合格か」がどこにも書かれていないので、その動きが誤りなのかどうか自体が、はっきりしないからです。仕様の問題をプログラムの修正でしのいだり、プログラムの問題を「そういう仕様だった」で片づけたりすることにもなりかねません。

エンジニアの方にはおなじみの考え方だと思います。ウォーターフォールでは、テストは設計に対応させてつくります。作るのがAIになっても、この順番はそのまま使えます。

まとめ

実装の後にAIにテストを書かせると、今のプログラムをなぞるだけになりやすい
テスト仕様書は、実装の前に、AIに作らせる
材料は「仕様」と「やってはいけないこと一覧」の2つ。AIが掛け合わせてテストの行を作る
やってはいけないこと一覧は、一度作って使い回し、足りないものを足して育てる
人が確かめるのは、テスト仕様書ではなく材料のほう

次回は、業務でAIを使う前に確認しておきたい6つのことを、チェックリストの形で紹介します。

連載「業務SEのための仕様駆動開発」

一覧はこちら → https://qiita.com/sha44444/stocks/3c9167054a4a82837bb3

この連載では、仕様駆動開発の「型」を1回に1つずつ紹介しています。
5つの工程を実案件でどう回しているか（各工程でAIに渡す依頼文、変更が入ったときの回し方、通しの実例）は、1冊の本にまとめました。第1章は無料で読めます。
→ https://zenn.dev/shin4/books/31499dd20de8ac