要件定義の費用はどう決まる？見積もりの読み方と増減の要因

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義の費用はどう決まる？「人数×期間」で見積もられる

要件定義（RD：Requirements Definition）は、システムで何を実現するかを決めて、発注側と開発側で合意する工程です。

ここでは開発側の担当者が、話を聞き、業務の流れを描き、要件定義書にまとめる作業をします。

『まだ何も作っていないのに、費用がかかるの？』と思う方も多いですよね。

ただ、要件定義は人が時間をかけて行う仕事なので、作る工程と同じように費用がかかるのが一般的なんです。

要件定義そのものの意味は、要件定義とは？意味をわかりやすく解説で確かめられます。

見積もりの中身はどうなっている？

要件定義の見積もりは、おおまかに次のような要素から組み立てられます。

この5つがそろっている見積もりなら、他の会社の見積もりとも比べやすくなります。

相場の金額を書かない理由

要件定義の費用について、公的な相場のデータは見当たりません。

金額は、案件の規模や条件、頼む会社の体制によって変わるからです。

要件定義の費用が増える要因・減らせる要因

見積もりを見て『思ったより高い…』と感じた時は、どの要因が費用を押し上げているかを見てみましょう。

表の上の4つは、案件そのものの性質なので、大きく変えるのは難しいこともあります。

一方で、下の2つは発注側の準備しだいで変えられる部分なんです。

今のシステムがある場合は、調べる作業が加わる

今のシステムを入れ替える場合、要件定義の前に「今のシステムが何をしているか」を調べる作業が加わります。

設計書が古い、作った人がいない、という状態だと、調べる時間がそのぶん増えますよね。

入れ替えの時に何を調べるかは、システム移行・リプレースの要件定義で詳しく扱っています。

非機能要件の厳しさも、費用に関わる

止まらないこと、速さ、守りの固さなどの非機能要件は、厳しくするほど決めることが増えます。

IPAの非機能要求グレードでは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目について、レベルを0〜5の段階で選びます。

『全部いちばん高いレベルにしておけば安心』と考えたくなりますよね。

ただ、高いレベルを選ぶほど、要件定義でも設計でも検討することが増えます。業務への影響から、項目ごとに必要な水準を選ぶのが、費用を抑えるコツなんです。

発注側の準備で減らせること

開発側が要件定義の時間の多くを使うのは、話を聞いて、まとめて、確かめる作業です。

発注側が先に材料をそろえておけば、そのぶん聞き取りの時間が短くなり、費用を抑えやすくなります。

『資料を作る時間なんてない…』という方もいるはずです。

その場合でも、上の一つ目と二つ目だけは書いておくのがおすすめです。何を決めるかの範囲がはっきりするだけで、見積もりの幅がぐっと狭まります。

見積もりの読み方：内訳の3点で比べる

要件定義の見積もりを複数の会社から取ると、合計の金額だけが目に入りがちですよね。

ただ、合計だけで比べると、「安いと思ったら成果物が少なかった」ということが起きます。

ここでは架空の題材として、「社内の文書の申請と承認を、紙からシステムに切り替える場合」に、2社の見積もりを並べてみます。

合計の金額だけ見るとイ社のほうが抑えめだったとしても、成果物の量と前提条件がかなり違います。

イ社に頼む場合は、業務フロー図や課題一覧を誰が作るのか、前提条件は何かを質問してから判断するのがよさそうです。

見積もりを比べる時の手順

同じメモを渡すのがポイントです。

会社ごとに伝える内容が違うと、見積もりの前提がずれて、比べられなくなってしまいます。

見積もりの前に渡すメモの記入例

各社に渡すメモは、立派な資料でなくて大丈夫です。

文書の申請と承認の例なら、次のくらいの粒度で書いておけば、見積もりの前提がそろいます。

『こんなに書かないといけないの？』と思うかもしれません。

ただ、表の多くは社内で一度は話している内容のはずです。分からない行は「未定」と書いて渡しても、見積もりの段階で質問してもらえます。

見積もりについて聞く時の会話例

内訳を聞く時は、こんなふうに聞いてみてください。

「この期間には、部署ごとの聞き取りの会議も入っていますか？」と発注側が聞きます。

