企業システム戦略

ドキュメントの検収におけるチェックポイントを説明する。ドキュメントは一つには、要件定義や要求仕様が、確実にプログラムに盛り込まれているか、その作業過程としての設計書や試験報告書。もう一つは、システムの運用・保守に必要な情報源として。

プログラムの保守性については、要求仕様書に明記しないのが普通である。ところが、後で自社で保守しようとしても、どこがどうなっているのか分からないようなプログラムを納品する業者も少なくない。検収での保守性に対するチェックポイントを説明する。

性能検査は要求仕様書に明記してあれば、それほど難しいものではない。想定した利用状況において、定められた目標値をクリアすれば可、目標値に達しなければ不可である。問題は、目標値をクリアしなかった場合に、どのように対処するかということだ。

機能検査におけるチェックポイント。要件定義書や要求仕様書に記載されている要求機能が、正しく実現されていることを一通り確認する。この時、先の述べたトレーサビリティが確保されていれば、漏れなく、素早く検査を実施することが出来る。

システムの出来具合と進捗状況を、適宜、報告を受けるのは、リスク管理の面から当然である。また、悪い知らせを早め々に聞き出して、先回りして対策を打つことも重要である。特に重要なポイントでは自らの目で確かめる３現主義（現場、現物、現実）が必要だ。

◆悪い知らせを聞く　人間誰しも悪い知らせは聞きたくないものだ。また、悪い知らせを持ってきた人間にあたったりする。しかし、それでは問題が発生しているのに、真の状況が隠され、「問題ありません。なんとかします。」という報告ばかりを受けることになる...

検収時点で全ての不具合を発見できる可能性が低いとなると、検収して支払いを完了した後に不具合が発生した場合の救済手段を用意しておかなければならない。これを、瑕疵期間と言い、民法では、一般に１年間を瑕疵期間として認めている。

納品後は、速やかに検収しなければならない。そして、検収条件を満足すれば支払いとなる。いつまでに、どんな条件で検収を完了するかを契約時点で取り決めておく。下請代金支払遅延等防止法に抵触しないよう注意が必要である。

契約後、仕事が始まるとすぐに問題になるのが仕様変更である。どんなに要件定義に時間を掛けても「業務」という形の無いものを、想定しなければならないのがシステム構築の難しいところである。契約において仕様変更は必ず発生するという前提で、十分に調整しておくことが必要である。

ソフトウェアの著作権は、通常、そのソフトウェアを作成したところが権利を所有する。そのため、契約書にて何も言及しなかった場合、納入されたソフトウェアを自社で勝手に書き換えることができなくなる。また、別の業者に、改修を依頼することもできなくなる。