第3回　仕様書の責任の所在を明確化
提案書に法的拘束力はない

2007.07.06

システム開発において、仕様書の不備や欠陥がトラブルの大きな要因になる。受注者と発注者との合意のもとに、詳細で正確な仕様書を作成することが不可欠だ。また、仕様書の作成責任は誰にあるのか明確にする必要もある。無償の仕様書作成はトラブルのリスクを高める。仕様書作成を独立した有償契約とすることが望ましい。

　システム開発における仕様書とは、（1）開発されるシステムの目的（そのプログラムによって処理される適用業務の種類、内容、目的）、（2）その目的を達成するために、開発するプログラムが保持しなければならない機能を記述した要件定義書、（3）要件定義書を開発担当SEが理解し、作業できるように具体化した設計書──などを含んだ文書の総体をいう。

　設計書には、各機能を技術的に定義する内部設計と、その内部設計を外部に表示するための外部設計が含まれる。いわば、建物建築における建物の平面図、立体図、構造計算、完成建物のイメージ図などに対応するものである。

　システム開発の成功には、適切に作成された仕様書が不可欠である。仕様書の内容が明確で、詳細かつ正確に作成されていなければ、開発するシステムが、求められる要件を十分に満たすことは難しい。ところが開発の現場では、この仕様書が案外軽視されているケースが多い。その結果、ユーザー企業とソリューションプロバイダ間のシステム開発のトラブルに発展することが少なくないのだ。

　例えば、システム開発を数多くこなしてきたSEの中には、仕様書を面倒臭いと作りたがらず、開発業務の生産性を低下させるものと考えている者さえいる。経験したプログラムの仕様を自分の頭の中に記憶していて、適用業務の内容を把握できれば、必要な要件定義を自分の頭の中で描けるからだ。

　しかし、システムが複雑になるほど、その開発リスクは高くなる。設計、関与するSEのスキルレベルや工数、各SEの作業分担、作業の進捗管理など、開発プロセス全体のコーディネートが複雑かつ重要になり、そのための作業時間も増大する。さらに、開発途中で仕様変更や開発計画の変更も発生する。そうなると、いかに優れたSEでも、開発の基本となる仕様書の作成とアップデートは不可欠になる。

無償で作成した仕様書にも責任を負う

　それだけ重要な仕様書は、中身が適切であることはもちろん、仕様書にかかわる責任の所在についても、明確にしておく必要がある。

　仕様書は、開発するプログラムの目的や要件を盛り込んだ開発要求書であるから、法的には、システム開発の委託者、すなわちユーザー企業の側が仕様書を作成し、開発受託会社にそれを提示するのが本来のあり方である。ところが、コンピュータや開発に関する高度な専門知識やノウハウが必要なため、伝統的に、適用業務の説明はユーザー企業自ら行うが、それ以後の工程、すなわち要件定義書やそれを含む仕様書の作成は開発受託者に委託するケースが多い。発注者の一応のレビューと承認を得て、あたかも発注者が仕様書を作成したかのように扱い、それに基づいて開発受託者が開発行為を行うのである。これが、システム開発のトラブルの大きな要因の1つになるのだ。

　開発したシステムに欠陥と責任が存在する場合、その瑕疵（かし）に対する責任を誰が負担すべきかが、しばしば実務上の問題となる。まず、仕様書の作成責任は発注者にあるから、第一義的には、発注者に責任がある。仕様書を発注者が自ら作成した場合には、発注者がその瑕疵の責任を負担することは明白である。その仕様書に起因する損害賠償を含む一切の法的責任は発注者に帰属する。

　ところが、仕様書の作成を開発受託者に委託して、仕様書を作成したときは、第一義的責任者は開発受託者である。ただ、受託者に発注者が与えた適用業務に関する説明などに瑕疵があった場合は、瑕疵の内容と程度により、発注者と受託者間における責任の分担とその比率に関する問題が生じる。そしてその分担は、契約内容によって決まる。

　現実には、どちらにどれだけ責任があるのかを明確にするのは容易ではない。「発注者側の説明が間違っていた（もしくはあいまいだった）」とする受注者側と、「正しく説明したのに受注者側が理解できなかった」と考えるユーザー企業の見解がぶつかる。仕様書作成時のやり取りの記録などを基に、どちらに原因があるかを、詳細に調査することが必要になる。

　前述のように、仕様書の作成義務は発注者に帰属するが、業界では伝統的に、受注者が無償で仕様書を作成し、それに基づきシステム開発が行われるのが一般慣行だった。無償で作ったとしても、免責条項がなければ作成者である受注者側に責任があるのだが、無償であるがゆえに相応の責任感を持てず、仕様書の不備によるトラブルにつながることが多かったのだ。

　ただし、システム開発契約で受託業者が成果物に責任を負う請負契約が主流になった最近では、仕様書作成を開発と切り離して、有料の別契約とするようになっている。法律家の目から見れば、この動きは健全な変化である。仕様書を引き受ければ、システム開発作業やカットオーバー後の保守業務、さらには将来の追加開発業務も受注できるという期待から、無償の仕様書作成という慣行が誕生したが、両者を分離してそれぞれを競争受注する方が業界の秩序として健全であり、法的にも望ましい。

　最後に、RFP（提案依頼書）や提案書の法的位置づけについても触れておく。システム開発では、ユーザー企業が作成したRFPに対して、開発事業者が提案書（プロポーザル）を提出するのが一般的だ。ただし、RFPやそれに対応する提案書自体は、その後の開発委託契約の交渉、契約内容、責任などについて、何ら法的拘束力を与えるものではない（通常は念を入れて、その旨の免責条項を記載するのが一般的である）。では両当事者を拘束するものは何かというと、 RFPおよび提案書に基づいて締結される開発契約と、その条項である（図）。そしてRFPや提案書は、契約書の内容や両当事者の意思を解釈する基準として利用されるのだ。