要件定義書の書き方とテンプレート【非エンジニア発注者向け7項目・記入例付き】

システム開発を外注することになり、「まず要件定義書を作ってきてください」と開発会社に言われた。そんな経験はありませんか。

要件定義書を書けと言われても、何を書けばいいのかわからない。技術用語が多くて怖い。完璧なものを作らなければならないのではないかと感じて、なかなか手が動かない——そんな非エンジニアの発注担当者は少なくありません。

実は、要件定義書は完璧である必要はありません。開発会社が求めているのは、「あなたの会社が何を解決したくて、そのために何が必要か」を伝えてくれる文書です。項目が全部埋まっていなくても、技術的に正確でなくても、対話のきっかけになる文書があれば開発はスタートできます。

本記事では、初めてシステム開発を外注する非エンジニアの担当者向けに、要件定義書に書くべき7つの項目と記入例を具体的に解説します。架空の在庫管理システム案件を例に使うので、自社の状況に置き換えながら読んでみてください。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

要件定義書とは？RFP・企画書との違い

要件定義書の役割：開発会社との認識合わせの土台

要件定義書とは、開発するシステムに必要な機能・性能・制約条件を整理した文書です。「開発会社に何を作ってほしいかを伝えるための設計図の素材」と考えるとイメージしやすいでしょう。

要件定義書がないままシステム開発を進めると、「こんな機能は頼んでいなかった」「想定していた動きと違う」といったトラブルが後から発生します。開発が進めば進むほど修正コストは上がります。そのため、開発着手前に発注者と開発会社が合意した文書として要件定義書を作成することが重要です。

RFP・企画書・基本設計書との違い一覧

「要件定義書」と混同しやすい文書が3つあります。それぞれの違いを整理しておきましょう。

本記事が扱うのは要件定義書です。RFPの書き方についてはRFPの書き方と構成をわかりやすく解説を、要件定義のプロセス全体については要件定義の進め方ガイドをご覧ください。

発注者が書くべき7つの項目

要件定義書に必要な項目はプロジェクトによって異なりますが、初めて要件定義書を書く非エンジニアの発注者が最低限押さえるべき項目は7つです。

「完璧に書けなくていい」という前提で読んでください。不明な項目は「未確定」と記入しておくことで、開発会社との打ち合わせのたたき台として使えます。

1. 業務背景・解決したい課題（なぜシステムが必要か）

現在の業務でどんな問題が起きているかを書きます。「〇〇の作業に時間がかかっている」「エクセル管理のため入力ミスが多発している」など、具体的に書くほど開発会社に状況が伝わります。

書くべき内容の例:

• 現状の業務フロー（どんな流れで仕事をしているか）
• 現在の課題・問題点（何が困っているか）
• システム化する背景（なぜ今この問題を解決したいか）

2. システムの目的・ゴール（何を達成したいか）

「このシステムで何を達成したいか」をゴールとして書きます。「業務効率化」「ペーパーレス化」など漠然とした表現より、「在庫管理にかかる作業時間を週10時間から2時間に削減したい」のように数値化できると理想的です。

3. 対象ユーザーと利用シーン（誰がどう使うか）

このシステムを誰が使うのかを書きます。利用者の数・IT習熟度・使う場所（社内/外出先/スマートフォン）なども整理しましょう。

書くべき内容の例:

• 利用者（例: 倉庫スタッフ5名、管理者2名）
• 利用する環境（例: 倉庫内PCとスマートフォン両方で使いたい）
• IT習熟度（例: PCの基本操作はできるが、複雑な操作は難しい）

4. 必要な機能一覧（優先度付き）

「このシステムで何ができる必要があるか」の機能を列挙します。機能ごとに優先度（必須/あれば嬉しい/将来検討）をつけることが重要です。

優先度なしで全機能を「必須」扱いにすると、開発コストが膨らみます。「最低限このシステムが動くために絶対必要な機能」と「あったら便利な機能」を分けて記載しましょう。

5. 非機能要件（性能・セキュリティ・可用性）

「システムに求める品質レベル」を書きます。「何ができるか（機能要件）」ではなく「どれくらいの品質で動くか」が非機能要件です。

初めて書く場合は以下の観点から考えてみてください。

• 性能: 「検索結果は3秒以内に表示してほしい」
• 可用性: 「業務時間中（平日8〜20時）は止まらないようにしてほしい」
• セキュリティ: 「顧客データが含まれるので、社外からのアクセスには認証が必要」
• 利用者数: 「同時に10人が使う想定」

すべての項目に答えられなくても大丈夫です。「わからない/未確定」と書いておけば開発会社が提案してくれます。

6. 予算・スケジュール制約（いつまでにいくらで）

プロジェクトの制約条件を共有します。「予算はないが期限も制約もない」はほぼありえません。現実的な制約を正直に伝えることで、開発会社が実現可能な提案をしやすくなります。

