要件定義の成果物とは？必要な項目と作成のポイントをわかりやすく解説

こんにちは。マニュアル作成・ナレッジ共有ツール「NotePM」ブログ編集局です。

システム開発の要件定義に臨むにあたって、「何を成果物として提出すべきなのだろう」と迷っている方もいるかもしれません。
要件定義においては、原則として要件定義書を成果物として作成する必要があります。要件定義書は、システム開発全体のゴールや具体的な開発工程についてまとめた重要な資料です。スムーズに開発プロジェクトを進めるためにも、事前に要件定義書の項目や内容を正しく理解しておくことが不可欠といえるでしょう。

そこで今回は、要件定義の成果物である要件定義書についてわかりやすく解説します。要件定義書に記載すべき項目や作成のポイントも紹介しますので、ぜひ参考にしてみてください。

関連記事：要件定義の進め方とは？必要なプロセスと効率良く進めるポイントを解説

要件定義の成果物とは？

要件定義のプロセスでは、具体的にどのようなドキュメントを成果物として提出すべきなのでしょうか。
本章では、要件定義の成果物とその提出方式について解説します。

要件定義の成果物は「要件定義書」

要件定義の工程で提出する成果物は、「要件定義書」という資料です。要件定義書とは、Webシステムやアプリケーションの開発において、開発の目的やゴール、予算、スケジュール、実装すべき機能などを網羅的にまとめたドキュメントのことをいいます。

要件定義書の作成にあたっては、開発チームが顧客と綿密に打ち合わせをし、現行システムの課題や新しいシステムに対する要望などを細かくヒアリングすることが一般的です。つまり、要件定義書には、「顧客側のかなえたいこと」と「それを実現するための道筋」がわかりやすくまとめられています。関係者間で共通認識を持つためにも、要件定義書は非常に重要な資料といえるでしょう。要件定義書が抜け漏れなく作成されていることで、以降の開発工程もスムーズに進みやすくなります。

要件定義書の提出は、「本紙＋別紙」でも可能

要件定義書は、1冊のドキュメントとしてまとめて提出します。ただし、フローチャートや図解などを作成する際は、本紙の流れに収まらない場合もあるでしょう。その際は、「別紙」という形で本紙に添えて提出することが一般的です。

また、要件定義書の内容や項目は、プロジェクトによって大きく異なります。開発規模が大きくなれば、そのぶん要件定義書で定義すべき内容も増えるため、項目数が非常に多くなることも珍しくありません。システムの規模や顧客側の要望に応じて、要件定義書の項目数は臨機応変に調整するようにしましょう。

関連記事：要件定義書テンプレート（書き方とサンプル例）

マニュアル作成・ナレッジ管理が浸透するサービス ⇒「NotePM」
NotePMのPDF資料をダウンロード ⇒ こちらから

要件定義の成果物（要件定義書）に必要な項目

要件定義の成果物である要件定義書には、具体的にどのような内容を盛り込めばいいのでしょうか。
本章では、要件定義書の代表的なページ構成と、そこに記載すべき主な項目について解説します。

プロジェクト概要

要件定義書のなかの「プロジェクト概要」とは、開発プロジェクトの全体像を端的にまとめたページです。具体的には、システム開発のスケジュールや予算、必要な人員数、開発場所などについて記載します。開発プロジェクトのゴールや進め方について、顧客と開発者が共通認識を持つための項目といえるでしょう。

＜プロジェクト概要で記載すべき主な項目＞
◆用語の定義
要件定義書内で使われる主な専門用語の意味を解説します。何度も使用する単語について、関係者間で認識のズレを起こさないための項目です。

◆システム導入の目的
旧システムの課題点や社会の動向も踏まえ、新システムの開発目的を説明します。例えば、「旧システムの改善によるユーザーの利便性向上」「新システムの導入による業務効率化」などが代表的です。

◆作業スケジュール
開発プロジェクト全体の大まかな日程を説明します。設計・テスト・運用・保守などの工程も含めて、フローチャートで記載することが一般的です。

業務要件

業務要件とは、システム化すべき業務の内容について定義するページです。具体的には、現在顧客が現場で実施している業務の中身やフロー、対応件数、エンドユーザー（利用者）とのかかわり方などについて定義します。「どの範囲までシステム化すべきなのか」「システム化することで業務がどう変わるのか」を明瞭にするための項目といえるでしょう。

＜業務要件で記載すべき主な項目＞
◆業務概要
顧客の該当部署が担当している業務について、事業モデルと商流を記載します。システム化の対象となる業務の全体像を説明するための項目です。

