要件定義書の書き方｜盛り込む項目とテンプレート・作成のコツ

システム開発の発注準備で出てくる「要件定義書」。難しそうに見えますが、要は**「何を作るか」を関係者で共有するための書類**です。この記事では、要件定義書に何を書けばいいのか、テンプレート項目と書き方のコツ、記入例、ありがちな失敗までを初心者向けに解説します。専門用語や図面を書く必要はなく、非エンジニアでも十分に準備できます。

要件定義書とは（「要件定義」との違い）

要件定義書とは、目的・必要な機能・優先順位などを整理し、「作りたいもの」を共有できる状態にした書類です。技術的な設計書ではなく、「作りたいものが正しく伝わる」ことがゴールです。ここが曖昧だと、認識のズレや手戻りが生まれます（→システム開発が失敗する原因と回避法）。

似た言葉に「要件定義」がありますが、両者は別物です。混同しやすいので、最初に切り分けておきましょう。

用語	意味
要件定義（工程）	「何を作るか」を決めていく作業・打ち合わせのプロセス。ヒアリングや議論を重ねる期間そのもの
要件定義書（書類）	その工程の結論をまとめた成果物。合意した内容を文書化したもの

つまり「要件定義」という活動の途中や最後に生まれるアウトプットが「要件定義書」です。発注側がいきなり完璧な書類を用意する必要はなく、開発会社との対話（＝要件定義の工程）を通じて一緒に書き上げていくのが普通です。工程全体の流れは要件定義の5ステップで、発注の全体像は発注の流れで解説しています。

なぜ書類にする必要があるのか。口頭の「なんとなくの共有」だと、開発が進むにつれて「言った・言わない」が発生し、完成品が想像と違う、という事故につながるからです。書類にしておけば、関係者全員が同じゴールを見られ、見積りの根拠にもなります（→見積書の見方）。

要件定義書の目次テンプレート（項目一覧）

まずは全体像です。要件定義書に盛り込む代表的な項目を一覧にしました。すべてを埋める必要はなく、わかる範囲から書き、空欄は打ち合わせで埋めるでかまいません。

#	項目	書く内容
1	目的・背景	なぜ作るのか、今どういう状況か
2	解決したい課題	何に、どれくらい困っているか
3	対象業務・対象ユーザー	どの業務を、誰が使うか
4	機能要件	ほしい機能（わかる範囲で）
5	非機能要件	速さ・使える人数・セキュリティなど
6	画面イメージ	どんな画面がほしいか（手描きでも可）
7	データ・帳票	扱うデータ、出力したい帳票
8	制約条件	予算・納期・既存システム・法令など
9	スケジュール・優先順位	いつまでに、どの機能から必要か
10	体制・関係者	発注側の担当者、決裁者は誰か

10項目あると身構えてしまいますが、初回の相談段階では 1〜4（目的・課題・対象・ほしい機能）が書けていれば十分です。5以降は開発会社が質問しながら一緒に埋めてくれます。書式もWordやスプレッドシート、あるいは箇条書きのメモで構いません。体裁より中身、つまり「目的と困りごとが具体的に伝わるか」が大切です。

各項目の書き方と記入例

抽象的な説明だけだと書きにくいので、項目ごとに「悪い例 → 良い例」で記入イメージを示します。実在の企業ではなく、一般化した架空のケースです。

目的・背景

なぜ作るのかを一文で言い切ります。「システムを作りたい」ではなく、その先の狙いまで書くのがコツです。

• 悪い例：「在庫管理システムがほしい」
• 良い例：「手作業のExcel在庫管理で月末の集計に丸一日かかっているため、日々の在庫を自動集計し、集計作業を月2時間以内にしたい」

解決したい課題

困りごとを、できれば数字で表します。数字があると優先順位も見積りも決めやすくなります。

• 悪い例：「業務が非効率」
• 良い例：「受注入力を2つのシステムに二重入力しており、1日あたり合計2時間・月40時間の手間と入力ミスが発生している」

対象業務・対象ユーザー

誰の、どの業務のためのものかを書きます。使う人によって必要な機能が変わるためです。

• 例：「利用者は店舗スタッフ10名（PC操作は不慣れ）と、本部の管理者2名。対象業務は日次の在庫報告と発注」

機能要件

ほしい機能を箇条書きにします。細かい実装方法は不要で、「〜できる」という形で書くとブレません。

• 例：「商品ごとに在庫数を登録できる」「在庫が設定数を下回るとアラートが出る」「月次の在庫推移をCSVで出力できる」

画面・データ・帳票

イメージがあれば、手描きのスケッチや、参考にしたい既存サービスの名前を添えると伝わります。出力したい帳票（請求書、日報など）があれば様式も書いておきます。

