要件定義書とは？〜提案依頼書（RFP）との違いの整理〜

よくある疑問〜要件定義とRFPとの違い〜

ともに、システム開発やWEBサイト構築等の何かしらの開発、制作を行う際に、提案・要件が目的や予算、必要な項目とずれることのないように関係者に共有するために作成されるドキュメントのことをいいます。

■RFP（提案依頼書）

RFPは“Request for Proposal”の略で、発注する側が、発注を受ける見込みのある開発・制作側に対して具体的な提案を依頼するために要件を整理した文書のことです。
プロジェクトの目的、目標、やりたいことや予算等の制約条件等を記載します。
発注する側が自社でRFPの作成が難しい場合、この段階で外部のコンサルティング会社などに外注する場合もあります。
「これを実現するための提案をください」というための書面で、RFPの内容次第で、自社に即した良い提案が受けられるかどうかが決まります。

■要件定義書

受発注の有無にかかわらず、開発・制作にかかわる関係者が作成するものです。発注する側が作成することもありますが、開発、構築を受ける側が作成することが多いです。
開発、構築に着手する前に、ドキュメントで方向性・方針を提示し、共通認識や課題を整理、共有するものです。
システム・WEBサイトにおける1つ1つの仕様や機能、また予算面やスケジュールなどについて整理します。

要件定義書作成の目的と重要性

開発工程全体の中での要件定義の役割

今度はシステム開発やWEBサイト構築のなかでの要件定義の立ち位置、役割を整理します。
よく使われるいくつかのフレームの切り口を紹介しますので、理解度を高めていただければと思います。

【要件定義理解①】システム開発工程の流れから

システム開発やWEBサイト制作は、設計→構築→テスト→リリース→保守というステップを取ります。


要件定義は、設計フェーズのなかでも企画内容をベースに予算やスケジュール、目標数字や目的を考慮しながら、必要な機能を優先度を付けて具体的な開発内容を定めるフェーズです。その後のプロセスの基準となる重要なフェーズです。
そのため、ここで方向性を間違えると、プロジェクト自体の成功確率に大きく影響を及ぼします。

【要件定義理解②】「V字モデル」から

システム開発に置いて、「V字モデル」というものが使われることがあります。


図を見ていただけるとわかりやすいですが、まずは要求定義→要件定義の順となります。
要求定義＝目的、目標、課題が解決できるか？という実効果の論点、要件定義はそのうえで、解決のために必要な施策＝機能の検討になります。

要件定義書の作成の際には、機能を検討する前提としての要求定義についても共通認識を持つために含めることが必要です。
ここから見ても、要件定義は全体に影響を及ぼす重要なポイントだということが理解できると思います。

要件定義の質次第で、プロジェクトの成否が決まる

全体の流れの説明から要件定義の重要性はご理解いただけたと思います。1つ要件定義の重要性を改めて指し示すデータがあります。



出典：株式会社サン・ブレーン「企業IT動向調査報告書2023」

• スケジュール通り完了しているプロジェクトは大きなプロジェクトでは15％以下で、年々減少。小規模でも2/3が多少なりとも遅延しています。
• 予算についても、大型のプロジェクトになると4割は明らかに超過しております。

要件定義後に、要望が追加された結果プロジェクトが遅延することもありますが、これは要件定義の甘さが影響していると考えられます。
実際に、プロジェクトが予定通りにならなかった理由として最も多いのは「計画時の考慮不足」でスケジュール、予算共に50％を超えます。


出典：株式会社サン・ブレーン「企業IT動向調査報告書2023」

また品質については、「ベンダーのスキル不足」で54.4％と最多の回答結果となっており、スケジュール、予算については割合が低くなっています。
予算、スケジュールについては何とか当初の予定通りに無理やりおさめたが、品質がいまいちというケースが多いものとみられます。これも、要件定義時の見積もりの甘さが原因とも考えられます。

基本的にはシステム開発やWEBサイト制作のオーナー側からすれば、同じプロジェクトというものを経験することは少ないです。

そのため、経験していないことを最初から先回りして想定することは困難です。基本的には同じようなプロジェクトの経験者を出来る限りアサインすることが、プロジェクトを成功させるためには必要不可欠だと考えています。

良い要件定義書にするポイント

ここまで、要件定義の目的や重要性を説明してきました。要件定義書によってプロジェクトの成否が左右するということは皆さまご理解いただけたのではないでしょうか。