「入っていません。全体の会議で決める前提なので、部署ごとに聞く場合は追加になります」と開発側が答えます。

このやり取りがあるだけで、後から費用が増える場面を一つ防げます。

要件定義だけ分けて頼む、という契約の形

受託の開発では、要件定義を「準委任契約」、設計以降を「請負契約」と分けて契約する例があります。

準委任契約は、決められた作業を行うことへの契約で、成果物の完成までを約束するものではありません。

請負契約は、決められたものを完成させて渡すことへの契約です。

どちらの形がよいかは、案件の規模や会社の方針で変わります。

契約の形を決める時は、社内の担当部署とも相談しながら進めてみてください。

契約の前に確かめておきたいこと

要件定義を分けて頼む場合も、まとめて頼む場合も、契約の前に確かめておくと安心なことがあります。

特に最後の点は、要件定義の後に頼む先を考え直す可能性がある時に大事です。

「要件定義書を、設計以降の見積もりを取る時に他社へ見せてもいいですか？」と、発注側から先に聞いておきましょう。

要件定義の進め方を知っておくと、見積もりが読みやすい

見積もりの期間に何が含まれているかは、要件定義の進め方を知っていると読みやすくなります。

聞き取り、業務の流れの整理、要件の一覧化、確認と承認、という一連の流れは、要件定義の進め方・手順で紹介しています。

要件定義の費用を削りすぎると何が起きる？

『要件定義は早めに切り上げて、早く作り始めたい』と思うこともありますよね。

気持ちは自然ですが、要件定義を短くしすぎた時に起きやすいことも知っておきましょう。

後の工程で見つかった食い違いほど、直す範囲が広くなります。

要件定義の費用は、後の手戻りを防ぐための費用でもある、と考えておくと判断しやすくなります。

例えば文書の申請と承認の例で、承認者が不在の時の扱いを決めずに進んだとします。

「承認者が休みの日は、誰が代わりに承認するんですか？」とテストの段階で利用部門から聞かれます。

「その場合の流れは、要件にありませんでした」と開発側が答えることになり、画面も処理も作り直しになります。

この一つの質問を、要件定義の会議で先に出せていれば、作り直しは起きなかったはずですよね。

要件定義で例外の業務まで聞いておくことは、遠回りに見えて、全体の費用を抑える近道にもなるんです。

費用を抑えたい時の現実的な進め方

それでも予算に限りがある、という場合もありますよね。

そんな時は、要件定義の質を落とすのではなく、対象の範囲を絞るのがおすすめです。

業務システムを新しく入れる時の要件定義の進め方は、システム導入・構築の要件定義で解説しています。

よくある相談に答えます

要件定義の費用は、どちらが持つもの？

システムを入れようとしている会社と、作る会社の間で、要件定義の費用をどちらが持つのか、という相談があります。

一般的には、要件定義も開発側の作業なので、発注側が費用を払う形が多いです。

ただ、提案の段階で行う簡単な聞き取りまで費用がかかるかどうかは、会社や取り決めによって違います。

『どこからが有料なのか分からない…』という時は、見積もりの段階で「どの作業から費用が発生するか」を確かめておきましょう。

要件定義の期間を長く取ってほしいと言われた

開発側の立場で、発注側から要件定義の期間を長めにしてほしいと頼まれ、予算との兼ね合いで悩む、という声もあります。

期間を長くすると、関わる人の作業時間も増えるので、費用も増えるのが一般的です。

まずは、なぜ長い期間が要るのかを聞いてみてください。

関係する部署が多い、業務がまだ固まっていない、などの理由が分かれば、期間を延ばす以外の手を一緒に考えられます。

ホームページの作り直しでも、要件定義の費用はかかる？

ホームページの作り直しを業者に頼む時も、要件定義にあたる作業に費用がかかるのか、という相談もよく見かけます。

呼び方は会社によって違いますが、目的や載せる内容、必要な機能を決める作業は、多くの場合に含まれています。

見積もりでは、その作業が「要件定義」「設計」「企画」など、どの名前で書かれているかを確かめてみてください。

名前が違っても、何を決めて何を渡してくれるのかが分かれば、比べられます！

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義の進め方とやり方｜6つの手順と週ごとのスケジュール例

プロジェクトの要件定義とは？システム導入・構築で詰めること