受入テスト仕様書

受入テスト仕様書の軸は「発注側の立場で合否を決める」ことにあります。システムテストが開発側の品質確認であるのに対し、受入テストは発注側が業務の目線で納品物を検収する工程です。その試験条件と判定基準を事前に書き起こしておくのが、この仕様書の役割になります。

作成の主体は発注側の業務担当者とPMで、現場の運用を知る利用部門が観点を持ち寄ります。開発ベンダーが草案を支援する場合もありますが、合否の基準そのものは発注側が握るのが基本です。これは、検収後に「言った言わない」の争点を残さないための線引きでもあります。

位置づけとしては、要件定義書で合意した業務要件を起点に、受入テスト計画で全体の進め方を決め、その下に個別の試験項目を落とし込んだものが仕様書にあたります。計画が『いつ・誰が・どこまで』を扱うのに対し、仕様書は『どの操作で・何を確認し・どうなれば合格か』という粒度を扱う、という分担で考えると整理しやすくなります。

つまずきやすいのは、開発側が作ったシステムテストの項目をそのまま流用してしまうことです。機能が動くかどうかの確認に寄りすぎて、実際の業務が回るかという発注側の視点が抜け落ちやすく、検収の意味が薄れてしまいます。

構成の軸は「一つの試験を、第三者が同じ手順で再現できるか」です。具体的には、次のような項目をそろえておくと、実施者が替わっても判定がぶれにくくなります。

• 試験項目のID と対応する要件
  どの要件を確認するための試験かを紐づけ、要件定義書との対応を追えるようにします。
• 前提条件とテストデータ
  どの利用者権限で、どんなデータが登録された状態から始めるかを明示し、再現性を担保します。
• 操作手順と入力値
  画面上でどの順に何を操作し、どの値を入力するかを、迷わない粒度で書きます。
• 期待結果と合否基準
  どの表示や出力になれば合格かを言い切り、判断が人によって割れないようにします。

これらに加えて、実施日・実施者・実際の結果・合否・不具合番号を記録する欄を設けておくと、検収のエビデンスとそのまま一体化します。帳票の出力や他システムとの連携のように、画面操作だけで確認しづらい項目は、確認方法を別途書き添えておくと迷いが減ります。

つまずきやすいのは、期待結果を「正しく表示されること」といった曖昧な言葉で済ませてしまう点です。何をもって正しいとするかが読み手に委ねられ、同じ試験でも実施者によって合否が分かれてしまいます。金額・件数・ステータスなど、確認する対象を具体的に書くほど判定は安定します。

進め方の軸は「要件から試験項目へ、漏れなく落とす」ことです。おおまかには次の順で進めると、抜けが見えやすくなります。

1. 要件の棚卸し
   要件定義書の項目を一覧化し、受入で確認すべきものと、設計・開発側で担保済みのものを仕分けます。
2. 業務シナリオの洗い出し
   日常の処理だけでなく、月次や例外処理など、現場で実際に起きる流れを並べます。
3. 試験項目への分解
   各シナリオを、一つずつ合否を出せる単位に割り、前提と期待結果を書き込みます。
4. 利用部門のレビュー
   現場の担当者に目を通してもらい、業務実態と合っているかを確認します。

PMの関わり方としては、自分で全項目を書くというより、利用部門が観点を出しやすいように枠組みと粒度をそろえ、要件との対応漏れを見張る役回りが中心になります。開発ベンダーとは、テストデータの準備や試験環境の用意について早めにすり合わせておくと、実施段階で手戻りが起きにくくなります。

つまずきやすいのは、正常に動くケースばかりを並べてしまうことです。入力を誤ったとき、データが想定外だったときにどう振る舞うかを確認しないと、本番で初めて問題が表に出ます。異常系や境界のケースを意識して項目に含めておくことが、検収の質を左右します。

比較の軸は「誰の視点で、何の合否を扱うか」です。似た名前の文書が並ぶため、位置づけを押さえておくと混同を避けられます。

• システムテスト仕様書との違い
  システムテストは開発側が機能や性能を確認する文書で、観点は仕様どおりに作られているかにあります。受入テスト仕様書は発注側が業務の成立を確認するもので、合否の主体が異なります。
• 要件定義書との違い
  要件定義書は何を実現したいかという期待を定めます。受入テスト仕様書は、その期待が満たされたかを確かめる手順と基準に落とし込んだもので、要件を検証可能な形に翻訳した位置づけです。
• 受入テスト計画書との違い
  計画書は体制・期間・対象範囲といった全体の枠を扱います。仕様書はその下で個別の試験項目を具体化する役割を持ちます。

実務では、これらが別々に存在するというより、要件から計画、そして仕様へと段階的に細かくなっていくつながりとして捉えるほうが扱いやすくなります。つまずきやすいのは、要件定義書に検証できない表現が残ったまま進んでしまうことです。測りようのない要件は試験項目に落とせず、受入段階で基準づくりに手間取ります。要件を固める時点で、どう確認するかまで意識しておくと後工程が楽になります。

受入テスト仕様書を扱えることは、PMにとって発注側と開発側の境目を設計できる力の表れになります。要件を検証可能な基準へ翻訳し、利用部門から観点を引き出し、検収のエビデンスとして形に残すという一連の動きは、品質管理やステークホルダー調整と地続きです。ここを押さえておくと、プロジェクト終盤で検収の根拠が曖昧になり、納品の合意形成が長引くといった事態を避けやすくなります。

転職や職域の拡張を考える場面でも、受入工程を語れるかどうかは一つの見分けどころになります。開発の進捗だけでなく、発注側の業務が本当に回るところまで見届けた経験は、上流から運用までを通して任せられる人材かどうかの判断材料になりやすいためです。要件定義から検収までを一本の線でつなげて説明できると、担える範囲の広さが伝わります。

受入テスト仕様書は発注側と開発側のどちらが作りますか

合否の基準を握るのは発注側のため、発注側の業務担当者とPMが主体となって作成します。開発ベンダーがテストデータの準備や草案づくりを支援する場合もありますが、業務が成立するかの判定観点は発注側が決めるのが基本です。利用部門のレビューを通して実態と合わせます。

システムテスト仕様書をそのまま流用してよいですか

流用はおすすめしにくいです。システムテストは機能が仕様どおり動くかを開発側が確認するもので、観点が異なります。そのまま使うと、実際の業務が回るかという発注側の視点が抜けやすくなります。要件と業務シナリオを起点に、受入の目的に沿って項目を組み直すほうが検収の意味を保てます。

期待結果はどの程度細かく書けばよいですか

実施者が替わっても同じ合否になる粒度を目安にします。「正しく表示される」ではなく、どの金額・件数・ステータスになれば合格かを具体的に書き切ると、判断のぶれが減ります。画面で確認しづらい帳票や連携は、確認方法を書き添えておくと迷いにくくなります。