システム開発の見積もりの見方と、自社に残る作業と費用

見積書は、金額より先に前提条件を読む

見積金額は前提条件の上に成り立っています。前提が書かれていない見積書は、内訳が読めても、他社の見積もりと同じ土俵で比べられません。

 

同じシステムを作る場合でも、対象の業務をどこまで含めるか、何人で開発するか、期間を何か月取るかで金額は変わります。前提の違う2通の見積書を金額だけで比べると、安いほうは単に「やる作業が少ない見積もり」だった、ということも珍しくありません。

概算見積か確定見積か

見積書は、要件が固まる前に出るものと、固まった後に出るものの2段階に分かれます。呼び名は会社によって違い、前者は「概算」「参考」「初期見積もり」、後者は「確定」「詳細」「本見積もり」といった表記です。大事なのは名前ではなく、その金額が後で動くかどうかです。

 

概算見積は、過去の類似案件などから規模感を出したもので、金額に幅があり、要件が具体化すると動きます。確定見積は、要件定義の成果物をもとに作業を積み上げたもので、前提が変わらない限り金額は動きません。

 

見分けるときは、まず見積書に「概算」「参考」といった記載があるかを見ましょう。ただし見積書の名前は手がかりにすぎないので、決め手になるのは前提条件の欄です。「要件定義完了後に再見積とする」と書かれていれば、その金額は後から変わります。

 

ここで間違いやすいのは、概算見積の金額をそのまま社内の予算として通してしまうことです。要件定義が終わって確定見積が出たときに金額が上がると、決裁者に説明できなくなってしまいます。稟議に出す前に「この金額は確定なのか、要件定義の後に変わるのか」を書面で確認しておきましょう。

前提条件で確認する5項目

前提条件の欄で確認するのは、次の5つです。

 

項目	何が書かれているべきか
対象範囲	どの業務・どの画面・どのデータを対象にするか
開発の人員	何人が、どの役割で入るか
期間	いつからいつまでか。遅れた場合の扱い
稼働環境	どのサーバー・どのブラウザ・どの端末で動かすか
非機能要件	同時に何人が使うか、応答速度、セキュリティ要件、停止できない時間帯

 

このうち確認漏れしやすいのが、最後の非機能要件です。性能やセキュリティの要求は、機能の数と関係なく作業量を押し上げます。100人が同時に使う前提と、5人が使う前提では、画面の数が同じでも中の作りが変わるためです。ここが書かれていない見積書は、後から金額が変わりやすくなります。

「一式」をどう見るか

「開発一式 500万円」のように書かれていると、何が含まれるのかわからないです。

 

一式という書き方そのものが問題なのではありません。小規模な案件では、内訳を細かく出す手間のほうが大きくなることもあります。困るのは、後になって「その作業は一式に入っていません」と言われたときに、反論する材料が手元にないことです。

 

この場合やることは1つで、「一式」について、含まれる作業を箇条書きで出してもらいましょう。口頭で聞くだけではなく、書面に残してもらいます。

 

内訳を求める順番は、金額の大きい項目からです。総額の大半が「一式」で書かれていると、他社の見積書と並べても比べようがありません。項目ごとの金額がわからないため、どちらの会社が何にいくらかけているのかが見えないからです。

見積書の項目が何の費用かを読む

見積書に並ぶ費目は、主に4つに分かれます。工程ごとに発生するもの、工程に紐づかず開発期間中ずっと発生するもの、納品後に発生するもの、人件費ではないものです。金額の決まり方が違うので、確かめ方も変わります。

工程に対応する費用：要件定義費・設計費・開発費・テスト費

システム開発の作業は工程に分かれていて、それぞれが費用の項目になります。

 

• 要件定義費：何を作るかを決める作業。発注者へのヒアリング、現在の業務の洗い出し、要件定義書の作成
• 設計費：決まった要件を、画面・データの持ち方・処理の流れに落とす作業。基本設計と詳細設計に分かれることが多い
• 開発費：設計に沿ってプログラムを書く作業
• テスト費：作ったものが動くかを確かめる作業。単体テスト・結合テスト・総合テストに分かれる

 

発注者が見るのは、この4つが項目として書かれているかどうかです。開発費だけが大きく、要件定義費とテスト費が見当たらない見積書があります。この場合、その作業をやらないのか、それとも開発費に含めているのかが読み取れません。どちらなのかを聞いてください。

 

見積書によっては、デザイン費と導入・移行費が独立した項目になっています。デザイン費は画面の見た目を作る費用、導入・移行費は完成したシステムを本番環境に載せて動かし始める費用です。どちらも設計費や開発費に含めてしまう会社があるので、項目が見当たらないときは、含まれているのかどうかを聞きましょう。

