要件定義のWBSと主要タスク一覧｜現場で使えるサンプルと成果物を徹底解説
「そんな話、聞いていない！」
「この機能じゃ、現場の業務が回らないよ……」
システム開発において、スケジュールが遅れる原因の50%以上は「要件定義の不備」にあると言われています。現場で踏ん張っているPMやエンジニアの皆さんなら、後工程になって上記のような厳しい声に悩まされた経験が一度はあるのではないでしょうか。
まさに「プロジェクトの成否は要件定義で決まる」と言っても過言ではありません。だからこそ、要件定義は場当たり的ではなく、多くのプロジェクトを見てきた経験から言っても、計画的かつ慎重に進める必要があります。
今回は、要件定義で漏れをなくすための主なタスクと成果物、反映したWBSのサンプルを詳しく解説します。
プロジェクトの成否を握る「要件定義」の役割
要件定義のWBSについて具体的に見る前に、まずは要件定義の立ち位置を整理しておきましょう。
要件定義とは、プロジェクトの「企画構想」で立てられた計画に沿って進める、システム開発の上流工程です。プロジェクトの目的を達成するために「どんな業務を実現したいのか」という要求を吸い上げ、それを「システムとしてどう実現するか」という仕様に落とし込む作業を指します。
言葉で言うのは簡単ですが、ここでの決定が後の設計、開発、テストのすべての基準になります。スケジュール遅延の半分以上がここでの不備から始まるという事実は、私たち現場の人間として重く受け止めておく必要があります。
なお、具体的な進め方のポイントについては「システム開発の要件定義で失敗しない進め方」でも詳しく解説していますので、併せて参考にしてください。
「ユーザーの言いなり」にならない要求定義の進め方
要件定義のインプットとして欠かせないのが「要求定義」です。企画構想の目的を叶えるために必要な「業務上のリクエスト」をとりまとめて文書化するプロセスですね。
ここで注意したいのは、ユーザーの言うことをすべて鵜呑みにすればいいわけではない、ということです。誤った要求や、矛盾した要求をそのまま検討してしまうと、最終的に「誰も使わないシステム」が出来上がってしまいます。抜け漏れがないか、ビジネスの目的に沿っているかを、これまでの失敗や成功の経験を糧にしたプロの視点で慎重に見極める必要があります。
要求定義と要件定義の細かな違いや、具体的な進め方のノウハウについては「要求定義とは？要件定義との違い・進め方」で詳しく紹介しています。
トラブルの火種を消す「非機能要件」の勘所
要件定義では「機能要件」だけでなく「非機能要件」も整理しなければなりません。
機能要件が「画面から入力してDBに保存する」といった目に見える動きであるのに対し、非機能要件は性能、可用性、セキュリティ、運用保守性など、ビジネスに直結しにくい裏側の要件を指します。
厄介なのは、お客様自身も非機能については「当たり前に動くもの」と考えているため、ヒアリングしても要望が出てきにくい点です。しかし、ここを詰め切らないと、いざ本番稼働した後に「レスポンスが遅すぎる」「バックアップが取れていなかった」という致命的なトラブルに直結します。システム基盤の設計には不可欠な情報ですので、現場の状況を想定しながら、こちら側からしっかりガイドして引き出していく姿勢が重要です。
非機能要件の重要性や現場での具体的なヒアリングのコツについては「非機能要件とは？なぜ必要？現場で役立つ進め方のポイント」でさらに深掘りして解説しています。
要件定義の主なタスクと成果物
要件定義は大きく分けて「企画構想」「要求定義」「要件定義」という3つのステップで進めていくのがスムーズです。それぞれの段階で作成すべき成果物を明確にすることで、プロジェクトの「現在地」が見えるようになります。
要件定義のタスク・成果物一覧
ここでは主なタスクと成果物を整理しました。プロジェクトの規模や特性に合わせて、必要なものをピックアップして活用してください。
※実際には、これらすべてを作成することが目的ではなく、お客様と「何を作るか」の合意を形成することが目的です。
| No. | タスク | 成果物 | |
| 1 | 企画構想 | ||
| 1-1 | 企画構想を理解する | プロジェクト目的の確認 | |
| ステークホルダーの確認※1 | ステークホルダー一覧 | ||
| 1-2 | プロジェクト体制を構築する | 要件定義に適したメンバーの確保 | |
| 1-3 | プロジェクト計画書にまとめ上げる | プロジェクト計画書 | |
| 1-4 | 要件定義の活動スケジュールを作成する | ヒアリング日程計画表 | |
| 2 | 要求定義 | ||
| 2-1 | 現状を把握する （現行業務の可視化） |
対象業務の洗い出し | |
| 既存システムの調査 （業務目的、機能、手順） |
|||
| 業務用語の定義 | 業務用語集 | ||
| 2-2 | 現状（As-Is）の業務フローをまとめる | 業務ヒアリング （日次、月次、年次、臨時） |
|
| 対象業務機能のリスト化 | 業務機能一覧 | ||
| 業務処理内容の定義 （業務処理の詳細説明） |
業務内容定義書 | ||
| 業務全体の鳥瞰図の作成 | 業務プロセス関連図 | ||
| 現状（As-Is）の業務フローの作成 |
業務フロー |
||
| 2-3 | 問題や課題を抽出する | 問題箇所の確認、課題の認識合わせ | |
| 洗い出した要求事項のリスト化 | 要求事項一覧 | ||
| 2-4 | 実現可能な問題解決の手段を決める | 解決手段の検討 | |
| 現状の問題点・あるべき姿、効果の図表作成 | ビフォーアフター図 | ||
| 3 | 要件定義 | ||
| 3-1 | システム化する機能をまとめる | システム化手段の検討 | |
| 3-2 | あるべき姿（To-Be）の業務フローをまとめる | 業務全体の鳥瞰図の作成 | 業務プロセス関連図 |
| あるべき姿（To-Be）の業務フローの作成 | 業務フロー システム化業務フロー |
||
| システム化の範囲の明確化 | システム構成図 | ||
| システム化する機能のリスト化 | システム化機能一覧 | ||
| 業務ルールの状態変化の図表作成 | 状態遷移図 | ||
| 3-3 | 非機能要件をまとめる | 既存システムの課題・要求の確認 | |
| サービスレベルの調整 | |||
| 優先度の調整 | |||
| 非機能要件を決定する | 非機能要求グレード | ||
| 3-4 | 新システム環境を決定する | 新システム稼働環境の調査 | |
| 新システムの技術検証 | |||
| アプリケーション基盤の決定 | |||
| 設計標準の作成 | 設計標準書 | ||
| 開発環境の準備 | |||
| 3-5 | 運用要件をまとめる | 運用要件の検討（運用要求、障害対応） | |
| 新システムの運用要件の作成 | 運用要件書 | ||
| 3-6 | 移行要件をまとめる | 移行要件の検討（移行方針、移行範囲） | |
| 移行スケジュールの作成 | 移行計画書 | ||
| 3-7 | 要件の抜け漏れがないか検証する | 要求事項一覧と要件定義書との突合 | |
| 3-8 | 目的を達成できる要件かを確認する | プロジェクト目的と要件定義の突合（実現可能な手段の確認） | |
| 3-9 | 概算見積もりを作成する※2 | 概算見積書の作成（開発・運用） | 概算見積書 |
| システム機能・非機能の現新比較 | 現新比較表 | ||
| 3-10 | システムテストの計画を策定する | システムテストの方針検討 | |
| システムテスト計画書の作成 | システムテスト計画書 | ||
| 3-11 | 次フェーズ（概要設計）の準備 | 概要設計書の作業方針、作成基準の作成 | 概要設計基準書 |
※1 ステークホルダーの管理方法、ステークホルダー一覧で記録すべき項目をまとめています。よろしければ参照ください。
※2 見積もり方法とポイントをまとめています。よろしければ参照ください。
要件定義のWBS
タスクを洗い出したら、それを時系列に並べて WBS に落とし込みます。企画構想、要求定義、要件定義の3つのフェーズに分けることで、「今は何を優先すべきか」「どの順番で進めるべきか」が整理され、プロジェクトの進捗が管理しやすくなります。
要件定義のWBSサンプル
上記の要件定義のタスク一覧をベースにしたWBSのサンプルです。
現場でWBSを引く際のポイントをいくつか挙げます。
- ヒアリング期間は余裕を持って
ユーザー側のキーマンの予定が合わないことはよくあります。バッファを持たせた計画にしましょう。 - 合意形成のタイミングを明記
ドキュメントを作って終わりではなく、いつお客様と合意（サインオフ）するのかをマイルストーンとして設定することが重要です。 - 「移行」や「運用」を後回しにしない
ついつい機能面に目が行きがちですが、初期段階から移行の難易度や運用のイメージを持っておくことで、終盤の「想定外」を減らせます。
【参考】要件定義の成果物のサンプル紹介
成果物のイメージが湧きにくい場合は、IPA（独立行政法人情報処理推進機構）が公開している「超上流から攻めるIT化の事例集：要件定義」などを参照するのも手です。豊富なサンプルが掲載されています。
ただし、それらを「全部作らなければならない」と捉えるのではなく、自プロジェクトにとって本当に価値のあるドキュメントは何かを選択する基準として使ってください。
独立行政法人情報処理推進機構（IPA）| 超上流から攻めるIT化の事例集：要件定義
まとめ：要件定義の精度がプロジェクトの「命運」を分ける
改めて強調したいのは、要件定義こそがプロジェクト成功の鍵を握っているということです。ここで手を抜いたり、曖昧なまま次工程へ進んだりすると、後の工程で何倍もの工数となって跳ね返ってきます。
「要件定義ですべてが決まる」という緊張感を持ちつつ、今回紹介したタスクやWBSを一つの地図として、プロジェクトを成功へ導いていきましょう。皆さんの現場の要件定義が、計画通りに進むことを願っています。
