要件定義を担当することになったけど、どうやって進めるの？
要件定義のタスクって何が必要なの？
要件定義のWBSがわからない？
システム開発において、スケジュールが遅れる主な原因のうち、50％以上が要件定義の不備に起因すると言われています。プロジェクトの成否は要件定義で決まると言っても過言ではありません。
要件定義を失敗すると以降の開発フェーズで問題が山積する事態になりかねません。それだけに要件定義は計画的に、かつ、慎重に進める必要があります。
ここでは、要件定義の主なタスクと成果物、WBSのサンプルを含めてわかりやすく解説します。少しでも要件定義の参考になれば幸いです。
要件定義とは
要件定義とは、プロジェクトの企画構想で立案したプロジェクト計画書に沿って進めるシステム開発の上流工程で、そのプロジェクトの目的を達成するための業務要求を実現するために、システム化の機能要件の抽出と実現可能な要件仕様を決定する作業です。
文章にすると分かり難いため、こちらで要件定義を進める3つのステップについて、図を用いてわかりやすく解説しています。
システム開発のスケジュールが遅れる原因の50％以上が要件定義の不備に起因すると言われています。
3つのステップとは何か、要件定義の進め方、要件定義の失敗事例、失敗しないための7つのポイントを詳しく説明していますので、要件定義に不安のある方はぜひお読みください。
要求定義とは
要求定義は、要件定義のインプットになる重要なプロセスで、企画構想の目的を実現させるために必要な業務要求を取りまとめて文書化する作業です。
しかし、誤った要求を抽出して検討を進めていくと、結果的に使われないシステムを構築することになります。
要件定義とは何か、要件定義との違い、要求定義の進め方とポイントを解説しています。よろしければ参照ください。
非機能要件とは
要件定義でお客様から受ける要求事項は、機能要求と非機能要求の２つに分類されます。
機能要求はビジネスに直結した要件で、現行業務や現行システムの改善要望です。それに対して非機能要求は、システムの性能や運用に関わる要件で、ビジネスに直結しないものになります。
しかしながら、非機能要求に関してはお客様自身も日頃から不満や改善要望を持っておらず、お客様にヒアリングして聞き出すことが難しい要求事項になります。
非機能要件とは何か、非機能要求はなぜ必要なのか、そして非機能要件の進め方とポイントを解説していますので、よろしければ参照ください。
要件定義の主なタスクと成果物
要件定義は「企画構想」「要求定義」「要件定義」の3つのステップで進めていきます。
企画構想でプロジェクトの目的を正しく理解し、その目的を達成するための業務要件を要求定義で決定します。その要求定義をもとに、要件定義でどのようなシステムを構築するのかを決定する流れになります。
つまり、要件定義のインプットは要求定義であり、要求定義のインプットは企画構想になります。
要件定義の3つのステップを詳しく知りたい方はこちらで解説しています。
要件定義のタスク・成果物一覧
企画構想、要求定義、要件定義のそれぞれの主なタスクと成果物を記述します。
そもそも「成果物って何？」と思った方は、こちらで成果物について解説していますので参照ください。
また、すべてのタスクが必要というわけではありません。プロジェクトの規模や特性によって、タスクや成果物の要否を判断してご活用ください。
「タスク」項目は、あえて内容が分かり易い表現で記述しましたが、実際は『○○する』などの文末表現は除いた項目名で記述するのが一般的です。
「企画構想を理解する」→「企画構想の理解」
「現状を把握する」→「現状把握」
| No. | タスク | 成果物 | |
| 1 | 企画構想 | ||
| 1-1 | 企画構想を理解する | プロジェクト目的の確認 | |
| ステークホルダーの確認※1 | ステークホルダー一覧 | ||
| 1-2 | プロジェクト体制を構築する | 要件定義に適したメンバーの確保 | |
| 1-3 | プロジェクト計画書にまとめ上げる | プロジェクト計画書 | |
| 1-4 | 要件定義の活動スケジュールを作成する | ヒアリング日程計画表 | |
| 2 | 要求定義 | ||
| 2-1 | 現状を把握する （現行業務の可視化） |
対象業務の洗い出し | |
| 既存システムの調査 （業務目的、機能、手順） |
|||
| 業務用語の定義 | 業務用語集 | ||
| 2-2 | 現状（As-Is）の業務フローをまとめる※2 | 業務ヒアリング （日次、月次、年次、臨時） |
|
| 対象業務機能のリスト化 | 業務機能一覧 | ||
| 業務処理内容の定義 （業務処理の詳細説明） |
業務内容定義書 | ||
| 業務全体の鳥瞰図の作成 | 業務プロセス関連図 | ||
| 現状（As-Is）の業務フローの作成 | 業務フロー システム化業務フロー |
||
| 2-3 | 問題や課題を抽出する | 問題箇所の確認、課題の認識合わせ | |
| 洗い出した要求事項のリスト化 | 要求事項一覧 | ||
| 2-4 | 実現可能な問題解決の手段を決める | 解決手段の検討 | |
| 現状の問題点・あるべき姿、効果の図表作成 | ビフォーアフター図 | ||
| 3 | 要件定義 | ||
| 3-1 | システム化する機能をまとめる | システム化手段の検討 | |
| 3-2 | あるべき姿（To-Be）の業務フローをまとめる※2 | 業務全体の鳥瞰図の作成 | 業務プロセス関連図 |
| あるべき姿（To-Be）の業務フローの作成 | 業務フロー システム化業務フロー |
||
| システム化の範囲の明確化 | システム構成図 | ||
| システム化する機能のリスト化 | システム化機能一覧 | ||
| 業務ルールの状態変化の図表作成 | 状態遷移図 | ||
| 3-3 | 非機能要件をまとめる | 既存システムの課題・要求の確認 | |
| サービスレベルの調整 | |||
| 優先度の調整 | |||
| 非機能要件を決定する | 非機能要求グレード | ||
| 3-4 | 新システム環境を決定する | 新システム稼働環境の調査 | |
| 新システムの技術検証 | |||
| アプリケーション基盤の決定 | |||
| 設計標準の作成 | 設計標準書 | ||
| 開発環境の準備 | |||
| 3-5 | 運用要件をまとめる | 運用要件の検討（運用要求、障害対応） | |
| 新システムの運用要件の作成 | 運用要件書 | ||
| 3-6 | 移行要件をまとめる | 移行要件の検討（移行方針、移行範囲） | |
| 移行スケジュールの作成 | 移行計画書 | ||
| 3-7 | 要件の抜け漏れがないか検証する | 要求事項一覧と要件定義書との突合 | |
| 3-8 | 目的を達成できる要件かを確認する | プロジェクト目的と要件定義の突合（実現可能な手段の確認） | |
| 3-9 | 概算見積もりを作成する※3 | 概算見積書の作成（開発・運用） | 概算見積書 |
| システム機能・非機能の現新比較 | 現新比較表 | ||
| 3-10 | システムテストの計画を策定する | システムテストの方針検討 | |
| システムテスト計画書の作成 | システムテスト計画書 | ||
| 3-11 | 次フェーズ（概要設計）の準備 | 概要設計書の作業方針、作成基準の作成 | 概要設計基準書 |
※1 ステークホルダーの管理方法、ステークホルダー一覧で記録すべき項目をまとめています。よろしければ参照ください。
※2 業務を漏れなく洗い出す業務フローの書き方をまとめています。よろしけれ参照ください。
※3 見積もり方法とポイントをまとめています。よろしければ参照ください。
成果物は、最終的にお客様への納品物となるため、プロジェクト活動でかかる費用の対価ということが言えます。その費用はプロジェクトで作成する成果物の量によって作業工数が変わってきますので、お客様とプロジェクト開始前に成果物についても合意しておく必要があります。
要件定義のWBS
タスク一覧と同様に、企画構想、要求定義、要件定義の3つのステップに分けて記述します。
3つのステップに分けて考えることで、それぞれのステップで何を実施するのか、何を優先して進めるべきか、タスクの順序と期間が整理できて見やすくなります。
要件定義のWBSサンプル
上述の要件定義のタスク一覧をベースにしたWBSのサンプルです。
この例は要件定義を3ヶ月間で実施する場合のサンプルですが、それぞれのタスクの期間は当該プロジェクトによって変わりますので参考程度にご覧ください。
（※画像をクリックすれば拡大表示されます）
（参考）要件定義の成果物のサンプル紹介
独立行政法人情報処理推進機構（IPA）が「超上流から攻めるIT化の事例集：要件定義」と題して成果物のサンプルを掲載していますので紹介します。
ここにはたくさんの成果物が掲載されていますが、これで全部ではないですし、掲載されているから絶対に必要ということでもありません。要件定義を開始する前に、個々のプロジェクトで必要な成果物を選択すればいいだけです。
皆さんの要件定義で必要な成果物のサンプルが掲載されていれば参考にしてみてください。
独立行政法人情報処理推進機構（IPA）| 超上流から攻めるIT化の事例集：要件定義
要件定義ですべてが決まる
要件定義がプロジェクト成功のカギを握っています。
要件定義を失敗すると、以降の開発フェーズで問題が山積となり、取り返しがつかない事態に陥ります。まさに、要件定義ですべてが決まると言っても過言ではありません。
それだけに要件定義は計画的に、かつ、慎重に進める必要があります。
ここに記述した要件定義の主なタスクとWBSを参考に、要件定義を無事に完遂してプロジェクトを成功に導きましょう。
もし要件定義の進め方に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
