受入テストのチェックリスト
現場の流れで業務アプリを確かめる

入力も検索もできたので完成としたのに、運用を始めると差し戻しができない、月末の集計が合わない。個々の画面が動くことと、現場の仕事を最後まで進められることは別です。受入テストでは、自分たちの業務の流れで確認する準備をしておきましょう。

受入テストは、自分たちの業務に使えるかを確かめる場

開発前の要件整理は要件チェックリストで扱っています。この記事では、利用開始前に利用者側がどのように動作を確かめるかを整理します。契約上の検収条件や、開発側が行うテストの範囲は、別途すり合わせが必要です。

IPAの業務シナリオテストに関する資料でも、利用者の観点で業務の流れに即した確認を行う重要性が示されています。画面の機能を一つずつ確認することに加え、担当者間の受け渡しを含めて仕事を通すことが大切です。

試作段階で確かめるのは、主に画面や流れが業務に合うかです。そこを確認できても、完成版の権限、性能、データ移行まで確認済みになるわけではありません。試作で確認することと、本番利用前に残る確認を分けておきましょう。

先に、担当者・環境・合格の基準をそろえる

• 誰が入力し、誰が確認し、誰が利用開始を判断するか
• 対象の版、端末、ブラウザ、利用者ごとのアカウント
• 試験用データと、外部送信・本番データとの区別
• 何ができれば合格か、許容できない問題は何か
• 見つかった問題の連絡先と、修正後に再確認する担当者

『使いやすければ合格』だけでは、人によって判断が分かれます。たとえば『申請した経費が上長の一覧に出て、承認後に経理の集計へ含まれる』のように、画面を見て確認できる結果に置き換えます。

通常の流れと、例外の流れを一組で作る

上の表は架空の経費申請業務の例です。自社なら、受注から出荷、日報から集計、予約から精算など、実際の始点と終点に置き換えます。正常な一件が通るだけでなく、途中で戻った場合、担当者が代わった場合も確認しましょう。

「動いた」ではなく、期待と実際を記録する

不具合を伝えるときは、どのアカウントで、どんなデータを使い、どの順序で操作したかを残します。画面の画像だけでは前提が分からない場合があるため、対象の番号や操作手順も添えます。

予定した機能の不具合と、使ってみて新しく欲しくなった機能も分けます。後者をすべて受入の不合格扱いにすると、いつまでも利用開始を判断しにくくなります。必要性と対応時期を関係者で決め、合意した範囲を更新します。

残った問題と、利用開始の判断を見えるようにする

すべての問題を同じ重さで扱う必要はありませんが、後回しにする理由と、業務への影響は残します。入力内容が消える、権限外のデータが見える、重要な計算が合わない、といった問題を、見た目の微調整と同じ欄で曖昧にしないことが大切です。

• 利用開始前に解消する問題と、対応予定の問題が分かれている
• 修正した箇所を再確認し、関連する流れにも影響がないか見ている
• 問い合わせ先、障害時の代替手順、移行の段取りが共有されている
• 残る制約を利用者に伝え、判断した担当者と日付を残している

受入テストだけで、セキュリティや負荷に関するすべての専門的な検証を代替できるわけではありません。それぞれの確認担当と範囲を、開発担当と合わせておきます。

よく使う一つの業務を、最初から最後まで通してみる

初めから大きな試験書を作ろうとせず、まず現場でよく使う流れを一つ選びます。担当者、データ、操作、期待結果を書き、通常と例外を試してみる。その記録を増やしていくと、利用開始に必要な確認が具体的になります。

SHISAKUBAへの相談でも、試作品で『誰が何を最後までできればよいか』を決めておくと、見た目の感想だけでなく、業務に合うかを確かめやすくなります。

参考にした公式資料

• IPA：業務シナリオテストに関する教訓

2026年10月27日確認。本文中の記入例・チェック項目は、業務を検討するために作成した例です。