要件定義は誰がやるか｜決めるのは業務を持つ発注側

同じ請求の手順を営業部と経理部が別々のやり方で説明し、どちらを書けばよいかで打ち合わせが止まる場面でも、何を作るかを決めるのは業務を持つ発注側です。要件定義ができないと感じる会社で、本当に足りないのが書く人なのかは、外注先の質問に答えられない箇所を並べると分かります。決める・書く・確かめるを発注側と開発側に割り振った表は、そのまま社内の役割分担の叩き台に使えます。

当社について書くのはFDE伴走開発のサービスページに書いている進め方の範囲で、案件の期間や件数ではありません。外部の記述は、IPA（情報処理推進機構）の公開資料を2026年10月30日に読んだ範囲です。契約と法律の扱いは一般的な説明にとどめるので、個別の契約は法務や専門家に確かめてください。

要件定義とは、作るシステムが業務の中で何をするかを決めて言葉にする工程で、決める・書く・確かめるの役割に分かれる

要件定義とは、作るシステムが業務の中で何をするかを決め、開発する人に伝わる言葉にする工程です。中身は決める・書く・確かめるの3つの役割に分かれ、誰がやるかの答えは役割ごとに違います。

開発側の列に印が無いのは、どの役割も開発側だけでは終わらないからです。

言葉の使い方はIPAの要件定義ガイドに合わせます。ガイドはJIS X 0166でrequirementが普通「要求」とも「要件」とも訳されるため、要求と要件に標準的な定義はないとしています。そのうえで要求を文書化・仕様化してステークホルダ（利害関係者）と合意したものを「要件」と定義し、要件は次の工程の入力なので第三者に伝えられる形にしておく必要があるとしています。伝える先の例は業務部門からIT部門へ、IT部門からベンダへです（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／2026年10月30日閲覧）。

この定義に沿うと、要件定義は要求を決める・文書にする・文書や動くものが要件に合っているかを確かめるという3つの仕事を含み、表の3行がこれに当たります。

IPAのモデル契約（第二版）も、工程の中身を部門ごとの役割で書いています。要件定義のフェーズは、システム化計画を受けて業務部門が業務上の要求を業務要件にし、情報システム部門が実装する機能要件と非機能要件を定義して経営層の実行稟議と承認を受けるフェーズと説明されています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。機能要件はシステムが何をするかで、非機能要件は速さや止まりにくさのように機能の外側で求める条件です。情報システム部門を置いていない会社でも、業務上の要求を決める仕事は業務部門の側にあります。

決める役は業務を持つ発注側に残り、書く役と確かめる役は開発側と分け合える

決める役が発注側に残るのは、業務のどこが正しくどこを変えてよいかを知っているのが業務を持つ側だけだからです。書く役と確かめる役は、調べる・整理する・案を出す・突き合わせるといった作業に分けると、開発側が受け持てる部分が多くあります。

IPAのモデル契約（第二版）によれば、信頼性と安全性の高い情報システムを作るには事業・業務システム・情報システムの必要性を最もよく知るユーザが自らの責任で要件を的確に洗い出し、システム設計と開発に反映させる必要があります。開発段階に入る前の超上流工程で、経営層・業務部門・情報システム部門というユーザ内の役割分担のもとに、ユーザが機能要件と非機能要件を明確に定義する責任があるとも書いています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

書く役の分け方は、同じモデル契約の要件定義作成支援業務の条文に表れています。第14条の解説は要件定義を、ユーザが作ろうとするシステムの要求仕様（ソフトウェアで実現すべき機能）をまとめる作業で、ユーザの業務内容に大きく依存する作業だとしています。そのため条文は要件定義の作業をユーザが行い、ベンダがそれを支える形を前提にしています。第14条2項でベンダが行うのは情報処理技術の専門知識と経験に基づく調査・分析・整理・提案・助言などの支援業務で、ユーザの作業が円滑かつ適切に進むように行うと定めています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

