要件定義書に最低限書くべき項目

要件定義書は分厚ければ良いものではありません。中小企業の開発では、何を書いて何を省略するかの判断が重要です。最低限押さえておくべき項目と、ベンダーへの伝え方のポイントを整理します。

要件定義書とは何か

要件定義書は、「このシステムで何を実現するか」を文書にまとめたものです。発注者とベンダーが共通の認識を持つための合意文書であり、開発中に「言った・言わない」が起きたときの拠り所にもなります。

大企業の開発では数百ページに及ぶ要件定義書が作られることもありますが、中小企業の開発でそこまでの量を作る必要はありません。大事なのは量より「合意すべきことが漏れなく書かれているかどうか」です。

以下の項目が揃っていれば、多くの中小規模開発では要件定義書として機能します。

このシステムをなぜ作るのかを書きます。「現状の何が課題で、システム導入によって何を実現したいのか」を簡潔にまとめます。

ここが曖昧だと、開発が進む中で「そもそも何のために作っているのか」が見失われます。追加機能の是非を判断するときにも、目的に立ち返ることが重要です。

「このシステムで何をやって、何をやらないか」の線引きです。

「やること」だけでなく「やらないこと」も明示することが重要です。発注者が「当然含まれる」と思っていた機能が、ベンダーには対象外と認識されていた——というトラブルはスコープの曖昧さから生まれます。

対象業務の流れを整理します。「誰が」「何をして」「どこに渡すか」を図や箇条書きで表現します。

現状の業務フローと、システム導入後の業務フローを分けて書くと、どこを変えたいのかが伝わりやすくなります。

実装する機能をリスト形式でまとめます。一機能ごとに「何ができるか」を一行で書き、優先度（必須・あれば良い・将来対応）も記載しておくと有用です。

機能の詳細（画面設計・処理ロジック）はこの段階では不要です。「何ができるか」の一覧で十分です。

システムで扱うデータの種類と、それぞれの関係を整理します。「顧客・商品・受注・受注明細」のように主要なデータを列挙し、それぞれに含まれる情報項目をまとめます。

技術的なデータベース設計はベンダーが行いますが、「どんな情報を管理したいか」は発注者が整理する部分です。

「何ができるか」ではなく「どれくらいの品質で動くか」に関する要件です。以下の観点を確認しておきます。

開発に影響する制約を書きます。「既存のシステムと連携しなければならない」「特定のブラウザに対応しなければならない」「予算と納期の上限」などが該当します。

ベンダーが知らないまま開発を進めて、後から制約が発覚すると大きな手戻りが生じます。

業界固有の言葉や社内用語をリストアップして意味を説明します。

同じ言葉でも、発注者とベンダーで意味が違うことがあります。たとえば「案件」が、ある会社では「商談」を指し、別の会社では「受注済みの仕事」を指すことがあります。こうした誤解の種を先に潰しておきます。

箇条書きと図を活用する：文章で書こうとすると長くなり、読まれなくなります。箇条書きで要点を絞り、業務フローは図で示します。

「当たり前」を省略しない：発注者には当たり前に思えることでも、ベンダーには伝わっていない前提が多くあります。「わかっているだろう」と思ったことほど、明示的に書いておきます。

完成度より合意を優先する：100点の要件定義書を作ることより、関係者全員が内容を理解して合意していることのほうが重要です。

要件定義書をベンダーに渡すだけでなく、内容を一緒に確認する打ち合わせの場を設けることを推奨します。文字を読んでもわからない部分を口頭で補足し、ベンダーからの疑問点にその場で答えることで、認識のズレを素早く解消できます。

要件定義書に必要なのは、背景・スコープ・業務フロー・機能一覧・データ・非機能要件・制約・用語定義の8項目です。量より「合意すべきことが書かれているか」を重視して作成してください。完璧な文書を目指すより、関係者全員が内容を理解して合意していることが、プロジェクトの成功に直結します。