（要約） 要件定義のセオリーと実践方法まとめ
要件定義の基礎を見に作ることを目的に下記の技術書を読みました。
図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科
内容を忘れないためにメモします。
要件定義の基礎知識
要件定義の基礎知識をまとめます。
要件定義とは？
要件定義を理解するには要件、要求、要望の違いを理解する必要があります。
■ 要件 (Requirements)
定義：プロジェクトや製品が満たすべき基本的な条件や機能。「これがなければプロジェクト/製品は成功しない」というレベルの必須要素。
例：ソフトウェアが動作するための最低限のシステムスペック、セキュリティ基準。
■ 要求 (Demands)
定義：ユーザーが特定の製品やサービスに求める具体的な機能や性能。「これが必要だ」と強く求められる点。
例：ユーザーインターフェースの使いやすさ、レスポンスの速さ。
■ 要望 (Wishes)
定義：プロジェクトや製品に対する追加的な希望や期待。「あれば嬉しいけれど、なくてもプロジェクトの成功には致命的ではない」というレベルの要素。
例：カスタマイズ可能なテーマ、追加機能。
■ 隠れた要求の発掘方法
要件定義をブラッシュアップするために、隠れた要求を引き出すことが重要です。
- 詳細なヒアリング：プロジェクトに関わる全てのステークホルダーとの詳細な対話を通じて、明確にされていないニーズや期待を探ります
- ワークショップの実施：グループディスカッションやブレインストーミングセッションを通じて、参加者から新たなアイデアや隠れた要求を引き出します
- アンケートや調査：定量的なデータを集めることで、ユーザーグループの中で共通のニーズや隠れた要求を見つけ出します
■ ツリー図
要件はツリー図に表すと網羅が確認しやすくなります。
要件定義の位置付け
- V字モデル（ウォーターフォールモデル）の開発手法は企画→定義→設計→実装の流れ
- 要件定義は、システム構築のかなり早い段階で行われるため、要求が曖昧なケース多いが、手探り状態の中でも抜け漏れのない定義が求められる
要件定義作業フェーズ
要件定義は下記の6つのフェーズで構成される
- 下調べ(ユーザーの要求の理解を深める)
- 段取り(要件定義でやるべき作業のリストアップ)
- 分析(要求を構造的に理解し、分析する)
- 定義(要件を網羅的に定義数る)
- 承認と合意(ユーザーとベンダー間で合意をとる)
- 管理と維持(見直しや拡張に備えて要求をメンテナンスする)
要件定義完了の状態
- システム規模が見積もれる具体性
- 設計工程の作業を進められる詳細度
要件定義の下調べ・段取りフェーズ
要件定義の作業に着手する前に下調べすることが重要です。
下調べフェーズの構成要素
| 項目 | 説明 |
|---|---|
| 事業目標の共有 | プロジェクトの目標をユーザーと同じ視点で共有し、プロジェクトの意図と期待される成果についての理解を深める。 |
| 対象範囲の確認 | プロジェクトを取り巻く環境や背景を理解し、プロジェクトの対象範囲を確認することで、期待される成果と制約条件を明確にする。 |
| ステークホルダーの認識 | 本案件に関係するステークホルダーを明確にし、彼らの期待、要求、影響範囲を認識することで、関係者間のコミュニケーションを効果的に行う。 |
段取りフェーズの構成要素
| 項目 | 説明 |
|---|---|
| 進め方の策定 | 作業内容を洗い出し、役割分担とスケージュール策定をする |
| ジャッジのための基準作り | 要件定義の作業中に衝突が発生した場合の解消方法を事前に決める |
| 計画書の作成 | 段取り時に決めた内容を計画書にまとめ、チームで共有する。 |
※1 レポートライン：報告ライン
※2 エスカレーションルート：業務が解決できない場合の引き継ぎライン
※3 承認パス：起案者から承認者への申請フロー
要件定義を進めていく上で、ステークホルダーの関係を理解し、どのような関係を及ぼしあうのかを下調べし、対象の組織の取り扱いについての特徴をしっかり理解し合うことが重要です。
要件定義作業の進め方
何をいつまでにやるか（ToDo）やチーム内の情報伝達（コミュニケーション）のやり方について、しっかり計画を立て、関係者に合意を得ておくことが要件定義の成功の鍵です。
要件を進める上で、関係者の間で衝突が起きた場合は意見を調整して衝突を解消し、関係者が納得できる落とし所を探すことが重要。
業務要求の分析・定義フェーズ
業務要求の分析・定義は、事業の目標を実現するために、業務に求められる機能の特徴を明確化する。
業務要件の理想を描き、その実現のためにどのような仕組みが必要かを明らかにします。
業務要求の分析の３大要素である「業務フロー※1」「ビジネス・ルール※2」「入出力情報※3」の３つに分けて整理します。
※1. 業務フローは業務の組み立て（処理順）に注目する
※2. ビジネスルールは業務に適用する枠組（規則や基準）を整理する
※3. 入出力情報はインプットやアウトプットの情報を洗い出す。
業務フローの分析・定義
業務フローでイメージを具現化し、共有します。
内容の具体化は、業務全体を詳細へトップダウンで洗い出します。
例えば、顧客管理、商品管理のように大きく業務を分析し次に分類ごとに処理を具現化します。
業務フローのタイミングで例外のバリエーションの認識合わせをすることも重要です。
ビジネスルールの分析・定義
業務フローの分析中に、条件分岐や例外処理が見つかると、そこからビジネス・ルールを抽出することができます。
行動のルール：ユーザーの行動の指針
定義付けのルーツ：組織の決め事や考え方
入出力情報の分析・定義
業務フローやビジネス・ルールの分析と同時に、業務に関連する入出力情報も洗い出します。
機能要求の分析・定義フェーズ
機能要求の分析・定義では業務要件を実現するために必要なシステムを具現化します。
| 項目 | 説明 |
|---|---|
| システム機能 | 業務を構成するシステム機能を整理 |
| 画面 | オンライン処理で利用する画面を整理 |
| 帳票 | オンライン処理及びバッチ処理で使用する帳票を整理 |
| データ | 業務で利用するデータ間の関係を整理 |
| 外部接続 | 外部組織と送受信するデータの整理 |
システム機能に関する分析・定義
業務要件で定義した「業務一覧」の中から、情報システムで実現する処理を抽出する。
システムは構造化して整理することを意識します。
構造化することで、ひとつひとつのシステム機能が、どの事業目標の実現に繋がるのかが確認できます。
画面に関する分析・定義
「機能一覧」で洗い出した機能、中でもオンライン機能について、どのような入力が必要か、それらをどのように画面に展開するかを整理します。
画面一覧をリスト化した後に、画面遷移図で体系的にまとめることで、画面の動きをシュミレートしながらユーザーがシステムに期待することを共有します。
帳票に関する分析・定義
業務要件定義で作成した業務フローを参照しながら、業務に必要な「帳票」を洗い出します。オンライン機能だけでなく、バッチ機能も分析の対象です。
画面遷移のように作業環境が想像しやすい訳ではないので、帳票するときは利用目的や利用場所についてユーザーと共有することが重要です。
データに関する分析・定義
新しいシステムで使用されるデータを画面や帳票のサンプルを参照しながら洗い出し、システムで使うテーブルや項目を具体化して整理していきます。
主要なデータ項目を一覧表にまとめます。
データ項目は列（フィールド）に分解してテーブル設計します。
外部接続に関する分析・定義
新しいシステムが外部接続される場合は、外部接続に関する要求を分析・定義します。
非機能要求の分析・定義フェーズ
機能要件できめたシステムに対して、どの程度厳密に求められているのか、機能が提供するサービスのレベルや品質について決める必要があります。
非機能要件ではこのレベルや品質について基準値を設定します。
可用性に関する非機能要求
可用性の非機能要求とは、稼働時間や停止予定など運用スケジュール、障害や災害時における稼働目標についての要求。
性能・拡張性に関する非機能要求
性能・拡張性の非機能要求とは、システムリソースの効率利用や、業務量の見積もりに対する性能のレベルについての要求。
運用・保守性に関する非機能要求
運用・保守性の非機能要求とは、運用中のシステム稼働レベルや、問題発生時の対応レベルについての要求。
移行性に関する非機能要求
移行の非機能要求とは、新システム移行の期間、方法、対象の資産や移行量についての要求。
セキュリティに関する非機能要求
セキュリティの非機能要求とは、システムの利用制限や不正アクセスの防止についての要求。
まとめ
PMが要件定義を完了した後に、エンジニアがタスク実装しますが。
もう一歩レベルの高いエンジニアになるには全体俯瞰力が必要になります。
上流工程の要件定義を勉強することで全体俯瞰力が上がった気がします。
参考