工程に紐づかない費用：プロジェクト管理費

進捗の管理や課題の管理、打ち合わせの準備と議事録、発注者との日程調整にかかる費用です。特定の工程ではなく、開発が続いている間ずっと発生するため、期間に比例します。

 

プロジェクト管理費の項目がない見積書は、その分だけ安く見えます。ただし、管理の仕事そのものがなくなるわけではありません。開発費に含めているか、そもそも管理に人を割いていないかのどちらかです。後者だと、進捗の報告が来ない、課題を出しても放置される、という形で、開発が始まってから表面化します。

保守・運用費：納品後にベンダーへ払う費用

納品した後に、不具合の修正、問い合わせへの回答、OSやミドルウェアの更新に合わせたシステムの手直しをしてもらうための費用です。開発費とは別の契約になることが多く、月額で書かれます。

 

発注者が見るのは、月額の金額が書かれているか、それとも「別途ご相談」で止まっているかです。止まっている場合は、年間でいくらかかるのかが読めないまま発注することになります。

 

もう1つ確認するのは、何が保守に含まれるかの線引きです。不具合の修正は含まれるが、機能の追加は含まれないという分け方が一般的で、その境目がどこかを聞いておきます。あわせて、納品後の一定期間は無償で不具合に対応してもらえるのか、その期間はいつからいつまでかも確認しておくと、保守費がどこから発生するのかがわかります。

工数では決まらない費用：ライセンス費・クラウド費・機器の購入費

ソフトウェアのライセンスやクラウドサービスの利用料、必要な機器の購入費です。これらは人月では決まらず、利用者の人数・台数・使った量で決まります。

 

発注者が見るのは、これらが見積書に入っているか、それとも発注者側で別に契約するのかです。「お客様手配」と書かれていたら、その金額は見積もりの総額に入っていません。総額を比べるときは、この分を足してから比べましょう。

金額の妥当性は「工数×単価」と工程ごとの配分で見る

見積金額の中心は人件費で、工数（人月）と単価の掛け算で決まります。ライセンス費やクラウド費のように工数で決まらない項目には、前述のとおり別の見方が必要です。そして、総額が同じでも、どの工程にいくら配分されているかで、後に起きることが変わります。

 

ここでは、相場と比べるのではなく、見積書1通の中で辻褄が合っているかを確かめます。確かめられることは2つです。1つは、各項目の金額が「工数×単価」の計算と合っているか、もう1つは、必要な工程が項目として書かれているかです。どちらも手元の見積書だけでできます。

1人月はどれくらいの作業量か

1人月は、1人が1か月働く作業量を表す単位です。1か月の営業日を20日として計算されることが多く、その場合の1人月は20人日にあたります。「3人月」と書かれていても、1人が3か月かけるのか、2人が1.5か月なのか、3人が1か月なのかまではわかりません。金額は同じでも、進み方は変わります。

 

ここで発注者が見るのは、人月の合計と期間が噛み合っているかということです。たとえば6人月の作業を2か月で終える見積書は、3人が同時に動く前提で組まれています。ただし、人数を増やせばそのぶん期間が短くなるとは限りません。人が増えるほど、引き継ぎや認識合わせに時間を取られるためです。

 

短い期間に人数を詰め込んだ見積書では、並行して動く人数分の引き継ぎと認識合わせが工数に入っているか、その人数を本当に確保できるのかを聞いておきましょう。3人が並行して進めば確認の依頼も同時に来るので、自社の担当者が答えられるかも先に考えておきます。

単価の差は何の差か

単価を分けるのは、主に役割（プロジェクトマネージャー・設計担当・開発担当・テスト担当）と、担当者の経験年数です。自社の社員か、協力会社の要員かでも変わります。

 

単価が1種類しか書かれていないからといって、誰がやっても同じ金額とは限りません。役割ごとの内訳を出さず、平均の単価でまとめていることが多いためです。ただし、役割を問わず本当に一律の単価にしている会社もあるので、どちらなのかは聞いて確かめます。

 

ここで発注者ができる確認は、電卓を使った確認です。各項目の「単価×工数＝金額」を計算して、書かれている金額と合うかどうかを確かめてください。合わない項目があれば、値引きや端数の調整、別の費用の混入、人日と人月の単位の混在といった理由が考えられます。理由を聞けば、その項目の中身が見えます。

工数を発注者側で概算して、桁が合うかを見る

ベンダーが出した工数が正確かどうかを、発注者が検算するのは難しいです。ただし、桁が合っているかどうかなら確かめられます。手順は3つです。

 

