システムテスト仕様書テンプレート｜項目と記入例

2026 10/21

2026年10月21日

結合テストまでは順調だったのに、システムテストに入った途端に「何を、どこまで、どう確認すれば終わりなのか」が曖昧になった——。受託開発の現場では、こうした停滞がリリース直前の品質妥協につながりがちです。

原因の多くは、システムテストの仕様書が整っていないことにあります。業務シナリオ全体や非機能、本番相当環境での確認は、単体・結合の延長で書いても抜けが出ます。テストを兼任でこなしていると、なおさら仕様書を作る時間が取れず、結果として現場任せの属人的な確認になってしまいます。

この記事では、そのまま流用できるシステムテスト仕様書のテンプレートを、章立て・記載項目・記入例までセットで示します。あわせて、システムテスト特有の観点、単体・結合との書き分け、よくある失敗と回避策まで、現場の判断基準を交えて解説します。

読み終えたときには、自社の案件に当てはめて書き始められる状態を目指します。上長やクライアントに「このテストで何を保証するのか」を説明する材料としても使える構成にしています。

システムテスト仕様書は何を定義する文書か

まず押さえたいのは、システムテストが「結合後、本番に近い環境で業務シナリオ全体を検証するテスト」である点です。モジュール単体でも、モジュール間の連携でもなく、利用者が実際に行う一連の業務が最初から最後まで成立するかを確かめます。

その検証内容を、誰が実行しても同じ結果にたどり着く粒度で書き起こしたものが、システムテストの仕様書です。言い換えると「何を・どの観点で・どうなれば合格とするか」を事前に確定させる定義書だと捉えると、役割がはっきりします。

具体的には、次の3点を言語化するのがこの文書の役目です。

範囲: どの業務・どの機能を、どこまで確認するのか
観点: 業務シナリオ・データ連携・非機能など、どの切り口で見るのか
合否: 何がどうなれば「このテストは終わった」と言えるのか

仕様書は「テスト計画書」とも「テスト結果報告書」とも別物です。計画書が体制・スケジュール・範囲の大枠を決める文書、報告書が終わった後の結果をまとめる文書であるのに対し、仕様書は「これから何をどうテストするか」を定義します。

計画と仕様の違いが曖昧なまま進めると、計画書に細かい確認項目を書き込みすぎて重くなったり、逆に仕様書が計画の話で埋まったりします。文書の住み分けはテスト計画の立て方と計画書の役割を整理するもあわせて確認すると明確になります。

単体・結合・システムの書き分け

同じ「テスト仕様書」でも、テストレベルが変われば書くべき内容は大きく変わります。JSTQB が整理するテストレベルの考え方（JSTQB 認定テスト技術者資格の公式サイトを確認する）に沿うと、各レベルの目的と検証対象は次のように区別できます。

観点	単体テスト	結合テスト	システムテスト
検証対象	関数・クラス単体	モジュール間の連携	システム全体の業務
主な視点	ロジックの正しさ	インターフェース・データ受け渡し	業務シナリオ・非機能
環境	開発環境	結合環境	本番相当環境
期待結果の基準	詳細設計	基本設計・IF仕様	要件定義・業務フロー
合否の判断者	開発担当	開発リーダー	PM・品質責任者
外部連携	モック・スタブで代替	一部実接続	実環境に近い接続

このように、システムテストだけが「業務」と「本番相当環境」を正面から扱います。だからこそ、単体・結合の仕様書をそのまま流用すると、観点が機能単位に偏り、業務全体の抜けが生まれます。

たとえば、受注機能も在庫機能も個別には正しく動くのに、受注から在庫引当へ進む業務の流れでデータの受け渡しが崩れる、といった不具合は単体・結合では見つけにくいものです。システムテストは、まさにこの「つながり」を検証します。

受託開発では、この書き分けがそのまま顧客への説明材料になります。「単体・結合でここまで確認済み、システムテストでは業務全体と非機能をこう確認する」と段階を示せると、どの品質を誰が担保しているかが伝わります。逆に書き分けが曖昧だと、受け入れ段階で「ここは確認したと思っていた」という認識のズレが表面化し、手戻りや信頼の毀損につながります。仕様書は、テストの実務だけでなく、品質の約束を文書で共有する役割も担っています。

