システムの納品が近づくと、作った会社から、検収書に判を押して返すよう求められます（発注側が自社で検収書を作って出す形の会社もあります）。判を押すと、発注した内容を受け取ったという意味になり、契約によっては、そこから支払いの手続きへ進みます。判を押した後に見つかった不具合をどう扱うかは契約の内容によります。ただ、受け取る前に試す機会は、そこで終わります。
判を押す前に発注側がやる確認を、受け入れテストと呼びます。作った会社も出荷前に試験をしていますが、それは仕様書に書いたとおりに動くかを見るものです。自社の仕事がそのシステムで本当に回るかは、仕事を知っている側でないと分かりません。ここでは、その試し方を順番に書いていきます。
作った側の試験とのちがい
作る側は、仕様書の1行ずつに対して「この操作をしたら、こう動く」を試します。ボタンを押したら保存される、金額を入れたら税込みの額が出る、といった試し方で、仕様書の行の数だけ試験が並びます。仕様書に書いてあることは、たいてい正しく動きます。
発注側が見つけるのは、仕様書に書いていなかったことです。書き忘れた例外、担当者が当たり前にやっている手順、月末だけの作業。これは作る側の試験では出てきにくいものです。だから受け入れテストは、仕様書を見ながらやるより、今の仕事を思い浮かべながらやる方が見つかります。
試す場所と期間
受け入れテストは、本番とは別の試験用の環境で行うのが普通です。試験用の環境なら、間違った注文を入れても、請求書を何枚出しても、実際のお客様には届きません。逆に言えば、試験用の環境から本当にメールや通知が送られないかは、最初に作る側へ聞いておいてください。
期間は、契約や発注の段階で決まっていることがあります。「納品から○日以内に検収」のような書き方です。現場の担当者は普段の仕事をしながら試すことになるので、その日数で本当に回るかを、テストの予定を組む前に見ておきます。足りなければ、始める前に相談します。終わりかけてから延ばしてほしいと言うより、ずっと話が通りやすいです。
実際の1日を流してみる
最初にやるのは、普段の1日の仕事を最初から最後まで流すことです。朝に届いた注文を入れ、昼に内容を見直し、夕方に出荷や請求の準備をして、1日を締める。その流れを、普段その仕事をしている担当者に、普段の順番で操作してもらいます。
ここは順番が大事です。作る側が用意した手順書どおりに操作すると、手順書を書いた人の想定どおりに動くのは当然です。担当者が自分のやり方で操作して、途中で「あれ、次はどこだろう」と止まった場所。そこが、画面の流れと仕事の流れがずれている場所です。
使うデータは、先月の実際の仕事から1日分を選ぶと現実に近くなります。お客様の名前や電話番号は仮のものに置き換えます。件数が多い日と少ない日の2日分があれば、画面の表示が件数に耐えられるかも見えてきます。
例外のケースを1つずつ
次は例外です。例外は普段の仕事の中では頻度が低いので、意識して試さないと納品後まで出てきません。業種によって違いますが、たとえば次のようなものです。
- 注文の取り消しと、一部だけの取り消し
- 登録した後に数量や日付が変わった場合
- 締めた後、請求書を出した後に間違いが見つかった場合
- 月末と月初、年度の替わり目、休業日をまたぐ予定
- 同じ名前のお客様、とても長い住所、全角と半角が混ざった入力
締めた後の修正は念入りに。修正できないと困りますし、誰でも自由に修正できてしまっても困ります。誰が、どういう手順で直せば、どこに記録が残るのか。今の Excel や紙ではどうしていたかと比べながら試します。
権限と、辞めた人のアカウント
業務システムには、役割ごとに見える範囲やできることを分ける仕組み（権限）があることが多いです。受け入れテストでは、役割ごとの試験用のアカウントを作る側に用意してもらい、1つずつログインしてみます。
パートの担当者の画面に、原価や他の社員の給与が見えていないか。閲覧だけのはずの人が、削除のボタンを押せてしまわないか。管理者だけが見るはずの一覧も試します。管理者でログインした時に、その一覧の画面のアドレス（URL）を控えておき、パートのアカウントでログインし直してから、控えたアドレスを開いてみます。開けてしまったら不具合です。管理者のアカウントで試しているうちは、この手のずれには気づけません。
辞めた人の扱いも見ておきます。アカウントを止めた後、その人が登録した注文や記録は残っているか。担当者の欄はどう表示されるか。止めた人のアカウントで本当にログインできなくなるか。システムの側で止め方が決まっていないと、退職の時にアカウントを止める手続きそのものが進められません。
データの出し入れ
新しいシステムは、たいてい外とデータをやり取りします。Excel で持っていた顧客の一覧を取り込む。月末に売上を会計ソフトへ渡す。取引先へ CSV のファイルで送る。
この出し入れは、実際のファイルで試します。取り込みでは、電話番号や郵便番号の先頭の0が消えていないか、日付が別の形に化けていないか、住所の途中で途切れていないかを見ます。出力では、できたファイルを受け取る側のソフトに実際に読ませてみます。会計ソフトが受け付けなければ、月末に手で直すことになります。
誰が試して、誰が合格を出すか
最後に、人の割り当てです。試す人と、合格を出す人は分けます。
試すのは、その仕事を毎日している現場の担当者です。合格を出すのは、費用と納期に責任を持つ社長や部門の責任者です。現場の担当者が1人で合格まで決めると、忙しさに押されて「まあ使えるか」で通してしまうことがあります。逆に責任者だけで試すと、現場の手順を知らないので、ずれに気づけません。
見つかった点は記録に残します。形は簡単でかまいません。番号、どの役割のアカウントで、どの端末で、どの画面で、何をしたら、どうなったか、本当はどうなってほしいか。画面の写真を1枚付けます。それぞれに、業務が止まるほどの不具合か、回避できる不具合か、約束の範囲外の要望か、を書き分けておくと、作る側とのやり取りが早くなります。
合格の基準も、テストを始める前に決めておきます。たとえば「業務が止まる不具合が0件で、回避できる不具合は直す日付が決まっていること」のように、何がそろえば判を押すのかを先に言葉にします。後から決めると、見つかった件数を見ながら基準を動かしたくなるのが人情で、そうなると判を押す理由が「もう時間がないから」になってしまいます。
直った後にもう一度通す
不具合を伝えると、作る側から「直しました」と連絡が来ます。直った箇所だけ見て終わり、にはしません。
1か所を直すと、同じ部品を使っている別の画面の動きが変わることがあります。請求の計算を直したら、見積もりの画面の合計も変わっていた、というようなことです。直った版が届いたら、指摘した箇所を見た後に、最初にやった1日の流れをもう一度だけ通します。2回目は慣れているので、1回目よりずっと早く終わります。
記録の表には、試し直した日と、誰が試したかを書き足します。直ったかどうかを口頭のやり取りだけで済ませると、半年後に同じ症状が出た時、直したはずなのか、最初から直っていなかったのかが分からなくなります。
検収書は、始める前に決めた基準を満たした時に押します。回避できる不具合が残っているなら、その一覧と直す日付を検収の記録に添えておきます。
判を押した後に見つかるものも、もちろんあります。それは使いながら直していくことになります。その時の頼み方と費用の扱いを保守の契約で先に決めておけば、慌てずに済みます。
