テスト観点の洗い出し手順｜観点表と抜け漏れ防止

2026 8/04

2026年8月4日 2026年8月4日

「テスト観点表を作っておいて」と言われ、真っ白なスプレッドシートを前に手が止まった経験はないでしょうか。何を1行目に書けばいいのか、どこまで書けば「洗い出せた」と言えるのかが分かりません。

テスト観点とは、テスト対象の何を確認するのかを示す切り口のことです。どの値でテストするかではなく、確認すべき対象と期待する性質を指します。

テスト観点の洗い出しは、テストケースを書く前の最上流にある工程です。ここで漏れた項目は、その後どれだけ丁寧にテストしても見つかりません。

抜け漏れは、担当者の注意力の問題ではなく、洗い出しの手順が仕組みになっていないことの症状です。手順と成果物の形を決めてしまえば、テストを兼任している体制でも品質の下限は引き上げられます。

本記事では、観点と技法の切り分けから5ステップの手順、観点表の列構成、漏れの検出方法までを解説します。

テスト観点が抜け漏れる3つの原因

なぜ抜け漏れが起きるのかを構造から整理します。原因が分かれば、対策は個人の頑張りではなく手順の設計に変わります。

原因1 仕様書に書かれていないことが観点にならない

仕様書は、書き手が「書く必要がある」と判断したことだけが書かれた文書です。関係者にとって当たり前すぎる業務ルールは、次のように書かれないまま残ります。

同じ顧客コードを2つ登録できない
月末の締め処理中は在庫を更新しない
退職済みの担当者は選択肢に表示されない

仕様書だけをインプットにすると、観点は目次の写しになります。本番で問題になるのは、たいてい目次に載っていない領域です。

原因2 実装した人が洗い出すと実装経路に引きずられる

これは能力ではなく認知の構造の問題です。実装した人は、コードとして書いた分岐を思い浮かべながら観点を出します。

その結果、自分が「通した」経路は観点になりますが、「そもそも想定しなかった」経路は観点にならないという偏りが生じます。実装時に考慮漏れした条件は、観点でも同じように漏れます。

開発と並行してテストを担当していれば「動くことの確認」が優先され、例外的な状況の観点は最後に短時間で書かれがちです。

この構造的な限界と体制を見直す判断基準は、開発者のテスト兼任が限界を迎える見極め方で整理しています。

原因3 観点の粒度がバラバラで網羅できているか判断できない

観点表を見て「これで足りているか」を判断できないのは、行ごとの粒度がそろっていないからです。「ログイン機能」と「パスワード欄の最大桁」が同じ列に並んでいれば、どちらを基準に網羅性を測ればよいか決まりません。

粗い行の内側に何が含まれるかは人によって違って読めます。レビューでも「たぶん含まれているはず」で流れてしまいます。

テスト観点と設計技法の違いを最初に切り分ける

抜け漏れの議論に入る前に整理しておきたいのが、観点と設計技法の切り分けです。ここが曖昧だと、観点を出しているつもりが「境界値をどう取るか」という技法の議論にすり替わります。

比較軸	テスト観点	テスト設計技法
答える問い	何を確認するのか（What）	どの値・組み合わせを選ぶのか（How）
主な工程	テスト分析	テスト設計（分析でも併用する）
成果物	テスト観点表	テストケース
決めること	確認すべき対象と切り口	テストケースの数と具体値
例	「入力桁数の制限が守られること」	同値分割・境界値分析で 0/1/8/9 桁を選ぶ

観点は「What」、技法は「How」

順番は観点が先、技法が後です。観点が漏れていれば、精緻な技法を使ってもテストケースは生まれません。技法は観点の抜け漏れを自動的には補いません。

ただし、状態遷移図やデシジョンテーブルを分析段階で描くこと自体は観点の発見に有効です。技法の議論に入る前に「何を確認するか」を出し切る、という順番の話です。

