「要件定義書を作りたいが、何を書けばよいか分からない」

「システム開発会社へ依頼する前に要件を整理しておきたい」

「要件定義書のテンプレートをそのまま使いたい」

「小規模な業務システムなのに、大企業向けの要件定義書は複雑すぎる」

このような方に向けて、本記事では中小企業のWebシステム・業務システム開発で使いやすい要件定義書テンプレートを紹介します。

要件定義書というと、何十ページもの資料を作るイメージを持つかもしれません。

しかし、重要なのはページ数ではありません。

発注者と開発者が

何を作るのか
何を作らないのか
誰が使うのか
どのような業務を実現するのか

について同じ認識を持てること

が重要です。

IPAも、要件定義ではビジネス要求とシステム化要求を文書化し、関係者と合意したものを「要件」とする考え方を示しています。また、作成する要件定義書はプロジェクトによって異なると説明しています。

そのため、従業員数十人規模の企業が利用する業務システムと、大規模な基幹システムで同じ要件定義書を使う必要はありません。

本記事では、

• コピペして使える要件定義書テンプレート
• 各項目の書き方
• 在庫管理システムを例にした記入例
• 機能要件と非機能要件の違い
• 小規模システムなら省略できる項目
• 要件定義書作成でよくある失敗

まで具体的に解説します。

要件定義書とは

要件定義書とは、

「どのようなシステムを作るのか」を発注者と開発者の間で明確にするための文書

です。

例えば、

在庫管理システムを作りたい

というだけでは、開発者は具体的なシステムを設計できません。

少なくとも、

誰が使うのか

何の商品を管理するのか

何拠点あるのか

在庫はどの単位で管理するのか

誰が在庫を変更できるのか

CSV出力は必要か

スマートフォン対応は必要か

既存Excelは移行するのか

などを決める必要があります。

これらを文書化したものが要件定義書です。

要件定義書は「仕様書」とは違う

要件定義書と仕様書は混同されやすい言葉です。

簡単に整理すると、

要件定義書
=
何を実現するのか

基本設計書・仕様書
=
どのように実現するのか

です。

例えば、

商品名・商品コードから
商品を検索できる

は要件です。

一方、

検索欄を画面上部に配置する

商品名は部分一致検索

商品コードは完全一致検索

などは、より詳細な仕様になります。

実際のプロジェクトでは境界が明確に分かれない場合もありますが、要件定義段階ではまず、

システムとして
何を実現する必要があるか

を決めることが重要です。

【コピペ用】要件定義書テンプレート

まず、全体のテンプレートを掲載します。

中小企業のWebシステム・業務システム開発であれば、次の構成をベースにすると整理しやすくなります。

# 要件定義書

## 1. システム概要

システム名：
対象業務：
利用部署：
想定利用者数：

## 2. 開発背景

現在の業務：
現在発生している問題：
システム化する理由：

## 3. 開発目的・ゴール

目的：
達成したい状態：
KPI・目標値：

## 4. システム化対象範囲

今回システム化する業務：

今回システム化しない業務：

## 5. 現状業務フロー

現在の業務手順：

利用しているツール：

関係する担当者・部署：

## 6. 新業務フロー

システム導入後の業務手順：

人が行う処理：

システムが行う処理：

## 7. 利用者・権限

ユーザー種別：

各ユーザーが利用できる機能：

閲覧可能なデータ：

## 8. 機能要件

F01：
機能名：
概要：
利用者：
優先度：

F02：
機能名：
概要：
利用者：
優先度：

## 9. データ要件

管理対象データ：

必須項目：

保存期間：

データ件数：

## 10. 帳票・CSV

帳票名：

出力形式：

必要項目：

## 11. 外部システム連携

連携先：

連携データ：

連携方法：

連携タイミング：

## 12. 非機能要件

利用時間：

想定同時利用者数：

性能：

セキュリティ：

バックアップ：

ログ：

障害対応：

対応端末・ブラウザ：

## 13. データ移行

移行対象：

移行元：

件数：

移行方法：

## 14. 運用・保守

ユーザー管理：

マスタ管理：

問い合わせ対応：

障害対応：

バックアップ：