それでは、成功確率を高める要件定義書を作成するためにどんなポイントを押さえなければいけないのか、現役のDXコンサルタントの視点で解説していきます。是非、このポイントだけは忘れず、プロジェクト実行時にはチェックシートとしてご活用ください。

【前提】３つの理解度の高さ

まず、大前提良い要件定義書を作成するためには“理解度の高さ”が必要です。
3つの必要な理解について紹介します。

①要件定義書のお作法への理解

こちらはそのままの回答ですが、要件定義書のお作法、つまり「良い要件定義書とは何か」を知っていることが重要です。
この点は、この記事を最後まで読んでいただき、実際に要件定義書を作成する際にはチェックシートとして活用してもらえれば問題ありません。

②IT/システムへの理解

次は、「システム理解」です。最も必要な要素になります。

各企業や事業によって、様々なシステムやツールが入っています。似たカテゴリのツールでも実際に触ってみると細かい部分で異なる点は多くあると思います。
特に異なるツール間の連携などは、内容によっては対応してみないとどのように挙動するか、しっかりと動くのか、わからない部分も多くあると思います。
そう考えると、同じようなプロジェクトの経験者、対象のツールを取り扱った経験が豊富な人材などが、要件定義書作成を主導することが重要と考えられます。

もちろん、システム開発に理解がある人間であれば、豊富な経験から勘所を持っている人もいるかもしれませんし、ある程度調査で解決する部分があると思います。ただ、ここは短期間の努力では解決できない可能性も高く、先述の通り、経験者の力を借りるということがキーになると考えられます。

③顧客のビジネスへの理解

これまで記載していた通り、要件定義は規格をベースに予算、スケジュール、目的、目標を考慮し、優先順位を付けてやることを絞ることともいえます。
その精度を高めるためには、ビジネスを理解しているかどうかが大きく影響をしてきます。システム側の理解だけでは、良い優先順位付けは出来ません。

基本的に、システムやWEBサイトの開発や制作は事業課題の解決のための施策の1つです。
ビジネスのポイント、顧客のニーズ、競合のサービス等の理解が深ければ、重要なポイントとそうでないポイントの検討の精度が高くなります。
勿論、限界があると思いますが、出来る限り意識して取り組むポイントです。

なので、シンプルに言ってしまえば、当該領域のビジネスに理解が深い人が要件定義書を書く、またはアドバイスをもらうといったことが必要なポイントになります。

【考え方】全ては、目的・目標に立ち返る

あったらいいなと、なくてはいけないを分けて考える

要件定義の前の企画段階でかなりシステム含めて練られている場合もあると思いますが、ないパターンの方が多いと思われます。

そうすると「やりたいこと」「あったらいいもの」がアイデアとして積みあがってきまが、それを全て対応しようとすると、予算・スケジュールを考えた際に全部対応することが難しくなります。そのために優先度をつける必要があるのですが、基本は、企画の目的があり、達成したい目標があります。

流行りの施策や競合がやっている内容、また、声が大きい人の要望などがまず検討の俎上に上がりがちですが、目的・目標から考えると実はそこまで重要ではなかったり、ROIが悪かったりすることが多々あります。そういったものは優先度を下げるべきです。その分他の重要度の高い機能の実装が行えます。

【コミュニケーション】相互理解への努力

社外だと発注者と受注者。社内でも担当者や責任者と要件定義の作成者で分かれる場合がありますが、下記のように理解、認識、想いの差はどうしても生まれます。
大きなプロジェクトだと、さらに各部門、各部署にもそれぞれ差が生じます。


原因は、下記がよく見られます。

• システム知識の差（実現のためのコスト、達成難易度、等）
• ビジネス理解の差（実現のためのコスト、達成難易度、等）
• やりたいことの優先度の理解の差
• 社内事情の理解の差（社内オペレーション、社内ルール・規定、社内政治、社内能力、今後のイベント、等）

適切なコミュニケーションを取り、極力認識齟齬をを埋めて、発注者・担当者が心の底から納得感があるように進めていくことが求められます。

【体裁】要件定義書の記載

最後に要件定義書の内容についてです。
どんな項目が必要か？は後述しておりますため、そもそもの注意点を記載します。

当たり前のことですが、「わかりやすく」することと「曖昧な表現を使わない」ことです。理由としては、「要件定義書」については、先述の通り、理解度や認識に差がある複数の関係者が、正しく共通認識を持つためのものだからです。