観点欄には「金額欄の上限を超える入力が拒否されること」のように、確認対象と期待する性質を書きます。技法名や具体的な入力値（「9999円」など）が観点欄にあれば、切り分けができていない証拠です。

技法の使い分けそのものは、テスト設計技法の全体像と使い分けにまとめています。

テスト観点はテスト分析工程の成果物である

テスト観点は、思いついたら書き足すメモではなく、テスト分析という工程の正式な成果物です。工程の成果物として扱うから、レビューでき、再利用でき、引き継げます。

なお、JSTQBが公開するテスト技術者資格の情報で体系化されている標準的なテストプロセスでは、テスト分析の成果物を「テスト条件」と呼びます。国内実務で言う「テスト観点」は、これにおおむね対応する用語です。クライアントや監査の場では、この対応関係を先に共有すると齟齬が減ります。

布施昌弘ほか『ソフトウェアテストの教科書』でも、テスト観点はテスト技法を適用する前段の観点設計として位置づけられ、テスト観点一覧表によって網羅性を担保するという整理が示されています。観点を作る行為は実質的に仕様レビューでもあり、上流に置くほど仕様の曖昧さを早く潰せます。

テスト観点の洗い出し手順【5ステップ】

作業を「センスのある人が頑張るもの」から「工程」に変えるため、5つのステップに分解します。入力と出力が決まっていれば、担当者が変わっても再現できます。

所要時間は機能数10・画面数20程度の案件で合計4〜6時間が目安です。筆者の実務上の感覚値で、機能数におおむね比例します。上長に時間を確保してもらうときの初期見積もりに使ってください。

ステップ	アウトプット	所要時間の目安
1 インプットを集める	インプット一覧と不足リスト	30〜60分
2 分類軸を先に決める	採用する分類軸（2〜3種）	15〜30分
3 軸に沿って展開する	観点のドラフト一覧	2〜3時間
4 粒度をそろえる	粒度統一済みの観点表	30〜60分
5 リスクで優先度を付ける	優先度付きの観点表	30〜45分

ステップ1 インプットを集める

材料が足りないと、以降をどれだけ丁寧にやっても穴が残ります。

要件定義書・基本設計書（何を作るか）
画面設計書・API仕様書（どんな入出力があるか）
過去の類似案件のバグ票（自社が過去に落とした穴）
運用ルール・業務フロー（仕様書に書かれない前提）
非機能要求（性能・セキュリティ・信頼性の目標値）
既存システムとの連携仕様

「過去のバグ票」と「運用ルール」を集めているかどうかで質は大きく変わります。この2つが、仕様書に書かれない領域を照らす数少ない材料だからです。「この資料が存在しない」と分かること自体も成果で、そのまま仕様確認のタスクになります。

ステップ2 分類軸を先に決める

軸がないまま書き始めるから、粒度が崩れ、重複と漏れが同時に発生します。代表的な軸は次の4つで、2〜3種類を組み合わせます。

分類軸	並べ方	向くシステム
機能軸	機能一覧の単位	機能が明確に分かれた業務系
画面軸	画面・帳票の単位	画面数が多いWebアプリ
ユーザー役割軸	管理者・一般・外部連携先	権限制御が複雑なもの
データライフサイクル軸	登録・参照・更新・削除・破棄	状態遷移が重要なもの

おすすめは「機能軸 × データライフサイクル軸」です。機能軸だけだと状態遷移が漏れ、ライフサイクル軸だけだと機能固有のルールが漏れます。

ステップ3 軸に沿って観点を展開する

軸が決まったら、各マスに機械的に観点を広げます。ここで使うのが正常系・準正常系・異常系の3系統です。

この3語は標準用語ではなく、定義が組織によって異なります。本記事では次の意味で用います。呼称と定義は観点表の凡例に書いておくことをおすすめします。

正常系: 想定どおりの操作・入力で期待どおりの結果になるか
準正常系: 仕様上あらかじめ想定されたエラー（入力規則違反、権限のない操作）を正しく扱えるか
異常系: 仕様で想定しきれない事象（通信断・二重送信・権限変更直後・締め処理中）で破綻しないか

