全社システムの再構築をテーマとし、現状分析、システム企画支援、提案依頼書（RFP）作成支援、ベンダー選定支援、開発工程におけるプロジェクトマネジメント支援など、システム開発の全工程をお手伝いさせていただいているユーザ企業のお話です。
ベンダーによるシステム開発も終盤に近づき、本格的なシステムの受入検収が始まりました。
システム規模が大きいことから、検収をより効率的に行うために、3段階方式で検収をすることにしました。
既に、第一段階と第二段階を実施。
しかし、部分的に開発が遅れている業務機能があり、第三段階として定義した総合検収へ進めずヤキモキする状況に。
併せて、当初の予定では既に運用を開始しているはずの業務 （市販パッケージの利用） に関しても、ベンダーがパッケージメーカとの調整に手間取ってしまった結果、導入が遅れてしまい、検収で右往左往している状況下で並行してパッケージ導入・環境設計・運用教育をする羽目になってしまったのです。
とは言え、ユーザ企業側の受入検収が遅延の原因と言わせないためにも、ユーザ企業側ではシャカリキになって検収を進めてます。
さて、ここで一考。
的を外さず、検収作業をより効率的に進めるためには・・・
悩んだ挙句、出た結論は、第三段階（総合検収）の更なる段階分け。
第一段階と第二段階は独立した業務単位での検収、と位置づけして実施してきました。
第三段階（総合検収）は全ての業務機能単位での検収が終わってから、との位置づけを変更することにしたのです。
まずは、独立した業務内における各機能の情報連携を確認することに。
次に、業務間における各機能の情報連携を確認することに。
この様に細分化したのは、幸いな事に、開発が遅れている部分は業務内／業務間の情報連携を阻害する箇所ではなく、バッチ処理として最終的に各種情報を集約する部分だったからです。
つまり、最終的な集計処理などの確認は後回しにして、システム全体を通し、データが業務シナリオに基づいて正しく流れるかを確認する 『スルーテスト』 を行うことにしたのです。
とは言っても、これはあくまでも暫定的な措置であり、本来の検収とはかけ離れていると思います。
しかし、この暫定的な措置を行うことで、
◇ユーザ企業の担当者は、自分の行う仕事が他の人の仕事とどの様に関連しあっているのかを認識できる（全体の把握）
◇本来の総合検収を行う際に 『予行演習』 をしているので、効率的に総合検収が進められる
◇システムが本稼動した際、何をすれば 『システムが正しく動いている』 のかを確認できる術も備わる
など、本来習得に時間が掛かることを効率よく進められそうです。
システム開発の現場では、常に何らかの問題をはらんでいるものです。
その時その時の対処、対策を間違えると取り返しのつかない事態へと発展する事があります。
反面、対策の立て方で、マイナスをプラスに転じる事も出来ます。
不測の事態への対処。プロジェクトマネージャーに求められる重要な能力の一つではないでしょうか。
