• ここでは、要件定義工程に含まれるプロセスの全体像を解説している。
• 標準の定めるテンプレートを手に入れたい方は、こちら → サンエム上流工程標準

標準は、通常守るべき順序や関係性を定義し、テーラリングの基準として働く。

顧客や案件、現場によっては、いくつかのプロセスや成果物が追加で必要になったり、あるいは不要になったりすることが想定される。要件定義に臨むPMやエンジニアは、標準で定められた基準を守りつつ、テーラリング（現場に合わせたアレンジ）することが求められる。

要件定義工程は全体として見たとき、要件の合意形成プロセスとみなせる。

flowchart LR
  %% 全体レイアウトを左→右
  subgraph A[入力]
    direction TB
    要望 ~~~ 制約
  end
  
  subgraph B[要件定義]
    direction LR

    %% 業務要件（縦方向のフロー）
    subgraph BA[業務要件]
      direction TB
      AsIs把握 --> 課題定義 --> ToBe定義
    end

    %% システム化要件（縦方向の独立ノード）
    subgraph BB[システム化要件]
      direction TB
      機能要件定義 ~~~ 非機能要件定義 ~~~ 移行計画
    end

    BA --> BB
  end
  
  %% 要件定義工程の入出力
  要望 -->|収集・分析| B
  制約 -->|スコープ調整| B
  B -->|文書化| 要件定義書

  %% 検証
  B -->|妥当性検証| A

これまで見てきた通り、要件定義は要望と制約を入力とし、ステークホルダー（顧客）との正式な合意によって、要件定義書を正式な工程成果物として出力する。

要件定義の主な活動は、以下のようになっている。

1. 要望を収集し、AsIs の業務を分析して、課題を定義する。
2. 要望と課題から、ToBeの業務を、業務要件として定義する。
3. 業務要件を実現するシステム要件を定義する。
4. 予算やスケジュールなどの制約で要件を優先順位付けし、取捨選択し、スコープ調整する。
5. 要件が妥当（要望を実現し、制約をクリアする）なものか確認する。
6. 決定した要件を合意・承認して、正式な成果物として確定する。

   ---

サンエム標準では、1つのプロセスは、1つの成果物を出力する。
要件定義工程では、すべての成果物は、最終的に要件定義書に統合される。

ここに示されるプロセスの実行タイミングは、あくまで標準である。
現場の状況にあわせて、適切にアレンジされることを想定している。

要件定義書の定義 → 個別の成果物の定義 → 個別プロセスの定義 → 個別プロセスガイド

全体ガイド → 個別プロセスガイド → 個別成果物

分類	プロセス	概要	実践ガイド
入力	🚫 Post not found	業務やシステムを設計・運用する上で守らなければならない制約を一覧として整理する	🚧制約条件整理
入力	要望分析
その他	🚫 Post not found	業務・システム関連の用語を定義し、ステークホルダー間で解釈を統一する	📄用語定義
業務要件	🚫 Post not found	現状(AsIs)の業務を分析し、フロー図として可視化し、課題と改善ポイントを明確にする。	🚧AsIs業務フロー作成
業務要件	🚫 Post not found	システムに関連する業務を洗い出し、一覧にして、システム化対象か対象外か明記する。	🚧システム化対象業務定義
業務要件	🚫 Post not found	現行業務（As-Is）で明らかになった課題や制約、ビジネス目標を踏まえ、「どのような業務の姿を目指すか」 を設計し、関係者間で合意を形成する	🚧ToBe業務フロー作成
業務要件	🚫 Post not found	ToBe業務フローで定義した手順・役割を具体的に運用可能にするために、「どのような条件・基準・判断ルールで業務が実行されるか」を明確化する。	🚧業務ルール定義
業務要件	🚫 Post not found	業務で扱う情報（データ）を統一的に整理し、属性・型・意味・利用ルールを定義する	🚧業務データ定義
システム要件	🚫 Post not found	業務要件を実現するために、システムが提供すべき機能を明確化し、業務とシステムの責任分界を定義する。「何をシステムで行うのか」「どのように業務を支援するのか」を明確にする。	🚧機能要件定義
システム要件	🚫 Post not found	システムが備えるべき性能・信頼性・可用性・セキュリティなど、機能以外の品質要求を明確化する	🚧非機能要件定義
システム要件	🚫 Post not found	システムやサービスの構成要素（アクター、サーバ、アプリケーション、DB、ネットワーク、外部サービスなど）を視覚的に表現する	🚧サービス構成図作成
その他	🚫 Post not found	定義された要件が、要望や制約、業務要件と整合しているか確認する。 要件仕様書が“正確に作られているか”（正当性）ではなく、“正しいものを作るための要件になっているか”（妥当性）を確認する。	🚧要件の妥当性検証

