IT化プロセス、4．受け入れテスト

IT資源の発注を行ったら、次は受け入れです。

受け入れには準備と実施の二つがあります。

準備は具体的にはテスト準備となります。発注者側としては、環境準備があります。受け入れするには、自分が発注したものがその通りになっているか確認する必要があります。システムで言えば、テスト完了で、納品してもらったものをテストするという事になります。発注者である人はテスト環境を準備します。具体的には、本番環境のバックアップを使って、テスト環境を準備する事になるでしょう。クラウドシステムであれば、テスト環境を簡単に準備してくれる仕組みを持っているものもあります。

もう一つ納品前に準備するものがあります。テスト計画書です。テスト計画書が無い場合、テストを始めると、その場で思いついたものだけをテストして終わりになる事が多いです。要は網羅的にテストをしないのです。その場合、後から、重大な不具合に気づく事があります。テスト前にテスト計画を作れば、網羅的にテスト計画を作る事が出来ます。一度テスト計画を作れば、あとはそれに従って、テストを行うだけです。

受け入れテストで重要な事は、最終的な利益受益者にテストを行ってもらう事です。需要者が自分なら自分でテストすれば良いです。需要者が自分以外の人ならば、その人にテスト計画を作ってもらい、実際にその人の責任でテストを行って貰う必要があります。

テストを行って貰ったら、その対応を行います。具体的には以下の種別のものがあるでしょう。

・不具合

・要望

・運用条件の明確化

・質問

不具合は取り扱いに注意が必要です。ユーザーは不具合と言ってくるものは、二つに分類します。依頼した通りに出来ていない場合のものは純粋に不具合として認識して良いでしょう。発注先に不具合として内容を伝えて、修正してもらえば良いでしょう。もう一つはユーザーにとって不都合なもの、これもユーザーは不具合として挙げてきます。要はユーザーの業務遂行にとって、ユーザー自身が（要件定義として明示的に示していなかったものも含め）、思った通りスムーズに業務が出来ないと、彼らはそれを不具合として、挙げてきます。これは発注先にとっては不具合ではありません。ユーザー側の不都合です。これをどうするかは、IT責任者の調整能力によって解決します。例えば、不具合が多ければ、これは要望だけど、無償で対応してもらう。逆に不具合も少なければ、有償での追加要望対応になるので、この事をユーザーに分かりやすく伝え、有償になる可能性がある事を伝えて、発注先に無償で対応してもらえるか、交渉しているみるという姿勢を伝える事にしましょう。