ソフトウェア開発規模を適正に評価する見積手法について

更新日:2017年05月30日 | 公開日:2017年05月26日

ソフトウェア開発の外注を行うにあたって、見積金額を適正に評価することは非常に大切です。しかし、ソフトウェアの開発は内容的に見えにくく、見積もりの根拠も専門的で分かりにくい部分があるのも事実です。また、相見積もりを取ったときに業者ごとにかなりの開きがあることもしばしばですので、発注担当者は相見積もりを見て何を基準に判断したらよいか迷ってしまうことも多いでしょう。

提出されてきた業者の見積もりを手に取りながら「いったいソフトウェア開発の見積もりの根拠はどうなっているのだろう…?」と疑問に感じた担当者の方はたくさんいるはずです。

この記事では、開発会社が実際に活用している見積手法の中身を明らかにし、そうしたモヤモヤを解消いたします。複雑な見積手法の本質部分を整理いたしますので、一読していただければ専門家でない発注担当者の方も見積もりの根拠について理解できるようになり、相見積もりを適切に評価できるようになるでしょう。

ソフトウェア開発の見積もりは「規模」をベースに算出します。この規模見積もりで適用する代表的な方法として、「類推法」「係数モデル」「ボトムアップ」の3つがあります。まずは、それぞれの見積もりの特徴を見ていきましょう。

「類推法」とはどんな見積手法か

「類推法」とは、現在見積もりを出そうとしている案件と過去に手掛けた類似した案件を比較検討して、開発規模や開発工数を「類推」する見積手法です。

複雑な見積計算を予想していた担当者の方は、拍子抜けするかもしれませんが、大規模なプロジェクトであっても開発会社の見積担当者がまっさきに行う見積計算はこの、過去のプロジェクトの中から類似した案件を探して「だいたいこれくらいの金額がかかりそうだな」という非常に直感的でアナログ的な類推を行うことから始まります。

当然のことながら、過去に多数のソフトウェア開発プロジェクトを手掛けた実績のある開発会社の場合には、参照することのできる実績も多いわけですが、自社で扱ったことのない分野であったり、似たような案件であっても詳細の機能要件がかなり違っていたりするというケースもあります。

では、そうした類推すべき過去のプロジェクトが見つからなかったり、詳細について過去の実績から判断しにくかったりする場合はどうするのか、発注担当者の方が気になるのはその点だと思います。

ずばり、そうしたケースでは開発会社の担当者の「知識」や「勘」が根拠になってきます。過去のプロジェクトから類推するにしても、お手本となるべき完全に一致した経験はまずあり得ないわけなので、担当者の「知識」や「勘」が根拠となることは避けられないと言ってもいいでしょう。

「類推法」は初期段階の概算見積もりで使われる

ソフトウェアに要求される基本となる「機能要件」、性能や信頼性、拡張性、運用性、セキュリティその他の「非機能要件」などを、担当者の「知識」や「勘」でどこまで正確に判断できるのか? という疑問が出てきて当然です。身もふたもない話をすると、「類推法」で出てきた見積もりの正当性を正確に判断するには、類推法で見積もりを出した開発側担当者以上の「知識」や「勘」を持った人間が、その人の「知識」や「勘」で判断し直す、という以外にありません。

つまり、類推法を使って見積もりを出した会社の上司にあたるような人は、担当者以上の「知識」や「勘」を持っているかもしれませんが、発注側にはそんな上席担当者はいませんので、発注側では類推法で出てきた見積もりを適切に評価できない、ということになります。

したがって類推法は、相見積もりを多数取っているようなまだプロジェクトの初期段階でのみ有効な見積手法だと言えます。初期段階で「ざっくりどのくらいかかりますか?」「そうですね、持ち帰って検討しますがだいたいこのくらいです」と担当者が即答に近い形で答えてくれるときの金額が類推法による見積もりです。

類推法は、超上流工程、上流工程のごく初期の見積もりで使われ、厳密な要件定義以降はほとんど使われないという点に注意しましょう。逆に言えば、設計が本格化してきているのに、初期の「ざっくりした」=類推法による見積もりをアップデートしてこない業者は信頼できないと言っても過言ではありません。

「類推法」のメリット

開発会社が使っている見積手法の解説ということで、専門的な話を期待した読者の方は少し拍子抜けしてしまったかもしれません。しかしソフトウェア開発会社とのやり取りの初期段階ではこの「類推法」による見積もりにはとても大きなメリットがあります。

ソフトウェア開発の初期段階においては、発注側は自分たちのやりたいプロジェクトにいったいどのくらいの予算を割けばよいのか見当もつかない、というケースがほとんどです。つまり他社との予算の比較の前に、「そもそもこのプロジェクトは予算を割いて元が取れるプロジェクトなのかどうか」という判断をしなければなりません。

例えば、現在手作業で行っているECサイトの商品入れ替えについて、自動プログラムを使えばアルバイトの人件費が月間で15万円減らせる、という目論見で自動商品入れ替えプログラムの見積もりを取ったとします。

