そんな金額で大丈夫？開発費用をどう見積もるべきか

私はよく牛丼を食べます。

とりわけネギたっぷりに卵が乗ったバージョンが好きで、時間がない時にチャチャッとお腹を満たせるのもありがたいところ。
通勤で利用する駅構内に店舗があるため、ついつい会社帰りに良い匂いにつられてしまい、子供のころアニメで流れていた「はやいの～うまいの～やっすいの～っ」の歌を頭の中でリフレインさせながら、いつもウキウキで入店することになります。

さて、件のアニメの主人公の「牛丼一筋300年」とまではいきませんが、気が付けばシステム開発の現場に身を置き30年近く。

これまでに多くの失敗プロジェクトを見聞きしてきましたが、やはり「当初の想定より大幅に開発コストが増加してしまう」というケースが相当多いように思います。

理由は以前書いた通り*ですが、同じように世の中の失敗プロジェクトを見知っている（または自らも経験している）経営者やCIOがシステム企画書に簡単にGoサインを出すことはなく、「その見積もりで本当に大丈夫なのか？」としっかり説明を求められることとなります（もちろん、ここでモゴモゴなると企画は通らず）。

という訳で、今回のテーマはシステム企画段階における開発費の見積もりについて。

*「なぜ要件定義後に開発費が倍増するの？」

Q企画段階で開発費用をどう見積もるべきか？

最初にハッキリ言ってしまえば、見積もりをシステム開発会社からの提案金額だけに頼っている限り、妥当性の高い見積もりは出せません。

企画段階ではどのようなシステムを作るのかカッチリとはまだ固められませんし、外部のシステム開発会社が発注側のビジネスや業務を把握している訳でもありません。限定的な情報だけで精度の高い見積もりを他社に求めるのは無茶というもの。
システム開発プロジェクトは「未知の要素」を多分に含む活動である以上、販売店からクルマの見積もりを貰うような感覚とは明らかに性質が異なるのです。
従って、「何社かに見積もりを依頼して提示された金額が各社大体1億円だったから、そのくらいの開発費で出来るんだろう」といった考え方は非常にリスキーとなります。

ではどうするか？

企画の主体者たる発注側でも見積もりを行うべきです。しかも、異なる複数観点からの見積もりを行うべきです。

とはいえ、自らが開発を行わない発注側が開発作業を一つ一つ洗い出しながら積み上げ方式で見積もる方法（「ボトムアップ見積もり」と言います）を取ることは難しいため、別の手法を用います。

まず手軽なのは、過去の実績や有識者の知見をもとに見積もる方法。

例えば、現在自社で利用しているシステムの開発に要したコストを調査したり、自社の複数の有識者に企画内容を説明して費用感を提示してもらったりという方法が考えられます。可能であれば取引先やグループ会社など、他社で同様のシステムを開発した際の実績コストを訊ねてみることも参考となるでしょう。

また、公開されている統計データも活用できます。

例えば、独立行政法人情報処理推進機構（IPA）が公開している「ソフトウェア開発データ白書」には、「会計・経理」「顧客管理」といった業務別に他社ではどの程度の規模のシステムが構築されているかといった情報が掲載されており、このようなデータを使えば「世の中の相場感」を掴むことが可能です。

さらに、システムで扱う情報の種類（商品情報、顧客情報、受注情報・・・など）の数と、他システムとやり取りする情報の種類から、簡易的にシステムの規模を予測することができる「NESMA試算法」といった手法もあります。
システムの複雑性や開発手法などにより一概には言えないものの、システムが扱う情報とシステムの規模には大きな相関性があるため、これを利用しようと言う考え方です。
少々長くなるため具体的な内容は割愛しますが、ITの専門知識がなくとも業務を理解していれば活用できる手法であり、これによって推定されたシステムの規模をもとに開発費を計算することができるのです。

このような様々な見積もり方法を活用することで、システム開発会社からの見積もりのみに頼るのではなく、複数の情報源・複数の根拠に基づいた説明可能かつ精度の高い見積もりを算出しておくことが企画段階における基本的ポイントと言えます。

今回のアンサー。

A複数の方法を組み合わせた独自の見積もりも行い、妥当性の高い開発費を算定しましょう！

アニメで登場する超人はそれぞれ特殊な能力を持っていますが、一人だけでは失敗してしまうこともあります。
複数の超人が協力して欠点を補い合って困難に立ち向かうのと同じように、様々な見積もり方法の長所・短所を知ったうえで組み合わせることが有効であること、お分かりいただけたのではないでしょうか。

それではまた次回！