決める役の置き場所は、責任者の条文に書かれています。第9条はユーザ側の責任者の権限と責任の筆頭に要件定義書を確定することを挙げ、ベンダ側の責任者には要件定義作成支援業務でユーザから求められた事項への対応についての権限と責任を置いています。第17条は、ユーザが要件定義書を書き上げた後にユーザとベンダが要件定義検討会（要件を決めるための打ち合わせ）の決定事項に合っているかを点検し、双方の責任者が記名押印すると定めています。双方の確認をもって要件定義書は確定します（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

表に置き換えると、要件定義書を確定させるのはユーザ側の責任者です。書く作業はユーザが行ってベンダが調査や提案で支え、確かめる点検は双方で行います。開発側に書く作業を多く受け持ってもらう場合でも、何を作るかを確定させる席は発注側に残ります。

IPAソフトウェア・エンジニアリング・センターの「超上流から攻めるIT化の原理原則17ヶ条」も同じ線を引いています。原理原則［9］は「要件定義は発注者の責任である」です。発注者の行動規範には、社内に「我々が要件を決め、責任を持つ」という意識を広げることが最初に置かれています。続けて業務部門とIT部門が二人三脚で要件定義を進めることと、要件定義の段階で受注者をうまく活用することが並びます。受注者の行動規範は「発注者側に立った支援を提供する」です（IPAソフトウェア・エンジニアリング・センター「SEC BOOKS：実務に活かすIT化の原理原則17ヶ条」／2026年10月30日閲覧）。

確かめる役は、2つに分けると分け合い方が見えます。要件定義ガイドは確認を、書かれた要件が要求を抜け漏れや誤りなく満たしているかを確かめる「検証」と、定めた要求そのものが目的を実現でき手段として妥当かを確かめる「妥当性確認」に分けています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／2026年10月30日閲覧）。検証は文書と決定事項の突き合わせなので、開発側が多くを担えます。妥当性確認は、業務の目的を知る側でないとできません。同じガイドは業務部門が要件定義の結果に責任を持つとし、総合テストの段階では業務部門に自らの目で検証する責任があると書いています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／印刷210頁・2026年10月30日閲覧）。

分け合うときに社内で先に決めておくのは、要件を承認する人を1人にすることです。承認する人を部署ごとに置くと、部署ごとの正解がそのまま要件に並びます。

要件定義ができない・丸投げしたくなるときは、どちらも決める役が社内で空いている

要件定義ができないときは、書く力より業務の正解が社内でまとまっていない

要件定義ができないという悩みは書き方の問題に見えて、その手前で止まっていることがあります。止まる場所は3つあります。同じ業務のやり方が部署や人によって違うこと、例外の扱いが担当者の頭の中にしかないこと、どのやり方を正解にするかを決める人が決まっていないことです。

やり方が部署で違うと、書き手はどちらのやり方を書けばよいかを決められません。例外が頭の中にあると、書いた要件は通常の流れだけを表し、例外が出た日に現場で回らなくなります。決める人がいないと、違いと例外を集めても、どれを採るかが宙に浮きます。3つとも書く力では埋まらず、決める役が空いていることから来ています。

IPAの要件定義ガイドも、オーナー（システムから期待どおりの業務上の効果を引き出す責任を持つ部門）の選定を扱う節で同じ問題を挙げています。解決したい問題の見出しは、要件定義は自分たちが責任を持って推進すべきものだと業務部門が認識していないことです。その下に、利用頻度に関わらず要求が出る・部門ごとにシステム化に対して温度差がある・実務で多忙なので「ITシステム部門にお任せ」・システム開発費用の確保はITシステム部門の役目、の4項目が並びます。本文はシステムを利用する部門も「必ずしも一枚岩ではない」とし、各部門の「思惑が分かれることにより要求が偏る」と書いています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／印刷209頁・2026年10月30日閲覧）。

