システム構築プロジェクトにおいて、発注者側の作業と位置付けられているのが「要件定義」と「受け入れテスト(ユーザーテストとも呼ぶ)」である。もちろんプロジェクトの性質や契約内容によって異なる場合もあるが、たいていの場合、この二つは発注者責任で行う作業となる。

 この二つは、いわゆる「開発V字モデル」でも対になっている。要件定義と受け入れテストはどちらも業務目線で行うべき作業。新たなシステムの導入によって業務がどう変わるのか、あるいはどのように変えたいのかを最終的に評価できるのはユーザーだけなので、発注者の責任となるわけだ。

 このうち要件定義の「丸投げ」の弊害は以前に触れているので、今回は受け入れテストに関して論じたい。

遅延の影響を受けやすい

 受け入れテストは多くのプロジェクトで最終フェーズとされる。だから、スケジュール遅延の影響を受けやすい。当初計画ではきちんと独立した作業として3カ月行うはずが、実際にはベンダーテストのバグ対応や急きょ追加した機能の開発などとごっちゃになりながら1カ月でやるしかない、といった場合も少なくない。

 理想的には、受け入れテストのシナリオ作成は要件定義と同時期にやるのが良いとされている。だが、要件定義そのもので四苦八苦しているプロジェクトでそれは無理である。受け入れテストの開始時期にバタバタとシナリオ作成を始めることになり、それで時間を使ってしまう。

 厄介なのは、ユーザーがテストそのものを甘く見ている場合だ。「画面に入力できるか」「入力後、正しい処理や計算がされるか」「画面が見やすく分かりやすいか」ということを確認すればよいと考えているユーザーは少なくない。それだけでは機能の確認であって、業務がきちんと回るかどうかの確認にはならない。

 テストを甘く考えていると、テストデータも簡略なもので済ませてしまう。テストの目的から見れば限りなく本番に近いデータで行うべきである。

 ベンダーに受け入れテストを「丸投げ」することは非常に危険だ。ベンダーは基本的に機能の確認テストはできても、業務視点でのテストはできない。より正確に言うならば、テストという作業は代行できても、その結果が業務として正しいかどうかは判断できない。ベンダーにはテスト作業支援を委託してもよいが、最終判断だけはユーザーがしなければならない。

 契約面でも受け入れテストは重要である。いわゆる「検収」の対象として最も重要なのはプログラムそのものの品質である。甘いテストを基に安易に検収すると、あとあと大変なことになる。テスト期間中に見つかった不具合であれば、ベンダーも対応しやすい。だが、検収後となると「瑕疵担保責任」の対象か否かという論点になるので簡単には対応できない。これは発注者だけでなく、ベンダーにとっても厄介なことなのだ。

 発注側は、受け入れテストの主体者が自分たちなのだという当たり前のことを再認識しよう。そして、きちんと準備と計画をしてほしい。