開発会社から届いた見積書を開くと、開発費とは別に「要件定義」の行があり、この金額が妥当なのか判断できずに困ることがあります。要件定義は画面もプログラムも生まれない工程なので、何にお金を払っているのかが見えにくいのです。

しかし、要件定義の費用を削ったプロジェクトほど、開発の途中で仕様が揺れて総額が膨らむ傾向があります。費用の決まり方と中身を知っておけば、金額の妥当性を自分で確かめられます。この記事では、要件定義の費用の決まり方、内訳、変動要因、抑え方、発注時の確認点を解説します。

この記事を読むと理解できること

• 要件定義の費用が人月と単価でどう計算されるのか

• 要件定義の費用に含まれる作業と成果物

• 要件定義の費用が高くなる5つの要因

• 要件定義の費用を抑えてよい部分と削ってはいけない部分

• 要件定義に向いた契約形態と多段階契約の考え方

• 見積書で要件定義の費用を確認するポイント

要件定義の費用はどう決まるのか？人月と工程比率で見る仕組み

要件定義の費用は、基本的に「どれだけの人が、どれだけの期間関わるか」で決まります。システム開発の費用は人件費が大半を占めるため、要件定義も作業量を人月で見積もり、そこに単価を掛けて算出するのが一般的です。

人月と単価で計算する

人月とは、1人が1か月フルタイムで働く作業量を表す単位です。例えば、2人が2か月関わる要件定義であれば4人月となり、これに人月単価を掛けた金額が費用の目安になります。

人月単価は、担当者の役割や経験によって変わります。業務を整理して要件にまとめるコンサルタントやプロジェクトマネージャーは、プログラマーより単価が高く設定されることが多く、上流工程は単価の高い人が中心になります。

見積もりの出し方にも種類がある

開発会社が工数を出す方法には、主に二つの考え方があります。一つは、作業を細かく分解して一つずつ時間を積み上げる方法で、もう一つは、過去の似た案件の実績をもとに全体を推し量る方法です。

積み上げで出した見積もりは根拠を説明しやすい一方、情報が少ない段階では精度が上がりません。初回の打ち合わせ直後に出てくる金額は、推し量りで出された概算であることが多いため、幅のある数字として受け止め、情報を渡したあとに改めて見積もってもらうのが現実的です。

開発全体に対する比率で検算する

この金額が妥当かどうかは、開発全体の費用に対する比率でも確かめられます。システム開発の費用を解説する記事では、要件定義は全体の1〜2割程度とされることが多く、極端に小さい場合や大きい場合は理由を確認する価値があります。

比率が小さすぎる見積もりは、上流の検討を簡易的に済ませ、詳細は開発しながら決める前提になっていることがあります。その場合、仕様の追加や変更が後から費用として積み上がる可能性があります。

システム開発全体の費用相場や見積もりの内訳については、システム開発の費用相場で種類別に解説しています。

要件定義の費用には何が含まれるのか？作業内容と成果物の内訳

要件定義の費用に含まれるのは、現状の把握から要件の合意までの一連の作業です。見積書に「要件定義一式」とだけ書かれている場合は、次のどの作業が含まれているのかを確認しましょう。

成果物で費用の中身を確かめる

この工程の費用は、目に見える成果物と結びつけて確認すると判断しやすくなります。同じ金額でも、業務フローまで作るのか、機能一覧だけで終わるのかによって、後工程の進めやすさは大きく変わります。

見積もりを依頼するときは、工程の終わりにどの成果物がそろっている想定なのかを、あらかじめ開発会社に聞いておくと安心です。

画面や業務シナリオを含めるか

費用の差が出やすいのが、画面のイメージや利用シナリオを要件定義に含めるかどうかです。文章だけでまとめる方法は費用を抑えられますが、実際の画面を見たときに「思っていたものと違う」となり、開発中の手戻りにつながることがあります。

FAKEが業務システムの要件定義に関わる際は、デザインドリブン®の考え方で、現場の利用者が実際に操作する流れを画面のたたき台で確かめながら要件を固めます。要件定義の段階で利用者の行動を見える形にしておくと、後工程の仕様変更を減らせるためです。考え方の詳細はUX視点で考える要件定義の進め方をご覧ください。

要件定義の費用が高くなるのはどんなときか？変動する5つの要因

