要件定義書は、システム開発におけるプロジェクトの初期に実施される工程である要件定義の内容を記載した書面です。
要件定義書には、システム開発の目的や実現したい内容のほか、その実現のためにシステムが備えるべき機能や性能などが具体的に記際されています。
要件定義書を作成することによって、そのシステムに求められる全体的な機能が明確となります。
この記事では、要件定義書の重要性、要件定義書に関する法的なトラブルのほか、要件定義書の書き方や具体的なサンプルなどについて、詳しい解説をしています。
要件定義書とは？
システム開発における初期段階で、どのようなシステムを作成したいのかを定義することを要件定義といいます。
要件定義書とは、この要件定義の内容を明記した書面のことであり、RDD（Requirements Definition Document）とも呼ばれます。
要件定義は、システム開発を担当するベンダーとユーザー側である企業とが、開発するシステムの内容や必要となる機能、業務要件等について、何度もヒアリングや打ち合わせを行って調整し、確定させていきます。
要件定義が確定すると、ベンダーがその内容をまとめた要件定義書を作成し、ユーザー側の企業に提出します。
要件定義書の法的性質は準委任契約
要件定義書の作成について、その法的性質は、民法上の準委任契約にあたります。
準委任契約は、①履行割合型と、②成果完成型の2種類に分類されます。
①履行割合型では、明確な成果という形がない場合において、成果の完成を基準に報酬を支払うことは困難であることから、履行の割合に応じて報酬を請求できます（民法648条3項）。
これに対し、②成果完成型は、委任事務の履行により得られる成果に対して報酬を支払うことを約した場合であり、報酬の支払いが請負契約に類似するため、原則として成果完成後に報酬の支払いを請求できます（民法648条の2第1項）。
委任事務の履行の結果が可分であり、かつその給付により委任者が利益を受ける場合は請負の規定（民法634条）を準用し、委任者（ユーザー）が受ける利益の割合においてベンダーは報酬を請求できます。
一般的に、要件定義書の作成は、②成果完成型の準委任契約です。
要件定義書が重要な理由
要件定義書の作成は、そのシステムに求められる全体的な機能を明確にする作業ともいえます。
要件定義書は、その後の設計や開発の工程の基となるものであり、システム開発の成否やプロジェクトの目標達成を左右する、非常に重要なものです。
要件定義書の内容があいまいであったり、誤りや抜け漏れがあったりすると、その後の開発計画が遅延したり、予期しなかった不具合が生じるだけでなく、システムの機能や性能がユーザーの求める水準に満たないものとなるおそれが高くなります。
このような場合、損害賠償責任などの法的責任が問題となることがあり、ベンダーとユーザー側の企業のどちらが責任を負うのか、法的なトラブルに発展してしまうケースも少なくありません。
そのため、無用なトラブルを避け、プロジェクトを成功させるためには、時間をかけて要件定義を適切に行ったうえで、不備のない要件定義書をしっかりと作成することが大切です。
要件定義書の法律トラブルの例
要件定義書に不備があった場合
要件定義書の内容に不備があると、システム開発の発注者であるユーザー側の企業と受注者であるベンダーとの間で法的なトラブルとなることが多いです。
誤りや抜け漏れがある要件定義書では、ユーザー側の企業が望むようなシステムが開発・提供されない可能性が高いでしょう。
このような不備のある要件定義書を作成したベンダー側は、不備を修正しない限り、ユーザー側に対して損害賠償責任を負うこととなります。
そのため、ベンダー側としては、要件定義書の作成に際しては、ユーザー側のシステム担当者などから適切なヒアリングを行い、ユーザー側の要望通りの要件定義書となっているか、しっかりと確認してもらうべきでしょう。
要件定義書に変更・追加がある場合
要件定義が確定して要件定義書の作成が完了し、システムの開発工程に進んだ段階で、ユーザー側の企業が、要件の追加や変更を要求するというケースがあります。
このように、後になって要件定義の変更・追加があると、開発スケジュールや納期に大幅な遅れが生じたり、当初の予定よりも費用がかかってしまう可能性が高くなります。
このような場合、ユーザー側の企業はベンダーに対し、当初の契約金額のまま要件定義を変更・追加するよう要求することはできるのでしょうか。
裁判例（東京地裁平成22年7月22日判決）は、要件定義の工程において、要件を決める責任は、原則としてユーザー側にあるとしています。
そして、要件定義が確定した後にユーザー側が要件を拡大させた場合、ベンダーに対して当初の契約金額で開発するように要求することはできないとしています。
なお、要件定義の追加・変更があると、予期せぬ不具合が生じるなどによって、場合によっては、ユーザー側の企業の要望の実現が不可能となってしまうこともあります。
そのため、要件定義を追加・変更する必要がある場合には、スケジュールの調整や費用の再検討だけではなく、そのプロジェクトの実現可能性はあるのかについてもしっかりと検討することが必要です。
要件定義書の書き方
要件定義書には、要件定義の工程で実施した内容を、明確かつ簡潔に記載します。
システムやプロジェクトの内容によって要件定義書の書き方は異なりますが、一般的には、まず冒頭に、開発を行うシステムの概要を記載します。
また、大きく分けて、以下の3種類の要件を記載します。
- 業務要件
- 機能要件
- 非機能要件
以下、具体的な要件定義書の書き方を説明します。
システム概要
システム概要では、システムの構成図を記載してその概要を分かりやすく説明します。
また、システム開発の目的や実現したい内容などを具体的に記述します。
さらに、要件定義書の理解に必要となる用語や言葉について定義します。
業務要件
業務要件では、導入するシステムによって達成すべき目的や、必要となる機能や性能などを具体的に記載します。
記載すべき主な事項は以下のとおりです。
業務実施手順
業務を実施するために必要な体制や手順、業務フロー図などを記載します。
規模
導入するシステムの利用者数や単位（年・月・日・時間等）当たりの処理件数を記載します。
時期・時間
業務の実施時期や実施期間、実施時間などを記載します。
場所等
業務の実施場所や設備、必要な物品等の種類・量などを記載します。
管理すべき指標
業務の運営に必要となる指標項目や手法、頻度などを記載します。
システム化の範囲
システム化の対象となる業務の範囲を記載します。
情報セキュリティ
業務の内容に応じた情報セキュリティ対策を記載します。
機能要件
機能要件では、すでに定められた業務要件を満たすために、導入するシステムの機能に求められる要件を定義し記載します。
記載すべき主な事項は以下のとおりです。
機能に関する事項
処理内容、入出力情報・方法、入力・出力の関係などを記載します。
画面に関する事項
そのシステムで表示される画面の概要や表示イメージなどを記載します。
帳票に関する事項
そのシステムで入出力される帳票について、帳票の概要や表示イメージなどを記載します。
データに関する事項
そのシステムで取り扱う全てのデータについて、データモデル、データ定義、データの利活用方法、オープンデータの範囲・方法などを記載します。
外部インターフェースに関する事項
外部連携する場合のインターフェースについて、送受信データ名や送受信の条件などを記載します。
非機能要件
非機能要件では、導入するシステムに求められる機能要件以外の要件を定義し記載します。
記載すべき主な事項は以下のとおりです。
ユーザビリティ及びアクセシビリティに関する事項
そのシステムの各機能についてのユーザビリティ及びアクセシビリティについて記載します。
システム方式に関する事項
クラウドサービス、ハードウェア、ソフトウェア、ネットワーク等の攻勢に関する全体の方針などの案を記載します。
規模に関する事項
機器数、設置場所、データ量、処理券数、利用者数などを記載します。
性能に関する事項
応答時間、バッチ処理時間などを記載します。
信頼性に関する事項
稼働率等を記載します。
拡張性に関する事項
そのシステムの性能及び機能の拡張性要件を記載します。
上位互換性に関する事項
そのシステムを構成するOS等のバージョンアップ時におけるシステムの改修の許容度合などを記載します。
中立性に関する事項
調達コストの削減、市場で容易に取得できるオープンな標準的技術または製品を用いる場合などの要件を記載します。
継続性に関する事項
障害・災害等によるシステムの問題発生時に求められる機能、システム構成などを記載します。
情報セキュリティに関する事項
情報セキュリティ対策について記載します。
稼働環境に関する事項
クラウドサービスの構成、ハードウェア・ソフトウェアの構成、ネットワークの構成などについて記載します。
テストに関する事項
システムの設計から運用開始に至るまでの全てのテストの種類、目的、内容、実施者、合否判定基準、テスト実施環境などを記載します。
移行に関する事項
本番環境への業務移行、システム・データ移行について、移行時期、移行方法、以降対象などを記載します。
引継ぎに関する事項
そのシステムの開発・運用等について、他の関係事業者への引継ぎに関する要件を記載します。
教育に関する事項
利用者に対する教育について、教育対象者の範囲、業務実施手順、システム操作に関するマニュアルの作成などを記載します。
運用に関する事項
そのシステムの運用時間、障害復旧、運用管理方針などを記載します。
保守に関する事項
そのシステムを構成するクラウドサービスやハードウェア、ソフトウェア、アプリケーションプログラム等の保守、サポート体制などを記載します。
要件定義書を書く際のポイント
ユーザー側は、必ずしもITの知識を十分に持っているとは限りませんので、ベンダーが作成した要件定義書を読んでもユーザー側が意味を理解することができない、という事態は避けなければなりません。
ベンダー側としても、ユーザー側の要望を、漏らすことなく正しく記載することができているかどうかを、ユーザー側自身でしっかりと確認できるような要件定義書を仕上げる必要があります。
そのため、要件定義書では、難しい専門用語の使用は避け、明確で簡潔な記述を用いることや、文章だけでは理解しづらい部分についてはイメージ図などを用いることなどによって、誰が読んでも内容が分かるようなものにしましょう。
要件定義書のサンプル
以下のページでは、要件定義書のサンプルを掲載しています。
要件定義書は、どのようなシステムを開発・導入しようとするのかによって、記載すべき内容は多少異なりますが、このサンプルを利用すれば、必要な部分を修正してさまざまなシステム開発に活用できます。
どなたでも、無料でダウンロードすることができますので、一から要件定義書を時間や労力をカットするためにも、ぜひご活用ください。
要件定義書のポイント
ベンダーだけでなくユーザー側の企業も積極的に要件定義に関与する
要件定義の工程では、ベンダーがユーザー側の企業の要望をヒアリングし、現状のシステムの課題や問題点、解決策などを洗い出し、まとめていく作業を行い、最終的に要件定義書にその内容を記載します。
ユーザー側の企業はシステムに関する専門家ではないことが多いため、要件定義書の作成をベンダーに任せきりにしてしまうケースも見られます。
しかし、要件定義書は、ユーザー側の企業の要望をまとめたうえで、開発・導入するシステムの機能や性能について具体的に記載したものです。
そのため、ベンダー側だけでは、ユーザー側の企業の要望を完全に満たす要件定義書を作成することは難しいでしょう。
したがって、要件定義の工程および要件定義書の作成については、ベンダーに任せきりにするのではなく、発注者であるユーザー側の企業自身も積極的に関与するべきです。
要件定義書の内容を明確にする
要件定義書があいまいな内容となっている場合や、誤りや抜け漏れがある場合、ユーザー側の企業が求めている機能や性能を備えたシステムが開発・提供されないという可能性が高まってしまいます。
要件定義書は、その後の設計・開発の工程を適切に進めていくためにも非常に重要なものですので、発注者であるユーザー側の企業が、そのシステムでどのようなことをしたいのか、どのような性能や機能を求めているのか等を明確に記載しておくべきです。
要件定義書の内容を明確にしておくことで、その後のプロジェクトがスムーズに進行し、無用なトラブルの発生を回避することができます。
また、要件定義書の内容について、その必要性や網羅性、具体性、整合性や情報セキュリティ等の観点から、実現可能性があるかどうかを確認することも重要です。
どうしても現時点では確定できない要件については、その後のプロジェクトの進行におけるリスクとなり得るという点に十分に留意したうえで、その旨を要件定義書に記載しておくことが重要です。
ITに詳しい弁護士・顧問弁護士を利用する
要件定義書に不備があったり、要件確定後に要件を追加または変更したりする場合、損害賠償責任などの法的トラブルに発展する可能性があります。
このような法的トラブルは、ベンダーとユーザー側の企業の話し合いで解決することが難しいケースが多いため、裁判に発展してしまうことも珍しくありません。
要件定義書やシステム開発をめぐる法的トラブルを未然に防ぐためには、法律の専門家であり、かつ、ITに精通している弁護士に相談することをお勧めします。
また、企業等が特定の弁護士を顧問弁護士として契約している場合には、その顧問弁護士に相談することが可能です。
顧問弁護士を利用するメリットなどについては、以下のリンク先でくわしく説明しています。
まとめ
以上、要件定義書について、その内容や重要性、ポイントなどについて詳しく説明しましたが、いかがだったでしょうか。
要件定義書は、システム開発の初期の段階で作成されるため、要件定義書に不備があると、その後の設計・開発の工程で問題が発生し、プロジェクトがうまく進まなくなるほか、損害賠償責任などの法的トラブルに発展しかねません。
この記事を読んだ方が、要件定義書の作成およびその後の工程をスムーズに進められるよう、お役に立てば幸いです。
