検収

　納入品が要求仕様に合っているかの検査のこと。システム開発においては、納品されたシステムの動作を検証し、仕様を満たしているかどうかを判定する作業を指す。検収が済むと、受注者に費用を支払うことになる。現在、システムを内部だけで開発しているユーザー企業はほとんどない。開発の全部または一部を外部に委託するのが一般的だ。元請けベンダーが下請けに開発を再委託することも多い。外部企業との契約機会が増えるにつれて、検収の重要性はますます高くなっている。

　検収は受注者から発注者へ責任が移る分岐点である。検収後に瑕疵（かし）による問題が発覚した場合、あらかじめ定めておいた保証期間内なら、ベンダーが修正作業を行うという契約が多いが、その期間が過ぎれば追加費用を支払わなければならない。発注者は、念入りにシステムの品質や機能をチェックする必要がある。

　そのためには、発注者が落ち着いて検収を実施できる環境を整えることが重要だ。具体的にはあらかじめ契約などに、検収について定めた条項を盛り込んでおく。

　情報サービス産業協会（JISA）が、2002年5月に改訂したソフト請負開発に関する契約書のひな型である「ソフトウェア開発委託モデル契約書」にも、検収について触れた部分がある。モデル契約書では、あらかじめ必要な検収期間を定めておいて、受け入れ側がこの期間内に書面で異議を申し立てることを規定している。検収期間内に受け入れ側からの申し立てがなければ、検査に合格するという条項が入っている。

　それでも、検収が引き金となってトラブルが発生するケースは多い。背景には、発注者とベンダー双方の、「検収はとりあえず済ませておいて、何かあれば後で修正すればよい」と考えてしまいがちな現実がある。ユーザーは、面倒なテストなどの作業を回避できるし、ベンダーはシステム開発案件の売り上げを早く計上することができるため、短期的には双方にとってメリットがある。どんなに入念にテストを行っても、不具合を撲滅することが難しいというシステム開発特有の性質が、この傾向に拍車をかける。

　だが、こうした姿勢は、発注者と受注者双方にとって望ましくない。後回しにした問題の中に、修正に大きな労力を要するものが発見された場合、両者の間で責任の所在についてトラブルが発生しかねないからだ。

　本来は、システムの不具合の原因がプログラムの瑕疵にあれば受注者の負担で、仕様が不十分といった理由であれば、発注者の負担で修正すべきである。だが、不具合の原因がどちらなのかを特定するのは、容易な作業ではない。そのため受注者が、不具合が瑕疵に属する可能性があっても仕様の問題と主張し、修正作業に応じない場合がある。一方で発注者による仕様変更であっても、力関係を背景に瑕疵として受注者に契約範囲外の作業を強いる構図も存在する。