◆ユースケース図
ユースケース図とは、エンドユーザーの立場から見たシステムの挙動を示す図のことです。ユーザーがシステムへアクセスしてから目的を果たすまでの流れを、端的に説明します。

◆As-IsとTo-Beの業務フロー
As-Is（現行システム）とTo-Be（新システム）、それぞれの業務フローを説明します。新システム導入後の業務の変化について、明示する項目です。

機能要件

機能要件とは、システムに実装する機能について定義するページです。システムによって機能は大きく異なりますが、一例として画面（ユーザーインターフェース）の使いやすさや出力できる帳票の種類、権限設定の有無、データの流れ、外部との連携可否などが挙げられます。システムのコアとなる部分なので、顧客との綿密なすり合わせのもとで記載する必要があるでしょう。

＜機能要件で記載すべき主な項目＞
◆機能一覧
システムに実装すべき機能の一覧を記載します。例えば、「アカウント発行機能」「決済機能」「申請機能」などの機能名を列挙し、それぞれの概要を書くことが一般的です。

◆帳票要件
システムで出力可能な帳票の種類と出力形式について説明する項目です。人事給与システムを例にすれば、「給与明細」や「源泉徴収票」などが挙げられます。

◆情報・データ要件
システム上で取り扱う情報の種類について記載する項目です。行政システムを例にすれば、「区民の氏名・住所・電話番号・支払情報」などが挙げられます。

非機能要件

非機能要件とは、システムの中核機能とは別に、実装すべき性能を定義するページです。例えば、システムの管理しやすさを意味する「運用・保守性」、新システムへの移行しやすさを示す「移行性」、情報の堅牢性や安全性を意味する「セキュリティ」などについて定義します。非機能要件は必須機能ではないものの、システムの使いやすさや得られる成果に大きな影響を与えるため、十分な検討が必要です。

＜非機能要件で記載すべき主な項目＞
◆ユーザビリティ要件
ユーザビリティ要件は、エンドユーザーの利便性（UI/UX）を高めるための要件です。例えば、画面の見やすさやヘルプのわかりやすさが挙げられます。

◆アクセシビリティ要件
アクセシビリティ要件は、エンドユーザーの操作性を高めるための要件です。例えば、複数言語への対応やスマートフォンへの対応などが代表例として挙げられます。

◆セキュリティ要件
機密情報を扱うにあたり、遵守すべき法律や必要な性能、障害対策について記載します。「脆弱性対策」「不正監視」などのカテゴリにわけて書くとわかりやすくなるでしょう。

要件定義の成果物（要件定義書）を作成するポイント

要件定義の成果物である要件定義書を作成する際は、どのようなことを意識すべきなのでしょうか。
本章では、わかりやすい要件定義書を作成するための必須ポイントについて解説します。

専門知識がなくても読めるように記載する

必ずしも顧客の全員が、ITに詳しいとは限りません。そのため、要件定義書を記載する際は、できるだけ専門知識がなくても読めるように工夫することが大切です。例えば、なるべく平易な表現を使ったり、冒頭で用語の解説を充実させたりするのも一案でしょう。誰にとっても理解しやすい要件定義書を作成することで、関係者間でより明確な共通認識を持てるようになります。

視覚的なわかりやすさを意識する

要件定義書は正確に書く必要があるため、どうしても文字が多くなりがちです。しかし、読み手にスムーズな理解を促すには、視覚的なわかりやすさを意識することも重要です。具体的には、図解やグラフ、チャート、箇条書きなどを積極的に活用します。こうした視覚的な表現を使うことで、関係者が内容をイメージしやすくなり、共通認識を得やすくなるでしょう。

要件定義の成果物作成に役立つ社内wikiツール「NotePM」

要件定義書の作成を効率化できる代表的なツールの一つに、社内wikiツールの「NotePM」があります。

NotePMは、豊富なフォーマットに沿って要件定義書やユースケース図などの資料をシンプル操作で作成でき、ツール上から共有できる“社内版ウィキペディア”です。高機能エディタと作図（画像編集）機能があるので、読み手にとって視覚的にわかりやすい要件定義書を作成できます。さらに作成した要件定義書はツール上からプロジェクトメンバーへすぐに共有できるため、開発チーム間の情報共有もスムーズになります。

要件定義書の作成・共有を円滑にするためには、社内wikiツールの「NotePM」が最適です。

マニュアル作成・ナレッジ管理が浸透するサービス ⇒「NotePM」
NotePMのPDF資料をダウンロード ⇒ こちらから