システム開発における「仕様」の重要性

システム開発紛争において、「仕様」はあらゆる場面で問題となる、最も重要と言っても過言ではない要素となります。

例えば、システム開発にかかる「契約不適合」、旧民法で言えば「瑕疵」ですが、その有無は原則として仕様との合致の有無によって判断されることとなります。
また、追加開発、追加報酬請求の場面では、本来の仕様にかかる開発作業でないならば、より追加報酬請求をしやすくなると言い得ます。

ですから、システム開発紛争を予防するためには、仕様を確定し、変更があった場合にはこれを明確にする必要があります。
また、紛争を解決するためにも、まずはその時点での仕様を把握しなければなりません。
このように、紛争の予防にも、紛争の解決にも、「仕様」は非常に重要な役割を担っています。

しかし、仕様については様々な問題が生じてしまっています。
ユーザー側から、約束したとおりにシステムが仕上がっていないとして、契約不適合責任(瑕疵担保責任)の主張がなされたり、そもそもシステムは完成していないとの主張がなされたりすることがあります。
また、ベンダー側からすると、当初の仕様がユーザー側の要望で変更されたという認識の下、仕様変更である以上は追加報酬を請求しようという話になることが少なくありません。
多くの場合は、ユーザーとベンダー側の仕様合意ができていなかったり、最終的な仕様を客観化した資料等が存在していなかったりすることが原因になっていると考えられます。

余談ですが、私自身の経験からも、システム開発紛争で大きく問題となりやすい「契約不適合(瑕疵)」と「追加開発」については、「仕様」の重要さを毎回のように感じる一方、毎回のように「仕様」がなんとなくないがしろにされているようにも感じているところです。

仕様確定のための役割

仕様確定のためにはユーザーの占める役割が大きい

ユーザーが自らの要望に合ったシステム開発をベンダーに委託するわけですから、システムの仕様を最終的に決定する当事者は、ユーザーであるはずです。
もちろん、コスト等に照らした実現可能性の問題はありますから、ベンダーによる支援が必要なことは言うまでもありませんが、だからといって、ユーザーの果たすべき役割が大きいのが一般的であることには変わりありません。

役割分担は明確にすべき

もっとも、一般論を言ってみても、システム開発紛争ではユーザーとベンダーの認識のズレが紛争の原因になっていることからすれば、役割分担は明確にすべきということになるでしょう。

そこで、契約書に役割分担を行う旨を記載した上で役割分担表を作成し、お互いがそれぞれどのような役割を果たさなければならないのかを明確にしておくことが紛争予防の観点からは必要と考えられます。
また、単に抽象的に役割を記載するのでは(例えば「支援」等)、結局何が役割なのか不明確な状態となり、役割分担表を作成した意味がなくなってしまう可能性もありますから、具体的に何をするのかを記載すべきと考えられます。
ここは、ベンダー側にノウハウがあるのが通常ですから、ベンダー側で具体化するのが適切ではないでしょうか。

役割分担が明確となっていれば、相手方が果たしていない役割があった場合、これを催促しやすいというメリットもあります。
他方、役割分担が記載されていたとしても、催促等をまったく行っていなかった場合には、記載どおりの役割分担が認定されない可能性もあります。
書面上でどういった役割分担となっていたのか、という点ももちろん重要ですが、実際の稼働や運用がどうなっていたのか、という点も重要になってきます。

分担した役割と実際の稼働での注意点

役割を決めたからといって、その通りに動くことができるかどうかは別問題です。
プロジェクトが進まない場合には、硬直的に動くことができない場面も生じるでしょう。

そのような例外的な場面が生じた場合には、注意して行動することが重要です。
例えば、本来ユーザーが行うべき役割を、ベンダーがやむを得ず肩代わりしなければならない場合もあるかもしれません。
これは、本来的な合意の範囲外の作業ですから、ベンダーとしては追加費用を請求する作業ということになるでしょう。
しかし、ベンダーが追加費用が発生する旨をユーザーに告げていないまま作業を始めてしまえば、後に精算を求めた際、ユーザーからすれば不意打ちとなり、トラブルとなってしまう可能性が非常に高くなります。
ですから、肩代わりした作業は合意の範囲外の作業であること、当該作業に追加費用が発生することにつき、それぞれ合意して作業を始めるべきです。

紛争になった場合の仕様の認定

仕様に関して当事者双方における明確な合意内容が記載されている資料がある場合には、それによって仕様の内容が判断されることになります。

最も重要なのは要件定義書や基本設計書等の仕様書

システム開発では、基本的に、仕様に関する合意のすべてが要件定義書等仕様書に反映されることを目標とし、仕様書を作成していると言い得ます。
ですから、仕様に関する合意のすべては仕様書に盛り込まれているのが本来的状態であって、仕様書に記載のない内容は、仕様として想定されておらず、合意に至っていない、と考えられます。

この観点からすると、たとえ仕様書を作成する過程で作成された資料には記載のある内容が仕様書からは欠落していた場合、当該仕様は開発しないことが合意されたか、そもそも開発することの合意にすら至っていないと原則として考えるべきということになるでしょう。

他方で、契約書は、システム開発の流動性からすれば、契約書締結時点で仕様が固まっていないことが通常でしょうから、明確な仕様が記載されていることは考えにくく、証拠としての価値は低いと言えます。
また、要求仕様書やRFPも、仕様確定前におけるユーザーの要望やベンダーの営業トークをも含む提案内容が記載されている資料であり、仕様として合意されたことを示す資料とは言いがたい性質のものです。

その他、議事録は、仕様書の内容の補完的な役割としては重要と言い得ますが、作成過程や作成方法等によって、その価値は大きく左右されるところです。

まずはお気軽にお問い合わせください。