「とりあえず、どれくらいの工数になるか見積もり取って！」
ITプロジェクトの企画を進めていると、上司からこんな一言を言われることがあります。
要件定義は一通りやった。でも正直、まだフワッとしている部分もある。とはいえ、何もしないと話は前に進まない。
- どこまで決まっていれば、見積もりを取っていいのか
- RFPって、ちゃんと作らないといけないのか
- そもそも、見積もりってそんなに重いものなのか
そんなモヤモヤを抱えたまま、「とりあえず金額だけでも…」とベンダーに声をかけてしまう。
これ、発注側あるあるだと思います。ただ、ここで一つだけ強調したいことがあります。見積もりは、単なる事務作業ではありません！
見積もりは、契約内容・支払い金額・対応範囲を固定する工程。つまり、お金と責任が発生する境界線です。
この時点での認識ズレは、開発フェーズに入ってから「戻れないトラブル」になります。だからこそ、見積もりは「急いで取るもの」ではなく、ちゃんと準備して取りに行くもの。
この記事では、発注側の視点で、
- 見積もりとは何をしている行為なのか
- RFPは何のためにあり、何を書けばいいのか
- 見積もり取得までをどう整理すればいいのか
を整理します。
この記事でわかること
- 見積もり取得が、なぜプロジェクトの重要分岐点なのか
- RFPとは何で、何を書けば「見積もれる状態」になるのか
- 見積もり〜RFP作成をどういう順番・考え方で進めればいいか
そもそも「見積もりを取る」とは何をしているのか？
まず、そもそも見積もりとは何をしているのでしょうか。
「開発にかかる金額を出してもらうだけでは？」と思っている人も多いかもしれません。
確かに、結果として金額は出てきます。ただ、見積もりの本質はそこではありません。
見積もりとは、開発ベンダーに「こちらのやりたいこと」を伝え、作業範囲・前提条件・金額をセットで可視化してもらう行為です。
重要なのは、金額の裏側です。
見積もりには必ず、次のような前提が含まれています。
- 何をやるのか
- どこまでやるのか
- どこから先は対象外なのか
- どんな前提条件で成り立っているのか
この前提の認識がズレたまま開発に入ると、
- 「それは見積もりに入っていません」
- 「追加対応になります」
- 「一度、設計を戻します」
といったやり取りが発生します。非常にまずい状況になります。
つまり見積もりは、価格交渉の場ではなく、合意形成のプロセスです。
見積もり内容をベースに契約を結ぶ以上、見積もり時点で認識がズレていれば、ズレたまま契約してしまうことになります。
だからこそ、見積もりは「とりあえず取るもの」ではなく、きちんと認識をそろえるための重要な工程なのです。
見積もり取得までの全体像
ここでは、見積もり取得までの流れを一度ざっと俯瞰しておきます。
細かい話に入る前に、まずは全体感を掴んでいきたいと思います。
基本的な流れは、シンプルです。
- プロジェクト計画・要件定義・ソリューション方針を整理する
- それらをRFP（提案依頼書）としてまとめる
- 開発ベンダーに見積もりを依頼する
見ての通り、特別に難しい工程はありません。前の工程がきちんとできていれば、見積もりに必要な情報はすでに揃っているはずです。
やることは、それらを「第三者である開発ベンダーに伝わる形」にまとめること。それがRFPの役割です。
次に、少し視点を引いてITプロジェクト全体の中での見積もりの位置づけも確認しておきましょう。
見積もりは、企画・要件定義フェーズと、開発フェーズのちょうど間に位置します。
ここで押さえておきたいのは、次の2点です。
- 見積もりは、企画・要件定義フェーズの「出口」であり
- 同時に、開発フェーズの「入口」でもある
企画・要件定義フェーズで決めた内容を、見積もりと契約に落とし込み、その契約を前提に開発を進めていく。つまり、契約や発注といった重要な手続きの根拠になるのが見積もりです。
改めてですが、見積もりを「とりあえず取る」わけにはいかない理由は、この位置づけを見てもわかるかと思います。
RFPとは何か？
見積もりを取ろうとすると、必ず出てくるのが RFP という言葉です。ここでは、RFPの役割を整理します。
RFPとは、提案依頼書（Request for Proposal） のこと。
開発ベンダーに対して、
「この内容を前提に、提案と見積もりをしてください」
と依頼するためのドキュメントです。
RFPには、主に次のような内容を書きます。
- 何を実現したいのか
- 何を提案してほしいのか
- どんな条件で見積もってほしいのか
ただし、ここで強調したいのは、RFPで一番重要なのは形式ではないという点です。
RFPの本質は、第三者である開発ベンダーに、こちらの考えを正確に伝えること。
そのため、多くのケースでは見積もりは、
- RFP本体
- 要件定義書やソリューション方針などの補足資料
のセットで行われます。
実は、見積もりの精度を大きく左右するのは、RFP本体よりも補足資料です。
RFPの書き方に関する情報は多いですが、見積もりの質を決めているのは、RFP以前に作ってきた要件定義書などのドキュメントだったりします。
そのため、付き合いのあるベンダーに見積もりを依頼する場合は、
- 形式的なRFPは作らず
- 要件定義書をそのまま渡して見積もりを取る
というケースも珍しくありません。
このように、見積もりを取るうえでRFPそのものは必須ではありません。大切なのは、RFPという形式にこだわることではなく、「見積もれるだけの情報が整理されているか」です。
RFPの作り方：何を書けば「見積もれる状態」になるか
ここからは、見積もりに必要な RFP（＋補足資料） の作り方を整理します。
とはいえ、ここまで順を追って進めてきていれば、やることの大半はこれまで作ってきた資料の整理・再構成です。ゼロから何かを書く、という感覚ではありません。
RFPのフォーマットを用意しているので、必要に応じてこちらも参照しながら読み進めてください。
前提確認｜いきなりRFPを書かない
まず大前提として、いきなりRFPを書き始めることはしません。
RFPは、見積もり前の工程が完了していることが前提条件になるからです。
なので、まずは以下が揃っているかを、最初に確認します。
- プロジェクト計画があること
- 要件定義が終わっていること
- ソリューション方針が決まっていること
どれか一つでも不十分であれば、まだ見積もりを取れる段階ではありません。
例えば、要件が固まりきっていない状態で見積もりを依頼しても、開発ベンダーは正確な見積もりを出すことができません。
仮に見積もりが出てきたとしても、
- 不明点が多いためリスクを上乗せされる
- 結果として高額な見積もりになる
というケースがほとんどです。
見積もりの精度は、前工程の完成度で決まる。
この前提は、ここでしっかり押さえておきましょう！
プロジェクト概要の書き方
RFPは大きく分けて、2つのパートで構成されます。前半が「プロジェクト概要」です。
ここでは、
- このプロジェクトの目的は何か
- どんなスコープで実施するのか
- どこを目指しているのか
- 体制やスケジュールはどうなっているか
といった全体像をまとめます。
これらは、すでにプロジェクト計画書に書かれている内容です。基本的には、それをそのまま転用すれば問題ありません。
もし状況が変わっている部分があれば、必要最低限アップデートする程度で十分です。プロジェクト計画に不安がある場合は次の記事も参考にしてみてください。
提案依頼内容の書き方
後半が、RFPの中心となる 提案依頼内容 です。
ここは、見積もりを依頼するにあたっての開発ベンダー向けの指示書のような位置づけになります。
- 何を
- どのように
- いつまでに
見積もってほしいのかを、正確に伝えることが重要です。
ここからは、項目ごとに見ていきます。
要求概要
ここでは、要件定義してきた内容のサマリーを記載します。
このプロジェクトで「何を実現したいのか」を大枠で伝えるパートです。
注意したいのは、ここで詳細を書きすぎないこと。
細かく書こうとすると、要件定義書の内容をRFPに転記するだけになりがちです。それは、工数の無駄になってしまいます。
このパートではあくまで概要に留め、詳細は補足資料を参照してもらう導線を作ることを意識します。
提案依頼内容
次に、何を提案してほしいのかを明確にします。
フォーマットをもとに記載すればOKです。少なくとも以下は必ず提案してもらいましょう。
- 費用・工数
- 作業内容・成果物
- 体制
- 契約条件
どれくらいの費用と期間で、どんな作業を行い、何を作るのか。それを、どんな体制で実施するのか。これらが揃っていなければ、契約・発注の判断ができません。
もし、追加で確認したいことや、特定の観点で提案してほしいことがあれば、このパートに追記します。
評価基準
提出された提案を、どのような観点で評価するのかを記載します。
プロジェクトによって、重視するポイントは異なります。
- 低予算のプロジェクトなら費用重視
- 技術的難易度が高ければ、実績や技術力重視
発注者側が何を重要視しているかを事前に伝えることで、ベンダーもそれに合わせた提案がしやすくなります。
提出方法・スケジュール
提案書の提出方法とスケジュールを記載します。
- 提出期限
- 提出形式
- 質問方法
など、最低限が書かれていれば十分です。
制約事項
作業場所や環境などに制約がある場合に記載をします。
特に、開発に使うPCや、システムを構築する環境について制約がある場合は、必ず記載しましょう。
補足資料
最後に、RFP本体とは別にどのような補足資料があるかを一覧でまとめます。
ここでは、
- 要件定義書
- 画面イメージ
- 制約条件
など、見積もりの前提となる資料を漏れなく示します。
実は一番重要なのは「補足資料」
RFP本体は、あくまで入口です。実際に見積もりを作るとき、開発ベンダーが一番見ているのは補足資料です。
RFP本体と補足資料の役割を整理すると、次のようになります。
- RFP本体：見積もりの指示書
- 補足資料：見積もりを作るためのINPUT情報
つまり、RFP本体は「何を、どんな条件で見積もってほしいか」を伝えるもの。
一方で、補足資料は「その見積もりを作るための材料」そのものです。
そのため、いくらRFP本体を丁寧に作り込んでも、補足資料の情報が足りなければ、精度の高い見積もりを取ることはできません。
良い見積もりを取りたいのであれば、力を入れるべきなのは要件定義書などの補足資料を、見積もれる粒度まで作り込むことです。
そのうえで、可能であれば補足資料を事前にチェックしてもらうことをおすすめします。
- 社内のIT企画担当
- エンジニア
など、ITの視点を持つ人に「この資料で、本当に見積もりができるか？」を確認してもらいます。
さらに余裕があれば、RFPを出す際に開発ベンダー向けに補足資料の説明の場を設けるのも有効です。書面だけでなく、発注者側の考えや前提を対面で共有することで、認識齟齬を減らし、より正確な見積もりにつながります。
まとめ
「とりあえず見積もりを取って」と言われるたびに、見積もりってそんなに簡単なものじゃないのにな、と思ってきました。この記事では、その理由を整理してきました。
見積もりは、企画・要件定義と開発をつなぐ、非常に重要な工程です。見積もりをもとに契約と発注を行い、その契約を前提に開発が進みます。
契約も発注も、会社対会社の重要な約束事です。その前提となる見積もりを、軽い気持ちで進めてはいけない理由は、ここにあります。
また、「見積もり＝RFP」というイメージを持っている方も多いと思いますが、実際に見積もりの精度を左右するのは、RFP本体よりも、補足資料となる要件定義書などのドキュメントです。
見積もりは、これまで積み上げてきた企画・要件定義の総まとめのようなもの。ここまでの工程を丁寧に進めていれば、見積もり自体は決して難しい作業ではありません。
一方で、前工程を曖昧にしたまま進めれば、見積もりの段階で必ずつまずきます。
だからこそ、「早く見積もりを取る」よりも、「見積もれる状態を作る」ことを意識する。
それが、プロジェクトを安定して前に進めるための一番の近道だと思います。
おまけ：見積もりにおけるNGパターン
ここでは、見積もり取得の現場でよく見かけるつまずきやすいNGパターンを整理します。
NG①：見積もりINPUTが揃っていない
いざ見積もりを取ろうとしても、要件定義書などの前提資料が揃っていないパターンです。
業務企画の立場だと、「そもそも何があれば見積もりが取れるのか」が分からないまま進んでしまうことも多く、かなりあるあるです。
この状態で無理やり見積もりを依頼すると、
- 不明点が多いためリスクを多めに見積もられる
- 結果として高額な見積もりになる
- 開発に入ってから手戻りが発生する
といった問題につながります。
この段階で大切なのは、無理に進めないことです。
一度立ち止まり、
- IT企画担当
- エンジニア
など、ITに詳しいメンバーをチームに含め、「見積もりに必要な資料は何か」を整理するところからやり直しましょう。
NG②：何を提案してほしいかが曖昧
次によくあるのが、何を提案してほしいのかが曖昧なまま依頼してしまうケースです。
例えば、
- 開発の見積もりを取りたいのか
- 要件定義フェーズの見積もりを取りたいのか
- スコープやスケジュールはどこまで確定しているのか
といった点が整理されていない状態です。
このNGは、①のケースともよくセットで起きます。
当然ですが、曖昧な依頼からは、曖昧な提案しか返ってきません。結果として、見積もり同士の比較もできなくなります。
こういうときも、無理に見積もりを取りに行くのではなく、
- プロジェクト計画書
- 要件定義書
を見直し、スコープ・前提・期待値を整理し直すことが先決です。
関連記事