博士

やあ、ロボ子。ソフトウェアの見積もりって、いつも難しいのじゃ。

ロボ子

博士、こんにちは。確かにそうですね。記事にも「ソフトウェアの見積もりは予測であり、不確実な未来の予測であるため、常に誤る可能性がある」とあります。

博士

そうそう、未来は誰にもわからんからの。計画は反復的にできるけど、プロジェクトは複雑怪奇じゃから、失敗することもあるぞ。

ロボ子

見積もりが失敗する理由も色々あるみたいですね。要件が不明確だったり、技術的な負債を考慮していなかったり…。

博士

「ホフスタッターの法則」とか「ブルックスの法則」とか、名前だけ聞くと難しそうじゃけど、要は「見積もりは甘くなりがち」ってことじゃな。

ロボ子

不確実性の円錐というのも興味深いですね。プロジェクト初期は不確実性が高いけど、進むにつれて情報が増えて減っていく、と。

博士

ふむ、見積もりを改善するには、進捗を追跡してフィードバックループを作るのが大事じゃな。バーンアップチャートとか使うと良いぞ。

ロボ子

見積もりが間違っていても問題ない、というのも気が楽になりますね。バッファを設けたり、予期せぬ事態に備えたりするのも重要ですね。

博士

COCOMOモデルみたいなのを使うのも手じゃな。でも、結局は対面でのコミュニケーションが一番大事だったりするぞ。

ロボ子

経験則も色々ありますね。タスクを細かく分解したり、不明な点は保守的に見積もったり…。「quick」「simple」みたいな言葉は使わない、というのは気をつけたいです。

博士

そうじゃな！「簡単」って言った時点で、フラグが立つぞ！あと、タスクにかかると思う時間の3倍を見積もりの下限、その2倍を上限にするってのも面白い。

ロボ子

見積もり = 複雑さ + 不確実性、ですか。シンプルで分かりやすいですね。

博士

NoEstimatesアプローチってのもあるぞ。ストーリーポイントとか使わずに、スループットやサイクルタイムで測るんじゃ。

ロボ子

Kanbanみたいな視覚的なシステムで進捗を追跡して、ボトルネックを見つけるんですね。定期的なふりかえりも大事ですね。

博士

そうそう、アジャイルじゃな！結局、色々なアプローチがあるけど、プロジェクトや状況に合わせて使い分けるのが一番じゃ。

ロボ子

本当にそうですね。状況に合わせて柔軟に対応することが大切ですね。

博士

ところでロボ子、もし私が「1週間で月に行ける」って見積もったら、どうする？

ロボ子

博士、それはさすがに「見積もり = 複雑さ + 不確実性」の式に当てはまらないと思います！