見積りの誤解

PM

｢見積り｣は，｢ターゲット｣ではない

プロジェクトが失敗する原因の中でも，大きな比重をしめるのが｢見積り｣ではないでしょうか．正確に言うと｢見積り｣ではなく，トップダウンで理由が不明確(政治的という意味は明確)に指定される期日，｢ターゲット｣が元凶ではないでしょうか．その｢ターゲット｣を｢コミット｣させられてしまったPMは，｢見積り｣と｢ターゲット｣があまりにかけ離れていることを，どうやってプロジェクトメンバに説明したらいいのか悩んでしまったりします．優秀なPMは，｢ターゲット｣と｢見積り｣の差を定量的にステークホルダに説明することで，あり得ない｢コミット｣を避けるか，適正な条件を彼らから引き出すようにします．｢見積り｣は，｢ターゲット｣｢コミットメント｣とは違うということをまずは理解しましょう．

良い見積りとは，プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで，適正な意思決定ができる明確な視点を提供する見積りである．[ソフトウェア見積り Steve McConnell]

達成可能な想定範囲

クライアントまたは上司の立場で考えてみよう．見栄やプライドをはるところではない．クライアントが望むこととは，成果物を手に入れる事，望まないこととは，手に入れられない事である．つまり予算オーバー，期間オーバーにより，想定範囲外になることを望まない．だからはじめに，なるべく正確な達成可能な想定範囲というものを提示してあげるべきでしょう．

一方，プロジェクトの立場で考えるとどうなるか．もし自分がそのプロジェクトの下請け会社の社長だったら…．｢コミット｣された期間を大幅に超えたら，二度と仕事をもらうことができなくなってしまうでしょう．

想定範囲内の信頼ある見積りのメリットは，進捗管理が正確に行える，コストの超過がなくなる，ステークホルダの信用を確保できる，｢ターゲット｣との差により正確にリスクヘッジできる．そして最も大事なことは，プロジェクトメンバの信頼を得ることができる．メンバは，到底無理なスケジュールを強いられてもがんばるわけはなく，むしろ｢できっこないのに…｣とモティベーションを著しく低下させる．

適度な瞬発的なプレッシャーは短期的には効果的があるが，慢性化した過度のプレッシャーは，優秀な人材を灰にし，病気にさせ，しまいには辞めさせてしまう．

リスターの法則
人間は時間的なプレッシャーをいくらかけられても，速くは考えられない．

過去の実績

全く新規のプロジェクトでないならば，過去における同程度の規模のプロジェクトの実績を参考にするのが良い．機能数/規模，モジュール数/規模，メンバの人数，期間といったものだけでなく，メンバのスキル，仕様，環境，開発プロセス，フェーズなどの差分を忘れずに考慮するのが大切である．また経験者，有識者への事前のヒアリングも精度アップには欠かせない．

粒度についてのよくある間違いは，細かくすればよいと思ってしまうことです．場合によるが，0.1日といった見積りはあまり意味がない．合計していくとますますよろしくない．開発者の見積りは，一般に実際の工数よりも20〜30%低くなるといわれている．少なくとも，0.5日単位からが妥当だと思います．上限は，フェーズにもよりますが，タスクレベルなら2日程度，長くとも1〜2週間レベルでないとコントロールができないと思います．有効数字にも気をつけたほうがいいですね．｢55.5日です｣と｢3ヶ月です｣では受け取る側の精度感触が全く違う．

確度も提示できると説明に信頼度が増します．±50%なのか，+5%なのかを付加してあげるとずいぶん違います．後半になればその範囲も狭めていけるはずです．

過小見積りに対する不利益は，過大見積りに対する不利益よりも深刻である．したがって，完全に正確には見積もれないならば,過小見積りよりも過大見積りの方へ誤ることを心がけた方がよい．[ソフトウェア見積り Steve McConnell]

早期のざっくり見積りで有効なのが，代替指標による見積りです．

    • ストーリーポイント：XPで使われるファジー理論に似た手法．ストーリー(要求や機能)ごとに，ポイントを割り当てる．ポイントは，2の累乗(1,2,4,8,16)，フィボナッチ数列(1,2,3,5,8,13)．デジタル予測(1,5,10,25,50,100)．
    • サイズ分け：S,M,L,LL

モジュール単位だけでなく機能単位での見積もりは，クライアントとの機能vs納期の交渉で役に立つのでぜひ作成しておきましょう．

定期的な見直しとレビュー

仕様が未決定なフェーズでは，見積り精度があまいのは仕方ないというか当然ですよね．仕様が策定され，制限事項が判明し，概要設計，詳細設計と進むにつれて，このあいまいさ(ばらつき)は小さくなっていきます．これをイメージで表したのが，｢不確実性のコーン｣[ソフトウェア見積り Steve McConnell]というものです．

このコーンが収束していく過程で，定期的に見直しをかけることは非常に有効で重要です．要求や制限事項はこのフェーズで最も変化します．また非常にクリティカルな問題が発生することもあります．ハードウェアがらみの問題や，アーキテクチャの問題，パフォーマンスの問題など．その場合は，速やかにそしてオープンに見直しをかけなければなりません．再見積り後は必ず，有識者や関係者でグループレビューをして，認識あわせ，漏れ抜けチェック，精度アップをしましょう．

よくある間違いは，｢不確実性のコーン｣のイメージを持ってないPMが，初期フェーズにて無意味に詳細な工数見積りをメンバに要求してしまうことです．指示されたメンバがこのイメージを持っていればよいのですが，そうでないときは，何の疑いも持たずに無意味な見積りに大切な時間を浪費してしまいます．

初期はどうしてもトップダウンの見積りになることが多いですが，見直しをかけていく上でできるならばボトムアップな見積りをしていくべきです．またステークホルダへの定期的な報告も結構重要です．

誤差の原因

  • 不確実性のコーン
  • 規模の不経済
  • 偏った思考/見積り
  • ｢顕在化したリスク｣(RE：Risk Exposure リスク重大度×発生確率)を想定外
  • TODOリストの不出来
    • やらないことまで書き出すつもりで全てをさらけだす
    • 優先度をつける
    • プロジェクトメンバ全員で共有できること
  • TODOリストの見落とし
    • 提示された要求だけでなく，暗黙に示されている要求や非機能要求，つまりすべての要求を含めること
    • 単にコーディングとテストだけでなく，必要なソフトウェア開発アクティビティをすべて入れること
    • 新規メンバの立ち上げ/指導
    • SCM，ビルドサーバ，要件管理ツール，スクリプトなどの保守/管理
    • 新しい開発ツールの学習
    • ユーザドキュメント，テクニカルドキュメントの入力/レビュー
    • デモ
    • 計画，見積り，アーキ，デザイン，コード，テストケースのレビュー
    • 休暇，祝日，病欠
    • 研修
    • 全社/部署Mtg
    • 新PCのセットアップ
    • トラブルシューティング

参考文献

ソフトウェア見積り

ソフトウェア見積り

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解