要件定義は誰がやる？発注者・受注者それぞれの役割と責任を徹底解説
結論：要件定義は発注者と受注者の共同作業です。 どちらか一方に丸投げすることは、プロジェクト失敗の大きなリスク要因になります。
システム開発を進める中で「要件定義って誰がやるんだろう？」と疑問を持つ方は少なくありません。発注者側は「専門家に任せればいい」と思いがちで、受注者側は「もっと情報を出してほしい」と感じていることが多いです。この認識のズレが、後のトラブルの温床になります。
本記事では、発注者・受注者それぞれが要件定義で担うべき役割と責任範囲を具体的に整理し、プロジェクトをスムーズに進めるためのポイントを解説します。
要件定義は誰がやるのか？結論から解説
Photo by Austin Distel on Unsplash
発注者（クライアント）の役割
発注者とは、システム開発を依頼する企業や担当者のことです。要件定義において発注者が果たすべき役割は、「何を実現したいか」を言語化することです。
具体的には以下のような情報を提供・整理する責任があります。
- 解決したい業務課題や経営上の目標
- 現状の業務フローや運用ルール
- 利用するユーザーの種類と人数規模
- 予算・スケジュールの制約条件
- 他システムとの連携要件
発注者はシステムの専門家でなくても構いません。ただし、「自社の業務を最もよく知っている人」として、現場の実態や要望を正確に伝える役割は不可欠です。
受注者（開発会社・SIer）の役割
受注者とは、システム開発を請け負う会社やエンジニアチームのことです。SIer（System Integrator）とは、システムの設計から構築・運用までを一括して請け負う企業を指します。
受注者の役割は、発注者の「やりたいこと」を「作れるもの」に変換することです。
- 発注者へのヒアリングと要望の整理
- 業務要件を技術的な仕様に落とし込む
- 要件の抜け漏れや矛盾の指摘
- 実現可能性の検討と代替案の提示
- 要件定義書のドラフト作成
PM（プロジェクトマネージャー）やシステムアナリスト（業務分析と要件整理を専門とする役割）が中心となって、発注者から引き出した情報を構造化します。
社内開発の場合はIT部門・PMが担う
外部への発注ではなく、社内エンジニアが開発を行う場合は、IT部門や社内PMが要件定義を主導します。この場合、「要件を出す側（事業部門）」と「要件を整理・実装する側（IT部門）」という構図になり、外部発注と本質的な役割分担は変わりません。
要件定義を「共同作業」と捉えるべき理由
Photo by Arnold Francisca on Unsplash
発注者だけでは要件を整理しきれない理由
発注者は業務のプロですが、システム開発のプロではありません。「こういうことがしたい」という要望はあっても、それをシステムとして実現するための整理・優先順位付け・技術的な制約の考慮は、専門知識がなければ難しいものです。
たとえば、「顧客管理をもっと便利にしたい」という要望一つとっても、どの機能が必要で、どの機能は後回しにできるか、既存システムとどう連携するかを整理するには、受注者側の知見が欠かせません。
受注者だけに任せると起きるリスク
一方、受注者だけに要件定義を任せると、以下のような問題が起きやすくなります。
- 業務実態とのズレ：現場の運用を知らないまま仕様を決めると、完成後に「使えない」システムになる
- 要件の後出し：発注者が関与しないまま進むと、後から「こんな機能も必要だった」という追加要望が増える
- 責任の曖昧化：「言った・言わない」のトラブルが発生しやすくなる
要件定義は、発注者の「業務知識」と受注者の「技術・整理力」を掛け合わせることで初めて機能します。
役割別：要件定義で具体的にやること一覧
発注者がやるべきこと
| タスク | 具体的な内容 |
|---|---|
| 目的・背景の説明 | なぜこのシステムが必要か、経営課題や業務課題を共有する |
| 現状業務の説明 | 現在の業務フロー、使用中のツール、課題点を整理して伝える |
| ステークホルダーの特定 | 誰がシステムを使うか、承認者は誰かを明確にする |
| 優先順位の決定 | 機能の必要度をMust/Want/Niceで分類する |
| 要件定義書のレビュー | 受注者が作成したドキュメントを確認・承認する |
| 社内調整 | 現場担当者・経営層との合意形成を行う |
受注者（PM・システムアナリスト）がやるべきこと
| タスク | 具体的な内容 |
|---|---|
| ヒアリングの設計・実施 | 適切な質問で発注者から必要情報を引き出す |
| 要件の構造化 | 機能要件・非機能要件に分類して整理する |
| ユースケース・業務フローの作成 | 図や表で要件を可視化する |
| 矛盾・抜け漏れの指摘 | 要件の論理的な整合性をチェックする |
| 実現可能性の検討 | 技術・コスト・スケジュールの観点で実現性を評価する |
| 要件定義書の作成 | 合意内容をドキュメントとして形式化する |
要件定義の責任はどちらにある？トラブル事例から考える
よくある失敗パターンと原因
ケース①：発注者が要件定義に参加しなかった
ある企業が在庫管理システムの開発を外部に依頼した際、担当者が多忙を理由にヒアリングをほぼ欠席。受注者は過去の類似案件をベースに要件を作成しました。完成後、現場から「うちの業務フローと全然合わない」という声が続出し、大規模な改修が必要になりました。
原因は明確で、発注者の業務知識が要件に反映されなかったことです。
ケース②：受注者が要件の確認を怠った
別のプロジェクトでは、受注者側が「おそらくこういう意味だろう」と解釈して開発を進め、発注者への確認を省略しました。リリース直前に「この機能の仕様が違う」と発覚し、スケジュールと予算が大幅にオーバーしました。
受注者が曖昧な要件を放置したことが原因です。
責任の所在を明確にするための契約・合意のポイント
要件定義の責任は、契約内容や合意プロセスによって異なります。断定的に「どちらが悪い」とは言えないケースも多く、事前の取り決めが非常に重要です。
実務上、以下のポイントを押さえておくことをおすすめします。
- 要件定義書を必ず書面化し、双方が署名・承認する
- 変更が生じた場合の手続き（変更管理プロセス）を契約に明記する
- 「要件定義フェーズ」を独立した契約として切り出す（一括請負ではなく段階的に契約する）
- ヒアリング議事録を毎回共有し、認識のズレをその都度解消する
要件定義書に合意した内容が後のトラブル解決の基準になります。「言った・言わない」を防ぐためにも、合意の記録は徹底してください。
要件定義をスムーズに進めるための実践ポイント
要件定義を円滑に進めるために、両者が意識しておきたいポイントをまとめます。
発注者向け
- キックオフ前に社内の要望を一度集約しておく（現場・経営・IT部門の意見をすり合わせる）
- 「何を作るか」より「何を解決したいか」を伝えることを優先する
- 要件定義フェーズに時間と人員を確保する（後工程の手戻りを防ぐ投資と考える）
- 受注者からの質問・確認依頼には迅速に対応する体制を作る
受注者向け
- ヒアリングの質問リストを事前に共有し、発注者が準備できるようにする
- 専門用語を使わず、発注者が理解できる言葉で議論する
- 要件の優先順位を発注者と一緒に決める（受注者が独断で決めない）
- 要件が曖昧なまま次工程に進まない。不明点は必ず確認する
共通して大切なこと
- 定期的なレビュー会議を設け、認識のズレを早期に発見する
- 要件定義書は「完成品」ではなく「合意の記録」として位置づける
- スコープ外の要望が出た場合は、追加か削除かを明示的に判断する
よくある質問（FAQ）
要件定義は発注者と受注者のどちらが主導すべきですか？
一般的には受注者（PM・システムアナリスト）が進行を主導し、発注者が業務知識・判断を提供するという形が多いです。ただし、発注者側に要件定義の経験者がいる場合は、発注者主導で進めることもあります。主導権よりも「両者が積極的に関与すること」が重要です。
要件定義書は誰が作成するのですか？
多くの場合、受注者（PM・システムアナリスト）がドラフトを作成し、発注者がレビュー・承認するという流れになります。発注者が作成したたたき台をベースに受注者が整理するケースもあります。いずれにせよ、最終的に双方が内容に合意することが重要です。
発注者が要件定義に参加しないとどうなりますか？
業務実態とかけ離れたシステムが完成するリスクが高まります。また、後から「こんな機能が必要だった」という追加要望が増え、コストとスケジュールの超過につながりやすくなります。要件定義フェーズへの発注者の関与は、プロジェクト全体の品質に直結します。
要件定義に失敗したとき、責任はどちらにありますか？
契約内容や合意プロセスによって異なるため、一概にどちらとは言えません。要件定義書への署名・承認があるかどうか、変更管理のプロセスが機能していたかどうかが判断の基準になります。トラブルを防ぐためにも、事前の書面化と合意プロセスの整備が不可欠です。
社内システム開発の場合、要件定義は誰が担当しますか？
社内開発の場合は、要望を出す事業部門と、開発を担当するIT部門・社内エンジニアが協力して進めます。外部発注と同様に、「業務を知っている人」と「技術・整理ができる人」の両方が関与することが重要です。社内PMが橋渡し役を担うケースが多いです。
要件定義に必要なスキルや知識はどんなものですか？
受注者側には、ヒアリング力・業務分析力・ドキュメント作成力・論理的思考力が求められます。発注者側には、自社業務の深い理解と、要望を言語化する力が必要です。どちらの立場でも、相手の立場を理解してコミュニケーションできる能力が特に重要です。
要件定義の工数はどのくらいかかりますか？
プロジェクトの規模や複雑さによって大きく異なります。小規模なシステムであれば数週間、大規模なシステムでは数ヶ月かかることもあります。一般的に、開発全体の工数の10〜20%程度を要件定義に充てることが望ましいとされていますが、プロジェクトの性質によって変わります。工数を削りすぎると後工程の手戻りが増えるため、十分な時間を確保することをおすすめします。
