要件定義の業務手順書テンプレート（受託開発・情報システム）
発注者の業務と困りごとを聞き取り、機能要件・非機能要件・移行・運用を整理して、要件定義書として承認をもらうまでの流れです。手順書にすると、聞き漏れによる後からの仕様変更や、承認があいまいなまま設計に進むことを防げます。
この手順書の範囲
- 目的
- 要件定義の進め方と確認項目をそろえ、承認された要件を設計・見積の土台にできるようにします。
- 範囲
- キックオフから、要件定義書の承認と、設計工程の見積の提示までです。
- 始まるきっかけ
- 準委任契約などで要件定義の工程を受注したとき
- 頻度・量の目安
- 案件ごと・1〜3か月（中規模で打ち合わせ8〜20回）
- 使う書類・システム
- 提案書・見積書・契約書、現行の業務フロー・帳票・画面、現行システムの資料、要件定義チェックリスト
担当と役割
プロジェクトマネージャー（PM）
計画、課題の管理、発注者との合意形成
システムエンジニア（SE）
業務の聞き取り、要件の整理、要件定義書の作成
発注者の業務担当・情報システム担当
業務の説明、要件の確認と承認
手順（13ステップ）
- 計画PM・目安 1日
1. 要件定義の計画を立てる
打ち合わせの回数と議題、参加者、成果物（要件定義書の目次）、承認の方法と時期を決めます。
- 確かめること
- 発注者側の決裁者と、承認に必要な日数を確かめる。
- できあがるもの
- 要件定義の計画書
- 計画PM・目安 1時間
2. キックオフで役割と進め方を合意する
双方の体制、連絡の窓口、課題の管理方法、変更の扱いを説明します。
- 確かめること
- 契約が準委任か請負かと、成果物の範囲を確かめる。
- できあがるもの
- キックオフの議事録
- 現状把握SE・目安 2〜5回
3. 現行の業務を聞き取る
業務の流れ、担当者、使う帳票・Excel、月の件数、例外処理を聞き取ります。
- 確かめること
- 「たまにある」例外は、月の件数と発生条件まで聞く。
- できあがるもの
- 現行業務フロー
4. 現行の帳票と画面を集めて項目を洗い出す
帳票・Excel・画面の項目を一覧にし、どこで入力されどこで使われるかを書きます。
- 確かめること
- 紙の帳票は記入済みのサンプルももらう。
- できあがるもの
- 項目一覧
- 要件整理SE・目安 1日
5. 課題と要望を整理する
聞き取った困りごとを、システムで解決するもの・運用で解決するもの・今回は対象外のものに分けます。
- 確かめること
- 対象外にしたものも理由とともに残す。
- できあがるもの
- 要望一覧
- 要件整理SE・目安 3〜5日
6. 機能要件をまとめる
画面、帳票、データ、外部連携、バッチ処理ごとに、誰が・何を・どうできるかを書きます。
- 確かめること
- 業務フローの全工程に、対応する機能か運用が割り当たっている。
- できあがるもの
- 機能一覧・画面一覧
- 要件整理SE・目安 2日
7. 非機能要件をまとめる
性能（応答時間・件数）、可用性（稼働時間・停止許容）、セキュリティ、バックアップ、保守の時間帯を数字で決めます。
- 確かめること
- 「速く」ではなく「検索結果を3秒以内に表示」のように数字で書く。
- できあがるもの
- 非機能要件一覧
- 要件整理SE・目安 2日
8. データ移行と運用の要件をまとめる
移行するデータの範囲と期間、移行の方法、運用の体制、問い合わせの窓口を決めます。
- 確かめること
- 移行元データの品質（重複・欠損）を確かめる方法を決める。
- できあがるもの
- 移行・運用要件
9. 未決の課題を課題管理表で追う
課題ごとに担当、期限、決まった内容を記録し、毎回の打ち合わせで確かめます。
- 確かめること
- 期限を過ぎた課題は、決裁者に判断を依頼する。
- できあがるもの
- 課題管理表
- レビューSE・目安 2日
10. 要件定義書を作り、チェックリストで確かめる
機能・非機能・移行・運用の確認項目に漏れがないかを点検します。
- 確かめること
- チェックリストの未確認項目が0件。
- できあがるもの
- 要件定義書の案
- レビュー発注者の業務担当・情報システム担当・目安 3〜5日
11. 要件定義書をレビューする
業務担当は業務の流れ、情報システム担当は非機能・運用を中心に確かめます。
- 確かめること
- 指摘と回答を一覧にして残す。
- できあがるもの
- レビューの指摘一覧
- 承認PM・目安 1日
12. 要件定義書の承認をもらう
決裁者の承認を書面または承認の記録で受け取り、版数を確定します。
- 確かめること
- 承認後の変更は仕様変更の手順で扱うことを合意する。
- できあがるもの
- 承認済みの要件定義書
- 見積PM・目安 2日
13. 設計以降の見積を出す
承認された要件をもとに、工数とスケジュール、前提条件を示します。
- 確かめること
- 見積の前提（対象外の機能・発注者の作業）を明記する。
- できあがるもの
- 見積書
締めのチェックリスト
- 発注者の決裁者と承認の方法を確かめた
- 現行業務の例外処理を件数まで聞いた
- 帳票・画面の項目を一覧にした
- 対象外にした要望と理由を残した
- 業務フローの全工程に機能か運用が割り当たっている
- 非機能要件を数字で決めた
- データ移行の範囲と方法を決めた
- 未決の課題が0件、または期限と担当がある
- 要件定義書の承認を記録した
- 見積の前提条件を明記した
よくあるミスと防ぎ方
例外処理の聞き漏れ
「普段はこうです」の説明だけで要件を決めると、例外処理が後から見つかり仕様変更になります。例外の件数と条件を聞く項目を議事録の型に入れます。
非機能要件があいまい
応答時間や停止できる時間帯を決めないと、テストで合否を判定できません。数字で決めます。
承認があいまいなまま設計に進む
口頭の了承だけで進めると、後で「聞いていない」と言われます。版数と承認の記録を残します。
測っておきたい指標
- 要件定義書の承認までの期間（計画との差）
- 設計以降に発生した要件の追加・変更件数
- 期限切れの課題の件数
この業務で残す書類の保存期間
関係する法令・規格
民法（請負・準委任）
要件定義を準委任で受けるか請負で受けるかで、成果物の完成の責任と報酬の考え方が変わります。
個人情報保護法
扱うデータに個人情報が含まれる場合、安全管理措置やアクセス権限を要件に入れる必要があります。
無料ダウンロード
業務手順書テンプレート集（IT・受託開発・10業務）
- 「要件定義」を含む10業務の手順書を、1業務1シートで書き換えられるExcel
- 手順ごとに担当・確かめること・できあがるもの・目安時間の列。自社のやり方に合わせて行を足せます
- 締めのチェックリストと改訂履歴のシートつき。A4横で印刷できます
フォームを送信すると、すぐにダウンロードできます
13手順のうち2つは、自動化の候補です
よくある質問
- 要件定義は請負と準委任のどちらで受けるべきですか。
- 要件は発注者の判断で決まる部分が大きいため、準委任で受けることが多いです。どちらにしても、成果物と完了の条件を契約で決めておきます。
- 非機能要件は何から決めればよいですか。
- 停止できる時間帯、同時に使う人数、扱うデータの量、バックアップの頻度から決めると、設計と見積に使えます。
- 紙の帳票の項目整理を早くできますか。
- 記入済みの帳票を AI-OCR で読み取ると、項目名と実際の値の一覧を早く作れます。読み取った値は移行データの品質確認にも使えます。