中小企業の業務システムの要件定義書の書き方。業務フロー・画面一覧・帳票一覧・非機能要件・受け入れ基準を、発注者が埋められる型で

この記事の結論：要件定義書を中小企業の業務システムのために書くなら、①目的と範囲、②用語、③業務フロー、④機能一覧、⑤画面一覧、⑥帳票一覧、⑦データ項目、⑧外部とのやり取り、⑨非機能要件、⑩受け入れ基準、⑪未決事項の11の章立てを先に作り、分かる所から埋めていくのがいちばん崩れない書き方です。発注する側が書くべきなのは、業務フロー・画面一覧・帳票一覧と、「これができれば合格」という受け入れ基準の4つで、業務フローの手順に振った番号を画面・帳票・受け入れ基準でも使い回すと、抜けと食い違いが見つけやすくなります。非機能要件は、IPAの非機能要求グレードの6つの大項目に沿って、決めたことと決めていないことを分けて書きます。

この記事は、業務システムの開発を外部に頼むことになり、要件定義書の下書きを自分たちで作ろうとしている会社の担当者に向けた、文書の型の話です。要件定義の前に何を準備するかや、開発会社との契約の形は扱いません。ここで扱うのは、書き始めるときの章立てと、各章の表の列、埋めるときの書き方です。例は、受注から請求までを1つの業務システムにまとめる場面を、架空の業務として置いています。

要件定義書は11の章立てを先に作り、分かる所から埋める

要件定義書は、頭から順に書こうとすると、業務フローの途中で手が止まります。先に章立てだけを作り、それぞれの章に「誰が埋めるか」を書いておきます。

表紙には、版、更新日、作った人、承認した人の欄を付けます。要件定義書は打ち合わせのたびに変わる文書なので、変更の履歴（いつ、どの章を、なぜ変えたか）を最後の頁に足していきます。

章立ての考え方は、IPAの「ユーザのための要件定義ガイド 第2版」が、要件定義を業務の要件・システムの要件・要件定義の進め方の管理に分けて整理しているものと方向は同じです。ただ、ガイドは大規模な開発も含めた内容なので、中小企業の規模では章を絞り、表の列を少なくした上の型から始めるほうが書き切れます。

要件定義書の業務フローは手順の表で書き、番号を振る

業務フローは、担当者ごとの列に分けた図（スイムレーン図）で描くこともできますが、発注する側が最初に作るなら、手順の表のほうが書きやすく、抜けにも気づきやすくなります。

書くときのコツは3つです。

• 例外の列を空けておかない。 「いつもはこう」より、「こういうときはこう」のほうがシステムの作りを大きく変えます。思いつかなければ「なし」と書き、空欄と区別する
• 今の流れと、システムにした後の流れを別の表にする。 今の流れには「Excelに転記する」「上長に紙で回す」のような手順が残っているはずで、それがシステムでなくなる手順です
• 番号は消さずに残す。 手順をやめたら「廃止」と書き、番号を別の手順に使い回さない。画面一覧や受け入れ基準から参照しているからです

画面一覧と帳票一覧は、業務フローの番号とつないで書く

画面一覧と帳票一覧は、画面の見た目を描く場所ではありません。「この業務の手順に、この画面が要る」という対応を示す場所です。業務フローの番号を列に入れておくと、どの手順にも出てこない画面や、画面のない手順が一目で分かります。

画面一覧の例です。

帳票一覧の例です。

帳票一覧の最後の列に、今使っている様式の見本を必ず付けます。帳票の欄には、法律で載せる決まりのある項目（請求書の登録番号など）や、取引先との約束で入れている欄が含まれていることがあり、見本がないと開発会社は気づけません。

データ項目は、帳票と画面の欄から逆算して書き出す

データ項目の章は、データベースの設計図ではなく、「この項目は何を意味し、どういう決まりがあるか」を書く場所です。帳票の見本と画面一覧に出てくる欄を全部書き出し、意味の同じものをまとめると、項目の一覧ができます。

