システム開発と要件定義に関する諸課題
前のページ RFP・提案書と法律 ┃ 次のページ 仕様変更・開発範囲の変更
要件定義とは
要件定義とは
システム開発において、そのシステムに必要な機能などを定義・決定することを要件定義といいます。そして要件には、次の２つの要件が含まれています。
機能要件
機能要件とは、どの範囲の業務をシステム化するのか、どんな役割をする機能を実装するのか、データの流れや処理内容等に関する要件です。
非機能要件
非機能要件とは、開発対象のシステムのうち、機能以外の要件をいいます。ここには、ユーザビリティやアクセシビリティ、応答速度などの性能要件、セキュリティ、データの容量などのキャパシティ要件等があります。
要件定義におけるユーザ（発注側）とベンダ（受注側）の役割
自社の業務のうちどの範囲をシステム化したいのか、システムにどんな機能や性能を持たせたいのかといったことは、ユーザ（発注側）が考えて決定すべきことであり、そのような意味では要件定義はユーザ側の役割ということになります。
しかしながら、システム開発については、技術的な知見や専門技術がないか乏しいユーザが、過不足なくかつ正確にシステム要件を把握して要件定義書を作ることは実際には困難です。したがって、通常は、要件定義についても、ベンダ（受注側）がユーザに対し、要件定義を支援する業務を提供します。
そのため、システム開発業務の工程の中で、要件定義の工程については、ベンダ（受注側）には成果物の完成の義務がない、むしろ必要な役務（サービス）を提供するものして、「準委任」という法的性質を持つと考えれらています。
要件定義に関する法的な問題と紛争
要件定義を行う主体に関する紛争
要件定義を行う主体について紛争の理由となることがあります。この点、東京地裁平成17年7月27日判決は、システム開発受託者Ａ社と、Ａ社が開発のためのカスタマイズのベースとして採用したパッケージのベンダーＢ社との紛争に関するものです。同ケースは、要件定義の段階で開発が頓挫したというものでした。
この点、Ａ社は、カスタマイズに関しての要件定義について、パッケージコアの部分はＢ社、周辺部分はＡ社が行うという合意だったと主張し、Ｂ社に責任があると主張しました。
これに対して裁判所は、ＡＢ間の契約において、Ｂ社の義務として「要件定義コンサルテーション」「要件定義支援」と明示されていること、ＡＢ間で要件定義を分担するとすれば相互の要件定義書の交換やドラフトレベルでの議論があったはずがそのような事実がなかったことから、Ａ社の主張を認めませんでした。
この案件は、ベンダ側にとっては、要件定義業務についての役割や法的位置づけを明確にすることの重要性を示唆するものといえるかもしれません。
要件定義に不備がある場合の責任
システム開発が頓挫したり大きなトラブルとなる原因の一つが、要件定義が不十分であったというケースです。
要件定義に大きな穴がある場合、次工程において漏れや抜けが見つかって仕様変更を余儀なくされることとなったり、要件定義が過剰である場合には、大幅な納期の遅延が発生したりすることがあります。
では、要件定義に不備がある場合の責任は、すべてユーザ（発注側）が負うのでしょうか。ケース・バイ・ケースではあるものの、ベンダが一部の責任を負うこともあります。例えば以下のような裁判例があります。
東京地方裁判所平成22年9月21日判決
同事件では、ユーザとベンダとの合意内容として、新システムでは旧システムが具備していた機能を実装すべきだったところ、要件定義の段階で複数の機能が欠落していた、というものでした。
ベンダとしては、要件定義自体は準委任契約であって要件定義の不備は債務不履行とはならないと主張しましたが、裁判所は要求定義の段階で当該機能が欠けていたことについてベンダの債務不履行であると認定しました。
東京高等裁判所令和6年5月16日判決
同事件は、セールスフォースのプラットフォームをベースとしたシステムの開発に関する案件でした。そして要件定義フェーズ終了時点にてすでに問題があったケースで、ベンダについて、ユーザが要求する機能をシステム上で実現するために必要な条件を技術的観点を踏まえて検討・整理するとともに、当該機能を取り入れることの相当性について助言すべき立場にあったこと、問題発生は不十分なプロジェクト・マネジメントや、経験・スキルの不足にあることを理由に、ベンダの責任を認め、次工程以降の開発費についての賠償を認めました。
他方で、ユーザ側の度重なる仕様変更要求の結果、スケジュールの縛りから開発時間が圧縮され、プロジェクトマネジメントを困難にした側面があることから、ユーザの過失相殺として10％の減額を認めました。
ただし、最終的には、契約書にあった責任限定条項が適用され、認容額がさらに若干カットされました。
開発の範囲と要件定義書との関係に関する紛争
要件定義書の記載のない機能について、開発の対象か否かが争われることがあります。要件定義書にないからといって、直ちに開発対象外とはなるわけではないケースがあるため、留意が必要です。
東京地方裁判所平成16年6月23日判決
ユーザは、航空券等の申込みや決済等の機能を有するシステムの開発をベンダに発注しました。争点の一つに、仕様書に記載のない遠隔操作機能（ユーザが直接サーバのデータを変更する機能）が開発内容に含まれるのか否かでした。
ベンダ側は、仕様書に遠隔操作機能の記載がないことやユーザから検収不合格の通知を受け取っていないこと等から、開発対象外と主張したのに対し、ユーザ側は、遠隔操作機能がそもそも不可欠の機能であること、これを付加することは合意していたこと、また、ベンダが作成した構成図にも遠隔操作機能を示す記載があること等を主張していました。
裁判所は、ユーザの主張を認め、遠隔操作機能は開発対象であって、当該システムは完成していないと認定しました。
前のページ RFP・提案書と法律 ┃ 次のページ 仕様変更・開発範囲の変更
弊所と法律相談等のご案内
弊所へのご相談・弊所の事務所情報等については以下をご覧ください。
- IT法務（ソフトウェア・システム開発・ITサービス関連法務）に関する弊所の特色と取組み
- 解決事例 システム開発紛争・IT紛争
- ウェブ会議・面談法律相談ご案内
- 事務所紹介
- 顧問弁護士契約のご案内
- 弁護士紹介
契約法務 弁護士費用自動見積のご案内
弊所の弁護士費用のうち、以下のものについては、オンラインで自動的に費用の目安を知ることができます。どうぞご利用ください。
- 英文契約・和文契約のチェック・レビュー
- 英文契約・和文契約の翻訳（和訳、英訳）
メールマガジンご案内
|
弊所では、メールマガジン「ビジネスに直結する判例・法律・知的財産情報」を発行し、比較的最近の判例を通じ、ビジネスに直結する法律知識と実務上の指針を提供しております。 学術的で難解な判例の評論は極力避け、分かりやすさと実践性に主眼を置いています。経営者、企業の法務担当者、知財担当者、管理部署の社員が知っておくべき知的財産とビジネスに必要な法律知識を少しずつ吸収することができます。 主な分野として、知的財産（特許、商標、著作権、不正競争防止法等）、会社法、労働法、企業取引、金融法等を取り上げます。メルマガの購読は無料です。ぜひ、以下のフォームからご登録ください。
バックナンバーはこちらからご覧になれます。 https://www.ishioroshi.com/biz/mailmag/topic/ |
ご注意事項
本ページの内容は、執筆時点で有効な法令に基づいており、執筆後の法改正その他の事情の変化に対応していないことがありますので、くれぐれもご注意ください。
