テスト観点案はテストケースではない——コードを急がない理由、ここにもある｜第6話

シリーズ：現役PMOがAI協調設計の新境地を拓く
第1話：PMOがVS Code × Markdownで仕事を変えた話
第2話：ブロックCRUDとは何か（非エンジニア向け）
第3話：ブロックCRUDをどう育てるか
第4話：履歴を中間と間違えたらどうなるか
第5話：「前回のファイルを残してある」——それ、本当にバックアップですか？
▶ 第6話：テスト観点案はテストケースではない（本稿）

要件定義の段階で、テストのことを考えるのか

「テストは下流工程でしょう」

そう思っている人は多い。実際、テストケース（何を、どのデータで、どの手順で確認するか）を要件定義の段階で書く必要はない。そんな余裕はないし、書いても早すぎて的外れになる。

ただ、「何を確認すべきか」という観点は、要件定義の段階で一度触っておく必要がある。安全のためだ。

この「観点を一覧にしたもの」が、テスト観点案だ。テストケースとは別物である。

テスト観点案とテストケースの違い

テストケースは、テストを実行するための設計書だ。「契約番号が欠損したデータを投入したとき、エラーログに出力されること」のように、具体的な条件と期待結果を書く。

テスト観点案は、「そもそも何を確認すべきか」を整理した一覧だ。「入力欠損の場合はどうなるか」という問いを立てることが目的であって、答えを詳細に書く段階ではない。

この違いを押さえないまま動き始めると、要件定義の段階で詳細すぎるテストケースを書こうとして行き詰まるか、逆に「観点案を作った」と言いながら抜け漏れを見逃すことになる。

なぜブロックCRUDの早い段階でテスト観点案が必要か

ブロックCRUD（処理の流れとファイル操作を整理した一覧表）を作っていると、こんな状況が起きる。

「消込結果ファイルは外部連携用か、それとも同一バッチ内の後続処理用か」——この問いに答えが出ないまま、データ性格の欄が「連携（仮）」のままになっている。「STEP013の集計結果は後続の業務判断に使われるか」——これも「ワーク（仮）」のまま止まっている。

この「仮」がついた行が、未確認事項だ。ブロックCRUDを育てる過程で、どうしても判断できない点が出てくる。

テスト観点案は、その未確認事項をあぶり出すための道具でもある。

ブロックCRUD・処理ブロック設計（ブロック単位の処理内容）・再実行設計（異常終了したときにどう動かし直すか）が揃った段階で、AIに対してこう指示する。

「ブロックCRUD、ブロック処理設計、再実行・異常時設計をもとに、この処理ブロック単位で必要なテスト観点を一覧化してください。観点は、正常系、入力欠損、マスタ不一致、重複、境界値、再実行、締め後、異常終了、状態遷移、帳票・ログ確認に分けてください。不明点は未確認事項として出してください。」

この指示で出てくるのが、テスト観点案だ。

テスト観点案には3つの役割がある

ひとつ目は、ブロックCRUDの抜け漏れをあぶり出すことだ。観点を列挙する過程で、「この処理の再実行時の扱いが未定義だ」「異常終了したときにファイルがどう残るかが確認されていない」という空白が見える。

ふたつ目は、未確認事項を記録に残すことだ。AIが「この資料だけでは判断できない点」を未確認事項として出す。それを判断ログに追加することで、ブロックCRUDの精度がさらに上がる。未確認事項には番号を振って管理する（may001・his003・tst001など）。この番号が、後工程でも追跡され続ける。

みっつ目は、後工程のテスト設計の見出しになることだ。要件定義から基本設計、テスト設計と進む中で、観点案の各行がテスト設計書の項目に育っていく。早い段階で観点を固めておくことで、下流工程の手戻りを減らせる。

どんな観点を一覧化するのか

処理ブロック単位で確認すべき観点はおおむね以下のとおりだ。

正常系は、入力が正しい場合に期待どおり出力・更新されるかを見る。

入力欠損は、必須の項目がない場合にエラーとして扱われるかを見る。

マスタ不一致は、契約マスタや料金区分マスタなどに該当データがない場合どうなるかを見る。

