要件定義と要求定義の違いとは？事業会社 PdM と SIer での進め方の違い

この記事でわかること

• 「要求定義」と「要件定義」の違い
• 事業会社のプロダクト開発と SIer の受託開発で進め方がどう違うか
• 事業会社 PdM が担う要求定義と PRD の位置付け
• SIer における SE の役割との比較
• 要求定義を進める 6 つのステップ
• PRD に含めるべき項目とサンプル構成
• よくある失敗パターンと回避策

はじめに：要求定義と要件定義は本来別工程

日本の IT 現場では「要件定義」という言葉がよく使われますが、実務では 要求定義 と 要件定義 を別工程として扱うことが多くあります。IPA（情報処理推進機構）の共通フレーム 2013 では正式には「要件定義」「システム要件定義」という用語体系ですが、業界実務では「要求定義」という言い方も広く使われています。本記事では実務慣用に合わせて以下のように整理します。

• 要求定義（Requirements Definition）: ユーザーやビジネスが「何を実現したいか」を整理する上流工程
• 要件定義（Requirements Specification）: 要求を受けて「システムが満たすべき機能要件・非機能要件」を定義する工程

ただし、この 2 つの工程を誰がどう担うかは、事業会社のプロダクト開発 と SIer の受託開発 で大きく異なります。本記事ではまず用語の違いを整理したうえで、それぞれの現場における進め方の違いを解説し、PdM が事業会社で担う要求定義の実務に焦点を当てます。

要求定義と要件定義の違い（用語整理）

観点	要求定義（Requirements Definition）	要件定義（Requirements Specification）
英語	User Requirements / Business Requirements	System Requirements / Functional Specification
問い	「ユーザー・ビジネスが何をしたいか」	「システムは何を満たすべきか」
粒度	課題・ジョブ・ゴール	機能仕様・非機能要件・画面・項目
時期	上流（先に実施）	要求定義の後
典型的な成果物	要求仕様書・PRD・ユーザーストーリー	要件定義書・機能一覧・画面設計書

両者は論理的には別工程ですが、日本の実務では包括的に「要件定義」と呼ばれることも多く、用語の揺れが混乱の原因になっています。そして「誰がこれを担うか」は現場のタイプによって大きく変わります。

事業会社のプロダクト開発での進め方

自社でプロダクトを開発・運営する事業会社では、PdM が主体となって要求定義を進めるのが一般的です。典型的なフローは次のようになります。

事業会社の典型フロー

1. PdM がユーザーリサーチ・ビジネス課題整理: ユーザーインタビュー・データ分析・競合調査などを通じて課題を特定
2. PdM が PRD を執筆: 「何を作るべきか」を要求事項として言語化
3. 開発チーム（エンジニア・デザイナー）との協働で詳細化: PRD を起点に、技術的実現方法・UI 設計・実装タスクを議論しながら詳細化
4. 実装・リリース: スプリント単位で細かく作り、継続的にリリース
5. 指標計測・改善: リリース後の数値を見て次の要求を更新

特に SaaS や Web 系の事業会社では、PdM の PRD を起点として、そのままエンジニア・デザイナーが実装に入る 進め方が比較的一般的です。「SE が別工程でシステム要件定義書を作る」という形は、基幹系システムや規制業界の大規模システム刷新、ERP 導入などのケースを除いて、日常的なプロダクト開発では少ない傾向があります。

スクラム / アジャイル開発では、PRD に加えてバックログ（ユーザーストーリー）・受け入れ基準・スプリントゴールといった形で要求と実装が統合的に管理されます。独立した「システム要件定義書」ドキュメントを作らないケースも多く見られ、「要求」と「要件」の境界が自然に溶けた状態 で進みます。

事業会社における PdM と要求定義の関係

事業会社の PdM が担うのは、主に次の領域です。

• ユーザーが抱えている課題（ジョブ）を言語化する
• ビジネスゴールと整合するプロダクトの方向性を決める
• 優先順位を付けてスコープを決定する
• 成功の定義（指標）を明確にする
• PRD として要求事項を整理し、開発チームと協働する

