要件定義の費用相場と外注の進め方 — 期間・契約・失敗しない発注の準備【中小企業向け】

要件定義とは、システムを作る前に「何のために、誰が、何をできるようにするのか」を整理し、開発会社と発注側が同じ完成イメージを持つための工程です。結論から言うと、要件定義を外注するときの費用は、市場でよく見られる目安として、小規模な案件で数十万〜100万円前後、中規模で100万〜数百万円、大規模では数百万円以上になり、開発費総額の1〜2割程度に収まることが多く見られます。契約は、完成を約束する請負ではなく、作業に対して支払う準委任契約が一般的です。

また、要件定義だけを別会社に頼む、あるいは開発とは別契約にする「分割発注」という選択肢もあります。要件定義書という成果物が手元に残るため、複数社から同じ条件で見積もりを取れるようになり、結果として開発費の適正化や、依頼先の選び直しがしやすくなります。本記事では、IT専門ではない経営者・担当者向けに、要件定義の費用相場、分割発注のメリットと注意点、準委任契約が多い理由、成果物の中身、期間の目安、発注側が準備することと社内の役割、よくある失敗、良いパートナーの見分け方、発注前チェックリストまでを整理します。記載する金額や期間は、いずれも市場でよく見られる大まかな目安であり、依頼先・案件の内容・体制によって大きく異なります。

システム開発は、大まかに「要件定義 → 設計 → 開発 → テスト → 導入・運用」と進みます。このうち要件定義は一番最初の「上流工程」にあたり、システムに求める条件（要件）を決めて文書にする作業です。要件には、大きく2種類があります。ひとつは「何ができるべきか」を表す機能要件（例：見積書をPDFで出力できる、在庫が一定数を下回ったら通知する）、もうひとつは「どのくらいの品質で動くべきか」を表す非機能要件（例：同時に何人まで使えるか、止まってよい時間はどのくらいか、セキュリティはどこまで求めるか）です。

要件定義が大切なのは、ここでの決め漏れや認識違いが、後ろの工程で何倍もの手戻りになって返ってくるからです。たとえば設計や開発に入ってから「実は承認フローが部署ごとに違った」と判明すると、画面もデータの持ち方も作り直しになります。一般に、問題の発見が後の工程になるほど修正の費用は膨らむと言われており、だからこそ、最初の工程にきちんと時間と費用をかける価値があります。なお、要件定義と似た言葉に「RFP（提案依頼書）」がありますが、RFPは開発会社に提案を依頼するための文書で、要件定義はその中身をより詳しく固める工程です。両者の関係はRFP・要件定義の基本で整理しています。

もうひとつ押さえておきたいのは、要件定義は「発注者が欲しいものを聞き取る作業」ではなく、「業務の課題を整理し、システムで解決すべき範囲を一緒に決める作業」だという点です。ヒアリングで出てきた要望をすべて並べるだけでは、費用が膨らむうえ、本当に必要なものが埋もれます。何を作り、何を作らないかを決めること自体が、要件定義の価値です。

要件定義の費用は、対象となる業務の広さ、関係する部署や外部システムの数、必要な打ち合わせの回数によって大きく変わります。以下は、国内の受託開発で市場でよく見られる大まかなレンジを、開発費の規模別にまとめたものです。特定の会社の価格や保証ではなく、データの整理状況や依頼先の規模によって、この範囲を外れることもあります。

割合で見ると、小規模な案件では開発費総額の1〜2割程度が一つの目安ですが、規模が大きくなるほど、開発費に対する要件定義の割合は小さくなる傾向があります。大きな案件ほど、要件定義の費用そのものは高くなっても、開発や運用の費用が桁違いに大きくなるためです。逆に言えば、数百万円規模の開発で要件定義が数十万円というのは、決して高くも安くもない水準です。開発費全体の考え方はシステム開発費用の相場ガイドも参考にしてください。

費用の算出方法は、多くの場合「人月（にんげつ）」または「人日（にんにち）」を単位とした積み上げです。要件定義を担当するコンサルタントやシステムエンジニアが、何人で何日かかるかに単価を掛けた金額になります。見積もりを受け取ったときは、総額だけでなく、誰がどのくらいの稼働で入るのか、打ち合わせは何回を想定しているのか、成果物は何かを確認してください。