• 例：「トップ画面に『今日の在庫一覧』を表示。既存の◯◯（他社サービス）のような見た目が理想」「月次の在庫推移を、経理提出用にA4のPDFで出力したい」

制約条件・スケジュール・体制

見落とされやすいのがこの3点です。予算・納期・既存システムとの連携などの制約は、開発会社の提案を大きく左右します。誰が窓口で、誰が最終決裁するか（体制）も最初に決めておくと、意思決定が滞りません。

• 制約の例：「予算は100万円前後」「既存の販売管理システムとデータ連携したい」「個人情報を扱うので社外からのアクセスは不可」
• スケジュールの例：「繁忙期の12月までに稼働させたい」「まず在庫機能だけ先行リリースしたい」
• 体制の例：「窓口は店舗運営部の田中、最終決裁は店長」

このように 「事実（現状）＋数字＋やりたいこと」 の順で書くと、開発会社が状況を正確につかめます。うまく書けない項目は「未定・要相談」と正直に書いて問題ありません。

ミニ事例：メモから相談が動いたケース

例えば、ある小売店では「Excelの在庫管理がつらい」という漠然とした悩みしかありませんでした。そこで、上の型に沿って「月末集計に丸一日」「二重入力で月40時間」という数字と、ほしい機能3つ、優先順位、予算感だけをA4一枚のメモにまとめました。この一枚を持って相談したところ、開発会社側から「まず在庫登録と自動集計だけ先行で作り、発注機能は次段階に」という具体的な提案が返ってきました。立派な書類でなくても、事実と数字が揃っていれば話は動くという好例です。

機能要件と非機能要件の違い

要件定義書でつまずきやすいのが、この2つの区別です。ざっくり言うと、**機能要件は「何ができるか」、非機能要件は「どれくらいの品質で動くか」**です。

種類	問いかけ	具体例
機能要件	このシステムは何ができる？	会員登録できる／検索できる／PDFを出力できる
非機能要件	どんな品質・条件で動く？	3秒以内に表示／同時100人が使える／毎日バックアップ

非機能要件は見落とされがちですが、後から「思ったより遅い」「スマホで見づらい」といった不満の原因になります。最低限、次の観点だけでも触れておくと安心です。

• 性能：どれくらいの速さ・データ量を想定するか
• 利用環境：PC／スマホ／タブレットのどれで使うか、社外からも使うか
• 同時利用者数：何人が同時に使うか
• セキュリティ：扱う情報の重要度、ログイン制御の要否
• 運用・保守：バックアップ、障害時の連絡体制

ここも完璧である必要はありません。「同時に何人使うか分からない」なら、「今は5人、将来的に20人程度を想定」と幅で書けば十分に伝わります。判断がつかない項目は空欄にせず「要相談」と書いておくと、打ち合わせで拾ってもらえます。

書き分けに迷ったら、こう覚えてください。「〜できる」で終わる文は機能要件、「〜以内に」「〜まで耐える」で終わる文は非機能要件です。この2つを分けて書くだけで、開発会社は必要な性能や構成を見積もりやすくなり、後からの追加費用や手戻りを防げます。

書くときのコツ

情報を足すほど良い、というわけではありません。伝わる要件定義書には共通のコツがあります。

• 技術仕様より目的を書く：「何を解決したいか」が最重要。実装方法は開発会社が提案します。
• 完璧を目指さない：わかる範囲で書き、細部は対話で詰める。空欄は「要相談」でよい。
• 優先順位をつける：「まず必要な最小限（MVP）」と「後で足す機能」を分ける。全部を一度に作ろうとしない。
• 「対象外」を明記する：やらないこと・今回は作らない機能を書くと、認識のズレと予算超過を防げます。「今回は英語対応はしない」など。
• 図やスケッチで補う：言葉で説明しづらい画面や業務の流れは、手描きの図で十分。一枚の絵が長文より伝わります。
• 数字を入れる：「速い」「多い」ではなく「3秒以内」「月100件」。判断の基準が揃います。

優先順位は、次のように3段階で色分けすると開発会社と相談しやすくなります。

優先度	意味	扱い
必須（Must）	ないと目的を達成できない	最初のリリースに必ず入れる
あるとよい（Should）	あると便利だが後回し可	予算・期間を見て判断
将来（Could）	いつか実現したい	今回は対象外として記録

ありがちな失敗と回避策

要件定義書でよくある失敗は、だいたい次の3つに集約されます。事前に知っておくだけで避けやすくなります（→システム開発の失敗事例）。

• 曖昧すぎる：「使いやすくしたい」「効率化したい」だけで、具体的な機能や数字がない。→ 現状の作業時間や件数など、事実と数字を添える。

