要件定義の成果物一覧と中身｜誰が承認していつ使うかの表つき

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義の成果物とは？まず全体像をつかもう

要件定義（RD：Requirements Definition）は、システムで何を実現するかを関係者で決める工程です。

そこで決めた内容を書き残したものが、要件定義の成果物なんです。

『要件定義書を一冊作れば終わりでは？』と思う方もいるかもしれませんね。

実は、要件定義書の本文だけに全部を書き込むと、何十ページにもなって誰も読まなくなります。

そこで、図にしたほうが分かる流れは業務フロー図に、番号で管理したい機能は機能一覧に、と分けて作るのが一般的です。

要件定義の成果物の一覧

よく作られる成果物を並べると、次のようになります。

会社ごとに呼び方や分け方は違うので、社内の過去の案件で使われた様式があれば、それに合わせるのが近道です。

要件定義書そのものの役割を先に知りたい方は、要件定義書とはもあわせてどうぞ。

成果物は「要件定義の後」に使われる

成果物は、作った時点ではなく、その後の工程で読まれて初めて役に立ちます。

例えば、基本設計では機能一覧と画面一覧が設計の出発点になります。

受入テストでは、要件定義書に書いた条件を発注側が一つずつ確かめます。

だからこそ、「後で読む人が困らないか」を基準に、どの成果物を作るか決めてみてください。

成果物ごとの中身を、例で見てみましょう

ここでは、架空の「社内の契約書管理を、紙の台帳からシステムに移す場合」を例にします。

契約書の受付、保管、更新期限の確認までを扱う、小さめの案件です。

要件定義書は「目次」の役割も持つ

要件定義書は、ほかの成果物を束ねる本体です。

本文には要点だけを書き、細かい一覧は別の資料に分けて「別紙参照」とつなぐと読みやすくなります。

書き方そのものは、要件定義書の書き方で章ごとに詳しく紹介しています。

業務フロー図は、今と後の2枚を並べる

業務フロー図は、契約書が届いてから保管されるまでの流れを、部署ごとのレーンに分けて描く図です。

今の流れ（As-Is）と、システム導入後の流れ（To-Be）の2枚があると、何が変わるのかがひと目で分かります。

「営業部が受け取った契約書を、法務担当に回す時はどうしていますか」
「社内便で送って、法務担当が台帳に手で書き写しています」

こんなやり取りで出てきた手順を、そのまま図の箱にしていくイメージです。

描き方のコツは、要件定義の業務フロー図の書き方でまとめています。

機能一覧には番号を振る

機能一覧は、システムが持つ機能を1行1機能で並べた表です。

番号があると、レビューや変更の場面で「どの機能の話か」がすぐに伝わります。

画面・帳票・データの一覧は「粒度」をそろえる

画面一覧や帳票一覧、データ項目一覧は、要件定義では「何があるか」までで十分なことが多いです。

ボタンの配置や項目の並び順は、基本設計で決める話なんですね。

例えば契約書の登録画面なら、「相手先名、契約期間、更新期限、保管場所を入力する」までを要件定義で決めておきます。

非機能要件一覧は、項目をそろえてから考える

非機能要件は、「どのくらいの品質で動くか」を決めたものです。

IPAの「非機能要求グレード」では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて考えます。

各項目のレベルを0〜5の段階から選ぶ方式なので、抜け漏れの確認にも使えますよ。

成果物ごとに「誰が承認し、いつ使うか」を決めておく

成果物を一覧にした時、意外と抜けやすいのが承認者です。

『全部、プロジェクトの責任者に見てもらえばいいのでは？』と思いますよね。

ただ、業務の流れは利用部門の責任者でないと判断できませんし、性能の目標は運用の担当者でないと決められません。

成果物ごとに、中身を判断できる人に承認してもらうのが自然です。

承認者と使う場面の一覧表（例）

架空の契約書管理の案件で、成果物ごとの承認者と使う場面を書くと、次のようになります。

承認の形は、押印や電子承認でも、議事録に「承認」と残す形でも構いません。

大事なのは、あとで「誰がいつOKを出したか」をたどれることなんです。

使う場面から逆算すると、作りすぎを防げる

この表を作っておくと、「この資料、誰も使わないのでは」という成果物にも気づけます。

例えば、外部のシステムとつながない案件なら、外部インターフェース一覧はいりません。

