要件定義は誰がやる？発注側とベンダーの役割分担と失敗しない進め方を解説

システム開発を発注する側は「専門家に任せたい」と考え、受注する側は「業務のことは分からないので教えてほしい」と考える。要件定義が進まないプロジェクトでは、この構図がよく起きています。お互いが相手に期待した結果、誰も主体的に動かないまま時間だけが過ぎていきます。

調べてみると、「要件定義は発注者の責任」と書かれた記事と、「システム開発者がやるべき」と書かれた記事の両方が出てきます。矛盾しているように見えますが、実は「責任を負うのは誰か」と「作業を担うのは誰か」という別々の話を、同じ言葉で議論しているだけです。

本記事では、この2つを切り分けたうえで、発注側とベンダー側がそれぞれ担う役割、社内に置くべき体制、丸投げしたときに起きること、そして人材がいない場合の選択肢までを順番に整理します。

確認したいポイント	結論	詳細
要件定義は誰がやる？	発注側とベンダーの協同	要件を出すのは発注側、要件定義書としてまとめるのはベンダー、という分担が実務の標準形です。
最終的な責任は誰にある？	発注側にある	IPAの原理原則でも「要件定義は発注者の仕事であり、発注者の責任で行うもの」と示されています。
ベンダーの役割は？	引き出し、具体化し、文書化する	経験にもとづく助言と、開発に使える粒度への落とし込み、そしてリスクの指摘が役割です。
丸投げするとどうなる？	業務に合わないものができる	技術的に作りやすい要件に寄り、ずれが後工程で表面化して追加費用と納期遅延を招きます。

この記事でわかること

• 「誰がやるか」で意見が割れる理由と、責任と作業を切り分けた整理
• 発注側でなければ担えない4つの役割と、その具体的な中身
• ベンダー側に期待してよい役割と、期待すべきでない範囲
• 丸投げしたときに起きることと、協力義務という論点
• 社内に専門人材がいない場合に取れる現実的な選択肢

▼ システム導入や業務改善の進め方を整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

「誰がやるか」で意見が割れる理由

まず混乱の原因を整理します。論者によって答えが違うのは、指している範囲が違うからです。ここを切り分けると、答えは明確になります。

責任の所在と作業の分担は別の話

要件定義には、何を作るかを決めるという意思決定の側面と、それを開発に使える形へ落とし込むという作業の側面があります。この2つは性質がまったく違います。

前者は、業務をどう変えるか、何を優先するか、どこまでで妥協するかという判断です。後者は、機能一覧や画面構成、データの扱い、非機能要件を、決められた粒度と形式で記述する作業になります。

判断する人と、書く人は別でよい。この整理ができると、「誰がやるか」という問いは「どの部分の話か」に置き換えられます。

この切り分けは、社内でシステムを内製する場合にも当てはまります。業務側を発注者、開発側を受注者と読み替えれば、同じ構造で整理できます。

「発注者の責任」という原則

意思決定の側面については、明確な原則が示されています。IPAが公開する原理原則では、要件定義は発注者の仕事であり、発注者の責任で行うものだと明記されています（出典：IPA「実務に活かすIT化の原理原則17ヶ条」）。

その理由も示されています。要件定義が曖昧なまま、あるいは検討不足のまま開発を依頼した場合、コスト増、納期遅れ、品質低下を招くおそれがある。そしてその責任を受注者に負わせることはできない、という考え方です。

どんな事業を営むかがその企業自身の問題であるのと同じように、どんなシステムを構築するかもその企業自身の問題である。この前提に立つと、判断を外部に委ねることの不自然さが見えてきます。

「開発者がやるべき」という主張の背景

一方で、作業の側面に着目すれば、別の結論も成り立ちます。要件定義書をどの粒度で、どの形式で書くべきかは、開発の経験がないと判断できません。ここは専門家の領域です。

やること、やらないことの線引きにも技術的な知識が要ります。「その機能は標準で用意されている」「この要望は実現できるがコストが跳ね上がる」といった判断は、発注側だけではできません。

つまり、この主張も間違ってはいません。ただし、同じ記事でも「発注者が丸投げしてよいわけではない」と必ず補足されている点に注意してください。前提となる情報の提供は発注側の仕事だと、どの立場からも言われています。

なお、要件定義を得意としない開発会社も存在します。開発工程に特化している場合、上流の進行そのものに不慣れなことがあるため、依頼先を選ぶ段階で確認しておくと安心です。

整理すると結論はこうなる

まとめると、要件を出すのは発注側、それを要件定義書という文書にまとめるのはベンダーという分担が実務の標準形です。文書を書く人と、中身を決める人は別だと理解してください。