1. 作ってほしい画面（または帳票）の数を数える
2. 1画面あたり何日かかる想定かをベンダーに聞く
3. 掛け算して、見積書の開発工数と比べる

 

桁が違っていたら、画面の数え方が違うか、1画面あたりの作りの重さについて認識がずれています。どこがずれているのかを聞くと、そのずれが何なのかがわかります。

 

この作業の目的は、金額を下げることではありません。発注者と開発会社が、同じものを想像しているかどうかを確かめることが目的です。ここがずれたまま契約すると、完成したものを見て「思っていたのと違う」となってしまいます。

要件定義・テスト・プロジェクト管理が書き出されているか

工程ごとの配分は、1通の見積書だけを見て比率で判定することはできません。適正な比率は作るシステムによって変わり、何割ならよいという数字が置けないからです。手元の1通で確かめられるのは、その工程が項目として書かれているかと、その項目の中身をベンダーが説明できるかどうかです。

 

要件定義の項目がない見積書は、何を作るかがすでに決まっている前提で組まれています。まだ決まっていないなら、後から要件定義の費用が追加になります。

 

テストの項目がない場合、どこまでテストするかが決まっていません。プログラム単位で動作を確かめるだけなのか、業務を通した確認まで含むのかを聞きましょう。

 

プロジェクト管理の項目がない場合は前述のとおり、開発費に含めているか、そもそも管理に人を割いていないかのどちらかです。

 

要件定義・テスト・プロジェクト管理の3つが項目として書かれていて、それぞれ何をするのかをベンダーが説明できる。ここまで確認できれば、どこかの工程に金額が偏っていても、なぜ偏っているのかを聞き出せます。

 

同じ要件で複数社から見積もりを取っているなら、比率そのものを比べられます。工程ごとの金額を社ごとに並べてみてください。総額が近くても、要件定義に厚みを置く会社と、開発に寄せる会社では配分の形が違います。

 

その差は値付けの差ではなく、どこに手間がかかると見ているかの差です。極端に違う工程があれば、そこが各社の見立ての分かれ目なので、その工程について各社に理由を聞きましょう。

発注者側の負担になる、見積書に含まれない4つの作業と費用

ここからは、見積書に書かれていないものについてです。見積書は「システムを作る作業」の見積もりであって、「業務で使い始めて、使い続けるまで」の見積もりではありません。見積書に書かれていない分は、開発会社に払う金額が増えるのではなく、発注者側の担当者が動く作業と、開発会社以外へ払う費用になります。

 

これは、開発会社が隠しているわけではありません。開発会社が見積もれるのは、自社が手を動かす作業です。発注者側でしか判断できない作業（現場との打ち合わせ、既存データの中身の判断）は金額を出しようがないので、見積もりには書かれません。

 

以下の4つは、見積書に項目がなくても発注者側に発生します。

1：既存データの整備とデータ移行

今使っているExcelや旧システムのデータを、新しいシステムに入れる作業です。

 

移行プログラムを作る費用は、見積書に入っていることがあります。入っていないことが多いのは、その前段にある「データを整える作業」のほうです。

 

会社名の表記を統一する、重複した顧客を1件にまとめる、必須項目が空になっているレコードをどう扱うか決める。こうした判断は、そのデータを使ってきた現場の担当者にしかできません。つまりこれは発注者側の作業になります。何人が何日かけるのかを、先に見積もっておきましょう。

 

発注者が確認しておくことは、移行の対象は何件あるか、本番前に何回リハーサルするか、移行できなかったデータをどう扱うかです。

2：利用者への操作研修とマニュアル

作ったシステムを、現場が使えるようにする作業です。

 

見積書に「操作説明会 1回」と入っていることがあります。ただし拠点が複数ある場合や、交代勤務で全員が同じ時間に集まれない場合は、1回では足りません。足りない分は、回数を追加して開発会社に依頼するか、自社の担当者が代わりに説明することになります。

 

マニュアルも分けて考えます。開発会社が作るのは、操作手順の説明書です。「自社の業務のこの場面で、この画面をこう使う」という手順書は、自社で作ります。

 

発注者が確認しておくことは、説明会が何回・何時間か、資料は誰が作るか、後から見返せる動画が含まれるかです。

3：受入テスト（UAT）の準備と実施

納品を受ける前に、発注者側が「発注したとおりに動くか」を確かめるテストです。

 

開発会社が行うテストとは目的が違います。開発会社が見るのは、仕様書のとおりに動くかどうかです。一方、発注者が見るのは、自社の業務が回るかどうかです。

 