3つ目の異常系は、意識して行を確保しないと出てきにくい領域です。

観点の書き方に型を用意すると、粒度が安定します。高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、テスト可能な要求の条件として「ステート＋条件・アクション＋特定された結果」という3要素が示されています。これを記述フォーマットに転用します。

たとえば「未入金の受注データに出荷登録を行うと、警告が出て登録が中断される」という書き方です。3要素のどれかが書けない観点は、確認内容が曖昧なまま残っている証拠です。

ステップ4 粒度をそろえる

展開した観点は必ず粒度がばらつくので、そろえる作業を挟みます。目安は1つの観点がテストケース概ね3〜10件に展開できる粒度、10件超は分割を検討です。筆者の実務上の目安なので、テストケース総数に応じて調整してかまいません。

粗すぎる例: 「ログイン機能が正しく動作すること」
ちょうどよい例: 「パスワードの入力規則違反が検出されること」
細かすぎる例: 「パスワードに半角スペースを入れるとエラーになること」

件数だけで判定せず、次の兆候を主基準にしてください。1つの観点に「かつ」「および」が複数含まれれば分割、隣の行との違いが値だけなら統合です。

ステップ5 リスクで優先度を付ける

すべての観点を同じ密度で実施するのは現実的ではありません。優先度は「発生頻度 × 影響度」を基本に、確認容易性を加味します。

高: 金銭・在庫・個人情報に関わる処理、利用頻度の高い導線
中: 業務は継続できるが手作業での回復が必要な処理
低: 表示崩れなど、影響が限定的で回避手段がある事象

このステップを飛ばすと、観点表は「並んでいるだけの一覧」になります。ある受託開発のテスト支援現場の振り返りでも、作業時間の割り振りが難しかった原因は、項目を列挙しただけで重要度やリスクによる順位付けに至っていなかった点だと整理されていました。

優先度付けを体系的に運用したい場合は、リスクベースドアプローチで優先度を決める手順を参考にしてください。

テスト観点表の作り方｜列構成と粒度の決め方

洗い出しの結果は観点表として残り、この表の列構成が運用の質を決めます。多くの観点表は「観点」と「確認内容」の2列しかなく、それでは漏れの検出も優先度の判断もできません。

観点表に持たせるべき8つの列

推奨する列構成は次の8列です。「この列がないと何が起きるか」も添えます。

列名	記入内容	この列がないと起きること
大分類	機能グループ・サブシステム	抜けた領域に気づけない
中分類	画面・処理単位	観点が一列に並び比較できない
観点	何を確認するか	そもそも成立しない
確認内容	期待される性質・結果	解釈が人によってぶれる
根拠	仕様書の該当箇所・過去バグ番号	思い込みと仕様漏れを検出できない
優先度	高・中・低	時間切れのとき上から削られる
担当	作成者・実施者	誰に聞けばよいか分からない
実施状況	未着手・実施中・完了	進捗が観点単位で見えない

2列運用から8列に移行する初期コストは、観点100行で2時間前後、以降は1行あたり数十秒が目安です（筆者の感覚値）。全列を一度に埋める必要はなく、まず根拠列と優先度列を足すだけでも効果は出ます。

「根拠列」が抜け漏れを検出する仕組み

いちばん軽視されがちで、いちばん効くのが根拠列です。「基本設計書 4.1」「過去障害 #482」のように、その観点が存在する理由を書きます。この列を必須にすると、2種類の問題が同時に見えてきます。

根拠を書けない観点 = 思い込み、または口頭で決まった未文書化の仕様
どの観点からも参照されない仕様の箇所 = 観点の漏れ

根拠列は、観点表を「一覧」から「検証可能な文書」に変える1列です。書けない観点をその場で削除する必要はなく、「根拠なし」と明記して残し、仕様確認のタスクに変えるのが実務的です。

記入例で見る観点表