同じ「要件定義」でも、見積もりが数倍違うことがあります。その主な理由は、次のような要因です。

- 対象業務の広さ：1つの業務か、受注から請求までの一連の流れか
- 関係者の数：打ち合わせに出る部署・担当者が多いほど、調整に時間がかかる
- 既存システムや外部サービスとの連携：連携先ごとに仕様確認が必要になる
- 現状の整理状況：業務の流れやルールが文書になっているか、担当者の頭の中にしかないか
- 非機能要件の厳しさ：個人情報や決済を扱う、止められない業務である、など
- 成果物の細かさ：画面イメージまで作るのか、機能一覧にとどめるのか
- 発注側の意思決定の速さ：確認や決裁が遅いと、期間が延び、費用も増えやすい

この中で、発注側の工夫で抑えやすいのは「現状の整理状況」と「意思決定の速さ」です。今の業務の流れを簡単な図やメモにしておく、使っている帳票や画面の例を集めておく、決裁者を打ち合わせに同席させる、といった準備をするだけで、要件定義の工数は目に見えて減ることがあります。この点は後半の「発注側が準備すること」で詳しく取り上げます。

通常、システム開発は要件定義から納品まで同じ会社に一括で頼むことが多いですが、要件定義だけを別契約にして先に依頼する方法があります。これを分割発注（工程分割での発注）と呼びます。たとえば「まず要件定義を専門の会社や、開発とは別のチームに依頼し、できあがった要件定義書をもとに、複数の開発会社に見積もりを依頼する」という進め方です。

分割発注の最大のメリットは、「要件定義書」という自社の資産が手元に残ることです。要件が文書として固まっていれば、複数社に同じ条件で見積もりを依頼でき、金額や提案内容を比べやすくなります。また、要件定義の段階で「やはりこの予算では難しい」と気づいた場合に、開発に進む前に範囲を見直せる、という安全弁にもなります。

一方、注意点もあります。まず、要件定義の費用が別途かかるため、小規模な案件ではかえって割高になる場合があります。次に、要件定義書の品質が低いと、開発会社が内容を読み取れず、結局やり取りをやり直すことになります。さらに、要件定義の担当会社と開発会社が違うと、「技術的に実現しにくい要件」が仕様に入ったままになり、開発側から後で指摘されるケースもあります。これを避けるには、要件定義の担当者に、開発の実現性を判断できる技術的な知見があること、そして要件定義書の著作権や利用権が発注側に残る契約になっていることを確認してください。

目安として、開発費が数百万円規模で仕様が明確ならば、一括発注のほうが手間もコストも抑えられることが多いです。一方、数千万円規模である、関係部署が多く社内でも意見が割れている、そもそも相場がつかめない、といった場合は、分割発注を検討する価値があります。アジャイル開発のように、要件を固めすぎずに進める方式を選ぶ場合は、要件定義の位置づけも変わります。詳しくはアジャイル開発の発注ガイドで整理しています。

要件定義の契約は、「準委任契約」で結ぶことが一般的です。準委任契約とは、成果物の完成ではなく、専門家としての業務の遂行そのものに対して費用を支払う契約です。これに対し、請負契約は、完成した成果物を納めることを約束し、完成しなければ報酬が発生しない（または減る）契約です。

要件定義が準委任になりやすい理由は、要件定義の「完成」が客観的に決めにくいからです。システムの設計や開発であれば、仕様書どおりに動くかどうかで完成を判断できます。しかし要件定義は、ヒアリングを重ねる中で新しい論点が出てきたり、発注側の判断で内容が変わったりします。「どの時点で要件が全部出きったと言えるか」を事前に決めることは難しく、請負にすると、受託側は想定外の変更に備えて見積もりを高くせざるを得ません。作業の進め方と期間で費用を決める準委任のほうが、双方にとって現実的なのです。

準委任は、発注側から見ると「完成の保証がない」ことが不安に映るかもしれません。ここで効いてくるのが、契約書や作業計画の中で、プロセスと成果物をできるだけ具体的に決めておくことです。たとえば、打ち合わせの回数と頻度、報告の方法、最終成果物（要件定義書）に含める章立て、受け入れの確認方法、期間の上限と延長するときの合意方法などです。準委任でも、これらを文書にしておけば、発注側のコントロールは十分に効きます。契約全般の考え方は開発契約の基本で解説しています。