• 盛り込みすぎる：思いついた機能を全部入れて、予算も期間も膨らむ。→ 優先度で仕分けし、まず必須機能だけで始める。

• 現場が不在：決裁者や情報システム担当だけで書き、実際に使う現場の声が入っていない。→ 使う人に「今どこで困っているか」を一度ヒアリングする。

• 専門用語で無理に書く：慣れない技術用語を使い、かえって意図がぼやける。→ 自分の言葉で「今こうしていて、こう変えたい」と書けば十分。

• 一度書いて放置する：最初のメモのまま更新せず、打ち合わせでの決定が反映されない。→ 決まったことはその都度追記し、常に最新の状態に保つ。

いずれも「立派な書類を作ろう」と気負ったときに起きがちです。目的は書類の完成度ではなく、作りたいものが正しく伝わることだと思い出してください。提出前に、次の3点だけセルフチェックすると精度が上がります。

• 目的が一文で言い切れているか（何のために作るのか）
• ほしい機能に優先順位がついているか（必須と後回しが分かれているか）
• 「対象外」と予算・納期が書いてあるか（際限なく広がらないか）

非エンジニアが準備できること（簡易版テンプレ）

「専門知識がないから書けない」と感じる方も多いですが、非エンジニアだからこそ書ける情報が要件定義書の核です。技術は開発会社が担当します。発注側が準備できるのは、次のような現場の事実です。

• 今の業務の流れ（誰が、何を、どの順で行っているか）
• 困っていること・時間がかかっていること
• 使っている道具（Excelやスプレッドシートなどのファイルやツール）
• ほしい結果（どうなったら楽になるか）

これらをメモにまとめるだけで、立派な相談材料になります。フォーマットに迷ったら、次の簡易版テンプレをそのまま埋めてみてください。箇条書きのメモで十分です。

■ 目的
　（例：Excel在庫管理をやめ、集計作業を月2時間以内にしたい）
■ 今困っていること
　（例：月末の在庫集計に丸一日かかっている／入力ミスが月数件ある）
■ 使う人
　（例：店舗スタッフ10名・本部管理者2名）
■ ほしい機能（わかる範囲で）
　- （例：在庫数を登録できる）
　- （例：在庫が減ったらアラートが出る）
　- （例：月次データをCSVで出せる）
■ 優先順位
　必須：（例：在庫登録・集計）
　あとで：（例：発注書の自動作成）
■ 使う環境
　（例：店舗はタブレット、本部はPC）
■ 予算・納期・対象外
　（例：予算100万円前後／◯月までに／英語対応は今回なし）

このメモが用意できれば、相談は十分にスタートできます。逆に、ここまで書けなくても、目的と困りごとの箇条書きだけで相談は前に進みます。

準備の順番に迷ったら、次のステップで進めると無理がありません。

1. 目的と困りごとを箇条書きにする（ここまでで相談は可能）
2. 実際に使う人に「今どこで困っているか」を一度聞く
3. ほしい機能を思いつくまま並べ、後で優先度をつける
4. 予算・納期・対象外を書き添える
5. 相談の場で、開発会社の質問に答えながら残りを埋める

この5番目が要件定義の工程そのものです。発注側が全部を一人で背負う必要はなく、たたき台を持ち寄って一緒に完成させるのが本来の姿だと考えてください。会社選びの観点は開発会社の選び方も参考になります。

完璧な要件定義書は不要

発注側が「完璧な要件定義書を作らねば」と気負う必要はありません。目的と課題、ほしい機能が書ければ十分で、細部は開発会社と一緒に固めていくのが正しい進め方です。むしろ発注側だけで細部まで作り込むと、技術的に無理があったり、もっと良い方法を見逃したりします。たたき台を持って相談し、対話で磨くのが失敗しにくい進め方です。

費用面の不安で要件を削ってしまう、という失敗もよくあります。一般的な見積りでは、要件を足すたびに金額が積み上がり、「これも言うと高くなるのでは」と本音を言いづらくなりがちです。その結果、本当は必要な機能を最初から外してしまい、後で作り直しになることもあります。

D-oneAppは料金が一律100万円（プロは200万円）で追加費用がなく、着手前に総額が確定します。そのため、要件を「盛るか削るか」で金額を気にせず、本当に必要なものを率直に相談しながら一緒に整理できます。100万円でどこまでできるかは100万円でできることもご覧ください。

まとめ

要件定義書とは、「何を作るか」を共有するための書類で、目的・課題・機能・優先順位が伝われば十分です。機能要件と非機能要件を分け、優先度と「対象外」を明記し、数字を添えると精度が上がります。完璧を目指さず、開発会社と一緒に固めるのがコツ。書き方に迷っても大丈夫です。無料相談で、あなたの「やりたいこと」を一緒に言葉にしていきましょう。