また、プロジェクトマネジャー（PM）候補が過去の類似したシステムの見積もりと実績を参考にして、リスクの少ない見積もりを行ったり、さらに大規模なプロジェクトの場合は、アプリケーション部分については機能単位などでチームが構成されるため、各チームリーダー候補あるいは経験者が担当機能の見積もりを行うことになる（図1）。この際、各機能の見積もりは、管理が十分に行われていれば作業完遂可能である最小作業工数（A、B、C、D）に、不測の事態に備えるための余裕工数（a、b、c）を加えた「リスクの少ない」見積もりとなる。

図1　ベンダー企業内における見積作業の例（出典：ITR）

　各チームリーダー候補が見積もりを行った後、PM候補はそれぞれのチームリーダーの過去の実績や能力を判断して、さらに安全なプロジェクトにするための上積み（a’、b’、c’）を行う。またPM候補がプロジェクトの損益責任を負う場合には、全体としてのバッファ的な工数（d）を加え、より「安全な」見積もりにしようとする。ベンダーによっては、こうした不確実性あるいは不測の事態に備えるための工数を「リスク分」として、全体工数の15～20％を別枠で見積もるところもあるが、非常にまれである。また見積もりに生産性の基準値を持つベンダーもあるが、その基準値自体が甘いものになっている。

　そして、最後に部門長がバッファ工数（e）を付け加える。これは自部門の損益を改善するために追加される可能性がある工数である。上記はあくまでも例であり、全てのベンダーがこのような方法を採っているわけではないが、こうして膨らんだ見積もりは、ユーザー企業の負担になるばかりではなく、ベンダー内での生産性・品質向上への意欲をそぐことにも作用するのである。

事例に見る見積書精査の重要性と効果

　ここで、ITRが見積妥当性評価を実際に支援した実績から、2社の事例を紹介したい。

　金融業A社では、見積書を十分に精査することなく金融系に強いベンダーB社に開発と保守運用業務を委託していた。ITRはA社から「保守運用コストが一向に減らない」との訴えを受けて調査に入ったところ、「ありがちな実態」が見えてきた。金融系システムであることから、一瞬たりともシステムを止めてはならないということで、数人のSEを24時間体制で常駐させていたのだ。生産性や品質を向上して効率化を図ることはベンダーにとっては売り上げの減少につながることから、ベンダーは障害の徹底した分析や改善を怠り、保守も言われるままに行っていた。

　また、別のプロセス型製造業C社では、ベンダーD社と長年にわたる取引があり、見積書の精査も一切行われることもなく、毎回「出精値引き」で満足していたが、あるきっかけがありITRが見積書の妥当性評価を行うこととなった。評価の結果、ITRが見積書の内容に関して7つの疑問を挙げたところ、ベンダーD社は「誤っていたので、再提出します」として、当初1億9000万円であった見積もりが、約6000万円になって再提示されたのである。ここでもし見積書の精査を行っていなければ、最低でも2億円で発注してしまっていただろう。

　こうした事例から理解できると思うが、見積書精査の重要性とその効果を再認識いただきたい。

　次に、もう少し詳細な実例を挙げよう。図2は、ある組み立て型製造業E社でITRが見積妥当性評価を行った際に発見した「異常値」である。

図2　見積もりの実例（出典：ITR）

　図に示した1つ目の例は、単価600万円ものコンサルタントが、毎週進捗会議に4時間も出席し、その資料作成に毎週9時間もかけるというものであった。会議資料であれば、単価の低い初級あるいは中級のコンサルタントに作成させ、上級コンサルタントはその指導や確認に時間を使うのが一般的だろう。

　2つ目の例は、生産性に問題がある。84の部門に対して同様の調査を実施するにもかかわらず、類似性や学習効果を全く考慮せずに相当余裕を持った見積もりを行っている。1部門当たり5時間を、単純に84部門分にかけているため、3.0人月もの工数に膨らんでいる。

　3つ目は、明らかに不自然な見積もりといえる。新規ではなく現行のシステムフローの作成に6時間かけているが、そのレビューに4時間、修正に5時間と、計9時間も投入する見積もりになっているのだ。しかしながら、ベンダーは通常ここまで細かな見積もりは提示しない。ユーザー企業が何も要求しなければ「一式XX万円」で終わってしまう。ベンダーと根気よく交渉し、ここまで明細を出させて精査することによって、明らかな水増しを発見することができた例である。

適正な見積もりを妨げる、ユーザー側の3つの問題

　見積もりが適正化しないのはベンダーにも大きな非があるが、ユーザー企業が自ら変わらなければベンダーも積極的には対応を変えないだろう。ここでは、ユーザー企業が改めるべき問題を3点、整理しておきたい（図3）。

図3　見積工数を膨らませるユーザー企業側の問題（出典：ITR）

　まず、ソフトウェアの調達に関する規定を保有しないユーザー企業が多い。一般の購買管理規定をそのまま利用しているところもある。一般の購買とは形態などが大きく異なるシステムインテグレーション（SI）の調達に規定が存在しなければ、誰しもできるだけ楽な方法を採ってしまう。当然個人差などを生むことになり、その管理も十分には行えない。

　次に、発注時に明確な要件を提示できないことも大きな問題の1つである。SIの調達において、要件を100％明確にして発注することは不可能に近いことではあるが、不明確な部分が多ければ多いほど、ベンダー側は前述のように見積もりにおけるリスクを大きく見込む必要が出てくる。また開発の過程で仕様の追加や変更が頻発し、結果的にコストが膨らんでしまうことにもなる。

　3つ目が最も大きな問題であると考えるが、ユーザー企業がベンダーの見積書を十分に査定していないことである。時間や能力がないことを理由に挙げる企業が多いが、ユーザー企業が厳密な査定を行わない限り、ベンダーは根拠の明確な見積もりを提示するはずもない。また、ユーザー企業自身が反論データを持たないため、ベンダーを相手に十分な交渉が行えない状況に陥っている。

　まずは、第1回、第2回で解説したようにユーザー企業側が適切なRFPを作成し、要求仕様を満たした、より適正な提案を求めることから開始されたい。このような取り組みは“ベンダーたたき”が目的ではない。ユーザー企業はベンダーとの間に、緊張感のある関係を構築すべきであり、そうすることで、さらに良いサービスを、より安価に享受できるようになるのである。

広川智理（ひろかわ　ともさと）

アイ・ティー・アール　シニア・アナリスト

電気通信大学電子計算機学科卒業後、NECにおいて、NEC本体およびNECグループ向けのシステム企画、開発、保守運用を担当。本社情報システム部門ERP担当部長などを歴任後、2001年より現職。現在は、要求開発／要求管理（BABOK）、プロジェクト管理、オフショア・アウトソーシングなどの分野を担当し、ユーザー企業のITコスト削減、ベンダー管理、見積もり妥当性評価、契約管理を支援するプロジェクトを数多く手掛ける。IIBA（International Institute of Business Analysis）会員