「この見積もり、高いのか安いのか分かりません」。システム導入のご相談で、いちばんよく聞く言葉の一つです。

私は中小企業診断士として、また公的支援機関で経営相談を受ける立場から、日々システム導入やDXのご相談に関わっています。その前は、ITベンダー側で20年以上、基幹業務システムの開発・導入に携わってきました。営業として見積もりを出す側にも、SE(システムの設計・開発を担う技術者)として中身を作る側にもいました。

その経験から言えるのは、見積書は「金額」より「前提」を読むものだということです。この記事では、ベンダー側にいたからこそ分かる見積書の読み方をお伝えします。

見積書は「金額」ではなく「前提」を読む

ERPベンダーにいたころ、同じ機能の見積もりでも、会社によって2〜3倍の差が出ることは珍しくありませんでした。

この差は、たいてい技術力や良心の差ではありません。前提の差です。どこまでを作るのか。何人で何か月かけるのか。何を見積もりに含めないのか。前提が違えば、金額が違うのは当然です。

困るのは、前提が見積書の中で目立たないことです。金額は表紙に大きく書かれますが、前提は最後のページに小さな文字で書かれていることが少なくありません。金額だけを比べると、前提の薄い見積もりほど安く見えます。

単価は出てこない。だから「期間と人数」で逆算する

システム開発の見積もりの多くは、「人月(にんげつ)」という単位をもとに作られています。人月とは、1人が1か月働く作業量のことです。

見積金額は、おおまかに「作業量(何人月か)×単価(1人月あたりいくらか)」で決まります。ただ、見積書にこの2つがそのまま書かれていることは、あまりありません。私自身、ベンダー側にいたときは、作業量と単価を見積書に出さないようにしていました。

特にパッケージ(既製品のシステム)を扱うベンダーでは、工数を積み上げるだけで金額が決まるわけではありません。どの機能をどこまで使うかによって、プロジェクトの期間そのものが変わります。使う機能が広がれば、設定やテスト、教育の範囲も広がるからです。

それでも、おおよその見当はつけられます。プロジェクトの期間と、関わるメンバーの人数を聞いて逆算するのです。たとえば「4人が6か月関わる」なら、ざっと24人月の規模です。総額をこの規模で割れば、1人月あたりの金額の目安が出ます。期間と人数は、単価よりずっと答えてもらいやすい質問です。

もう1つ見ておきたいのが、工程ごとの内訳です。システム導入には、ふつう次のような工程があります。

• 要件定義(システムに何をさせるかを決める)
• 設計・開発
• テスト
• データ移行(今のシステムやExcelのデータを新しいシステムに移す)
• 操作教育・稼働の立ち会い

開発だけが大きく、要件定義やテスト、データ移行が薄い、あるいは書かれていない見積もりは要注意です。その工程がなくなるわけではありません。あとから追加になるか、御社の社員がやることになるかのどちらかです。

要注意の3つの表記:「一式」「別途」「想定」

見積書の中で、特に注意して読んでほしい言葉が3つあります。

「一式」……中身が見えない

「導入作業 一式 ◯◯万円」のような書き方です。業界の慣習としてよく使われ、悪意があるわけではありません。ただ、何が含まれているのか分からないと、他社と比べることも、範囲を相談することもできません。

「一式」と書かれていたら、何が含まれているのか、どのくらいの期間と人数を見込んでいるのかを確認するのが基本です。遠慮せずに聞いてかまいません。

「別途」……合計に入っていない

「データ移行は別途お見積り」「帳票の作り込みは別途」のように、見積もりの外に出されている項目です。よく「別途」になるのは、次のようなものです。

• データ移行
• 帳票(請求書や納品書などの印刷物)の作り込み
• 他のシステムとの連携
• 操作教育
• サーバーやソフトウェアのライセンス費用

どれも、導入すれば結局必要になるものです。合計金額に入っていないぶん、見積もりは安く見えます。「別途」の項目を全部足すと、いくらになりそうかを、必ず確認してください。

「想定」「前提条件」……ここを超えると追加費用になる

「帳票は10種類を想定」「標準機能の範囲内での導入を前提とする」といった書き方です。見積書の中でも、特に注意して読んでほしい欄です。

想定や前提を超えた分は、追加の費用になります。たとえば帳票10種類の想定で、実際には30種類必要だったとすれば、差の20種類は追加です。前提条件は、見積金額が守られる範囲を決めている「契約の境界線」だと思って読んでください。

安すぎる見積もりには、理由がある

他社より明らかに安い見積もりが来ると、うれしくなるものです。ただ、安さには理由があります。前提が狭いか、「別途」が多いか、あとから回収する仕組みになっているかです。

あとから回収するのは、主に次の2つです。

• 仕様変更の追加費用……要件定義のあとに出てきた変更や追加を、どういうルールで見積もるのか
• 保守費用……導入後に毎年かかる費用。パッケージの場合、ライセンス費の15〜20%程度が相場です

保守費用は、導入して終わりではなく毎年続きます。初期費用が安くても、保守費の割合が高ければ、5年間の合計では逆転することがあります。比べるときは5年間の合計で見てください。費用の内訳はERP選びの記事でも詳しく書いています。

契約の形にも目を向けておきましょう。完成を約束する「請負」なのか、作業した時間に対して支払う「準委任」なのかで、同じ金額でも意味が変わります。準委任の見積もりは、作業が延びればその分だけ費用が増えます。

念のため付け加えると、安い見積もりが悪いわけではありません。前提がはっきり書かれていて、そのうえで安いなら、それは良い見積もりです。見るべきは、金額の安さではなく、前提の明確さです。

相見積もりは「前提」をそろえて比べる

相見積もりを取ったのに比べられない。これもよくあるご相談です。原因の多くは、各社にばらばらの伝え方で依頼していることにあります。伝え方がばらばらなら、前提もばらばらになり、金額を並べても意味がありません。

比べるときは、金額の前に、次の項目を横に並べてみてください。

表を埋めていくと、どこかの会社の欄が空欄になります。その空欄が、ベンダーに質問すべきことです。

明日からやれること:見積もりを頼むとき、前提を書面で渡す

見積書を読む力も大切ですが、もっと効くのは、依頼するときに前提をこちらから渡すことです。見積もりを頼む前に、次の3つを書面にまとめてください。

1. 目的と範囲……何のために、どの業務をシステム化するのか。何はやらないのか
2. 今の業務と量……今の業務の流れと、帳票や画面のおおよその数
3. 見積もりの形……データ移行・教育・5年分の保守を含めること。工程ごとの内訳と、プロジェクトの期間・体制を示してもらうこと

各社が同じ前提で見積もるので、そのまま比べられます。これがRFP(提案依頼書。ベンダーに提案を依頼するための資料)の考え方です。「システム導入が失敗する本当の理由」で紹介した「A4一枚」を育てると、この書面になります。RFPの基本は「RFPって何?」の記事をご覧ください。

まとめ

システム開発の見積書は、金額の大小より、その金額がどんな前提で出ているかを読むものです。

• 期間と人数……単価が出ていなくても、期間と体制から規模を逆算し、工程ごとの内訳を見る
• 3つの表記……「一式」は内訳を、「別途」は合計を、「想定」は境界線を確認する
• 安さの理由……変更と保守を含めた5年間の合計で比べる
• 相見積もり……前提をそろえて依頼し、空欄を質問に変える

「手元の見積書をどう読めばいいか分からない」「ベンダーにどう質問すればいいか分からない」という場合は、発注する側の立場で一緒に読み解きます。