システム開発の見積もり、3社集めても比べたことになりません

システム開発 見積もり 3社

「この金額、高いのか安いのかも分からない」

開発会社から届いた見積書を開くと、想定の2倍か3倍の数字が並んでいました。
そのままでは社内に出せないので、もう1社か2社から相見積もりを取ろうとしているところだと思います。

その順番で進めると、3社の金額は並びます。ただし、その金額を払うべきかどうかは並びません。3社とも、あなたに何かを作って納める側にいるからです。

私は自治体の技術職として、6年ほど工事を発注する側にいました。届いた見積もりを見て判断するのではなく、こちらで先に金額を計算する仕事です。工事を出す前に発注する側で金額の当たりを自分で持っておく、というその手順から取り出したものが、この記事で渡す判断基準です。

読み終えたときには、手元の見積書について次の3つを自分で決められます。

  • 見積書のどこを分解して、どこを聞き返すか
  • その金額の根拠が、誰の内側にあるか
  • 承認する前に、何と何を比べておくか

目次

見積書は「工数×単価」に分解できます

たとえば、届いた紙に「システム開発一式 850万円」と1行だけ書かれていたとします。「何にそんなにかかるんですか」と聞きたくなる紙です。この紙から、何人が何か月動く想定なのかは読み取れません。

見積書の総額は、作業量に単価を掛けて、諸経費を足した数字です。だから総額のままでは、高いとも安いとも判定できません。850万円が高いかどうかを考える前に、そもそも比べる場所がないという状態です。

費目が分かれていないと、比べる場所がありません

工程ごとの費目にきちんと分かれた見積書であれば、そのそれぞれに置かれた作業量と単価から、何にいくらかかる想定なのかを追えます。並んでいてほしい費目は、だいたい決まっています。

見積書の費目
  • 要件定義(何を作るかを決める工程)
  • 設計(どう作るかを決める工程)
  • 開発(実際に手を動かして作る工程)
  • テスト(想定どおり動くかを確かめる工程)
  • 進行管理(全体を回して調整する工程)
  • 導入と保守(渡したあとを支える工程)

この中のどれかが書かれていないとき、その工程が消えたわけではありません。あとで別の請求書になって出てくるか、自社の誰かが代わりに引き受けることになります。

その作業量を出したのは、見積もりを出した会社です

費目が分かれていても、もう一つ見ておく場所があります。その作業量が、どこから出てきた数字なのかという点です。作業量の出し方には、いくつかの決まったやり方があります。

  • 過去の似た案件から見当を付ける
  • 作業を細かく分けて積み上げる
  • 蓄積したデータを計算式に当てはめる

どのやり方で出したとしても、その根拠になっているのは、見積もりを出したその会社の内側に貯まっている過去の案件の記録になります。これは手抜きでも不正でもなく、そういう仕組みだということです。ただ、そうであれば、発注する側が手元で当てられる物差しはどこにあるのか。


3社から取っても、比べているのは金額だけです

相見積もりは、金額の物差しとしては働きます。ただし、その仕組みを作るべきかどうかの物差しにはなりません。3社とも、あなたに何かを作って納める側にいるからです。

仮に3社から取った場面を考えます。A社が800万円、B社が1,200万円、C社が2,500万円で戻ってきました。差の理由を聞けば、どこが厚くてどこが薄いのかは見えてきます。

それでも3社が答えているのは、同じ1つの問いです。「その要件を、うちならいくらで作れるか」。だから比べられるのは、作る場合の値段だけになります。その要件そのものを作るべきかどうかは、3社のうちどこも答える立場にいません。

3社の見積書を並べたとき、何が揃って何が揃わないのかを分けてみてください。

3社の紙の中身
  • 作る場合の金額は、3社とも書いてある
  • 作る場合の期間と体制も、3社とも書いてある
  • それを作るべきかどうかは、3社とも書いていない

1つの提案に対して金額を3つ並べただけの状態では、比べているつもりで、実際には「やるか、やらないか」のどちらかを選んでいることになります。見積もりで損をしやすい場所は、私の見るかぎりここです。

とはいえ、金額が高く出てくること自体には、はっきりした理由があります。


高いのは、まだ決まっていない分が入っているからです

見積もりの金額には、まだ決まっていない分の値段が含まれています。厚くなるのは、何を作るかが固まっていないときです。

開発会社の側から見ると、要件がはっきりしない案件は、あとから作業が増える可能性の高い案件です。増えた分を自社でかぶらないために、先に余裕を積んでおきます。この余裕は、使われないまま終わっても返ってきません。

まだ何も決めていないのに、金額だけ先に決まる。

つまり発注する側は、自分たちがまだ決めていないという事実に対して、決めていない量に応じた金額を先に払っていることになります。値引きを頼んでも、この部分はあまり動きません。動くのは、決まっていない量のほうです。

安くしてほしいと頼む前に、まだ決めていないことを1つ減らします。

とはいえ、自社がいまどこで詰まっているのかが見えないままだと、何から決めればよいのかも決まりません。下のボタンから9つの質問に答えると、見える化・自動化・内製化のどこで止まっているかが出ます。所要は3分です。

決める材料が揃ったとして、もう一つ見ておく場所が残ります。その金額が、どこの基準に照らして出てきたのかという場所です。


金額の根拠を、外に置いている発注者もいます

金額の根拠を、発注する側にも作る側にも置かないやり方があります。公共工事では、それが制度として動いています。

私は自治体の技術職として、6年ほど工事を発注する側にいました。工事を出す前に、こちらで金額を計算します。その計算をせずに発注する道は、制度の上にありません。省けば不正になるからです。

何をいくらと見るかは、外の基準で決まっていました