## 15. 制約条件

予算：

希望納期：

利用技術の指定：

利用サービスの指定：

## 16. 対象外

今回実装しない機能：

将来検討する機能：

## 17. 未決事項

項目：

担当者：

決定期限：

## 18. スケジュール

要件定義：

設計：

開発：

テスト：

リリース：

すべての項目を必ず埋める必要はありません。

例えば小規模な社内システムであれば、

1. システム概要
2. 開発目的
3. 業務フロー
4. 利用者・権限
5. 機能要件
6. データ要件
7. 非機能要件
8. 対象外
9. 未決事項

程度まで簡略化することもできます。

ここから、それぞれの項目について書き方を解説します。

1．システム概要

最初に、

何のシステムなのか

を簡潔に記載します。

テンプレート

システム名：

対象業務：

利用部署：

利用者：

想定利用者数：

システム概要：

記入例

システム名：
在庫管理システム

対象業務：
商品在庫・入出庫管理

利用部署：
本社、千葉営業所、東京営業所

利用者：
営業担当、倉庫担当、管理者

想定利用者数：
30名

システム概要：
現在Excelで管理している3拠点の
在庫情報をWebシステムへ統合する。

ここでは詳細な機能を書く必要はありません。

システム全体を1〜3文で説明できれば十分です。

2．開発背景

次に、

なぜシステム開発が必要なのか

を記載します。

テンプレート

現在の業務：

現在発生している問題：

システム化を検討した背景：

記入例

現在の業務：

各拠点がExcelで在庫を管理している。
毎週金曜日に本社へExcelをメール送付し、
本社担当者が一つのファイルへ集約している。


現在発生している問題：

・集計に毎週約3時間かかる
・ファイルの最新版が分からなくなる
・他拠点の在庫をすぐ確認できない
・入力方法が担当者によって異なる


システム化を検討した背景：

複数拠点の在庫情報を一元管理し、
Excelの集計作業を削減するため。

「システムが欲しい」という要望だけでなく、

現在何が問題なのか

まで記載するのがポイントです。

3．開発目的・ゴール

開発目的は、要件定義書の中でも重要な項目です。

例えば、

在庫管理システムを開発する

は目的ではありません。

それは手段です。

目的は、

複数拠点の在庫情報を一元化し、
本社で発生している集計作業を削減する

です。

テンプレート

開発目的：

実現したい状態：

可能であれば数値目標：

記入例

開発目的：

3拠点の在庫情報を一元管理し、
Excelによる集計作業をなくす。


実現したい状態：

・全拠点の在庫をリアルタイムで確認できる
・担当者以外でも在庫情報を確認できる
・Excelファイルの送受信を不要にする


目標：

毎週約3時間かかっている
在庫集計作業を30分以内にする。

数値目標が設定できる場合は記載します。

4．システム化対象範囲

要件定義では、

何を作るか

だけではなく、

何を作らないか

も明確にします。

テンプレート

今回の対象：

今回の対象外：

将来対応予定：

記入例

今回の対象：

・商品管理
・拠点管理
・在庫管理
・入出庫管理
・CSV出力
・ユーザー管理


今回の対象外：

・発注管理
・会計システム連携
・需要予測
・スマートフォンアプリ


将来対応予定：

第2フェーズで発注管理を検討する。

これを決めておかないと、

当然含まれていると思っていた

という認識違いが起こりやすくなります。

5．現状業務フロー

現在の業務を「As-Is」として整理します。

例えば、

商品入荷

↓

倉庫担当がExcel入力

↓

営業所ごとにファイル保存

↓

金曜日に本社へメール

↓

本社担当者が統合

↓

管理職へ共有

という形です。

文章だけでなく、図にすると理解しやすくなります。

確認する項目

誰が

何を受け取り

何を入力し

何を確認し

誰へ渡しているか

を確認します。

6．新業務フロー

次に、システム導入後の「To-Be」を整理します。

例えば、

商品入荷

↓

倉庫担当がWebシステムへ登録

↓

共通DBへ保存

↓

全拠点から確認可能

↓

本社は集計作業不要

となります。

ここでは、

人が担当する業務

システムが担当する業務

