仕様変更・開発範囲の変更に関する諸問題
前のページ 要件定義に関する諸課題 ┃ 次のページ システムの完成・未完成
頭の痛い仕様変更・開発範囲の変更の問題
仕様変更などが生じる原因
システム開発の業務は、開始の時点では全体を見通しにくいことも少なくなく、それゆえに、仕様変更、機能拡張、開発範囲の拡大といった変更が発生することがあり、ときにはその変更が多数に及ぶこともあります。
そうした仕様変更や開発範囲の拡大が生じるのは、いろいろな原因があります。例えば以下のような原因です。
- ユーザー側で、そもそもどんなシステムを構築したいのかが明確になっておらず、あいまいな要件や設計のまま製造フェースに入る
- 納期が厳しかったり、要件定義や設計のフェーズで遅延が生じているゆえに仕様未確定のまま製造フェースに入り、ユーザーとベンダーの認識の齟齬が後に噴出する
- いったん凍結した要件に基づいて開発しているにもかかわらず、ユーザーから途中で新たな機能の要望が次々と生じ、断れずに受け入れてしまう
- 開発後に、開発成果物を見たユーザーから新たな機能要望が多数出て、これを受け入れてしまう
- 凍結した仕様の実現のための開発工程において、所定の機能の実現が技術的に困難であったり他の技術的問題が生じる
法的紛争と仕様変更
法的紛争に発展するシステム開発のケースでは、仕様変更が関わることが多く、仕様変更は紛争の温床といえます。
以下、仕様変更をめぐる法的な紛争において高い頻度で争点となる論点と、仕様変更をトラブルの種とする可能性を減じる方策について考えたいと思います。
仕様変更をめぐる法的な争点1 開発対象の範囲や特定の問題
当初の開発対象の特定の問題
仕様変更がからむシステム開発を巡るトラブルとして、そもそも、発注者（ユーザー）から開発途中に出される要望が、当初の契約において合意した仕様の範囲内なのか、それとも当初の仕様の変更や機能の追加なのかが争われる、ということがあります。
この点は、契約書や仕様書、双方が合意した設計書があれば大きな立証資料となりますが、法的な紛争が生じているケースでは、重要な書類がなかったり、あっても抽象的なレベルの記載しかなかったりすることがままあります。
この場合、訴訟実務では、仕様書、RFP、提案書、見積書、契約交渉過程で作成されたチャート、図面、議事録、担当者間のメールやメッセージングのやりとり、などのあらゆる証拠から、当事者間の合意内容を探っていきます。
これらは得てして膨大な作業となり、システム開発訴訟の長期化と費用の高額化を招く要因の一つですし、有利不利の見通しが立てにくいことも少なくありません。そこで、こうした紛争においては、いかに資料を多く確保し、立証のために保全できるか、が重要な要素となります。
紛争リスク軽減のための対処法
ものをいうのはドキュメント
いざという場合に物をいうのはドキュメントです。契約締結段階では成果物の範囲・要件・仕様を確定できないことも少なくないと思います。それで、要件定義や設計など各フェーズごとに成果物の要件や仕様を凍結し、顧客の承認を得て、これをドキュメントに残すという作業を行うことは重要といえます。
また、これら仕様書面が詳細で明確であるほど争いの余地は狭まっていきます。
また、要件や仕様の凍結とともに、課題管理一覧表などを作成して管理し、その課題が当初合意された要件や仕様の範囲なのか範囲外なのかを都度明確にしていくことも有益といえますし、追加作業に関するやり取りを議事録に残して都度双方で確認することもいざというときに自社を守るものとなります。
多段階契約にする
伝統的なウォーターフォール型の手法では、システム開発のプロセスは、(1)要件定義 (2)外部設計、(3)内部設計、(4)開発（製造）、(5)運用テスト、(6)納品といった工程をたどります。
実は各工程の業務の法的性質は同じではなく異なるため（詳細は「「請負」と「準委任」」のページ参照）、各工程、またはまとまった複数の工程ごとに、業務の性質にあった契約形態を選択し、個別契約を締結していくことがあります。これを「多段階契約」といいます。
多段階契約にすることで、各工程ごとに仕様や成果物を凍結して次の工程に進むことに繋がり、結果として、ある追加作業が仕様変更に該当するか否かを区分けしやすくなります。
仕様変更をめぐる法的な争点2 仕様変更と開発費の追加請求
仕様変更と超過分の報酬請求が認められるケース
仕様変更や開発範囲の拡大があると、見積時や契約時の想定工数を大幅に超過してしまうという事態は多く発生します。
この場合、追加報酬についての明示的な合意がないようなケースで、ベンダーとしては超過分の報酬を請求することはできるでしょうか。
結論からいえば、ケース・バイ・ケースであり、できる場合とできない場合があります。以下、費用の追加請求ができる可能性があるケースを考えたいと思います。
当初仕様開発すべき機能や開発範囲が確定できる場合
凍結した仕様書から、当初に合意した機能や開発範囲が確定でき、仕様変更が、その範囲を超えた作業であることが明らかである場合には、基本的には開発費の追加請求が認められることが多いと考えられます。
ただしこの場合も、仕様変更の内容や程度によっては、ユーザーからの変更要求に対しベンダーが安易に受け入れて開発を行う場合、その時点で、開発費の増額なく仕様変更の合意があったと、裁判所が認定する場合もありますから、注意が必要です。
例えば、大阪地裁平成14年8月29日判決は、ソフト開発の性質上、当事者間の打ち合わせの中で仕様の詳細にある程度修正が加えられるのが通常であるから、仕様の詳細に関する変更では、追加報酬は発生しないとも述べました（ただしこのケースは、仕様変更要求が、基本機能設計書で確定した項目に変更を加えるものであり、追加報酬が発生すると判断しています）。
当初合意で開発費の金額の算定根拠が定められている場合
また、機能数などに基づいて開発費の金額が算定されており、その根拠となる機能数に変動が生じ、かつそのことをユーザも認識していたというケースで、追加請求が認められた事例があります。
例えば、東京地裁平成17年4月22日判決の事例は、182本であったプログラム数が、最終的に414本まで増加したという大幅な仕様変更があったというケースで、見積書には、「作業着手後の機能追加、変更等により工数に大幅な変動が生じた場合は別途相談」との趣旨の記載がありました。
裁判所は、見積書の記載事態から追加費用の請求は認めなかったものの、別途当事者間で合意があったとして当該報酬請求権を認めました。
追加報酬請求に関する紛争リスク低減策
以下、追加報酬請求に関する紛争リスク低減策のうちいくらかをご説明します。
仕様の明確化
初の仕様凍結の段階で、開発範囲や要件、仕様が明確化され、これがドキュメント化されていれば、あるい追加作業が仕様変更や開発範囲の拡張なのか、当初仕様の範囲なのかの判断がしやすくなり、追加報酬の請求のしやすさに繋がります。
この点、当初の開発対象の特定の問題については、こちらの項目をご覧ください。
報酬算定の根拠を定めておく
実務上可能なら、報酬算定の根拠を定めておくことを検討できます。例えば、工数と時間単価で定めているようなケースでは、追加開発の報酬についての算定についても、工数と時間単価で定めることが可能となる可能性が高くなります。
追加作業の際に追加報酬が生じる旨を合意する、示唆する
追加作業の際に追加報酬が生じる旨を契約書に定めるほか、仮にそれが難しい場合も、その旨を見積書に記載することで、紛争のときに追加費用の支払いが認められる可能性を上げることができます。
あるいは、ある時点で発注者（ユーザー）から追加作業の依頼を受けた場合に、その時点では機能追加または仕様変更ではないかと思いながらも、正面からこの点を主張しにくい場合があるものと思います。
こういう場合でも、メールなど証拠に残る形で、「今回依頼を受けた作業が当初仕様に含まれていない機能追加である場合には、費用の追加について相談させていただきたい」といった趣旨の文言を残すだけでも、黙って依頼を受けることに比べれば、追加報酬の支払を受けられる可能性を高めるものとなります。
仕様変更をめぐる法的な争点3 仕様変更と他の責任の関係
仕様変更に関する立証と開発遅延に関する責任
当然ながら、当初仕様にない仕様変更や開発範囲の拡大が多く発生すると、開発期間は大幅に延び、開発の遅延がトラブルに繋がるということは珍しくありません。
そして、追加の作業が、ユーザーの意思に基づく、当初仕様にない仕様変更や開発範囲の拡大であることが立証できれば、受注者（ベンダー）としては基本的には開発遅延について責任を負わないということになります。
そのため、開発途中に発注者（ユーザー）からなされる作業の依頼が、仕様変更や機能追加なのか、当初仕様の範囲内なのか、またこのあたりの事実をいかに立証できるかは、仕様変更をめぐる直接の争点のみならず、開発の遅延という他の責任にも関わってくることになります。
仕様変更や機能追加とベンダーの責任
とはいえ、受注者（ベンダー）が、発注者（ユーザー）からの要請に応じて仕様変更や機能拡張に応じた結果生じた開発遅延につき、その責任の一部がベンダーにあると判断された裁判例もあります。
この点、東京高裁平成26年1月15日判決は、ベンダーが、ユーザーからの変更申入を応諾する契約上の義務がなかったこと、システム開発の専門的知見や経験を備えていることから、ユーザーからの変更の申入があった時は、これに応じることが、システムの不具合や障害の発生の可能性を増加させ、検収終了時期が大幅に遅延し、個別契約の目的を達成できなくなる場合があるということを告知して説明する義務があると述べました。
そして裁判所は、 システムの瑕疵によって生じたユーザーの損害のうち、ベンダーが負うべき責任の範囲を決めるにあたり、以上の判断を一つの要素としています。
したがって、受注者（ベンダー）としては、当初仕様や機能が凍結した後は、ユーザーからなされる機能追加などの要請については、すべて応じてもよいと安易に考えることは慎重であるべきと考えられます。むしろ、これに応じた結果として開発の遅延や成果物の不具合が出た場合に、すべてユーザーの責任とは当然には判断されないということを念頭に置き、都度適切な対応が必要になると考えられます。
前のページ 要件定義に関する諸課題 ┃ 次のページ システムの完成・未完成
弊所と法律相談等のご案内
弊所へのご相談・弊所の事務所情報等については以下をご覧ください。
- IT法務（ソフトウェア・システム開発・ITサービス関連法務）に関する弊所の特色と取組み
- 解決事例 システム開発紛争・IT紛争
- ウェブ会議・面談法律相談ご案内
- 事務所紹介
- 顧問弁護士契約のご案内
- 弁護士紹介
契約法務 弁護士費用自動見積のご案内
弊所の弁護士費用のうち、以下のものについては、オンラインで自動的に費用の目安を知ることができます。どうぞご利用ください。
- 英文契約・和文契約のチェック・レビュー
- 英文契約・和文契約の翻訳（和訳、英訳）
メールマガジンご案内
|
弊所では、メールマガジン「ビジネスに直結する判例・法律・知的財産情報」を発行し、比較的最近の判例を通じ、ビジネスに直結する法律知識と実務上の指針を提供しております。 学術的で難解な判例の評論は極力避け、分かりやすさと実践性に主眼を置いています。経営者、企業の法務担当者、知財担当者、管理部署の社員が知っておくべき知的財産とビジネスに必要な法律知識を少しずつ吸収することができます。 主な分野として、知的財産（特許、商標、著作権、不正競争防止法等）、会社法、労働法、企業取引、金融法等を取り上げます。メルマガの購読は無料です。ぜひ、以下のフォームからご登録ください。
バックナンバーはこちらからご覧になれます。 https://www.ishioroshi.com/biz/mailmag/topic/ |
ご注意事項
本ページの内容は、執筆時点で有効な法令に基づいており、執筆後の法改正その他の事情の変化に対応していないことがありますので、くれぐれもご注意ください。
