前回まで、ユーザー企業がソリューションプロバイダの提案書を評価する7つのポイントを紹介してきた。最終回の今回は、特に見積もり根拠の書き方について、その問題点を指摘すると共に、ユーザー企業がどのような視点で見積書を評価しているかを紹介したい。

 前回(第5回)、「コストの妥当性」の説明の中でも述べたが、提案書上ではソフト開発の見積もりに関しては総額でしか示されないことが多く、ほとんどの場合、その見積もり根拠は全く示されない。

 特に、要件定義工程の前の見積もりでは不明な点が多く、細かな計算式までを提示するのは、ソリューションプロバイダにとってリスクが高い。また、ユーザー企業の業種や業務に対する知識の有無が、その精度を左右することは否めない。しかし、要件をユーザー企業に何度も確認し詰めていくことによって、その精度を高め、競合他社に差をつけることが可能になるはずである。

 さらに工程が進み、基本(概要)設計、詳細設計工程の見積もりとなると、細部がよく見えるようになるわけなので、相当細かな見積もり根拠を提示する必要が出てくる。しかし多くの場合、ユーザー企業から要求されなければ、ソリューションプロバイダが詳細な見積もり根拠が提示することはない。

 この点に対して、ユーザー企業は大きな不満を抱いている。JUAS(日本情報システムユーザー協会)の調査でも、ソリューションプロバイダに対する不満の第2位に「見積もり金額の妥当性が不明」を挙げており、「価格が高い」などを上回っている(不満の第1位は「企画提案力不足」)。しかし、改めてよく考えてほしいのは、数千万円あるいは数億円といった金額の契約書に、根拠が示されないまま押印できるだろうかということだ。

 確かに今までは、そういったことが行われてきたが、ユーザー企業も一層厳しい目を持ち始めているのである。筆者の経験でも、あるユーザー企業が何度も見積もり根拠の提示を求めていたにもかかわらず、根拠の提示を拒むソリューションプロバイダがあり、大きな不信感を抱いていたことがある。結局筆者が間に入り、可能な範囲で人月単価、想定工数、計算式、予定成果物を提示してもらったことで、ユーザー企業はようやく納得した。

 ソリューションプロバイダには、余計な数字を出すと突かれるといった不安があり、具体的な根拠を提示することを避けようとしたのかもしれない。しかし、具体的根拠を提示した上で、想定できないリスクに対してもユーザー企業に理解してもらうように説明した方が、より良い結果になるのではないだろうか。

根拠が分からないPMの人月単価

 それでは、ユーザー企業が見積書を評価する際の視点について説明したい。先に書いたように、特に基本設計や詳細設計では、ユーザー企業は詳細な見積もり根拠の提示を求める。

 ソリューションプロバイダが見積もる際には、まず作業規模の見積もりを行うはずだ。作業内容のブレークダウンには、WBS(ワーク・ブレークダウン・ストラクチャ)など、ソリューションプロバイダごとの社内標準があり、それに基づいて、システム構築のための作業と成果物を洗い出し、作業ごとに必要なスキルとおおよその工数を求める。工程が進むにつれ、画面や帳票ごとの難易度や流用(類似)度などから個別の工数を求め集計する。多くの場合、ソリューションプロバイダの経験(実績値)から作業工数などを求める。

 FP(ファンクションポイント)法などによりユーザー企業に社内での実績値などを提示できると、説得力は非常に高くなるだろう。FP法を用いなくても、難易度や規模ごとの実績値を出すことも有効である。ただし、ここまで具体的な数値を出す場合には、ユーザー企業との間で守秘義務契約書を結んでおく必要がある。また、納品物とするかどうかは別にして、作業ごとの成果物を明確にすることで、ユーザー企業の納得度を高めることができる。

 次に、人月単価の問題である。多くの場合、「見積もり金額=工数×人月単価」であるため、人月単価がどう設定されるかで総額が大きく異なってくる。人月単価の10%の違いは総額の10%の違いとなり、例えば1億円規模のプロジェクトであれば1000万円の差が生まれる。売り上げ利益率が3%のユーザー企業が1000万円の利益を得ようとすると、それは3億3000万円の売り上げに相当することを認識する必要がある。

 人月単価は一般的に上級SEや中級プログラマといった職種で決められているが、ソリューションプロバイダごとにその職種の設定や単価が異なっている。大手ソリューションプロバイダでは中級SEの人月単価は140万~150万円、中級プログラマで90万~100万円といったところが現状だろう。

 しかしITRの調査では、大手と中堅・中小ソリューションプロバイダの人月単価には大きな開きがあり、場合によっては2倍もの差がある。例えば極端な話をすると、大手ソリューションプロバイダが1億円で受けるプロジェクトなら、中堅・中小であれば5000万円で可能ということである。しかし、一般的には大規模プロジェクトで中堅・中小ソリューションプロバイダがプライムをとることはほとんどなく、大手ソリューションプロバイダの下につく形になる。

 そうした場合でも、大手ソリューションプロバイダの提案書では、中堅・中小ソリューションプロバイダの工数分も大手の人月単価で積み上げられ、高額な見積もりとなる。昨今ではオフショア開発も増え始めており、大手と中堅・中小の単価差は一層広がるだろう。ユーザー企業も、複数の協力ソフト開発会社が参画することを知っており、それらの単価が大手よりもはるかに低いことも知っている。

 ユーザー企業は、大手ソリューションプロバイダに対して、たとえ安価な中堅・中小のソフト開発会社を使おうとも管理面での充実と完成保証を期待しており、多くの場合、協力会社分の単価を下げろとは言わない。従ってソリューションプロバイダは、協力会社がどこにどのように参画するのかを示し、自社で十分に管理し、自社要員と同様の能力を発揮させることを明言することで、ユーザー企業の信頼度を高めることができるだろう。当然、その協力会社の自社との関係や実績を明確に示すことも必要である。

