情報システムの発注方法(2ページ目)

将来の保守作業のため、納品物にソースコードを入れておく

将来の保守作業のために、納品物にソースコードを入れておく

ITベンダーから最終的に納入してもらうドキュメント類などを一覧の形で明示します。あわせて開発したプログラムのソースコードをCD-ROM等の形で納入してもらいます。プログラムのソースコードを発注側が受け取っても、中身がわかるものではありませんが、保守・運用時の保険になります。ITベンダーにとり手間がかかるものではないので、見積に変更はありません。

システム開発が終わると、長いシステム運用が始まります。その間に現場のニーズが変わったり、法改正などでシステムのアップグレードが必要となります。現在のような経済情勢では、開発を委託したITベンダーがずっと存在するとは限りません。倒産だけではなく、M&AなどでITベンダーの経営方針が変わり、システム構築がサービスの対象外になったりすることもあります。つまり、アップグレードや保守に対応してもらえなくなります。

別のITベンダーにシステム変更をお願いしても、元々のソースコードがなければ、どこを修正すればよいか皆目検討がつきません。最悪のケースでは、システムを作り直す再構築になってしまいます。そこで、ソースコードを納入物に入れておきます。バグの修正等でソースコードが変更された時は修正し、常に最新版ソースコードが手元にあるようにします。

検収が終わると、システムに関する責任が発注側に移行する

発注側が検収合格書を出せば、システムに関する責任はITベンダーから発注側の中小企業に移行します

納期と検収について契約で取り決めます。検収という作業は、ITベンダーへ開発委託したシステムが発注した仕様通りであったかどうか発注側が確認する作業です。検査仕様書に基づき検査し、システム仕様書通りにシステムが動いているかどうかを確認。例えば、物を仕入れた場合、取引先から納入された物が数量通りか、頼んだものと同じか検品という作業で確認するのと同じです。

システムの検収テストを実施した経験のある中小企業は少なく、検査仕様書をどう作ればよいかとまどうような場合は、ITベンダーによる支援内容をあらかじめ盛り込んでおきます。

検収がITベンダーと発注側の責任分界点になります。発注側が検収合格書を出せば、システムに関する責任はITベンダーから発注側の中小企業に移行します。それもあって中には検収にずるずる時間をかける中小企業がありますが、結局は最終の運用開始の時期がずれたり、あとあと追加修正が出たりする遠因となります。

お互いの役割分担が明確になるように契約に記載しておきます。品質が悪く、検収合格書を出せない場合の取扱についても取り決めをしておきます。検収が終わってから見つかったバグについては、瑕疵担保責任期間を定めて無償で修正してもらうよう記載しておきます。