計算に使っていたのは、国や関係する協会が作った積算基準書と、その工事で何がどれだけ必要になるかを書き出した数量計算書の2つでした。手元にあったのは、次の3つです。

積算で使ったもの
  • 積算基準書(作業ごとの人手と時間の目安)
  • 単価表(材料や労務の値段)
  • 数量計算書(この工事で何がどれだけ要るか)

積算基準書には、この作業にはこれだけの人手と時間がかかるという目安が、歩掛という形で決められています。作ったのは国や協会であって、発注する私たちでも、工事をする会社でもありません。

だから私が確かめていたのは、金額の高い安いではありませんでした。歩掛のとおりに、この現場の条件で価格が組まれているかどうかです。建設業の場合、この部分がきっちり決めやすい特徴があるためです。

業者の見積もりは、そのままでは使いませんでした

基準書に載っていない作業も出てきます。その場合は、会社から見積もりを取って計算に使いました。ただし、届いた金額をそのまま入れることはありません。

届いた見積もりを査定して、別の担当者が検算し、それから決裁に回すという手順が決まっていました。この手順を省く選択肢は、担当者の側にありません。

システム開発の側にも同じものがあるのかを調べました。IPAが「ソフトウェア開発分析データ集」を公開していて、工数や工期、生産性の目安を業種別に見られます。出典:IPA「ソフトウェア開発分析データ集2022」(2022年公開・収集データ5,546プロジェクト)

ただ、積算基準書と並べると、性質の違いが3つ出てきます。

  • 数字を出しているのは、作る側の会社
  • 参照するかどうかは、発注する側の任意
  • 2022年版を最後に、発行の予定がない

建設のやり方が正しくて、システム開発が間違っているという話ではありません。制度の形が違うだけです。ただ、手元の見積書を前にした発注者にとって、この違いは効いてきます。特にIT業界の移り変わりは激しいため、固定の見積もり方では実情に合わないという特性があるためです。

その金額の根拠が誰の内側にあるのかを確かめて、自社の側でその数字を一度でも検算した人がいるかどうかも確かめてください。どちらも「いない」であれば、いま比べる相手がいない状態にあります。


提案してきた会社が、それを作る会社かを見ます

提案を受けること自体に問題はありません。見る場所は、その提案をした会社が、それを作る会社でもあるかどうかです。

作る会社にとって、契約とは要件どおりのものを納めることです。その立場から要件そのものを疑うと、自分が結んだ契約と食い違います。能力の話でも、誠実さの話でもありません。そういう構造になっているだけです。

以前、複数の拠点を持つ会社の自動化案件に、開発の工程から参加しました。どの業務を自動化するかを決めていたのは、要件定義を担当した別の会社です。私が受け持ったのは、決まったものをどう作るかという部分でした。

依頼した会社の側にあったのは、提案に対する合意です。ここは私が外から見た形であって、提案や合意の場にいたわけではありません。

提案を受けて可否を答えるという形になったとき、比べる対象は、そのとき出ている案とそれをやらない場合の2つに絞られてしまいます。この案件の進め方が悪かったという話ではありません。提案する会社が作る会社でもあるとき、提案の幅はその会社が作れるものに収まります。

出す先が作る側かどうかで、提案に起きることが変わります。

スクロールできます
出す先提案の幅要件を疑えるか
作る側その会社が作れるものに収まる自社の契約と食い違う
作らない側作れるかどうかに縛られない自社の契約と食い違わない

公共工事では、設計と施工を別の会社に出すのが基本でした。まとめて1社に出す方式もあり、そちらは私が担当した経験を持ちません。どちらが正しいという話ではなく、分ける形が制度として存在しているという事実です。

ここまでが、外に出せるものの話です。出せないものが1つだけ残ります。


決めることだけは、外に出せません

外に出せるのは、判断の材料を作るところまでです。決めること自体は出せません。

その仕組みを入れて自社の何が変わるのかを知っているのも、止まったときに何が困るのかを言えるのも、発注する側の人間だけです。そこは誰かに預けても、預けた先が答えを持っていません。見積書を承認する前に、3つだけ確かめてください。

承認前の3つの問い
  • いま検討している仕組みについて、提案を2つ以上比べたか
  • その提案をした会社は、それを作る会社でもあったか
  • その仕組みが止まったとき、何が困るかを自社の言葉で言えるか

2つ目だけは、「はい」と答えた場合に確認が要ります。作る会社が自分で提案をすること自体は、ごく普通の進め方です。ここで問うているのは、その提案のほかに、比べる相手を一度でも作ったかどうかというところになります。

3つのうち1つでも答えられないなら、社内ではこう言えます。「この提案、比べる相手がいない」。私の見立てでは、決裁の場でこの一文がいちばん通ります。


金額を見る前に、比べる相手を作ります

見積書が高いかどうかは、その紙だけでは決まりません。決まるのは、比べる相手があるかどうかです。印を押す前の数分あれば、そこは確かめられます。

いま手元にある提案について、それ以外の案を一度でも見たかどうかを思い出すところから、比べる相手を作るという作業は始まります。思い出せないなら、それが今日の1手です。

比べる案をどこから作ればよいのかが分からないときは、先に自社の詰まっている場所を見るほうが早く進みます。私自身、発注する側にいた頃に効いたのは、金額の交渉ではなく、その前に置いた計算のほうでした。

下のボタンから診断を受けてください。9つの質問に3分で答えると、自社がいまどの工程で止まっているかが出ます。その結果を持って、もう一度この見積書を見てください。


システム開発 見積もり 3社

この記事が気に入ったら
フォローしてね!

役に立ったらシェア!
  • URLをコピーしました!
目次