ソフトウェア開発において、見積もりは必須の作業です。
開発スタイルは様々ありますが、共通して大事と思うポイントについて紹介します。
全部が全部必要というわけではありません。
判断材料として武器を多く持てるようにしましょう。
※個人の経験上、CCPMライクな手法に寄ってるとは思います。
想定読者
プロマネ駆け出し層を想定して書きました。
見積もりの手法
見積もりの手法は山のようにありますが、王道はおさえておきましょう。
2点見積もり
見積もる対象が、「うまくいった場合」と「うまくいかなかった場合」の2種類の見積もりを行う手法です。
よく使われるのはABPとHPによる見積もりかと思います。
ABPとHP
- ABP(Aggressive But Possible)
- HP(Highly Possible)
簡単に言うと、頑張れば何とか間に合うかもの見積もりがABP。
こんだけ工数積んでれば何かトラブっても大丈夫だろうがHPになります。
確度・精度が高ければABPとHPの差は小さくなりますが、要求があいまいだったり技術課題が解決していなかったりと見通しがよくないタスクはABPとHPの差が大きくなります。
それぞれを2点見積もりのインプットとして、例えばABPとHPの中央値をプロジェクトの見積もりとしたり、特殊な係数をかけてプロジェクトの見積もりとしたりすることもあります。
見積もりポーカー
こちらも有名な手法です。
特に開発初期段階や新規性の高い案件で使われることが多いと思います。
具体的には、複数人の有識者がそれぞれ見積もりを持ち寄って、議論することで数字を決めるというやり方です。
それぞれがその見積もりになった根拠や前提を共有し、認識を合わせていきます。意外と実績値と近くなったりすることが多いです。
若手・未経験者は入っていきにくい手法なので育成要素も忘れずに。
また、安易に「わからないから一番多く見積もってきた人の数字に合わせておこう」はやめましょう。コストは有限です。
見積もる前の事前準備
過去のデータを集める
言わずもがな、過去のデータは次に活かすためにあります。
類似の個所があれば積極活用して精度を高めましょう。
または、前回結果を上回るスピードを出すために何ができるか考えましょう。
見積もり値を考える工数が浮いた分は、建設的な部分に充てるべきです。
有識者とネゴをとる
過去データと同じく、過去の経験者とネゴをとっておくといざというとき有効です。
普段からのコミュニケーションもこういったときに効いてきます。
とはいえ、データも有識者もあればラッキーくらいのスタンスが精神的には楽だと思います。
見積もりの合意形成に必須の項目
前提条件を合わせる
かなり大事です。
「この要求は工数に余力があったら対応を検討します」
「この要求は〇〇という技術で進めます」
のような、言った/言わないの認識がずれてるだけで大きく手戻りが発生しうることは細かいところでも言質をとって議事録等で残しておくのがよいです。
これが仕事を受注する側だと大概負けます。
また、見積もりの単位にも注意が必要です。
日単位や月単位で見積もる際、それを時間換算したらどのような数値になるのかも認識を合わせたおいた方が良いです。
プロジェクト以外にも社内業務等あるでしょうし、1日をフルにプロジェクトに充てられるという状況になること自体が稀なはずです。
一方は6h/dで考えてて、一方は8h/dで考えてたとしたら、一ヶ月(20日)で40hもの開きが出てきます。
40hと言ったら、1週間です。
認識が少し違うだけでこれだけ開きが生じます。
注意しましょう。
完了条件を合わせる
かなり大事です。
リーダー：「このタスク、（実装～開発者テストまで）5日で終わりますか？
メンバー：「はい、（コーディング完までなら）5日でなら何とか」
あるあるですが、気を付けましょう。
見積もりのプロセス
あくまでも一例です。
WBSを作る
WBS(Work Breakdown Structure)も鉄板かと思います。
鉄板ではありますが、分解の粒度には多少経験とセンスが要求されます。
場数を踏んでいきましょう。
例えばイテレーションを1か月という期間で進めようとしているプロジェクトで、それを超えるレベルの分解しかできないようであればどこかが間違えています。
分解したタスクについて見積もる
可能な限り人への依存性は排除しましょう。
特殊技能を要求する場合はその限りではないかもしれませんが、計画段階ではリソースも未決定なことのほうが多いです。
だからと言って、プログラミング初心者でも間に合うような見積もりをするものでもありません。
この辺りが前提条件をすり合わせておくべきポイントの一つです。
必要に応じて、見積もるための調査をする
特に新規技術要素を使う予定がある場合、実現の目途が立っていないまま突き進むわけにはいきません。
重要な要素については見通しを上げるための投資を見積もりよりも前に行っておくべきです。
見積もりの検証方法
見積もって終わりではなく、その妥当性を検証することが一番大事です。
ボトムアップで積み上げて見る
ソフトウェアという見えないものを開発する以上、不確定要素は多くあります。
いくらABPで見積もりをしようとなっても、そこには心理的なバッファが積まれてきます。
そしてそれは、WBSで分解した個々のタスクに対して何重にも重複して計上されてきます。
トップダウンで俯瞰して見る
そのためにも、プロジェクト単位・機能単位といったトップダウンで俯瞰した数字の検証が必要になります。
ここを技術力のない管理者が判断してしまうととても危険です。
ソフト開発におけるリーダーは、技術的にも一定水準のスキルを有しておくべきです。
おわりに
なんとなく書いてみようと思って書き始めたら長くなってしまいました。
これでもだいぶ端折りましたが。
が、こういった読み物を書く練習にもなるのと自分の理解を整理するのにも役立つのでたまに書いてみようと思います。
とりあえず文章としては納得してないけど書き直す気力もない。何千文字もかける人すげーなー
