この記事の要点
- 見積もりの金額は工数と前提条件の組み合わせで決まるため、内訳と前提を先に読みます
- 範囲外とされた作業やリスクの見込みの扱いは、後の追加の費用につながりやすい点です
- 相見積もりは、同じ資料を渡して条件をそろえ、金額だけでなく前提と体制で比べます
システム開発の見積もりを受け取ったら、合計の金額を見る前に、何を前提に、どこまでを含めた金額なのかを読みます。同じシステムを頼んだつもりでも、含まれる作業や前提が違えば、金額は大きく変わるためです。
安く見える見積もりが、実は範囲が狭いだけということもあります。私たちが見積もりを作るときにも、読んでいただきたいと考えている5つの点を順に説明します。
見積もりの金額はどう決まるか
見積もりの金額の多くは、作業の量に単価を掛けて計算されます。作業の量は工数で表され、「何人が何か月(何日)働くか」を単位にした人月・人日がよく使われます。
工数のほかに、ソフトウェアのライセンス、クラウドの利用料、外部のサービスの利用料などが加わることがあります。開発の費用と、使い続けるための費用が分けて書かれているかも見ておきます。
見積もりの金額の組み立て
金額の多くは、作業の量(工数)に単価を掛けて計算されます。開発の費用と、使い続けるための費用が分けて書かれているかも見ておきます
工数の内訳を見る
工数は、工程ごと・機能ごとに分かれていると、中身を確かめやすくなります。「開発一式」とだけ書かれた見積もりでは、何にどれだけかかるのかが分からず、ほかの見積もりとも比べられません。
確かめたいのは、次のような点です。
- 要件定義・設計・開発・テスト・移行など、工程ごとの工数が出ているか
- 画面や機能ごとに、工数が分かれているか
- テスト、データの移行、打ち合わせ、プロジェクトの管理の工数が入っているか
テストや移行の工数が見当たらない場合は、別の項目に含まれているのか、入っていないのかを質問します。後の工程の作業ほど、見積もりの段階で見落とされやすいためです。
前提条件を読む
前提条件とは、見積もりの金額が成り立つための条件です。前提が変わると、金額も変わります。
たとえば、次のようなものが前提として書かれます。
- 発注する側が用意するもの(データ、テストの環境、既存のシステムの資料)
- 確認や回答の期限、打ち合わせの回数
- 利用者の数、データの量、対応する端末やブラウザ
- 既存のシステムや外部のサービスとの連携の方法
前提条件の中に、自社が担う作業が含まれていることがあります。社内でその作業を担えるか、期限に間に合うかを確かめておきます。
範囲外を確かめる
範囲外とは、見積もりの金額に含まれていない作業です。見積もりに書かれていない作業は、含まれていないものとして扱われることが多いため、明記されているかを確かめます。
範囲外になりやすいのは、既存のデータの移行、既存のシステムの側の改修、本番の環境の構築、操作の研修やマニュアルの作成、稼働後の運用です。必要な作業が範囲外になっていれば、別に見積もってもらいます。
リスクの見込みと変更の扱い
見積もりの段階で決まっていないことが多いほど、金額には不確かさが残ります。不確かな部分をどう扱っているかを読みます。
見込みの分を金額に上乗せしている場合も、別の項目に分けている場合もあります。要件が固まっていない部分は概算として扱い、要件定義の後に詳しい見積もりを出し直す、二段階の見積もりにする方法もあります。
あわせて、仕様変更の手順を確かめます。変更を申し出たときに、だれが影響を見積もり、どう合意するかが決まっていると、追加の費用の話がこじれにくくなります。完成に対して払う契約か、作業の期間に対して払う契約かでも、変更の扱いは変わります。契約の形の違いはシステム開発の請負契約と準委任契約は、何が違うかで整理しています。
保守と運用の費用
システムは作って終わりではなく、使い続けるための費用がかかります。開発の見積もりとあわせて、年あたりの費用と、その中身を確かめます。
- 不具合の修正や、ソフトウェアの更新への対応(保守)
- 動いているかの監視、問い合わせへの対応(運用)
- クラウドやライセンスの利用料
- AIを使う場合は、APIの利用料と、精度の見直しの作業
保守契約で何をどこまで対応してもらえるのか、対応の時間帯はいつか、範囲外の作業はどう扱うかも、開発を頼む前に聞いておくと安心です。
相見積もりの比べ方
相見積もりでは、同じ資料を渡して条件をそろえ、金額だけでなく、前提と範囲と体制で比べます。条件がそろっていない見積もりどうしは、金額を並べても比べたことになりません。
条件をそろえるには、目的・範囲・要件をまとめた依頼の文書を用意し、見積もりの形(工程別・機能別の内訳、前提条件、範囲外)も指定します。依頼の文書の書き方はRFP(提案依頼書)の書き方をご覧ください。
| 比べる点 | 確かめること |
|---|---|
| 範囲 | 同じ機能と工程が入っているか。範囲外は何か |
| 前提 | 発注する側が担う作業、データや環境の用意 |
| 工数の内訳 | 工程別・機能別に出ているか。テストと移行の扱い |
| 体制 | だれが担当し、窓口はだれか |
| 作った後 | 保守の範囲と費用、利用料 |
ほかと比べて大きく安い見積もりがあれば、範囲や前提に抜けがないかを、まず質問します。金額の差の理由が説明できるかどうかも、判断の材料になります。
当社のご支援
当社では、プロジェクトや現場に入るFDEの費用を、範囲・体制・期間に合わせてお見積りします。料金の考え方は料金の目安にまとめています。進め方と費用について、まずは30分の無料相談で課題をうかがいますので、お問い合わせからご連絡ください。
- 見積もり
- 相見積もり
- 工数
- システム開発
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。