システム開発において、要件定義書の作成は大切な作業です。
きちんと要件定義書が作成ができなければソフトウェアの開発が上手く進まず、思うような開発ができません。
しかし、「要件定義書とは？」「要件定義書はどうやって書けばいいの？」など疑問を感じた人は多いでしょう。
そこで今回は、ソフトウェアの開発に欠かせない要件定義書について詳しく解説していきます。
要件定義書とは？
一般的には要件定義書とは、発注者の要望とその要望を叶える具体的なプロセスを「文書」の形式でまとめたもの です。
私たちがソフトウェアやシステム開発を行う目的は、クライアントや社内での要望・課題をソフトウェアやシステム開発を通して実現・解決することです。そのシステム開発の前段で「要件定義」をし、その内容を記した「要件定義書」を作成します。大規模開発においては特に必須のドキュメントです。
開発手法によってはいわゆる「要件定義書」を作成しない場合もあると思います。しかし、どんなプロジェクトでもそれに匹敵するようなアウトプットを作成する場合がほとんどだと思います。発注者にこれからどんな開発をしていくのか、要件定義段階で認識を合わせ、お互いの解像度を高める本質的な目的には変わりありません。 そこで、Jiteraがこのフェーズで提供する文書の例もご紹介します。
Jiteraが提供する要件定義フェーズのアウトプット 株式会社Jiteraでは、要件定義書に以下のファイルを含めることが大半です。
- 業務フロー図（要求整理に含まれる倍もあります）
- ユースケース
- デザインファイル（画面設計）
- 画面一覧
- 画面遷移図
その他には、設計工程に近くなりますが、
- 辞書（用語定義）
- データ定義
- コーディングガイドライン
- セキュリティガイドライン
などを含めることもあります。 この場合は、設計フェーズなどで
- ER図作成
- 外部インターフェイス設計（API定義書）
- テストケース作成
- インフラ構成図
を作成しています。
要件定義とは？
要件定義とは、システム開発や新サービスの初期段階で、そのシステムに必要な機能や条件、つまり要件を明確にする作業です。
より具体的に言えば、そのシステムに期待されている要件
- 達成条件や目標となる指標
- 必要な機能要件
- 必要な非機能要件
- UIの使いやすさや拡張性、性能やセキュリティ性など
- 制約事項や規則
を明確に洗い出し、システムの全体像を理解し、関係者同士の認識を共有する工程になります。
- 顧客のニーズを収集し、
- ニーズに沿ったシステムの機能や制約を明確化し、
- それぞれを具体的な機能要件として文章化（要件定義）し、
- 開発関係者全員に、システムの動作や機能に焦点を当てた仕様書やユースケースを共有する
という4段階を経て初めて、顧客のニーズに沿ったシステム開発が行えます。
逆に、もしシステムの要件が十分洗い出されていない場合、
- 期待と異なるシステムが開発され、開発コストが無駄になる
- 何度も要求が変更され、スケジュールが延々と遅延する
- コストは増加する反面、求めている品質には届かず、顧客からの信頼を失う
といった多くのリスクが発生します。
要件定義に十分なコストを割くことで、開発するシステムに必要な機能や特性を明確に整理し、効率的な開発が可能となります。
要件定義書の作成目的
要件定義書の目的は、発注側の課題解決のためにそのプロジェクトの目的、それを踏まえて何のために何をどのように開発するのかを明確にすることです。これが、最終的な成果物への道標となります。加えて、このプロジェクトに関わるすべての人が読むことになります。したがって、非エンジニアの方でも理解できるよう、専門用語は多用せず、わかり易い言葉選びもポイントになります。
また、開発中に「仕様変更・機能追加」をよく耳にしますよね。 そんな時、お互いの合意のもとに作成された要件定義書があれば、プロジェクトに関わる全ての人が同じ方向を向くことができるため、方向性の大きく異なる仕様変更・機能追加を未然に防ぐこともできます。
クライアントの要望と期待を明確化
要件定義書の最大のメリットは、クライアントのニーズを開発チーム全員が理解し、システムに反映できることです。
開発を行う前には、クライアントとのコミュニケーションを通じて、プロジェクトの目的や要求を収集し、本当に欲しいものを整理します。
ですが、この「たんなる顧客からの要望」と「具体的なシステム」の間には、多くのギャップが存在しています。
この「集めた要求」を「開発者全員が認識共有できる具体的な要件」、つまり要件定義書にすることで初めて、クライアントのニーズに沿ったシステムが作れるようになります。
開発範囲を限定
文書化することで、プロジェクトの開発範囲が明確に整理されることも重要な利点と言えるでしょう。
システムを開発する際には、プロジェクトに「何が含まれていて何が含まれていないか」が非常に重要となります。
どこまで開発すればいいのかわからなければ、無駄な機能を開発し、予算やスケジュールが超過するリスクが常に付きまとうからです。
要件定義書によってプロジェクト範囲が明確になることで、本当に必要とされているシステムの範囲と方向性が開発チームに共有されます。
品質の基準を設定
要件定義書は、開発する要件だけでなく、達成すべき品質基準も定義します。
開発作業やテストの際に設ける品質基準が早期に明確化されることで、
- 一貫性の確保による品質の向上
- 基準の明確化によるバグや顧客トラブルの早期発見
- 効率的なプロジェクト進行と予算の管理
といった様々なメリットが得られます。
要件定義書と提案依頼書（RFP）、要求定義書、要求仕様書の違い
システム開発では、主に以下のような文書が発注側と開発側で交わされ、お互いの認識のすり合わせに使われます。
「要件定義書」と似て非なるドキュメントもありますので、簡単に違いを記載します。
| 作成者 | 目的・役割 | |
| 提案依頼書（RFP） | 発注側 | 外部業者からの提案を求めるために作成する文書 |
| 要求仕様書 | 発注側 （自社開発の場合・開発側が作成する場合も） |
発注側の要望をシステムベースの要件や機能としてまとめた文書 |
| 要件定義書 | 開発側 （開発者自信が作成するのが一般的） |
発注側と開発側の認識を合わせるための文書 |
| 要求定義書 | 発注側 | 発注者のシステムに組み込んで欲しい具体的な仕様や機能について記載する文書 |
提案依頼書（RFP）
提案依頼書とは、外部委託を検討する際に外注先に送る「こんなシステムを求めています」という概要をまとめた文書です。
主にシステムを求めている発注側が、ベンダーからの提案を得るために作成します。
提案依頼（Request for Proposal）の頭文字を取って、RFPと略されることが多いです。
当たり前の話なのですが、何かを外部委託する際には、発注側の考えを受注側に明確に伝える必要があります。
「こういうシステムを求めているのだが、いつまでに、どのくらいの予算になるか」という希望を出されて初めて、受注側は具体的な提案を行う事ができます。
企業がシステムの外注先を選定するために、候補となるベンダーに「具体的な提案」を依頼するための書類、それがRFPです。
要求仕様書
要求仕様書は、発注側がシステムに求めている詳細な要求や仕様を記述した文書です。
要求仕様書は、開発するシステムの詳細な要求内容を開発チームやベンダーが理解することを求めて作成します。
自社の要望をより具体的なシステムベースの要件や機能に整理し、求めているシステムをより深く理解してもらうための書類で、
- システムや製品の機能要件
- 性能要件
- 非機能要件
が記載され、発注側と開発側のシステムに対する認識をすり合わせるために使用します。
要件定義書
要件定義書は、前述の通りシステム開発に必要な機能や要件を明確に定義した文書です。
システムを開発するチームが、プロジェクトの目的や範囲を明確に共有するために作成します。
-
- プロジェクトが達成すべき成果
- 開発範囲
- 顧客に提供するべき具体的な機能
- プロジェクトのロードマップや予算
- 個別の作業やタスク
などが記載されており、目標が明確化されることで、チームが一丸となってシステムを開発することができます。
要求定義書
要求定義書は、顧客からの要求を明確に定義した文書です。
顧客の要望やニーズを収集し、整理しておくことで、顧客の求める重要な要件を見落とさないようにします。
あくまでも顧客からの希望を書いたものであり、実際のシステムにどう組み込むかは要件定義書に記述されますが、システムの大枠をブレさせないための重要な書類と言えるでしょう。
要件定義書の要件とは？
要件定義書の「要件」とは、発注側からの要求を実現するために、どのような仕様のどのような機能を開発すればいいかを技術的な視点で捉え直したもののことを言います。 発注者からの「要求」だけでは開発に進むことはできません。
では、この「要求」をどのようにして「要件」に落とし込み、「要件定義書」としてアウトプットするのでしょうか？次は要件定義書作成の流れをみていきます。
要件定義書作成の基本的な流れと書き方
要件定義書作成の流れを紹介いたします。どんなプロジェクトでも同じような流れになります。
※ただし、システム開発とソフトウェア開発では確認するニーズやプロセスが異なることも多いです。
双方の違いについては、別の記事で詳しく紹介していますので参考にしてみてください。
1. 要求のヒアリング（要求定義）
まずは、クライアントや社内のシステム発注者から要望を聞き出すためのヒアリングを行います。開発側は、発注者の抱える課題の潜在的なニーズも汲み取り、確認できるとベストです。以下を中心にヒアリングを進めましょう
- 現状と抱えている課題の確認
- システム開発の目的
- ソフトウェア・システム開発でどのように課題を解決したいのか
- 開発後のイメージ
わからないことは都度発注者に確認することで、認識の齟齬を最小限に抑えることができます。 初期段階の齟齬は、工程が進むにつれどんどん大きくなっていくものです。十分に注意が必要です。
2. ヒアリング内容を要件に落とし込む
1.で行ったヒアリングの内容を整理し、システム全体の構造から要件まで決めていきます。
- 現状と開発後の変化
- どのような課題をどのような機能で解決するのか
などにフォーカスして以下の要件をまとめてみましょう。
2-1. 業務要件をまとめる
業務要件では、今回のプロジェクトの目的・背景・狙いを記載したり、ビジネスプロセス図や業務プロセス（フロー）図などをフローチャートを用いて全体の構造を表現します。 発注者と認識のズレなどが生じないよう、しっかりと確認していきましょう。
Jiteraでは、ほとんどのお客様にはこの時点でワイヤーフレームの作成も行い、ソフトウェアの全体像がわかりやすいアウトプットを行っております。また、このフェーズでデザインを作成する場合もあります。
2-2. 機能要件をまとめる
機能要件とは、課題解決にあたって、どのような機能（開発）が必要になるのかを記載します。 一覧を作成したら、それらに必須要件と希望要件を分けたりするなど優先順位をつけていきます。この優先順位も発注側との認識のズレがないようにしっかりと合意を取りながら進めたい部分です。
2-3. 非機能要件をまとめる
非機能要件とは、先述の機能要件以外の内容を記載する項目です。例えば、性能・拡張性、運用・保守性、セキュリティ、システム環境・エコロジーの観点での要件をまとめたものです。
2-4. 工数見積・スケジュールを出す
これまでの要件を通して、成果物を納品するまでの工数・スケジュールを立てます。
3. 要件定義書を書く
ここで初めて「要件定義書」の材料を揃えることができました。この材料を章立てでまとめます。記事の最後にご紹介するサンプルもご参考ください。
また、別の記事で開発期間やコストの目安について詳しく紹介しています。
要件定義書作成を終えたら
要件定義書を書き終えたら、発注者らと齟齬がないか綿密にチェックを行います。要件の抜け漏れや、認識の齟齬をなくすように、お互いに疑問に思ったことはその場で解決しましょう。時間の制約などもありますが、できる限りお互いの認識を合わせて、気持ちよく開発に入りましょう。
より良い要件定義書のために気をつけたいポイント
要件定義書の構成
構成に関しては、ポイントをカテゴリごとにまとめて、章立てで記載するのが一般的です。章立てで作成することによって、どこに何の情報が書いてあるのかがわかります。目次も忘れずに作成しましょう。 記事の最後にサンプルがあるので、こちらもご参考になさってください。
非エンジニアもいる！平易な文章を心がけて
プロジェクトに参加しているメンバーは、開発に明るい方ばかりではありません。そういった方でも、要件定義書を読んで今後のプロジェクトの展開を意識してもらえるようにしましょう。
わかりやすさが一番！図を適切に使用する
様々な要件を文章で表現することも大切ですが限界があります。そんなときは、図解することも検討してみましょう。文章よりも図の方が把握し易い場合もあります。 例えば、画面内の機能を要件定義で文字で記述することが一般的です。しかし、そういったものは図を添えられると発注者もイメージがつきやすいでしょう。
打合せには適宜ステークホルダーにも参加してもらう
システム、ソフトウェア開発において、時間の制約がないプロジェクトは殆どありません。重要な意思決定を都度持ち帰って承認を…となると、時間が余計にかかってしまいます。 意思決定が必要になりそうな打合せには、予め意思決定者に同席してもらいましょう。
Jitera では、週に2-3回、1回1-2時間でお客様とお話しする機会を設けています。ほとんどがオンラインでの開催になりますが、たまにオフラインで開催するとお客さまとの距離も一段と縮まり、その後の顧客関係にも良い影響があります。
要件定義書の必要項目は？Jiteraの要件定義書サンプル
先述の要件定義書作成の基本的な流れでご紹介した内容をこちらのテンプレートにまとめてみました。ぜひご活用ください。
Jiteraの要件定義書構成サンプル
要件定義書は誰が作るのか？
要件定義書は概ね開発側が作成することが多いです。
理由は、発注者は必ずしも開発に十分明るいわけではないからです。 開発側でも、開発自体に深い理解のある人が対応することがほとんどです。例えば、エンジニア経験があったり、開発の理解があるPMやシステムエンジニアが要件定義書を作成します。
要件定義を適切に行うために必要なスキル
コミュニケーション能力
発注者から要件を引き出し、またシステム開発観点で潜在的な問題やニーズを引き出すことも時には求められます。また、非エンジニアの方に、わかりやすく技術的な話をする機会も多くなります。不明点をなるべく少なく、解像度の高い要件定義書を作成・合意形成するためにはコミュニケーション能力は不可欠です。
システムの全体像や成果物をイメージできる能力
要件定義書を作成していく上で、システム全体のイメージができていると、「できる・できない」「時間がかかる・かからない」の判断も迅速に行うことが出来ます。それによって、合意の形成も時間をかけずに済みますし、理由も説明できるので発注者側の理解も同時に得られます。
納品までの工数・スケジュール算出能力
各要件を洗い出し、それらに必要な工数とリソースの見積もりが必要になってきます。この見積もりの集大成がスケジュールとなり、納期を決定できますし、費用や予算も算出できます。これらの見積もり能力も重要になってきます。
システムエンジニアの役割
先述したように、システムエンジニアは発注者とプログラマーとのパイプ役となっていることがわかります。これは非常に重要な役割です。また、開発全体のスケジュール管理も担うことも多いと思いますので、常にプロジェクト全体を見渡しつつ、実装作業の進捗にも気を配る必要があります。
要件定義書はソフトウエア開発の大きな道標
要件定義書は、発注者と開発側の合意文書です。なにかあった時には、要件定義書に立ち返って検討します。要件定義をしっかり行って、システム・ソフトウェア開発を成功に導きましょう！
メールマガジン登録