期間は、規模のほか、発注側の関係者の調整にどれだけ時間がかかるかで決まります。小規模な案件であれば2〜6週間、中規模で1〜3か月、大規模では3〜6か月以上が、市場でよく見られる目安です。長くなりすぎると、検討しているうちに業務や市場が変わってしまうので、数か月を超える場合は、フェーズを分けて段階的に決める方法も検討します。進め方の大まかな流れは次のとおりです。

1. 現状把握：今の業務の流れ、使っている帳票・システム、困りごとを整理する
2. 課題の整理と目的の確認：何を解決したいのか、なぜ今やるのかを言葉にする
3. 要望の洗い出し：関係部署から要望を集め、機能・データ・画面の候補を出す
4. 優先順位づけと範囲の決定：必須・あれば良い・今回はやらない、に分ける
5. 要件の文書化：機能要件・非機能要件・制約条件を要件定義書にまとめる
6. レビューと合意：関係者で内容を確認し、決裁者が承認する
7. 概算見積もりと計画の確認：要件をもとに開発費・期間・体制の見込みを確認する

重要なのは、手順5〜6の間にいきなり完成版を目指さず、早めに素案を共有して、何度かやり取りを重ねることです。最初から分厚い文書を待つよりも、機能一覧や業務フローの下書きを段階的に見せてもらうほうが、認識のずれに早く気づけます。

要件定義の成果物は「要件定義書」と呼ばれる文書です。形式は会社によって異なりますが、中小企業の案件で最低限そろっていてほしい内容は、次のとおりです。発注後に「何が納品されるのか分からない」とならないよう、見積もりの段階で、どこまでの文書が成果物に含まれるのかを確認してください。

文書の分量が多ければ良いわけではありません。大事なのは、読んだ人によって解釈が分かれない書き方になっているかどうかです。たとえば「使いやすい画面にする」「素早く動作する」といった表現は、人によって基準が違います。「注文入力が1件3分以内で終わる」「検索結果が3秒以内に出る」のように、確認できる形で書かれているか、という視点でチェックしてください。

あわせて、成果物の権利についても確認しておきます。要件定義書の著作権や利用権が誰にあるか、他の開発会社に渡して見積もりを取ってもよいか、が曖昧だと、分割発注の利点が活かせません。契約書の段階で、要件定義書は発注側が自由に利用できると明記しておくのが安全です。

要件定義の質は、外部の専門家の腕だけでなく、発注側の準備で大きく変わります。専門家は業務のことをよく知りません。発注側から必要な材料が出てこなければ、ヒアリングが長引き、費用も期間も増えます。要件定義の依頼前に、次のようなことを準備しておくと、スムーズです。

- 目的と課題を一文で書く：「何を、どれだけ、いつまでに改善したいのか」を、できれば数字で整理する
- 現状の業務の流れをメモにする：きれいな図でなくてよいので、誰が何をしているかを書き出す
- 実際に使っている帳票・Excel・画面を集める：サンプルは、言葉の説明よりずっと伝わる
- 困りごとと要望を、関係者から事前に集める：後から出る要望は、費用が増える原因になる
- 予算の上限と希望の時期を決める：決まっていないと、現実的な範囲の提案が出にくい
- 既存システムや契約サービスの一覧を用意する：連携や移行の検討に必要
- 決裁者と、打ち合わせの窓口を決める：誰が最終判断をするのかを最初に明確にする

完璧に準備する必要はありません。むしろ、「ここまでは決まっているが、ここから先は決まっていない」という状態を、そのまま正直に伝えることが大切です。決まっていない部分を隠したり、あいまいなまま進めたりすると、後で追加費用や手戻りの原因になります。

要件定義は、外注しても「丸投げ」はできません。業務の中身を一番よく知っているのは発注側であり、その知識を引き出して、最終的に判断するのも発注側だからです。開発会社の役割は、聞き出し、整理し、文書にし、実現方法を提案することであって、御社の事業にとって何が正しいかを決めることではありません。

