システム開発を初めて外注したとき、「要件定義書を作成してください」と言われて戸惑う方は少なくありません。要件定義書は誰が作るのが正解なのか、自分のような非エンジニアが書くものなのか、それとも開発会社が用意してくれるものなのか。迷うのは当然です。
先に結論をお伝えすると、要件定義書という文書を取りまとめるのは多くの場合が開発会社です。しかし、そこに何を書くかを決める主体は発注側です。つまり「作る」を文書化と意思決定に分けて考えると、役割分担がすっきり整理できます。
この記事では、要件定義書を誰が作るのかという問いに対して、発注側と開発会社の役割分担を整理し、発注側が必ず果たすべき役割と、丸投げが許されない理由を実務目線で解説します。これから要件定義に臨む発注担当者が、自分のやるべきことを具体的に掴める形でまとめました。
この記事のポイント
- 要件定義書の文書化は開発会社、書く中身を決めるのは発注側という役割分担が基本
- 「要件を出す」のは発注側、「要件定義書にまとめる」のは開発会社と整理する
- 要件定義を丸投げすると失敗し、裁判では発注側の協力義務が問われることもある
- 発注側は業務情報・優先順位・判断を出す役割で、ここは代わりがいない
目次
要件定義書は誰が作るのか
文書を作るのは開発会社が多い
要件定義書という成果物そのものを書き起こすのは、多くのプロジェクトで開発会社（ベンダー）です。要件定義書には、機能の一覧、画面の構成、データの扱い、非機能要件などを、開発に使える粒度と形式で記述する必要があります。どの項目をどこまで書くべきかは開発の経験がないと判断しづらく、ここは専門家であるベンダーの役割です。
そのため、発注側が一からExcelで要件定義書を書き上げる必要は基本的にありません。「要件定義書を作ってください」と発注側が言われた場合でも、それは「真っ白な状態から全部書け」という意味ではなく、「要件を決めるプロセスに主体的に参加してほしい」という意味であることがほとんどです。もし本当に発注側がゼロから書くことを求められているなら、それは支援の薄い契約になっている可能性があるので、ヒアリングや文書化をどこまでベンダーが担うのかを契約前に確認しておきましょう。
要件定義書の具体的な項目や書き方そのものを知りたい場合は、要件定義書の作り方と成果物サンプルで構成を確認しておくと、開発会社から出てきた文書も読み解きやすくなります。
中身を決めるのは発注側
一方で、要件定義書に何を書くか、つまりどんなシステムを作るのかを決めるのは発注側の責任です。ここを取り違えると、プロジェクトは高い確率で失敗します。
システム開発は、発注側が「何を解決したいか」「業務をどう回したいか」を決め、その実現方法をベンダーが設計するという形で進みます。業務の実態、現場のルール、優先順位、予算、これらは発注側にしか分かりません。ベンダーは開発の専門家ですが、あなたの会社の業務の専門家ではないからです。
整理すると、システムへの要件を出すのは発注側（ユーザー）、出された要件を要件定義書という文書にまとめるのは開発会社（ベンダー）、という分担になります。文書を書く人と、中身を決める人は別だと理解しておきましょう。
この分担を誤解すると、両極端な失敗が起きます。一方は、発注側が「専門家に任せよう」と何も伝えずに丸投げするケース。もう一方は、逆に発注側が技術的な実現方法まで細かく指定してしまい、ベンダーの提案を活かせないケースです。どちらも結果は良くありません。発注側は「何を実現したいか」までを語り、「どう実現するか」はベンダーに委ねる。この境界を意識すると、お互いの強みが噛み合います。
役割を文書化と意思決定で分ける
この役割分担を表にすると、自分が何を担うのかが具体的に見えてきます。
| 項目 | 発注側（ユーザー） | 開発会社（ベンダー） |
|---|---|---|
| 業務の説明 | 現状の業務・課題・例外を伝える | 不足を質問でひき出す |
| やりたいことの決定 | 目的・優先順位を決める | 実現案・代替案を提示する |
| 文書の作成 | 内容が業務と合うか確認する | 要件定義書として記述する |
| 承認 | 内容を確認し承認する | 承認をもとに設計へ進む |
発注側の仕事は「書く」ことより「伝える・決める・確認する」ことに集中します。文書化はベンダーに任せても、業務情報の提供と意思決定だけは肩代わりしてもらえません。ここが要件定義の役割分担の核心です。
この表で特に見落とされやすいのが「やりたいことの決定」の行です。発注側が「いい感じにしてほしい」とだけ伝えると、ベンダーは判断材料がなく手が止まります。優先順位や予算という制約条件を発注側が示してはじめて、ベンダーは現実的な実現案を出せます。決めるのが発注側の仕事だというのは、裏を返せば、決めてもらえないとベンダーも動けないということなのです。
社内に作れる人がいない場合の選択肢
とはいえ、社内にITに詳しい人がおらず、要件を整理して伝えること自体が難しいケースもあります。その場合の選択肢は主に3つです。
- 開発会社の要件定義支援を手厚く受ける（ヒアリングを多めに設定してもらう）
- 要件定義だけを切り出して、上流に強い会社や支援サービスに依頼する
- 発注側を支援する立場の専門家（社外CTOやITコンサル）に入ってもらう
いずれの場合も、最終的に業務の意思決定をするのは発注側であることは変わりません。支援を受けるのは「決めるための材料を整える」ためであって、「決めること自体を丸投げする」ためではない、という点だけは押さえておきましょう。
なお、要件定義を支援サービスや開発会社に手厚く依頼する場合、その費用や工数は別途かかります。要件定義だけを切り出して発注できるケースもあるので、見積もりを取るときは「要件定義フェーズにいくら、どれくらいの期間がかかるのか」を確認しておくと予算計画が立てやすくなります。社内に人がいないこと自体は珍しくないので、引け目に感じず、足りない部分を補う前提で体制を組むのが現実的です。
要件定義書を誰が作るにせよ発注側が担う役割
発注側が出すべき情報
要件定義をスムーズに進める最大のコツは、発注側が持っている情報を事前に整理しておくことです。ベンダーはヒアリングで情報を引き出そうとしますが、その場で思い出しながら答えるのと、準備した資料をもとに話すのとでは、要件の精度がまるで違います。
発注側が用意したい情報
- システム化で解決したい課題と、実現したい状態
- 現状の業務の流れと、関わる人・部署
- 例外的な業務（締め処理、特殊な承認、繁忙期の運用など）
- 絶対に外せない要件と、あれば良い程度の要望の区別
- 予算の上限と、いつまでに使い始めたいかの希望
これらは完璧な文書である必要はなく、箇条書きのメモや現行の帳票で構いません。大事なのは、現場の実態をベンダーに渡せる状態にしておくことです。要件の優先順位の付け方に迷う場合は、ペルソナやユーザーストーリーで使う人の視点から整理すると決めやすくなります。
特に効くのが、現状の業務で使っている帳票やExcel、画面のスクリーンショットをそのまま見せることです。言葉で業務を説明するのは難しくても、実物を見せればベンダーは現状を正確につかめます。「今これをこういう順番で入力していて、ここが手間」という具体が伝わると、要件のズレは大きく減ります。完璧な資料を作ろうとして着手が遅れるより、手持ちのものを早く共有するほうが結果的に良い要件定義書につながります。
丸投げが許されない理由
「専門家に任せたほうが良いものができる」と考えて、要件定義をベンダーに丸投げするのは危険です。理由は2つあります。
1つ目は、品質の問題です。ベンダーが業務を知らないまま要件を埋めると、現場で使えないシステムができあがります。テストや本番稼働の段階で「これでは業務が回らない」と発覚すると、設計からのやり直しになり、追加費用と納期延長を招きます。
2つ目は、法的な責任の問題です。システム開発を巡る裁判では、ベンダーのプロジェクトマネジメント義務とあわせて、発注側の「協力義務」が争点になることがあります。発注側が必要な情報提供や意思決定を怠り、それがプロジェクト頓挫の一因と判断されれば、発注側にも責任が及ぶ可能性があります。要件定義は、丸投げしたくてもできない構造になっているのです。
もう少し身近な言い方をすると、要件定義の丸投げは「家を建てるのに、間取りも予算も伝えず全部おまかせします」と言うようなものです。建築士がどれだけ優秀でも、住む人の暮らし方を聞かずに理想の家は建てられません。システム開発もまったく同じで、業務を一番知っている発注側が黙っていては、現場で使えるものはできあがらないのです。専門知識が必要な部分はベンダーに頼り、自社にしか分からない部分は自分たちが責任を持つ。この線引きが、丸投げと適切な依頼を分ける境目になります。
レビューと承認も発注側の仕事
要件定義書はベンダーが書きますが、その内容が業務と合っているかを確認し、承認するのは発注側の重要な役割です。承認した内容が、以降の開発・費用・納期・検収の基準になるため、ここを雰囲気で通してはいけません。
レビューでは、専門用語の正しさではなく「自社の業務と合っているか」「やりたいことが漏れていないか」を見ます。判断できない項目は、そのままベンダーへの質問に変換すれば十分です。承認前に何を確認すべきかは要件定義書レビューのチェックリストに観点をまとめているので、文書が届いたら突き合わせてみてください。
特に利用部門の担当者をレビューに巻き込むことが、抜け漏れを防ぐ近道です。取りまとめ担当だけで承認すると、現場しか知らない例外業務が漏れたまま開発が進んでしまいます。実際に毎日その業務を行っている人の目を通すだけで、要件定義書の精度は一段上がります。
レビューにかける時間も確保しておきましょう。受け取ったその場で承認するのではなく、最低でも数日は確認期間を取り、社内の関係者に回覧して意見を集めるのが理想です。要件定義書は分量が多く専門的に見えるため敬遠されがちですが、ここで時間を惜しむと、後工程での手戻りという形で何倍もの時間を失うことになります。
要件定義の進め方の全体像
役割分担が分かったら、次は要件定義そのものの進め方を押さえておくと安心です。発注側が準備し、ベンダーがヒアリングし、要件定義書にまとめ、発注側が確認・承認する。この一連の流れの中で、どのタイミングで何を決めるのかを把握しておくと、ベンダー任せにならずに進められます。
要件定義の準備からヒアリング、合意までの流れは要件定義の進め方と失敗しない準備で詳しく解説しています。役割分担とあわせて読むと、自分がいつ何をすべきかが時系列で見えてきます。
初めての発注では、すべてを完璧にやろうとせず、まず「業務の情報を出す」「優先順位を決める」「届いた文書を確認する」の3つだけは自分の仕事だと意識するところから始めれば十分です。
逆に言えば、この3つさえ発注側が責任を持って担えば、専門的な文書化や技術的な判断はベンダーに安心して任せられます。要件定義書を誰が作るかで悩むより、自分が担うべき3つの役割に集中するほうが、プロジェクトは前に進みます。役割分担がはっきりしていれば、ベンダーとの関係も「丸投げと不信」ではなく「分担と信頼」で進められるようになります。
