プログラムの見積金額査定の方法（買う側）

Question

業務効率改善のためのシステム（プログラム）作成をＡ社に依頼したとします。このときにＡ社からあがってくる見積金額について、妥当な金額なのか、高い金額なのかを判断する良いアイデアはありますでしょうか？
プログラムの行数の多さで金額を決める方法も考えましたが、無駄に行数を増やされたら高い金額になってしまいます。
皆さんはどのような方法で対処していますか？

yokohamahope · Accepted Answer

システムエンジニアを３５年やってました。私は以下のように考えます。

１．ご質問における問題点
　　行数であろうが何であろうが、生産性（単位あたりの金額）も併せて最終的に見積金額で評価する訳ですから、例えば’無駄に行数を増やされたら’だけを取り上げて心配しても意味がないと思います。（注）
　　見積行数は２倍と大きいが、生産性も２倍のため見積金額は同じというケースもあります。行数なんて、１行で済むところを２行で書くなんて簡単（考え方ひとつ）ですから。
　　見積もる方も、規模や生産性はプラスマイナス５０％程度の幅はよくあることで、見積精度は当該開発に類似したケースをいかに経験しているかで大きく変わってきます。
　（注）見積金額ではなく、出来高契約（後述の実費タイプ）とするということであれば話は別です。

２．見積りと妥当性
　　見積方法には、ご指摘のような行数や、他に機能数や、画面・帳票数などによる方法、その他多数あります。しかし、この行数や金額を算定するための生産性については、計算式や標準値に相当するものはありません。さらに、前述のようにこれらは見積もりした企業の経験や技術によって変動します。
　　したがって、見積の妥当性という観点で考えると、売り手と買い手が納得できる金額であるかどうかという点しか見極めできないと思います。ソフトウェア開発の場合にはこれに品質が影響してくるから、さらに見極めが難しくなってくるのですが。
　　では、納得できるとはどういうことか、これは見積りを業者と対等に評価できるように自ら調査・勉強するか、評価できる第三者に依頼するしかないと思います。
　　一般的には、妥当かどうかというより、業務効率改善を行って得る効果に見合った投資額以下かどうかで決断されているように思います。

３．契約
　　ソフトウェア開発の場合、前述のように見積りが非常に難しいことや変動要素が多いことに起因して、契約面でいろいろ考慮されています。実際の契約タイプは概ね以下のようになります。
１）定額タイプ
　　当初の見積金額で契約するもので、開発対象や前提条件などスコープが明確な場合に適しています。定額なため、開発者（受託者）のリスクが高くなります。
２）実費（出来高）タイプ
　　行数やプログラム本数、工数（人月）など出来高を実費として契約するタイプです。当然、出来高が変動するため、発注者側のリスクが高くなります。
３）混合タイプ
　　定額タイプと実費タイプの混合型で、両者のリスクを折半したような契約形態になります。
４）その他
　　混合タイプではなく、定額タイプと実費タイプの複数の契約に分けて行う方法もあります。見積りの困難な上流工程は実費タイプとし、基本設計が終了してある程度正確な見積ができる工程から以降を定額タイプとするやり方です。
　　この他にも、基本は定額ではあるがインセンティブとペナルティを併用した組み合わせなど、いろいろあるようです。

４．その他
　　大手ベンダのＳＥをやっていましたので見積りについて更に一言。
　　基本的には規模×生産性で見積金額を算定するわけですが、実際顧客に提示するには更に幾つかのパラメタ（変動要素）を加味して決定します。
　　パラメタには、例えばお客様の性格（トップダウンで決定できるか否か）、規模（きめ細かい設計が要求されるか否か）、業種（社会システム等高信頼性を要求されるか否か）など最低でも１０項目以上はあります。

長文になってしまいましたが、少しでも参考になれば幸いです。

ShowMeHow · Answer

いくらのソフトを検討しているのかにもよりますが、出来合いのソフトで対応できないなら、

1.　RFPを副数社に出して工数を含む詳細な見積もりの提出を依頼します。　それを比較検討します。
2.　対象を（2,3に）絞り込んだ後、導入済みで見学できるところを紹介してもらい見学を行いそれも参考にする。

galluda · Answer

がると申します。
最終的には
・御社が、そのシステムに対して支払う事ができる(支払ってもデメリットにならない)金額以下
であれば、という程度でしか判断は難しいのではないかと思います。
なお「行数で判断」は、純粋に無意味な上に、高確率で有害になりかねませんので、避けられる事を強くお勧めいたします。

なお。#1さんがおっしゃっているやり方ですと…正直、判断は難しいと思われます。
どれだけ明確にRFPを書いたとしても、実際に「どのように実装するか」からstartして、「実装途中で気付いた変更点に対してどれくらい良心的に対応してもらえるか」「品質(BUG、システムダウンに対する考察、データ量の考察、スケールアウト、機能拡張、セキュリティ、など)」など。詳細設計であってもなお、見極めが難しい項目があまりにも多すぎるので。
＆
「あいみつで安いところ」をチョイスすると、時々もの凄く痛い目にあうので。

まずは、作成会社さんを落ち着いて見極めるのが尤もよろしかろうと思います。基準は「ちゃんとコミュニケーションが取れる事」と「必要であればちゃんと苦言を呈してくれる事」、あたりでしょうか。
「よいおつきあいができる」と判断してもらえれば、ふっかけられるような事はまずないですから。

プログラムの見積金額査定の方法（買う側）

いくらのソフトを検討しているのかにもよりますが、出来合いのソフトで対応できないなら、

がると申します。

システムエンジニアを３５年やってました。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング