システムの検収

システムの検収はどのように進めるべきでしょうか。

情報システムの発注において、発注者側の情報システムに対する知識が不十分になりやすい傾向にあると言われます。発注者側の情報システム担当部で要件定義書を作成するという事も少なくなり、要件定義書の作成からをSIerに依頼するというパターンが一般化しています。

情報システムのライフサイクルの中で、要件定義、開発、テスト、リリース、保守運用は一括してお任せする事ができるのですが、テストからリリースの間には「検収」という作業があります。

検収は発注した通りの情報システムができているかどうかを発注者側が確認する作業ですので、少なくとも供給者たるSIerに検収を頼む意味はありません。自分で作ったものを自分で検査するという事はなかなかやりづらいものがあるでしょう。

となると、発注者が自分でやるということになるのですが、情報システムはますます複雑化している上、発注者側の情報システム部門が力不足になっていると難しいところです。検収計画を作らず、何をもって検収合格とするかを明確にしないままで2，3日適当に操作をしてみてバグが出なければOK、というように検収作業が形骸化してしまうこともあるかもしれません。

本格的に検収をやるとなれば、納入されたソースコードやらプログラム仕様書やらテスト結果を紐解いて、コーディング規約が守られていないですとか、テスト件数が足りないですとか、そういった指摘をすることになります。しかしながら発注者側にそういったことができる人材がいることは珍しいでしょう。

となるとどういった人に頼むかということになりますが、システム監査技術者の試験ではリリース前のシステムが適切に作られているかどうか監査を行うというような問題が多数ありました。確かにシステム監査を専門とする人ならば各種のテスト技法にも詳しいですし、初見のシステムを素早く把握することにも慣れていますし、システムの効率性、信頼性、安全性を確認する能力に長けています。

これからますます情報システムが大規模化、複雑化していくにあたり、システム監査人が負う役割、担当する業務も増えていくのではないかと思います。監査というと内部統制が注目されていますが、他にも色々なビジネスチャンスが転がっていそうですね。

（参考）

＠IT情報マネジメント：納品されたシステムに対する効果的な検収方法
http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/09/01.html