単体・結合それぞれの書き方は、単体テスト仕様書テンプレートと記載例を確認する、結合テスト仕様書の作り方と項目例を確認するで詳しく扱っています。本記事はシステムレベルに振り切って解説します。

仕様書に必要な章立て（テンプレートの全体像）

テンプレートの全体像から押さえます。システムテストの仕様書は、次の9つの章で構成すると過不足なくまとまります。これは IEEE 829 や ISO/IEC/IEEE 29119 といったテストドキュメントの国際標準が示す構成を、受託開発の実務向けに整理したものです。

章	役割	この章で決めること
目的	テストの狙いを示す	何を保証するテストか
前提・環境	実施条件を固定する	どの環境・データ・権限で行うか
対象範囲	範囲を線引きする	テストする／しない業務
テスト観点	切り口を定義する	業務・連携・非機能などの視点
シナリオ一覧	検証対象を列挙する	どの業務フローを流すか
テストケース	手順に分解する	入力・手順・期待結果
合否基準	終了判定を定める	個別と全体の合格条件
体制・スケジュール	実行計画を示す	担当・期間・レビュー
課題管理	不具合を管理する	検出課題と残課題の扱い

重要なのは、章を埋めること自体が目的ではなく、「対象範囲」と「合否基準」を先に確定させることです。この2つが曖昧なまま走り出すと、テストがどこまで行っても終わらない状態に陥ります。

実務では、まず章立てだけを自社フォーマットへ移し、空の見出しを並べた状態を作ります。そのうえで、埋めやすい「前提・環境」や「対象範囲」から着手すると、全体像を保ちながら書き進められます。各章の詳細と記入例は次のセクションで示します。

なお、9章すべてを毎回フルで書く必要はありません。小規模な改修案件では、目的・対象範囲・シナリオ・合否基準の4章に絞っても機能します。案件の規模とリスクに応じて章を取捨選択し、過剰な文書作成で工数を浪費しないことも大切です。大切なのは章数ではなく、迷いを生む曖昧さを残さないことです。

【コピーして使える】システムテスト仕様書テンプレートと記入例

ここからが本題です。先ほどの9章それぞれについて、記載項目と記入例をセットで示します。自社の案件名・環境名に置き換えれば、そのまま下書きとして使えます。題材は、受注管理システムを例にしています。

目的・前提・環境・対象範囲

仕様書の冒頭では「何のためのテストか」と「どこで実施するか」を明確にします。ここが曖昧だと、後続のケースの前提が揺らぎます。

記載項目	記入例
目的	受注管理システムの全業務フローが本番相当環境で正常に完結することを確認する
前提条件	結合テストが完了し、残課題が「高」以下であること
テスト環境	ステージング環境（本番と同一構成・マスキング済み本番相当データ）
使用データ	移行後の顧客マスタ1万件・商品マスタ3千件を投入
テストアカウント	管理者・一般・外部取引先の3ロール
対象範囲	受注〜出荷〜請求の基幹業務フロー
対象外	帳票の印字レイアウト微調整（別途目視確認）

対象外を明記することは、対象範囲を書くことと同じくらい重要です。「書いていない＝やらない」の合意がないと、現場で際限なく範囲が広がり、工数が読めなくなります。

環境の記載では、本番との差分を正直に書くことがポイントです。外部連携先をモックに差し替えている、データ量が本番より少ない、といった差分は不具合の見逃し要因になるため、前提条件に明記して関係者に共有します。

テスト観点・シナリオ一覧

次に、どの切り口で検証するかという観点と、検証する業務シナリオの一覧を定義します。観点は「業務シナリオ」「データ連携」「非機能」などに分類しておくと、抜けに気づきやすくなります。

シナリオID	業務シナリオ	主な観点	優先度
SC-01	新規受注〜在庫引当〜出荷指示	業務シナリオ・在庫連携	高
SC-02	受注変更〜再引当〜出荷差し替え	業務シナリオ・例外処理	高
SC-03	月次締め〜請求データ生成〜会計連携	データ連携・バッチ	中
SC-04	同時アクセス時の在庫引当	非機能（性能・競合）	中
SC-05	外部決済サービス障害時の代替フロー	異常系・外部連携	中