重複は、同じ請求や同じ消込対象が複数来た場合にどう扱うかを見る。

境界値は、金額0円・最大金額・月末日・年度末といった端の条件で正しく動くかを見る。

再実行は、異常終了後に動かし直したとき、二重登録・二重更新が起きないかを見る。

締め後は、月次などの締め処理が終わった後に再実行・修正してよいかを見る。

異常終了は、処理が中断したときに残るファイルや、どこから再開するかが明確かを見る。

帳票・ログは、エラーリスト・処理件数・ログが期待どおり出るかを見る。

状態遷移は、「未処理→候補→確定→締め済み」といった状態が崩れないかを見る。

この一覧が、テスト設計書の見出しになる。

消込処理に当てはめてみると

消込処理（入金データと請求データを突き合わせて帳消しにする処理）を例に取る。

「消込候補を作るブロック」に観点を当てはめると、以下のような問いが立つ。

正常系では、消込候補のファイルから正しく確定レコードが作られるか。入力欠損では、請求番号・入金番号が欠損した場合にエラーログに出るか。マスタ不一致では、契約マスタに該当なしの場合に突合エラーとして扱われるか。これは判断できないので未確認事項（tst001）として残す。重複では、同一請求番号が複数来た場合にどちらを採用するか。先勝ちか後勝ちかは業務ルールとして決める必要があるため、未確認事項（tst002）だ。

「消込確定を正本と履歴に反映するブロック」では、さらに重要な問いが立つ。

正常系では、残高（正本）が正しく減額され、消込履歴が追加されるか。再実行では、同じバッチを再度動かしたとき、残高が二重に更新されないか。状態遷移では、正本の更新と履歴の追加が同一のまとまった処理として完結するか。これは以前の記事で出た未確認事項（his003）と同じ問いだ。締め後では、月次締め処理の後に再実行した場合、補正として扱われるか（tst003）。

未確認事項は、ブロックCRUDから引き継がれて、テスト観点案でも繰り返し登場する。追跡が続いているということは、まだ答えが出ていないということだ。コードを書く前に、これを確定させる必要がある。

AIにできることと、人間が確認することの分担

AIにできることは、ブロックCRUDと処理ブロック設計をもとに観点の草案を作ることだ。粒度を揃え、用語を統一し、抜け漏れを指摘することもできる。「この資料だけでは判断できない点」を未確認事項として列挙することもできる。

人間が確認しなければならないのは、業務ルールと運用手順が絡む部分だ。

何が「正しい」状態かは業務として決める。締め処理後に修正・再実行が許されるかは運用判断だ。異常終了したときにどのファイルを削除して、どこから再開するかは現場の手順と一致させる必要がある。重複が来たとき「先勝ち」か「後勝ち」かは、業務ルールとして決める。

AIが観点の草案を作り、人間が業務ルールと運用手順を当てはめる。これが4回の往復の最終段階だ。

成果物の連鎖の中での位置づけ

ブロックCRUDから始まる成果物の流れをおさらいしておく。

処理のステップ単位でファイルの流れを整理したものがブロックCRUDだ。それをもとに処理ブロック設計書を作り、データの責務・正本の定義・状態遷移・再実行と異常時の設計を固めていく。その次にテスト観点案を作り、抜け漏れを最終確認する。そこから初めて、新システムへの対応表とコード生成指示書に進む。

テスト観点案は、コードを書く前に一度立ち止まる場所だ。コードを急がない理由は、ここにもある。

まとめ

テスト観点案とテストケースは別物だ。

テスト観点案は「何を試験すべきか」を人間とAIが前もって認識するための資料であり、後工程のテスト設計書の見出しになるものだ。

要件定義の段階でテスト観点案を一度触っておくと、3つのことが得られる。ブロックCRUDの抜け漏れが見える。未確認事項が追加されて判断ログが充実する。後工程のテスト設計の手戻りが減る。

ブロックCRUDから始まった設計の精度が、テスト観点案で最終確認される。それがコード生成の前に行う最後の人間の仕事だ。

次回（第7話）では「運用・保守チームと語らずに、移行設計はできない」を書きます。14年間課長だった人の話と、レガシー運用チームから引き継ぐべき3つのものについて書きます。