1. はじめに
システム開発における要件定義は、プロジェクトの成否に大きく影響する重要な工程です。
しかし、実際に要件定義書を作成しようとすると、「何を書けばいいのか」「どこまで詳細に記載すべきか」など、悩むことが多いのではないでしょうか。
私自身も初めて要件定義書を作成した際、何から手をつければよいか分からず苦労した経験があります。先輩エンジニアや過去のドキュメントを参考にしながら試行錯誤を重ね、ようやく実務で使える要件定義書のテンプレートが固まってきました。
本記事ではそんな経験をもとに、要件定義書のテンプレートと具体的なサンプルをご紹介します。
2. 対象読者
- 初めて要件定義書を作成する方
- 要件定義の書き方に悩んでいる方
- 要件定義のテンプレートを探している方
- チーム内で要件定義のフォーマットを統一したい方
3. 要件定義の基礎知識
3.1 要求と要件の違い
要件定義を行う上で、まず理解しておくべきなのが「要求」と「要件」の違いです。
要求(Requirement)
- クライアントやユーザーが求めている内容
- 抽象的で曖昧な表現が含まれることが多い
- 「~したい」という文末で統一すると、要件と区別しやすい
- 例: 「注文を管理したい」「１つの画面でたくさんの情報を見たい」
要件(Specification)
- 要求を具体的に実現可能な形に落とし込んだもの
- 明確で測定可能な表現
- 例: 「管理画面に注文管理機能を作成」「一覧画にはxxx,yyy,zzzを表示」
要件定義とは、クライアントの「要求」を開発可能な「要件」に変換する作業です。
3.2 要件定義書の目的
要件定義書には主に以下の目的があります。
- 認識の統一
- 関係者全員がシステムの仕様を正しく理解できる
- 開発の指針
- 開発チームが何を作るべきか明確になる
- テストの基準
- 受入テストの基準が明確になる
- 契約の根拠
- 契約範囲の明確化とトラブル防止
3.3 要件定義で押さえるべきポイント
要件定義書を作成する際は、以下のポイントを意識しましょう。
具体性
- 曖昧な表現を避け、具体的な数値や条件を記載する
- NG: 「高速に動作する」 → OK: 「応答時間3秒以内」
測定可能性
- 実装後に確認・テストできる内容にする
- NG: 「使いやすい画面」 → OK: 「登録は2画面遷移以内で完了し、必須入力項目は3項目以内とする」
網羅性
- 機能要件だけでなく、非機能要件も漏れなく記載する
- セキュリティ、性能、運用・保守なども考慮
対応性
- 要求から要件、機能への紐付けを明確にする
- 変更時の影響範囲を追跡できるようにする
4. 要件定義書テンプレート解説
4.1 要件定義書テンプレート全文
以下に要件定義書のテンプレート全文を掲載します。
このテンプレートをコピーして、中身を埋めていくことで要件定義書が作成できます。
また、ChatGPTやClaudeなどのAIに要件定義を作成させる際は、このテンプレートをプロンプトに含めることで、構造化された要件定義を生成できます。具体的な活用方法は6章と7章で解説します。
要件定義テンプレート
要件定義書テンプレート全文
# 要件定義書テンプレート
## 1. 文書情報
### 1.1 改訂履歴
| 版数 | 日付 | 更新者 | 更新内容 |
| ---- | ---------- | --------- | -------- |
| 0.1 | YYYY/MM/DD | 〇〇 〇〇 | 初版作成 |
## 2. プロジェクト概要
### 2.1 背景と目的
[プロジェクトの背景と目的を記述します。なぜこのシステムが必要なのか、どのような課題を解決するのかを明確に説明します。クライアントからの要望や市場の課題、現状の問題点などを含めて記載します。]
## 3. 要件定義
### 3.1 要求一覧
| 要求No. | 要求内容 |
| ------- | ---------------- |
| R1 | [要求内容を記述] |
| R2 | [要求内容を記述] |
| R3 | [要求内容を記述] |
| R4 | [要求内容を記述] |
| R5 | [要求内容を記述] |
### 3.2 機能一覧
| 機能No. | 要求No. | 機能名 | 内容 |
| ------- | ------- | -------- | ---------------- |
| F1 | R1 | [機能名] | [機能の詳細説明] |
| F2 | R1,R2 | [機能名] | [機能の詳細説明] |
| F3 | R3 | [機能名] | [機能の詳細説明] |
| F4 | R4 | [機能名] | [機能の詳細説明] |
| F5 | R5 | [機能名] | [機能の詳細説明] |
### 3.3 プロジェクトスコープ
本プロジェクトの範囲は、[プロジェクトの範囲を明確に定義します。含まれる機能や対象ユーザー、対象業務などを記述します。]
**スコープ内**
| 機能No. | 機能名 | スコープ内容 |
| ------- | -------- | ------------------------------------------------------------------- |
| F1 | [機能名] | ・[詳細な機能内容1]<br/>・[詳細な機能内容2]<br/>・[詳細な機能内容3] |
| F2 | [機能名] | ・[詳細な機能内容1]<br/>・[詳細な機能内容2] |
| F3 | [機能名] | ・[詳細な機能内容1]<br/>・[詳細な機能内容2] |
**スコープ外**
次の項目は本プロジェクトではスコープ外とする。
- [スコープ外項目1]
- [スコープ外項目2]
- [スコープ外項目3]
- [スコープ外項目4]
## 4. ユーザー区分
| ユーザー区分 | 説明 | 人数(想定) | 主な利用機能 |
| -------------------- | ------------------------------------ | ------------ | -------------------------------------- |
| 管理者 | システム全体の管理権限を持つユーザー | XX名 | ユーザー管理、マスタ管理、各種設定機能 |
| 一般ユーザー | 通常の業務機能を利用するユーザー | XX名 | 検索、登録、更新、レポート出力 |
| 閲覧専用ユーザー | 参照のみ可能なユーザー | XX名 | 検索、レポート閲覧 |
| システム連携ユーザー | 外部システムとの連携用アカウント | - | API連携 |
## 5. ユーザーフロー
### 5.1 [メインフロー名]
```mermaid
flowchart TD
Start([フロー開始]):::start
Step1[ユーザー操作1<br/>・詳細内容1<br/>・詳細内容2]:::user
Step2[システム処理1]:::system
Decision{判定条件}:::system
Step3[ユーザー操作2]:::user
Step4[システム処理2]:::system
End([フロー終了]):::endstyle
Start --> Step1
Step1 --> Step2
Step2 --> Decision
Decision -->|条件A| Step3
Decision -->|条件B| Step4
Step3 --> End
Step4 --> End
%% スタイル定義
classDef start fill:#c8e6c9,stroke:#4caf50,stroke-width:2px;
classDef endstyle fill:#ffcdd2,stroke:#f44336,stroke-width:2px;
classDef user fill:#e3f2fd,stroke:#2196f3,stroke-width:2px;
classDef system fill:#fff3e0,stroke:#ff9800,stroke-width:2px;
\```
**特記事項**
- [フローの補足説明]
- [制約事項や前提条件]
### 5.2 [サブフロー名]
[必要に応じて追加のフローを記載]
## 6. システム概要
### 6.1 構成案
```mermaid
flowchart TD
%% ユーザー
User[ユーザー]:::user
Admin[管理者]:::admin
%% フロントエンド
subgraph Frontend[フロントエンド]
style Frontend fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
WebUI[Web画面]:::frontend
AdminUI[管理画面]:::frontend
end
%% API層
subgraph API[API層]
style API fill:#c5e1a5,stroke:#689f38,stroke-width:2px
MainAPI[メインAPI]:::api
AdminAPI[管理API]:::api
end
%% 外部サービス
subgraph External[外部サービス]
style External fill:#f8bbd0,stroke:#c2185b,stroke-width:2px
ExternalService[外部サービス]:::external
end
%% データストア
subgraph DataStore[データストア]
style DataStore fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px
Database[データベース]:::db
end
%% 接続関係
User -->|操作| WebUI
Admin -->|管理| AdminUI
WebUI -->|API呼出| MainAPI
AdminUI -->|API呼出| AdminAPI
MainAPI -->|データ操作| Database
AdminAPI -->|データ操作| Database
MainAPI <-->|連携| ExternalService
%% スタイル定義
classDef user fill:#fff59d,stroke:#fbc02d,stroke-width:2px,rx:20,ry:20;
classDef admin fill:#ffccbc,stroke:#d84315,stroke-width:2px,rx:20,ry:20;
classDef frontend fill:#bbdefb,stroke:#1976d2,stroke-width:2px,rx:10,ry:10;
classDef api fill:#a5d6a7,stroke:#388e3c,stroke-width:2px,rx:10,ry:10;
classDef external fill:#f48fb1,stroke:#ad1457,stroke-width:2px,rx:10,ry:10;
classDef db fill:#ffcc80,stroke:#e65100,stroke-width:2px;
\```
### 6.2 コンポーネント説明
| コンポーネント種別 | コンポーネント | 説明 | 備考 |
| ------------------ | -------------- | ---------------------------------- | -------------------- |
| **フロントエンド** | | | |
| フロントエンド | Web画面 | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
| フロントエンド | 管理画面 | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
| **API層** | | | |
| API | メインAPI | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
| API | 管理API | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
| **データストア** | | | |
| データベース | データベース | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
| **外部サービス** | | | |
| 外部システム | 外部サービス | [コンポーネントの役割と機能を説明] | [技術情報、制約事項] |
### 6.3 外部システム連携
| 連携システム名 | 連携方向 | 連携内容 | 連携方式 | 連携頻度 |
| ---------------- | -------- | ---------------------------- | ---------- | -------------- |
| 〇〇システム | 送信 | [連携するデータや処理の内容] | API (REST) | リアルタイム |
| 〇〇データベース | 受信 | [連携するデータや処理の内容] | バッチ | 日次 |
| 〇〇サービス | 双方向 | [連携するデータや処理の内容] | API (SOAP) | リアルタイム |
| 〇〇クラウド | 送受信 | [連携するデータや処理の内容] | Webhook | イベント発生時 |
## 7. 非機能要件
### 7.1 性能要件
**7.1.1 応答時間**
| 処理内容 | 目標応答時間 | 備考 |
| -------------------- | ------------ | ------------------------ |
| 画面表示 | 2秒以内 | 通常の一覧表示、詳細表示 |
| 検索処理 | 3秒以内 | 条件指定による検索処理 |
| レポート生成 | 10秒以内 | 標準的なレポート出力 |
| ファイルダウンロード | 5秒以内 | 5MB以下のファイル |
| ファイルアップロード | 10秒以内 | 10MB以下のファイル |
**7.1.2 同時接続ユーザー数**
- 通常時: XX ユーザー
- ピーク時: XX ユーザー
**7.1.3 データ量**
- 初期データ量: 約XXレコード(約XXMB)
- 年間増加量: 約XXレコード(約XXMB)
- 想定最大データ量: 約XXレコード(約XXMB)
### 7.2 セキュリティ要件
**7.2.1 認証・認可**
- [認証方式の説明]
- [アクセス制御方式の説明]
- [パスワードポリシーの説明]
- [アカウントロックの条件]
- [セッション管理の方法]
**7.2.2 データ保護**
- 通信の暗号化: [暗号化方式、バージョン]
- 保存データの暗号化: [暗号化対象、方式]
- アクセスログの取得: [ログ取得対象、保存期間]
**7.2.3 脆弱性対策**
- [対応する脆弱性対策基準]
- [セキュリティテストの実施方法と頻度]
- [インシデント対応計画]
### 7.3 運用・保守要件
**7.3.1 バックアップ**
- バックアップ頻度: [頻度を記載]
- バックアップ方式: [方式を記載]
- 保存期間: [期間を記載]
- リストア手順: [概要を記載]
**7.3.2 監視**
- [監視対象リソース]
- [監視項目と閾値]
- [アラート通知方法]
- [障害検知と対応フロー]
### 7.4 互換性要件
**7.4.1 ブラウザ対応**
| ブラウザ | バージョン | 備考 |
| ------------- | ---------------- | ---------- |
| Google Chrome | [対応バージョン] | [補足情報] |
| Safari | [対応バージョン] | [補足情報] |
**7.4.2 デバイス対応**
| デバイス | 画面サイズ | 備考 |
| -------------- | ---------------- | ---------- |
| PC | [対応画面サイズ] | [補足情報] |
| タブレット | [対応画面サイズ] | [補足情報] |
| スマートフォン | [対応画面サイズ] | [補足情報] |
### 7.5 技術選定
| 項目 | 説明 | 備考 |
| -------------- | ----------------------------------- | -------------------- |
| フロントエンド | [使用技術、フレームワーク] | [選定理由、制約事項] |
| バックエンド | [使用技術、フレームワーク] | [選定理由、制約事項] |
| データベース | [使用するDB] | [選定理由、制約事項] |
| インフラ環境 | [クラウド/オンプレミス、サービス名] | [選定理由、制約事項] |
| 開発環境 | [開発ツール、CI/CD] | [選定理由、制約事項] |
### 7.6 制限事項
| 項目 | 制限値 | 備考 |
| ----------- | -------- | ---------------------- |
| [制限項目1] | [制限値] | [エラー対応、補足説明] |
| [制限項目2] | [制限値] | [エラー対応、補足説明] |
| [制限項目3] | [制限値] | [エラー対応、補足説明] |
## 8. 前提条件・制約条件
### 8.1 前提条件
- [前提条件1]
- [前提条件2]
- [前提条件3]
### 8.2 制約条件
- [制約条件1]
- [制約条件2]
- [制約条件3]
## 9. 添付資料
- 添付資料1: [資料名]
- 添付資料2: [資料名]
- 添付資料3: [資料名]
(テンプレート終わり)
5. 要件定義書テンプレート解説
5.1 文書情報
ここからは、要件定義書の各セクションについて簡単に説明します。
改訂履歴を記録することで、ドキュメントの変更管理を行います。
誰がいつ何を変更したのかを明確にすることで、仕様変更の経緯を追跡できます。
5.2 プロジェクト概要
「背景と目的」では、なぜこのシステムが必要なのかを記載します。「なぜ」の部分は記載が漏れやすい部分ではありますが、根拠となる部分のため、非常に重要です。
クライアントの課題など、プロジェクトの根拠を明確にすることで、開発の方向性がブレにくくなります。
5.3 要件定義
「要求一覧」では、クライアントから出された要求を列挙します。
ここでは抽象的な表現でも問題ありません。クライアントからの要求を漏れなく拾い上げることが重要です。
「機能一覧」では、要求を実現するための具体的な機能を定義します。
各機能には要求番号を紐付けることで、要求の漏れを防ぎます。
「プロジェクトスコープ」では、何を作り、何を作らないのかを明確にします。
特にスコープ外の項目を明示することで、後のトラブルを防ぐことができます。
5.4 ユーザ区分
システムを利用するユーザー区分を定義します。
各ユーザーの役割、想定人数、利用機能を明確にすることで、画面設計や権限設計の基準になります。
5.5 ユーザーフロー
ユーザーの操作フローを視覚化します。
画面遷移や処理の流れを図示することは、文言だけの説明に比べて比較的把握しやすくなります。
5.6 システム概要
システムの全体構成を示します。
フロントエンド、バックエンド、データベース、外部サービスなどの関係性を明確にします。
5.7 非機能要件
性能、セキュリティ、運用・保守など、機能以外の要件を定義します。
機能要件に比べて軽視されがちな部分ではありますが、
検討が不十分の場合は後工程で大きな手戻りが発生する可能性があります。
5.8 前提条件・制約条件
開発の前提となる条件や、技術的・ビジネス的な制約を記載します。
これにより、関係者間での認識のズレを防ぎます。
6. サンプル要件定義: Todoアプリ
ここからは、実際のTodoアプリを題材に、AIを活用した要件定義書の作成例を紹介します。
前章で紹介したテンプレートを使って、AIに要件定義を作成させる実践例を示します。
以下のようなプロンプトで、AIにTodoアプリの要件定義書を作成させることができます。
添付した要件定義書テンプレートを使って、以下の要件でTodo管理アプリの要件定義書を新規作成してください。
## プロジェクト情報
- 対象: 個人利用を想定したシンプルなTodo管理アプリ
- 背景: 紙のメモやExcelでのタスク管理の課題を解決したい
- 主な機能: タスクのCRUD、完了管理、期限設定、検索・フィルタリング
- ユーザー認証: 必要(個人ごとにタスクを管理)
## スコープ外としたいもの
- チーム機能(タスク共有、割り当て)
- モバイルアプリ
- 外部カレンダー連携
- リマインダー通知
## 要求事項
1. タスクの登録・編集・削除ができる
2. タスクの完了状態を管理できる
3. タスクに期限を設定できる
4. ユーザーごとにタスクを管理できる
5. タスクを検索・フィルタリングできる
このようなプロンプトに、テンプレートファイルを添付することで、要件定義書を効率的に生成できます。
以下は、このプロンプトで生成された要件定義です。
実務では生成された要件定義をベースに、関係者とレビューを重ねて完成度を高めていく想定です。そのまま使うのではなく、あくまでドラフトとして活用することを強く推奨します。
生成されたTodoアプリの要件定義書
Todo管理アプリ 要件定義書
1. 文書情報
1.1 改訂履歴
| 版数 | 日付 | 更新者 | 更新内容 |
|---|---|---|---|
| 0.1 | 2025/12/20 | AI | 初版作成 |
2. プロジェクト概要
2.1 背景と目的
個人のタスク管理において、紙のメモやExcelを利用した管理では以下の課題が存在する。
- タスクの進捗状況が可視化されにくい
- タスクの検索や絞り込みが困難
- 期限管理が煩雑で見落としが発生しやすい
- 過去のタスク履歴の追跡が難しい
- データの紛失リスクがある
これらの課題を解決するため、個人利用を想定したシンプルで使いやすいTodo管理Webアプリケーションを開発する。
タスクの登録から完了までをスムーズに管理でき、期限やステータスで効率的に整理できるシステムを提供することで、個人のタスク管理の効率化と生産性向上を図ることを目的とする。
3. 要件定義
3.1 要求一覧
| 要求No. | 要求内容 |
|---|---|
| R1 | タスクの登録・編集・削除ができるようにしたい |
| R2 | タスクの完了状態を管理したい |
| R3 | タスクに期限を設定できるようにしたい |
| R4 | ユーザーごとにタスクを管理したい |
| R5 | タスクを検索・フィルタリングしたい |
3.2 機能一覧
| 機能No. | 要求No. | 機能名 | 内容 |
|---|---|---|---|
| F1 | R4 | ユーザー登録 | 新規ユーザーのアカウント作成機能(メールアドレス、パスワード) |
| F2 | R4 | ユーザー認証 | メールアドレスとパスワードによるログイン・ログアウト機能 |
| F3 | R1 | タスク登録 | タイトル、説明、期限を入力してタスクを新規作成 |
| F4 | R1 | タスク編集 | 登録済みタスクの内容(タイトル、説明、期限)を変更 |
| F5 | R1 | タスク削除 | 不要になったタスクを削除 |
| F6 | R2 | タスク完了 | タスクを完了状態に変更し、完了日時を記録 |
| F7 | R2 | タスク未完了化 | 完了状態のタスクを未完了状態に戻す |
| F8 | R5 | タスク一覧表示 | 登録されているタスクを一覧表示 |
| F9 | R5 | ステータスフィルタ | 未完了・完了でタスクをフィルタリング表示 |
| F10 | R5 | タスク検索 | タイトルや説明文での部分一致検索 |
| F11 | R3 | 期限表示 | タスク一覧で期限が近いタスク(3日以内)を強調表示 |
3.3 プロジェクトスコープ
本プロジェクトの範囲は、個人向けシンプルTodo管理機能の提供とする。
スコープ内
| 機能No. | 機能名 | スコープ内容 |
|---|---|---|
| F1-F2 | ユーザー管理 | ・メールアドレス/パスワードによる認証 ・新規ユーザー登録 ・ユーザーごとのタスク完全分離 |
| F3-F7 | タスク管理 | ・タスクのCRUD操作 ・タスクの完了/未完了状態管理 ・期限設定機能 |
| F8-F11 | タスク表示 | ・一覧表示とステータスフィルタリング ・タイトル/説明での部分一致検索 ・期限が近いタスクの強調表示 |
スコープ外
次の項目は本プロジェクトではスコープ外とする。
- チーム機能(タスクの共有、他ユーザーへの割り当て、権限管理)
- モバイルアプリ(iOS、Android)
- 外部カレンダー連携(Googleカレンダー、Outlookカレンダーとの同期)
- リマインダー通知(メール通知、プッシュ通知)
- タスクの優先度設定
- タスクのカテゴリ分類・タグ付け機能
- サブタスク機能
- ファイル添付機能
- コメント・メモ機能
- タスクの繰り返し設定
4. ユーザー区分
| ユーザー区分 | 説明 | 人数(想定) | 主な利用機能 |
|---|---|---|---|
| 一般ユーザー | タスク管理を行う個人ユーザー | 制限なし | タスクのCRUD、完了管理、検索、フィルタリング |
5. ユーザーフロー
5.1 タスク登録フロー
特記事項
- タイトルは必須項目(最大200文字)
- 説明は任意項目(最大1000文字)
- 期限は任意項目(未来の日付のみ設定可能)
5.2 タスク完了フロー
特記事項
- 完了済みタスクは打ち消し線で表示
- 完了日時はタスク詳細で確認可能
- 完了済みタスクも未完了に戻すことが可能
6. システム概要
6.1 構成案
6.2 コンポーネント説明
| コンポーネント種別 | コンポーネント | 説明 | 備考 |
|---|---|---|---|
| フロントエンド | |||
| フロントエンド | Web画面 | ユーザーインターフェースを提供。タスクのCRUD操作、検索、フィルタリングを実装 | React または Vue.js を推奨 |
| API層 | |||
| API | REST API | フロントエンドからのリクエストを受け取り、ビジネスロジックを実行 | RESTful API設計、JWT認証を実装 |
| データストア | |||
| データベース | データベース | ユーザー情報、タスクデータを永続化 | MySQL または PostgreSQL を推奨 |
6.3 外部システム連携
本プロジェクトでは外部システムとの連携は行わない。
7. 非機能要件
7.1 性能要件
7.1.1 応答時間
| 処理内容 | 目標応答時間 | 備考 |
|---|---|---|
| 画面表示 | 2秒以内 | 初回ロード時 |
| タスク一覧取得 | 1秒以内 | 100件以下のタスク表示 |
| タスク登録 | 1秒以内 | 通常の入力内容 |
| タスク編集 | 1秒以内 | 通常の入力内容 |
| タスク削除 | 1秒以内 | 削除処理 |
| 検索処理 | 2秒以内 | 全文検索 |
7.1.2 同時接続ユーザー数
- 通常時: 10ユーザー
- ピーク時: 20ユーザー
7.1.3 データ量
- 初期データ量: 0レコード
- 年間増加量: ユーザーあたり約500レコード
- 想定最大データ量: ユーザーあたり約2000レコード
7.2 セキュリティ要件
7.2.1 認証・認可
- 認証方式: メールアドレス/パスワード認証
- アクセス制御: ユーザーは自分のタスクのみアクセス可能
- パスワードポリシー: 8文字以上、英数字を含む
- アカウントロック: 5回連続ログイン失敗で30分間ロック
- セッション管理: JWT トークンによるステートレス認証(有効期限24時間)
7.2.2 データ保護
- 通信の暗号化: HTTPS(TLS 1.2以上)
- 保存データの暗号化: パスワードはbcryptでハッシュ化
- アクセスログの取得: 全APIアクセスログを取得、30日間保存
7.2.3 脆弱性対策
- OWASP Top 10 に基づくセキュリティ対策を実施
- SQLインジェクション対策: プリペアドステートメント使用
- XSS対策: 入力値のサニタイジング、エスケープ処理
- CSRF対策: トークン検証の実装
7.3 運用・保守要件
7.3.1 バックアップ
- バックアップ頻度: 日次(毎日深夜2時)
- バックアップ方式: データベースフルバックアップ
- 保存期間: 30日間
- リストア手順: バックアップファイルからのリストアスクリプトを用意
7.3.2 監視
- サーバーCPU使用率、メモリ使用率(閾値: 80%)
- データベース接続数(閾値: 最大接続数の80%)
- API応答時間(閾値: 3秒)
- エラーログの監視(5分間に10件以上でアラート)
7.4 互換性要件
7.4.1 ブラウザ対応
| ブラウザ | バージョン | 備考 |
|---|---|---|
| Google Chrome | 最新版 | 推奨 |
| Firefox | 最新版 | 推奨 |
| Safari | 最新版 | 対応 |
| Edge | 最新版 | 対応 |
7.4.2 デバイス対応
| デバイス | 画面サイズ | 備考 |
|---|---|---|
| PC | 1024px以上 | メイン対応 |
| タブレット | 768px〜1023px | レスポンシブ対応 |
| スマホ | スコープ外 | 今回は対応しない |
7.5 技術選定
| 項目 | 説明 | 備考 |
|---|---|---|
| フロントエンド | Next.js | コンポーネントベース開発、保守性の高さ |
| バックエンド | Laravel | REST API実装の容易さ、豊富なライブラリ |
| データベース | MySQL | リレーショナルデータの管理に適している |
| インフラ環境 | AWS (ECS, RDSなど) | スケーラビリティ、コスト効率 |
| 開発環境 | Git、GitHub、Github Actions | バージョン管理、チーム開発対応 |
7.6 制限事項
| 項目 | 制限値 | 備考 |
|---|---|---|
| タスクタイトル文字数 | 200文字 | 超過時はエラーメッセージを表示 |
| タスク説明文字数 | 1000文字 | 超過時はエラーメッセージを表示 |
| 同時登録タスク数 | 制限なし | ただし、パフォーマンス考慮で表示は100件まで推奨 |
| ファイルアップロード | 対応なし | スコープ外 |
8. 前提条件・制約条件
8.1 前提条件
- ユーザーはインターネット接続環境を持つ
- ユーザーは対応ブラウザの最新版を使用する
- ユーザーは有効なメールアドレスを持つ
8.2 制約条件
- 開発期間は3ヶ月以内とする
- 初期リリースは個人利用に特化し、チーム機能は対応しない
- モバイルアプリは提供せず、Webアプリケーションのみとする
- 外部サービスとの連携機能は提供しない
(サンプル終わり)
7. 活用時のポイント・注意点
昨今のAI技術の進化により、要件定義書の作成を効率化できます。
ここでは、AIを活用する際のポイントや注意点を紹介します。
レビューは必ず実施する
- 必ず関係者でレビューを実施
- クライアント、開発チーム、テスト担当など、多角的な視点でチェック
- 曖昧な表現や矛盾がないか確認
テンプレートはプロジェクトに合わせてカスタマイズ
- プロジェクト規模に合わせて項目を増減させる
- 業界やドメインに応じて項目を追加
図解を積極的に活用
- テキストだけで伝わりにくい部分は図で表現
- 第三者にとっては文言だけの説明は想像以上に伝わりにくい
具体的な情報を明確に伝える
- プロジェクトの背景、目的、主要機能を明確に記載
- スコープ外の項目も明示することで、不要な機能が含まれるのを防ぐ
段階的に詳細化していく
- 最初は大枠を作成し、徐々に詳細を詰めていく
- 一度に完璧な要件定義を求めない
- 生成された要件定義をレビューし、不足部分を追加で依頼
8. さいごに
要件定義は、システム開発の中で重要な工程です。
本記事で紹介したテンプレートとサンプルが、皆さんの実務で役立てば幸いです。
最初は完璧な要件定義書を作ることを目指すのではなく、
何度も書いていくうちに、自分なりのコツやポイントが見えてくるはずです。
本記事のテンプレートは、あくまで一例です。
プロジェクトの規模や特性に応じて、柔軟にカスタマイズしてご利用ください！
テンプレートにこだわりすぎず、関係者にとって分かりやすい記載を心掛けることが一番大事です！