9.2 クライアントが確認検証する範囲と受注側が確認検証する範囲
システムがからむWeb構築の動作検証/テストというと、クライアントにどのような動作検証までしてもらうのかという点が重要なポイントのひとつです。単体テストや結合テストあるいは非機能要件テストは受託先であるベンダー側で行うテストですが、総合テストは「受入テスト」としてクライアントにも実行してもらい、きちんと期待するシステムが実現されていることを確認してもらうという手順を踏むことがよくあります。
システムの開発委託契約の形態には「請負契約」というものがありますが、請負契約のプロセスとしては、契約で規定した金額を請求する前に、「検収」という手順があります。システムを納品した後にクライアント側が発注時に約束された開発要件を満たしていることを一定期間内に確認する手順です。クライアントが納品されたものが要件をすべて満たしていることを確認するのにもある程度の期間と手間をかけないと確認できるものではないという認識に沿った手順かと思いますが、受入テストはクライアントの検収作業ともとらえられると思います。
クライアントにどのような動作検証までしてもらうのか、受託側がどのような動作検証まで行うのか、その動作検証内容について注意が必要な状況としては、以下のような場合があります。
・業務がどのように遂行されるか十分にベンダー側がわかっていない場合
開発受託しているベンダー側が実際の業務がどのように遂行されているか、十分に把握できていない場合は、システムの仕様についてドキュメントにきちんと書き下して、その仕様を満たすシステムとなっていることを網羅的にテストを行うのがまずは間違いないのですが、クライアント側にも実際に想定される業務の通りに操作してもらい確認してもらうことが望ましいです。
・クライアントがシステムに詳しくなく設計結果をレビュー困難な場合
クライアントがシステムに詳しくない場合は、ベンダー側が業務について十分に把握してベンダー側で機能テストからシナリオテストまできちんと行うか、クライアント側にもテスト期間の早い段階からきちんと受入テストを行ってもらう必要があります。
上述の品質管理 / テストに関する考え方は、アジャイルな開発手法をとる場合にはすこし異なってきます。アジャイルな開発手法とは、開発の初期段階で要件/仕様をきちんと規定せずにまずは迅速に作成してみて、実際に動くものを関係者が操作した上で修正を加えていくという手法ですので、厳密なテスト計画と詳細な動作検証はあまり意味をなしません。逆の言い方をすると、きちんとした開発要件/仕様を規定できないような状況では、アジャイルな開発手法が適しているとも言えます。
ただし、アジャイルな開発を行っていて、要件や仕様として十分には詰められていない状態で開発を進めていたとしても、はっきりと仕様が規定されたところでも期待通りに動作しないところがいろいろ存在すると、単純に要件/仕様通りに動作できていないのか、修正リクエストなのかがわかりにくくなりますので、規定されている仕様は明確にするとともに、動作検証を行って期待通りに動作することを確認するプロセスは必要です。
・これまで要件/仕様として規定されていない部分の、追加での要件/仕様
・これまで規定していた要件/仕様が不適切であることが判明したための要件/仕様の変更
また、業務設計まで踏み込んでクライアントをサポートしている場合にはクライアントの領域に深く踏み込めば踏み込むほど、クライアント側には業務からシステムまで全体像を把握してきちんと管理できている担当者がいないことが多いので、受託しているベンダー側としては、形式的にドキュメント確認をしてもらったことでよしとするのではなく、きちんと現場で運用されるものができあがるために必要なテスト内容を考えて、クライアントと分担分けして動作検証を行うことを意識する必要があります。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。