登録も取消もできた。それでも受け取っていい？受入テスト・検収で確かめること

たとえば、備品の貸出登録はできる。取消もできる。それでも、このシステムを受け取って使い始めてよいかは、合格した項目の数だけでは決まりません。

備品貸出システムで残った三つの問題から、受入れの判断方法を見ていきます（想定例）。

残っていること	判断
一般社員に他部署の情報が見える（U04）	受入れを止め、権限を直して試し直す
通知停止後の再処理をまだ試していない（U06）	問題なしとは扱わず、実施まで保留する
PDFで長い備品名が切れる（U05）	CSVで全文を読めることと業務上の影響を見て、修正期限付きで残せるか判断する

権限の不具合は情報が見えてしまうため、修正が先です。未実施の項目は、試すまで良否が分かりません。表示不具合は、代わりの方法で仕事ができるかを確かめたうえで扱いを決めます。この違いを、項目ごとの結果と全体の受入判断に書き分けます。

受入テストで確かめることと検収の違い

開発会社は、仕様どおりに動くことや、機能を組み合わせたときの動作を試験します。発注者は、現場の手順、出力される帳票、利用者ごとの操作、困ったときの対応を確かめます。日々使う担当者が操作し、受入れを判断する人をあらかじめ決めておくと、気づいた問題を判断につなげられます。

デジタル庁の実践ガイドブックは、業務を正しく実施できるかを発注者の視点で確認し、現場担当者を受入テストに組み込む考え方を示しています。目的、業務シナリオ、具体的な確認項目を分けて準備する事例も掲載しています（出典：デジタル庁「デジタル社会推進実践ガイドブック DS-120」第3編第7章、54〜56ページ（PDF））。

受入テストは、実際の操作で期待結果を確かめる作業です。検収は、その結果や納品物をもとに、契約で定めた方法で受け取りを確定する手続きです。運用開始には、使う人への案内やデータの準備なども関わります。テスト結果、検収の手続き、運用開始日を別々に記録しておけば、どこまで終わったかが分かります。

操作手順より先に期待する結果を決める

「一通り触って問題がなければ合格」では、判断が担当者の感覚に寄ります。試す業務ごとに、誰が、どの状態から、何を行い、どんな結果になればよいかを先に書きます。画面だけでなく、一覧、帳票、通知、保存された記録のどこで結果を確かめるかも決めます。

まず、日常の業務を一つ選び、どんな記録や帳票が出れば完了と判断できるかを書いてください。通常の流れに加えて、業務停止、金額の誤り、情報の漏えいにつながる操作を優先して確かめます。正常な操作と異常な操作を同数にそろえる必要はありません。利用頻度と、失敗したときの影響から選びます。画面の速さのような性能も受け入れの条件に入れる場合は、性能要件の決め方と遅いときの調べ方で測り方を決めておきます。

備品貸出で試す業務の例

各項目は、それぞれの前提に戻して確かめます。

確認IDと場面	期待する結果
U01 通常の貸出	空いている備品を貸すと、借りた人と返却予定日が一覧に出る。
U02 重複した貸出	貸出中の備品を別の人に貸そうとすると止まり、元の貸出記録が残る。
U03 貸出の取消	貸出を取り消すと空き状態に戻り、取消の記録も残る。
U04 利用者の権限	一般社員が管理用の一覧を開こうとしても、他部署の貸出情報は見えない。
U05 帳票との照合	一覧と貸出台帳の件数・借りた人・返却予定日が一致し、備品名の末尾まで読める。
U06 停止後の再処理	通知が止まった後に再処理しても、貸出記録と通知が重複しない。

入力欄には空欄、長い名称、重複する値なども用意し、案内が出ることと、誤った記録が保存されないことの両方を確かめます。取消や再処理では、操作前後の状態を見比べます。

実務用のテストデータも、まずは実際の個人情報や取引情報をコピーせず、現場で使う値の長さや空欄などの特徴を再現します。移行した実データの照合が必要な案件では、使用する環境、閲覧できる人、保管・削除の条件を事前に決めます。

返却した工具を、点検前に貸し出せないか試す

工具の貸出・返却・点検の操作例では、架空の工具TL-007で返却後の流れを試せます。2026年10月26日の画面確認では、返却受付により「点検待ち」へ移り、点検を終えるまで貸出の入力へ進みませんでした。返却の受付と、再び貸せる判断を分けた例です。

次の順で操作すると、止まることと、正しい条件で進めることの両方を確かめられます。

操作	この画面で確認した結果
選択中のTL-007で「受け取った（点検台へ）」を押す	点検待ちが3点から4点へ増え、工具の記録に返却が追加された
破損・動作・付属品・棚へ戻したことを選び、点検者は選ばない	「あと：点検者」と表示され、「点検を終える」は押せなかった
点検者を選んで「点検を終える」を押す	点検待ちは3点へ戻り、担当者付きの点検記録と貸出の入力が表示された

自社の受入確認表へ追加するなら、現物番号、点検前の状態、必要な確認項目、期待する停止、点検後の状態を書きます。停止の試験だけでは、必要な担当者まで作業できなくなった不具合を見逃すので、最後の行も一緒に試してください。

これは画面の操作結果です。U04の利用者ごとの閲覧制限や、U06の通知停止後の再処理を試した結果には置き換えられません。それらは自社の試験環境で、合意した利用者と通知先を使って確かめます。

期待結果と実際の結果を分けて記入する

確認表には、実際に見た結果を期待結果とは別に書きます。「問題なし」だけでは、何を見て合格にしたのか分かりません。どの備品を誰に貸し、どの一覧や記録で確かめたかを残します。

U01 通常の貸出の記入見本