これらはすべて要求定義の領域です。PdM は要件定義（狭義のシステム要件化）を独立工程として行うことは少なく、開発チームとの対話の中で実装方法を詰めていきます。

SIer・受託開発での進め方

一方、SIer や受託開発の現場では、進め方が大きく異なります。SIer は顧客企業からシステム開発を請け負う立場なので、顧客企業（発注者）と SIer（受注者）の間でやり取りが生じます。

SIer の典型フロー

1. 顧客の要求ヒアリング: SIer の SE・コンサルタントが顧客企業に対してヒアリングを実施し、業務課題と要求事項を整理
2. 要求定義: 顧客の要求を整理した要求定義書を作成。顧客と合意
3. 要件定義: 顧客の要求を受けて、システムが満たすべき機能要件・非機能要件を SE が定義。要件定義書として顧客と合意（契約時点の固定的なドキュメント）
4. 基本設計・詳細設計: SE が要件定義書を基にシステム設計を進める
5. 実装・テスト・納品: エンジニアが実装し、顧客受け入れテストを経て納品

SIer の現場では、PdM というロールが介在しないケースが多く、SE が主導で要求定義・要件定義を進めます。ただし実際には顧客側のプロジェクトマネージャー・業務部門担当者・BA（ビジネスアナリスト）などが顧客要求の整理を担い、SIer の SE と共同で作業するのが一般的です。顧客側にシステム化の要望を持つ担当者（情報システム部門のマネージャー等）がいて、その人と SE がやり取りをする構図が典型的です。

SIer の契約形態による違いも押さえておくべきです。請負契約の場合、要件定義書は「ここまで作る」という契約書に近い役割を持ち、プロダクト開発のように頻繁に更新されにくい傾向があります。一方、準委任契約やアジャイル契約では仕様の柔軟な変更が認められ、開発中の要件更新が可能なケースもあります。

事業会社 PdM と SIer SE の役割比較

観点	事業会社の PdM	SIer の SE
所属	プロダクトを運営する自社	システム開発を請け負う受注側
対話相手	自社内のエンジニア・デザイナー・経営層・ユーザー	顧客企業の担当者・自社エンジニア
担う工程	要求定義が中心（実装は開発チームと協働）	要求定義と要件定義の両方
ドキュメント	PRD（生きたドキュメント）	要件定義書（契約的ドキュメント）
変更への対応	継続的に仮説検証し更新	契約スコープで制限、変更には追加調整
成果の評価軸	プロダクトの事業成果（指標）	要件通りの納品と顧客満足

両者が混ざるケース

実務では両者が明確に分かれるわけではなく、次のような中間的なケースもあります。

• 事業会社の大規模基幹システム刷新: 自社プロダクトでも、基幹系・ERP の刷新では SIer 的なプロセス（要件定義書を作ってから実装）を取ることがあります
• SIer のアジャイル開発・プロダクト開発支援: 近年は SIer もアジャイル開発や事業会社のプロダクト開発支援に関わるケースが増え、PdM 的な関与（顧客企業の PdM と一緒に PRD を作るなど）も見られます
• スタートアップの外注開発: 小規模スタートアップが開発会社に依頼する場合、社内に PdM がいて発注先の開発会社 / フリーランスと連携するハイブリッド型もあります

PRD（Product Requirements Document）の位置付け

事業会社の PdM が主に書く成果物である PRD は、日本の現場では「要件定義書」や「要求仕様書」と呼ばれることもあります。これは英語の直訳というより、日本の IT 現場に定着している「要件定義」という言葉に PRD を当てはめて呼んでいるのが実態です。本記事の分類では、PRD は 要求定義 の領域の成果物に位置付けるのが正確です。

PRD には「なぜ作るか（Why）」「誰のためか（Who）」「何を解決するか（What Problem）」「どんなユーザー体験を実現するか（How）」が中心に記述され、実装の詳細仕様は必要最小限に留めるのが現代的な書き方です。機能の細部は、PRD を起点として開発者・デザイナーと協働しながら詳細化していきます。

SIer の要件定義書と PRD の違い

観点	SIer の要件定義書	事業会社の PRD
目的	システムが満たすべき仕様を網羅的に記述し、契約の基礎にする	解決すべき課題と成功の定義を明確化し、開発の指針にする
主読者	発注顧客・開発ベンダー・システム担当者	開発チーム・経営層・ステークホルダー
フォーカス	What（何を実装するか、どんな仕様か）	Why（なぜ作るか） + What（何を解決するか）
粒度	画面・項目レベルの詳細仕様	ユーザーストーリー + 必要な詳細
更新頻度	契約時点で固定されがち	仮説検証に応じて継続的に更新
典型的な記述形式	ISO/IEC/IEEE 29148 等の国際規格準拠の文書、機能一覧表	Markdown、Notion、Confluence

要求定義を進める 6 つのステップ（事業会社 PdM 視点）

ステップ 1: 背景と目的の言語化

何を作るかを決める前に、なぜ作るかを明確にします。「どのユーザーのどんな課題を解決するか」「ビジネス上のどのゴールに寄与するか」を具体的な言葉で書きます。ここで時間をかけることで、後の議論がブレにくくなります。

ステップ 2: ユーザーリサーチと課題の検証

背景の仮説が立ったら、実際のユーザーに話を聞いて裏付けを取ります。ユーザーインタビュー、既存データ分析、サポート問い合わせログのレビューなどを通じて、「本当にこの課題はあるのか」「解決されたらユーザーは喜ぶのか」を確認します。詳しくは本マガジンの「ユーザーインタビューとは」記事を参照してください。

ステップ 3: 成功の定義を決める

「この機能がリリースされて、何がどう変われば成功と言えるか」を定量指標で定義します。

• 定量指標: 継続率・コンバージョン率・NPS・利用時間・特定機能の利用率など
• 目標値: リリース後 30 日で X% 改善する、など
• 測定方法: どのツールでどう計測するか

ステップ 4: 要求事項（What）の記述

具体的にユーザーが実現したいことを記述します。ユーザーストーリー形式（「○○したい、なぜなら△△だから」）で書くのが一般的です。重要なのは、単に画面項目を並べるのではなく、ユーザーが達成したいゴールと紐付けて書くことです。

粒度は「開発チームが判断に迷わない程度」を目安とします。細かすぎる仕様は開発者の判断の余地を奪い、粗すぎる仕様は実装時に毎回質問されて手戻りが増えます。

ステップ 5: 非機能要求とスコープ外の明示

機能要求だけでなく、非機能要求（パフォーマンス・セキュリティ・可用性・運用性）もあわせて記述します。また、「今回は作らないもの（スコープ外）」を明示することが重要です。スコープ外を書かないと、後から「これもやってほしい」という要望が膨らみ、スコープクリープが発生します。

ステップ 6: レビューと合意形成

書いた PRD を関係者（開発・デザイン・経営・マーケ・営業・CS）にレビューしてもらい、合意を取ります。この段階で出る指摘は、実装後に修正するより圧倒的にコストが低いので、早めに広くレビューを受けるのが鉄則です。

合意が取れた PRD は、プロダクトの「現時点での決定」として記録・公開します。後からの変更は履歴が追跡できる形で管理します。

PRD に含めるべき項目

PdM が書く PRD に含めるべき項目は、企業やチームによって異なりますが、以下の要素は標準的に含まれます。

1. タイトルと概要: 何についての PRD か、1 文で表現
2. 背景と課題: なぜこの機能が必要か、ユーザー課題とビジネス課題
3. ターゲットユーザー: 誰のための機能か、ペルソナまたはセグメント
4. 成功の定義: 何が達成されれば成功か、指標と目標値
5. ユーザーストーリー: ユーザーが実現したい体験の記述
6. 要求事項（機能要求）: ユーザーが必要とする機能とその目的
7. 非機能要求: パフォーマンス・セキュリティ・可用性
8. スコープ外: 今回は作らないもの（重要）
9. 依存関係と前提条件: 他機能・外部システム・データへの依存
10. リスクと代替案: 想定リスクと対処方針
11. スケジュール: マイルストーンとリリース時期の目安
12. 関係者: 各領域のオーナー

PRD のサンプル構成