わかりやすく～概念図や表をフル活用～

テキストだけだと、文字を全部読み切れずに流してしまったり、理解したつもりで出来ていないということがよくあるのではないでしょうか。
要件定義書はかなりのボリュームの資料になります。ただでさえ、テキストは読みづらいですが、読んで理解する労力が大変です。

そのため、出来る限り概念図や表を駆使して、理解を促進し、要件定義以降の認識相違を発生させないことが重要です。

曖昧な記載、表現を避ける～補足説明もフル活用～

曖昧な表現、抽象的な表現、複数の意味を持つ表現などは人によってとらえ方が変わり、つまり認識の相違が発生します。
そのためそういった表現の使用は出来る限り避け、具体的に誰がどう見ても解釈、理解がずれないように工夫することが必要です。

これを押さえればOK！要件定義書に必要な項目一覧

ここまでは、要件定義書を作成するうえでの心構えについて記載してきました。
ここからは、要件定義書に記載するべき項目、内容についてご案内していきます。最低限ここにある内容は抜け漏れなく押さえてください。

前提条件の認識のすり合わせ

背景、目的

まずは、前提となる背景や目的を記載します。
要件定義書の前提の方針、指針となる内容で、認識の相違がないかを確認するために記載します。

制約条件

あとになって、「これはできない」「あれもできない」となると要件定義書を作成する過程で手戻りが大きくなります。
予め、出来ないこと、やらないこと、条件、また要件の対象範囲などを提示して合意します。
見逃しがちですが、大変重要なポイントです。

サマリー

方針とシステム概要

各論の機能について説明する前に、まずは要件定義をまとめた大枠の考え方、方針やシステム構成図といった全体像を指し示すことが重要です。
全体像や方針がわかると、その後の説明も理解がしやすくなります。

機能要件／非機能要件

機能要件

機能要件とは、システム開発やWEB制作によって目的、目標を達成するために必要な機能として何を実装するかを決めることです。

非機能要件

非機能要件とは、システムに関わる機能以外のについての論点です。
具体的には、セキュリティ、利便性、拡張性、性能などの決めごとのことを指します。

IPA（情報処理推進機構）の非機能要件グレードでは下記の通り、例示されています。
勿論、システムやWEB制作の内容によってどこまで必要かはあるかと思いますが、参考にはなると思います。

・可用性（システムが継続して稼働できる能力）
└継続性、耐障害性、災害対策、回復性

・性能・拡張性
└業務処理量、性能目標値、リソース拡張性、性能品質保証

・運用、保守性
└通常運用、保守運用、障害時運用

・移行性
└移行時期、移行方式、移行対象(機器・データ)、移行計画

・セキュリティ
└前提条件・制約条件、セキュリティリスク分析、セキュリティ診断、セキュリティ管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策、セキュリティインシデント対応・復旧

・システム環境・エコロジー
└システム成約・前提条件、システム特性、適合規格、機材設置環境条件、環境マネジメント

導入後の業務フロー

システムの導入によって、既存の業務フローが変わることがあります。
そのため、要件定義書の段階で変更点を記載しておく必要があります。

図式化し、before、afterをわかりやすく記載することで「誰の」「どこの」「どんなフローが」「どのように」変わるかを明確にしましょう。
その業務フローが現実的に実現可能かを判断するのに十分な情報が必要です。

業務フロー図の書き方に関して詳しく知りたい方はこちらの記事もご覧ください。
https://pro-connect.jp/columns/detail/business-flow-diagram/

予算、スケジュール

開発にかかわる費用、運用にかかる費用を記載します。
出来る限り詳細に整理することで、コスト管理のための予算目安となります。

プロジェクト全体のマイルストーンや各種納期をスケジュールに落とし込みます。
各フェーズの開始・終了日やローンチ日、リリース日等、出来る限り具体的に提示しましょう。
プロジェクト全体の進行管理の解像度が高まり、遅延防止につながります。

開発体制

体制図によって、誰がどの役割で、どこに責任を持つのかを明確にしましょう。
体制図だけではなく、各メンバーの役割や実行内容を明確にすることでタスクや対応事項の抜け漏れを防げます。
また、何かあった際に、誰に何を確認すべきかが明確になります。

コミュニケーション設計