「決まり」の列がいちばん大事です。「手で入れさせない」「入れられるのは責任者だけ」のような決まりは、画面の作りと権限の両方に効きます。型や桁数が分からなければ空けておき、開発会社と一緒に埋めます。

非機能要件は、IPAの非機能要求グレードの6分類で漏れを確かめる

非機能要件は、機能以外の「どのくらい止まらないか」「どのくらい速いか」「どう守るか」といった要件です。IPAの非機能要求グレードは、これを可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて整理しています。中小企業の業務システムでは、238ある指標を全部埋める必要はなく、6つの大項目ごとに「決めたこと」と「決めていないこと」を書き分ければ、漏れの確かめとして十分に使えます。

例の中の時間帯や頻度は、会社ごとに決めるものです。数字が決まらないときは、「月末の請求作成の日は止まると困る」のように、困る場面を書いておくだけでも、開発会社が構成と費用を考える材料になります。決めていない大項目は、未決事項の章に移します。

受け入れ基準は「前提・操作・結果」の3つで、確かめられる文にする

受け入れ基準は、できあがったシステムを受け取るときに、合格かどうかを決める条件です。「使いやすいこと」「速いこと」のような書き方では、合格かどうかを誰も決められません。前提・操作・結果の3つに分け、試せば必ず白黒がつく文にします。

書き方のコツは、うまくいく場合と同じ数だけ、うまくいかない場合（AC-02、AC-04）を書くことです。入れてはいけない値をはじく動きや、権限のない人にさせない動きは、書いておかないと試験から漏れます。業務フローの番号を入れておけば、受け入れ基準が1つもない手順も見つけられます。

決まっていないことは、未決事項の表に決める人と期限を付けて残す

要件定義書を書き終える時点で、すべてが決まっていることはまずありません。決まっていないことを本文の中に「要検討」と散らして書くと、そのまま開発が始まり、後から作り直しになります。未決事項は1つの表に集めます。

期限は日付でなく「何の前までに」で書いても構いません。決まったら行を消さずに「決まったこと」の列を埋め、本文の該当する章に反映して、変更の履歴に残します。

株式会社bundlyzeでは受託する業務システムの仕事で要件の整理から開発、保守運用までを担っており、この記事の型は、作る側が見積もりと設計に入るときに受け取りやすい形を意識して組み立てたものです。下書きを作ったあと、作る側の目で抜けを確かめたい場合は、受託開発（業務システム）の案内ページで受け付けています。

要件定義書を書き上げたら、開発会社に渡す前に確かめる5つのこと

下書きができたら、開発会社に渡す前に、次の5つを自分たちで確かめます。

1. 業務フローのどの手順にも、画面か帳票か「システム外」の印が付いているか。 何も付いていない手順は、作るのか作らないのかが決まっていない
2. 画面一覧と帳票一覧のどの行にも、業務フローの番号が入っているか。 番号のない画面は、何のために作るのかを説明できるかを確かめる
3. 受け入れ基準が、主な手順ごとに、うまくいく場合とうまくいかない場合の両方あるか
4. 用語の章の言葉が、本文の中で同じ意味で使われているか。 「受注」と「注文」、「出荷」と「発送」が混ざっていないか
5. 未決事項に、決める人と期限が入っているか

この5つを確かめた下書きなら、開発会社との打ち合わせは「何を作るか」の確認から始められ、「何を言いたいのか」の聞き取りに時間を使わずに済みます。

参考にしたIPAの資料（確認日 2026-10-03）

• IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」：要件定義の全体像、業務の要件とシステムの要件、要件定義の進め方の管理（2019年12月公開、PDFで公開）
• IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」：非機能要求グレード2018の構成（利用ガイド、グレード表、項目一覧、樹系図、活用シート）。ページはアーカイブとして公開
• IPA「非機能要求グレード2018 改訂情報」（PDF）：6つの大項目と、大項目・中項目・小項目・指標の階層