システム検収
プロジェクトも後半になると、ユーザ企業ではシステムの受入検収や運用テストやら、考えなくてはならない事が増えてきます。
実際に関与しているプロジェクトの一つが大詰めを向かえ、主だった議論が
◇業務移行について
◇システム検収について
◇運用テストについて
◇本稼動開始時期について
など、本稼動までにユーザ企業が行わなければならない事にスライドしてきました。
その中で、ユーザ企業としてわかり難いのが、システム検収（検収手順）についてのようです。
そもそもユーザ企業にとって 『システム検収』 とは何をすべきなのでしょうか。
簡単に言ってしまえば 『確かに要望した通りにシステムが出来上がっている』 事を確認し、承認する事です。
しかし、闇雲にシステムを動かしてみても、まんべんなくシステムの検収が行えるものではありません。
ですから まんべんなくシステムの検収を行うためにも 『何をどの様に確認するか』 という視点で 『検収手順』 を明確にすることはとても大切な事なのです。
ベンダーとしては、検収完了をもって売上に計上するなどの事情もありますから早めに検収を完了したいでしょうが、ユーザとしては安易に検収を完了してしまうと取り返しのつかない事になることがあります。
バグであれば契約上、瑕疵担保責任の条項が入っているでしょうから何とかなりそうですが、システムへの実装漏れがあっても検収を完了してしまっていては、漏れの取扱いついて揉め事になるのは必至です。
要求事項がシステムへ実装されていることを確認すると共に、正確にシステムが稼動する事を確認してから、検収完了とすべきなのです。
※但し、システム設計段階で漏れがない事を確認し、ユーザとベンダーでシステムの範囲とその実装機能について合意しているということが前提です。
それが 『システム検収』 というものです。
当たり前の事ですが、システム検収を行う前にベンダーによる各種テスト（単体テスト／結合テスト／総合テストなど）が実施され、システムが 『まともに動く』 状態になっていなければなりません。
そうでなければ、システム検収をやる意味がありません。（システム検収段階ではないという事です）
それでは、システム検収はどの様な手順で行うべきでしょうか。
闇雲にシステムを動かしても、システム全体をまんべんなく動かせるものでもありません。
システムは 『入力』 『処理』 『出力』 の3つの組み合わせで出来上がっているのです。
その組み合わせは、業務フローを意識して出来上がっているはずです。
と言う事は、業務の流れ（業務フロー）を意識して、システムを動かしてみる事が肝要ということになります。
そして、組み合わせの正確性を確認するために、
◇システム全体をまんべんなく動かすための 『データ』 を用意する
◇想定結果の通りに、システムが正しい結果を出すかどうかを確認する
事を意識した、業務の流れ（業務フロー）に順ずる検収シナリオを作る事が肝要ということになります。