まずは、会議体をどのように行っていくか。
全体の進捗確認、各プロジェクト毎の分科会、上流の役割のメンバーによる共有会など、会議を可視化することで進行がスムーズになり、何か起きたときの際の対処もしやすくなります。

他にも、下記を整理することで、情報のやり取りの抜け漏れや行き違い、手間を防ぐことに繋がります。

• タスク管理ツール、スケジュール管理ツール
• メール、slack、Teams、その他等のコミュニケーションツールの使い方
• 資料の種類別の共有方法、更新ルール

リスク事項

要件定義の段階で、「もしかすると予算をオーバーするかも」「もしかしたらここの実現は難しいかも」など、プロジェクトのボトルネックや論点になりそうな事項があれば、その点はしっかりと明示してみんなで把握し、別途管理することが必要です。

後々、プロジェクトの進行に大きく影響しそうな内容が発覚した場合、予算・スケジュールとして取り返しがつかなくなってしまう可能性があります。
要件定義の段階である程度把握できていれば、その後のプロセスで考慮しながら対策を事前に考えたり、コストを押さえたり、スケジュールを調整したりすることができます。

要件定義書の作成手順

①理解促進のためのインプット

まず初めに、インプットの作業が必要です。上述のポイントでも記載した通り、理解度の高さはプロジェクトの成功を左右します。

プロジェクトの前提として事前情報のドキュメントが提示されると思います。まずはその資料を読み込み理解を十分することが必要です。事前情報の提供は不十分なことも多いです。

また基本的にはドキュメントをベースに業務担当者やシステム担当へヒアリングを行い、事業理解などを深めていきます。扱うシステムなどが決まっていれば、そのシステムの情報収集なども行う必要があります。

ここで特に重要なのは、「目的」「目標」「課題」といったポイントを理解することです。
システム開発では、基本的にはやりたいことは多めに見積もられ、全てを実現しようとすると納期や予算を考慮すると難しくなるため、上記の論点に合わせて絞り込む作業が必要になります。

逆に要件定義書作成を依頼する立場であれば、作成者に対してのアウトプットを惜しまずに、必要以上に共有する姿勢が重要になります。

②優先度付け「やりたいこと」→「やるべきこと」に

上述の通り、システム開発では、基本的にはやりたいことは多めに見積もられ、全てを実現しようとすると納期や予算を考慮すると難しくなることが非常に多いです。

そのため、「目的」「目標」「課題」といったポイントを論点に『やりたいこと』を優先度を付けて『やるべきこと』に精査する必要があります。
各担当、各部門と連携を行いながら1つ1つ整理をしていきます。

③システム全体の構成図と要件定義書のタタキ作成

インプット内容から「目的」「目標」「課題」といった上流の本質的な観点から、予算内、スケジュール内での実現を考慮し、「やりたいこと」を「やるべきこと」に優先順位付けをしてます。ここは関係者各位と議論を重ねて合意を得る必要があります。

そのうえで、まずは全体像としての要件定義書のタタキを作成します。
システム構成図の全体像をベースに、大枠での機能面や非機能要件におる「やるべきこと」をまとめ、合意、共通認識を得た上で、細かい要件定義に入っていきます。

④要件定義書の作成

機能要件を定義する

上記で設定した全体像から、1つ1つの機能要件を細かく整理して、仕様等を決定していきます。

非機能要件を定義する

上記で設定した全体像から、1つ1つの機能要件を細かく整理して、仕様等を決定していきます。

予算とスケジュール、コミュニケーション方法を定義する

予算や各機能や非機能要件の構築スケジュールを定めます。
また、プロジェクト進行におけるコミュニケーション方法を定めます。

まとめ～要件定義書がプロジェクト成否のカギ～

長文を最後までお読みいただき誠にありがとうございました！
ご覧いただいた通り、要件定義書はシステム開発やウェブ制作の成否を決める非常に重要なドキュメントです。

目的、目標、課題解決の観点に立ち返り、達成のために必要なものを精査し、上記の内容を参考に進めてください。
そして何よりも成功確率を高めるのは、該当プロジェクトに近い経験をした人間をPMやアドバイザーなどでしっかりとアサインすることです。

要件定義書の作成にあたり、ProConnectがご相談を承ることも可能です。
ぜひご登録・お問い合わせください。
https://pro-connect.jp/

執筆者

ProConnect編集部
4,000名のフリーランスの皆さまにご登録をいただいており、年間100件以上のプロジェクトをフリーランスの皆さまと取り組んでおります。