信頼度高める生産性向上、品質向上施策の明示

 体制面では、ほかにも問題が散見される。ユーザー企業にとって最も不明瞭であるのが、PMを中心に複数でプロジェクト管理を実行する場合である。プロジェクト管理については、成果物は明示されず、単純に「人月単価×工数」で見積もり金額が提示される。プロジェクト管理の成果物とは「プロジェクトが予算内、期間内で完了し、高品質のシステムを稼働させる」ことであるから、人月との関係はよく分からない。

 優秀なPMクラスなら全体工数の7~8%の管理工数でプロジェクトを成功裏に完了させることができる半面、全体工数の13~15%もプロジェクト管理工数をかけても成功できない場合もある。プロジェクト遂行能力については、第4回で述べたのでここでは重複を避けるが、空いている人材や経験を積ませたいPM要員を、安易にユーザー企業のプロジェクトにPMとしてアサインすべきではない。もしその必要があるのであれば、ソリューションプロバイダとして組織的なバックアップ体制を充実させるべきである。

 筆者が提案書の体制図を確認して、いつも問題だと思うのは、プロジェクト管理チーム内の役割分担である。例えば、PMと2人のサブPMが存在しているような場合、3人の役割が明確であることは少ない。しかも、役割分担が明確でない場合の多くは、プロジェクトの失敗につながっている。ユーザー企業に3人分の工数見積もりを出す以上、3人の役割分担を明確に示す必要があるだろう。少なくとも、こうした高単価の人材が、SEやプログラマがやるべき作業を行うべきではない。

 システム開発における生産性向上施策や品質向上施策も、見積額に影響を与える。ソリューションプロバイダは、生産性と品質を高めるための社内標準を保有しているはずだが、そうした管理方法や各種施策をユーザー企業に提示するのも効果的だろう。生産性が高く、品質管理が十分に行き届いていれば、効率的・効果的開発が可能となり、無駄な工数はほとんど発生しないと期待できるからである。

 生産性向上施策には、パッケージの活用や、ツールの活用、ソフトの部品化などが挙げられる。それらをどのように活用し、どの程度の生産性向上が期待できるかを提示できるとよい。一方、品質管理施策に関しては、こうしたツールの活用による品質向上を明示するとともに、どれくらい徹底した品質管理を実施し、それによって無駄な後戻り工数をどの程度削減できるかを示すとよいだろう。また、ks(キロステップ)当たりのバグ検出目標などの数値を示すことによっても、ユーザー企業の信頼度を高めることができる。

 こうした生産性向上施策や品質向上施策を提示した上で、ブレークダウンした見積もり工数を示すことにより、ユーザー企業に効果的な管理が行われるとの期待を抱かせることができる。それにより、見積もり工数を納得させることも可能となるだろう。

 最後に、筆者がユーザー企業に対して、ソリューションプロバイダから見積もりの提示を受ける際に、どのような形で根拠を提示してもらうように助言しているかを一部紹介しておこう()。全工程を通した共通的な考え方と工程ごとのチェックポイントに分かれている。考え方の基本は、ユーザー企業が提示された金額をどれだけ納得できるかである。第5回でも紹介したが、ユーザー企業は納得できる内容であれば20%程度のリスク分の上乗せは認めてくれる場合が多い。総額の中に隠すのではなく、リスク分を明示し、その具体的な根拠を提示することによって、ユーザー企業の信頼の獲得につながる。

図●見積もり根拠の記述方法
図●見積もり根拠の記述方法

 つまり、ユーザー企業の立場で提案書を作成することである。見積もりに関しては、特にそれが必要である。根拠が明示されないまま数千万円、数億円という契約書に簡単に押印するユーザー企業は明らかに減少している。ユーザー企業の期待や不安に応える提案書や見積書を作成できるソリューションプロバイダの勝算は、今後ますます高まっていくだろう。

広川 智理
アイ・ティ・アール 取締役 シニア・アナリスト
1977年にNEC入社、グループ内のシステム企画、開発、運用に携わる。2001年にアイ・ティ・アールに入社、翌年に取締役。オフショアアウトソーシングを含むベンダーマネジメント領域を得意とし、ユーザー企業の見積書妥当性評価などを支援