ログイン機能を題材にした記入例です（設計に関わる6列を抜粋）。

大分類	中分類	観点	確認内容	根拠	優先度
認証	ログイン画面	入力規則違反の検出	規則違反のID・パスワードでエラーが表示される	基本設計書 4.1	高
認証	セッション	権限変更直後の挙動	権限変更後、次操作で新権限が適用される	過去障害 #482	高
認証	ログイン画面	二重送信	連打で二重にセッションが生成されない	根拠なし（要確認）	中

最終行のように「根拠なし（要確認）」を残すと、レビューで真っ先に議題に上がります。空欄のままでは見落とされます。

なお、他社の観点表を流用するより、自社の実績に合わせて育てるほうが機能します。リー・コープランド『はじめて学ぶソフトウェアのテスト技法』は欠陥分類について、一番役に立つのは自分自身の分類、つまり自分で作成した分類であると述べています。この考え方は観点表にも当てはまります。

観点表からテストケースへの展開は、観点からテストケースへ展開する具体的な書き方で解説しています。

機能・非機能別のテスト観点一覧（観点例つき）

観点を展開するときの引き出しです。観点出しのテクニックとしては、この一覧を横に置き、自分のシステムに当てはまるかを上から判定するのが速く、確実です。

機能観点の一覧と観点例

機能側は、次の7分類でほぼ回収できます。

分類	観点例	確認内容の例
入力	入力規則・必須・桁数・文字種	規則違反が登録前に検出される
出力	表示内容・帳票・件数・並び順	正しい件数と順序で出る
状態遷移	画面遷移・ステータス変更	許可されない遷移が起きない
権限	ロール別の可視範囲・操作可否	権限外のデータを操作できない
データ整合性	関連データの更新・削除制約	参照中のデータが削除できない
エラー処理	表示・ログ・ロールバック	中断してもデータが壊れない
同時実行	排他制御・二重送信・競合更新	後勝ちの上書きが起きない

非機能観点の一覧と観点例

非機能側は、テストを兼任する体制で最も落としやすい領域です。そこで、ISO/IEC 25010:2011 が定める8つの品質特性をそのまま分類名に使います。規格に名前をそろえておくと、あとで点検表に流用できます。

品質特性（2011年版）	観点例	確認内容の例
機能適合性	業務要件の充足・計算結果の正確さ	仕様どおりの結果が得られる
性能効率性	応答時間・同時接続・データ量増加	最大件数でも規定時間内に応答
互換性	ブラウザ・OS・端末・外部連携	対象環境で表示と操作が成立
使用性	操作手順・エラーメッセージ	利用者が自力で復帰できる
信頼性	障害時の縮退・復旧・バックアップ	規定手順で復旧できる
セキュリティ	認証・認可・入力値検証・機密情報	権限昇格や漏えいの経路がない
保守性	ログ出力・設定変更のしやすさ	調査に必要な情報がログに残る
移植性	環境移行・インストール・置換	検証環境と本番で同じ手順が通る

現場でよく使う「可用性」は、この体系では信頼性の副特性です。独立した分類にすると、信頼性の他の側面（障害許容性・回復性）が落ちやすくなります。

布施昌弘ほか『ソフトウェアテストの教科書』でも、この8つの品質特性（2011年版）は品質を評価する体系として整理されています。なお ISO/IEC 25010 は2023年に改訂され、特性の構成が見直されています。どの版を使うかは組織で決めれば十分ですが、最新版で点検表を作るならISO/IEC 25010の品質特性一覧を原典で確認するようにしてください。版を混在させると点検の抜けが見えなくなります。

重要なのは、特性を上から順に「該当あり／該当なし」で判定し、判定した事実を記録することです。記録が残っていれば、検討漏れではなく判断済みの状態になります。

見落としやすい観点のショートリスト

経験的に落ちやすい観点です。観点表が一通りできた段階で突き合わせてください。

