要件定義は試験ごとにどう問われるか（本文から要件を拾う・認識のずれを防ぐ）

結論：PD-Sは「要件を正しく拾う」、PD-Mは「ずれを誰と止めるか」

要件定義は、PD試験（仮称）の2つの区分で、違う側から問われています。システム区分（PD-S）は、業務の記述から機能要件を過不足なく拾えるかを、マネジメント区分（PD-M）は、要件の認識のずれをどの工程で、誰を巻き込んで防ぐかを問いました。

サンプル問題	問われていること
PD-S問1	業務の記述から、ダッシュボードに載せる情報を過不足なく選ぶ
PD-M問3	認識誤りによるリリース中止を繰り返さないための進め方を選ぶ

データマネジメント試験（仮称）には要件定義の問題はありませんが、シラバス案の「データの定義及び内容の確認」で、PD-S問1の決め手と同じ「粒度」を扱っています。

PD-S問1：要件の対象は、現状の業務の記述で決まる

PD-Sのサンプル問1は、不動産会社の新システムに付けるダッシュボードの問題です。マネージャには「現在の業務で確認している営業担当者ごとの情報」を見られるようにする、という下線①に当たるものを、9つの候補から選びます。

下線①には条件が2つあります。確認しているのがマネージャであること、営業担当者ごとの情報であることです。本文でマネージャが確認しているもののうち、両方を満たすのは、営業担当者ごとの媒介契約数と、営業担当者ごとの物件ステータスの値の推移だけで、答えはエ（(一)，(四)）でした。自部門全体の媒介契約数の推移は、マネージャが見ていても「営業担当者ごと」ではありません。成約率は営業担当者ごとに計算されますが、日々確認しているのは営業担当者自身です。

IPAは出題趣旨で、この問題を、業務とシステムの概要（データの項目、関係などを含む）と業務ニーズを踏まえて、ダッシュボード機能の機能要件を適切に定義する能力を評価するものとしています。要件を「現在の業務で確認している〜」と書けば、何が対象になるかは現状の業務の記述で決まります。解く側は、その記述の主語と集計の単位を落とさずに読む必要があります。

PD-M問3：認識誤りは、要件定義に顧客を入れて止める

PD-Mのサンプル問3では、A社のSaaSの昨年度のリリースで、顧客が参加する運用訓練のときに、機能追加要望に対するA社の認識誤りが原因の不具合が見つかり、一部の機能のリリースが中止になっていました。本年度は、①予算の範囲で顧客の機能追加と確実なリリースの要望を実現すること、②A社の短期的な資金繰りを改善すること、の2つの条件を満たす進め方を2つ選びます。

正解はカ（(四)，(五)）です。(四)は大口顧客と費用負担に合意した要望3を優先する案で、開発費をリリース時に請求できるので、資金繰りの条件に応えます。もう一方の(五)が「顧客に要件定義に参加してもらって，定義した要件が顧客の要望に適合しているかどうかを確認する」です。誤答の(二)は、運用訓練の期間を長くして不具合を確かめてもらう案でした。運用訓練は作り終えたあとのリリース前の工程なので、そこで認識誤りが見つかれば、作り直すかリリースを止めるしかありません。認識誤りが入り込むのは要件を決める段階なので、その段階で顧客と突き合わせるのが(五)です。

PD-Mのシラバス案（Ver.0.2）の科目B「3-3」は、ステークホルダの要求を満たすために、成果物と活動をスコープとして定義するスキルを挙げています。PD-Sのシラバス案（Ver.0.2）の科目B「1-2」にも、関係者から情報を集めて要求をシステム要件として定義するスキルと、矛盾する要求を調整するスキルが並んでいます。どちらの項目も、関係者・ステークホルダの要求から出発する点は共通しています。誰を要件定義に呼ぶかまでは、どちらの項目にも書かれていません。

2つの問題をつなぐ「粒度」：誰ごとに、何の単位で

PD-S問1の「営業担当者ごと」と「自部門全体」の違いは、データの粒度の違いです。ダッシュボードでは、集計の単位が違えば、画面の構成も集計の処理も変わります。要件を書くときに粒度を区別しておかないと、後の工程で手戻りになります。PD-M問3の認識誤りの中身は本文に書かれていませんが、当サイトの見方では、こうした粒度や範囲の取り違えは、顧客と要件を突き合わせる場で見つけやすい種類の誤りです。

データマネジメント試験（仮称）のシラバス案（Ver.0.1）は、科目Bの「1-1. データの定義及び内容の確認」で、キー項目のコード体系、粒度、範囲、発番ルールを把握・説明するスキルを挙げています。粒度の例は「顧客の企業単位，部門単位」、範囲の例は「法人顧客を対象とし個人顧客は含まない」です。DMでは、要件を決める側ではなく、決まったデータを使う側として、同じ区別を問われます。ITパスポートのサンプル問3でも、顧客番号の採番の規則や粒度の説明がメタデータの例として出ています（メタデータの記事）。

ITパスポートの水準：業務要件・機能要件・非機能要件を分ける

ITパスポート試験のシラバス案（Ver.0.1）は、情報システム戦略の用語例に、業務要件定義、機能要件定義、非機能要件定義と、要件定義の手法（DFD、決定表、UML）を挙げています。サンプル問題には要件定義の問題はありません（2026年10月3日の時点）。

PD-S問1の本文に当てはめると、区別は次のようになります。

種類	問1での例
業務要件	マネージャが、営業担当者ごとの媒介契約数を日々確認して実績を把握する
機能要件	ダッシュボードに、営業担当者ごとの媒介契約数を表示する
非機能要件	最新のデータを確認できる（データの鮮度。当サイトの解釈）

業務要件は業務として何を実現するか、機能要件はそのためにシステムが何をするか、非機能要件は、応答の速さや止まりにくさ、情報の守り方など、何をするかではなく、どのように動くべきかの条件です。本文の「最新のデータを確認できるように」は、どの情報を出すかではなく、どれだけ新しい状態で出すかの条件なので、非機能要件の側に置きました。

学ぶ順番：要件の区別 → 粒度 → 本文から拾う → ずれを防ぐ進め方

学ぶ順番

ITパスポート要件の区別業務・機能・非機能
DM粒度キー項目の粒度・範囲・発番ルール
PD-S本文から拾う主語と集計の単位に印を付ける
PD-Mずれを防ぐ進め方原因の工程に対策を置く

図：この記事が勧める学ぶ順番。各段の詳しい説明は、下の番号の項目にある。

ITパスポートの範囲で、業務要件・機能要件・非機能要件の違いを、上の表のような1つの業務の例で言えるようにする。
DMを受けるなら、自分の業務のデータについて、キー項目の粒度・範囲・発番ルールを説明できるかを確かめる。「企業単位か部門単位か」を言えれば、PD-S問1の「営業担当者ごとか部門全体か」と同じ区別ができている。
PD-Sを受けるなら、本文の主語と集計の単位に印を付けてから候補を選ぶ練習をする。問1では、候補の文言から「営業担当者ごとの」という修飾が削られていた。
PD-Mを受けるなら、不具合が見つかった工程と、原因が入り込んだ工程を分けて読む。原因が要件の段階にあるなら、対策も要件の段階（顧客の参加、要件と要望の突き合わせ）に置く選択肢を選ぶ。