OUTSOURCING

システム開発の見積もりは、どこを見ればよいか

システム開発の見積もりは、合計の金額より先に、工数の内訳・前提条件・範囲外・リスクの見込み・保守の費用を読むと、中身と比べ方が見えてきます。相見積もりで条件をそろえて比べる方法もあわせて説明します。

この記事の要点

  • 見積もりの金額は工数と前提条件の組み合わせで決まるため、内訳と前提を先に読みます
  • 範囲外とされた作業やリスクの見込みの扱いは、後の追加の費用につながりやすい点です
  • 相見積もりは、同じ資料を渡して条件をそろえ、金額だけでなく前提と体制で比べます

システム開発の見積もりを受け取ったら、合計の金額を見る前に、何を前提に、どこまでを含めた金額なのかを読みます。同じシステムを頼んだつもりでも、含まれる作業や前提が違えば、金額は大きく変わるためです。

安く見える見積もりが、実は範囲が狭いだけということもあります。私たちが見積もりを作るときにも、読んでいただきたいと考えている5つの点を順に説明します。

見積もりの金額はどう決まるか

見積もりの金額の多くは、作業の量に単価を掛けて計算されます。作業の量は工数で表され、「何人が何か月(何日)働くか」を単位にした人月・人日がよく使われます。

工数のほかに、ソフトウェアのライセンス、クラウドの利用料、外部のサービスの利用料などが加わることがあります。開発の費用と、使い続けるための費用が分けて書かれているかも見ておきます。

見積もりの金額の組み立て

見積もりの金額
=
工数人月・人日
単価
ライセンス・利用料など加わることがあります

金額の多くは、作業の量(工数)に単価を掛けて計算されます。開発の費用と、使い続けるための費用が分けて書かれているかも見ておきます

工数の内訳を見る

工数は、工程ごと・機能ごとに分かれていると、中身を確かめやすくなります。「開発一式」とだけ書かれた見積もりでは、何にどれだけかかるのかが分からず、ほかの見積もりとも比べられません。

確かめたいのは、次のような点です。

  • 要件定義・設計・開発・テスト・移行など、工程ごとの工数が出ているか
  • 画面や機能ごとに、工数が分かれているか
  • テスト、データの移行、打ち合わせ、プロジェクトの管理の工数が入っているか

テストや移行の工数が見当たらない場合は、別の項目に含まれているのか、入っていないのかを質問します。後の工程の作業ほど、見積もりの段階で見落とされやすいためです。

前提条件を読む

前提条件とは、見積もりの金額が成り立つための条件です。前提が変わると、金額も変わります。

たとえば、次のようなものが前提として書かれます。

  • 発注する側が用意するもの(データ、テストの環境、既存のシステムの資料)
  • 確認や回答の期限、打ち合わせの回数
  • 利用者の数、データの量、対応する端末やブラウザ
  • 既存のシステムや外部のサービスとの連携の方法

前提条件の中に、自社が担う作業が含まれていることがあります。社内でその作業を担えるか、期限に間に合うかを確かめておきます。

範囲外を確かめる

範囲外とは、見積もりの金額に含まれていない作業です。見積もりに書かれていない作業は、含まれていないものとして扱われることが多いため、明記されているかを確かめます。

範囲外になりやすいのは、既存のデータの移行、既存のシステムの側の改修、本番の環境の構築、操作の研修やマニュアルの作成、稼働後の運用です。必要な作業が範囲外になっていれば、別に見積もってもらいます。

リスクの見込みと変更の扱い

見積もりの段階で決まっていないことが多いほど、金額には不確かさが残ります。不確かな部分をどう扱っているかを読みます。

見込みの分を金額に上乗せしている場合も、別の項目に分けている場合もあります。要件が固まっていない部分は概算として扱い、要件定義の後に詳しい見積もりを出し直す、二段階の見積もりにする方法もあります。

あわせて、仕様変更の手順を確かめます。変更を申し出たときに、だれが影響を見積もり、どう合意するかが決まっていると、追加の費用の話がこじれにくくなります。完成に対して払う契約か、作業の期間に対して払う契約かでも、変更の扱いは変わります。契約の形の違いはシステム開発の請負契約と準委任契約は、何が違うかで整理しています。

保守と運用の費用

システムは作って終わりではなく、使い続けるための費用がかかります。開発の見積もりとあわせて、年あたりの費用と、その中身を確かめます。

  • 不具合の修正や、ソフトウェアの更新への対応(保守)
  • 動いているかの監視、問い合わせへの対応(運用)
  • クラウドやライセンスの利用料
  • AIを使う場合は、APIの利用料と、精度の見直しの作業

保守契約で何をどこまで対応してもらえるのか、対応の時間帯はいつか、範囲外の作業はどう扱うかも、開発を頼む前に聞いておくと安心です。

相見積もりの比べ方

相見積もりでは、同じ資料を渡して条件をそろえ、金額だけでなく、前提と範囲と体制で比べます。条件がそろっていない見積もりどうしは、金額を並べても比べたことになりません。

条件をそろえるには、目的・範囲・要件をまとめた依頼の文書を用意し、見積もりの形(工程別・機能別の内訳、前提条件、範囲外)も指定します。依頼の文書の書き方はRFP(提案依頼書)の書き方をご覧ください。

比べる点確かめること
範囲同じ機能と工程が入っているか。範囲外は何か
前提発注する側が担う作業、データや環境の用意
工数の内訳工程別・機能別に出ているか。テストと移行の扱い
体制だれが担当し、窓口はだれか
作った後保守の範囲と費用、利用料

ほかと比べて大きく安い見積もりがあれば、範囲や前提に抜けがないかを、まず質問します。金額の差の理由が説明できるかどうかも、判断の材料になります。

当社のご支援

当社では、プロジェクトや現場に入るFDEの費用を、範囲・体制・期間に合わせてお見積りします。料金の考え方は料金の目安にまとめています。進め方と費用について、まずは30分の無料相談で課題をうかがいますので、お問い合わせからご連絡ください。

  • 見積もり
  • 相見積もり
  • 工数
  • システム開発

この記事に出てくる用語

この記事を書いた人

石田 誠 フロレンティナ 取締役CTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

開発の発注と契約のコラムを見る コラムの一覧に戻る