# [機能名] PRD（Product Requirements Document）

## 1. 概要
- 1 文サマリー
- バージョン・作成日・オーナー

## 2. 背景と課題
- ユーザー課題
- ビジネス課題
- 現状の数値（あれば）

## 3. ターゲットユーザー
- メインペルソナ
- セカンダリペルソナ（あれば）

## 4. 成功の定義
- 指標 1: [指標名] を [現状値] から [目標値] に
- 指標 2: ...
- 測定方法

## 5. ユーザーストーリー
- [ユーザー種別] として [機能] を使いたい、なぜなら [理由] だから

## 6. 要求事項（機能要求）
- 必要な機能 A: ...
- 必要な機能 B: ...
- ユーザーが実現したい体験: ...

## 7. 非機能要求
- パフォーマンス: ...
- セキュリティ: ...
- 可用性: ...

## 8. スコープ外
- 今回やらないこと 1
- 今回やらないこと 2

## 9. 依存関係と前提
- 他機能への依存
- 外部 API の依存

## 10. リスクと代替案

## 11. スケジュール
- M1: ...
- M2: ...

## 12. 関係者
- PdM: [名前]
- Tech Lead: [名前]
- Designer: [名前]

よくある失敗パターン

失敗 1: 要求と要件を混同する

PdM が本来は要求定義を行うべき場面で、いきなり実装の詳細仕様を書き始めてしまうパターン。ユーザー課題の解像度が低いまま機能仕様を決めると、作った機能がユーザーニーズとずれます。まずは「誰のどんな課題を解決するか」から始めることが重要です。

失敗 2: 背景の言語化が薄い

「〇〇機能を追加する」で始まる要求定義書は、背景と目的の記述が薄いパターンです。開発者が「なぜ作るか分からない」状態で作業すると、細部の判断がブレます。必ず「なぜ今これを作るか」から書き始めましょう。

失敗 3: 成功の定義がない

指標が書かれていない PRD は、リリース後に成果を測定できません。完璧な指標が決められなくても、「仮でもいいので決める」ことが重要です。リリース後に振り返り、次の意思決定につなげるためです。

失敗 4: スコープ外が書かれていない

「何を作らないか」が書かれていないと、プロジェクト途中で次々と追加要望が来て、スコープクリープが発生します。明確に「今回はやらない」と書くことで、関係者の期待値をコントロールできます。

失敗 5: レビューが不十分

PdM が 1 人で書いて開発チームに投げるだけでは、経営・マーケ・営業・CS の視点が抜け落ちます。リリース後に「そんな話は聞いてない」と言われないよう、早めに広くレビューを受けることが重要です。

失敗 6: 更新されず腐っていく

PRD は、仮説検証や開発中の学びに応じて更新されるべき生きたドキュメントです。「最初に書いて終わり」のドキュメントは実装中に現実とズレていき、結局誰も見なくなります。Notion や Confluence のようなコラボレーションツールで、継続的に更新する運用が理想です。

関連情報

PdM のスキル全体については本マガジンの「PdM のスキル・学習・リサーチ完全ガイド」記事、ユーザー理解については「ユーザーインタビューとは」、「ペルソナ設計とは」記事を併せてご覧ください。

まとめ

「要求定義」と「要件定義」は本来別工程ですが、日本の IT 現場では両者を包括して「要件定義」と呼ぶことも多く、そのため混乱が生じがちです。重要なのは、どちらの工程を誰が担うかが 事業会社のプロダクト開発 と SIer の受託開発 で大きく異なる点です。

事業会社の PdM は主に要求定義を担い、PRD を起点として開発チームと協働しながらプロダクトを作ります。一方 SIer では SE が要求定義と要件定義の両方を一貫して担当し、顧客との合意形成に基づいてシステムを開発します。自分が関わる現場がどちらのタイプかを理解したうえで、適切な成果物と進め方を選ぶことが重要です。

Granty はプロダクトから求人を探せるサイトとして、事業会社で PRD を自律的に書ける PdM 環境のプロダクトを提供しています。プロダクト開発の実務に深く関わりたい方は、ぜひご活用ください。