要件定義とは「何を作るか」を決める工程｜発注者がやることと費用・期間

業務システムの開発を依頼しようとしたら、見積書や打ち合わせで「要件定義」という言葉が出てきて、戸惑っていませんか。
何をする工程なのか、依頼前に自社でどこまで決めればよいのか、開発に詳しくない自分が関われるのか、費用や期間はどれくらいか。気になることは多いはずです。

この記事では、要件定義の意味と決めること、似た言葉（要求定義・基本設計）との違いを説明します。
そのうえで、依頼前に発注者がまとめることと開発会社と一緒に決めることの線引き、進め方、要件定義書で確かめる点、要件を決めきれない場合や置き換える場合の進め方、費用と期間の目安を整理しました。

この記事を執筆するのは、業務システムの受託開発を行うEPICsです。
当社は業務診断（現場の業務と課題を確かめる作業）から始め、既製のサービスで足りる場合は作らない選択肢も含めて中立に提案しています。開発実績は250件以上です（出典：EPICs アプリ・システム受託開発サービス）。

要件定義とは？システム開発で「何を作るか」を決めて合意する工程

要件定義とは、システム開発の最初の工程で、業務の課題を解決するためにシステムが何をするかを決め、発注者と開発会社が文書で合意することです。
「要件」とは、システムが満たすべき条件のこと。作る範囲や機能、速さなどの条件を決め、その内容を要件定義書にまとめます。
以下で、要件定義で何を決めるのか、開発のどこにあたる工程なのか、なぜ大事なのかを順に見ていきましょう。

要件定義では、業務・機能・機能以外の条件の3つを決める

要件定義で決めるのは、業務の流れ（業務要件）、システムに持たせる機能（機能要件）、機能以外の条件（非機能要件）の3つです。
非機能要件とは、画面の表示の速さ（性能）や安全性、同時に使える人数、止まらない仕組みなど、機能以外にシステムが満たすべき条件のこと。
なお、分け方や呼び方は資料や開発会社によって異なり、業務要件を「ビジネス要件」と呼ぶこともあります。

種類	決めること	業務システムでの例
業務要件	業務の流れと担当	受注から請求までを、誰がどの順で行うか
機能要件	必要な機能と、画面・帳票（請求書など、システムから出力する書類）	・受注の登録 ・請求書の発行 ・担当者ごとに見られる画面を分けること
非機能要件	機能以外の条件	・同時に使う人数 ・画面が表示されるまでの時間 ・データを保管する期間 ・セキュリティ

3つのうち、発注者が言葉にしにくく、抜けやすいのが非機能要件。
普段の業務では「何人が同時に使うか」「何年分のデータを残すか」を意識する機会が少なく、聞かれるまで決まっていないまま進みがちです。
IPA（情報処理推進機構）は、非機能要件の定義の漏れを防ぐための指針として「非機能要求グレード」を公開しています（出典：IPA「非機能要求グレード2018 利用ガイド［活用編］と経営層向け読本を改訂」）。

要件定義は、契約後に開発会社と進める最初の工程

要件定義は、開発会社と契約したあと、設計や開発に入る前に行う最初の工程です。
相談・見積もり・契約を経て要件定義に入り、設計・開発、テストへと進むのが一般的な順番。設計からテストまでの工程の全体は、システム開発の流れで紹介しています。
開発の前半で何を作るかを決める工程は「上流工程」と呼ばれ、要件定義はその始まりです。

要件定義で決めたことは、設計・開発・テストのすべての前提。テストでも、要件定義のとおりにシステムが動くかを確かめます。
なお、要件定義だけを先に契約し、その結果をもとに開発の見積もりを改めて出してもらう進め方もあります（費用と期間の章で紹介します）。

要件定義があいまいだと、追加費用と遅れの原因になる

要件定義があいまいなまま開発に進むと、できあがったものが業務に合わず、作り直しや追加の費用、納期の遅れにつながりやすくなります。
2019年に発行されたIPAの「ユーザのための要件定義ガイド 第2版」の紹介ページも、システム開発の遅延の過半は要件定義の失敗にあると言われていると紹介しています（出典：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」）。