初期状態（データ0件、初回ログイン時）と終了状態（上限到達、契約終了後）
日付の境界（月末・年度末・うるう年・営業日）とタイムゾーン
文字コードと文字数（絵文字・機種依存文字）
ブラウザの戻る・再読み込み・複数タブでの同時操作
通信断やタイムアウト後の再送、印刷・CSV出力など画面以外の出力経路

具体的な事例で確認したい場合は、見落としやすいバグ30選を分類別に確認すると観点表の穴が見つけやすくなります。

テストケースの抜け漏れを機械的に検出する4つの方法

「漏れがないか確認しましょう」で終わるレビューは、結果が担当者の経験値に依存します。作成した観点表を、誰がやっても同じ結論になる形で検証する4つの方法を紹介します。特別なツールは不要です。

方法	検出できる漏れ	所要時間の目安	インプット
1 トレーサビリティ突合	仕様にあるのに観点がない領域	突合行数 × 1〜2分	仕様書か画面・API一覧
2 過去バグ票の逆引き	自社が繰り返し落とす穴	初回3〜4時間	障害記録、なければ記憶
3 品質特性の悉皆チェック	非機能観点の丸ごと欠落	1〜2時間	品質特性の一覧
4 語彙突合	仕様にあるのに扱われない対象	1時間前後	用語定義・項目一覧

方法1 仕様書と観点表をIDで突き合わせる

最も確実なのが仕様書と観点表の突合です。ただし全機能を一度にやる必要はなく、優先度「高」の機能に限定した部分適用から始めるのが現実的です。突合の単位は手元の資料に合わせて選びます。

項番が振られた設計書がある場合: 仕様書の項番をそのまま突合の行にする
項番がない場合（Excel・Word・議事録・課題管理ツールに散在）: 画面一覧・API一覧・データ項目一覧を代用の行にする

観点表の各行に観点ID（V-01、V-02…）を振る
突合単位（項番、または画面・API）を縦に並べた表を作る
各行に対応する観点IDを記入する
観点IDが1つも書かれていない行を抽出する
その行が「観点不要」か「漏れ」かを判定し、理由を残す

所要時間は1行あたり1〜2分が目安です。画面5〜10・仕様書20ページ程度の機能なら、優先度「高」に絞れば2〜3時間で回せます。観点IDがない行は漏れの候補、どの行にも対応しない観点は思い込みか未文書化の仕様です。

この突合の価値は、漏れを「見つける」ことではなく、漏れの有無を「証明できる」ことにあります。上長やクライアントに網羅性を説明する際も、最も強い材料になります。

方法2 過去のバグ票から逆引きする

2つ目は、自組織の過去の障害を観点に変換する方法です。組織が繰り返し落とす穴には強い傾向があり、汎用のリストでは代替できません。

直近1〜2年の障害チケットを重大度順に30〜50件抽出する
各件について「どんな観点があれば検出できたか」を1文で書く
重複を統合し、案件固有の名詞を消して汎用化する
今回の観点表に同等の観点があるかを照合する
存在しないものを追加し、次案件へ引き継ぐ

障害記録がまとまって残っていない場合は記憶で代用します。直近案件のメンバー数名に「本番で出して肝を冷やしたバグ」を各数件ずつ挙げてもらえば、30分ほどで初版には十分な数が集まります。あわせて今回から障害票に「どの観点なら検出できたか」欄を足しておけば、次回は記録から逆引きできます。

方法1と方法2は、性質が異なる漏れを拾います。リー・コープランド『はじめて学ぶソフトウェアのテスト技法』では、欠陥分類を使わず要件・仕様からテストケースを作る非特定不具合モデルと、過去経験のある欠陥に似たものを発見できるよう作る特定不具合モデルが紹介されています。方法1が前者、方法2が後者です。

開発データを組織的に蓄積・分析する取り組みは公的機関でも行われており、IPAのソフトウェア開発分析データ集として公開されています。記録すべき項目を決める参考にできます。

方法3 品質特性による非機能観点の悉皆チェック