ガイドの書籍ページは、ITベンダやシステム部門が中心になって要件定義を進める従来のやり方から、業務部門のユーザが主体的に関わるやり方への変革の必要性が増しているとしています。本文の「改訂にあたって」では、要件定義はITシステムをビジネスに使う当事者であるユーザが自ら中心になって行うべきものだと書いています。そのうえで、単にユーザの責任で実施すると言ってもユーザは要件定義に慣れているとは限らず、なかなかうまくいかないことが多いとも認めています。そこでガイドは何をするか・何を作るかに加えて、どう考えどう作るかを示すことを目指したとしています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／2026年10月30日閲覧）。

慣れていないことは、書く作業を外の手で補えば埋まります。埋まらないのは、どのやり方を正解にするかの判断です。社内で決める人を1人立て、その人が部署ごとの違いと例外を並べて選ぶ時間を取れるかどうかが、要件定義ができるかどうかの分かれ目になります。

丸投げすると、何を作るかの判断が社内にも外注先にも残らない

要件定義を外注先に丸投げすると、決める役が空いたまま工程が進みます。確定した要件を受けて作る形の受け手にとって、要件は発注側から渡ってくるものです。業務の正解を知らない受け手にできるのは、推測で埋めるか発注側に聞き返すことです。聞き返した先に決める人がいなければ、何を作るかの判断はどこにも残らないまま文書だけができます。

要件定義ガイドは、ユーザ企業とベンダ企業の責任分担の境目は要件定義だとしています。そのうえで、要件定義から請負契約を結ぶケースも少なくなく、ベンダ企業への丸投げ状態になって問題を起こしているプロジェクトが見られると書いています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／印刷23頁・2026年10月30日閲覧）。

モデル契約（第二版）の解説にも、請負型にするとユーザ側に「丸投げ」「ベンダにすべてお任せ」の意識が強くなる場合があるという指摘が載っています。準委任型にしなかった場合はユーザ自身が要件定義でステークホルダと調整する責任などが曖昧になりやすく、要件定義の見落としも生じやすくなるとの指摘が多いとも書いています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

17ヶ条の原理原則［4］は「ステークホルダ（利害関係者）間の合意を得ないまま、次工程に入らない」です。発注者の行動規範には「ステークホルダの合意確認を自らの仕事と心得る」が置かれています。受注者の行動規範には、合意確認の作業は支援できても請負（責任）はできないと明示することが置かれています（IPAソフトウェア・エンジニアリング・センター「SEC BOOKS：実務に活かすIT化の原理原則17ヶ条」／2026年10月30日閲覧）。

丸投げで進めた開発がすべて止まるわけではありません。ただ、止まったときに直す方向を決める人がいない状態は残ります。作業は外へ出して判断は社内に残すという分け方は新規事業の外注でも同じで、工程ごとの表は新規事業の外注が失敗する5パターンに載せています。

丸投げしたくなるのは、決める人の時間が取れないときです。その場合に外へ出せるのは決める人の時間を減らす作業で、違いと例外を集めて並べ、選ぶ材料にするところまでです。

受託・SES・コンサル・伴走型のどれでも決める責任は発注側に残り、違うのは決める材料を誰が集めるかと決める時点である

外に頼む形を選ぶときは、決める材料を誰が集めるかと決める時点で比べます。当社のFDE伴走開発のサービスページでは、よくある質問で4つの形の違いを次のように書いています。右の列は、その書き方から決める責任の置き場を読んだものです。

表は横にスクロールできます。

どの形でも、決める責任が発注側に残る点は同じです。違うのは、決めるための材料を誰がどこまで集めるかと、決める時点が作る前か作りながらかです。受託開発は作る前に決め切る形なので、要件が固まっている課題に噛み合います。伴走型は作りながら決める形なので、作り始めてからも決める人の時間を取り続ける必要があります。SESで手を増やす場合も、何を作るかを決める席は発注側で埋めておく必要があります。

契約の形（準委任・受託・顧問）の違いと選び方はFDEは採用か外部活用かにまとめたので、ここでは扱いません。

