ユーザーはどのタイミングでテスト工程へ参画すべきか？
システム開発において、どのタイミングで、ユーザーにテスト工程へ参画してもらうかの判断が、難しいことあります。
システムテスト（総合テスト）の最終段階でユーザーが参画した場合、プロジェクトがひっくり返されるような問題（要件モレなど）が発生することがあります。
そうならないように、密に連携をとりながらユーザーを巻き込んでテストに取り組みたいところです。
そこで、ユーザーがテストに参画するタイミングについて、ケースを上げながら、みていきたいと思います。
しかし、管理人はベンダー側の人間です。偏った視点になっていた場合はご容赦ください。
管理人が考えるテストの進め方
管理人は、「早い段階からユーザーの参画を求める」のがベストと考えています。
理由は、機能要件のユーザー確認を少しでも早く進めるためです。制約はあるのですが、できる限り早く確認してもらえるよう尽力します。
そうすることで、手戻りを幾分でも少なく、被害が少ない状態にできると考えています。
早い段階とはいつを指すのか？ とお考えでしょう。管理人は、結合テストの段階を想定しています。
管理人が理想とするテストの流れ
管理人が「こう進められるとプロジェクトがうまくいくのだが」と感じている観点です。実際には、さまざまな制約があるので、机上の空論かもしれません。
なお、テスト作業の細かい内容は記載しません。あくまでも概要・イメージと考えてください。
テストへの参加者
実際にテストを行う可能性がある人たち（ステークホルダー）は、次のとおりに分けられます。（ベンダーとは、元受会社と協力会社をまとめたものを指します）
ベンダー側の参加者
- 開発者（プログラムの開発を行います）
- 設計者（機能設計を行います）
- 品質保証チーム（第三者的な観点で品質を確認するチーム、いない場合もあります）
- プロジェクトマネージャ（最終的な責任を負います、以降PMとします）
ユーザー側の参加者
- システム部門（ベンダーとシステム構築を担当します）
- 利用部門キーマン（要件定義、外部設計などで利用部門代表で参画していたメンバーです）
- 利用部門（エンドユーザーに該当します、システムの中心的な利用者です）
- 役員など役職者（システムの最終決定権を持つ人たちです）
単体テスト
「ベンダー側開発者」が中心に実施します。開発中でも、抜き打ちで「ベンダー側設計者」と「ベンダー側PM」がサンプリングチェックしてください。
同様に、成果物の受け入れ時には、さらに厳しいチェックが必要です。そうでないと、単体品質が担保できないまま結合テスト突入ということになりなません。
必ず、設計者の観点で、単体レベルの品質チェックを行ってください。品質が悪ければ容赦なく突き返すくらいの気構えが必要です。
そうでないと、後工程になって、災いが設計者の身に降りかかってきます。恐ろしいことです。
結合テスト
早いタイミングですが、ベンダー側の結合テストが完了した段階で、ユーザー側に参画してもらいます。
リソースと期間があればという前提ですが、3フェーズに分けると、機能要件に関する障害は出尽くせるのでは？ と感じています。
実際は、管理人がマネジメントしたプロジェクトでも、ベンダー側テストとユーザー側テストの2フェーズに分けて実施することが限界でした。
結合テスト（第1フェーズ）
「ベンダー側設計者」が中心となりテストします。単体レベルのバグはすべてつぶしてください。また、開発対象すべての機能を結合させて機能要件の確認をします。”すべて”というところが重要です。
漏れがあってはダメです。ベンダーとしての品質を担保することを心がけます。すべての機能要件がもれなく実装されていることを確認してください。
品質保証チームに参画してもらうのもこのタイミングです。ユーザー側に公開する前に第三者的な観点で障害をつぶしておくためです。
ユーザー公開後に障害や要件モレが発生すると面倒です。特に単体レベルの障害が発生すると信用がなくなりますので注意が必要です。
結合テスト（第2フェーズ）
「結合テスト（第１フェーズ）」で、ベンダー側の品質を担保したあとは、「ユーザー側システム部門」が参画してテストを行います。
ユーザー側システム部門の観点で機能要件の検証を行います。利用部門に開放しても問題ないかの確認です。利用部門に開放した後に障害が発生すると面倒です。
この段階で、ベンダー側とユーザー側システム部門は、機能要件に関して「同じ方向を向いている（双方認識してに相違がない）状態であること」が理想です。
結合テスト（第3フェーズ）
「ユーザー側利用部門キーマン」が参画します。「結合テスト（第2フェーズ）」で、ベンダー側とユーザー側システム部門は、機能要件に関しては握っていることが前提です。
ユーザー側利用部門キーマンと、ユーザー側システム部門で握られるとベンダは窮地に陥る場合があります。
できれば、この段階で、システムテストでのユーザー側利用部門テスト時に使用する機能マニュアルを作成してもらうとよいでしょう。
状況に応じて、「ユーザー側役員などの役職者」にも、一部の機能（目玉機能など）を確認してもらいます。ここでも、ベンダー側とユーザー側システム部門が、「機能要件に関して握っている状態であること」が前提です。
システムテスト（総合テスト）
システムテストは、「システム寄りのフェーズ」と「利用部門が検証するフェーズ」の2つに分けてテストしたいところです。
システム寄りのフェーズで非機能要件をつぶしきらないと、利用部門テスト時にレスポンス問題などが発覚してしまい、対応に追われてしまいます。また、移行データがある場合は、この段階で投入してテストを行います。
システムテスト（第1フェーズ）
ユーザー側システム部門とベンダー側が中心となり、実機を用いて、主要な業務運用の検証、非機能要件の検証を行います。
性能などに支障がない段階になれば、「ユーザー側利用部門キーマン」が参画してもよいかもしれません。
システムテスト（第2フェーズ）
「ユーザー側利用部門キーマン」を中心として、「ユーザー側利用部門」に参画してもらいます。ユーザー側利用部門キーマンが、一般利用者に対しての操作指導をします。システムの教育期間と考えてください。
それと並行して、実運用のサイクルテスト（月次運用など）や、限定した条件での二重入力を行い、データの整合性などを確認します。
運用テスト
運用テストは、また違った観点が必要なので、今回は除外します。
まとめ
ユーザー側がテストに参画するタイミングは、非常に悩ましいところです。
PMとしては、計画段階でユーザー側が参画するタイミングを決定しており、ユーザーとの合意もとっています。
しかし、品質や進捗具合が思わしくない場合、次第に参画するタイミングを遅らせようとしたりします。先延ばしとも言えます。
それではよい結果を生むことは難しいでしょう。
早めに機能検証をしてもらうこと、すなわち結合テストの段階で参画してもうことで、バグ出しや要件・仕様漏れを洗い出しておいたほうが、あとあと楽になることは間違いありません。
問題は早めにつぶすこと、いや、問題を早めにあぶり出す勇気が、プロジェクト成功への第一歩です。