システム開発において、「見積もり」は単なる金額の比較ではありません。その精度次第で、プロジェクトのスケジュール・品質・コストすべてが大きく左右される、極めて重要な工程です。
「なんとなく安い方を選んで失敗した…」
「後から追加費用が発生して予算オーバーになった…」
――そんな事態を未然に防ぐために、発注前に知っておくべき”落とし穴”と”防ぎ方”を解説するウェビナーを開催いたしました。
アーカイブ動画の視聴はこちら＞＞
目次
システム開発の見積もりの仕組み
まずは典型的な見積もりでの失敗事例をご紹介するとともに、いくつかの代表的な見積もり手法を解説します。
よくある見積もり失敗事例
典型的な見積もりでの失敗例が「開発のフェーズや期待値に合わない見積もり方法を取ってしまうケース」です。
例えば、不確実性が大きいプロダクトにもかかわらず、具体的な要件や仕様が定まっていることを前提とした見積もりを依頼すると、見積もりと実際の開発が大きく乖離してしまいます。
前提が曖昧な状態ではベンダーごとに解釈が異なり、結果としてベンダーごとに内容の異なる見積もりが並ぶことになります。いわゆるアップル・トゥ・アップルの比較ができず、結果的に発注側にとって価値のある判断材料にはなりません。
さらに、見積もりの評価ポイントが不明確なまま、総額や人月単価だけで比較してしまうことも問題です。単価の安さだけを重視すると、そこから得られるアウトプットの質やリスク管理といった本質的な部分を見落とし、判断を誤る可能性があります。
見積もり手法の使い分け
非常に多くの種類がある見積もり手法ですが、必ずしもすべての手法について細かく理解する必要はなく、大切なのは、自社の状況やフェーズに合った見積もり手法と、その中間成果物が何かを理解しておくことです。
今回はウォーターフォール型とアジャイル型に分けて、代表的な見積もり手法とその特徴をご紹介します。
ファンクションポイント法（ウォーターフォール開発向け）
ウォーターフォール開発で、ある程度要件や仕様が曖昧な段階での見積もり依頼をする際によく使われるのが「ファンクションポイント法」です。中でも広く利用されているのが、国際標準（ISO）や日本工業規格（JIS）にも採用されている「IFPUG法」です。
ファンクションポイント法で注目すべきポイントは、以下の3つの中間成果物です。
- ファンクションポイント（機能の複雑さを定量化）
- ファンクションポイント生産性（1ポイントあたりにかかる時間）
- 人月単価
これらを比較することで、各社の生産性や技術力を定量的に評価することができます。たとえば、人月単価は安くても生産性が低ければ、最終的な金額に大きな差は出ないこともあります。逆に、生産性の高いベンダーであれば、総額は同じでもより高い技術力を期待できる可能性がある、といった比較が可能になります。
属人的な判断を避け、組織の能力に基づいた比較ができる点が、ファンクションポイント法の大きな特徴です。
ウォーターフォール開発で用いられる見積もり手法にはもうひとつボトムアップ見積もりというものもあり、こちらはより具体的に仕様が確定しているプロジェクトに向いています。
Tシャツサイズ見積もり（アジャイル開発向け）
アジャイル開発、特にスクラムでよく使われるのが「Tシャツサイズ見積もり」です。名前の通り、XS・S・M・L・XLといったTシャツのサイズで、機能の相対的な難易度をシンプルに分類するユニークな見積もり手法です。
同じくアジャイル開発で使われるストーリーポイント見積もりやプラニングポーカーよりも、さらに不確実性の高いユーザーストーリーに対して使われる見積もりです。
また、アジャイルのイテレーションの中で実績と照らし合わせて再評価できるため、より精度の高い見積もりへとブラッシュアップしていけるのも大きな特徴です。
ウェビナーでは、家計簿アプリを想定したケーススタディを通じて詳しい説明が行われました。
＞＞アーカイブ動画のご視聴はこちら
見積もりの3つの落とし穴と対策
続いて、見積もりを取得する際に陥りやすい落とし穴を解説します。
落とし穴1：見落としがちな項目は後のコスト増額リスク
最初の落とし穴は、見落としがちな項目についてです。
見積もりの包括性、つまり、提示された見積もりがプロジェクトの全範囲をカバーしているかどうかは重要なポイントになります。
精緻な見積もりを出すことができる限界は、通常1-2ヶ月先までの開発についてです。例えばウォーターフォール開発において、まだ要件が定まっていない段階で正確な見積もりを取ろうとしても、せいぜい要件定義の段階までしか算出することはできません。
しかし、当たり前ですが要件定義の予算だけでは、きちんとしたプロダクトをユーザーに届けることはできません。
したがって、開発、テスト、運用保守といった、プロダクトをユーザーに届けるために必要な全てのフェーズを、概算であっても見積もりに含めることが非常に重要です。これにはある程度の慣れや経験が必要になります。
特に「運用保守」という言葉は幅広い意味を持ちます。例えば、「半年間で開発した機能を、その後は一切変更せず、正しく動くことだけを保証する」のか、それとも「ユーザーからのフィードバックを受けて、継続的に機能を追加・改善していく（エンハンス）体制まで含める」のかによって、費用は大きく変動します。
そのため、ユーザーにプロダクトを届けるにあたり、どのような体制でどこまでをゴールとするのかをベンダーと明確に合意し、包括的な見積もりを作成してもらうことが不可欠です。
また、概算見積もりで重要なのが、どれくらいの振れ幅があるのかを発注側とベンダー側で合意しておくことです。多くのベンダーはPMBOKに基づき、マイナス25%からプラス50%の誤差を許容範囲としてプロジェクトを進めています。
提案時にこれらの前提条件が明確に説明されない場合は、どの程度の誤差が含まれるのかをしっかりと確認するようにしましょう。
落とし穴2：変化が激しい市場と相場観
2つ目の落とし穴は「変化が激しい市場と相場観」です。
フリーランスエンジニアの相場はこの5〜10年で大きく変動しています。そのため、人月単価における「高い」「安い」を判断する際には、最新の市場感を把握しておくことが重要です。
法人としてエンジニアをチームで契約する際には、チームとしての品質管理や付加価値がつくため、人月単価が高くなることが一般的です。
デザイナーの単価もこの10年で大きく高騰しています。そもそもデザイナーという職種は非常に広義であり、提供される価値が人によって大きく異なります。
例えば、ワイヤーフレームをもとにグラフィックデザインを行う「UIデザイナー」もいれば、業務ヒアリングからファシリテーション、ユーザー体験（UX）の設計、情報整理、ワイヤーフレーム作成、そして最終的なグラフィックデザインまで一貫して担当する「UX/UIデザイナー」もいます。
相場観をきちんと認識しておくことは、見積もりの比較に役に立ちます。
落とし穴3：かかるコストは発注額だけじゃない
3つ目の落とし穴は、「かかるコストは見積もり金額だけではない」という点です。
デジタルプロダクトの制作は、クライアントとベンダーが協力して進めるものです。そのため発注側にも様々なタスクが発生します。
ベンダーからの見積もり提案によって、求められるタスクの範囲や、それに対応するための人材確保や人件費も変わってくるというのは重要なチェックポイントです。
どのようなタスクが発生するかはプロジェクトに依存する部分もありますが、一般的には以下のようなものがクライアント側のタスクになりがちです。
- 要件・機能イメージ策定/ヒアリング
- 市場リサーチ
- レビュー・決議
- テスト
- 課題確認・決議
例えば、アジャイル開発では、最初のキックオフやプロダクトの方向性を決めるタスクが特に重要になります。
ざっくりとした目安として、ウォーターフォール開発の場合、ベンダー工程で発生する工数の5〜10%がクライアント側のレビュー工数としてかかると見ていいでしょう。
また、アジャイル・スクラム開発の場合、プロダクトオーナーとして5〜10人規模のチームを持つ場合は、0.3〜0.5人月程度を専任プロダクトオーナーとして人材調達する必要があると考えてください。
まとめ：見積もりチェックポイント
まとめとして、見積もりにおけるチェックポイントをお伝えします。
中間成果物＝技術力＋生産性＋人月単価
ベンダーを比較検討する際には、各見積もり手法で出てくる中間成果物を確認することがポイントだとご説明しました。
中間成果物とは、シンプルにいうと「技術力」「生産性」「人月単価」の3つからなり、これらを掛け合わせたものが最終的な見積もり金額となります。
今回紹介した見積もり手法に照らし合わせると、以下のようになります。
- ファンクションポイント法:
- 技術力：ファンクションポイント
- 生産性：ファンクションポイント生産性
- 人月単価：人月単価
- Tシャツサイズ見積もり:
- 技術力：ストーリーポイント
- 生産性：ストーリーポイントあたりのスケール
- 人月単価：人月単価
適切な見積もり依頼と開発手法の選択
開発に求めることや優先度、さらには開発ワークフローや契約形態によっても、適切な見積もりの手法は異なってきます。
ウォーターフォール開発が向いているケースは、以下のような場合です。
- 業務フローに明確な価値があるプロダクト: 例えるなら基幹システムのように、「どんなインプットを与えれば、どんなアウトプットが得られるか」が明確で、完成すれば確実に役に立つと確信できるプロダクト。
- 請負契約を希望し、デリバリーの優先度が高い場合: 「何月何日にこの機能が確実に提供されること」が最重要視される場合。
この場合、ファンクションポイント法やCOSMIC法といった見積もり手法が適しています。
一方で、アジャイル開発が向いているケースは、以下のような場合です。
- プロダクトの価値が未検証の状態: そもそもその業務フローに明確な価値があるか不明な場合。
- 準委任契約を希望し、コストの優先度が高い場合: 費用対効果を重視し、柔軟な開発プロセスを求める場合。
- ユーザーにとって必要な機能の不確実性が高い場合: 「リリースするまでに、当初想定していたA・B・C・D機能が必要だと思っていたが、実はAは不要でC・D・E・Fが必要だった」といったように、柔軟な機能変更が想定される場合。
この場合は、Tシャツサイズ見積もりやストーリーポイント見積もりを選択することが、適切なベンダー比較検討につながります。
RFP（提案依頼書）の活用
最後に、非常に基本的なことではありますが、見積もり相談をする際にはRFP（提案依頼書）を作成することをお勧めします。
RFPとは、開発についての要望を整理し、文章化してベンダーに伝えるための重要な文書です。RFPには、主に以下の内容を記載します。
- 案件・プロダクトを作る背景と目的
- ベンダーに求める要望の範囲
- ベンダーを評価する基準
- プロジェクトの期待スケジュール
RFPで前提条件をすべて明確に言語化してベンダーに渡し、その回答を比較検討することで、より良い見積もりとベンダー選定を実現できるでしょう。
さいごに
デジタルプロダクト開発において、「とりあえず見積もりを取ってこい」と言われたり、曖昧な状態で開発会社に相談してよいのか迷ったりすることもあるかもしれません。
「誰もが価値創造に夢中になれる世界」を目指すSun*は、まさにそのような曖昧でふわっとした状態でこそ、きっとお力になれると信じております。ぜひお気軽にご相談ください。
アーカイブ動画の視聴はこちら＞＞
本ガイドでは、複雑になりがちなシステム開発の見積もりの基本構造や比較のポイントをわかりやすく解説いたしました。
業務システムの課題を見える化し、改善につなげるためのヒントをまとめた資料です。業務システム刷新検討中の方におすすめ。