要件が固まっていない段階では、現場の業務とデータを見るところから始め、動くものを見せて決める

要件が固まっていない段階で頼むときは、要件定義書を待たずに現場の業務とデータを見るところから始めます。何を作るかが決まっていない段階でも、現場で起きていることから解くべき課題を発注側と開発側が一緒に言葉にできます。仕様を先に固めるのではなく、動くものを見せながら決めていく進め方です。

IPAのモデル契約（第二版）の解説は、システム化計画や要件定義のフェーズではユーザ側の業務要件が具体的に固まっておらず、ユーザ自身もフェーズの開始時点では成果物を具体的に想定できないとしています。動くものを見せて決める考え方も、同じ解説に開発モデルの違いとして載っています。プロトタイプモデル（試作品を使う作り方）では、フェーズを分けずにユーザの要望から試作品を作って見せ、評価しながら開発するとしています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

動くものを見せると、決める役の仕事が変わります。文書を読んで正しいかを判断するより、試作品を触って「この欄はうちの例外では使えない」と言うほうが業務を持つ人には答えやすくなります。決める人が答えた内容を開発側が要件の言葉に直せば、書く役と決める役がそれぞれの側に収まります。

要件定義ガイドの「はじめに」は、顧客とのつながりによる協働を重視しIoT・ビッグデータ・AIなど比較的新しい技術を使う分野を攻めの分野と呼んでいます。この分野ではユーザ企業が責任を持って要件を定義するという線引きだけでなく、ベンダ企業と協力してデータを集め・ため・分析してサービスにするサイクルを回すことが大切だとしています。要求のすべてが開発段階で分かるわけではなく、使ってみて初めて分かる本来の要求に応える必要があるとも書いています（IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」／印刷5頁・2026年10月30日閲覧）。

ただし、動くものを見せる進め方でも、見て決める人が発注側にいなければ試作品は増えても要件は決まりません。観察から移管までの段取りはFDEの仕事内容の記事に書き、要件定義書がない状態でどこから頼めるかの答えもその記事のよくある質問に置いています。試作品を見て本番に進むかを決める評価項目は、PoCの評価項目の記事にまとめました。

要件が完全に確定した大規模な開発や既製のSaaSで足りる課題なら、要件を固めてから発注する従来の形が合う

ここまでの進め方が、いつも合うわけではありません。当社のFDE伴走開発のサービスページでも、向かないのは要件が完全に確定した大規模開発や既製のSaaSで足りる課題で、その場合は従来型の選択肢を勧めると書いています。

要件が完全に確定しているなら、作りながら決める形を選ぶ理由は薄くなります。決める仕事はすでに終わっているので、確定した要件を受けて作る受託開発のほうが作る範囲と終わりの線をはっきり引けます。既製のSaaS（インターネット経由で使う既製のソフトウェア）で足りるなら、要件定義は作るもののためではなく選ぶもののために行います。

この場合でも、決める役が発注側にある点は変わりません。変わるのは、決める時点が作る前にまとまることです。向く課題と向かない課題の見分け方はFDE支援の使いどころに、FDE型を要件が固まる前の課題に使う投資の型として整理した背景はFDEが増えている理由の記事に書きました。

要件定義は誰がやるかについてよくある質問

Q. 要件定義書は発注側と開発側のどちらが書くものですか？

書く作業は分け合えますが、内容を承認して確定させるのは発注側です。IPAのモデル契約（第二版）も、ユーザが書いてベンダが支え双方の責任者が点検して確定させる形をとっており、条文は決める役の節で紹介しました（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。下書きの多くを開発側に頼むときは、決めた事項と決めた人と日付を発注側で記録に残しておきます。承認の前に、下書きの要件がそれぞれ記録のどの決定から来ているかを見ます。記録に無い要件が混ざっていれば、誰がいつ決めたかを確かめてから承認します。

Q. 社内に要件をまとめられる人がいない場合はどうすればよいですか？

