執筆：弁護士 森田 芳玄（AI・データ（個人情報等）チーム）
『連載：システム開発紛争の基本問題（１） 請負契約と準委任契約の区別の判断要素について（前編）』はこちらから
『連載：システム開発紛争の基本問題（２） 請負契約と準委任契約の区別の判断基準について（後編）』はこちらから
『連載:システム開発紛争の基本問題（４） プロジェクトマネジメント義務』はこちらから
１．はじめに
システム開発業務を委託/受託するに際してトラブルに巻き込まれてしまうことは意外にあるものです。そのようなときに後悔しないように、本連載では事前に対処するべき事項や、実際にトラブルになってしまった際の対処法などをできる限りやさしく解説してゆくことを目的としています。
第３回目は、仕様の重要性について検討してみたいと思います。なお、今回は主に請負契約の場合を想定しています。
２．仕様が重要である理由
システム開発における仕様とは開発の対象となるシステムの機能や性能などを記述したものを指しますが、それが重要である理由について、まずは見てゆきたいと思います。
（１）契約履行の対象となる
まず、業務委託契約書を締結する場合、（とりわけ請負契約の場合には）法律上は仕事の完成により報酬が請求できるとされていることから、どのような仕事を完成させれば報酬が請求できるのか、その「仕事」を明確化する必要があります。
この点について、契約書には「〇〇システム開発」とか「〇〇サイト制作」などという行うべき作業の題目が記載されているかと思いますが、それだけでは当然のことながら具体的な作業が明らかではありません。そこで、仕様とは受託者が行うべき作業の内容を確定する意義を有することになります。
契約書においても「仕様は別途当事者間で定める仕様書のとおりとする」のような文言が記載されて、具体的にどのような内容の作業を行い、何を制作したら「完成」となるのかが明らかにされている例が多いかと思われます。
（２）検収の際の合否の基準となる
つぎに、実際に仕事を完成させた場合、通常検収という作業を委託者の方で行うことになります。これは委託者の方で、完成したとされる成果物が委託した内容と合致しているか否かを確認する作業になります。
この場合、大規模な案件の場合などには検収基準があらかじめ作成され、それに基づき検収作業が行われる場合もありますが、そのような基準がない場合においても当初の仕様に従った成果物になっているか否かという観点で確認することになります。
したがって、仕様は検収の基準としての役割も有することになります。
（３）契約不適合責任の基準となる
３番目に、受託者は完成した成果物に不具合があった場合に補修や損害賠償などの義務を負う契約不適合責任（２０２０年４月１日施行の民法改正前のいわゆる瑕疵担保責任）を負担することになるのですが、契約「不適合」であったか否かというのも、当事者間で定めた仕様に合致しているか否かという観点で判断されることになります。すなわち、あらかじめ当事者間で定めた仕様のとおりに開発するというのが契約の内容となっていると考えるため、仕様のとおりの成果物ではないことをもって契約違反である、と考えることになるためです。
したがって、仕様が明確になっていない場合には、契約不適合責任を主張する際にどの点が契約に合致していないのかについて明らかにできない可能性が生じてしまうことになります。
（４）追加報酬請求の基準となる
最後に、システム開発の場合、当初の仕様のまま完成に至るということはむしろ少なく、通常は途中で開発内容が変更されたり、追加されたりするということが頻繁に生じるかと思います。そのような場合に、受託者としては行うべき作業が増えた分の追加の報酬を請求することになります。そこで委託者から開発内容変更の要請があった際に同時に追加報酬の取り決めまでできればあまり問題は生じないのですが、実際の開発現場では担当者レベルで次々に変更依頼が舞い込み、なおかつ納期が迫っていたりして、追加報酬の取り決めまでできずに開発が進んでしまうケースもよくあります。
そのような場合に、事後的に追加報酬を請求できないかというと、当初の仕様に定められている仕事以上の作業を行ったということが明らかであれば、追加の報酬請求ができる余地があります。
しかしながら、当初の仕様が明確でないと、どこまでが当初の仕事の範囲内の作業であり、どこからが追加分になるのかが明らかではなく、追加請求が困難となってしまいます。したがって、仕様は追加報酬を請求する場合の「追加」になるか否かの基準の役割も果たすことになります。
３．仕様がトラブルになる原因
以上のように仕様には様々な役割があり非常に重要なものであるということになりますが、これがトラブルになる原因としては、以下のような事情が挙げられるかと思います。
（１）そもそも仕様が明確に定められていない
急ぎの案件や小規模な案件、委託者と受託者の関係性（例えば代表者同士が以前からの友人・知人関係にあるなど）から、なんとなく口頭で成果物のイメージの共有はあるものの、具体的な仕様が明確に決められないまま作業が進んでしまうという事例が見受けられます（とくにサイト制作のような案件では多いような印象です。）。あるいは、計画書のような概要のみ定められている例も多いかと思います。
（２）仕様の変更が頻繁になされる
上述したとおり、システム開発の場合、当初定められた仕様のとおり最後の完成にまで至る場合の方がむしろ少ないのではないかと思われます。通常は開発の途中で開発内容の変更・追加などが行われます。しかもそれが多数回に及ぶことにより、どの時点でどの仕様が当事者間で共有されている仕様なのかがわからなくなることがあります。
（３）仕様の変更が現場レベルで行われる
システム開発の現場では、開発に関する日常的なコミュニケーションについては委託者側の担当者と受託者側の担当者との間でやり取りが行われるのが通常かと思います。そうすると仕様変更も開発の現場担当者レベルでのコミュニケーションの中で行われることがあり、しかもその担当者が複数いる場合には、仕様が変更されているのか否か、全体像を責任者が把握していない場合もあり得ます。
（４）仕様の変更が口頭で行われる
緊急の案件の場合など、仕様変更が口頭のやり取りで行われる場合があります。そうすると、あとになってからいつの時点でどのような変更の依頼があったのか、そもそも仕様変更の依頼があったのか否かが不明確になってしまう場合があります。
４．トラブルを避けるための留意点
以上のように仕様は重要なものであるにもかかわらず、その性質上トラブルになる原因を多数孕んでいるものであるともいえます。そこでトラブルを避けるための留意点を挙げたいと思います。
（１）仕様はできる限り明確に確定しておく
契約書を締結する際には、具体的にどのような内容の仕事を行えば「完成」に至るのか、その内容をできる限り詳細に明確化しておく必要があります。そもそも仕様が明確でなければ「完成」させる対象が明らかとはなりませんし、その後に仕様が変更になったり追加の作業が発生したりした場合においても、最初の仕様が明確でなければ、委託者から当初の作業内容に含まれるものであると主張された場合に、追加の報酬請求をすることが困難となります。したがって、仕様はできる限り明確に確定しておく必要があるといえます。
（２）変更管理を明確にしておく
これまで繰り返し述べたとおり、システム開発の場合には仕様変更が頻繁に行われるのが通常であることから、その変更管理を明確にしておく必要があります。しかも、最新版だけ保存しておけばよいというものではなく、当初の仕様からどの部分が追加になったり変更になったりしているのかが事後的に明確になるように、どの時点ではどのような内容であったかということがわかるように、変更履歴を残すとか、すべてのバージョンを保存しておくことが重要になります。というのも、あとから追加の報酬請求を行う場合には、最初の仕様とその後の変更後の仕様の差分が追加の作業部分という主張を行うことになるかと思いますが、最新の仕様しかない場合にはその点が明らかではなくなってしまうためです。
（３）変更は文字に残す
仕様変更は会議や電話などで決められる場合もあり得るかと思います。ただ、当然のことながら事後的にトラブルになった場合、口頭のやり取りでは実際にそのようなやり取りがあったのかなかったのかわからなくなってしまいます。そこで、やり取り自体をメールやコミュニケーションツールにより文字媒体で残すことや、会議などの口頭のやり取りで行われた場合には、事後的に議事録などの書面にしておくことが重要となります。
なお、コミュニケーションツールなどを利用してやり取りが行われる場合、何らかの事情でそのツールにログインできなくなると、必要なメッセージやファイルにアクセスできなくなるリスクがありますので、仕様変更に関するやり取り部分を別途保存しておくなどの必要も生じます。
５．仕様の判断方法
以上のとおりシステム開発において極めて重要な位置づけを持つ仕様なのですが、実際に紛争になった場合にどのように仕様が判断されるのかが問題となります。
この点については、仕様書などがあればまずはその内容が有力な証拠となります。これは仕様書という名称ではなく、要件定義書とか基本設計書など他の名称であっても実質的に仕様が記載されているものであれば同様となります。
しかしながら、とくに小規模な開発案件やサイト制作などのような場合には、そのような正式な仕様書がない場合も多くあり得るかと思われます。そのような場合でも、契約書に添付されている開発対象の概要が記載されている別紙書面や委託者の要求仕様書、場合によっては提案依頼書（ＲＦＰ）なども仕様に関する内容が記載されていれば根拠になり得る可能性があります。
また、その後の仕様変更については、もちろん変更のたびに仕様書の内容が改訂されていれば最も確実な証拠ということになりますが、そうではない場合も多いのではないかと思われます。その場合においても、会議の議事録やメール・コミュニケーションツールでのやり取りなどでも仕様変更の合意があったと認められる可能性はありますので常にその保存を心掛けておくべきです（ただし、決裁権限のない現場担当者同士のやり取りのみで合意があったと認められるか否か、という別の問題はあります。）。
６．まとめ
今回は仕様の重要性について検討しました。システム開発に関するトラブルについては、突き詰めると依頼した内容に沿ったものができているか否か、というところに帰着することは多いです。そこで依頼した内容が明確であればそれが完成しているか否かのみが争点となるのですが、そもそも依頼した内容自体が不明確になってしまっているために深刻な紛争になっている例が非常に多く見受けられます。そのような紛争の深刻化を避けるためにも、仕様の明確化の重要性を十分に認識していただければと思います。
