やってみなきゃわからないという現実

システム開発の見積金額を提出して、「どうせ言い値でしょう？」といわれたことはないだろうか？

もちろん否定するだろう。ビジネストークとして。しかし、言い値といわれても仕方がないのが実情でもある。

システム開発の見積は、全くでたらめというわけではないにせよ、全く正確でもない。KKD（勘と経験と度胸）による主観的な見積はもちろん、COCOMO やファンクション・ポイント法といった客観的な見積手法を使っても、100% 正確な見積は不可能だ（※１）。

開発工数の見積は天気予報に似ているが、おそらくもっと難しいだろう。「ひまわり」や「アメダス」に相当するものがないからだ。開発の進捗に影響を及ぼす因子は無限にあるが、そのほとんどは測定することすら出来ない（※２）。

結局のところ、システム開発は、どこまでできるか、やってみないとわからないのである。

★

そんないい加減なことでビジネスとして成り立つか！　とお叱りを受けそうである。しかし、いいかげんなのは、現在、多くのシステム会社が行っている見積のほうである。

システム開発業界は、自分たちが「いい加減なビジネスをしていない」と思い込みたいがために、半ば意識的に現実から目を背け、「開発工数は見積可能」という幻想を作り上げている。そして、同じ幻想を顧客も見ている。

不透明なソフト開発価格の解決への第一歩は“相場”を示すことだという意見もある（※３）。いかにも正論に見えるが、それでは「幻想」を補強するだけのことだろう。

本当の解決への第一歩は、「どこまでできるか、やってみないとわからない」という現実を受け入れることである。

★

例えば、XP (eXtreme Programming) という開発プロセスは、実際にそのような現実を受け入れている。

システムには沢山の機能があるが、頻繁に使われる（必要性が高い）ものと、ほとんど使われない（必要性が低い）ものがある。XP では、必要性が高い機能から順番に作って行くことになっている。

また、突然開発プロジェクトが中止されたとしても、いつでも納品できるように、常に「システムが動く状態」をキープしながら作っていく。

こうすることで、たとえ作っているうちに、納期が来てしまった（顧客が開発予算を全て使い果たしてしまった）としても、本当に必要な機能は揃った状態で納品することが出来る。開発が間に合わなかった機能があるかもしれないが、それは、必要性が低い機能ということになる（※４）。

もちろん、開発期間があまりに短いと、必要な機能すら作ることが出来なくなるので、ある程度の見積は必要だろう。しかし、見積には、それほど高い精度を期待しなくてもよいのである（少なくとも、ウォーターフォールのような従来の開発手法に比べれば）。

XP は開発現場から生まれた手法である。現場の人間が、システム開発は「やってみなけりゃわからない」ということを身にしみて知っているからこそ、こういった方法が生み出されたのだと考えてよいだろう。

※１
ここでは、受託開発で作業工数（人月＝開発者の労働時間）を基準にした見積を行う場合の話。工数とは無関係に、導入効果などからシステムの「価値」を判断して、金額を設定することもあるらしい。また、パッケージ・ソフトには、市場価値というものがあるので、工数に直結はしないだろう。

※２
システムの規模は？　納期は？　技術的な難易度は？　要件がどれだけ明確化されているのか？　仕様変更はどれくらい発生するのか？　顧客とのミーティングにとれる回数や時間は？　開発者のスキルはどれくらいか？　管理者のスキルは？　開発者のチームワークはよいか？ .... 開発効率に影響する要因は無数にある。しかし、簡単に数値化したり、予測したりできるものは少ない。

※３
daxanya さんの関連記事にトラックバックしてます。

※４
もちろん、「必要性の低い機能は出来なくてもよい」という判断は顧客が行うことである。XP では、顧客が開発チームに参加することが必須とされているので、このような方法が可能なのである。
なお、ここで紹介しているのは、XP のほんの一側面に過ぎない。XP には、システム開発を良くするためのアイデアが満載である（→ おすすめ参考資料「オブジェクト倶楽部 Xp-jp 」）。

■関連記事
・システム開発費を値切る理由
・システム開発費の削減方法教えます