を分けることがポイントです。

例

人：

・実際の入荷数確認
・返品可否判断
・棚卸し


システム：

・在庫数計算
・在庫データ保存
・拠点別在庫表示
・CSV生成

すべてを自動化する必要はありません。

7．利用者・権限

業務システムでは非常に重要な項目です。

例えば、

一般担当者

拠点管理者

本社管理者

システム管理者

などに分けます。

テンプレート

操作	一般担当者	拠点管理者	本社管理者
在庫閲覧	○	○	○
入出庫登録	○	○	○
在庫修正	×	○	○
他拠点閲覧	×	×	○
ユーザー管理	×	×	○

権限を後から追加するとデータ構造や画面設計へ影響する場合があるため、要件定義段階で整理しておくと安全です。

8．機能要件

機能要件は、

システムで何ができるか

を定義する項目です。

おすすめテンプレート

ID	機能名	概要	利用者	優先度
F01	ログイン	ID・パスワード認証	全員	必須
F02	商品管理	商品の登録・編集	管理者	必須
F03	在庫一覧	拠点別在庫を表示	全員	必須
F04	入庫登録	入庫数を登録	担当者	必須
F05	出庫登録	出庫数を登録	担当者	必須
F06	CSV出力	在庫一覧をCSV出力	管理者	高
F07	在庫通知	在庫不足を通知	管理者	中

この形式ならExcelやGoogleスプレッドシートでも管理しやすくなります。

機能にはIDを付ける

例えば、

F01 ログイン
F02 商品管理
F03 在庫一覧

のようにIDを付けます。

すると打ち合わせで、

F05について確認したい

と指定でき、認識を合わせやすくなります。

機能要件は詳細を書きすぎない

例えば要件定義段階で、

ボタンは右上から23px

まで決める必要はありません。

まず、

誰が

何を入力して

どのような結果を得られるか

を明確にします。

詳細なUIは基本設計・画面設計で決めます。

9．データ要件

次に、

システムで何を管理するか

を整理します。

例えば商品なら、

項目	必須	内容
商品コード	○	商品を一意に識別
商品名	○	商品名称
カテゴリ	○	商品分類
単価	△	販売単価
ステータス	○	有効・無効

在庫なら、

商品

拠点

在庫数

更新日時

更新者

などを管理します。

データ件数も確認する

例えば、

商品：
100件

と、

商品：
500万件

では設計が大きく変わります。

要件定義時に、

現在件数

年間増加件数

保存期間

も確認します。

10．帳票・CSV要件

業務システムでは忘れやすい項目です。

例えば、

見積書

請求書

納品書

一覧PDF

CSV

Excel

などです。

テンプレート

ID	帳票名	形式	利用者
R01	在庫一覧	CSV	管理者
R02	棚卸表	PDF	倉庫担当
R03	入出庫履歴	CSV	管理者

既存のExcel・PDFがある場合は、実物を要件定義時に共有すると認識を合わせやすくなります。

11．外部システム連携

他のシステムとデータをやり取りする場合に記載します。

例えば、

会計システム

販売管理システム

決済サービス

Google Workspace

Slack

メール配信

外部API

などです。

テンプレート

連携先：

連携するデータ：

連携方向：

連携タイミング：

連携方法：

障害時の対応：

記入例

連携先：
会計システム

連携データ：
売上データ

連携方向：
在庫管理システム → 会計システム

連携タイミング：
1日1回

連携方法：
CSV

エラー時：
管理者へメール通知

12．非機能要件

機能要件と同じくらい重要なのが非機能要件です。

IPAも、システム要件を考える際には機能面だけでなく、稼働率・レスポンスタイム・セキュリティなどの非機能面を分析する必要があるとしています。

またIPAの「非機能要求グレード」は、発注者と開発者の認識違いを防ぐ目的で、非機能要求を網羅的に整理し、重要項目から段階的に要求レベルを確認する方法を示しています。

最低限確認したい項目

利用時間

性能

利用人数

セキュリティ

バックアップ

障害対応

監視

対応端末

ブラウザ

例えば、

利用時間：
平日8:00〜20:00

想定利用者：
30名

同時接続：
最大20名程度