シナリオは、要件定義や業務フロー図から「利用者が実際にたどる道筋」を抜き出すのがコツです。機能一覧からではなく業務の流れから起こすことで、機能はそろっているのにつながらない、という典型的な抜けを防げます。

優先度は、業務への影響度と発生頻度で決めます。基幹の受注フローは「高」、月末だけ動く締め処理は「中」というように、メリハリをつけておくと、時間が足りなくなったときに何から削るかの判断が速くなります。

テストケース・合否基準

シナリオを、実行手順と期待結果に分解したものがテストケースです。システムテストでは「業務として成立したか」を期待結果に書くのがポイントです。画面単位の細かな遷移確認は結合テストで済ませ、ここでは業務の結末を見ます。

ケースID	前提	手順	入力データ	期待結果	合否
TC-01-01	在庫10個	受注5個を登録し出荷指示まで実行	商品A×5	在庫が5に減り出荷指示が生成される	該当なし（実行前）
TC-01-02	在庫3個	受注5個を登録	商品A×5	在庫不足として警告し受注が保留になる	該当なし（実行前）
TC-03-01	当月受注100件	月次締めバッチを実行	対象期間を当月指定	請求データ100件が生成され会計へ連携される	該当なし（実行前）

合否の「該当なし（実行前）」は、まだ実行していないことを示す初期値です。空欄にせず必ず値を入れることで、記入漏れと未実施を区別できます。実行後は「合格」「不合格」「保留」などへ更新します。

全体の合否基準は次のように定義します。

個別ケース: 期待結果と実際の結果が一致すれば合格
シナリオ単位: 優先度「高」のケースが全て合格
全体終了判定: 残不具合の重大度が「中」以下、かつ回避策が合意済み

合否基準は「残不具合ゼロ」ではなく「残不具合が許容範囲内で合意済み」と書くのが現実的です。ゼロを基準にすると永遠に終わりません。テストケースそのものの書き方は、他人が迷わず実行できる項目と例を別記事で整理しているので、基礎から固めたい場合はそちらも参考になります。

体制・スケジュール・課題管理

最後に、誰がいつ実施し、見つかった課題をどう扱うかを定義します。受託開発では、この章が顧客への説明責任を果たす材料になります。

項目	記入例
テスト担当	自社2名（実行）＋顧客1名（受入観点の立ち会い）
期間	2週間（うちバッファ3日）
レビュー体制	仕様書は着手前にPMと顧客がレビュー・承認
課題管理	不具合は管理表で重大度・対応期限・担当を管理
報告頻度	日次で進捗と残課題を共有

課題管理では、検出した不具合の重大度と残課題の扱いを明確にします。次のように、重大度ごとに対応方針を先に決めておくと、現場で判断に迷いません。

重大度	定義	対応方針
高	業務が止まる・データが壊れる	リリース前に必ず修正
中	代替手段で業務は回る	期限を決めて修正
低	軽微・見た目の問題	合意のうえ次期対応も可

スケジュールは開発スケジュールに引きずられやすいため、バッファを明示しておくことが欠かせません。前工程の遅れを吸収する余白がないと、システムテストが最も圧縮され、品質妥協の直接の原因になります。

記入でつまずきやすい項目のコツ

テンプレートの枠はすぐに埋められても、実際に書き始めると手が止まる項目があります。現場でよく質問される箇所について、記入の判断基準をまとめます。

つまずく項目	よくある悩み	記入の判断基準
対象範囲	どこまで書くか決まらない	業務フロー単位で区切り、機能名ではなく業務名で書く
期待結果	画面表示だけ書いてしまう	データ・連携先の変化まで含めて書く
優先度	全て「高」になる	業務停止につながるものだけ「高」に絞る
合否基準	書けずに空欄にする	残不具合の重大度で全体判定を定義する
前提条件	本番との差分を書き忘れる	モック利用・データ量の差を正直に明記する

