PR

システム要件が固まっていない段階で,構築費用を見積もるのは難しい。受注を目指すITエンジニアとしては,どうしても低めに見積もってしまいがちだ。しかし,精度を度外視した見積もりは結局,顧客に迷惑をかけることになる。

イラスト 野村 タケオ

 Sさん(33歳)が,企業向けシステム構築大手のZ社に入社したのは10年前。いまや,顧客に対するサービス担当リーダーを務めるベテランSEに成長した。4月には課長代理に昇進し,一段と仕事に燃えている。

 そのSさんはある日,A社から嬉しい相談を受けた。同社の情報システム部門を率いるNマネジャーに,「販売管理システムを全面刷新したい。ついては,新システムの予算を申請するために概算費用を見積もって欲しい」と頼まれたのだ。

 A社は,鞄やハンドバッグの輸入販売業者である。業界では老舗として高い知名度を誇っているが,近年の消費不況により売り上げは低迷していた。そこで,「現状を打破するには,これまでの商売のやり方に甘んじていてはいけない」と判断。従来の店頭に加えて,電話やインタ-ネットといった新たなチャネルによる通販事業を展開しようとしていた。

 今回のシステム刷新は,こうした販売チャネル増に伴う取り組みだった。新システムの狙いは,複数の販売チャネルからの受注を的確に処理するとともに,受注から在庫引当,出荷までのリードタイムを短縮すること。併せてデータベース・マーケティング・システムの導入を計画しており,かなりの大型プロジェクトになりそうだった。

受注のために工数見積を圧縮

 Sさんは,この案件に特別入れ込んでいた。従来の販売管理システムを開発したのが,Z社にとって最大のライバルD社だったからだ。Sさん自身も,大きな案件を目の前でさらわれた苦い経験がある。それがついに,一矢報いるチャンスが来たのである。

 「D社が構築したシステムをひっくり返せたら,お手柄だぞ」。Sさんは,高鳴る胸を押さえて作戦を練った。「A社はおそらく,D社を含むベンダー数社に相見積もりを依頼するだろう。その中から選んでもらうポイントは,やはり価格だ」。概算見積の提案段階でNマネジャーの想定を下回る見積金額を提示できれば,競合他社に対して圧倒的に有利な立場に立てる。Sさんはそう考えた。

 さっそく,A社におけるドキュメントや出力帳票を分析して新システムの大枠を組み立てた。さらに,Nマネジャーから予算規模についてさりげなく聞き出し,それよりも見積金額が安くなるように開発工数を低めに調整した。

見積もりの甘さが露呈

 3カ月後,Nマネジャーから連絡が入った。Sさんの作った概算見積に基づくシステム予算が,A社の役員会で無事承認されたという。しかも,「この金額なら,他社とのコンペを実施するまでもない。Z社に開発を引き受けてもらうことになったよ。もちろん,提案してくれたSさんにプロジェクト・リーダーを任せたい。ぜひ成功させてほしい」と激励された。Sさんは,「よし。A社の期待に応えて素晴らしいシステムを構築してみせる」と心に誓った。

 それから3カ月ほどかけて,今回のシステム刷新の対象になる業務範囲の確定や業務処理要件などの詳細を検討。基本スケジュールの策定や開発工数の詳細見積へと進めていった。ここまで,極めて順調に進んだように見えた。

 ところが,改めてシステム構築全体の詳細見積を算出したSさんは青くなった。はじめに提示した概算見積を,大幅に上回ってしまったのだ。特に,開発工数は当初の見積もりに対し60%以上も超過していた。結果として,全体のコストが大幅に割り増しになる上に,納期にも影響を与えることは明白だった。

顧客に予算修正を強いる

 あわてたSさんは,工数見積の基礎にした開発の生産性基準を見直したり,作業の手戻り予想を少なめにするなど手を尽くした。しかし,そうした見直しにも限界がある。開発の生産性基準を甘くすれば,システムの手直しが発生する度に工数ギャップが大きくなってしまう。

 その一方で,手戻り予想にある程度の余裕を持たせなければ,システム品質を保証できなくなる。結局のところ大して工数を削減できず,全体の超過額を30%に抑えるのが精一杯だった。Sさんは途方に暮れて,Nマネジャーに泣きついた。「当社ではこれ以上,どうにもできません」。

 Nマネジャーは「今になってそんなこと言わないでくれよ」と頭を抱えてしまった。実はNマネジャーは,Sさんが最初に提示した見積もりに2割ほど上乗せした予算を確保していた。Sさんの見積もりが,受注獲得を意識した“営業用の見積もり”であることを見越していたからだ。しかし,まさかここまで現実とかけ離れるとは思っていなかった。「要件が定まっていない段階と,要件定義後では見積金額が違うのは仕方がないと思うよ。でも,ここまで差があるのでは,もはや『見積もり』とは呼べないだろう」。Nマネジャーは,Sさんを叱りつけた。Sさんは,ひたすら頭を下げるしかなかった。

 とにかく,Nマネジャーに悩んでいる暇はなかった。すでに詳細設計のフェーズまで終えている。今さら依頼先を他社に変更しては,システムのカットオーバー時期が大幅にずれ込む。社の命運をかけたシステム刷新だけに,計画自体を延期したり中止するわけにはいかない。やむなく追加予算を申請したNマネジャーに,社内から批判が相次いだのは言うまでもない。

 「他社が構築したシステムのリプレース」という功を焦ったばかりに,顧客に多大な迷惑をかけてしまったSさん。今は,開発スケジュールや要員体制をやりくりして,増加した開発工数が納期に与える影響を最小限にとどめるのに必死だ。

今回の教訓
・何のための見積もりか,その使用目的や状況を十分に考える
・過小見積は,過大見積と同様に役に立たない
・見積もりには他人の意見を取り入れて,チェック機能を働かせる

岩井 孝夫 クレストコンサルティング
1964年,中央大学商学部卒。コンピュータ・メーカーを経て89年にクレストコンサルティングを設立。現在,代表取締役社長。経営や業務とかい離しない情報システムを構築するためのコンサルティングを担当。takao.iwai@crest-con.co.jp