項目	記入例
前提	検証用 v1.0。総務担当でログイン。備品EQ-001は空き。
操作	社員Aへ貸し出し、返却予定日を2026年9月20日にする。
期待結果	一覧に社員Aと返却予定日が出て、貸出記録が1件残る。
実際の結果	社員Aと返却予定日が表示された。貸出記録は1件。
証拠	U01_貸出一覧、U01_貸出記録という名前で保存する想定。
項目の判定	合格。確認者は佐藤、確認日は2026年9月13日。

確認IDは、修正を依頼するときにも使います。U04で権限の問題を見つけたら、不具合記録にもU04と記入します。開発会社へ伝えるときは、使った版、操作した人の権限、操作手順、期待と実際の違い、証拠をそろえます。証拠を共有する前に、個人情報や不要な情報が写っていないかも確認します。

記入用資料には、6つの試験項目と対応記録の見本、結果を入れていない空欄版を収録しています。

• 受入確認表と不具合記録をExcelで記入する
• 空欄版と記入見本を印刷する
• 受入確認表のCSV／不具合記録のCSV

不具合の影響と受入判断を分けて考える

記録では、業務への影響、テスト項目の合否、修正がどこまで進んだか、全体を受け入れるかを分けます。たとえばU05は、PDFの備品名が切れている間は不合格です。CSVで仕事を続けられると合意しても、PDFを修正済み・テスト合格にはしません。表示上の不具合であっても、金額を読み違える、別の相手へ送るといった結果につながるなら、軽微とは扱えません。

重大なものは受入れを保留し、修正と再確認へ進みます。業務に支障がある不具合は修正範囲と期限を決め、軽微でも回避手順を実際に確かめます。どこまで残せるかは、案件の業務と合意した条件によって変わります。合意範囲にない追加要望は、元の項目の合否と分けて費用・納期を相談します。

重要な項目の未実施は、「軽微」や「合格」には入りません。たとえば通知停止を再現する準備ができずU06を試せなかった場合、問題が出なかったとは言えません。準備する人と確認日を決め、結果が出るまで判断を保留します。

U04 権限不具合の対応見本

項目	記入例
不具合IDと確認ID	D01／U04
期待と実際の違い	一般社員に見えないはずの他部署の貸出一覧が表示された。
重大度と初回判定	重大・不合格。受入れは保留。
修正担当と期限	開発担当の鈴木、2026年9月15日。
再確認条件	v1.1で一般社員の閲覧を止め、総務担当は一覧を使えることを試す。
再確認結果	両方とも合格。佐藤、2026年9月15日。証拠名はU04_再確認の想定。
受入判断	D01による保留を解除。ほかの未解決事項を含む全体判断は別に行う。

軽微な不具合を残す例では、U05の台帳PDFで長い備品名の末尾が切れています。件数や借りた人、返却予定日は一致し、CSVなら備品名の全文を読める、という設定です。CSVを使う回避手順を確認し、PDFの修正期限と再確認する人を決めます。回避できることだけで自動的に受入可能とはせず、その方法で業務ができるかを発注者が判断します。

修正後の再確認から検収と運用開始へ

再確認では、直した操作に加え、その修正で影響を受ける関連動作を確かめます。権限を直したなら、見せない相手への制限と、使うべき担当者が引き続き使えることを確認します。初回の不合格を消さず、修正版と再確認結果を追記すると、何が変わったかを追えます。

この見本では、U04の修正を確かめ、U06も実施して合格になった段階で全体を再判断します。残るU05について、CSVでの回避手順と修正期限に合意し、条件付きで受け入れる想定です。

全体の受入判断の記入見本

項目	記入例
判断日・判断者	2026年9月15日・田中
U04	v1.1で再確認済み。佐藤が権限制限と総務の利用を試し、合格。
U06	通知停止と再処理を実施し、合格。
U05	PDF表示は不合格のまま。CSVでは全文を読めた。
残る修正	鈴木が9月18日までにPDFを修正し、佐藤が再確認する予定。
全体の判断	CSVでの回避手順と上記対応を条件に受け入れる。

受入れの判断前には、次の内容をそろえます。

• 合意した試験項目が実施され、期待結果と証拠が対応している。
• 受入れを止める不具合が解消され、修正後の再確認が終わっている。
• 残す不具合の影響、回避手順、修正期限、担当、判断者の合意が記録されている。
• 納品物、操作手順、移行がある場合の照合結果、問い合わせ先がそろっている。

検収の期限や通知方法は契約に合わせます。IPAのモデル契約書の第27条は検査項目・データ・方法・期間を定める検査仕様書、第28条は検査、不合格理由の通知、修正後の再検査を扱っています。同条には、期間内に所定の異議を述べない場合の扱いもあります。自社の契約に同じ条件があるかを確認し、問題を見つけたら期限と通知方法に沿って伝えます（出典：IPA「情報システム・モデル取引・契約書（第二版）」第27・28条）。

本記事の条件付き受入れの例は、モデル契約書の条項をそのまま適用したものではありません。実際の契約でその扱いが可能かを確かめ、残る対応と検収の扱いを合意します。合意済みの範囲を確認する際は、システム開発費は何で決まる？予算別3案の比較も参考になります。

最後に、検収の手続きと運用開始の準備をそれぞれ進めます。利用者への案内、データの準備、問い合わせ先、開始日を決め、テスト用の記録が業務へ混ざらない状態にします。試作・PoC・MVPから本番へ進む条件と見送る条件では、試作の段階から判断条件を準備する方法を整理しています。

受入条件を試作段階から相談する

参考出典

• デジタル庁「デジタル社会推進実践ガイドブック DS-120」2025年5月27日版、第3編第7章54〜56ページ（PDF）
• IPA「情報システム・モデル取引・契約書（第二版）」2025年4月8日更新、第27・28条と解説