要件定義の費用は、関わる人数と期間を増やす要因によって変わります。主な要因は次の5つです。

発注者側の準備で費用は変わる

5つの要因のうち、発注者が最も動かしやすいのは準備状況です。業務フロー図や現在使っている帳票、Excel、過去の検討資料がそろっていれば、開発会社は現状調査の時間を短くできます。

逆に、目的が社内で固まっていない状態で要件定義を始めると、会議のたびに議論が振り出しに戻り、期間が延びていきます。費用を抑えたいなら、まず社内で「何のためのシステムか」を決めておくことが近道です。

範囲を広げすぎない

すべての部署の要望を一度に盛り込もうとすると、検討の範囲が広がり、費用も期間も増えます。最初のリリースでは中核となる業務に絞り、残りは次の段階で検討する進め方にすると、上流と後工程の費用の両方を抑えやすくなります。

納期の制約も金額を押し上げる

稼働開始の時期が先に決まっていて期間が短い場合も、費用は増えやすくなります。短い期間で同じ量の作業をこなすには、関わる人数を増やす必要があり、打ち合わせを並行して進めるための調整の手間も増えるためです。

期間に余裕がない場合は、範囲を絞るのか、人数を増やして費用を受け入れるのかを、早い段階で決めておくと見積もりの前提がぶれません。

要件定義の費用は削ってよいのか？抑えてよい部分と削ってはいけない部分

結論として、要件定義の費用は「準備で減らせる部分」は抑えてよい一方、「合意形成と検証」は削るべきではありません。要件定義は後工程のすべての前提になるため、ここを省くと開発中の手戻りとして跳ね返ってきます。

抑えてよい部分

抑えてよいのは、発注者側で代わりに用意できる作業です。現状業務の資料集め、関係者のスケジュール調整、社内アンケートによる要望収集などは、発注者が担えば開発会社の工数を減らせます。

また、要件定義の対象を初期リリースの範囲に限定することも有効です。将来の拡張については方向性だけを決めておき、詳細は次の段階で詰めれば、今回の費用は抑えられます。

削ってはいけない部分

削ってはいけないのは、利用者を交えたレビューと、決裁者を含めた合意形成です。ここを省くと、開発が進んでから現場の反対や決裁者の方針変更が起き、作り直しが発生します。

非機能要件の検討も削るべきではありません。性能やセキュリティ、運用の条件が曖昧なまま開発に入ると、稼働直前になって追加の対応が必要になり、上流で節約した金額を大きく上回る費用がかかることがあります。

費用と期間の判断に迷ったら

要件定義をどこまで外部に任せ、どこを社内で担うかの線引きは、プロジェクトの規模や社内の体制によって変わります。FAKEでは、業務システムの要件定義を現場に入り込んで一緒に進める支援を行っています。判断に迷う段階でも、範囲の切り分けからご相談いただけます。

社内の稼働も費用として見ておく

見積書には現れませんが、発注者側の社員の時間もこの工程のコストです。ヒアリングへの参加、資料の準備、レビューや決裁のための会議など、現場の担当者や管理職が想像以上に時間を使うことになります。

社内の稼働が確保できないと、開発会社は確認待ちの時間が増え、期間が延びて費用もかさみます。外部に払う金額だけでなく、社内の誰がどのくらいの時間を割くのかも、計画の段階で見積もっておきましょう。

要件定義の費用を適正にするにはどう発注するか？契約形態と見積もりの確認点

要件定義の費用を適正にするには、契約形態の選び方と見積書の読み方が重要です。特に、要件定義と開発を一括で契約するか、工程ごとに分けて契約するかで、費用の決まり方とリスクの所在が変わります。

要件定義は準委任が使われやすい

この工程は、始める時点で「何が完成すれば終わりか」を厳密に決めにくい工程です。そのため、成果物の完成を約束する請負ではなく、業務の遂行に対して報酬を払う準委任で契約されることが多くあります。

準委任の場合、費用は作業の量と期間に応じて決まるため、範囲が広がれば費用も増えます。契約時に対象範囲と想定期間、作業報告の方法を決めておくと、費用の膨らみを早めに把握できます。請負と準委任の違いは準委任と請負の違いで詳しく整理しています。

多段階契約で見積もりの精度を上げる