記入に迷ったら、「この行だけ読んだ別の担当者が、同じ手順で同じ結論に至れるか」を基準にしてください。再現できない記述は、粒度か情報が足りていないサインです。

もう一つのコツは、完璧な初版を目指さないことです。まず8割の精度で全章を埋め、着手前のレビューで顧客と埋めきれなかった前提を確定させる進め方が、結果的に手戻りを減らします。仕様書は一度で完成させる文書ではなく、レビューを通じて合意を積み上げる土台と考えると、着手のハードルが下がります。

システムテスト特有のテスト観点をどう洗い出すか

システムテストで最も差が出るのが、観点の洗い出しです。機能一覧をなぞるだけでは、業務全体や非機能の抜けに気づけません。システムテスト特有の観点は、次の5つの切り口で整理すると漏れが減ります。

業務シナリオ／エンドツーエンド: 複数機能をまたぐ一連の業務が完結するか
データ連携: 画面・バッチ・外部システム間でデータが正しく受け渡されるか
非機能: 性能・負荷・セキュリティなど、動くだけでは分からない品質
本番相当環境: 本番と同じ構成・データ量・権限で問題が出ないか
異常系・業務例外: 障害・中断・差し戻しなど、正常に進まない場合の挙動

単体・結合で「機能は動く」と確認済みでも、業務としてつながるか・本番の負荷に耐えるかは別問題です。システムテストはそこを引き受けます。

特に見落とされやすいのが、複数の業務が同時に走るケースです。ひとりが受注を登録している最中に、別の担当が同じ在庫を引き当てたらどうなるか。こうした同時実行や競合は、机上のシナリオからは抜けやすく、本番で初めて露呈しがちです。

観点を体系的に洗い出す手順そのものは、テスト観点の洗い出し手順と観点表の作り方を確認するで詳しく解説しています。観点表を先に作り、そこからシナリオへ落とす順序にすると、仕様書の網羅性が安定します。

非機能の観点は数値で合否を決める

非機能は「速い・安全」といった曖昧な言葉では検証できません。合否を数値で定義することが欠かせません。性能の目安を社内で決める際は、IPA が公開するソフトウェア開発分析データ集を参照するのような公的データを参考にし、根拠を持って基準を設けると、顧客への説明がしやすくなります。

非機能観点	合否基準の例	確認方法
応答性能	主要画面の応答が2秒以内	代表業務での計測
同時実行	想定同時50ユーザーで処理が破綻しない	負荷ツールで再現
セキュリティ	権限外データへアクセスできない	ロール別の境界確認
耐障害性	外部連携の障害時に代替フローへ切り替わる	障害注入で確認

数値の根拠は、要件定義や非機能要求の合意事項から引くのが基本です。合意がない項目は、仕様書を作る段階で顧客と握り直します。「なんとなく速ければよい」で進めると、合否が判定できず、テストが主観の押し問答になります。

テストケースの粒度と合否基準の書き方

システムテストのテストケースは、細かすぎても粗すぎても機能しません。粒度の判断には現場の基準があります。

細かすぎるケースは、画面の1クリックごとに1行を割り当てるような書き方です。これは結合テストの領域であり、システムテストで同じ粒度にすると件数が膨れ、業務の流れが見えなくなります。逆に粗すぎると「受注業務が正常に動くこと」のような一文になり、誰も同じ手順を再現できません。

判断の目安は、「1ケース＝利用者が意味のある1区切りを完了するまで」です。受注登録から在庫引当までを一塊にするなど、業務の節目で区切ると過不足が減ります。

粗すぎる例: 「受注業務が正常に完了すること」（手順が再現できない）
細かすぎる例: 「受注ボタンを押すと確認ダイアログが出ること」（結合テストの粒度）
適切な例: 「在庫10個の状態で5個受注し、在庫5・出荷指示生成を確認する」

期待結果は「業務の結末」で書きます。画面表示だけでなく、在庫・帳票・連携先データがどう変化するかまで含めると、システムテストらしい検証になります。たとえば「出荷指示が生成される」だけでなく「在庫テーブルが正しく減算される」「連携先の会計システムにデータが届く」まで確認対象に含めます。