そして最終的な責任は発注側にあります。書いたのがベンダーであっても、その内容でよいと承認するのは発注側だからです。この構造は、どんな契約形態でも変わりません。

発注側が担う役割

では具体的に、発注側は何をするのか。「書く」ことより「伝える、決める、確認する」ことに集中するのが基本です。4つの役割に整理します。

目的とゴールを決める

最初の役割が、なぜこのシステムを作るのか、完了したときに何が実現されているのかを定めることです。ここが曖昧なままだと、以降のすべての判断がぶれます。

ゴールは測れる形にしておきます。「業務を効率化する」ではなく「月次集計にかかる時間を20時間から5時間にする」と書けば、要望が出てきたときに「それはゴールに寄与するか」で判断できます。

この役割はベンダーには担えません。事業の方向性や経営判断が絡むためです。

あわせて、ゴールに含めない範囲も決めておきます。「今回は在庫管理までは対象としない」と明示しておけば、途中で範囲が膨らむのを防げます。

現行業務の情報を出す

2つ目が、今の業務がどう回っているかを正確に伝えることです。誰が何をどの順で行い、どんな例外があり、なぜその手順になっているのか。

手順書と実態がずれていることは珍しくありません。ベンダーは資料に書かれていないことを知る術がないため、実際に作業している人からの情報提供が不可欠です。

ここを省くと、設計上は正しいのに現場では使えないシステムができあがります。時間はかかりますが、削ってはいけない部分です。

優先順位を決め、やらないことを決める

3つ目が、限られた予算と期間のなかで何を諦めるかの判断です。要望をすべて盛り込めることはまずありません。

この判断はベンダーにはできません。どの業務がどれだけ重要かは、その企業の事情によって決まるからです。ベンダーができるのは、選択肢とそれぞれのコストを示すところまでです。

部署間で要望が競合した場合の調整も、発注側の仕事になります。社内の利害調整をベンダーに委ねると、必ずどこかで詰まります。

判断を先送りすると、その分だけ後工程が圧迫されます。決められない理由が情報不足なのか、権限がないのかを切り分け、必要なら上位者へ早めに上げてください。

内容を確認して承認する

4つ目が、提示された要件定義書の内容を確認し、承認することです。読まずに押印するのは承認ではありません。

確認の観点は、業務が回るかどうかです。技術的な妥当性はベンダーが担保する部分なので、発注側は「この手順で現場が動けるか」を見ます。

実際に作業する担当者にも目を通してもらってください。管理職だけで承認すると、現場での例外処理が抜け落ちたまま進みます。

▼ 発注側としての進め方をご相談いただけます 何を決めておくべきか、どう社内をまとめるか、ベンダーとどう分担するか。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

ベンダー側が担う役割

次に、ベンダーに期待してよい範囲を整理します。専門家として求めるべきことと、期待すべきでないことの線引きが重要になります。

要望を引き出して具体化する

ベンダーの中心的な役割が、豊富な経験をもとに適切な助言を行い、要望をシステム設計に落とし込めるレベルまで具体化することです。ヒアリングの設計と進行も含まれます。

発注側が言葉にできていない要望を引き出すことも期待される部分です。「こうしたい」の裏にある本当の困りごとを探るのは、経験が要る作業になります。

過去の類似案件の事例を提示してもらうのも有効です。他社がどう解決したかを知ることで、自社の要望が特殊なのか一般的なのかを判断できます。

実現性とコストの見通しを示す

出てきた要望について、技術的に実現できるか、どの程度の工数がかかるか、スケジュールに収まるかを示すのもベンダーの役割です。

「できます」とだけ答えるのは不十分です。実現方法が複数あるなら選択肢を並べ、それぞれの長所と短所、コストの違いを提示する。発注側が判断できる材料を揃えるところまでが仕事です。

要件定義書として文書化する

前述のとおり、成果物としての要件定義書を書き起こすのは、多くのプロジェクトでベンダー側です。機能一覧、画面構成、データの扱い、非機能要件を、開発に使える粒度で記述します。

どの項目をどこまで書くべきかの判断には経験が要ります。ここを発注側に求めるのは現実的ではありません。

ただし、書かれた内容が業務の実態と合っているかを確認するのは発注側です。文書化を任せることと、内容を確認しないことは別問題だと理解してください。

リスクを指摘する

見落とされやすいのが、発注側が気づいていないリスクを指摘する役割です。要件が曖昧なまま次工程へ進もうとしているとき、スケジュールに無理があるとき、それを伝えるのも専門家の仕事です。

言われたとおりに作るだけのベンダーは、一見協力的に見えて実はリスクが高くなります。指摘してくれるかどうかは、パートナーを選ぶ際の判断材料になります。

