あるお客様とのコンサルティング契約の再契約締結が完了しました。
ありがとうございました。
そのプロジェクトは、フェーズごとと言いますか、一定期間ごとといいますか、今までに経験がない方式で、２～３ヶ月ごとに契約を締結させて頂きます。
たいへん緊張感があり、良い経験をさせて頂いています。
さて、以下の話題は、別の顧客とのプロジェクトについてです。
いつの間にか、顧客にシステム受入テストを実施して頂く段階になりました。
今までいろいろ考えてきたのですが、私は、一定期間の運用テストと受入テストとを同じものとして捉える場合があります。
各種団体等による整理では、ソフトウェアの受入テストとシステムの総合運用テストを分けられています。
私もその意見に賛成です。
しかし、なかなか論理的に整理された内容で契約およびプロジェクト計画が立てられない、または計画どおりに進まないケースが発生します。
これらは言い訳なのですが、今回は、ある範囲までの「システム一式」として納品する方式であるため、システム一式の運用テストと受入判定テストを同じテストとして実施頂くことにしています。
繰り返しですが、それは本来は避ける方がよいと思っています。
ハードやミドルウェアの購入契約、ハードやミドルウェアの設置・設定工事、ソフトウェアの開発契約（フェーズ分けを含む）、システム導入・導入後支援（教育、移行、セットアップ、運用テスト支援、切り替え後支援など）という契約単位ごとに検収が発生すること、また、システム導入・導入後支援は準委任契約で実施すべきことなどは十分に承知し且つそのように対応したプロジェクトもあります。
しかし、今回は違います。
お客様で実運用（並行運用）をしていただきながら、受入検査を実施していただくことになります。
その際、合否判定のために、最低限として月末処理まで完了して頂いた上で、内容を検査して頂く必要があります。
しかし、月末処理まで完全な並行運用を実施いただけない場合（システム上の原因によるものを含む）があります。
その場合にどうするか？
まず、安易な妥協は混乱のもとになります。
よって、運用テスト時のお客様責任というものを、十分ご理解いただいておく必要があります。
ＲＡＭ（ＷＢＳに基づく役割分担表）を用いて、プロジェクト発足時から十分に説明しておく必要がありますし、定例会議においても、時期がきたら、その旨を十分に説明する必要があります。
それから、現実問題としては、可能な範囲で効率化する必要があります。
月初から完全並行を月途中まで実施し、日々のデータ整合性を確認、更に月途中で月末締処理を実施して月次の数値を確認する、という方法が考えられます。
既存システムで繰り返し締処理が実施できる場合や、多少の費用で既存ベンダーの支援を受けることができる場合などは、実施可能な選択肢です。
また、月途中までのデータを移行し（移行ソフトの利用かパンチ作業かを問わず）、それ以降、完全並行運用して頂いた上で、日々のデータ整合性を確認、更に月末後に締処理を実施し月次の数値を確認する、という方法も考えられます。
これも、十分に実施可能な選択肢です。
その他、それらのテスト範囲にしましても、全拠点ではなくパターン別に対象拠点を選んで実施すること等も効率的な方法として考えられます。
ただし、データ移行回数は間違いなく増えることになります。
繰り返し「言い訳」と思われるかもしれませんが、特に中小企業のシステム切り替えにつきましては、１００％完全な並行運用テストの実施が難しい場合が多々あると思っています。
それらについて、「お客様がテストを実施してくれない。。。」と嘆くのではなく、お客様と一緒に効率的・効果的な運用テストを計画し、その実施をご支援しようとする姿勢が必要だと感じています。
なお、その作業や工数は、予めＷＢＳ・ＲＡＭ・予算に見込んでおく必要があります。
以上、現実的なお客様側のシステム運用テスト（受入テスト）に関する、私の考え方を記載してみました。いろいろ反論等があるかもしれませんが、一つの意見としてご理解下さい。
＜関連記事＞
超上流工程からシステム運用テストまでにおける考慮事項
ソフトウェアの総合テスト
システム総合テストの重要性
ありがとうございました。
そのプロジェクトは、フェーズごとと言いますか、一定期間ごとといいますか、今までに経験がない方式で、２～３ヶ月ごとに契約を締結させて頂きます。
たいへん緊張感があり、良い経験をさせて頂いています。
さて、以下の話題は、別の顧客とのプロジェクトについてです。
いつの間にか、顧客にシステム受入テストを実施して頂く段階になりました。
今までいろいろ考えてきたのですが、私は、一定期間の運用テストと受入テストとを同じものとして捉える場合があります。
各種団体等による整理では、ソフトウェアの受入テストとシステムの総合運用テストを分けられています。
私もその意見に賛成です。
しかし、なかなか論理的に整理された内容で契約およびプロジェクト計画が立てられない、または計画どおりに進まないケースが発生します。
これらは言い訳なのですが、今回は、ある範囲までの「システム一式」として納品する方式であるため、システム一式の運用テストと受入判定テストを同じテストとして実施頂くことにしています。
繰り返しですが、それは本来は避ける方がよいと思っています。
ハードやミドルウェアの購入契約、ハードやミドルウェアの設置・設定工事、ソフトウェアの開発契約（フェーズ分けを含む）、システム導入・導入後支援（教育、移行、セットアップ、運用テスト支援、切り替え後支援など）という契約単位ごとに検収が発生すること、また、システム導入・導入後支援は準委任契約で実施すべきことなどは十分に承知し且つそのように対応したプロジェクトもあります。
しかし、今回は違います。
お客様で実運用（並行運用）をしていただきながら、受入検査を実施していただくことになります。
その際、合否判定のために、最低限として月末処理まで完了して頂いた上で、内容を検査して頂く必要があります。
しかし、月末処理まで完全な並行運用を実施いただけない場合（システム上の原因によるものを含む）があります。
その場合にどうするか？
まず、安易な妥協は混乱のもとになります。
よって、運用テスト時のお客様責任というものを、十分ご理解いただいておく必要があります。
ＲＡＭ（ＷＢＳに基づく役割分担表）を用いて、プロジェクト発足時から十分に説明しておく必要がありますし、定例会議においても、時期がきたら、その旨を十分に説明する必要があります。
それから、現実問題としては、可能な範囲で効率化する必要があります。
月初から完全並行を月途中まで実施し、日々のデータ整合性を確認、更に月途中で月末締処理を実施して月次の数値を確認する、という方法が考えられます。
既存システムで繰り返し締処理が実施できる場合や、多少の費用で既存ベンダーの支援を受けることができる場合などは、実施可能な選択肢です。
また、月途中までのデータを移行し（移行ソフトの利用かパンチ作業かを問わず）、それ以降、完全並行運用して頂いた上で、日々のデータ整合性を確認、更に月末後に締処理を実施し月次の数値を確認する、という方法も考えられます。
これも、十分に実施可能な選択肢です。
その他、それらのテスト範囲にしましても、全拠点ではなくパターン別に対象拠点を選んで実施すること等も効率的な方法として考えられます。
ただし、データ移行回数は間違いなく増えることになります。
繰り返し「言い訳」と思われるかもしれませんが、特に中小企業のシステム切り替えにつきましては、１００％完全な並行運用テストの実施が難しい場合が多々あると思っています。
それらについて、「お客様がテストを実施してくれない。。。」と嘆くのではなく、お客様と一緒に効率的・効果的な運用テストを計画し、その実施をご支援しようとする姿勢が必要だと感じています。
なお、その作業や工数は、予めＷＢＳ・ＲＡＭ・予算に見込んでおく必要があります。
以上、現実的なお客様側のシステム運用テスト（受入テスト）に関する、私の考え方を記載してみました。いろいろ反論等があるかもしれませんが、一つの意見としてご理解下さい。
＜関連記事＞
超上流工程からシステム運用テストまでにおける考慮事項
ソフトウェアの総合テスト
システム総合テストの重要性