影響が大きくなるのは、後の工程に進むほど、決めたことを変えるときに作り直す範囲（手戻り）が広がるため。
画面ができてから業務の流れの違いに気づくと、画面だけでなく、その裏の処理やデータの持ち方まで直すことになりかねません。

要件定義で目的と範囲を合意しておけば、見積もりの精度が上がります。
追加の費用が出たときも、合意した範囲の内か外かで判断しやすくなるでしょう。

要求定義・基本設計・RFPとは何が違う？

要求定義は発注者の「こうしたい」をまとめること、要件定義はそれをシステムで実現する内容に落として合意すること、基本設計は画面や帳票など使う人から見える部分を決めることです。
RFP（提案依頼書）は、開発会社に提案と見積もりを依頼するために、発注者が作る文書を指します。
それぞれの違いを表にまとめました。

言葉	何をするか	主に作る人	いつ
要求定義	困りごとと実現したいことをまとめる	発注者	相談の前
RFP（提案依頼書）	要求をもとに、提案と見積もりを依頼する文書	発注者	開発会社を選ぶとき
要件定義	要求を実現する範囲・機能・条件を決めて合意する	発注者と開発会社	契約後の最初の工程
基本設計（外部設計）	画面・帳票・他のシステムとの連携など、使う人から見える部分を決める	開発会社 （発注者が確認）	要件定義の後
仕様書	作るものの細かい仕様を書いた文書（呼び方と範囲は会社によって違う）	開発会社	設計の段階

要求はすべてが実現するとは限らない点が、要件との違いです。
要求として出した「こうしたい」は、要件定義の段階で予算・期間・技術の制約に照らして取捨選択され、残ったものが要件になる、という関係です。

「要件整理」という言葉は、要求を整理してまとめる意味で使われることが多く、指す範囲は会社によって少しずつ異なります。

要件定義と基本設計は、決める対象が違います。
要件定義が「何を作るか」を決めるのに対し、基本設計は、要件をもとに画面の配置や見た目、帳票の形、他のシステムとのつなぎ方など「使う人にどう見せるか」を決めます。
基本設計のあとには、システムの内部の仕組みを決める詳細設計が続く流れです。

なお、RFPの作り方や依頼先の選び方は、システム開発の依頼の進め方で紹介しています。

依頼前に、発注者はどこまで準備すればいい？

開発を依頼する前に、要件定義書まで作り切る必要はありません。
依頼前に発注者がまとめるのは要求（目的・使う人・必要な機能・予算と納期）で、要件定義そのものは開発会社と一緒に進めます。
ただし、何を解決したいかを決めるのは発注者。IPAのガイドの紹介ページも、要件を定義する責任はシステムを使う側にあると言われていることを紹介しています（出典：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」）。
以下で、まとめること、要件定義書の分担、詳しくなくても関われるかを順に見ていきましょう。

依頼前にまとめるのは、目的・使う人・必要な機能・予算と納期

依頼の前に発注者がまとめておくのは、目的、使う人、必要な機能、予算と納期の4つです。

• 目的：なぜ作るか、今の業務の何に困っているか、導入後にどうなっていれば成功か
• 使う人：誰がどんな役割で使うか、いちばんよく行う操作の流れ
• 必要な機能：これがないと意味がない機能と、あれば良い機能の区別
• 予算と納期：予算の上限、使い始めたい時期、その期限を動かせるか

書き出すときは、5W1H（誰が・何を・いつ・どこで・なぜ・どのように）の観点で考えると抜けにくくなります。
分かる範囲で、次のことも添えておくと、話が具体的になるはずです。

• 必要な画面
• 使う端末（パソコン・スマホ）
• 同時に使う人数
• 個人情報を扱うか
• システムが止まったときやデータが消えたときに、どこまで許容できるか

これらは空欄のままでも依頼でき、開発会社と一緒に決めれば問題ありません。
完璧な文書である必要はなく、箇条書きのメモや、今使っている帳票・Excelの実物で十分に伝わります。