▼ ベンダー選定や役割分担の設計もご相談いただけます 何を社内で担い、何を外部に任せるか。プロジェクトの立ち上げ段階からご一緒に整理します。 ＞ 相談予約はこちら

発注側に置くべき体制

責任が発注側にある以上、それを担う人と体制が社内に必要です。誰をどう配置するかを整理します。

発注側にも責任者を置く

まず必要なのが、プロジェクト全体に責任を持つ発注側の担当者です。日本では「ベンダーに丸投げ」という進め方が根強く残っていますが、欧米では発注者側にプロジェクトマネージャーや要件定義の担当を置くのが一般的とされています。

この担当者に求められるのは、技術的な専門性より社内の意思決定を動かせることです。関係部署から情報を集め、要望を調整し、必要な判断を上位者から引き出す。この役割ができる人を選んでください。

兼務でも構いませんが、割ける時間を事前に確保しておく必要があります。通常業務の片手間では、ヒアリングの日程調整すら進みません。

社外の支援を受ける場合でも、この担当者を置かずに済ませることはできません。窓口が不在のプロジェクトは、支援する側も動きようがなくなります。

業務部門をどう巻き込むか

実際に業務を行っている部門の参加は不可欠です。ただし、「協力してください」と依頼するだけでは動きません。通常業務が優先されるためです。

効果があるのは、参加の負荷を具体的に示すことです。「週1回1時間、3か月間」と明示し、上長の合意を取ったうえで依頼する。この段取りがあるかどうかで、参加の質が変わります。

完成後に使う人が要件定義に関わっていると、導入時の抵抗も小さくなります。参加の負荷は、定着のための投資と考えてください。

情報システム部門の役割

情報システム部門がある場合は、既存システムとの整合、セキュリティ方針、社内の技術標準の観点から関与します。業務部門だけで進めると、後から実現不可能だと判明することがあります。

ただし、情報システム部門が業務の要件まで決めるのは無理があります。業務を知っているのは業務部門です。どちらか一方に任せる構図を避けることが重要になります。

経営層の関与

部署間で利害が対立したとき、決着をつけられるのは経営層だけです。「最終判断は誰が下すのか」を事前に決めておかないと、要件が固まりません。

定期的に進捗を報告する場を設け、判断が必要な論点を上げる仕組みを作っておいてください。トラブルになってから初めて経営層が登場するのでは、選べる手が限られます。

丸投げすると何が起きるか

役割分担が機能しないまま進めると、予測できる形で問題が現れます。典型的なパターンを知っておくと、回避の判断がしやすくなります。

業務に合わないシステムになる

ベンダー任せにすると、技術的に作りやすい要件に寄り、業務実態とのずれが生じます。悪意があるわけではなく、業務を知らないのだから当然の結果です。

このずれは、多くの場合テスト工程か、最悪の場合は稼働後に発覚します。その時点での修正は、要件定義段階で直すより何倍もコストがかかります。

さらに問題なのは、稼働後に現場が使わないという結果です。要件定義に関わっていない人にとっては、押しつけられたシステムにしか見えません。

「言った言わない」になる

役割分担を明確にしないまま走り出すと、後で「言った言わない」のトラブルに発展します。誰が何を決めたのかが記録されていないためです。

打ち合わせの議事録を残し、合意した内容を文書化して双方で確認する。地味ですが、これが最も効く対策になります。

協力義務という論点

トラブルが法的な争いに発展した場合、発注側の協力義務が問われることがあります。必要な情報を提供しなかった、意思決定を先送りしたといった点が争点になる例があります。

一方で、ベンダー側にもプロジェクトを適切に運営する義務が問われる場合があります。どちらか一方が一方的に責任を負うという単純な構図にはなりません。

なお、個別の事案における法的な判断は事情によって異なります。契約や責任の範囲で懸念がある場合は、法務部門や弁護士にご確認ください。ここでは、記録を残すことの重要性を示す文脈として触れています。

追加費用と納期遅延

要件が固まらないまま次工程に進むと、後から要件が追加され、そのたびに見積もりと納期の見直しが発生します。予算超過の典型的な原因です。

この問題は、要件定義に十分な時間を取らなかったことが原因であることがほとんどです。急いで進めた結果として遅くなるという構造を、関係者で共有しておいてください。

▼ 「うまく進んでいない」段階でもご相談いただけます 要件が固まらない、社内の合意が取れない、ベンダーとの認識がずれている。 そうした状況の整理からご支援します。 ＞ 相談予約はこちら

社内に人材がいない場合の選択肢

「担う役割は分かったが、できる人がいない」という状況は現実的によくあります。主体的に関与することと、すべてを自前でやることは違います。取れる選択肢を整理します。

発注者側の支援を受ける

