システム開発の初期段階で行う「要件定義」では、現状の課題や目指すべきゴールについて、ユーザー（発注側）とベンダー（開発側）の関係者全員が認識を合わせられるよう、成果物として「要件定義書」というドキュメントを作成します。
要件定義書は、プロジェクトの成否を大きく左右するほどの重要な書類であり、システム開発の成功には絶対に欠かせませんが、特に書式やフォーマットが決まっているわけではないため、どのように書くべきかお悩みの担当者の方も多いことでしょう。
そこで今回は、「要件定義書を作成したいけど、書き方がよく分からない・・・」という方に向けて、要件定義書に記載すべき項目や作成までの流れ、重要なポイントなどについて詳しくご紹介します。
記事の後半では、雛形としてすぐに使える要件定義書のWordサンプルもダウンロードいただけますので、ぜひご活用ください。
目次
１．要件定義とは？
まずは、要件定義の意味について軽くおさらいしておきましょう。
要件定義とは、ベンダー（開発側）がユーザー（発注側）の要望をヒアリングしたうえで、その要望を実現するために必要な機能や要件は何か、誰が見ても理解できるようにまとめる作業のことです。
システム開発の初期段階で行われる作業であり、その後の設計・開発の根幹となることから、プロジェクトの成否やシステムの品質を左右する非常に重要な役割を担っています。
プロジェクトの進行とともに要件定義に立ち返ることも多く、プロジェクトが達成すべき目的を見失わないよう、脱線を防止するための「道しるべ」と考えることができます。
なお、要件定義に関しては、以下の記事にて詳しく解説しておりますので、こちらも併せてご参照ください。
２．要件定義書とは？
要件定義書とは、要件定義にて決定した内容をまとめて文書化したものです。
要件定義の最終的な「成果物」と言えます。
ITの技術的な専門家であるベンダー（開発側）の支援を受けながら、どのようなシステムを開発するか最終的な決定権を持つユーザー（発注側）が主担当となり、責任を持って作成すべきドキュメントになります。
作成した要件定義書は、エンジニア・非エンジニアに関わらず、プロジェクトに携わるすべてのメンバーが読むものであるため、専門知識の少ないメンバーが見ても内容を理解できるような、分かりやすい書き方が求められます。
なお、要件定義書に決まったフォーマットはなく、制作する会社ごとに違いがあるほか、記載内容に修正や変更が入ることもあります。
要件定義書の目的
要件定義書を作成する目的は、ユーザーとベンダーの間で認識の齟齬をなくし、ユーザーの期待に沿ったシステムを確実に開発することにあります。
認識のズレを解消せず、ベンダーの主観で開発が進んでしまうと、ユーザーが望んでいたものとは全く違うシステムが出来上がり、結果的にかかったコストや時間がすべて無駄になってしまう恐れがあります。
こうしたリスクを避け、ユーザーが求めるシステムを限られた期間内に無事完成させるためには、「何のために」「どのような」システムを開発すれば良いのか、具体的にどういった方法でシステムを作っていくべきか、方向性や実現手段を明確にした要件定義書が欠かせないというわけです。
RFP（提案依頼書）との違い
要件定義書と似たような書類として、「提案依頼書（RFP：Request for Proposal）」があります。
RFPは、ユーザーが発注先の候補となる複数のベンダーに対し、自社の現状や解決したい課題、「こんなシステムを求めています」という細かな要望を伝え、ベンダーから具体的な提案を得るために作成するものです。
要件定義よりも前、まだシステム開発を委託するベンダーが1社に決まっておらず、発注を見込んでいる複数のベンダー候補に対し、システムの提案を依頼する際に活用されます。
なお、RFP（提案依頼書）に関しては、以下の記事でも詳しく解説しておりますので、こちらも併せてご参照ください。
RFI（情報提供依頼書）との違い
さらに、RFPとよく似た用語に「情報提供依頼書（RFI：Request for Information）」があります。
RFIは、ユーザーが発注先の候補となる複数のベンダーに対し、会社情報や製品・サービス情報、開発実績、技術情報などの開示を求めるために作成するものです。
RFPよりも前、過去一度も取引したことのないベンダーに関する情報が不足している中、「この会社に依頼して、必要なシステムを本当に開発してもらえるだろうか？」という疑問や不安を解消すべく、各ベンダーの製品・サービス情報を幅広く収集するために活用されます。
なお、RFI（情報提供依頼書）に関しては、以下の記事でも詳しく解説しておりますので、こちらも併せてご参照ください。
3つの文書を作成する順番は？
改めて、RFI・RFP・要件定義書の作成順を整理すると、下図のようになります。
３．要件定義書に記載すべき項目
要件定義書で特に決まったフォーマットが無いとはいえ、とりわけ記載すべき主な項目は次の通りです。
- 概要
- 業務要件
- 機能要件
- 非機能要件
概要
概要には、現状どんな課題を抱えていて、システム化によって何を実現したいのか、開発の目的や背景などについて記載します。
加えて、開発予定のシステムの全体像を示す「システム構成図」や、要件定義書内で使われる専門用語について共通認識を持つための「用語定義」を載せることもあります。
目的や背景を明らかにしておくことで、システム開発の方向性が定まり、関係者全員で認識を合わせることができるほか、もし開発途中で仕様変更などが発生しても、当初の目的に立ち返ってズレなく円滑な合意形成が可能となります。
【目次例】
- システム化の目的：なぜシステムを導入するのか？
- 現状の課題：今どんなことに困っている？
- プロジェクトの背景：プロジェクトが立ち上がった背景は？
- システム構成図：システムの全体像は？
- 用語定義：これから文書内で使う専門用語を簡単に説明
業務要件
業務要件では、現状の業務プロセス（＝As-Is）を分析したうえで、システム導入後の業務はどうあるべきか（＝To-Be）を明確に記載します。
システムを使って実施する業務の範囲と、システムを使わずに実施する業務の範囲を明確に切り分け、フローチャートを活用して業務全体の流れなどを記載します。
【目次例】
- 業務要件一覧：業務内容や実施担当者をまとめる
- 業務フロー図：業務の流れを図でまとめる
- 規模：どれぐらいの規模を想定しているか？
- 時期・時間：業務を行う時期やかかる時間は？
- 場所：どこでシステムが使われるか？
- 指標：業務上ベンチマークとなる指標は？
- システム化の範囲：システム化の対象／対象外となる業務範囲は？
機能要件
機能要件では、システムで具体的にどのような機能が必要になるかを記載していきます。
開発の要となる部分であり、必要だと思われる機能をここでいかに漏れなく洗い出せるかが非常に重要となります。
【目次例】
- 機能一覧：システムに必要な機能は？（要件定義書で大部分を占める）
- 画面：各画面の役割やイメージは？
- 帳票：システムで入力／出力ができるファイルの種類は？
- 情報・データ：データ項目や処理方法は？
- 外部インターフェース：外部システムとの連携方法は？
非機能要件
非機能要件では、機能以外の要件、すなわちシステムのパフォーマンス性能やセキュリティなど、ユーザーの目からは見えにくい「システムの裏側」に関する内容を記載します。
システムを安全・快適に利用していくために必要な要件であり、非機能要件を充実させることで、ユーザーの満足度を大いに高めることができます。
【目次例】
- ユーザビリティおよびアクセシビリティ：システムは誰がどのように使う？
- システム方式：システムの構成は？
- 規模：想定される同時ユーザー数やトランザクション数は？
- 性能：応答時間や処理速度、閾値（しきい値）は？
- 信頼性：稼働率の目標、バックアップ間隔、復旧時間の目安は？
- 拡張性：将来的なユーザー数やデータ量の増加に対応するための設計方針は？
- 互換性：新旧システム間でのデータの互換性は？
- 継続性：システムの冗長性・耐障害性を高めるための方策は？
- セキュリティ：必要とされるセキュリティレベルは？
- 稼働環境：セキュリティを考慮した最適な稼働環境は？
- テスト：システムの品質を確保するために必要なテストの種類・方法は？
- 移行：移行のプロセスやスケジュールは？
- 引継ぎ：引継ぎ範囲や対象者、方法は？
- 教育：運用方法・利用方法の教育について
- 運用：運用体制・運用業務について
- 保守：保守体制について
４．要件定義書作成の進め方
要件定義書の作成は、次の6ステップに沿って進めていきます。
- 現状を把握・分析する
- ユーザーの要求を明確化する
- 要件の優先順位を決める
- システム全体の構成を決める
- 「業務要件」「機能要件」「非機能要件」を定義する
- プロジェクトの予算・スケジュールを設定する
①現状を把握・分析する
まずは、ユーザー側とベンダー側で念入りに情報共有を行い、現在どのようなプロセスで業務を行っており、そこでどのような問題を抱えているのか（＝現状の課題）を明らかにします。
新規開発にせよ、既存システムのリプレイスにせよ、何か現状に課題を感じているからこそプロジェクトが立ち上がったはずなので、現在直面している状況を客観的に分析し、そこに潜む問題点を徹底的に洗い出します。
【課題例】
- 手作業が多く、ヒューマンエラーが多発している
- 情報が1ヵ所に集約されておらず、作業効率が悪い
- 既存システムの性能が低く、処理に時間がかかる
- 業務プロセスの変更に伴い、既存システムで不足する機能が出てきた
②ユーザーの要求を明確化する
現状抱えている課題をすべて洗い出せたら、次は「どのような課題を解決したいのか？」「システムを活用して何を実現したいのか？」（＝システム開発の目的）を明らかにします。
ただし、「この業務のこの課題をこの機能で解決したい！」と、ユーザーが最初から自身のニーズを言語化できているケースは稀であり、ほとんどの場合何が欲しいのか自覚できていません。
そのため、ベンダー側がヒアリングを通じて、ユーザー自身も気付いていない「真の要求」「潜在的なニーズ」を汲み取り、明確化していく作業が重要になってきます。
③要件の優先順位を決める
ヒアリングの結果、ユーザーの要求内容が明確になったら、次はその要求がシステム化によって実現可能なものかどうか、1つずつ吟味していく必要があります。
技術的な制約、プロジェクトの予算・スケジュールなどの都合もあり、ユーザーの要望をすべて一気に叶えることは難しいので、必ず実現したい「必須要件」なのか、できれば実現したい「希望要件」なのか、ユーザーと調整して優先順位を付けていきましょう。
④システム全体の構成を決める
ヒアリングした要求内容を整理し、システム化すべき範囲や内容を確認できたら、開発するシステム全体の概要・構成を決定します。
開発の方向性について、ユーザーとベンダーの間で共通認識を持てるよう、システムの全体像を可視化した「構成図（アーキテクチャ図）」を作成することで、システム全体の概要を視覚的に理解しやすくなります。
⑤「業務要件」「機能要件」「非機能要件」を定義する
続いて、ユーザーの要求内容を「業務要件」「機能要件」「非機能要件」の3つに分けてドキュメントに落とし込んでいきます。
抜け漏れや認識のズレが生じないよう、ユーザーとベンダーの双方でしっかりと合意を取りながら進めていきましょう。
⑥プロジェクトの予算・スケジュールを設定する
最後に、ここまで詰めてきた要件をもとに、プロジェクトの予算・スケジュール・体制（メンバー）などを決めていきます。
無理なスケジュールや不十分な予算、開発人員の不足は、プロジェクトの失敗につながりかねませんので、「三点見積もり法」のような体系化された見積手法をもとに、現実的な計画を立てるようにしましょう。
他にも、ユーザーとベンダー間のコミュニケーション方法や、プロジェクトの進行において考えられるリスクへの対処法なども事前に検討しておくとスムーズです。
５．要件定義書作成時のポイント
分かりやすく質の高い要件定義書を作成するためには、次の5つのポイントを意識するようにしましょう。
- 発注側と開発側で認識をすり合わせる
- 要件の抜け漏れが無いか徹底的にチェックする
- ユーザーの業務やシステムを理解する
- 役割分担を明確にしておく
- 専門用語を使いすぎない
発注側と開発側で認識をすり合わせる
要件定義書を作成する過程では、ユーザー（発注側）とベンダー（開発側）でお互いの認識を統一することが何よりも重要です。
要件定義の段階でユーザーとベンダーの間に認識の齟齬があると、そのギャップを埋められないまま開発が進み、結果としてユーザーの期待に沿わないシステムが出来上がってしまい、修正作業のために余計なコストや時間がかかることになります。
このような事態を防ぐため、要件定義のフェーズでは定期的にミーティングを開催して認識のすり合わせを繰り返し行い、双方が納得のいく形で出した結論を要件定義書に記述するようにしましょう。
要件の抜け漏れが無いか徹底的にチェックする
要件に漏れがあると、そもそもシステム設計・開発・実装の対象とならないので、もし後から「この機能が足りない」といった問題が発覚すると、大きな手戻りが発生してかなりのコストや時間が無駄になります。
そのため要件定義の際は、要件の内容に抜け漏れが無いか入念にチェックを行うようにしましょう。
加えて、事前に要件漏れの防止に役立つフレームワークを把握しておくと、さらなるリスク軽減につながります。
【要件定義に役立つフレームワークの例】
- EA（エンタープライズアーキテクチャ）：発注側のニーズ分析に役立つ
- 5W2H：情報の整理・ヒアリング精度の向上に役立つ
- RASIS（レイシス）：非機能要件の定義に役立つ
- ER図：データの構造・関係性を全体的に把握できる
- DFD：データの流れを可視化し、システムに必要な機能を洗い出せる
ユーザーの業務やシステムを理解する
より精度の高い要件定義書を作成するには、ユーザー（発注側）の業務フローや既存システムに関する理解が必要不可欠です。
RFP（提案依頼書）をはじめ、事前情報となる資料を十分に読み込んだり、業務担当者やシステム管理者へのヒアリング調査を複数回行うなどして、ユーザーの業務やシステムに関する理解を深め、問題点の把握に努めることで、新しいシステムに盛り込むべき機能を考案しやすくなります。
役割分担を明確にしておく
要件定義書をスムーズに作成するためには、ユーザーとベンダーで役割分担を明確に決めておくことも大切です。
役割分担を曖昧なままにしておくと、元々ユーザーが行わなくてはならないタスクをベンダー側が引き取って作業するなど、やらなくてもよい仕事が増えて本来の業務に支障をきたしてしまう可能性があります。
そのため、WBSなどを活用してすべてのタスクに担当者と期限を割り振り、「誰が」「いつまでに」「何を完成させるのか」はっきりしていないタスクが残らないよう注意しましょう。
専門用語を使いすぎない
要件定義書は、ユーザーとベンダーがシステムに必要な要件について共通認識を持つための書類であり、エンジニア・非エンジニアを問わず、プロジェクトに携わるすべての人が目を通すものです。
そのため、専門知識の少ないメンバーが見ても内容を十分に理解できるよう、難しすぎる言葉やIT業界でしか通じないような専門用語は極力使わずに、誰が読んでも分かりやすい文章を書くことを心がけましょう。
さらに、業務フローなど文字だけではイメージしにくい部分に関しては図解を活用したり、どうしても専門用語を使う必要がある場合は注釈を加えたりするなど、理解促進に向けて工夫を凝らすのも効果的です。
６．要件定義書のよくあるQ＆A
最後に、要件定義書に関してよく挙がる疑問点を2つご紹介します。
要件定義書は誰が作る？
要件定義書は、ITの技術的な専門家であるベンダー（開発側）の支援を受けながら、どのようなシステムを開発するか最終的な決定権を持つユーザー（発注側）が主担当となり、責任を持って作成すべきドキュメントです。
よく「要件定義書は開発側であるベンダーのSE（システムエンジニア）が作成するもの」と言われますが、2018年に経済産業省が「2025年の崖」の危機を訴えたDXレポートでは、下記のように指摘されています。
- 我が国においては、要件定義から請負契約を締結する（＝要件定義をベンダー企業に丸投げする）ケースも少なくないが、これは何を開発するかをベンダー企業に決めてくれと言っていることと同じである。
- 要件の詳細はベンダー企業と組んで一緒に作っていくとしても、要件を確定するのはユーザー企業であるべきことを認識する必要がある。
つまり、
「要件定義書は、システム化について最終的な責任を持つユーザーが主体となって作成すべき文書だが、ユーザー側の業務担当者はシステム開発に精通していないことが多く、自力で作成を進めるのは難しいため、ITの豊富な専門知識を持ったベンダーが “支援” する立場として要件定義書の作成に携わる」
というのが、本来あるべき理想の姿といえます。
要件定義書をExcelやPowerPointで作ってもよい？
要件定義書に決まったフォーマットは存在しないため、Word・Excel・PowerPointのいずれを使って作成しても問題はありません。
要件定義書を作成する目的は、「ユーザーとベンダーで要望をすり合わせ、開発するシステムのイメージを統一すること」「要望を誰が読んでも理解できるように分かりやすく文書化すること」であり、この目的さえ達成できるのであれば、基本的に使うツールは何でもOKです。
ただし、使用ツールに関して社内で規定がある場合は、そちらに従いましょう。
７．まとめ －要件定義書のWordサンプルダウンロードはこちらから
いかがでしたでしょうか？
冒頭でもお伝えした通り、今回は「要件定義書の書き方が分からない」という方に向けて、本記事の内容と連動した要件定義書のWordサンプルをご用意しました。
実際のプロジェクト内容に合わせて適宜カスタマイズしていただき、要件定義書の作成にお役立ていただければ幸いです。
なお、要件定義書の作成に向けて支援を必要とされている企業様向けに、当社コンピュータマネジメントでは情シス支援サービス「ION」を行っております。
以下リンクより情シス支援サービス「ION」に関する資料を無料でダウンロードすることができますので、興味のある方はぜひチェックしてみてください。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