ソフトウェア開発会社から類推法(即答に近い形)で「300万円程度かかります」という回答があった場合、2年近く経たないともとが取れないということがすぐに分かります。逆に「50万円程度かかります」という回答があった場合には、3ヵ月程度でもとが取れるという計算ができます。

前者の場合には、「商品自動入れ替え開発のプロジェクトに費用対効果なし」と判断できるかもしれませんし、後者の場合には「すぐにでもやろう!」という判断が可能になるかもしれません。意思決定を迅速に行うことは企業活動の基本でもありますので、類推法以外の厳密な見積手法で正確な見積もりを長い間待っていることは時間的ロスとなります。

つまり、類推法はプロジェクトの費用対効果などを簡単に算出する場合などに大きなメリットがあるのです。

「類推法」のデメリット

一方で類推法には、大きなデメリットもあります。それは、類推法が開発側の会社の過去の実績、開発側担当者の経験値に大きく左右され、客観的な根拠を厳密に問われても説得力ある見積金額算出の理由を説明できないという点です。

例えば見積金額の妥当性を他社と比較したいときには、下記のようなやり取りが発生します。

依頼者:「見積もりありがとうございます。ところでなぜこの金額になるのですか?」
業 者:「去年、御社とそっくりなプロジェクトをやったことがあって、その金額から算出しました」
依頼者:「その去年のプロジェクトはどうやって算出したのですか?」
業 者:「一昨年の、また別の会社のプロジェクトから算出しました」
依頼者:「そうなのですか……」

これでは、いつまでかかっても納得のできる客観的な見積金額の根拠が出てきません。相見積もりを取って他社と見積金額を比較したいのに、他社と共通の基準がなくその会社の内部の判断基準で出てきた見積もりがたくさんあっても比較のしようがありません。

類推法にはもうひとつ欠点があります。それは、開発会社が判断の基準とする「去年」とか「一昨年」に類似したプロジェクトを実施した経験がないという場合です。この場合には、担当者が過去に別の会社で経験したプロジェクトであったり、担当者の人脈で業界の相場をあわてて調べたりといったさらにあいまいな基準から見積金額が出てきてしまうことがあります。

いずれにしても、類推法による見積もりはざっくりとした初期段階の金額を聞いて、プロジェクトそのものがやるメリットがあるものなのかどうかという段階の判断にとどめておくべきでしょう。

このような特徴を理解した上であれば、類推法による見積もりは有効です。開発会社の担当者が類推法で出してきた見積もりを評価する場合には、可能な限り「根拠となった過去のプロジェクト」の中身を教えてもらいましょう。具体的にはどのような機能を持つプロジェクトを、どのくらいの人員を割いて開発し、どのくらいの時間で仕上げたのかを聞いてみましょう。

「係数モデル」とはどんな見積手法か

係数モデルとは、システムの細部を算出した後、一定の定数を掛け算して全体の規模コストを割り出す方法です。例えば、基本的な機能を数字で表した後、「このケースの場合、基本的な数値に2.5を掛け算する」といった係数を元に見積金額を算出します。そして、類推法とは違って、この2.5という数字には明確な根拠がありますので、担当者に聞けばこの計算根拠も明示してくれるでしょう。

「係数モデル」は概算見積もりで使われる

最初に解説した「類推法」は、プロジェクトの費用対効果をざっくり判断するときなどには有効でも、見積もりの客観性を測る場合には不向きであることを確認しました。そのため、類推法はプロジェクトの初期段階で有効な見積もりではあっても、いつまでも類推法を基にした見積もりしか出してこない業者は信用できないと判断してよいということもお伝えしました。

では、プロジェクトが進んできたとき、つまり超上流工程や上流工程のヒアリングが終了して具体的な設計に取り組み始めた段階では、どんな見積もりが有効なのでしょうか。具体的な係数モデルの手法としては「FP法」や「COCOMO/COCOMOII」「LOC法」「ユースケース・ポイント法」などがあります。

ここでは、代表的な係数モデルである「FP法」について解説します。

「FP法」とはどんな見積手法か

「FP法」では、FP(ファンクショナル・ポイント)という共通の指標で開発規模を表します。算出の計算式は下記のようにとてもシンプルなものです。

■ 機能数 × 重み付け係数 = FP

ここで言う「機能」とは、入出力ファイルの数、画面や帳票、バッチなどの処理プロセスなどを指します。その機能数に係数を乗じてFPを計算します。

さらに、FPから人月の計算も導き出せます。計算式は下記のようになります。

■ FP ÷ 生産性基準(FP/人月) = 工数(人月)

FP法で人月単位の見積もりを出す場合には、必ずこの計算式に基づいていますので、例えば「生産性基準(FP/人月) 」を各社で比較してみれば、同じ作業にどのくらいの人員を割かなければならないのかが分かります。

つまり同じ作業をするのにA社では2人のエンジニアが必要だと言っているのに、B社では同じレベル(金額)の技術者1人でよいと考えている、などの比較ができます。当然、この場合B社の方がこの部分の見積金額が半分でよいということになり、その根拠は安くて優秀なエンジニアを社内に抱えているというB者の技術力の高さが際立っているからであるということになります。

