見積りの根拠とは何か？PMBOKに登場する用語を解説
見積りの根拠の概要
見積りの根拠とは、プロジェクトの見積りに使用する、前提条件、制約条件、詳細度、見積り幅、信頼度などを記載した詳細な補足資料を指します[1]PMBOK第６版、735頁。。
今回はプロジェクトの見積りの根拠の出し方と、ソフトウェア開発での具体例を紹介していきます。
見積りの根拠に記載する内容
ステークホルダーやクライアントに提出する見積りには金額だけが記載されていることも少なくありません。
しかし、ソフトウェア開発は100万円や1,000万円など高額になることもあり、見積りの根拠をステークホルダーやクライアントから求められることもあります。
見積りの根拠には、以下のような内容を記載していきます[2]PMBOK第６版、204頁及び247頁。。
- 見積りをどのように作成したか
- 見積りの前提条件・制約条件
- すべての既知の制約条件を記載した文書
- 見積り範囲の表示
- 最終見積りの信頼水準の提示
- 見積りに影響を及ぼすプロジェクトの個別リスクの証拠を記載した文書
ここからは、これらの記載内容について解説していきます。
見積りをどのように作成したか
見積りの根拠に記載する「見積りをどのように作成したかを記載した文書」には、その名の通り、どのようにして見積書に提示した金額を算出したのかを記載します。
算出根拠を示さず、「何となく実装できそう」で見積りを作成したとします。しかし、いざ開発を開始したら実現不可能な機能だったり、膨大な工数が必要になったりして、プロジェクト途中で採算が合わないことが判明するということもめずらしくはありません。
このような事態を防ぐために、提出をしない場合でも、見積りの根拠は定量的に示せるようにしておいた方が良いでしょう。
主な見積りの算出方法は以下の通りです。
これらの内容については、上記のリンクから詳細ページに遷移できます。
見積りの前提条件・制約条件
同じ作業をする場合であっても、見積り金額が同じになるとは限りません。
ソフトウェア開発では、繁忙期である12月の年末、３月の年度末は、資源（リソース）を調達できないことから、見積り金額が高くなることがあります。
このように、見積りでは前提条件が非常に重要になるため、見積りの根拠の資料として、前提条件も記載します。
前提条件には、先ほどのように、見積りが適用される期間や、「データベース設計はしない前提条件で見積り」というように作業範囲についても記載すると良いでしょう。
このような前提条件がないと、提示した見積りでどのような要望でも叶えないといけないということにもなりかねません。
同様に、見積りに制約条件がある場合は、それも記載していきます。
これら見積りの前提条件や制約条件を記載することと同じく大切なのは、前提条件や制約条件が変われば、見積りも変わることをステークホルダーやクライアントに伝えるということです。
見積り範囲と信頼水準
見積り範囲と信頼水準はほぼ同じようなことを意味しており、要するに「この見積りはどの程度信頼できるものなのか」を示すものです。
例えば、スケジュールを見積る場合、「作業Aは30日で完了する」と見積りをした場合でも、作業Aがちょうど30日で終わるということはまずないでしょう。
29日で終わることもあれば、35日かけてようやく完了するということもあります。
これは金額の見積りでも同様であり、「作業Aには30,000円が必要」と見積りをした場合でも、本当にその金額になるとは限りません。
そのため、見積り範囲には「どの程度の振れ幅が発生すると考えられているのか」、信頼水準には「どの程度信頼できるのか（どの程度の確率でこの見積りの数値が実現されるのか）」を記載していきます。
これらの内容は統計学の範囲でもありますが、三点見積りの知識程度でも十分対応できます。
統計学に触れてこなかった方は、まずは三点見積りの内容を確認されることをおすすめします。
三点見積りについては、以下の記事もご参照ください。
https://ssaits.jp/promapedia/method/3-point-quotation.htmlリスク
正確な見積りを出すためには不明点を無くすことがとても重要です。
不明点がある場合には、見積りの数値にリスクを考慮した金額や期間を上乗せすることも少なくありません。
しかし、リスクによって見積り金額やスケジュールがかさむとステークホルダーやクライアントからその理由を問われることは目に見えています。
そうした時に提示するのが、「見積りに影響を及ぼすプロジェクトの個別リスクの証拠を記載した文書」です。つまり、「どのような状況を恐れているのか」を列記した資料を作成していきます。
このリスクの内容によっては、前提条件や制約条件に加えることで対処することができます。
例えば、「依頼時期が不明であるため、そのリスクを金額に計上した」というような内容を文書として記載していきますが、ステークホルダーやクライアントと相談する中で、「時期が読めないことで見積りが変わるのであれば、依頼時期は８～11月にする」という話になる可能性もあります。こうなると、「依頼時期が不明である」というリスクを「依頼時期は８～11月」という前提条件にすることができるため、より正確な見積りを提示することが可能となります。
このように、すべてのリスクを解消することは難しいものの、ステークホルダーやクライアント、チーム・メンバーと話し合い、できるだけ前提条件や制約条件の形にすることをおすすめします。
ソフトウェア開発の見積りは人件費+環境構築コスト
今までは汎用的な見積りの根拠についてお話ししてきましたが、ここからはソフトウェア開発特有の内容について解説を加えていきます。
ソフトウェア開発の見積りは「人件費」と「環境構築コスト」に集約されます。
とはいえ、ソフトウェア開発の費用のほとんどが人件費です。あとは内容次第で多少の環境構築コストが発生します。
ソフトウェア開発原価の大半はエンジニア人件費
ソフトウェア開発コストの大半はエンジニアの人件費です。ソフトウェア開発はエンジニアやプログラマーの頭で生み出す生産物だからです。ソフトウェア開発は「プログラマーが何人いればそのソフトウェア開発が完了するのか」という視点で見積りをします。
例えば、マッチングサイトの見積りを考えていきましょう。
お客様から要件をヒアリングした結果、画面は20画面、データ表示は30箇所、データ更新は５箇所、データ削除は２箇所だと言われたとします。
「データ表示の１箇所はだいたい４時間で実現可能」、「データ更新は６時間で実現可能」というように、機能実装に必要な時間を積み上げます。仮に積み上げた合計時間が400時間だったとしましょう。これをどのように金額に変換するのでしょうか。
１日を定時間の８時間だとして、休日を除く月労働日数が20日間。つまりエンジニアは月160時間働く計算となります。そして先ほどの400時間を160時間（１ヶ月労働時間）で割ると2.5となります。これは、１名のプログラマーが2.5ヶ月間、そのソフトウェア開発に従事すれば完了することを意味します。そして最後に会社のプログラマーの月単価を掛け算します。この月単価は会社によって異なりますが、仮にプログラマーの月単価が80万円だとすると、先ほどの見積り金額は200万円（80万円×2.5月）となります。
このように、ソフトウェア開発においては「開発完了にかかる時間×月単価」が基本的な見積り額の根拠となります。
人件費以外は環境構築やツール使用料
ソフトウェア開発はほとんどが人件費ですが、案件次第ではサーバー代やツール代などの環境構築コストが必要となります。システムを動かすにはサーバーが必要ですし、Visual Studioなどの有料環境も必要な場合もあります。
さらにテスト自動化のために有料ツールを購入する必要があるかもしれません。
このように、ソフトウェア開発に必要な環境構築コストも見積りに加えます。