システム開発を何社かに相談して見積もりを取ると、金額の桁が違う数字が並んで判断できなくなることがあります。 一括見積のサービスを使って複数社から一度に集めた場合はなおさらで、 同じ相談をしたはずなのに、安い会社と高い会社で何倍もの差が出る。 どこかが極端に高いのか、それとも安いほうが何か抜けているのか、比べる手がかりが見つからない状態です。
この差の大半は、会社の価格設定というより各社が置いた前提の違いから生まれます。 そして前提がばらつく原因は、多くの場合、発注側が各社に渡した情報の側にあります。 この記事では、受託開発を手がけるCoconutWorksが、 見積もりを依頼する段階で用意しておきたい依頼書の作り方を整理します。 届いた見積書のどこを読むかはシステム開発の見積書、どこを比較すればいいかで扱っているので、ここは送る前にできることに絞ります。
結論: 依頼書に入れておく5つの要素
| 依頼書に入れる要素 | 何を書くか | 書かないまま渡すと起きること |
|---|---|---|
| 今の業務と困っている事象 | 誰が・どの順番で・どのくらいの頻度でやっているか。困りごとは解決策ではなく起きている事象で書く | 各社が別々に業務を想像して設計するため、規模の想定から食い違う |
| 対象範囲と、含めない範囲 | 今回作りたい業務の範囲、既存の仕組みとの境目、今回は手を付けないと決めたもの | 1社は周辺業務込み、別の1社は最小限という見積もりが並び、総額を比べる意味がなくなる |
| こちらから指定する共通条件 | データ移行の有無、使い始めたい時期、公開後の対応をどうしたいか、社内で確認に入れる人 | 各社が自社の標準的な前提で埋めるため、金額差の理由が前提の差なのか力量の差なのか分からない |
| 回答してほしい形式 | 内訳の粒度、前提条件を書く欄、想定する進め方と期間、提出の期限 | 総額だけの見積書と工程別の見積書が混ざり、並べても対応する項目が見つからない |
| 選ぶときに見るところ | 金額以外に何を重く見るか（進め方・体制・公開後の関わり方など） | 価格競争の提案ばかりが集まり、続けて頼める相手かどうかの判断材料が出てこない |
この5つのうち、最初に思い浮かぶのは業務の説明でしょう。 一方で見落とされやすいのは、後ろの3つ——こちらから指定する共通条件、回答してほしい形式、選ぶときに見るところです。 この3つは「発注側が決めてよい」と思われていないために空欄のまま渡され、 各社がそれぞれの標準で埋めることになります。以下、順に掘り下げます。
同じ相談をしても前提はそろわない
たとえば、紙とエクセルで回している受発注の管理をシステムにしたい、という相談をしたとします。 この一文から各社が思い描くものは、実際にはかなり違います。 一方は入力と一覧だけの最小限の画面を想像し、 別の一方は在庫や請求との連携、権限の分け方、既存データの移行まで含んだ姿を描く。前者と後者では、そもそも作る量が違います。 金額の差は、多くの場合ここで決まっています。
前提がばらつくのは、各社が不誠実だからではありません。 受託側は、書かれていない部分を自社の経験から埋めて見積もるしかないためです。 普段から小さく作って様子を見る進め方をしている会社は最小限で見積もり、 あとから追加が出ないように先回りして設計する会社は広めに見積もります。 どちらも自社の標準的な進め方に従っているだけで、埋めた前提が違うので、数字も違うという結果になります。
ここから分かるのは、比較できる状態を作れるのは発注側だけだということです。 受託側は他社に何を伝えたか知りませんし、比較しやすいように前提をそろえることもできません。 逆に言えば、渡す材料を同じにするだけで、届く数字は比べられる形に近づきます。 使う技術や進め方は各社の判断に任せてよく、 そろえたいのは業務としての条件だけです。
困りごとは「解決策」ではなく事象で書く
依頼書でいちばん量を使うのは、今の業務と困っている内容の説明です。 ここで起きやすいのが、困りごとを解決策の形で書いてしまうことです。 「顧客管理システムが欲しい」「入力を自動化したい」と書くと、 受託側はその手段を前提に見積もるため、本当に困っている場所とずれた提案が返ってくることがあります。
たとえば、受注の内容を担当者ごとに別のエクセルで管理している会社で、 月末の集計に時間がかかっているとします。 これを「集計を自動化したい」と書くと集計の仕組みの見積もりが返ってきますが、 実際に時間を食っているのが、担当者ごとに書き方が違うファイルを突き合わせる作業なのであれば、 効くのは集計の自動化ではなく入力の形をそろえることです。 事象のほうを書いておけば、受託側はその判断から提案できます。
書き方として使いやすいのは、誰が・どの順番で・どのくらいの頻度でやっていて、 どこで止まるか・どこで間違いが起きるかを並べる形です。 あわせて、その作業に月あたりどのくらいの時間がかかっている感覚かを添えると、 受託側は力を入れる場所を判断できます。 この整理は要件定義の入り口でも使うもので、 具体的な書き出し方は要件定義の前に発注側が準備することで詳しく扱っています。
範囲は「含めないもの」を書くほうが効く
対象範囲を書くとき、やりたいことを並べるのは自然にできます。 揃えるうえで効くのはむしろ逆側で、今回は手を付けないと決めたものを明記することです。 範囲の外側が書かれていないと、各社は「ここまでは当然含むだろう」という線を自分で引きます。 その線の位置が会社ごとに違うため、総額を並べても対応しません。
書いておきたい境目は、だいたい次のあたりに現れます。 今あるエクセルや別システムのデータを移すのか、それとも新しい運用から始めるのか。 会計や在庫など隣の業務とつなぐのか、当面は手作業でつなぐのか。 社外の方が使う画面まで含むのか、社内利用だけか。データ移行と外部連携は、含むかどうかで金額が大きく動く代表格です。 決めきれない場合も、「今回は含めず、次の段階で相談したい」と書けば前提はそろいます。
段階に分けて進めたい場合は、その意図も書いておきたいところです。 最初に使い始める範囲と、あとから足したい範囲を分けて示しておくと、 各社は今回の見積もりと将来の拡張を分けて答えられます。 これを書かないと、将来やりたいことまで一式に含めた見積もりと、 目の前の範囲だけの見積もりが混ざります。
共通条件は発注側から指定してよい
依頼書で最も抜けやすく、しかし効き目が大きいのがこの部分です。 技術的な選定は各社に任せるべきですが、業務としての条件は発注側でなければ決められません。 そして、それが金額を動かします。空欄のまま渡すと各社が自社の標準で埋めるため、 後から「その前提だったのか」と分かる形になります。
指定しておきたいのは、たとえば次のような項目です。 今あるデータを引き継ぐ必要があるか。いつまでに使い始めたいか、その時期に理由があるか。 公開したあとの不具合対応や小さな改修を続けて頼みたいか、社内で持つ想定か。 テストや確認に社内の誰がどのくらい入れるか。 最後の項目は見落とされがちですが、発注側が確認に入れる時間が取れるかどうかで、 受託側が用意するテストの範囲と期間が変わります。
時期については、希望を書くだけでなく理由を添えると扱いが変わります。 期の切り替わりに合わせたい、繁忙期の前に慣れておきたいといった背景が分かれば、 受託側は間に合わせる形（先に使う範囲を絞る、など）を提案できます。 逆に理由のない締め切りだけが書かれていると、 急ぎに対応するための体制を積んだ見積もりが返ってくることがあります。
回答の形をそろえ、質問は全社に配る
材料をそろえても、返ってくる書式がばらばらなら並べられません。 依頼書には、どういう形で答えてほしいかも書いておきます。 指定しておくと効くのは、工程ごとの内訳を分けて書いてもらうこと、 前提条件を書く欄を設けてもらうこと、 公開後の費用を初期費用と分けて示してもらうこと、そして提出の期限です。
前提条件の欄は特に効きます。 各社が何を含めたつもりなのかがそこに出るため、 金額差の理由を読み解く手がかりになります。 「この前提が変わると金額はどう動くか」まで書いてもらえると、 社内で予算を調整する場面でも使えます。 内訳の粒度については、機能を一式でまとめず、画面や機能の単位で書いてもらうよう頼むと、 後から追加費用が出やすい箇所が見えやすくなります。
依頼書を渡したあとは、各社から質問が届きます。 これは読み込まれている合図なので、来ること自体は歓迎してよいものです。 気をつけたいのは、回答をその会社だけに返してしまうことです。 1社への回答で前提が更新されると、その会社だけ違う条件で見積もる状態になり、 そろえたはずの土俵が崩れます。届いた質問と回答は一か所にまとめ、 全社に同じものを配るようにします。この手間を惜しまないと、比較の精度がはっきり変わります。
よくある誤解と、作る順序
- 「細かく書くと高い見積もりが出てくる」 — 逆になることが多いです。情報が足りない見積もりには、不明な部分を見込んだ余裕が乗ります。範囲と前提が明確なほど、その余裕を削れます。高くなるのは書きすぎたときではなく、範囲を絞れていないときです。
- 「仕様が固まっていないうちは依頼書を作れない」 — 依頼書に書くのは仕様ではなく、今の業務と困っている事象、そして条件です。決まっていないことは「未定」と書いてよく、むしろ未定だと分かるほうが各社は前提を明示して答えられます。
- 「同じ文面を送ったのだから条件は同じはず」 — 文面が同じでも、書かれていない部分は各社が別々に埋めます。そろうのは渡した文面ではなく、埋める余地を減らした部分だけです。
- 「揃えてしまうと各社の提案の幅が出ない」 — そろえるのは業務としての条件で、実現の手段は各社に任せます。条件が同じだからこそ、進め方や範囲の絞り方の違いが見える形になります。
作る順序としては、次のように進めると迷いにくくなります。
- ①今の業務の流れと困っている事象を書き出す — 誰が・どの順番で・どのくらいの頻度で。困りごとは解決策ではなく起きている事象として書きます。ここが依頼書の土台になります。
- ②今回の範囲と、含めない範囲を線引きする — データ移行と外部連携の扱いを先に決めます。決めきれないものは「今回は含めない」と書いておけば前提はそろいます。
- ③共通条件を埋める — 使い始めたい時期とその理由、公開後の関わり方、社内で確認に入れる人。発注側でなければ決められない項目です。
- ④回答の形式と期限を指定する — 工程別の内訳、前提条件の欄、初期費用と公開後の費用の分離。並べたときに対応する形を先に決めます。
- ⑤質問の受け付け方を決めて配る — 窓口を一か所にし、届いた質問と回答は全社に同じものを配る。ここまで決めてから声をかけます。
よくある質問
まとめ
見積金額が会社ごとにばらつくのは、価格設定の差というより各社が埋めた前提の差です。 そして前提をそろえられるのは、各社に何を渡したかを知っている発注側だけです。 困りごとは事象で書き、範囲は含めないものまで線引きし、 時期や公開後の関わり方といった条件はこちらから指定する。 回答の形式と期限を決め、届いた質問は全社に同じものを配る。 ここまで整えると、届いた数字は比べられる形になり、 差の理由も読み解ける状態になります。 依頼書をどう書くかの段階からのご相談も歓迎です。システム開発・業務改善サービスのページもあわせてご覧ください。ご相談・お見積もりは無料です。
