システム開発

欠陥防止のポイントは、業者に任せ切りにせず、主体性を持って適宜、チェックを入れることと、第三者の専門家による検査を実施するということ。

欠陥と仕様変更は必ず発生する。欠陥の場合は、業者側に修繕義務や損害賠償責任が発生する。仕様変更の場合は、発注側に追加発注という費用負担が発生する。そこで、両者の過失を相殺するというのは、いかがだろう。

仕様書に書いていなくても、当然、機能として盛り込まれていなければならないと主張する根拠として、それが、常識的なものであるかどうかが争点となる場合もある。ところが、この常識というのが非常にあいまいであり、どこまでを常識というのかがはっきりしない。

検収で必ず争点となるのが、発注側が「欠陥」と主張するのに対し、業者側は、仕様に書いていなかったので「仕様変更」と反論されること。主張が通らなければ、是正の費用を負担することになるので、どちらも簡単には譲らない。問題の切り分けに対する考え方を説明する。

受入検査の結果、要求事項に対して正しく作業されていない点については「瑕疵」として、業者に是正を要求する。この場合の是正作業に要する費用は基本的にベンダの負担、すなわち無償となる。その為、業者としては、瑕疵であることを簡単には認めないことも少なくない。

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

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

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

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

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