性能：
主要画面は通常3秒以内

バックアップ：
1日1回

対応端末：
PC、スマートフォン

ブラウザ：
Chrome、Edge最新版

認証：
メールアドレス＋パスワード

などです。

「高速」「安全」とだけ書かない

例えば、

高速に動作すること

では、人によって認識が異なります。

可能であれば、

主要画面は通常3秒以内

と具体化します。

同様に、

十分なセキュリティ

ではなく、

管理者のみユーザー削除可能

通信はHTTPS

パスワードはハッシュ化

操作ログを90日保存

など、必要な内容へ具体化していきます。

すべての非機能要件を最初から詳細に決めるのは現実的ではなく、IPAも重要な項目から段階的に確認する方法を示しています。

13．データ移行要件

既存のExcelやシステムを置き換える場合は必須です。

例えば、

商品：
5,000件

顧客：
10,000件

在庫：
15,000件

過去履歴：
3年分

などです。

テンプレート

移行元：

移行対象：

データ件数：

データ形式：

移行対象期間：

データクレンジング担当：

移行後の確認方法：

「既存Excelを全部移行」で済ませない

例えばExcelを見ると、

商品名が統一されていない

同じ顧客が2件存在

電話番号形式が違う

不要データが大量にある

可能性があります。

データ移行は、

移す作業

だけではなく、

移せる状態に整理する作業

も必要です。

14．運用・保守要件

システム完成後の管理方法も決めます。

例

ユーザー追加：
自社管理者

商品マスタ：
業務担当者

障害一次受付：
システム管理者

障害対応：
開発会社

バックアップ：
自動

問い合わせ：
社内管理者へ集約

特に、

誰がユーザーを追加するのか

誰がマスタを変更するのか

エラー時は誰へ連絡するのか

を決めておくと、リリース後に困りにくくなります。

15．制約条件

開発にはさまざまな制約があります。

例えば、

予算

納期

既存システム

指定クラウド

利用端末

会社のセキュリティルール

です。

テンプレート

予算：
300万円以内

希望リリース：
2026年12月

利用端末：
会社支給PC

インフラ：
AWS指定

その他：
既存Microsoft 365アカウントを利用したい

制約条件は早い段階で共有した方が、実現不可能な提案を減らせます。

16．対象外

対象範囲と同様に重要です。

例えば、

今回対象外：

・会計機能
・給与計算
・ネイティブアプリ
・AI需要予測
・既存会計システム連携

とします。

「書いていないから対象外」ではなく、

対象外であることを明記する

のがポイントです。

17．未決事項

要件定義中にすべて決まるとは限りません。

無理に確定させるより、未決事項として管理します。

テンプレート

ID	未決事項	担当	期限	影響
Q01	CSV形式	業務担当	8/10	CSV機能
Q02	データ移行範囲	PM	8/15	移行工数
Q03	メールサービス	開発会社	8/20	通知機能

これによって、

決まっていないこと自体を
チーム全員が認識する

ことができます。

18．スケジュール

最後に大まかな開発スケジュールを記載します。

例えば、

工程	期間
要件定義	8月
基本設計	9月
開発	10〜11月
テスト	12月前半
リリース	12月後半

要件定義段階では、詳細なWBSではなく全体の目安でも構いません。

中小企業向け要件定義書の簡易テンプレート

ここまでの内容でも多いと感じる場合は、次の簡易版から始めても構いません。

# 要件定義書

## 1. 開発目的

なぜシステムを作るのか：

解決したい課題：

## 2. 利用者

誰が利用するか：

何人利用するか：

## 3. 現在の業務

現在どのように仕事をしているか：

利用しているExcel・システム：

問題点：

## 4. システム導入後

新しい業務フロー：

人が行うこと：

システムが行うこと：

## 5. 必要機能

・

・

・

## 6. 管理するデータ

・

・

・

## 7. 権限

一般ユーザー：

管理者：

## 8. 非機能

利用人数：

利用時間：

セキュリティ：

バックアップ：

対応端末：

## 9. データ移行

既存データ：

移行対象：

## 10. 対象外

・

・

## 11. 予算・納期

予算：

希望納期：

