受入テストと検収の進め方

受入テストは、プロジェクトの最後にある工程です。しかしここでもめるかどうかは、ほぼ設計段階で決まっています。

「業務で問題なく使えること」としか決めずに進むと、終盤に「これでは使えない」と言われ、誰も終わらせられなくなります。

■ テスト工程ごとの役割を整理する

まず、受入テストが何を見る工程なのかをはっきりさせます。

ここで重要なのは、受入テストだけ判断の基準が違うことです。他の工程は「文書どおりか」ですが、受入テストは「業務が回るか」です。

だからこそ、何をもって「回る」とするかを先に決める必要があります。

■ 合格基準は、設計段階で数と条件で書く

「正しく動くこと」では基準になりません。次のように書きます。

この作業を要件定義と同時にやります。テスト計画のときに考え始めると、もう遅いことが多いです。

■ 業務側の体制を2か月前に押さえる

受入テストで最も多い遅れの原因は、技術的な問題ではありません。業務側の担当者が集まらないことです。

次の3点を、遅くとも2か月前に確定させます。

• 誰がテストするか（部署名ではなく個人名で）

• 何日間・1日何時間使えるか

• その期間が、相手の部署の繁忙期と重なっていないか

月末月初、決算期、繁忙シーズン。ここに受入テストを置くと、人が来ません。相手の業務カレンダーを先に聞いておきます。

■ 不具合か変更かを、先に決めておく

受入テスト中の対立は、たいていここで起きます。

この表をテスト開始前に配って、「判定はこのルールでやります」と合意しておきます。テストが始まってから決めようとすると、感情的な話になります。

■ 毎日、件数で見る

受入テスト中は、日次で次の数字を共有します。

とくに「判定待ち」の件数に注意します。ここが増えているときは、判断できる人が会議に出ていないサインです。

■ 検収は、残件の扱いを書いてから

全件が完璧に終わってから検収、ということはほとんどありません。だからこそ、残件をどう扱うかを書面にします。

• 残っている件数と、その内容

• いつまでに、誰が直すか

• 直すまでの間、業務をどう回すか

• 費用が発生するものはどれか

ここを口頭で済ませると、数か月後に「あれはやってもらえると思っていた」という話になります。検収書と一緒に、残件一覧を添えるのが確実です。

■ 発注者側PMの場合

立場が逆の場合、やるべきことは次のとおりです。

• テストする人を、早い段階で名指しで確保する

• 合格基準を、業務の言葉で具体的に出す

• 現行業務の実データ（件数・パターン）を提供する

• 不具合の報告は、再現手順と画面を添えて出す

「とりあえず触ってみて、おかしければ言う」というやり方では、テストになりません。何を確認するかのリストを、こちらから出します。

■ まとめ

受入テストがもめるのは、テストのやり方が悪いからではなく、合格基準が決まっていないからです。

いま進行中の案件で、受入テストの合格基準が数と条件で書かれているかを確認してみてください。書かれていなければ、いまが決めどきです。