□◆いまだにはびこる「システム一式○億円」
「今回のCRMシステムは、開発費用一式で2億円になります。勉強させていただきま
した」――。
あるユーザー企業の調達担担当者は、ベンダーA社からこう言われて驚いた。見積
書に「2億円」の根拠がほとんどなかったからだ。A社に聞くと、過去の類似案件に照
らした結果だという。
「はぁ、ずいぶん高いですね」。調達担当者はこう答えた。なぜなら別のベンダー
2社から提示されていた金額は、ともに1億円前後。それも根拠がきちんと示されてい
たのだ。「簡単だがRFP（提案依頼書）を作って説明したはず。どうしてこんないい
加減な見積もりになるのか」。調達担当者はA社に対して不信感を抱くと同時に、再
見積もりを依頼する気にさえならなかったと打ち明ける。
◆ いきなり「金額」は見積もれない
いまだに勘や経験に頼り「一式○億円」と見積もるこうしたベンダーが存在するよ
うだ。しかしシステム開発の見積もりに根拠がなければ、プロジェクト計画そのもの
が破綻する。冒頭のケースでは相見積もりによって難を逃れたが、A社だけに見積も
りを依頼していれば、デスマーチに突入した可能性が高い。
「一式○億円」といったいい加減な見積もりなどもってのほか。そう思うベンダー
担当者は多いだろう。しかしたとえ根拠を示したつもりでも、それが過去の類似案件
だとしたら、「当社の要求に向き合っていない」と、根拠として認めてもらうのは
難しい。
では、根拠が明確な見積もりとは何か。ひと言でいえば「見積もりプロセス」が
明確な見積もりである。どんな前提条件や手順で見積もったのかを説明できなければ
根拠なき見積もりと言われてしまう。
一般的な見積もりプロセスとは、
（1）規模見積もり→
（2）工数見積もり→
（3）期間見積もり→
（4）コスト見積もり→
（5）価格見積もり、という五つのステ
ップを踏む。（1）と（2）のステップを踏まずに期間やコスト、価格をいきなり出す
ことはできない。
「何を作るか」を決定する規模見積もりでは、機能要件を定量化する必要がある。
ここではファンクションポイント（FP）数やステップ数（SLOC）などを使うのがセオ
リーだ。続く「どう作るか」を決める工数見積もりでは、規模見積もりの結果を規模
当たりの生産性（FP当たりの人日など）で除算して求める。これがいわゆる人月工数
である。
そして人月工数に対して、メンバーを何人割り当てるかによって期間が決まる。
4人月の工数に2人をアサインすれば期間は2カ月。そして工数に人月単価を乗じたの
がコストである。価格はこのコストをベースに利益を乗せる。通常は、顧客向けの
人月単価を工数に乗じて求める。
- 原理原則[1] ユーザとベンダの想いは相反する
- 原理原則[2] 取り決めは合意と承認によって成り立つ
- 原理原則[3] プロジェクトの成否を左右する要件定義の先送りは厳禁である
- 原理原則[4] ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則[5] 多段階の見積りは双方のリスクを低減する
- 原理原則[6] システム化実現の費用はソフトウェア開発だけではない
- 原理原則[7] ライフサイクルコストを重視する
- 原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
- 原理原則[9] 要件定義は発注者の責任である
- 原理原則[10] 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則[12] 表現されない要件はシステムとして実現されない
- 原理原則[13] 数値化されない要件は人によって基準が異なる
- 原理原則[14] 「今と同じ」という要件定義はありえない
- 原理原則[15] 要件定義は「使える」業務システムを定義すること
- 原理原則[16] 機能要求は膨張する。コスト、納期が抑制する
- 原理原則[17] 要件定義は説明責任を伴う
◆ 一般的なプロセスを踏んでもまだ足りない
もっとも、この見積もりプロセスは、あくまで一般論にすぎない。実際には工数
見積もりにおいて開発作業や成果物を分解したWBS（Work Breakdown Structure）を
作成する必要がある。期間見積もりでは、工数に対する最適な期間があるので、むや
みな短納期化を避ける調整も必要だ。価格見積もりでは、人月単価の相場を知らなけ
れば法外な見積もりになる。
さらにブレない見積もりとするには、FPやSLOCを正しく計測するスキルも身に付
けなければならない。WBSの作成においては、成果物ベースとプロセスベースによる
分解のテクニックも求められる。期間見積もりでは、要員を追加した場合の管理面
のオーバーヘッド、スケジュールの並行化のワザも押さえておきたい。
最近、見積もりミスが原因でプロジェクトが失敗する例が目立ってきた。ベンダー
側は精緻な見積もりを算出するスキルを、ユーザー企業側は見積もり精度を見極める
スキルを磨く必要がある。
（日経SYSTEMS 池上俊也＝）
ITproメール 2014年11月4日