FP(ファンクショナル・ポイント)の種類

ひとくちにFPと言っても、FPを算出する方法にはいろいろあり、代表的なのは以下の3つの手法となります。

FP(ファンクショナル・ポイント)の種類
  • IFPUG法
    米国International Function Point Users Group(IFPUG)が整備した方法で、FP法の完全バージョンと言えるでしょう。機能を算出するときに、データファイル、内部論理ファイル、外部インタフェースファイル加えて、システムに対するトランザクションの数もカウントします。
  • FP概算法
    データファイルと内部論理ファイル数と外部インタフェースファイル数のみを計算対象とします。
  • FP試算法
    データファイルのみを計算対象とします。

個々の複雑な計算式まで発注担当者が理解している必要はありませんが、FP法を使った見積もりを比較する場合には、どの方法でFPを算出しているのかを把握しておく必要があります。

「ボトムアップ」とはどんな見積手法か

これまで、プロジェクト初期段階に有効な「類推法」、相見積もりの根拠を知りたい段階の「係数モデル」と見てきましたが、相見積もりを比較して候補を絞り、発注先を決めたい段階でさらに詳細な見積もりを知りたいときにぜひ検討したい「ボトムアップ」について説明します。

ボトムアップは詳細見積もりで使われる

最初に検討した類推法は、開発会社や開発会社の担当者の過去の経験から基準となるモデルを選び出し、そこからトップダウンで現在のプロジェクトの見積もりを算出しました。ボトムアップ方法はこれとまったく逆の方法で、現在あるプロジェクトの特徴を精査するところから見積もり算出を開始します。

ここでは、代表的なボトムアップ手法である「WBS法」について解説します。

WBS法の「WBS」とはそれぞれ「Work」「Breakdown」「Structure」を指します。

最初の「Work」は、ソフトウェア開発で言えば目的を達成するために必要な作業のことです。要求定義から要件定義、設計、テストといった一連のプロセスを指します。

例えば、プロジェクトの最終的な目的が「顧客管理システムを作る」ことであれば、WBSの「Work」では顧客管理システムを作るためにどんな要求定義、要件定義、設計、テストが必要なのかを洗い出します。

次の「Breakdown」は、個々の要求定義、要件定義、設計、テストを可能な限り詳細にしていきます。類推法は過去のモデルの類似点に着目しますが、WBS法では現在のプロジェクトで求められることを詳細にBreakdownしていきますので、過去のプロジェクトにはなかった部分もすべて洗い出します。ここが、トップダウンの「類推法」に対するボトムアップの「WBS法」の特徴となります。

そして最終段階が「Structure」となりますが、これは、Breakdownによって洗い出された詳細を「構造化」することです。Breakdownでは、とことんまで必要な要素を洗い出しますので、未整理の要素が列挙されることになります。これをプロジェクトの目的である「顧客管理システムを作る」ことに合わせて整理・再構成します。

いったん詳細部分までとことん洗い出しているので、詳細見積もりを出してもらう段階に適した見積手法だと言えるでしょう。

【まとめ】試算見積もり、概算見積もり、詳細見積もりの段階に合わせた最適な見積手法を理解しよう

いかがだったでしょうか。「類推法」「係数モデル」「ボトムアップ」の3つの見積手法を整理しながら、それぞれの手法がどんな場面で最も効果を発揮するのかを見てきました。

段階的にどんな見積もりが有効なのかですが、試算見積もりでは主に「類推」見積もり、概算見積もりでは主に「係数モデル」見積もり,詳細見積もりでは主に「ボトムアップ」見積もりを使うとよいことが分かりました。

最後に、これは半分冗談なのですが、「KKD法」という見積手法(?)をご紹介します。このKKDとは、 K(勘)、K(経験)、D(度胸)の略で、本来見積もりをする能力や経験のまったく欠如した会社や担当者が、仕事欲しさで適当な金額を無責任に提示することを揶揄した言葉です。

こうしたいい加減な会社は途中でプロジェクトが空中分解するというケースも多いはずですし、途中でこの種の会社のいい加減さに気がついた場合でも、それまでのやり取りの労力は大きな損失です。ソフトウェアが完成したとしても適正な金額・品質のものであるのかは大きな疑問です。くれぐれも根拠のない安い見積もりを鵜呑みにしないよう注意してください。

見積もりは、開発会社の専門技術者であってもかなり熟練の技術を必要としますので、実はすべての会社がきちんとした見積もりを出せるとは限らないのです。発注者側からすると意外かもしれませんが、これが現実です。

この点、業界の評判にも精通した「アイミツ」にご相談いただければ、きちんとした見積もりを出せる経験豊富で信頼のできる業者をピックアップすることが可能です。「きちんとしたソフトウェア開発の見積もりを取るのもけっこう大変だな…」と感じた場合には、ぜひ私たちにご相談してください。

見積もり、取ってますか?

発注をする際に最も大切なことは適正価格を知ることです。
3~4社から見積もりを取ることで、
発注への納得度を高めることができます。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください