システム開発の見積もりって、どうすればいいの？
見積もりを出すタイミングはいつ？
そもそも見積もりのやり方がわからない？
失敗したらどうしよう・・・何に気をつければいいの？
プロジェクトが失敗する原因は、見積もりミスによるものが多いと思います。
お客様から受注を得るために競合他社より安く見積もりを出したいところですが、しっかり見積もりすることが最終的にお客様にも迷惑をかけません。
そのためには、お客様が納得できる見積もりを提示する必要があります。曖昧な見積もりでは信用されません。運よく受注できたとしても困難なプロジェクトになる可能性が高くなるでしょう。
お客様に根拠ある見積もりを提示できるように、システム開発の見積もりについて、プロジェクトマネージャーの視点で見積方法やポイントをわかりやすく解説します。
なぜ、見積もりを失敗するのか？ 失敗する5つの要因
見積もりを失敗する要因はいくつかあると思います。
どのような要因があるでしょうか？ 思い当たるものが無いか見ていきましょう。
何を開発するか明確でない時期に見積もる
お客様が何を開発したいのか、機能要件がはっきりしないと何を開発していいかわかりません。そのため見積もり根拠が曖昧になって、的外れな見積もりとなります。
開発内容が不明確な時期は、前提条件や想定した機能要件と合わせて概算工数（参考価格）を提示し、開発内容が明確になってきてから正式な見積もりを出すようにしましょう。
お客様の予算に合わせた見積もりを出してしまう
お客様の予算を超えるような見積もりを出しても受注することは難しいでしょう。営業からの強い要求で、どうしても予算に合わせた見積もりを出さないといけない場面もあるかもしれません。
しかし、無理な見積もりは、予算が足りなくて機能不足なシステムができてしまう、単価の安いSEを雇うことで品質が保てない、工期も延伸してしまう等、最終的にお客様に迷惑をかけることになります。決してお客様の予算に合わせた見積もりは出さず、開発要件に見合った見積もりを出しましょう。
要件・仕様が変化しても見積もりを出し直さない
システム開発のプロジェクトは生き物です。プロジェクトを進めていくと、常にお客様の要求・仕様は変化していきます。
特にプロジェクト当初に提示する見積もりは、要件も不明確な部分があるために見積もりが正確ではないと思います。そのため、機能要件や仕様の変化に合わせて見積もりを出し直しましょう。
いきなり見積もりを出し直してもお客様から了承いただくことは難しいと思います。なので、機能要件や仕様が変わった場合は再度見積もりを提示して開発するかどうか責任者同士で合意して進めることを、プロジェクト計画書に明記しましょう。
仕様凍結をせずにプロジェクトを進める
お客様はいつまでも機能要件の変更を要求してきます。それではいつまで経っても仕様は固まりません。仕様変更が発生する都度、システム開発が後戻りして進まず、品質も悪化していきます。
そうならないように、あらかじめ仕様凍結の時期をプロジェクト計画書に明確にし、プロジェクト開始前にお客様と合意しましょう。
仕様凍結は要件定義や概要設計（UI設計）までとし、それ以降はしっかり変更管理をしましょう。開発工数に影響する場合は見積もりを再提示しましょう。
変更管理について知りたい方はこちらもお読みください。
無理なスケジュール（工期）を見積もる
見積もった工数を無視して、お客様が要望する本稼働日（リリース日）に合わせて無理なスケジュールを見積もると、システム開発の工程が進むほど苦しくなってきます。工数に見合った開発スケジュール（工期）を見積もりましょう。
どうしてもスケジュールがお客様の要望通りにいかない場合は、開発する機能を分割して段階的にリリースできないか検討しましょう。
初回リリースは業務影響が大きいものに絞ることで工数を減らし、スケジュールの短期化を検討しましょう。
見積もりを出すタイミング
見積もりは、どのタイミングで出すのが良いのでしょうか？
見積もり失敗の要因から見て、次の3つのタイミングで見積もりを出す必要があります。
提案書を提示する時
提案書を作成する時期はお客様の要件が明確になっていない場合が多いため、どうしても見積もりが大雑把になります。
過去の類似したプロジェクトを参考にして開発工数や工期を割り出したり（類推見積もり）、社内の有識者に意見を伺って参考価格や超概算工数を提示します。
プロジェクト計画書を提示する時
プロジェクト運営は、プロジェクト計画書を作成することから始まります。作成したプロジェクト計画書から見積もりを作成します。
プロジェクト計画書には、システム化の目的や背景、開発対象範囲、前提条件、制約条件など、見積もりのベースとなる根拠が書かれています。
プロジェクト計画書があれば、お客様にとっても納得感のある見積もりを提示することができます。どうしても要件に曖昧な部分が残る場合は、前提条件付きで見積もりを提示しましょう。
要件定義が完了した時
要件定義を進めることでお客様の要求が明確になり、必要な機能要件を洗い出すことができます。この時点で初めて正確な見積もりを作成できます。
そのため、お客様とプロジェクト計画時に『要件定義（もしくは概要設計・UI設計）が完了した時点で再度見積もりを提示して契約する』ことを事前に合意することが重要です。
また、見積もりの失敗要因にもあるように、機能要件や仕様の変更をしっかり管理して、変化があればお客様と検討するフローも事前に協議して合意しておきましょう。
こちらで変更管理の方法を解説していますので、あわせてお読みください。
コストに影響する環境が変化した時
機能要件や仕様変更だけではなく、コストに影響する環境が変化する場合も要注意です。例えば、予定していたクラウドサービス会社の課金体系が見直された、利用するソフトウェアのライセンス使用料が値上げされた、当初お客様が実施する予定だったデータ移行作業を依頼された、などです。
他にも色々あると思いますが、コストに影響する環境が変化した時は、追加コストが必要かどうか再度見積もりしましょう。
見積もりの手順と方法
見積もりは次の手順で行います。
規模が小さい場合は「①規模の見積もり」は飛ばしてもいいでしょう。
- 規模の見積もり
- 開発工数の見積もり
- コンピュータ資源の見積もり
- スケジュール（工期）の見積もり
- コストの見積もり
①規模の見積もり
まず、システムの開発規模を見積もります。
システムの規模は以下の情報からプロジェクトに適切なものを選択します。
- システム機能数
- 画面数、帳票数
- 作成する成果物の予定ページ数
- プログラム本数、ステップ数
- データ項目数、テーブル数
- ファンクションポイント
新規開発の場合は、お客様にヒアリングして情報を洗い出します。
システムリプレースの場合は、ヒアリング以外にも現行システムのマニュアルや仕様書等から情報を洗い出しても良いでしょう。
また、マニュアル作成やデータ移行作業、ユーザー教育など、システム開発以外の支援も必要かどうか、お客様の意向を確認しましょう。
②開発工数の見積もり
次に、見積もった規模から開発工数を見積もります。
開発工数は、次の４つの視点で見積もります。
- システム開発の作業工数
- プロジェクトの管理工数（プロジェクトの進行管理の工数）
- 初期導入期間のサポート工数
- その他の工数
それぞれをもう少し詳しく説明します。
システム開発の作業工数
見積もった規模（システム機能数、画面数・帳票数、データ項目数など）をベースに、過去の実績から算出した単位当たりの工数や係数を掛け算して割り出します。
例えば、過去の実績から1画面当たり概ね1人月かかる※として、難易度が低い参照系画面は0.5人月、難易度が高い複数テーブルを更新する画面は1.5人月という具合に標準工数を決めておきます。これに規模で見積もった画面数を掛け算することで作業工数を計算します。
このようにプロジェクトの特性や保有している過去の実績値を考慮して、規模から見積もることで精度が高い作業工数を算出できます。ただし、過去のプロジェクトで積み上げた実績が少ないと精度が落ちるため、プロジェクト完了後の情報収集も見積もりには重要です。
※この1人月には設計、プログラム開発、テスト工数が含まれている工数です
要件定義後に要件が変わることは容易に想像できます。仕様変更による影響が少ない場合でも工数増加は避けられません。だからと言ってお客様に予算の増額をお願いしても簡単には承認いただけないと思います。
そのため、一般的には予備費（コンティンジェンシー予備やマネジメント予備）を確保しておくことで回避することができます。概ね、予備費は開発費用の10％程度が良いとされています。
プロジェクトの管理工数（プロジェクトの進行管理の工数）
これは、プロジェクトを推進していく上で発生する工数で、システム開発工数とは別のものです。プロジェクトマネージャーやリーダー、事務局が活動するための工数にあたります。
例えば、日々の進捗管理や品質管理、各種ミーティング、それらに付随する資料作成がそれに該当します。
この工数はプロジェクトの規模や体制によって関わる人数が変わるため、個々のプロジェクトに合わせて工数を見積もることになります。ざっくり言うと、マネジメントに関わる人数と工期の掛け算で割り出すことが多いと思います。
初期導入期間のサポート工数
開発したシステムの初期導入時（リリース後）にサポートが必要な場合は工数を見積もります。サポートが必要かどうかはお客様が決めることですので、見積もり前に忘れずに確認しましょう。
工数は過去事例を参考に見積もることが多いと思いますが、こちらもざっくり言えば、サポートに関わる人数とサポート期間の掛け算で割り出すことになります。
その他の工数
その他の工数として下記の見積もりが必要であれば追加します。
- システム開発で利用するテスト環境を構築する工数
- パッケージやアプリケーションの初期セットアップ工数
- ハードウェアの初期セットアップ工数
- 既存システムから新システムへのデータ移行作業の工数
③コンピュータ資源の見積もり
ハードウェアに関するコンピュータ資源の見積もりも忘れずに検討しましょう。
運用開始していくとデータ量の増加とシステム利用ユーザーの増加に伴って、システムのパフォーマンスが落ちることがあります。見積もり段階で、お客様の運用後のイメージをしっかりヒアリングし、要件に見合ったコンピュータ資源を見積もる必要があります。
運用開始後の性能、利用ユーザー数、データ量、可用性などを検討しましょう。
キャパシティに関する項目
CPU能力、メモリー容量、ディスク容量、ネットワーク容量（速度、回線数）、PC能力（CPU、メモリー、HDD）、PC台数
パフォーマンスに関する項目
オンライントランザクション応答時間、バッチ処理時間、ファイル転送時間、ターンアラウンドタイム
利用ユーザー数
④スケジュール（工期）の見積もり
開発工数の見積もりが出れば、それをベースにスケジュール（工期）を見積もります。各工程の工数を工程比率から割り出し、その工数から必要な要員数と期間を算出します。
これは、要員計画と合わせて検討する必要があります。こちらで要員計画の方法について解説していますので、あわせてお読みください。過去のプロジェクトで利用した工程比率を参考に記載しています。
また、スケジュールを検討する上で、下記の点についても考慮して見積もりましょう。
作業順の検討
それぞれの作業の順番を検討しましょう。作業の先行、後続、並行を検討して、負荷の高い作業は平準化を検討しましょう。
マイルストーンの確認
プロジェクトの重要なマイルストーンを洗い出し、各作業との関連に問題がないか確認しましょう。
- 契約日
- 各フェーズの完了日
- 運用を見据えたキャパシティ検証時期
- ソフトウェア、ハードウェア導入時期（開発・テスト・本番）
- 納品成果物の提出日
- お客様の検収日
⑤コストの見積もり
最後にコストを見積もります。ここで言う「コスト」とは、実際にシステム開発で発生するコストを指しており、開発メンバーの要員費用だけでなく、そのメンバーが利用するパソコンや交通費、電話代、事務所費用等、プロジェクト運営で必要となるコスト全体を見積もります。
見積もったコストが、お客様に提示するプロジェクト全体の見積もりと比較して妥当かどうか最後に判断します。つまり、適正な利益や予備費が確保された見積もりになっているか確認しましょう。
開発要員のコスト
各工程で必要となる要員数と必要なスキルを考慮して、妥当なメンバーをアサインするためのコストを見積もります。
設備を購入するコスト
コンピュータ資源の見積もりから必要となるハードウェア、ネットワーク関連の購入（レンタル）、ツールやミドルウェア等の購入費用や利用料を見積もります。
その他のコスト
事務所賃借代（開発場所等）、什器備品代（机、椅子、消耗品等）、コピー代（コピー機レンタル）、電話代、交通費（お客様事務所での打ち合わせ等）、研修費（開発環境の研修等）を見積もります。
見積もりで失敗しないために
冒頭に記述した見積もりの失敗要因は、システムエンジニアの方なら誰しも思い当たることではないでしょうか。
見積もりの失敗を知ることで、正しい見積もりを作成することができます。何よりも、見積もり根拠を明確にすることで、お客様にとっても納得できる見積もりを作成することができます。
曖昧な見積もりでは信用されません。運よく受注できたとしても困難なプロジェクトになる可能性が高くなるでしょう。
繰り返しになりますが、システム化の目的や背景、開発対象範囲、前提条件、制約条件など、見積もりのベースとなる根拠をプロジェクト計画書にまとめ、それをベースに見積もりすることがプロジェクトを成功に導く近道だと思います。是非とも、プロジェクト計画書をまとめ上げて、お客様に納得いただける見積もりを作成しましょう。
もしプロジェクトマネジメントの経験が浅く不安がある方は、プロジェクトマネジメントについて解説していますので、こちらもあわせてお読みください。少しでもプロジェクト活動のヒントになれば幸いです。