逆に、紙の台帳からデータを移すなら、データ項目一覧はかなり大事になります。

システム開発・業務要件定義・アジャイルで成果物はどう違う？

一口に要件定義の成果物といっても、案件の種類によって重みが変わります。

『うちの案件だと、どこまで作ればいいんだろう』と迷う方も多いはずです。

システム開発の要件定義で作る成果物

システム開発で、開発会社に作ってもらう場合は、ここまでに紹介した成果物がひととおり出てきます。

システム要件定義の成果物としては、機能一覧、非機能要件一覧、外部インターフェース一覧の比重が大きくなります。

開発会社と契約を結ぶ時の根拠にもなるので、範囲や品質の条件は文章で残しておくと安心です。

なお、受託開発では要件定義を準委任契約、設計以降を請負契約に分けて契約する例もあります。

その場合、要件定義の成果物が次の契約の前提になるので、範囲の書き方がより大事になりますね。

業務要件定義で作る成果物

業務要件定義の成果物は、業務フロー図と業務一覧が中心です。

業務要件定義は「業務をどう変えるか」を決める段階なので、システムの画面より先に、誰がいつ何をするかを固めます。

業務要件の決め方そのものは、業務要件定義とはで詳しく紹介しています。

アジャイル開発の要件定義で作る成果物

アジャイル開発では、短い期間で作って確かめることを繰り返します。

そのため、最初に分厚い要件定義書を作るより、プロダクトバックログに要件を並べて、少しずつ詳しくしていくことが多いです。

要件は、ユーザーストーリーという形で書かれることがよくあります。

「〈利用者〉として〈目的〉のために〈機能〉がほしい」という形の文です。

例えば「法務担当として、期限切れを防ぐために、更新期限の近い契約を一覧で見たい」のように書きます。

ただし、アジャイルでも非機能要件や外部とのつなぎ方は、早めに決めておかないと後で困ります。

詳しくはアジャイル開発の要件定義を読んでみてください。

成果物の「品質」をどう確かめる？レビューのコツ

成果物を作り終えると、ほっとしますよね。

ただ、ここで一度立ち止まって、中身の品質を確かめておくのがおすすめです。

良い要件の性質で見直す

国際規格のISO/IEC/IEEE 29148では、良い要件の性質として、必要である、あいまいでない、検証できる、実現できる、矛盾しない、一つのことだけを言う、追跡できる、といった点が挙げられています。

全部を一度に完璧にするのは難しいので、まずは「あいまいでない」と「検証できる」の二つから見てみましょう。

成果物どうしの食い違いを探す

成果物を分けて作ると、資料どうしで内容がずれることがあります。

例えば、業務フロー図には「営業部も契約書を登録する」とあるのに、機能一覧の使う人が法務担当だけになっている、といったずれです。

この確認をしておくと、基本設計に入ってからの手戻りがぐっと減りますよ。

よくある相談に答えます

要件定義の成果物について、よく寄せられる相談を要約してお答えします。

結論から言うと、要件定義では「業務として困らない水準」を目標として決めます。

例えば「月末に利用者が集中しても、登録の操作が業務に支障のない時間で終わること」を、具体的な目標値とあわせて非機能要件一覧に書きます。

基本設計では、その目標をどの構成で満たすかを考え、詳細設計ではプログラムの作りに落とします。

工程ごとに「決めること」が違うと考えると、ぐっと分かりやすくなりますよ。

アジャイルにしても、「何を作るか」を決める作業そのものは無くなりません。

決める時期と、残す成果物の形が変わるだけなんです。

プロダクトバックログの優先順位を決めるのは発注側の役割なので、決める人が決められない状態だと、アジャイルでも揉めることがあります。

要件定義の工程では、成果物そのものが品質の記録になります。

「どの成果物を作るか」「誰がレビューし、誰が承認したか」「指摘をどう直したか」を残しておくと、工程の品質を説明しやすくなります。

先ほどの承認者の表に、レビューの日付と指摘の件数の欄を足すだけでも、立派な記録になりますよ。

よくある質問

まとめ

成果物の形をすぐに整えたい方は、要件定義書の例・テンプレートから使えそうな様式を探してみてください。

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義書とは？中身と読み手別の見方、システム要件定義書との関係

要件定義書の例とテンプレート｜各章の記入例をそのまま使える形で