近年は、発注者を支援することを専門とするコンサルティングの形態が広がっています。開発を請け負うベンダーとは別に、発注側の立場で要件整理を手伝う役割です。

利点は、開発を受注する側との利害が分離していることです。判断の材料を中立的な立場から提示してもらえます。費用は発生しますが、手戻りのコストと比べて判断してください。

ただし、この形態でも最終的な判断は発注側が下すという構造は変わりません。支援であって代行ではない、という点は押さえておいてください。

選ぶ際は、その支援者が特定のベンダーと利害関係を持っていないかも確認してください。中立であることが、この形態の価値の源泉になります。

小さく始めて学ぶ

いきなり基幹システムの刷新から始めるのではなく、規模の小さい業務から手をつけるという進め方もあります。要件定義の経験そのものが社内に蓄積されます。

ノーコードのツールを使えば、要件を文書で伝える前に動くものを作って確認できます。作りながら決めるという進め方は、要件を言葉にするのが苦手な組織と相性がよくなります。

生成AIを補助に使う

近年は、ヒアリング項目の洗い出しや、聞き取った内容の整理に生成AIを使うという方法も広がっています。白紙から考えるより、候補を前に取捨選択するほうが人にとっては速い作業です。

ただし、出力をそのまま使うことはできません。業務固有の事情を理解した判断はできず、書かれていない前提を補って生成することもあります。叩き台として扱い、確認は人が行う運用にしてください。

段階的に内製化する

外部への依存を続けると、案件のたびに費用がかかり、社内に知見が残りません。最初の数件を伴走してもらいながら一緒に進め、徐々に自社で担える範囲を広げる進め方が現実的です。

目指すのは、すべてを自前でやることではありません。何を任せて何を自分で決めるかを、自社で判断できる状態になることです。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

役割分担を機能させる進め方

最後に、分担を実際に動かすための実務的な工夫を整理します。決めておくだけで、多くのトラブルは避けられます。

最初に分担表を作る

プロジェクトの開始時に、誰が何を担当するのかを一覧にして双方で合意しておきます。現行業務の整理、資料の提供、テストデータの準備、環境の用意、承認。作業を並べて担当を書き込むだけの表で構いません。

この表があると、進行中に「それはそちらの仕事では」という議論が起きません。発注側が担う作業の量を、事前に把握できるという効果もあります。

共通の枠組みとして、IPAの共通フレームを参考にする方法もあります。企画から要件定義、開発、運用までの作業項目と役割が体系的に整理されており、用語をそろえる土台として使えます（出典：IPA「共通フレーム2013」）。

分担表は一度作って終わりではありません。進行中に想定外の作業が出てきたら、その都度どちらが担うかを決めて追記していく運用にしてください。

決める人と決める場を明確にする

誰の承認をもって要件が確定するのか、その判断はどの会議で行うのかを決めておきます。これが曖昧だと、決まったはずの内容が後から覆ります。

判断が必要な論点が出たときのエスカレーションの経路も決めておいてください。現場で決められない案件が滞留するのは、この経路がないことが原因です。

合意の記録を残す

打ち合わせのたびに議事録を作り、決定事項、保留事項、次回までの宿題を明記します。双方が確認したうえで確定させる運用にしてください。

要件定義書が完成したら、版数と承認日、承認者を記録します。その後の変更も、いつ誰の判断で変えたのかを残しておけば、後から経緯をたどれます。

担当を1人に集中させない

発注側の担当者が1人だけという体制は、その人の異動や退職でプロジェクトが止まります。副担当を置き、情報を共有しておいてください。

あわせて、社内で要件定義に関われる人を増やす取り組みも並行して進めてください。一度きりのプロジェクトで終わらせず、次に活かせる形にすることが投資の回収につながります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

要件定義を「誰がやるか」の答えは、要件を出すのは発注側、要件定義書としてまとめるのはベンダーという分担になります。判断する人と書く人は別でよく、最終的な責任は発注側にあります。

発注側が担うのは、目的とゴールを決める、現行業務の情報を出す、優先順位を決めてやらないことを決める、内容を確認して承認する、の4つです。いずれもベンダーには肩代わりできません。

ベンダーには、要望を引き出して具体化すること、実現性とコストの見通しを示すこと、文書化すること、そしてリスクを指摘することを期待します。言われたとおりに作るだけの相手は、かえってリスクになります。

そして、社内に人材がいないことは丸投げの理由になりません。発注者支援の活用、小さく始める、生成AIを補助に使う、段階的に内製化する。主体的に関与しながら外部の力を借りる方法は、いくらでもあります。

▼ システム導入と業務改善を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しから要件の整理、システム化・AI活用の設計、社内への定着支援までを一貫してご支援しています。 何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら