仕様書がなくてもテスト設計はできる―
散らばった情報を「判断できる仕様」に変える方法

まず、対象プロジェクトの概要と、案件開始時点の状況を整理します。

・対象システム：塾で利用する学習管理サービス
・実施工程：受入テスト工程の第三者検証を担当
・インプット情報：検証環境（STG環境）、画面デザイン案、機能一覧案、要件メモ、営業資料

案件着手時点では、要件定義書、画面一覧、画面遷移図、画面仕様書、DB定義書といった、テスト設計のインプットとして一般的に想定される資料がありませんでした。

一方で、何もなかったわけではありません。上記に記載したような、仕様を考える材料は点在していました。

仕様が一つの文書にまとまっていなくても、営業資料にはサービスの目的があり、画面には想定される操作があり、STG環境にはその時点の実装があります。問題は、情報がないことではなく、情報が業務や仕様として構造化されていないことでした。

今回のプロジェクトでは、次の順序で情報を整理しました。

1.業務一覧と正常系の業務フローを作る
2.正常系のユースケースを洗い出す
3.正常系を基準に、異常系のユースケースを洗い出す
4.ユースケースと機能を突合する
5.顧客レビューで仮説を修正し、未決事項を決める
6.ユースケースからテストケースへ落とし込む

重要なのは、画面から直接テストケースを作らないことです。業務、ユースケース、機能の関係を先に整理することで、個々の確認項目を業務上の目的と結び付けます。

最初に営業資料とSTG環境を確認し、その情報をもとに、画面一覧、業務一覧、業務フローを整理しました。

仕様が不足していると、画面を一つずつ調査し、入力項目やボタンの動作を詳細に記録したくなります。しかし、詳細な画面調査から始めると、設計者の対象システムに対する理解度や経験値によって、調査結果に差が生まれます。知識・経験のある設計者は画面の背景にある業務まで想像できますが、そうでない設計者は、目に見える項目や操作の確認にとどまりやすいためです。

実際に過去の案件でも、同じ資料や画面を確認しているにもかかわらず、設計者によって業務の捉え方が異なり、テスト設計書の確認範囲や深さにばらつきが生じることがありました。また、一人で設計する場合でも、業務への理解が深まるにつれて、案件の前半と後半で設計の粒度が変わることがあります。

そこで、詳細を調べる前に、システムで実現する業務を粗く一覧化し、正常に業務が完了する流れを業務フローとして仮置きしました。この段階では例外的なケースまでは盛り込みません。異常系は正常系の派生であり、基準となる業務が曖昧なままでは、何が例外なのかも判断できないからです。

業務フローを作る最大の目的は、資料を完成させることではありません。関係者が同じ業務像を見ながら、流れの漏れや認識の違いを具体的に指摘できる状態を作ることです。

業務の全体像を整理した後、ユーザーがシステムを使う目的を「ユースケース」として分解します。まず業務から主要なユースケースを設定し、次に画面上のボタン、入力項目、選択肢、フラグなどから、派生する利用目的やテスト条件を探します。

ここで確認するのは、文字数や必須項目だけではありません。「この項目は、なぜ存在するのか」「この画面があるなら、どの業務で使われるのか」を考えます。

画面上の要素は、主に次の二つへ振り分けます。

・利用目的が変わるもの：別ユースケースの候補
・処理結果や導線が変わるもの：テスト条件の候補

画面の項目をそのままテスト項目へ変換するのではなく、その項目が存在する業務上の理由を考えることが重要です。

画面を操作するだけでは見つからない仕様もあります。登録した情報が後続の処理や履歴へどう引き継がれるか、通常とは異なる条件のデータをどう登録するかといった事項は、画面単体では判断できませんが、ユースケースの洗い出しにおいては必要です。

このような確認事項を見つけるため、存在するインプット資料の確認に加え、私は次の三つを実施します。

画面上で当たり前に想像できる「典型的な正常系」の操作だけでなく、年間スケジュールや学習カリキュラムを確認し、年度替わりなどの実際の業務で起こり得る出来事を考えます。現実の出来事をシステム上の操作や状態へ置き換えることで、画面に現れていない仕様の候補を発見できます。

登録したデータが、その後どの機能で参照・更新・削除されるかを追います。流れを書き出すことで、「想定外の画面や機能への影響がないか」「ある操作を取り消したら後続データはどうなるか」「再度登録したら以前のデータとどうつながるか」といった確認事項が見つかります。

過去に不具合が発生した場面や、顧客確認が必要になった場面を思い出し、同じ問題が起きる可能性を考えます。

正常系を一通り整理した後、そこから派生して例外的な状況を洗い出します。

一般的な、意図しない操作や誤操作などの観点に加え、私は、正常系のユースケースの一部の条件を変化させることを意識します。

よく使うのは、主に三つの変化です。

状態の変化

対象データや関連データの状態を変えます。

・登録済みである
・無効になっている
・削除されている
・処理中である

例えば、正常系が「生徒に講座を登録する」であれば、「退会済みの生徒に講座を登録する」「終了済みの講座を登録する」といった状況を考えます。

順序の変化

本来必要な処理の順番を入れ替えます。

・前提となる設定より先に登録する
・承認前に後続処理を実行する
・利用開始前に結果を登録する
・終了処理後に情報を変更する

単一画面では正常に操作できても、業務の順序が変わると、データの整合性が崩れる場合があります。