3つ目は、前章の品質特性の一覧を検証にも使う方法です。特性を縦に並べた点検表を作り、特性ごとに対応する観点が何行あるかを数えます。

0行の特性は「該当なし」か「漏れ」かを判定し、該当なしなら理由を1文で記録します。この記録を必須にすると、次の案件で再利用できる判断基準が育ちます。

方法4 仕様書の語彙と観点表を突き合わせる

4つ目は、扱う対象の名前で照合する簡易チェックです。仕様書の全文から名詞を機械的に抽出するのは現実的ではないため、すでに一覧化されている語彙を使います。

語彙リストを用意する（用語定義・データ項目一覧・画面項目定義をそのまま使う）
一覧がない場合は、その業務で扱う対象物の名前を30語程度、手で書き出す
各語が観点表に1回以上登場するかを確認する（表計算ソフトの検索で足ります）
一度も登場しない語について、観点が必要かを判定する

「返品」「代理店」「一時保存」といった語が仕様書に何度も出るのに観点表に1回も登場しないなら、その領域は丸ごと抜けている可能性が高いと判断できます。

観点レビューをチームの仕組みにする

観点出しを個人の技能から組織の仕組みに変えるには、レビューと資産化の運用が要ります。

実装していない人が1人入るだけでレビューは変わる

実装者は自分が通した経路に引きずられます。この偏りを打ち消す最も安価な方法が、実装していない人を1人レビューに入れることです。

専任のQAでなくてかまいません。別案件の開発者や業務に詳しい担当者でも効果があります。実装の前提を共有していない人が「これはどうなりますか」と聞ける状態が重要です。

レビュー観点を固定したチェックリストにする

レビューの質を安定させるには、毎回同じ問いを投げることです。ただし全項目を毎回確認すると時間内に終わりません。頻度を分けます。

毎回確認する3項目（これだけなら20〜30分で回ります）:

根拠列が空欄の行はいくつあり、確認先は決まっているか
異常系の観点が、正常系に比べて極端に少なくないか
優先度「高」が全体の何割か（半分以上なら機能していない）

初回と大きな仕様変更時のみ確認する3項目（別枠で1〜2時間）:

非機能の観点が、品質特性の全項目で判定済みか
粒度が粗すぎる行（テストケース10件を超える行）はないか
過去の類似障害を、観点表のどの行で検出できるか説明できるか

各自が別々に資料を読むより、全員で1つの画面を見ながら観点表を上から追うほうが共通理解は早く形成されます。ある受託開発のテスト支援現場の振り返りでも、同じ画面を全員で見る時間が全体像の共通理解を作ったと報告されていました。

観点整備の投資対効果を上長にどう説明するか

「観点表を整備する時間をください」と言うには、数字が要ります。業界平均ではなく、自社の実績を当てはめるのが最も説得力を持ちます。

集める数字	取得元	使い方
A リリース後バグの対応実工数	直近3案件の障害対応記録・工数表	現状の損失の実測値
B 観点整備の見込み工数	5ステップの目安（4〜6時間）× 案件数	投資額
C 観点があれば防げた件数	Aの障害を1件ずつ仕分け	効果の見込み上限

「A ×（C ÷ 障害の全件数）− B」が正になれば、投資は回収できる見込みだと説明できます。重要なのは金額の精度ではなく、判断を勘から自社の実測値に移すことです。Cの仕分けは方法2の逆引きと同じ作業なので、一度やれば両方の材料になります。

観点表を案件をまたいで資産化する

観点表の価値は2案件目から跳ね上がります。作り捨てているうちは同じ穴を踏み続けます。

タイミング	やること	残るもの
案件開始時	前案件の観点表を雛形として複製	立ち上げ時間の短縮
テスト設計時	今回固有の観点を追記	案件別の差分
リリース後	流出した不具合を観点表に追記	検出できなかった観点の補強
案件終了時	汎用化できる行を共通観点表へ昇格	組織の共通資産