要件定義書は、開発会社と一緒に作ればよい

要件定義書は、発注者が出した要求をもとに開発会社が書き起こし、発注者が確認して承認するかたちで作るのが一般的です。
主な分担は次のとおり。

• 発注者：目的と業務の説明、優先順位の判断、内容の承認
• 開発会社：実現方法の提案、要件の書き起こし、抜けている条件（非機能要件など）の指摘

業務システムではなく新規事業のアプリですが、当社が開発を担当した株式会社フェイバリット様の「ふぇいばりっとクリエイターズ」（ファンとクリエイターがつながるモバイルアプリ）の例を紹介します。
同社はインタビューで「仕様や要件定義を自社だけで詰めることが難しい状況でした」と振り返りつつ、要件定義の段階から深く関わってもらえた点を挙げています。
事例ページによると、依頼前に要件をある程度固めていたため要件定義は円滑に進み、期間は2週間でした。依頼前に要求をまとめておくほど、一緒に進める要件定義は進みやすくなります。

開発に詳しくなくても、業務を知る人が関われば進められる

要件定義で発注者に求められるのは、開発の知識ではなく、自社の業務の知識と、何を優先するかを決める判断です。
開発のスキルがなくても、専門用語の意味や実現の方法は、開発会社が説明し、提案します。

発注側の体制は、最初に決めておきましょう。必要なのは、取りまとめ役の担当者、実際の作業と例外を説明できる現場の担当者、予算と範囲を決める社長などの決裁者です。
IPAのガイドの紹介ページも、ITベンダやシステム部門が中心の進め方から、業務部門のユーザーが主体的に関与するスタイルへの変革の必要性が増しているとしています（出典：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」）。

打ち合わせで心がけたいのは、次の3つ。

• 分からない言葉は、その場で聞く
• 「全部ほしい」ではなく、優先順位で答える
• 今の業務の不満だけでなく、理想の姿も伝える

要件定義はどう進める？開発会社と決める3つの段階

要件定義は、ヒアリング、業務の流れの整理と範囲の決定、機能の優先順位付けの3つの段階で進み、最後に要件定義書にまとめて合意します。

1. ヒアリング：今の業務の流れと困りごとを伝える
2. 業務の流れの整理と範囲の決定：どの作業をシステムで行うかを決める
3. 機能の優先順位付け：作る機能と作らない機能を決める

段階の分け方や呼び方は開発会社によって異なり、打ち合わせは段階ごとに複数回行うのが一般的です。
要件定義書の中身と確かめ方は、次の章で紹介します。

ヒアリングで、今の業務の流れと困りごとを伝える

最初の段階では、開発会社が発注者と現場の担当者から、今の業務の流れと困りごと、実現したいことを聞き取ります。
この場に発注者が用意しておくとよいのは、次のような材料です。

• 依頼前にまとめたメモ
• 今使っている帳票・Excel・画面の実物
• 業務の量（1日・1か月あたりの処理件数）
• 使う人の人数と、使う場所

現場の担当者に同席してもらうと、手順の抜けや例外的な処理が早い段階で出てきます。
開発会社からの質問には分かる範囲で答え、分からない点は社内で確かめてから答えれば十分です。

業務の流れを図にして、システムで扱う範囲を決める

聞き取った内容をもとに業務の流れを図にして、どの作業をシステムで行い、どの作業を人の手に残すかを決めます。
この図は業務フローと呼ばれ、誰が・どの順で・何を使って作業するかを、箱と矢印で表したものです。システムで扱う範囲は、スコープとも呼ばれます。

範囲は「やること」と「やらないこと」の両方を書き出すのが基本。
やらないことを決めておけば、後になって「入っていると思っていた」という食い違いを防げます。
また、業務の流れを図にすると、作る前に業務そのものを見直したほうがよい箇所が見つかることも少なくありません。

要望に優先順位を付け、作る機能と作らない機能を決める

出てきた要望は、なくてはならないもの、あれば良いもの、今回は作らないものに分け、予算と期間に収まる範囲で作る機能を決めます。
決めた機能を、名前と内容の一覧にまとめたものが機能一覧です。

すべての要望を最初に入れようとすると、費用と期間が膨らみ、現場で使わない機能も増えやすくなります。
あれば良い機能は、使い始めてから次の段階で足すという分け方も一案です。
優先順位を決めるのは発注者で、各機能が費用と期間にどう影響するかを示すのが開発会社の役割。

要件定義書には何が書かれる？受け取ったら確かめること

要件定義書は、要件定義で合意した内容をまとめた文書で、発注者は承認する前に、業務が回るか、あいまいな点がないかを確かめます。
要件定義書に書かれていないことは、設計・開発・テストの対象にならないのが原則。承認は「この内容で作る」という合意になるため、主な項目と確かめ方を知っておくと安心です。

要件定義書には、目的・業務・機能・機能以外の条件・範囲がまとまる

要件定義書には、目的と背景、業務の流れ、機能、機能以外の条件、作る範囲、スケジュールと体制がまとめられます。
目次の構成や項目の名前は開発会社によって異なりますが、おおむね次の6つが入るのが一般的です。発注者が見ておきたいところとあわせて紹介します。

項目	書かれること	発注者が見るところ
目的と背景	・なぜ作るか ・解決したい課題	依頼前に伝えた目的と合っているか
業務要件	新しい業務の流れ（業務フロー）	いつもの業務が流れに入っているか
機能要件	・機能一覧 ・画面と帳票の一覧 ・他のシステムとの連携	必要な画面と帳票がそろっているか
非機能要件	速さ・安全性・利用人数など	あいまいな言葉になっていないか
範囲	・やること ・やらないこと	やらないことに、必要なものが入っていないか
スケジュール・体制・前提条件	・期間 ・担当 ・発注側の役割	発注側が用意するものと期限が書かれているか

実際の業務の手順で読み、例外の処理まで回るかを確かめる

要件定義書は、項目を順に読むよりも、いつもの業務の手順を追いながら、その作業がどの機能で行えるかを確かめると、抜けに気づきやすくなります。

現場の担当者にもレビューしてもらい、次の点が書かれているかを確認しましょう。

• 例外的な処理（取消・差し戻し・締めた後の修正など）
• 権限（誰が見られて、誰が直せるか）
• 今のデータを移す範囲

画面の流れ（画面遷移）が示されている場合は、使う部門が確認するとよいと、IPA「共通フレーム2013」のガイダンスにも書かれています（出典：IPA「共通フレーム2013 第3部 共通フレームとガイダンス」）。
分からない言葉が残っている場合は、承認する前に開発会社へ説明を求めることが大切です。

「速く」「使いやすく」のようなあいまいな言葉を残さない

「速く」「使いやすく」のような言葉は人によって受け取り方が違うため、要件定義書では数字や基準に直してもらうことが欠かせません。
「十分なセキュリティ」も同じで、何をどこまで守るのかが書かれていなければ、思い描く水準がずれてしまいます。たとえば、次の問いに答えられる形になっているかを確かめましょう。

• 画面の表示は何秒以内か
• 同時に何人が使うか
• 止まったときに何時間で戻すか
• データを何年保管するか

非機能要件の項目と水準を整理したIPAの「非機能要求グレード」は、非機能要件の定義の漏れを防ぐための指針として公開されています（出典：IPA「非機能要求グレード2018 利用ガイド［活用編］と経営層向け読本を改訂」）。
すべての項目を発注者が決める必要はなく、開発会社に案を出してもらい、業務に照らして判断すれば十分です。

要件を決めきれないとき、今のシステムを置き換えるときは？

要件を最初にすべて決めきれない業務は一部で試しながら段階的に固め、今のシステムを置き換えるときは、今のシステムが行っている処理を書き出してから要件を決めます。
当社も、一気に要件を固めるのではなく、業務改善を段階に分けたロードマップ（段階ごとの計画）を共有してから進める方針です（出典：EPICs DX・業務システム開発支援）。

使ってみないと決まらない業務は、一部で試してから要件を固める

現場で使ってみないと細かい要望が決まらない業務は、対象を一部の業務に絞って先に作り、使い勝手を確かめてから残りの要件を固めます。
当社の進め方でも、一部業務のパイロット（試験導入）で現場の効果と使い勝手を確かめ、そのあとに「拡げる・作り直す・止める」を判断する流れです（出典：EPICs DX・業務システム開発支援）。

小さな範囲で作って確かめることを繰り返す進め方（アジャイル開発）でも、要件定義で最初に目的・全体の範囲・優先順位を決め、細かな仕様は作りながら決めていきます。
最初にすべてを決めてから順に作る進め方（ウォーターフォール開発）との違いは、細かな仕様を決めるタイミングです。

一部で試す進め方では、試す段階の分だけ全体の期間が延びることがあり、発注側も短い間隔で確認と判断を続けなければなりません。

置き換えでは「今と同じ」で済ませず、今の処理を書き出す

サポート終了や担当者の退職で、今のシステムやExcelのマクロ（Excelの操作を自動で行う仕組み）を置き換えるときは、「今と同じ機能で」と頼まず、今のシステムが行っている処理を書き出してから要件を決めます。
今の仕組みには、画面に見えない自動の計算、入力のチェック、他のシステムとのデータの受け渡し、帳票の細かい書式など、書類に残っていない処理が含まれていることも珍しくありません。「今と同じ」では伝わらず、抜けやすい部分です。

書き出すときの進め方は、次のとおり。

• 今の画面と帳票を1つずつ確かめる
• 使っている人に、1日の操作を見せてもらう
• 移すデータの範囲と期間を決める
• 今の不便を直すか、そのまま移すかを分けて決める

期限がある場合は、まず今の業務を止めないための機能を優先し、改善したい点は次の段階に回す分け方も現実的です。
置き換え全体の進め方は、システムリプレイスの進め方で解説しています。

要件定義の費用と期間はどれくらい？

要件定義にかかる期間は開発全体の約2割、作業量は約15%が一つの目安です（出典：JUAS「ソフトウェア・メトリクス調査2025【ガイドブック】」）。
実際の期間は、発注側の確認と決定の速さで変わります。また、要件定義の前の業務の整理（業務診断）や、要件定義だけから頼む方法もあるので、あわせて見ていきましょう。

期間は開発全体の約2割、作業量は約15%が目安

JUASの調査では、要件定義が占める割合は、期間で開発全体の約2割、作業量で約15%です。
JUAS（日本情報システム・ユーザー協会）が2025年4月10日に公開したガイドブックの、工程別の比率を示した図表の値です（出典：JUAS「ソフトウェア・メトリクス調査2025【ガイドブック】」図表-2-2-1）。
工数は、1人が1か月で行う作業量を1とする「人月」などで表す作業量のこと。

JUASのガイドブックは、期間の割合が大きい理由を、要件定義が作業を分担して進めることに向かないためと考察しています。
見積書で要件定義の費用や期間を見るときに、全体に占める割合の目安として使える数字です。

ただし、JUASの調査は情報システムの開発・保守に取り組んできた企業へのアンケートをもとにしており、500人月以上の大規模な案件も含みます。
中小企業の小規模な案件に、そのまま当てはまるとは限りません。

期間を左右するのは、発注側の確認と決定の速さ

要件定義の期間は、システムの規模だけでなく、発注側が質問に答えて優先順位を決め、承認するまでの速さで大きく変わります。
期間が延びやすいのは、関係する部署が多く意見がまとまらない、決める人が打ち合わせに出ない、現場の担当者の時間が取れない、といった場面です。

発注側でできることは、次の3つ。

• 決める人と、質問への回答の期限を最初に決める
• 現場の担当者が打ち合わせに出る時間を確保する
• 工程表に、要件定義の期間と発注側の確認の期間が入っているかを確かめる

要件定義の前の業務診断から頼むこともできる

