はじめに：要件定義書ってなに？
システム開発を始める前に「何を作るのか」「なぜ作るのか」を明確にするために必要なのが 要件定義書 です。
この文書がしっかり作られていないと…
- 開発後に「こんな機能じゃなかった」と言われる
- 無駄な工数が発生して予算オーバー
- チーム内の認識ズレで炎上
といったトラブルが起こる可能性も。
この記事では、実際の「勤怠管理システム」構築例を使いながら、初心者でも書ける要件定義書の書き方をわかりやすく解説します。
1. システム化の目的を書く
書き方のポイント
- なぜこのシステムが必要なのか
- 今の業務のどこに問題があり、どう改善するか
具体例
本システムの導入目的は、従業員の勤怠情報をWEB上で効率的かつ正確に管理することで、総務部門の業務負荷軽減および処理時間の短縮を図ることにある。
現在、紙の勤務表をメールで提出・確認・手入力しているプロセスをデジタル化することにより、処理工数を削減し、業務の生産性向上を実現する。
2. 現状分析を行う
書き方のポイント
- 現在の業務フローを記述
- 問題点を「見える化」する
具体例
2.1 勤怠管理業務の流れ（現行）
- 各従業員が月次で紙の勤務表を作成し、PDFまたはスキャンしたものを総務にメールで提出
- 総務担当者がメール添付の勤務表を開き、内容を確認
- 勤務時間情報を社内システムやExcelに手入力
2.2 問題点
- 作業時間の多さ：1人あたり10分 × 60人 = 月間600分（10時間）
- 年間作業時間：10時間 × 12ヶ月 = 120時間
- ヒューマンエラーのリスク：手入力ミスが発生する可能性
3. システム要件を定義する
書き方のポイント
- 機能要件：システムで「何ができるか」
- 非機能要件：セキュリティや操作性などの「使いやすさ」
3.1 機能要件
| 機能名 | 概要 |
|---|---|
| 勤怠入力機能 | 従業員がWEB画面から勤務実績（日別）の入力を行う |
| 勤怠一覧表示 | 総務が全社員の勤怠情報を一覧表示・確認できる機能 |
3.2 非機能要件
- セキュリティ：HTTPS通信、パスワード暗号化、アクセス制限
- 操作性：直感的なUI、マニュアルなしでも使える
- 可用性：99%以上の稼働率を確保
- 拡張性：年休管理や在宅勤務申請機能の追加を想定
- 保守性：ログ取得、障害時の通知機能を実装
4. 効果試算を書く
書き方のポイント
- 具体的な数字で導入効果を示す
具体例
| 項目 | 月間処理時間 | 年間処理時間 |
|---|---|---|
| 導入前 | 600分（10時間） | 120時間 |
| 導入後 | 300分（5時間） | 60時間 |
→ 年間で 60時間の作業時間削減
→ 総務部門の生産性向上と業務効率化に貢献！
5. 利用対象者を明確にする
| ユーザー区分 | 利用目的 |
|---|---|
| 従業員 | 勤怠の入力・提出 |
| 総務担当者 | 勤怠の確認・集計・管理 |
6. スケジュール（案）を書く
| フェーズ | 期間 | 内容 |
|---|---|---|
| 要件定義 | 6月中旬 | 要件定義書の確定 |
| 設計 | 6月下旬〜7月上旬 | UI設計・DB設計 |
| 開発 | 7月中旬〜8月末 | 実装・テスト |
| 試験運用 | 9月 | 一部部署で試験導入 |
| 本番導入 | 10月 | 全社展開開始 |
まとめ
要件定義書は、プロジェクトの「地図」です。
目的・背景・必要な機能・スケジュールなどを明確にすることで、関係者間の認識ズレを防ぎ、プロジェクト成功に導きます。
開発の大前提となる資料なのでしっかりと認識のズレがないようにしましょう。
今回ご紹介したフォーマットと実例を参考に、ぜひあなたのプロジェクトにも活かしてください！
🎁 おまけ：要件定義書テンプレートがほしい方へ
先ほどの記事で解説した要件定義書を以下に作成しましたので、
使ってください。
【付録】勤怠管理システム 要件定義書（サンプル）
1. システム化の目的
本システムの導入目的は、従業員の勤怠情報をWEB上で効率的かつ正確に管理することで、総務部門の業務負荷軽減および処理時間の短縮を図ることにある。
現在、紙の勤務表をメールで提出・確認・手入力しているプロセスをデジタル化することにより、処理工数を削減し、業務の生産性向上を実現する。
2. 現状分析
2.1 勤怠管理業務の流れ（現行）
- 各従業員が月次で紙の勤務表を作成し、PDFまたはスキャンしたものを総務にメールで提出。
- 総務担当者がメール添付の勤務表を開き、内容を確認。
- 各勤務時間情報をExcelに手入力。
2.2 問題点
- 作業時間の多さ：確認・入力に1人あたり10分、対象従業員数が60名のため、月間600分（10時間）を要している。
- 年間コスト：10時間 × 12ヶ月 = 120時間
- ヒューマンエラーのリスク：手入力によるミスの可能性がある。
3. システム要件
3.1 機能要件
| 機能名 | 概要 |
|---|---|
| 勤怠入力機能 | 従業員がWEB画面から勤務実績（日別）の入力を行う |
| 勤怠一覧表示 | 総務が全社員の勤怠情報を一覧表示・確認できる機能 |
3.2 非機能要件
- 操作性：直感的なUI設計、マニュアルなしでも操作可能な画面構成。
- 可用性：99%以上の稼働率を目指す。
- 拡張性：将来的に年次有給休暇や在宅勤務申請機能の追加を想定。
4. 効果試算
| 項目 | 月間 | 年間 |
|---|---|---|
| 従来 | 600分（10時間） | 120時間 |
| システム導入後 | 300分（5時間） | 60時間 |
- 年間60時間の作業時間削減が見込まれ、総務部門の生産性向上および業務効率化に寄与する。
5. 利用対象者
| ユーザー区分 | 利用目的 |
|---|---|
| 従業員 | 勤怠の入力・提出 |
| 総務担当者 | 勤怠確認・集計・管理 |
6. スケジュール（案）
| フェーズ | 期間 | 内容 |
|---|---|---|
| 要件定義 | 6月中旬 | 本ドキュメントの確定 |
| 設計 | 6月下旬〜7月上旬 | UI設計、DB設計 |
| 開発 | 7月中旬〜8月末 | 実装・内部テスト |
| 試験運用 | 9月 | 一部部署で試験導入 |
| 本番導入 | 10月 | 全社展開開始 |
7. リスクと対応
| リスク | 対応策 |
|---|---|
| 社員のITリテラシーによる導入障壁 | 操作マニュアルや動画チュートリアルを用意 |
| サーバ障害・アクセス不能 | クラウドインフラでの冗長化構成を採用 |
| 勤怠不正入力 | 承認フロー、ログ監視機能で抑止 |