システム開発工数見積もり方法の奥義を探れ!

プロジェクトの成否はまず見積もりから

のっけから難しいテーマです。

見積もり金額の正確性いかんによってプロジェクトの成否が決まると言っても過言ではありません。高ければコンペに勝てませんし、かといって安すぎればリスクヘッジできません。
ERP構築とか基幹システムが絡むものであれば、数億の赤字プロジェクトなんてこともあり得るのですから、大手SIerの単価が高いのもある程度はやむを得ないと思います。

一方でフリーエンジニアは数万円の案件を叩き合っているというのも、これまた現実であります。一人で開発できるレベルのものであれば、おおよその工数予測というのは経験から導き出されるものなので、受注単価はお客様が納得していただける算定根拠さえ示せればあとは人柄勝負かもしれません。

システムの見積もり金額って何故バラバラなの?

ではある程度の規模を持ったシステムの開発工数算定について、明確な指標というのはあるのでしょうか?

人月単価、ステップ数、ファンクションポイント等々いろいろ手法はあるものの、管理工数や設計、テスト、打ち合わせなど製造以外の工数は結構多く、最終的な算定根拠は見積もり担当者の匙加減というのが残念ながら現状です。

大手と中小企業や個人事業者では、同じシステムでもヘタすると10倍くらい見積もり金額に差が出たりします。これは実際のところ瑕疵担保責任能力の有無による安心料が大部分を占めています。

お客様がどこに価値を求めるのか、目先のコストなのか、確実なプロジェクトの成功なのか、はたまた無難に波風立たずに終わることなのか、ご担当者の立場や指向によってそこは変わってくる訳です。
「わたし失敗しないんです!」と、いくらフリーエンジニアが叫んでも大手の体制には敵わないですし、逆に個人中小の小回りには大手は敵わないものです。

あなたが発注者側であれば開発業者に何を期待するかを、受注者側であればお客様が何を期待しているのかをしっかり把握する、その辺がおかしな見積もりに翻弄されないポイントになってくるでしょう。そのためにはどうすれば良いでしょうか。

適当な見積もりには悲劇が待っている!

現在某プロジェクトに御意見番として参加しています。PMOなんて格好いいものではありません。なんせプロジェクトの途中で呼ばれて参加したのですから……。
先ず、どんなシステムを開発中なのか把握するところからスタートしました。

社内SNSでこれまでの経緯が管理されているということなので一通り見ていったのですが、場当たり的な議事録だけでまともなドキュメントが見当たりません。
見積もり仕様書は? 要件定義書は? 基本設計書は?
このプロジェクト、web案件ではありますが、単純なホームページ作成の類ではありません。千万円単位の受発注金額であるにも関わらず、発注者側からも受注者側からもろくなドキュメントが出ていなかったのです。

アジャイルとか格好いいキーワードがありますが、千万円単位のプロジェクトはアジャイルで進行することはできません。それは場当たり的というのです。
結局、実態把握はしつこいヒアリングとその時点での成果物を見ることによって何とかなったのですが、案の定要求仕様に対して成果物は穴だらけ。検証するのも憚られるような代物でした。

発注者側にも問題が。見積書請求前に必要なこと

そんなこんなで客観的な指摘をしていったことがきっかけで、お客様と業者の和気あいあいとしたプロジェクトの空気は吹き飛び、プロジェクトリーダー交代、基本設計やり直し、システムは作り直しとなりました。図らずも私はデストロイヤーとなってしまい、顧客からは感謝されたものの、業者側からは恨み辛みの嵐です。

ただ既に発注済み案件なので、何とか予算内で収まるように仕様に対していろいろ首を突っ込みました。
難しいアルゴリズムで考えられていたものをweb標準のAPIに変える提案をしたり、システムそのものの単純化を提案することで、逆に業者側のプライドが喚起され困難な状況を何とか脱することが出来ました。

ここでお気付きになったかと思いますが、見積もり段階でも見積もり仕様書つまりRFP(提案依頼書)が必要だということです。
最低限のドキュメント作成は、実は発注者側にも義務があって、小さなプロジェクトを対象とした下請法にもその辺は明記されています。要求仕様無きところに見積もりはありません。お客側から提示が無ければしつこく聴くしかありません。

システム開発の上流工程と下流工程を切り離す!

発注者側の立場からすれば、「そもそもRFPを書けるだけのスキルが無いよ」というケースもままあると思います。

そんな場合の解決策ですが、ITコンサルタントの活用が考えられます。
ある程度大きなプロジェクトであれば、最上流工程を別で予算化するわけです。別に超高額なシンクタンクに依頼せよと言っているのではありません。今はフリーエージェントのコンサルが結構いるので、1名分の人月単価で一定期間予算化し、そこで内部的に要件をしっかりまとめるわけです。RFPがあれば業者側も安心して見積もりが出せますし、各社ごとの見積もり精度についてはコンサルタントがジャッジできます。

予算化のための見積もり依頼

それでも「そんな手順は踏めないよ」というケース、予算化の観点でアバウトな見積もりを依頼するされる場面は結構多いと思います。

今度は業者側の立場として考えてみましょう。

PERT(Program Evaluation and Review Technique)というスケジュール管理の考え方があります。
これは楽観的、悲観的、中庸の3つのケースを想定して工数算定を行うものです。予算化の段階であればバッファは許されると思います。
お客様に対してしっかりリスクの説明をして一応「松竹梅」を提示したうえで金額の高い方を出すわけです。
この段階でこれは高過ぎるとかいろいろ顧客の反応は探れるわけですから、最終的に相見積もりになった場合でも根拠を明示した適切な見積もり金額を提示できることでしょう。

あとは第三者のレビューを受けることもたいへん有効です。見積もりも第三者の視点にさらされれば、それが適正か否か気付かなかった点まで指摘してくれます。

結局工数見積もり方法の奥義はあるのか?

ここまで読まれて、見積もり金額というのは発注者側の立場・受注者側の体制や立場によって大きく変わるものだということはご理解いただけたかと思います。フリーコンサルの活用やPERTや第三者レビューといった方法論もご紹介してきましたが、結局のところ工数見積もり方法の究極の奥義は存在するのでしょうか?

いい加減な見積もり依頼、それにもましていい加減な見積もりが無くならないのは、単純な話でお客様の側も請ける側も要求仕様が見えていないためです。

本末転倒な結論かもしれませんが、プロジェクトはヒアリングが全ての成否を握ります。お客様から要求仕様の提示がなければ訊いてください。しつこく訊く、それしかありません。それによってお客様が気付くこともあるでしょう。もしそこで回答を拒否されるようであれば、そのプロジェクトは請けてはいけません。リスクがありすぎます。

逆に発注する側の立場で考えた場合、何も訊いてこない、何も提案してこない業者を信用してはいけません。ただ金額だけで判断すれば、あとで思わぬ失敗の連鎖が待っています。結局のところ失敗しない工数見積もりの奥義は 『コミュニケーション』 に尽きると思います。

難しい方法論を求めていた読者には肩透かしかもしれませんが、コミュニケーションがシステム開発に限らずビジネスの本質です。皆さまのプロジェクトの成功をお祈り申し上げます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)