システム開発における納品物についてですが、決まりごとはないと言っても過言ではありません。
つまり、納品物はユーザ企業とベンダー企業との話し合いによって決るということです。
極端な例ですが、あるユーザ企業のシステム更改プロジェクトに関与した際、既存システムの設計書が全くないという由々しき事態に遭遇した事もあります。
理由を尋ねたら、システム開発費用のダウンをベンダーに申し入れたら、ベンダーからは費用をダウンさせるために設計書を作らないと回答され、両社合意の上で設計者が納品物とならなかったのです。
ユーザとしては、システム本体が納品され、そして目的どおりにシステムが稼動さえすれば良いと考えたようです。
つまり 『 納品物 = システム本体 』 との意識が強く働いたようです。
数年後のシステム更改プロジェクトへ影響するとは思わずに。
さて、システム更改プロジェクトのスタートです。
私の関与はここから始まるのですが、まずは現状分析をするために現行システムの仕様を確認し始めたとき、前述の事態に遭遇したわけです。
結局、現行システムに関する資料が何もないところから、システム全面更改プロジェクトがスタートしたのです。
当時の担当者もうろ覚えな事もあり、現状調査・分析にかなりの時間を投下する事になったのです。
幸い、業務改善を伴うシステムの全面更改ということもあり影響は少なくすみましたが、これが現行システムの改善プロジェクトだったらと思うと、ゾッとします。
ベンダーに当時の担当者が居ればまだしも、もし居なかったら・・・
私が関与しているプロジェクトでは、提案依頼書(RFP)の中であらかじめ納品物を指定し、提案段階からベンダーと納品物に関する調整を行います。
また、選定したベンダーと契約を交わす際、契約書に納品物を明記し、更に検収条件にも組み込んでいただきます。
そうする事で、未納品物件がある場合は検収完了とならないため、ベンダーも責任ある対応をしてくれます。
納品物は、システムの種類や著作権などの権利の帰属先によっても変わってきますが、一例として挙げてみます。
【納品物】 ※実際の提案依頼書(RFP)で記載した内容
◇ハードウェア、同操作説明書
◇システムソフトウェア、同仕様書
◇基本設計書、詳細設計書(データフォーマットを含む)
◇アプリケーションソフトウェア、同仕様書、同操作説明書
◇テスト計画書、テスト結果報告書
◇システム運用マニュアル
社内に資料類が揃っているかどうか、一度確認してみた方が良いと思います。