合否基準は、個別ケースと全体の2段階で定義します。個別は期待結果との一致で機械的に判定し、全体は残不具合の重大度で判定します。この2段階を分けておくと、「個々は合格だが全体としてリリースしてよいか」という判断を、感覚ではなく基準で下せます。

ケース数が増えすぎたときは、優先度で絞り込みます。基幹業務のシナリオは厚く、使用頻度の低い業務は代表ケースのみ、という配分が現実的です。全てを同じ密度で書くと作成も実行も破綻します。限られた時間でどこに力を割くかを決めるのも、仕様書の重要な役割です。網羅性の高さよりも、重要な業務を確実に押さえる判断を優先してください。

移行・運用との境界と非機能の扱い

システムテストでつまずきやすいのが、データ移行や運用との境界です。ここを仕様書で線引きしておかないと、責任の押し付け合いが起きます。

データ移行は「移行作業そのものの検証」と「移行後データでの業務検証」に分けて考えます。前者は移行テストの領域、後者はシステムテストの領域です。移行後の本番相当データで業務シナリオを流すのがシステムテストの役割になります。移行作業自体の検証はデータ移行テストの進め方と検証設計を確認するで扱う領域と切り分けましょう。

領域	主担当テスト	システムテストでの扱い
移行ツールの正確性	移行テスト	対象外（結果データのみ利用）
移行後データでの業務	システムテスト	対象（本番相当データで検証）
運用手順・監視	運用テスト	一部（障害時の業務影響を確認）
本番切り替え手順	運用・リリース	対象外（別途リハーサル）

「移行データで業務が回るか」はシステムテストの責任範囲です。きれいなテストデータでは通っても、現実の重複・欠損を含むデータで初めて露呈する不具合は少なくありません。仕様書の前提条件に「本番相当データを使う」と明記しておきます。

運用との境界も同様です。監視やバックアップの手順確認は運用テストの領域ですが、「障害が起きたときに業務がどう影響を受けるか」はシステムテストで確認します。境界をあえて重ねる部分と切り分ける部分を仕様書に書き分けておくと、抜けと重複の両方を防げます。

本番切り替え手順の確認は、システムテストではなくリリースリハーサルで扱うのが基本です。ただし、切り替え後に業務が正常に回るかの最終確認はシステムテストの範囲と重なります。どこまでを仕様書に含め、どこからをリハーサル計画に委ねるかを、工程の早い段階で関係者と合意しておくと、終盤の混乱を避けられます。境界の判断に迷ったら、「本番に出た後に誰が責任を持つ範囲か」を基準にすると整理しやすくなります。

システムテスト仕様書でよくある失敗と回避策

最後に、現場で繰り返し起きる典型的な失敗を、匿名化した形で紹介します。どれも仕様書の書き方で予防できるものです。

失敗1：機能一覧からケースを起こした

機能はそろっているのに業務がつながらない、という抜けが頻発します。業務フローからシナリオを起こす順序に変えると防げます。

失敗2：合否基準を書かずに走り出した

「どこまでやれば終わりか」が人によって違い、テストが延々と続きます。着手前に終了判定を数値で合意します。

失敗3：テストデータがきれいすぎた

本番相当データに差し替えた途端に不具合が噴出します。前提条件にデータ条件を明記し、早い段階で本番相当データを投入します。

失敗4：非機能を後回しにした

リリース直前に性能問題が発覚し、手戻りが致命傷になります。非機能の合否基準を仕様書の時点で数値化しておきます。

失敗5：対象外を書かなかった

「これもやってくれると思っていた」という認識のズレが、受け入れ段階で表面化します。対象外を明記し、着手前に合意します。

失敗	根本原因	仕様書での回避策
業務の抜け	機能視点で設計	業務フローからシナリオを起こす
終わらないテスト	合否基準なし	終了判定を数値で事前合意
本番で露呈	データが理想的	前提に本番相当データを明記
直前の性能問題	非機能が後回し	非機能基準を数値で先に定義
認識のズレ	対象外が未記載	対象外を明記し着手前に合意