## 12. 未決事項

・

・

従業員数十人程度で使う小規模な社内Webシステムであれば、まずこの程度から整理してもよいでしょう。

要件定義書はWord・Excel・スプレッドシートのどれがよい？

結論として、目的によって使い分けます。

Word・Google Docs

向いているもの：

開発背景

目的

業務フローの説明

非機能要件

運用要件

文章を中心に整理する場合に向いています。

Excel・Google Sheets

向いているもの：

機能一覧

画面一覧

データ項目

帳票一覧

権限一覧

未決事項

課題一覧

一覧形式の管理に向いています。

実務では組み合わせる

例えば、

Google Docs
↓
要件定義書本文

Google Sheets
↓
機能一覧
画面一覧
課題一覧

という構成です。

無理に一つのファイルへまとめる必要はありません。

要件定義書を作る順番

テンプレートの上から順番に埋めればよいとは限りません。

おすすめは、

1．開発目的

↓

2．現状業務

↓

3．課題

↓

4．新業務フロー

↓

5．対象範囲

↓

6．機能

↓

7．データ・権限

↓

8．非機能

↓

9．移行・運用

↓

10．未決事項

↓

11．全体レビュー

です。

いきなり、

どんな画面が必要ですか？

から始めると、機能ありきの要件定義になりやすくなります。

要件定義書作成でよくある失敗

失敗1｜テンプレートを全部埋めることが目的になる

要件定義の目的は、

空欄をゼロにする

ことではありません。

必要なのは、

発注者と開発者の認識を合わせる

ことです。

不要な項目は省略して構いません。

失敗2｜機能一覧しか作らない

例えば、

ログイン

検索

登録

CSV

管理画面

だけでは、なぜ必要なのか分かりません。

開発目的
↓
業務
↓
課題
↓
機能

という関係が重要です。

失敗3｜画面イメージだけで要件定義を終わらせる

画面イメージは非常に有効です。

しかし、

セキュリティ

権限

バックアップ

データ移行

外部連携

運用

は画面から分かりません。

ワイヤーフレームと要件定義書を併用します。

失敗4｜非機能要件を書かない

例えば開発後に、

実は24時間365日必要です

同時に500人使います

個人情報を保存します

と分かると、システム構成を見直す可能性があります。

IPAも非機能要求について、機能要求より発注者・開発者間で認識差が起こりやすい課題を指摘し、その確認方法として「非機能要求グレード」を公開しています。

失敗5｜対象外を書かない

最もトラブルになりやすいポイントの一つです。

発注者：
当然入っていると思った

開発者：
依頼されていない

という問題を防ぐため、

今回含めないもの

も明記します。

失敗6｜「いい感じに」など曖昧な表現を使う

例えば、

使いやすい画面

高速に表示

柔軟な検索

十分なセキュリティ

は曖昧です。

可能な範囲で、

商品名・コードから検索

主要画面は通常3秒以内

管理者のみ削除可能

などへ具体化します。

失敗7｜要件定義書を作った後に更新しない

要件定義中にも、

追加要望

変更

削除

未決事項の決定

が発生します。

資料には、

バージョン

更新日

更新者

を付けると管理しやすくなります。

例えば、

v0.1
初版

v0.2
権限要件追加

v1.0
要件定義確定

とします。

良い要件定義書の5つの条件

1．開発目的が明確

何のためのシステムか

が分かること。

2．対象範囲が明確

どこまで開発するか

が分かること。

3．利用者と業務が分かる

機能だけでなく、

誰がどの業務で利用するか

が分かること。

4．曖昧な表現が少ない

できるだけ確認可能な条件になっていること。

5．未決事項が明確

決まっていないことを隠さず管理できていること。

要件定義書は発注前に完成させる必要がある？

必ずしも必要ありません。

例えば、

Excelで顧客管理している

↓

業務が複雑になってきた

↓

システム化したい

↓

しかし必要な機能はまだ分からない

という状態でも、開発会社へ相談できます。

むしろ、業務システムの場合は、

完成した要件定義書を渡す

より、

現在の業務
+
課題
+
使っているExcel
+
希望する状態

を共有し、開発会社と一緒に要件整理する方法も有効です。