見積書に「受入テスト支援」という項目が入っていても、テストそのものは発注者が行います。テストの項目を作り、実際に操作し、結果を記録する作業を行います。

 

ここで詰まる発注者が多いのは、担当者が普段の仕事をこなしながらテストをするからです。誰が何日をテストに使うのかを先に決めておかないと、予定の期間では終わりません。テストが終わらなければ検収もできず、本番で使い始める日が後ろにずれます。

 

発注者が確認しておくことは4つ。受入テストの期間は何日取られているか、テスト項目は誰が作るか、見つかった不具合を修正する日数が計画に入っているか、修正後に再テストする日数も入っているかです。

4：本番環境のクラウド費用

システムを動かし続けるための、サーバーやデータベースの利用料です。AWSやAzureのようなクラウドを使う場合、使った量に応じて毎月請求されます。

 

見積書にクラウド費の項目があっても、開発中に使う分しか含んでいないことがあります。その項目が本番稼働後の分まで含んでいるのかを、先に確かめてください。

 

ここで混同しやすいのが、先に説明した保守費との違いです。保守費は開発会社に払うお金で、クラウド費用はクラウド事業者に払うお金です。支払先も、金額の決まり方も違います。保守契約を結んだのだから使っている間の費用も込みだ、と読んでしまうと、稼働後に想定していない請求が来ます。

 

もう1つ注意したいのが、システムによっては、開発中と本番稼働後で金額が違う点です。開発中は小さな構成で動かすため安く、本番では利用者の数に応じて大きくなります。

 

発注者が確認しておくことは、本番稼働後の月額はいくらの想定か、その想定は何人が使う前提か、クラウドの契約は開発会社と自社のどちらの名義にするかです。

見積書を読んだ結果を、ベンダーへの質問に変える

見積書を読むだけで終わってはいけません。書かれていないのは、その作業をやらないからなのか、他の項目に含んでいるからなのか、発注者側でやる想定だからなのか。これは、聞かないとわかりません。

 

そして、聞いた答えは書面に残します。口頭のやり取りだけだと、後で認識が食い違ったときに困ります。見積書の前提条件の欄に追記してもらうか、打ち合わせの議事録に残してもらいましょう。

前提条件と作業範囲について聞くこと

• この金額は確定でしょうか。要件定義の後に変わる可能性はありますか
• 「一式」と書かれた項目に含まれる作業を、具体的に教えてください
• 同時に何人が使う前提で作りますか

 

3つ目は非機能要件の確認です。ここが曖昧なまま進むと、「動くけれど遅い」ということになってしまい、完成後に問題が出ます。

工数の根拠について聞くこと

• この工数は、何を単位に積み上げたものですか（画面数・機能数・過去の類似案件のいずれか）
• 主要な画面1つあたりに見ている日数を教えてください
• 単価は役割ごとに分かれていますか。それとも平均の単価ですか

 

工数の根拠を説明できる会社と、説明できない会社があります。この差は、金額の大小よりも後々まで響きます。根拠を持っている会社は、仕様が変わったときに「その変更なら何人日増えます」と数字で答えられるからです。

 

根拠が出てこない会社だと、追加費用を提示されても、それが妥当かどうかを確かめる手がかりがありません。

見積もりの範囲外を確定させる聞き方

聞き方を変えると、出てくる答えが変わります。「データ移行は含まれていますか」と聞くと、答えは「はい」か「いいえ」で終わります。こちらが思いついた項目しか確認できません。

 

代わりに「この見積もりに含まれていない作業を教えてください」と聞きましょう。相手に列挙してもらう形にすると、こちらが想定していなかった項目が出てきます。そのうえで、既存データの整備とデータ移行、操作研修、受入テスト、本番環境のクラウド費用の4つを名指しで確認してください。

 

出てきた項目は、金額が付いていなくてもリストにして、誰がやるのかを決めておきます。ここを決めておけば、開発が始まってから「そちらでやってもらえると思っていた」というやり取りを減らせます。

 

決裁者に持っていくのは、書面で確認した前提条件、ベンダーが説明した工数の根拠、今作ったリストの3つです。これが揃えば、「なぜこの金額なのか」と「この金額に入っていないものは何か」を、自分の言葉で説明できます。

まとめ

見積書が届いたら、総額を見て判断する前に、前提条件と「入っていないもの」から確認してみてください。書かれていることは読めばわかりますが、書かれていないことは、こちらから聞かないと出てきません。

 

聞いた内容は、口頭で終わらせずに書面へ残しておきましょう。後になって追加費用の話が出たとき、困ってしまいます。前提条件と書かれていない作業まで確かめられれば、見積書を金額の大小ではなく、何をどこまでやる約束なのかで判断できます。