見出し画像

見積りミスを引き起こす原因

見積りは非常に難しいものです。だから、普通にやっていては失敗しますし、"普通"にやってる程度で大丈夫と思っている方がおかしくなるでしょう。

見積りが失敗する大きな要因は、大別すると以下の通りです。

・要求が完全に決定される前に、正式な見積りが求められる場合
・新しい要求が加えられても、見積りは変更されない場合
・主要なソフトウェア開発プロジェクトでも見積りツールが使われない場合
・実績データがなく見積りのキャリブレーション(較正)ができない場合
・保守的な見積りは採用されず、挑戦的な見積りで置き換えられる場合
・見積りに関して根拠をきちんと説明できない場合
・期間と工数に関して、「望み」と「見積り」が混同されている場合
・期待に基づいて計画が立てられる場合
・要求が曖昧な場合、要求が変化し、増加していく場合
・成果物の品質が悪い(顧客の満足が得られない)ことが判明した場合

そういったミスを起こしやすい要因が詰め込まれている"見積り"に対し、私たちは普段どのように実施しているのでしょう。

図2

元ネタは忘れてしまいましたが、それぞれの領域ではこのような方法で見積りされていることがわかっています。かれこれ10年近く前の話ではありますが、これらは今でもほとんど変わっていないところが多いと思います。

少なくとも「見積り」について社内で徹底教育や強化、ルール作りをしている企業はあまり聞いたことがありません。基本的に、個人任せです。

ですので、過半数近くが「経験則」…もっと言うなら勘と経験と度胸(KKD)によって行われていることがわかります。圧倒的に『社内の見積もり基準に基づいた』を上回っていますね。

属人的な方法が減少している一方で、過去の経験則に依存した類推的な方法が残っていることがわかるでしょうか。類推見積りのすべてが悪いわけではありませんが、類推見積りをするには条件のあてはめ方があまりにも杜撰なのです。

たとえば、

・種類:Web系
・規模:400Kstep

という条件だけで過去経験から類推するのと

・言語:javascript
・DB:PostgreSQL
・種類:マイグレーション
・規模:21機能(画面17機能+帳票4機能)
・条件:現行データはすべて再利用できること
    帳票形式は紙ではなくPDF
    多言語対応

などと詳細に条件が提示された場合に、過去経験から類推するのとで、まったく同じ見積りになりますでしょうか。もしも、あなたがPostgreSQLの未経験者だったとしましょう。チームメンバーにも理解している人材が一人もいない場合、おそらくは「難易度」という係数をかけていたかもしれません。

類推見積りには、その正確性、妥当性を導き出すために、類推するだけの明確な根拠を並べ上げなければなりません。ですが、その点が属人任せになっていて、殆どの企業で粒度がピンキリになってしまうのです。

これでは、経験したことがない開発であれば大幅に失敗しますし、経験者の世代交代が起きた時点で、その会社は破綻します。

これに対し、開発を依頼するユーザー企業はそんな見積りをどう見ているのでしょう。

 ・基本的に、基準を持つよりは受身
 ・ベンダ/SIerの見積りに依存

 (2005年度JUAS企業IT動向調査)

委託先への満足度

 ・「価格」への満足22%
 ・「見積り金額の妥当性」は19%(普通が50%弱、不満が35%)

 (2010年度JUAS企業IT動向調査)

ユーザーの方々は、大型投資となるIT導入に対して非常にシビアな目で見ています。今やITなくしてビジネスは成立しない企業が多く、どんなに不安があっても折り合いをつけながらIT投資することになりますが、それでも、やはりエンドユーザはわかっています。

 見積りの根拠が浅薄で、疑わしいことを!

大手SIerの方法論に倣っても、殆どのお客さまは妥当だと思っていません。だからと言って、勘と経験と度胸だけに頼った、根拠が明確でない見積りなどは目も当てられません。根拠が明確でないということは、1回1回、すべての見積方法が少しずつ異なっていてもわかりません。おそらくは本人も説明できません。

一方で、品質などの見えない影響や、納品には直接関係しないプロジェクトマネジメントの工数など、定量的に明確化することが困難なものも見積りしなければならず、常にミスを引き起こす要因がつきまとうことも考えなければなりません。

これは大きな課題です。

特定の企業だけが適切であればいいわけではなく、いずれIT業界そのものが解決すべき事案でもあります。そうしないとユーザーは安心してIT企業に仕事を依頼できなくなってしまいます。

最低限、人に依存しない類推的見積り手法を用いるのであれば、技術要素やニーズ難度だけでなく、プロジェクト活動そのものの実績…中でも

・作業内訳
・成果物量
・生産性
・不良発生件数
・不良傾向

と言った様々な情報をデータ化し、統計分析しなければならない時がくるのではないでしょうか。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。