多段階契約とは、共通の条件を基本契約で定め、要件定義、設計、開発といった工程ごとに個別契約を結ぶ方式です。前の工程の結果を見てから次の工程の費用を決めるため、見積もりの精度を段階的に上げられます。

一方、最初に全工程を一括で契約すると、要件が固まっていない段階で総額を決めることになります。開発会社は不確実な部分のリスクを見積もりに上乗せしやすく、結果として発注者の負担が大きくなる場合があります。

支払い方と精算の単位を決める

準委任で契約する場合は、支払いの単位も確認しておきます。月ごとに稼働時間で精算する方法のほか、あらかじめ決めた成果物の納品に合わせて支払う方法もあり、どちらを選ぶかで発注者が管理すべきことが変わります。

稼働時間で精算する場合は、毎月の作業報告で何にどれだけ時間を使ったかを確認できるようにします。成果物に合わせて支払う場合は、何をもって完了とするかの基準を契約前にすり合わせておくと、検収の段階でもめずに済みます。

見積書で確認するポイント

要件定義の見積書では、次の点を確認しましょう。どの作業と成果物が含まれているか、誰が何人月関わる想定か、打ち合わせやレビューの回数はどのくらいか、範囲が増えた場合の追加費用の扱いはどうなるか、の4点です。

複数社から見積もりを取る場合は、同じ資料と同じ前提を渡すことが大切です。前提がそろっていないと、金額の差が作業範囲の差なのか単価の差なのかを判断できません。そのためにも、依頼内容は提案依頼書の形で文書にまとめ、全社に同じものを渡すようにしましょう。

業務システムの要件定義や画面設計まで任せられるパートナーを探している場合は、業務システム・DXに強いデザイン会社の比較も役立ちます。

まとめ

要件定義の費用は、関わる人数と期間から決まる人月に、単価を掛けて算出されるのが基本です。開発全体の1〜2割程度が一つの目安とされ、比率が極端な見積もりは前提を確認する価値があります。

費用の中身は、現状調査から合意形成までの作業と、その成果物で確かめられます。対象業務の範囲、関係者の数、連携の多さ、業務の標準化の度合い、発注者側の準備状況によって費用は変わり、特に準備状況は発注者が自ら改善できる要因です。

資料集めや範囲の絞り込みで費用を抑えるのは有効ですが、利用者を交えたレビューや合意形成、非機能要件の検討は削るべきではありません。要件定義は準委任や多段階契約と相性がよく、見積書では作業・成果物・人月・追加費用の扱いを確認しましょう。要件定義の進め方や範囲の切り分けに迷ったときは、FAKEにお気軽にご相談ください。

要件定義の費用に関するよくある質問

要件定義だけを別の会社に依頼することはできますか？

可能です。要件定義だけを先に依頼し、その成果物をもとに開発会社を選ぶ進め方もあります。ただし、要件定義書の粒度や書き方が開発会社にとって使いやすいかどうかで、後工程の進めやすさが変わります。成果物の形式や引き継ぎの方法を、契約時に決めておくと安心です。

要件定義の費用は無料にしてもらえることがありますか？

開発の受注を前提に、提案活動の一環として簡易的な要件整理を行う開発会社もあります。ただし、無料の範囲は限られることが多く、本格的な要件定義は有償になるのが一般的です。無料で進めた場合は、その成果物を他社の比較に使えるかどうかも確認しておきましょう。

要件定義にはどのくらいの期間がかかりますか？

対象業務の範囲や関係者の数によって大きく変わるため、一律の期間はありません。期間を見積もる際は、ヒアリングの対象部署の数、レビューの回数、決裁の手順を開発会社と一緒に洗い出すと、現実的な期間が見えてきます。

要件定義の費用が他社より高い見積もりは避けるべきですか？

金額だけで判断せず、含まれる作業と成果物を比べてください。画面のたたき台や業務フローの作成まで含む見積もりは、文章だけの要件定義より高くなりますが、後工程の手戻りを減らせる場合があります。何が含まれているかをそろえて比べることが大切です。

要件定義の途中で費用が増えることはありますか？

準委任で契約している場合、対象範囲が広がったり、会議が増えたりすると費用が増えることがあります。契約時に範囲と想定工数を決め、定期的に作業報告を受けることで、増加の兆しを早めに把握できます。範囲を広げるかどうかは、その都度発注者が判断できるようにしておきましょう。