• 予算: おおよその上限（例: 開発費用は500万円以内を想定）
• リリース期限: いつまでに使えるようにしたいか（例: 2026年10月末までに稼働させたい）
• 優先順位: 予算と期限が両立しない場合はどちらを優先するか

7. 成功基準・KPI（何をもって完成とするか）

「このシステムが成功したと判断する基準」を書きます。「在庫管理業務の工数を50%削減」「在庫切れによる機会損失をゼロにする」など、測定できる形で書くのが理想です。

KPIが明確だと、リリース後の効果測定もしやすくなります。

各項目の記入例（在庫管理システム案件で解説）

架空の案件概要（前提設定）

以下の架空の案件を例に、7項目の記入例を見ていきます。

前提:

• 会社: 中堅アパレル小売業（社員50名）
• 課題: 倉庫の在庫管理をエクセルで行っているが、入力ミスや更新漏れが多く、在庫切れや過剰在庫が発生している
• 依頼: 在庫管理システムの新規開発

記入例（7項目すべて）

1. 業務背景・解決したい課題

2. システムの目的・ゴール

3. 対象ユーザーと利用シーン

4. 必要な機能一覧（優先度付き）

5. 非機能要件

6. 予算・スケジュール制約

7. 成功基準・KPI

開発会社が「わかりやすい」と思う書き方3つのコツ

コツ1: 曖昧な表現を「5W1H」で具体化する

要件定義書でよくある失敗は、「わかりやすい画面にしてほしい」「使いやすくしてほしい」といった曖昧な表現です。開発会社は言葉を文字通りに受け取るため、「わかりやすい」の基準が発注者と異なると、完成後に「こんなはずじゃなかった」という事態になります。

5W1H（誰が・何を・いつ・どこで・なぜ・どのように）を意識して書くと、曖昧さが自然に減ります。

コツ2: 機能に「必須・あれば嬉しい・将来検討」の優先度をつける

機能要件に優先度をつけないと、すべての機能が「必須」として見積もられます。結果として見積金額が予算を大幅に超え、削ぎ落とす作業に時間を使うことになります。

最初から「本当に必要な機能（MVP）」と「あったら便利な機能」を分けて書くことで、予算内での調整がスムーズになります。

• 必須: このシステムが動くために絶対に必要
• あれば嬉しい: なくてもシステムは動くが、あると業務が楽になる
• 将来検討: 今回は不要だが将来的に追加を検討したい

コツ3: わからない項目は「未確定」と書いて渡す勇気

要件定義書の全項目を埋めなければ渡せない、と思っている発注者は多いです。しかし、「未確定」や「開発会社のご提案に従いたい」と書いて渡すことは何も問題ありません。

むしろ、「よくわかっていない」のに推測で書いた内容が後から誤りだと判明すると、大きな手戻りが発生します。「この項目は社内で決まっておらず未確定です。アドバイスいただけますか？」と書くことで、開発会社が適切な選択肢を提案してくれます。

要件定義書は「完成品を渡す文書」ではなく「対話を始めるための文書」です。8割の完成度で渡して、残り2割を開発会社との打ち合わせで詰めるのが現実的な進め方です。

テンプレートの使い方とダウンロード案内

テンプレートの構成と使い方

本記事で解説した7項目を網羅したテンプレート（Excel/Word形式）を用意しています。以下の手順で活用してください。

1. テンプレートをダウンロードする
2. 各項目に自社の状況を入力する（わからない箇所は「未確定」と記入）
3. 開発会社の担当者に共有し、打ち合わせのたたき台として使う
4. 打ち合わせの内容を反映してテンプレートを更新する

最初から完璧なものを作ろうとせず、「まず7項目を埋める」ことを目標にしてください。

テンプレートのダウンロード案内

より実践的なテンプレートと要件定義書作成の詳しい解説は、ダウンロード資料にまとめています。

ダウンロード資料を見る

まとめ：まず7項目を埋めることから始めよう

要件定義書は、完璧なものを作る必要はありません。開発会社に自社の状況を伝え、対話を始めるための文書として、以下の7項目を埋めることから始めてみてください。

1. 業務背景・解決したい課題
2. システムの目的・ゴール
3. 対象ユーザーと利用シーン
4. 必要な機能一覧（優先度付き）
5. 非機能要件（性能・セキュリティ・可用性）
6. 予算・スケジュール制約
7. 成功基準・KPI

わからない項目は「未確定」と書いて渡す。機能に優先度をつける。曖昧な表現は5W1Hで具体化する。この3つのコツを意識するだけで、開発会社に「伝わる」要件定義書になります。

要件定義の進め方全体についてはシステム開発の要件定義とは？進め方と注意点を解説で解説しています。また、開発会社の選定から始める場合はRFP（提案依頼書）の書き方と活用ガイドもあわせてご覧ください。

無料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード