当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
ウォーターフォールの案件で要件定義を任されて、『どこまで決めれば次に進んでいいの？』と迷っていませんか。
結論から言うと、ウォーターフォールの要件定義は「後の工程が迷わず進めるところまで決めて、関係者の承認で固める」工程です。
この記事では、工程の流れの中での役目と、要件を固める合意の取り方、決めた後に変更が出た時の扱い方を順に見ていきます。
ウォーターフォールの要件定義とは？最初に「何を作るか」を決めきる工程
ウォーターフォールでは、前の工程の成果物を確定させてから次へ進みます。そのため要件定義は、後から大きく戻らずに済むよう、範囲と中身を一度で固めることが求められます。
ウォーターフォールとは、工程を上から順に進め、前の工程の成果物を確定させてから次に進む開発の進め方です。
滝の水が上から下へ流れるように進むので、この名前が付いています。
その一番上流にあるのが要件定義です。発注側の「こうしたい」を、システムで実現すると合意した内容にまとめる工程ですね。
要件定義そのものの意味から確かめたい方は、要件定義とは？意味をわかりやすく解説を先に読んでおくと話がつながりやすくなります。
なぜ「決めきる」ことが大事なのか
ウォーターフォールでは、要件定義の後に設計、開発、テストと工程が続きます。
どの工程も、前の工程で決まった内容を土台にして作業を進めるんです。
だから要件があいまいなまま進むと、設計の途中で「これはどっちですか？」という質問が積み上がります。
テストの段階で漏れが見つかると、設計や開発まで戻ってやり直すことにもなりかねません。
| 要件定義で決めきれなかった時 | 後の工程で起きやすいこと |
|---|---|
| 対象範囲があいまい | 設計の途中で「これも入るの？」と範囲が広がる |
| 例外の処理を聞いていない | テストで想定外のケースが見つかり手戻りになる |
| 非機能要件を決めていない | 本番に近い環境で動きが遅いと分かり、構成を見直す |
| 承認者が決まっていない | 誰の判断で確定したのか分からず、後から覆る |
ウォーターフォールの流れの中で、要件定義はどこにつながる？
要件定義で決めた内容は、最後の受入テストで発注側が確かめる基準になります。最初と最後がつながっていると考えると、どこまで決めるべきかが見えてきます。
ウォーターフォールの工程は、会社によって呼び方が違うものの、おおよそ次の順に並びます。
- 要件定義
- 基本設計（外部設計）
- 詳細設計（内部設計）
- 実装と単体テスト
- 結合テスト、システムテスト
- 受入テスト
- 導入、運用・保守
この流れを、左側の上流工程と右側のテスト工程に分けて向かい合わせた見方を「V字モデル」と呼びます。
要件定義の向かい側にあるのが、発注側が確認する受入テストです。
『受入テストなんて、まだずっと先の話では？』と思う方も多いはずです。
実は、要件を書く時に「これをどうやって確かめるか」を一緒に考えておくと、あいまいな書き方がぐっと減ります。
例えば「請求書をすぐに発行できる」と書くと、何をもって合格か分かりません。
「締め日の翌営業日の朝までに、全取引先分の請求書データができあがっている」と書けば、受入テストでそのまま確かめられます。
工程の並びと用語の関係は、要件定義プロセスとは（開発工程の中の位置づけ）でも詳しく扱っています。
ウォーターフォールの要件定義で決めることと成果物
業務要件、機能要件、非機能要件に加えて、移行と運用の要件まで決めておくのがウォーターフォールの特徴です。後の工程で「聞いていない」が出ないよう、範囲を広めに押さえます。
ここでは、架空の題材として「取引先への請求書の発行を、紙と表計算ソフトの手作業からシステムに置き換える場合」で考えてみます。
| 決めること | 中身 | 記入例（例） |
|---|---|---|
| 背景・目的 | なぜシステム化するのか | 締め日後の請求書作成にかかる手作業と転記ミスを減らしたい |
| 対象範囲 | どこまでを今回やるか | 請求書の作成と発行まで。入金の消し込みは今回の対象外 |
| 業務要件 | 業務をどう変えるか | 経理担当が締め日の翌日に一覧で確認し、課長が発行を承認する |
| 機能要件 | システムが何をするか | 売上データから請求書を作り、取引先ごとに送付方法を切り替える |
| 非機能要件 | どのくらいの品質で動くか | 締め日の夜間処理が翌朝の始業までに終わる |
| 移行要件 | 今のデータをどう移すか | 取引先の一覧と未発行の売上データを切替日に移す |
| 運用要件 | 動き始めた後の決まりごと | 発行後に訂正が出た時は、赤字の請求書を別に発行する |
| 未決事項 | まだ決まっていないこと | 電子での送付に切り替える取引先の範囲は次回の会議で決める |
成果物としては、要件定義書のほかに業務フロー図、機能一覧、画面一覧、帳票一覧、非機能要件一覧、課題管理表、議事録などがよく作られます。
『全部そろえないとダメなの？』と不安になりますよね。
様式は会社ごとに違うので、まずは自社のひな形があるかを確かめてみてください。
非機能要件は、IPAの「非機能要求グレード」を使うと話がまとまりやすくなります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目について、レベルを0〜5の段階で選ぶ方式です。
どうしても決めきれない項目はどうする？
『全部を決めきるなんて、正直むずかしい…』という方も多いはずです。
実際、取引先との調整待ちなど、要件定義の期間内に答えが出ない項目は残ります。
そんな時は、無理に決めたことにせず、未決事項として課題管理表に載せておきましょう。
その際は「誰が」「いつまでに」決めるのかと、決まらなかった時の仮の扱いを一緒に書いておくのがコツです。
| 未決事項（例） | 決める人 | 期限 | 決まらない時の仮の扱い |
|---|---|---|---|
| 電子での送付に切り替える取引先の範囲 | 経理の責任者 | 基本設計の開始前 | 全取引先を紙と電子の両方に対応させる前提で設計する |
| 請求書の控えを残す期間 | 経理の責任者と情報システム部門 | 基本設計の途中 | 現行の紙の運用と同じ期間で仮置きする |
こうしておけば、設計の担当者は仮の前提で作業を止めずに進められます。
要件を「固める」ための合意の取り方：承認の場面と変更管理
「固める」とは、変更をゼロにすることではありません。誰がいつ何に合意したかを残し、その後の変更は決まった手順で扱えるようにすることです。
ウォーターフォールの説明では「要件を確定させてから次へ」とよく言われます。
ただ、現場では確定した後にも変更の相談は出てきますよね。
大事なのは、確定の場面をはっきり作り、その後の変更を手順に乗せることなんです。
承認の場面をあらかじめ決めておく
要件定義の途中で、どの場面で誰が何を承認するのかを、最初に決めておきます。
| 承認の場面 | 承認する人（例） | 何に合意するか |
|---|---|---|
| 範囲の確定 | 発注側の責任者 | 今回やること、やらないことの線引き |
| 業務要件の確定 | 利用部門の責任者 | 業務フローと業務のルール |
| 機能・非機能要件の確定 | 利用部門と情報システム部門 | 機能一覧と品質の水準 |
| 要件定義書の最終承認 | 発注側の責任者と開発側の責任者 | 次の工程に渡す内容のすべて |
承認は口頭で済ませず、議事録や承認欄に名前と日付を残しておきましょう。
「このあいだの会議でOKと言いましたっけ？」と後から揉めるのを防げます。
確定した後の変更はこの手順で扱う
確定後に「やっぱりこうしたい」が出た時は、受け付けてから判断するまでの流れを決めておきます。
- 変更の内容と理由を、決まった様式に書いて受け付ける
- 開発側が、範囲・期間・費用への影響を調べる
- 発注側の責任者が、受けるか見送るかを判断する
- 受ける場合は要件定義書を更新し、版と日付を残す
- 関係者に変更内容を知らせ、課題管理表を閉じる
会話にすると、こんなやり取りになります。
「請求書に取引先ごとの独自の欄を足したいんです」と利用部門から相談が来たとします。
「承知しました。影響を調べて、次の定例で受けるかどうかを決めましょう」と返せば、その場で安請け合いせずに済みます。
小さな変更だからと、要件定義書を直さずに口頭で受けてしまう。積み重なると、どれが最新の要件か誰にも分からなくなります。小さな変更ほど、版と日付を残しておきましょう。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
ウォーターフォールとアジャイルの要件定義は何が違う？
- 最初に範囲と中身をまとめて決める
- 要件定義書の承認で確定させる
- 変更は決まった手順で受け付ける
- 大きな方向を決め、細部は作りながら決める
- 優先順位の並んだ一覧で要件を管理する
- 短い期間ごとに見直して入れ替える
どちらが良い悪いではなく、向いている案件が違います。
業務のルールがはっきりしていて、範囲を最初に決めやすい案件はウォーターフォールと相性がいいです。
一方で、使ってみないと何が欲しいか分からない案件は、アジャイルのほうが進めやすいこともあります。
アジャイルで要件をどう扱うかは、アジャイル開発の要件定義で詳しく比べています。
よくある相談に答えます
- ユースケースの文書はどの工程で作るのか
- 資格の勉強で、工程の名前と順番が覚えられない
- 現場では省かれる工程があって戸惑う
ユースケースの文書は、ウォーターフォールのどの工程で作るもの？
ユースケースは、利用者がシステムを使って何をするかを場面ごとに書いたものです。
利用者の目的と流れを書くので、要件定義で作ることが多いです。
画面の細かい動きまで書き込む場合は、基本設計で詳しくしていくと考えると分かりやすくなります。
資格の勉強で、工程の名前と順番が混ざってしまう
試験の勉強中に、要件定義や設計の名前が似ていて覚えられないという相談もよくあります。
おすすめは、V字モデルで左右をセットにして覚えることです。
要件定義と受入テスト、基本設計とシステムテスト、という組み合わせで覚えると、順番も自然に入ってきます！
現場では工程が省かれていて、本当に必要なのか分からない
『教科書の工程を全部やっている現場なんて見たことがない…』という声もあります。
小さな改修では、設計書をまとめて作るなど工程をまとめることも実際にあります。
ただ、要件定義の承認だけは省かないのがおすすめです。何に合意したかが残っていないと、受入テストで判断の基準がなくなってしまいます。
要件定義の後の工程全体は、要件定義から運用までの流れで確かめられます。
よくある質問
ウォーターフォールの要件定義とは何ですか？
工程を順に進めるウォーターフォール開発の最初の工程で、システムで実現する内容を決めて関係者の承認で固める工程です。後の設計や開発は、ここで決めた内容を土台に進みます。
要件定義が確定した後は、一切変更できないのですか？
変更はできます。ただし、影響を調べて責任者が判断し、要件定義書の版を更新する手順に乗せるのが前提です。口頭だけで受けると、どれが最新か分からなくなります。
ウォーターフォールの要件定義では、どこまで細かく決めればいいですか？
後の設計の担当者が、業務の判断を聞き直さずに進められるところまでが目安です。受入テストで確かめられる書き方になっているかを基準にすると判断しやすくなります。
要件定義を準委任契約にすることがあると聞きました。なぜですか？
受託開発では、要件定義を準委任契約、設計以降を請負契約に分けて結ぶ例があります。要件定義は中身が決まっていない状態から始まるので、成果物の完成を約束しにくいという事情があると言われます。契約の形は案件ごとに確かめてください。
まとめ
- ウォーターフォールの要件定義は、後の工程が迷わないところまで決めて承認で固める工程
- 要件定義の内容は、最後の受入テストで確かめる基準になる
- 業務・機能・非機能に加えて、移行と運用の要件まで押さえる
- 固めるとは、承認の場面を決め、変更を手順に乗せること
- アジャイルとは向く案件が違うので、案件の性質で選ぶ
コメント