見積りを破綻させる理由とさせない方法
国際的なプロジェクトマネジメント標準であるPMBOK（Project Management Body of Knowledge：プロジェクトマネジメント知識体系）では、プロジェクトの見積り精度について、以下のように示されています。
建築業界ではほとんどの工事は見積り額の－10～＋10％に入るといわれており、多少誤差はありますがこのPMBOKの定義とほぼ一致していることになります（元々、ITのマネジメント技術の殆どは建築業界から模倣したものなので、当然と言えば当然ですが）。
これに対しシステム開発では、最終的にはどのくらいの見積り精度なのでしょう。
感覚値ですが、おそらくは－20～＋100％ぐらいになっているのではないでしょうか。
なぜシステム開発においては、見積り精度が出ないのでしょう。
これには、いくつかの理由が考えられます。
機能の洗い出しが不十分
言い換えるなら「成果」の洗い出しが不十分ということです。
アウトプットとして必要となる成果を洗い出せていないということは、その成果を仕上げるために必要な作業が洗い出せないということです。作業が洗い出せなければ、その作業にかかる工数が見定められないため、当然ながら見積もりに反映されません。
見積りに含まれていなかったのに後々になって必要性が生じた場合、
・スケジュールが不足する
・リソースが不足する
・それらを詰めるとコストが不足する
確定（正式）見積りを算出するためには、プロジェクトで開発する
「システムの機能」とその「難易度」
が分からないといけません。
しかし、見積りを算出する段階でそもそも機能はすべて明確になっているかと言うと、多くのプロジェクトにおいて残念ながらそれはありえません。機能が明確でないのに見積りを提出しているとすれば、その精度はそもそも期待できなくて当然です。
見積りの手順が確立していない
システム開発においては、「見積る人によって金額に倍の開きが出た」というような話をよく聞きます。
なぜか。
見積り方がフリーダムだからです。
しかも、見積り根拠を明らかにするエンジニアというのはあまりいません。なぜなら「工数見積り」というと、
単位あたりに要する工数 × 担当する人の生産性 × 単価
が必要になる…ところまではいいのですが、この「担当する人の生産性」が企業ごと、部門ごと、担当ごとに変わります。
単価も変わるのでしょうけど、ますます説明がつかなくなっていきます。
単価は大手企業になればなるほど高くなる傾向がありますが、その背景には
「ポストが増えすぎて実務をしない管理職が増えすぎ、彼らを養う必要がある」
「販管費に予算を投じすぎて利益率が下がってしまった」
といった事情を耳にしたこともあります。心底お客さまにとってはどーでもいいことですから、当然説明するわけにはいきませんよね。
たとえば同じ機能に対してＡ社の見積りが50万だったときに自社の見積りが70万だったとしたら、そこに生じる20万の差をみなさんはいかに説明しますか？
ビジネスとして契約を締結する以上、Ａ社も自社も品質は100%で提供するつもりでいるでしょう。期限はお客さまが定めた期限で納品・リリースすると思います。にもかかわらず20万の差が生じる…まさか「うちの要員はＡ社よりも生産性が低いので、そのぶんお金がかかっているんです」とは言いませんよね。ですが、恥ずかしくて言えないだけで暗黙ではそうなっているにすぎません。
大まかな機能内容を見て、個々の生産性を安定させる施策を講じるでもなく「エイヤ！」で見積もるなんていうのは乱暴このうえない話であり、人によって大きなばらつきが出るのは当然です。
多少なりとも見積りがわかっている人は、それをマイナス方向にブレさせる（減額する）のではなくプラス方向にブレさせる（増額する）よう調整します。後述しますがよく使う言葉では「バッファ」と呼んだりしますが、このバッファとして積み上げた金額は要するに
「よくわかんないからとりあえず積んどこ」
という主旨のものです。
リスクバッファとかコンティンジェンシーバッファとか、言い方はいろいろありますが、それらのバッファとして積み上げた工数や金額に対して明確な根拠はありません。
わかりやすく言うと"ぼったくる"わけです。
このような見積りをしている限り、見積り精度の向上は期待できません。
リスクをお客さまと共有し、お客さまの予算として積み上げてもらっておいて、本当にリスクが顕在化した際に追加請求することで対処する…というのであればわかります。
しかし、そうした誠実な対応をとるでもなく、またそうしたバッファを積み上げていることを明確にお客さまに説明するでもなく、ただただ最初の見積もりの中にこっそり組み込み、何事もなければごっそり利益にしてしまおう…なんて考え方では、まともなビジネスとは言えません。
最近はファンクションポイント（ＦＰ）法などの、もう少し客観的な見積り手法も広まってきていますが、ＦＰなどの方法を採用したとしても組織全体できちんとした見積り基準を確立している会社はまだ多くないのが実情です。
予備をきちんと確保しない
先ほどお話ししたバッファのことを言います。
プロジェクト…中でもＢ２Ｂにおけるプロジェクトの特徴は、
期限が決まっているという「有期性」
毎回違う仕事をするという「独自性」
そのほかにも
絶対と呼べる回答が存在しないという「不確実性」
にあると言われています。
その中でも特にこの"独自性"がプロジェクトのリスクの大きな要因となっています。
つまり、毎回同じ仕事をしているのであれば、だんだんと仕事にも慣れて失敗する確率を下げることができるのですが、プロジェクトは常に新しく、常に違う（100%同じにはならない）仕事をするためにどうしてもリスクが低くならず、失敗する可能性がつきまとうのです。
このようにプロジェクトには常に何かしらのリスクが存在するため、それに対処するために何らかの準備・予備を用意しておく必要があります。
ところが、日本ではリスクマネジメントの考え方があまり定着していないために、このような準備や予備を上乗せすると、
「何を甘いことを考えているんだ。そんなリスクは発生しないように頑張れ」
などといわれ、根性論に走らされる企業も少なくありません。この点はＩＴ企業だけでなく、ＩＴを利用する"顧客"企業側も意識の改善が必要な部分になります。
見積りの数字的な欠陥
一般に、定常作業のタスクのコストや納期のばらつきは正規分布に従うといわれます。
これに対して、プロジェクトのタスクのばらつきはベータ分布または三角分布に従うといわれ、原則として左右非対称になります。
この分布の平均は最頻値よりも大きくなります。従って、この最頻値を積み上げた"見積りを守れる確率"は50％以下と言うことになります。
一般的に、この最頻値を積み上げた見積りが守れる確率は10～15％程度といわれています。
つまり、予備を持たない最頻値を使った通常の見積りをしているとすれば、それは10～15％程度しか見積り通りに達成できる確率がない見積書を作っていることになりうる、そういう見積もりを得意げにしているのだと覚えておきましょう。
正確な見積りを作成する方策
必ずしも実現可能かどうかは分かりません。
理想論、空想論かもしれません。
しかし、正確な見積りにするためにはやはり以下のようになるよう最大限心がける必要があります。
漏れのない機能の洗い出しを行う
正確な見積りの第一歩は、必要な機能を漏れなく洗い出すことです。
そのためには、要件定義が漏れなく行われていなければなりません。
これができていなければ、そもそも正確な見積りを行うことはできません。
たまに要件定義から…というか機能仕様までの合意形成が図られていない段階から請負契約をしたがるプロジェクトを見かけますが、そういった人たちは今一度ＩＰＡ（旧 経産省）が以前から警告し続けている契約モデルを見直したほうがいいでしょう。
歴史を紐解けば易々とわかることですが、いかに公共系のＩＴプロジェクトで「契約」がらみで揉めてきたか、そのリスクがわかります。
しかし実際には、要件が完全に確定していない段階で見積りを行わなければならない場合もあります。この場合は、リスクを見込んだ見積りを作成することになります（これが"見積条件"に表現されることになります）。
もし、要件も確定していない超概算見積りを作成するのであれば、＋100％のブレが出ることを想定して見積りを行うことになります。
見積もり手順の確立
たとえばフレームワークやミドルウェアを多用するWeb中心の開発では、従来のようなステップ数を基にした見積りはあまり意味がありません。そのため、多くの会社がＦＰ法などの画面、帳票や機能数と難易度をベースにした見積りを採用しています。
しかし、ここで問題になるのは、この方法が『会社内で標準化されているか』です。
また、『その標準化されている内容が正しいといえる根拠があるか』です。
大手メーカーはともかく、多くの会社は担当者や部署ごとにバラバラな見積りをしていることでしょう。なぜ標準化が必要かというと、会社として標準化した方法を採用していないと生産性のデータが取れなくなり、見積りの精度を上げていくことが難しくなるからです（たとえば、大手メーカーの多くが基準値を持っているのは、標準化とデータ収集を日頃から行っているからに他なりません）。
適正な予備の確保
すでに述べたように、適正な予備を確保することはプロジェクトにとって必須です。
ここでいう予備とはコストだけではありません。人的リソース、スケジュールリソース、リスクに対するバッファリソース、etc.…様々なリソースの"予備"…つまりは、
「何があっても対処できる、準備と段取りが予め備えられているか？」
という意味での『予(め)備(える)』です。
予備には、コンティンジェンシー予備とマネジメント予備の２種類があります。
前者はリスクマネジメントの一環で洗い出したリスクに対応して取る予備で、各リスクの内容を見て予備を設定することになります。
たとえば、
下流工程以降、逼迫するリスクを考えて、
要員計画上、すぐに回せるポジションの仕事を１～２名作っておくか
と言った具合です。
これに対して後者のマネジメント予備は、予測できないリスクに対応するために取るもので、一般的に見積もった全体のコストやスケジュールに対して一定の割合を上乗せするなどの方法が取られます。
たとえば、
バグは出るだろうから、今の工数×1.15倍くらい工数を上乗せして計算しようかな
計算式を見せると拒否されるので、単価に上乗せするか…それとも他の費目にするか
という感じになります。
見積もりに際しては、これらの予備を適切に加味することが重要です。
見積もりの数字的な欠陥への対策
最頻値による見積りは、コストとして楽観的な見積りになってしまうことは数学的に証明されています。これに対する一番適切な対応は、
PERT分析などの楽観値、最頻値、悲観値を使った"３点見積り"を行う
ことです。
しかし、この方法は慣れないうちは非常に手間がかかるため、得てしてしっかり導入している企業は多くありません（アジャイル開発をメインで行う企業やベンチャー企業では作業見積りなどでも見かけますが）。
個人的にはクリティカルパスを把握する際に用いたり、プロジェクトバッファの計算に用いるうえでもPERT分析は必ず実施するマネジメント業務の１つと見込んで活動しているのですが、案外同じことをやっている人をこれまで在籍した企業のなかでは見たことがありません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。