開発会社へ相談する前に最低限整理したい内容

要件定義書が完成していなくても、次の7点があると相談しやすくなります。

1．何に困っているか

2．現在どう業務をしているか

3．誰が使うか

4．現在使っているExcel・システム

5．絶対に必要なこと

6．予算感

7．希望時期

例えば、

現在Excelで50社程度の顧客を管理している。

営業担当5名で利用しており、
案件状況の共有が難しくなっている。

顧客・案件・対応履歴を
Web上で一元管理したい。

予算は100〜200万円程度。

年内リリース希望。

という情報でも、要件整理を始めることができます。

要件定義書に関するよくある質問

要件定義書に決まったフォーマットはありますか？

絶対的なフォーマットはありません。

IPAも、要件定義で作成する文書はプロジェクトによって異なると説明しています。

システム規模・業種・開発方法に合わせて必要な項目を選びます。

要件定義書は誰が作るのですか？

発注者と開発会社が協力して作るのが現実的です。

発注者は、

業務

課題

社内ルール

優先順位

を提供します。

開発会社は、

ヒアリング

システム化範囲整理

機能整理

非機能要件整理

技術的な実現方法の検討

を支援します。

要件定義書はExcelでもよいですか？

問題ありません。

特に、

機能一覧

画面一覧

権限一覧

データ一覧

などはExcel・Google Sheetsと相性があります。

背景や目的はWord・Google Docs、一覧はExcel・Sheetsという組み合わせもおすすめです。

小規模システムでも要件定義書は必要ですか？

必要です。

ただし、大規模開発と同じ量のドキュメントは必要ありません。

開発目的、業務フロー、機能、データ、権限、非機能、対象外など、重要項目へ絞って整理します。

非機能要件には何を書けばよいですか？

最低限、

利用時間

利用人数

性能

セキュリティ

バックアップ

障害対応

対応端末

を確認します。

より詳細に整理する場合は、IPAが公開している「非機能要求グレード」も参考になります。

要件定義書とRFPは同じですか？

異なります。

RFPは、開発会社へ、

このようなシステムを検討しているので
提案してください

と依頼するための提案依頼書です。

要件定義書は、実際に開発するシステムの要件を整理・合意する文書です。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく要件整理から対応しています。

例えば、

• 現状業務のヒアリング
• 既存Excel・業務フローの整理
• システム化範囲の整理
• 要件定義書作成
• 機能一覧作成
• 画面・ワイヤーフレーム整理
• データ項目整理
• 権限設計
• 非機能要件整理
• データ移行方針の整理
• 外部API・既存システム連携
• Java・Python・TypeScriptを利用したWebシステム開発

などを検討できます。

例えば現在、

Excel
↓
担当者が入力
↓
メールで共有
↓
別担当者が再入力
↓
月末に集計

という業務がある場合、

現状業務をヒアリング

↓

課題を整理

↓

不要な作業を確認

↓

新しい業務フローを設計

↓

必要機能を要件定義書へ整理

↓

設計・開発

という順番で進められます。

要件定義書は「立派な資料を作ること」が目的ではない

要件定義書のテンプレートを探すと、

数十項目

何十ページ

大量の専門用語

が並んだものも見つかります。

しかし、中小企業の業務システムで最初からすべてを詳細化する必要はありません。

重要なのは、

なぜ作るのか

誰が使うのか

現在どのような業務なのか

どの業務を変えるのか

何ができればよいのか

何は今回作らないのか

を発注者と開発者で共有できることです。

まずは今回紹介したテンプレートを使い、

1．開発目的

2．現状業務

3．課題

4．新しい業務フロー

5．利用者・権限

6．機能要件

7．データ要件

8．非機能要件

9．データ移行

10．運用

11．対象外

12．未決事項

を整理してみてください。

そして、

どの機能が必要か分からない

業務フロー自体を整理したい

既存Excelをどうシステム化すればよいか分からない

要件定義から開発会社へ相談したい

という場合は、要件定義書を完成させてから相談する必要はありません。

現在の業務や課題を共有しながら、一緒に要件を整理していくことも可能です。

要件定義・業務システム開発について相談する