要件定義は、開発とまとめて頼むだけでなく、要件定義だけ、またはその前の業務の整理から開発会社に頼むこともできます。
要件定義だけを先に頼めば、その結果をもとに出す開発の見積もりの精度が上がるのが利点。
契約の前に、要件定義書などの成果物を引き渡してもらえるか、その後の開発をほかの会社に頼む場合も使えるかを確かめておきましょう。

当社の場合、業務診断（現状の業務把握、SaaSの活用も含めた手法選定、段階導入計画の策定）は30万円〜です。SaaSとは、インターネット経由で使う既製のソフトウェアのこと。
本開発を依頼する場合は、診断の費用を開発費に全額充当しています（出典：EPICs DX・業務システム開発支援）。

業務システムの要件定義から相談するならEPICs

当社EPICsは、業務の整理から要件定義、開発、現場への定着まで、この記事で紹介した進め方を1社で支援する業務システムの受託開発会社です。
業務診断から始め、SaaSで足りるか、一部の改修で済むかも含めて中立に提案し、診断だけ・開発だけのご依頼にも対応します。

一気に要件を固めず、段階に分けたロードマップを共有して進めるため、一部業務のパイロット後に「拡げる・作り直す・止める」を判断できます。
開発手法はノーコード（プログラムを書かずに作る手法）・AI駆動開発（AIを使う開発手法）・スクラッチ（一から作る手法）を業務領域ごとに使い分けます。
ドキュメントの整備とコード・データの所有権のお渡しで、移管しやすい状態を保ちます。

費用の目安は、業務診断が30万円〜（本開発を依頼する場合は全額充当）、一部業務のパイロット開発が50万円〜、小規模なシステム（〜15画面・〜1,000人想定）が期間1ヶ月〜・費用80万円〜。開発実績は250件以上です。
まずは今の業務で困っていることと、システムで実現したいことを書き出し、どこから手を付けるかを専門家と一緒に決めることから始めてみてください。

出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス

なぜ要件定義は、発注者が主体になると言われるのですか？

何を解決したいか、業務が実際にどう動いているかを知っているのは、発注者だけだからです。開発会社は実現の方法を提案できますが、どの業務を優先するかまでは決められません。IPAの「ユーザのための要件定義ガイド 第2版」の紹介ページでも、要件を定義する責任はシステムを使う側にあると言われていることが紹介されています。主体になるとは、一人で要件定義書を書くことではなく、業務を説明し、優先順位を決め、内容を承認することです。要件の書き起こしや、抜けている条件の指摘は、開発会社と分担して進められます。

要件定義では、画面のデザインまで決めますか？

一般に、画面のデザインまでは決めません。要件定義で決めるのは、必要な画面と帳票の一覧と、各画面で何を入力し何を表示するかまでです。色や配置などの見た目は、要件をもとに使う人から見える部分を決める基本設計以降の工程で決めます。ただし、要件定義書に書かれていないことは、設計・開発の対象にならないのが原則です。業務に必要な画面と帳票が一覧に入っているか、各画面で扱う項目に抜けがないかを、承認する前に確かめておきましょう。

要件定義のあとで要望が変わったら、どうなりますか？

要望を変えることはできますが、費用と期間に影響します。後の工程に進むほど、決めたことを変えるときに作り直す範囲が広がるためです。変えたいときは、まず開発会社に費用と期間への影響を示してもらいましょう。内容を確かめて承認してから進めれば、後の食い違いを防ぎやすくなります。また、現場で使ってみないと細かい要望が決まらない業務は、対象を一部の業務に絞って先に作り、使い勝手を確かめてから残りの要件を固める進め方も一つの選択肢です。

要件定義書は、開発が終わった後も使いますか？

使います。要件定義書に書かれた内容が、受け入れテスト（発注者が実際の業務で使えるかを確かめるテスト）で確かめる基準になるからです。公開後に改修や追加開発をするときも、今のシステムがどんな仕様で作られているかを確かめる資料として役立ちます。そのため、要件定義書は開発会社だけでなく、発注者の手元にも残しておくことが大切です。EPICsでは、ドキュメントを整備し、コードとデータの所有権をお渡しして、移管しやすい状態を保っています。