ソフトウェア開発には、人と時間が必要です。
ソフトウェア開発コストの見積もりとは、必要となる人と時間、工数（人月）を予測することです。
■ ソフトウェア開発コストの見積もり技法
ソフトウェア開発コストを定量的に見積もる主な技法は、以下の２つです。
両方とも、ソフトウェアの規模を表す総量をひと月当たりの生産性で割ることで、工数（人月）を算出できます。
１）標準値法
工数（人月）＝総ステップ数 / 生産性（ITエンジニアが一カ月で書けるステップ数）
※ステップ数とは、ソースコードの行数。
２）FP（ファンクションポイント）法
工数（人月）＝総FP数 / 生産性 （ITエンジニアが一カ月で作成できるFP数）
※FP数とは、画面、ファイル、データベースのテーブルなど、各種構造をもつデータの数。
■ 見積もり技法の問題点
上記の見積もり技法は、ソフトウェアをつくる前からあらかじめステップ数、FP数がわかって、さらに標準的な生産性が明確にされていることが前提です。しかし、こんなことは、現実的に絶対、あり得ません。
結論から言えば、ソフトウェア開発コストの見積もりは、いくら数式を使っても、決して正確に算出することはできません。
なぜならば、何を作るかを数値化することができないのと、ソフトウェアを作るのは機械ではなく、生身の人間だからです。このような不確定で、不明瞭なものをあてにした数式なんて、まったく使えないといっていいでしょう。
特に「生産性」は、非常に怪しく、ITエンジニアがひと月でどれだけ動くコードを書けるか、どれだけのデータ構造を設計できるか、なんて誰も計測したことなんてありません。それも、年齢、性別、身長、体重、学歴、仕事環境、人間関係、スキルなど、ITエンジニアという人間を取り巻く環境は１００人十色です。このような状況で、定量的な計算式を持ち出されても、鼻で笑うしかありません。
「過去のメトリクスを使えばいいじゃん」という声が聞こえてきそうですね。
実際のところ、ITプロジェクトの内部で収集するメトリクスは、ステップ数当たりのテスト件数やバグ検出率など、テスト工程での品質指標として使うことが主目的です。
プロジェクトを横断した形で、ステップ数などのメトリクスを一元管理している会社は、少なくとも私が参画したプロジェクトではありません。
じゃあどうするか。ITエンジニア個々人が持つ経験と勘、そして、交渉力と度胸を発揮して、工数を見積もります。
■ ソフトウェア開発現場での見積もりのリアル
実際の見積もり作業の手順は、おおよそ以下の通りです。
１）同僚や委託先をつたって、過去の類似プロジェクト案件を探す
２）過去の類似プロジェクトで開発した機能と工数を調査する
３）必要と思われる類似の機能を思いつく限り洗い出す
４）２）で調査した機能から、類似の機能を洗い出す
５）類似度合いに応じて、経験と勘で、工数を積み増す
６）現時点でわかる不明点、問題などリスクを洗い出す
７）リスク見合いとして、経験と勘で工数を積み増す
８）妥当性を判断し、委託先との打ち合わせをし、工数を擦り合わせる
９）顧客の予算と比較し、工数が多ければ、委託先との協議を繰り返し、工数を調整する
つまりは、ソフトウェア開発の見積もりなど、決してスマートとはいかず、どうにかこうにかして利害関係者がそれなりに納得するところに落ち着くまで、喧々諤々が繰り返されることになります。
見積もりとは、お金を支払う顧客と、お金が必要なITプロジェクトの間で、お互いの腹の中を見せずに行われる何とも人間臭い交渉なのです。
■ 工数の使い方
見積もった後も、プロジェクトを進めながら慎重に注意深く、見積もり内に収まるように、やりくりをしていくのが実態です。ITプロジェクトとは、見積もった工数内にソフトウェア開発を収める難しいゲームといっていいでしょう。
以下は、工数を消費するときの留意点です。
１）できない人は、できる人より工数の消費量が倍以上
スキルの高い人、能力のある人に仕事が集まると言われますが、ソフトウェア開発ほどその傾向が顕著に出る仕事はないでしょう。知識、プログラミング、経験の有無などのハードスキルだけではなく、思考法、コミュニケーション能力、文章力、英語力などのソフトスキルのレベルによって、アウトプットの速さと質のレベルが違います。できない人がした仕事は、結局、できる人がやり直しをせざるを得なくなることも頻繁に起こります。そうなると、単純に工数が倍以上かかります。
結局、仕事を安易に分担し、分散させるより、仕事ができる人に、できるだけ仕事を集中させる方が、結局は工数が低く済みます。
２）社内工数の管理は緩くていいが、社外工数の管理は厳密にする
委託先は、別会社の人であることを忘れてはいけません。同僚に聞くように、委託先へ頻繁に問合せをしたりすると、その対応工数が消費されることになります。
また、バグの対応は原則、工数不要ですが、仕様変更は必ず工数が必要になることも意識しておく必要があります。気軽に機能や処理の変更を依頼すると工数が要求されます。それがたとえ、些細なことに見えたとしてもです。
時に、ソフトウェアの問題が発覚すると、バグなのか、仕様変更なのか、委託先と見解が分かれることも頻繁にあります。このような場合、問題が埋め込まれた背景と経緯などをロジカルに説明できるほうに分があります。
これも、工数を消費しないテクニックです。少なくとも、無理強いをするよりも、ずっとマシでしょう。
３）顧客からの依頼をなんでも受けると破綻する
「お客様は神様です」という意識が、受託開発をするITエンジニアには強く染みついています。営業のように客と接する機会の多い人であれば、顧客の言うことをすべて飲み込むようなこともなく、取捨選別できるでしょう。
しかし、ITエンジニアは顧客と対峙すると、少なからずというか、かなり萎縮してしまう人が多いです。
顧客から何か言われるのを恐れるあまり、何でも言われることに「Yes」を繰り返してばかりだと、どんどん工数を消費し、早々に枯渇してしまいます。
顧客とは、ある程度距離を取り、「顧客の依頼＝工数」ということを念頭に話を聞くことです。ある程度のことは受け入れてもいいと思いますが、工数がかかる依頼についてはその旨を説明し、断ることも必要です。
４）倹約ばかりではなく、適切なタイミングで必要な工数を投入する
工数という燃料を燃やして、ソフトウェアは作られるので、あまりにケチでは、ソフトウェアを完成させることはできません。工数を消費するタイミングが非常に重要となります。たとえば、設計漏れが見つかれば、即、設計作業を追加で実施する、バグがありそうであればすぐに再現作業をするなど、作業すべき工程内で工数を使い、問題をつぶしていく必要があります。
プロジェクトがうまくいかなくなり始めると、工数をバカ食いし始めます。そうなると、見積もった工数内では、とても収まらず、仕切り直しが必要になってしまいます。
見積もった工数を想定以上に消費する主な要因は、発生する問題の数です。問題を放置せず、適切なタイミングで一つ一つ解決し続けることが、見積もりの工数で納める最も重要なポイントです。
最後に、開発予算の絶対額に目がくらむと、見積もりも甘くなり、デスマーチが待っていることを肝に銘じておきましょう。