プロセス名	制約条件整理
成果物名	制約条件一覧
成果物テンプレート	🚫 Post not found
プロセス概要	業務やシステムを設計・運用する上で守らなければならない制約を一覧として整理する
目的(成果物の役割)	設計・改善の判断基準を明確化し、実現可能なTo-Be業務設計・システム設計を支える
実行タイミング	要件定義開始前に一度整理し、要件定義中に随時更新する。 特に、ToBe業務フローや業務ルール定義の前提として整理しておくことが望ましい
主な活動	• 納期・予算・法令・規程・社内規則・契約・リソース制約・システム制約などを収集する • 収集した制約を業務別・システム別・リスク影響別などで分類し一覧化する • 関係部門のレビューで、内容に間違いがないことを確認する。
文書の構造・形式	通常、表として一覧化。
実践ガイド	🚧制約条件整理

プロセス名	用語定義
成果物名	用語集
成果物テンプレート	🚫 Post not found
プロセス概要	業務・システム関連の用語を定義し、ステークホルダー間で解釈を統一する
目的(成果物の役割)	・ステークホルダー間で共通言語を確立し、誤解・認識差を防止 ・ドキュメント間で一貫した用語使用を担保 ・要件定義・設計レビュー・テストでの議論を効率化
実行タイミング	要件定義工程の初期段階で開始し、工程全体で継続更新する。 できるだけ早期に整備することが望ましい。
主な活動	• ドキュメント（業務フロー、要件一覧、データ定義書など）や会話から主要用語を抽出 • 各用語の意味、用途、関連語、区別点を明確に定義する
文書の構造・形式	通常、表として一覧化。
実践ガイド	📄用語定義

プロセス名	システム化対象業務定義
成果物名	業務一覧
成果物テンプレート	🚫 Post not found
プロセス概要	システムに関連する業務を洗い出し、一覧にして、システム化対象か対象外か明記する。
目的(成果物の役割)	•ステークホルダー間で「業務」に対する認識齟齬を防ぎ、合意形成を支援する • システム化対象業務と対象外業務を識別し、スコープを明確にする • トレーサビリティ（業務 → 機能 → 非機能要件、さらにはテスト仕様等）の出発点となる
実行タイミング	要件定義の初期段階、業務分析フェーズの冒頭で行うべき
主な活動	• 関連業務の洗い出し • 識別のための業務名称と、その範囲の明文化 •システム化対象内/対象外の識別と合意
文書の構造・形式	通常は表形式で表現される
実践ガイド	🚧システム化対象業務定義

プロセス名	AsIs業務フロー作成
成果物名	AsIs業務フロー
成果物テンプレート	🚫 Post not found 🚫 Post not found
プロセス概要	現状(AsIs)の業務を分析し、フロー図として可視化し、課題と改善ポイントを明確にする。
目的(成果物の役割)	• 現行業務の流れ、関係者、情報の流れ、課題を可視化し、共通認識を形成する。 • 後のToBe業務フローとの差分が、要件定義の根幹となる。
実行タイミング	要件定義の初期段階、業務分析フェーズ。業務一覧の作成と並行して行うべき
主な活動	• 現行業務のヒアリング・ドキュメント収集・現場観察などで情報収集 • 実際の業務手順、入力・出力、担当者、システムを整理してフロー図作成 • フロー中のボトルネック、属人化、重複業務などの原因事象を洗い出し、課題定義する
文書の構造・形式	通常、業務ごとに1つのフロー図+注釈。必要なら表として一覧化。
実践ガイド	🚧AsIs業務フロー作成

プロセス名	ToBe業務フロー作成
成果物名	ToBe業務フロー
成果物テンプレート	🚫 Post not found 🚫 Post not found
プロセス概要	現行業務（As-Is）で明らかになった課題や制約、ビジネス目標を踏まえ、「どのような業務の姿を目指すか」 を設計し、関係者間で合意を形成する。
目的(成果物の役割)	・業務の新しい流れ・責任分担・情報のやり取りを定義 ・業務改善施策やシステム化範囲の根拠資料となる ・業務要件・システム要件の基礎を作る ・将来の業務イメージをステークホルダー間で一致させ、運用テスト仕様の入力となる
実行タイミング	要件定義工程の業務要件を定義するとき
主な活動	• AsIs分析結果から、課題・制約・非効率箇所を抽出し、改善すべきテーマを特定する • 新しい業務手順、役割分担、システム活用方法を設計し、ToBeフローとして可視化する • 関係部門との妥当性レビューや合意形成、実現性評価を行う
文書の構造・形式	通常、業務ごとに1つのフロー図+注釈。必要なら表として一覧化。
実践ガイド	🚧ToBe業務フロー作成

プロセス名	業務ルール定義
成果物名	業務ルール一覧
成果物テンプレート	🚫 Post not found
プロセス概要	ToBe業務フローで定義した手順・役割を具体的に運用可能にするために、「どのような条件・基準・判断ルールで業務が実行されるか」を明確化する。
目的(成果物の役割)	・フロー図では表現しきれない業務ルールを明文化する。 ・ToBe業務を一貫性・再現性をもって運用できるようにする ・システム要件（機能・制約・業務ロジック）の根拠となる
実行タイミング	ToBe業務フロー確定後、システム要件定義の前。 特に「判断」「条件分岐」「例外処理」「入力ルール」「承認ルート」などを整理する段階
主な活動	• フロー図では表現しきれない業務の判断・条件分岐・例外対応などを洗い出す • 各ルールを「条件」「処理内容」「責任者」「根拠」「例外対応」などとして定義 • 関係部門との妥当性レビューや合意形成、実現性評価を行う
文書の構造・形式	通常、表として一覧化する。
実践ガイド	🚧業務ルール定義

プロセス名	業務データ定義
成果物名	データ定義書
成果物テンプレート	🚫 Post not found
プロセス概要	業務で扱う情報（データ）を統一的に整理し、属性・型・意味・利用ルールを定義する
目的(成果物の役割)	・業務で使用するデータ項目の意味や構造の共通認識を形成する ・システム設計やデータベース設計の基礎資料を作成する
実行タイミング	ToBe業務フローと業務ルールが確定した後。 システム要件定義の前。 通常、業務ルールで必要なデータ項目が洗い出されている状態で開始
主な活動	• ToBe の業務から、システムで扱うべきデータを洗い出す • データ名、型、桁数、単位、必須/任意、制約、参照関係などを整理し、定義する • 関係部門とレビューし、業務・システム双方で使用可能な正式な定義として確定する
文書の構造・形式	通常は、表およびドメインモデル図として表現する。
実践ガイド	🚧業務データ定義

プロセス名	機能要件定義
成果物名	機能要件一覧
成果物テンプレート	🚫 Post not found
プロセス概要	業務要件を実現するために、システムが提供すべき機能を明確化し、業務とシステムの責任分界を定義する。「何をシステムで行うのか」「どのように業務を支援するのか」を明確にする。
目的(成果物の役割)	・業務要件を実現するために必要なシステム機能を明示する。 ・ステークホルダー（顧客側・開発側）の間で、機能の範囲・粒度・優先度の共通認識を形成する。 ・基本設計および見積りのインプットとする。
実行タイミング	ToBe業務フローおよび業務ルール定義が完了し、業務要件の整理が終わった段階
主な活動	• 業務要件と業務ルールの分析 • 業務プロセスとの機能対応付け • 機能一覧の作成 • 機能階層構造（ツリー）および概要定義 • 非機能要件との整合確認
文書の構造・形式	通常、表として一覧化。機能ごとの定義を詳細にする場合は、別途機能ごとの仕様書を作成する。
実践ガイド	🚧機能要件定義

プロセス名	非機能要件定義
成果物名	非機能要件一覧
成果物テンプレート	🚫 Post not found
プロセス概要	システムが備えるべき性能・信頼性・可用性・セキュリティなど、機能以外の品質要求を明確化する
目的(成果物の役割)	・システム全体の品質水準を定義する ・機能要件と組み合わせて、実現可能な設計の指針を示す ・テスト基準や受入条件の根拠を提供する ・システム性能や運用リスクに関するステークホルダー合意を得る
実行タイミング	機能要件定義と並行または後に実施
主な活動	• 非機能要件項目の洗い出し関連する • 制約条件・業務条件との整合確認 • 測定可能な基準値の設定（例：レスポンスタイム、可用性率） • 優先度や重要度の整理 • レビューと承認による合意形成
文書の構造・形式	通常、表として一覧化。要件が少なければ、箇条書きでも十分。
実践ガイド	🚧非機能要件定義

プロセス名	サービス構成図作成
成果物名	サービス構成図
成果物テンプレート	🚫 Post not found
プロセス概要	システムやサービスの構成要素（アクター、サーバ、アプリケーション、DB、ネットワーク、外部サービスなど）を視覚的に表現する
目的(成果物の役割)	・システム／サービス全体の構成を俯瞰できる ・関連システムや外部サービスとの接続関係を明示 ・設計・運用・保守の指針資料として利用 ・ステークホルダー間の共通認識と合意形成
実行タイミング	要件定義の後期～基本設計前。 機能要件、非機能要件、外部インタフェースが概ね固まった段階
主な活動	・サービス／システム構成要素の洗い出し ・接続・依存関係の整理図面化（視覚化）
文書の構造・形式	ネットワーク図や、システム構成図などの図として表現
実践ガイド	🚧サービス構成図作成

プロセス名	要件の妥当性検証
成果物名	妥当性検証記録
成果物テンプレート
プロセス概要	定義された要件が、要望や制約、業務要件と整合しているか確認する。 要件仕様書が“正確に作られているか”（正当性）ではなく、“正しいものを作るための要件になっているか”（妥当性）を確認する。
目的(成果物の役割)	・要件定義書の承認のベースライン、前提となる ・定義された要件が実際の業務目的・ニーズに適合していることを保証する
実行タイミング	業務要件からシステム要件に落とし込んだ直後。 および、要件定義の最終段階。ある程度、並行してもよい。
主な活動	・レビュー等で妥当性をステークホルダー間で確認する ・承認者による署名や電子承認で正式な記録として確定する
文書の構造・形式	電子署名などで承認履歴を明確化できる文書
実践ガイド	🚧要件の妥当性検証

次のページ → 🚧システム化対象業務定義