当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
システムを作ることになって、『要件定義書って、うちが書くの？それとも開発会社が書くもの？』と迷っている方も多いはずです。会社によって言うことが違うので、混乱しますよね。
結論から言うと、要件定義書は中身を決める責任は発注側、文書にまとめる作業は開発側も手伝うという分担がいちばん多い形です。ただし「何を作るか」を決めるのは、最後まで発注側なんです。
この記事を読めば、誰が何を受け持てばいいのかが、役割表で分かります。
要件定義書は誰が作る？結論は「決めるのは発注側」
要件定義書の中身に責任を持つのは、システムを使う発注側です。開発会社が文書を書くことはあっても、何を作るかの判断を開発会社に任せきりにはできません。
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義は発注者の責任である」という一条があります。共通フレーム2013のガイダンスでも、この原則が引かれています。
『でも、うちにはシステムに詳しい人がいないし…』と思いますよね。それでも大丈夫です。
責任を持つというのは、全部を自分で書くことではありません。業務のどこを変えたいのか、何ができれば合格なのかを、発注側が決めて承認するという意味なんです。
| 立場 | 主に受け持つこと |
|---|---|
| 発注側（システムを使う会社・部署） | 目的と業務の決定、優先順位、最後の承認 |
| 開発側（システムを作る会社・部署） | 聞き取り、文書のたたき台、実現できるかの確認 |
| 両者で一緒に | 機能の範囲、性能や運用の水準、未確定事項の扱い |
仕様書は誰が作る？要件定義書とは書き手が変わる
「仕様書は誰が作るのか」という疑問もよく聞きます。実は、文書の種類によって書き手が変わるんです。
要件定義書は発注側の責任で固めます。その後の基本設計書や詳細設計書などの仕様書は、開発側が要件定義書をもとに書くのが一般的です。
文書の全体像は仕様書とは？意味と目的、設計書・要件定義書との違いで紹介しています。
公的な手引きでは誰の仕事になっている？
国の情報システムの進め方を決めたデジタル庁の標準ガイドラインでは、要件定義書を作るのは発注側のプロジェクト推進組織です。民間でも、この考え方は参考になります。
デジタル庁の「デジタル・ガバメント推進標準ガイドライン（DS-100）」では、第3編の第5章が要件定義です。ここで、発注側のプロジェクト推進組織（PJMO）が要件を定義し、要件定義書を作ると書かれています。
その要件定義書を調達仕様書に添付して、開発事業者を選ぶ流れです。つまり国の案件では、開発会社を選ぶ前に発注側が要件をまとめているんですね。
| 公的な手引き | 要件定義についての書き方 |
|---|---|
| 超上流から攻めるIT化の原理原則17ヶ条（IPA） | 要件定義は発注者の責任である |
| 共通フレーム2013（IPA） | 企画・要件定義の一部を供給者に発注する時は、請負か準委任かを区別しておく |
| DS-100（デジタル庁） | PJMOが要件定義書を作り、調達仕様書に添付する |
民間の案件では開発会社が書くことも多い
ただ、民間の案件では事情が少し違います。社内に書ける人がいない時は、要件定義の作業そのものを開発会社やコンサルタントに頼むこともよくあります。
その場合も、書くのは開発側でも「決めるのは発注側」という点は変わりません。打ち合わせで出た案に、発注側が「これで進めてください」と承認して、はじめて要件として固まります。
共通フレーム2013のガイダンスには、要件定義の一部を外部に頼む時は「請負」か「準委任」かを区別しておくのがよい、という趣旨の記述があります。契約の形は、後のトラブルを防ぐためにも最初に決めておきましょう。
要件定義の作業を3つに分けた役割表
要件定義の作業は「発注側が決める」「開発側が書く」「一緒に詰める」の3つに分けると、担当があいまいになりません。誰の作業か迷ったら、この表に当てはめてみてください。
『誰が作るか』でもめる時は、たいてい作業がひとかたまりになっています。作業をばらして並べると、受け持ちがはっきりしますよ。
| 作業 | 発注側が決める | 開発側が書く | 一緒に詰める |
|---|---|---|---|
| システム化の目的と効果 | 決める | 文章に整える | |
| 今の業務の流れと困りごと | 説明する | 業務フロー図にする | 抜けを確かめる |
| 必要な機能の一覧 | 必須か希望かを決める | 機能として書き出す | 範囲と優先順位 |
| 画面や帳票のイメージ | 使う場面を伝える | たたき台を描く | 項目の過不足 |
| 性能・セキュリティ・運用 | 求める水準を決める | 実現方法と費用感を出す | 水準と予算の釣り合い |
| データ移行 | 移すデータを決める | 移行の手順を書く | 移行の時期 |
| まだ決まっていない事 | いつ決めるかを決める | 未確定として書き残す | 決まった時の進め方 |
| 最終の承認 | 承認する |
「一緒に詰める」所で差がつく
いちばん大事なのは、真ん中の「一緒に詰める」作業です。ここを片方だけで済ませると、後で食い違いが出やすいんです。
例えば、発注側が「速く動いてほしい」とだけ言った場合を考えてみましょう。
「どれくらい速ければいいですか？」
「画面を開いてすぐに出てくれば、それで十分です」
こんなやり取りを経て、はじめて数字で確かめられる要件になります。性能や運用の水準の決め方は、非機能要件とは？要件定義書に書く項目と決め方を見てみてください。
体制によって分担はこう変わる
『うちの場合は、どの形になるんだろう？』と思った方もいますよね。発注側の体制によって、開発側が書く量は変わってきます。
| 発注側の体制 | 要件定義書の作り方の例 | 気をつけたいこと |
|---|---|---|
| 社内SEや情報システム部門がある | 社内でまとめて、開発会社に渡す | 現場の部署の声を聞き漏らさない |
| 担当者はいるが書いた経験がない | 開発会社がたたき台を書き、社内で直す | 直した所を記録に残す |
| システムの担当者がいない | 要件定義の作業ごと外部に頼む | 契約の形と承認する人を先に決める |
どの形でも、承認する人を一人決めておくと話が早く進みます。承認する人があいまいだと、決まったはずの事が何度もひっくり返ってしまうんです。
発注側と開発側、それぞれの心構え
発注側は「決めて承認する」こと、開発側は「聞き出して書き残す」ことが仕事です。どちらかが相手に丸投げすると、要件定義書は形だけになってしまいます。
IPAの17ヶ条には「ユーザとベンダの想いは相反する」「取り決めは合意と承認によって成り立つ」という条もあります。立場が違えば考えることも違う、という前提で進めるのがコツなんです。
発注側が押さえておくこと
- システムで解決したい困りごとを、自分たちの言葉で書き出しておく
- 業務をよく知る現場の人を打ち合わせに呼ぶ
- 機能ごとに「必須」か「あればうれしい」かを決める
- 決めきれない事は、いつ誰が決めるかを残しておく
- 要件定義書を読み、納得してから承認する
『専門用語が分からないから、開発会社に任せておこう』という気持ちも分かります。ただ、分からない言葉はその場で聞いてしまいましょう。
承認したあとで「こんなつもりじゃなかった」となるのが、いちばんつらいパターンです。
開発側が押さえておくこと
開発側は、発注側の言葉をそのまま書くだけでは足りません。言葉の裏にある業務の事情まで聞き出して、誰が読んでも同じに伝わる文にするのが役目です。
「月末に忙しくて困っている」と聞いたら、「月末に何件くらい、どの作業が重なるのか」まで聞いてみる。この一歩で、要件の精度がぐっと上がります。
開発側が気を利かせて、聞いていない機能を足してしまうことがあります。17ヶ条にも「機能要求は膨張する」という条があります。足したい時は、発注側に確かめてから書き加えましょう。
要件定義書は誰が作るかでよくある相談
よくある相談は「設計書は誰の物か」「先輩の書いた設計書に漏れが多い」「要件定義だけ自社でやる時の分担」の3つです。どれも、最初の取り決めで防げることが多いんです。
よく寄せられる相談を、内容をまとめた形で紹介しますね。
相談1：仕様書や設計書は、作った会社と頼んだ会社のどちらの物？
完成したプログラムは納品するけれど、途中で作った仕様書や設計書は誰の資産なのか、という相談です。閲覧数も多く、気になっている人が多い話題です。
答えは、契約でどう決めたかによります。DS-100の調達仕様書の記載事項にも「成果物の取扱い（知的財産権の帰属、契約不適合責任、検収等）」が入っています。
民間の案件でも、どの文書を成果物として納めるのか、権利はどちらに置くのかを契約前に決めておきましょう。分からない時は、社内の法務担当や専門家に相談するのが安心です。
相談2：先輩が作った設計書に漏れや矛盾が多い
設計書を見ながら開発していたら、漏れや矛盾がたくさん見つかって困っている、という相談もあります。
こういう時は、元になった要件定義書まで戻って確かめるのが近道です。17ヶ条には「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という条があります。
要件定義書に書かれていない事なら、自分で決めずに確認を取りましょう。「この部分は要件定義書に記載がないので、どちらで進めるか確認させてください」と聞けば角が立ちません。
相談3：要件定義は自社でやって、作る所だけ外に頼みたい
自社で企画と要件定義をして、プログラムを書く所だけを外部に頼みたい、という相談です。
この進め方もよくあります。その場合、要件定義書は発注側が書き上げて、開発会社に渡す形になります。
開発会社が設計に入ってから質問が出るのは自然なことです。質問への回答と、それで要件が変わった所を記録しておくと、言った言わないを防げますよ。
要件定義を自分の仕事にしたい人へ
要件定義を任される人は、発注側では社内SE、開発側ではSEやPMが多いです。どちらの立場でも、聞き出して文書にまとめる力が評価されます。
厚生労働省の職業情報提供サイト（job tag）では、受託開発のシステムエンジニアの仕事として、顧客にヒアリングして業務を理解し、どのようなシステムにするかを決める「要件定義」が挙げられています。
発注側として要件をまとめる仕事は、社内SEと仕様書｜発注側として要件をまとめる仕事で紹介しています。外部に頼む時の文書はRFP（提案依頼書）とは？要件定義書・仕様書との関係が参考になります。
要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。今の職場で経験を積むのも立派な道ですし、担当工程から一歩進みたい人は、求人の仕事内容を比べてみると道が見えてきます。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
要件定義書は誰が作るのが正しいですか？
中身を決めて承認するのは発注側です。文書を書く作業は開発側が手伝うことも多く、民間の案件では開発会社がたたき台を書く形もよくあります。
仕様書は誰が作りますか？
要件定義書は発注側の責任で固め、その後の基本設計書や詳細設計書などは開発側が書くのが一般的です。どこまでを誰が作るかは、契約の前に決めておきましょう。
発注側にシステムに詳しい人がいなくても大丈夫ですか？
大丈夫です。業務をよく知る人が、困りごとと必要なことを伝えれば、開発側が文書に整えてくれます。分からない言葉はその場で聞き、納得してから承認しましょう。
開発会社が書いた要件定義書は、そのまま承認していいですか？
読まずに承認するのは避けましょう。業務の流れや機能の一覧が自分たちの説明と合っているか、まだ決まっていない事がどう書かれているかを確かめてから承認するのが安心です。
要件定義を外部に頼む時の注意点は？
請負か準委任かなど、契約の形を先に決めておくことです。共通フレーム2013のガイダンスにも、この区別をしておくのがよいという趣旨の記述があります。
まとめ
- 要件定義書の中身を決めて承認するのは発注側
- 文書を書く作業は開発側が手伝うことも多い
- 作業を「決める」「書く」「一緒に詰める」に分けると担当が明確になる
- 設計書などの権利や成果物の範囲は契約前に決める
- 迷った時は要件定義書に立ち返って確認を取る
コメント