見積りレビューのアプローチ(概算編)¶
コードレビューより前にするレビューについての模索その2
Updated on 2020-12-09
見積もりについて知りたかったら「ソフトウェア見積り 人月の暗黙知を解き明かす」 1 を読もうね！と言う話な気がしてきました。
はじめに¶
以前の記事 Webシステム開発でのコードレビューより前のレビュー でコードレビューだけじゃなく「要件定義〜設計」の成果物に対してもレビューをした方がいいのでは？ということを書いたので、今回はその続きで具体的な見積りレビュー方法について書いてみました。
注釈
とりあえず、ここでは最初期の概算見積りのみを対象にします。要件定義後の再見積りはスコープ外です。
注釈
この文章は今まで何となくやっていたものを明文化したという状態で、draft の段階と言えます。その前提でお読みください。( 設計レビューのアプローチ より想像で書いている面があります
WEBシステムが対象です
見積り手法¶
前提として何かしらのロジックに従って見積りをしないと、レビューしようがない。
まず、見積り手法としては以下がある。
類推見積り: 過去の実績をもとにする
パラメトリック見積り: ファンクションポイント法など、何かしらの変数から統計的に工数を算出する
ボトムアップ見積り: タスクに分解してそれぞれにかかる工数を算出・集計
下に行くほど正確な見積りが可能(なはず)だが、条件として要件がより具体的になっている必要がある。ボトムアップは最初期ではタスクの漏れ(認識できないタスク)がありえるし、パラメトリックはボトムアップよりは出しやすいが、代表的なファンクションポイント法でもデータとその入出力が既に決まっている必要がある。
つまるところ最初期に正確な見積りをすることは不可能であり、それでも見積りを求められた場合は「不確実さを考慮に入れた概算見積り」が必要になる。
不確実性¶
Code Complete の著者である Steve McConnell 氏の「ソフトウェア見積り 人月の暗黙知を解き明かす」 1 では「不確実性のコーン」という図が説明されており、それによると初期コンセプト段階では見積りに0.25倍から4倍までばらつきがあることが示されている。つまり、最も悲観的なケースを想定した場合、最初期では見積りにx4しても良いということになる。
見積りを楽観的に出すか、悲観的に出すかと言うのは見積り者あるいは会社のポリシー次第だとは思うが、楽観して出すメリットは開発側には無いのではなかろうか。良心やらプログラミングへの自信からなるべく低めに出してあげたい、と考える事は心情的には理解できるが、
プロジェクトが炎上してクライアント・チームともに疲弊し、信用を失い、（残業・延長により）損失を被るリスク
と
クライアントが「多少」多めに出費することになるリスク
を冷静に比較したら前者の方が重くは無いだろうか。というか、仮に実際に工数が多かったとしても、要件定義後の再見積りで調整したり、要件定義で多かった分の工数を開発工数に回せばクライアントが損することはそうそう無いのではないか。
まぁとはいえ現実的な話としては、４倍出すにはそれなりの根拠が求められると考えられるので、「見積もり時点でどれだけプロジェクトが不確実か」を評価することになるだろう。
不確実性の評価¶
先の本では「不確実性のコーン」は単純に開発フェーズが変わるごとにばらつきが小さくなるのではなく、フェーズの中で「意思決定により不確定事項が取り除かれる」ことでばらつきが小さくなる、と説明されている。
つまり初期段階で不確実性が取り除けるのは「RFPに書かれている内容がひっくり帰らない」ことが大前提となる。これは次の二つを満たしている必要がある。
RFPが上層部（財布の紐を持っている人）の承認を得ている
RFPがエンドユーザのニーズを正しく反映している
これらが無いと途中でストップがかかったり、作ってから使い物にならないなどの問題が発生する可能性が生まれる。この前提で以下の事柄がチェック項目になる 2
やりたいことが明瞭で一貫性があるか
解釈が人によって変わるような記述がないか
目的と手段または全体を通して矛盾がないか
規模の大きい、小さいを判断できるか
そもそもの規模が小さければそこまでブレないため
既存のシステムを再構築したいがドキュメントはありませんみたいなことがないか
クライアントとスムーズなコミュニケーションが取れそうか
経済産業省の [簡略版] 紛争事例に学ぶ、IT導入講座~ ユーザとしてここだけは見ておきたい ~ では「情報システムの開発は、発注者と受注者の共同作業であり、単に 受注者の努力によって成功するものではない。」という判例文(意訳)が紹介されている。共同作業にはコミュニケーションが伴う。
当然開発側もクライアントがわからないことには懇切丁寧に説明するなどのコミュニケーション努力が必要であり、場合によってはそれなりのコストがかかることもありえる。そういった努力の必要性や、クライアント側の意思決定が（開発側の手に及ばないところで）スムーズにいかなそうな雰囲気を感じたのであれば、それは判断材料に加えるべきである
調査してみないと何とも言えないことがないか
スケジュールに合わせてアサインの調整が可能そうか
クライアントからすれば関係ない話だが、実際問題ちゃんとアサインできないなら納期守れないんだから、その点考慮するべき
スケジュールに余裕があるか？また状況によって変更可能か？
リリース日が決まっていて、それに向けて対外的にも調整するような（かつ時間的な余裕もない）場合はミスできないので不確実さに対するリスクが大きくなる。
リスクが大きそうな案件では、リスクマネジメントを誰がするのかというが見積もり以前に受けるかどうかに影響するのではないかと思う。
上記が全て問題なければ、最小で x1.5 まで係数を減らすことはできるかもしれない（不確実性のコーンが要求の完了時点で x1.5 なのでどれだけ甘くみても1.5倍になる）。 3 ただし、この場合上述したように「ひっくり返らない」ことが前提にあることは明確に伝えた方が良いだろう。そもそも仮にクライアントが「今後どれだけ無理を言ってもなんとかする金額」として「見積り」を要求しているのであれば、何も考えずに4倍すればよいのではなかろうか。
見積りのレビュー¶
ここまで書いてようやくレビューに入るわけですが、まぁ上記に沿っていてそれが妥当かを見れば良いので
ベースの工数はどの手法で出しているのか
不確実さの係数はどのような根拠で出したか
を見ることになるかなと。
まとめ¶
一言でいうと「概算は多めに出しておいて後工程で再見積もりすればいいんすよ」という話でした
感想¶
とりあえず書いた
いやまぁ、別に高く見積もって儲けたいとかじゃなく、低く見積もって失敗した経験があるので、適切にしたいんですよ。。
各見積り手法でどれだけ精度が期待できるかっていう指標があればいいんですが、見つかりませんでした（あったら追記）
この辺の見積り分野はいわゆるエンタープライズ系のほうがよほど進んでいるように思える。まぁWEBは比較的に規模が小さいので勘でやってもなんとかなっていたと言う感じなのかな。
(おまけ)見積もり後のことも考える¶
概算見積もりでは後に正式の見積もりを出すので、後の変動要因が説明できるようにする
説明可能な「見積もりの根拠」や「仮説」はある程度共有してしまった方が、後の見積もりの話はスムーズにできるように思える
「あくまで概算なんで」で通したいのであればやはり多めに見積もっておいた方が、後から「やっぱりもっと必要でした...」と言うより誠実だろうやはり。
正式の見積もりをどのような条件で行うか、流れは前もって共有する
「不確実さは意思決定によって取り除かれる」ので意思決定したこと・すべきことリスト管理し、それらが解決され新たな項目がでなくなったタイミングをもって正式見積もりとするのが理想だと思うが、現実的？には時間を見積もってその範囲で頑張るみたいな感じになりがちな感がある。
参考¶
Footnotes
- 1(1,2)
「ソフトウェア見積り 人月の暗黙知を解き明かす」 Steve McConnell 著 溝口 真理子、田沢 恵 (翻訳), 久手堅 憲之 (監修) 日経BP (2006年10月)
Cone of Uncertainty のWikipedia によるとソフトウェア分野に最初にこの概念が導入されたのは Boehm, B (1981). Software Engineering Economics, Prentice-Hall. だが、 "Cone of Uncertainty" と言う名前をつけたのは McConnell 氏ということなようです。
- 2
以下を含むが，これらに限定されない
- 3
同書では「製品定義の承認」と「要求の完了」と言うフェーズがあるが、違いがよくわかっていない。あと、努力でなんとかなるのは誤差20%まで、と書いてあるので結論として（画面）設計までやらないと正式な見積もりは出せないと言うことでは