- 責任者（決裁者）：目的と予算を決め、範囲や優先順位の最終判断をする。打ち合わせの要所に同席する
- 窓口担当者（プロジェクト担当）：外部との連絡を一本化し、社内の意見をまとめ、期限内に回答する。週に数時間〜数日の稼働を見込む
- 現場の担当者：業務の実態を説明し、画面や帳票の案をレビューする。実際に使う人の声を反映する
- 情報システム担当（いる場合）：既存システムやセキュリティの条件を確認する。いない場合は、窓口担当者が兼ねる
- 経理・総務など関係部署：請求、承認、権限管理といった周辺のルールを確認する

とくに重要なのは、窓口担当者の確保です。要件定義の期間中は、週に数回の打ち合わせや、資料の確認、社内への確認が発生します。他の業務と兼務で、ほとんど時間が割けない状態だと、期間が延び、結局は費用も増えてしまいます。担当者を決めるときは、普段の業務の一部を他の人に分担するなど、時間を空ける調整も含めて検討してください。社内に専任の担当者を置くのが難しい場合は、外部のITコンサルタントに窓口を補助してもらう方法もあります。

この中でも、とくに多いのが「要望の羅列で終わる」ことです。ヒアリングの場では、現場から「あれもできたら便利」「これも欲しい」と意見が次々に出ます。それをすべて取り込むと、予算も期間も際限なく増えます。要件定義の腕の見せどころは、出てきた要望を、目的に照らして仕分けることにあります。「今回の第1弾で必要か」「第2弾以降でもよいか」「そもそもシステムで解決すべきことか」の3つの観点で整理してもらってください。

システム開発全体で起きやすい失敗は、システム開発の失敗パターンも参考になります。また、技術面の不確かさが大きい案件では、要件定義と並行して、小さく試して確かめるPoC（概念実証）を行う方法もあります。詳しくはPoCの費用と進め方をご覧ください。

要件定義を任せる相手は、会社の規模や知名度ではなく、進め方で見分けるのが確実です。見積もりや最初の打ち合わせで、次のような点を確認してみてください。

- 「何を作りたいか」の前に、「なぜ作りたいか」「今どう困っているか」を聞いてくる
- 要望をそのまま受け入れず、優先順位づけや「やらない」という判断も提案してくれる
- 専門用語を使わず、発注側が理解できる言葉で説明してくれる
- 成果物（要件定義書）の見本や、目次の例を見せてくれる
- 見積もりの内訳（誰が・何日・どの作業か）が説明でき、前提条件が書かれている
- 技術的に難しい点、リスクのある点を最初に伝えてくれる
- 要件定義書の権利が発注側にあり、他社に渡して見積もりを取ってよいと明言してくれる
- 契約外の追加作業が発生する条件や、その費用の考え方を事前に説明してくれる
- 業務への理解が深く、同じ業種や規模の企業での経験がある

逆に注意したいのは、「要件定義は無料で、開発をお任せいただければ」と言って、要件がはっきりしないまま開発の見積もりを出す会社や、見積もりの根拠を説明しない会社です。無料や格安の要件定義が一概に悪いわけではありませんが、その分が開発費に上乗せされていないか、他社へ移れなくなる条件が付いていないかは確認しておきましょう。複数社を比較するときの考え方は、RFP・要件定義の基本でも触れています。

要件定義を依頼する前に、次の項目を確認してください。すべてに「はい」と答えられなくても構いませんが、答えられない項目は、後で問題になりやすい部分です。

- システムで解決したい課題と目的を、一文で説明できる
- 今の業務の流れを、メモやサンプル帳票で示せる
- 予算の上限と、希望する時期を決めている
- 要件定義を一括で頼むか、分割して頼むかを検討した
- 契約形態（準委任か請負か）と、費用の決まり方を理解している
- 成果物（要件定義書）に含まれる内容と、受け入れの方法を確認している
- 要件定義書の権利が発注側にあることを、契約書で確認している
- 決裁者と窓口担当者が決まっており、打ち合わせの時間を確保できる
- 現場の担当者がレビューに参加できる体制がある
- 期間の上限と、延長が必要になったときの取り決めを確認している
- 「今回はやらないこと」を決める覚悟がある