冒頭で触れた転校生のケースも、業務フローを整理した後、「カリキュラムを『最初』から学習する」という順序を変えたことで発見しました。実際の塾では、年度途中から利用を始め、カリキュラムの途中の単元から学習する生徒もいます。しかし、画面のどこにも「転校生を年度途中から登録する」という専用の操作はありません。画面や機能を一つずつ調べるだけでは、この確認事項にはたどり着けませんでした。

そこで、未学習の単元をどのような状態として扱うのか、途中から登録しても進捗管理や後続処理に影響しないのかを確認事項として整理しました。これは、画面に表示された仕様を拾ったのではなく、業務フローを構造化し、通常の順序を変えて考えたからこそ発見できた確認事項です。

時間の変化

・日・月・年をまたぐ
・有効期限が切れている
・予定より遅れる

時間に関する条件は、画面上に明示されていないことも多いため、現実の業務スケジュールから検討します。
異常系のテストは、エラーになるものを確認するだけではありません。想定していない状況が発生した際に、画面やデータに不整合が起きず、業務継続ができるかどうかまでを確認します。

ここまでのプロセスで正常系と異常系のユースケースを書き出しただけでは、必要な確認を網羅できたとは判断しません。把握できた機能とユースケースを突合し、次の二方向から確認します。

・ユースケースごとに、必要な機能が揃っているか
・機能ごとに、利用されるユースケースが存在するか

どのユースケースにも登場しない機能があれば、ユースケースの不足、対象外機能の混在、利用目的の認識不足などが考えられます。ユースケースから機能を見るだけでなく、機能からユースケースを逆引きすることで、機能面の重大な確認漏れを抑えます。

業務とユースケースを整理したら、テストケースへ落とし込む前に、内部レビューと顧客レビューを実施します。この段階で認識を揃えなければ、詳細化した後に大きな手戻りが発生するためです。

顧客レビューで行うことは、大きく二つあります。

・資料や画面から組み立てた仮説を確認し、誤っている部分を修正する
・顧客側でも決まっていない事項を明らかにし、期待する振る舞いや運用方法を決める

レビューで特に重要なのは、システムの開発関係者だけでなく、業務を設計した人や、実際にその業務を行っている人の視点です。実務を知る人だからこそ、資料や画面には表れない業務の前提、実際の作業順序、運用上の制約を指摘できます。

異常系についても、実務を知る人から情報を引き出します。通常の手順では処理できない例外、過去に利用者から寄せられた問い合わせ、現場で個別対応した事例などは、異常系ユースケースを補う重要な材料になります。テスト設計者の想像だけで完結させず、実際の運用で起きた出来事を反映することで、より現実に即したユースケースを整理できます。

このように、詳細化する前に全体像への認識を揃え、指摘を横展開してからテストケースの作成へ進むことが、手戻りを抑えながら網羅性を高めるポイントです。

顧客レビューを経てユースケースを整理した後、ユースケース単位でテスト観点とテスト条件を決めます。最後に、実行手順と期待結果を記載してテストケースへ落とし込みます。

この順番で進めることで、個々のテストケースが、どの業務目的とユースケースを確認するものなのかを説明できます。

ここまで紹介した作業には、人が判断すべき部分がある一方、AIで効率化できる部分もあります。例えば、次のような作業です。

・営業資料、要件メモ、画面案など、複数資料から機能の目的（ユースケースの参考情報）を抽出する
・業務一覧や業務フローから、ユースケース候補を作る
・正常系のユースケースをもとに、状態・順序・時間を変えた異常系候補を作る
・機能とユースケースの対応を整理し、対応先がない項目を検出する
・顧客へ確認すべき事項を、選択肢や仮説付きの質問として下書きする

SHIFTでは、こうした品質保証の思考を、AIテストセンター「ネムラナイ」の設計や活用にもつなげています。ただし、AIが提示した候補を実際の業務に照らして評価する役割は、引き続き人が担います。

AIが扱えるのは、基本的に与えられた資料や指示の範囲です。 AIはその範囲から候補を迅速かつ網羅的に提示できます。しかし、その外側にある現実を持ち込み、「この業務では何を守るべきか」「どの仮説を顧客と決めるべきか」を定めるのは人です。

AIには整理と探索を任せ、人は現場に照らして問いを立てる。この役割分担によって、仕様書がないプロジェクトでも、テスト設計の速度と深さを両立できます。

ここまで見てきたように、仕様書がなくても、仕様を考えるための情報は画面や資料、実装、実際の業務のなかに存在します。ただし、それらは一つの仕様として整理されているとは限りません。

テスト設計者の役割は、こうした散らばった情報を業務上の目的と結びつけ、関係者が判断できる形に整理することです。業務、ユースケース、機能、データの関係として構造化することで、確認すべき仕様の全体像が見えてきます。

その際に重要なのは、画面やその中の機能を、現実の業務と結びつけて考えることです。業務で起こり得る出来事と、守るべき業務要件を明らかにすれば、画面に現れない前提や例外も確認事項として捉えられます。

テスト設計のゴールは、テストケースを作ること自体ではありません。仕様書がないプロジェクトでテスト設計者が作るべきものは、単なるテストケースの集合ではなく、「判断できる状態になった仕様」です。何が確定し、何が未決で、何を確認すれば決められるのかを明確にする。そこまで仕様を構造化することが、曖昧なプロジェクトをテスト可能な状態へ変える、テスト設計者の成果です。