まとめる人より先に、決める人を1人決めます。まとめる作業は外の手を借りられますが、決める人は外から連れてこられません。IPAのモデル契約（第二版）は、中小企業ユーザのように社内の体制が十分でない場合も超上流工程の重要性は変わらないとしています。自社で固められないときは、開発契約の前提としてコンサルティングを活用するか企画・要件定義段階と開発段階を別の契約にすることが望ましい、という書き方です（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。

Q. アジャイル開発なら要件定義はいらないのですか？

決める役はなくならず、決める単位が小さくなって回数が増えます。IPAのアジャイル開発版モデル契約は、プロダクトの方向性と内容に責任を持つプロダクトオーナー（PO）の役割を非常に重要とし、POはユーザ企業が選ぶとしています。ベンダ企業はバックログ（作る機能を優先順に並べた一覧）への助言や技術的なリスクの説明などを行い、スクラムマスター（チームの進め方を支える役）はベンダ企業が選びます。同じページは、ユーザ企業が利点を生かすには十分なスキルとノウハウを持つベンダ企業を選ぶだけでは足りず、主体的かつ積極的に関わる必要があり相応の負担を伴うとしています（IPA「情報システム・モデル取引・契約書（アジャイル開発版）」／2026年10月30日閲覧）。

Q. 要件定義の途中で要件が変わったらどうなりますか？

動くものを見て決める進め方では、要件が変わることを前提に置きます。先に決めておくのは、変更を誰が決めるかです。IPAのモデル契約（第二版）の第36条（未確定事項の取扱い）の解説も、実際のプロジェクトではある程度の積み残し事項を残したまま次のフェーズに進まざるを得ないことが多いと認めています。そのうえで、未確定事項の内容と確定予定時期などを書面で確かめておく扱いを定めています（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月30日閲覧）。変える判断をする人が決まっていれば、変わった点を記録に残して次に進めます。

SAIの視点：要件定義書が無い段階から着手しても、解くべき順番を合意する相手は発注側の経営と現場である

何を作るかを一緒に言葉にする段階でも、当社が持たないのはどの課題から解くかを決める席です。現場の業務とデータを見て課題を特定するところまでは当社が受け持ち、解く順番は経営・現場と合意して決めます。どれを先に直すと業務が回るかは、業務を持つ側でないと決められないからです。

観察から入るのは、インタビューでは出てこないボトルネックを現場の業務とデータから特定するためです。支援の実例は、導入事例に業種名で載せています。

対象の業務について、部署ごとのやり方の違いを並べて選ぶ人の名前を1人書けるかを見てください。書けたかどうかと、対象の業務名・止まっている箇所（「要件を出してほしいと言われた」など）をFDE伴走開発の相談の入口に添えてください。

出典と確認日

外部の出典はいずれも2026年10月30日閲覧。IPAのモデル契約（第二版）は、掲載ページから開いた解説付きのWord文書（2025年4月8日更新）で条文と解説を読んだ。要件定義ガイドの頁は印刷版の頁番号で示した。当社の一次情報はFDE伴走開発のサービスページに書いた進め方で、案件の期間や件数ではない。

• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開・最終更新日2026年9月11日。総論の超上流工程と開発モデルの説明、第9条・第14条・第17条・第36条と各条の解説）
• IPA「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日公開・最終更新日2026年9月11日）
• IPA社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年12月20日発行・第2版2刷は2021年12月13日公開。はじめに・改訂にあたって・1.1.3 システム開発の現状・3.4 用語定義・6.1.3 オーナーの選定）
• IPAソフトウェア・エンジニアリング・センター「SEC BOOKS：実務に活かすIT化の原理原則17ヶ条」（2010年10月12日発行。原理原則［4］と［9］。行動規範の引用は掲載ページから開いた折りたたみ版の一覧表による）
• 当社の進め方: FDE伴走開発のサービスページ（よくある質問・支援メニュー）