アジャイルな見積技法：『アジャイルサムライ』を読んで

読んでからずいぶんと経ってしまったのだけど、アジャイル開発について言わずと知れた『アジャイルサムライ』について書いておく。

本書はアジャイル開発についての思想とそれを支える各種ツールを、かなり平易な言葉で時に面白おかしく、かつ網羅的に解説している。アジャイルについて本格的に学び始めるには非常に良い本だと思う。

構成としては大きく3つ、計画、運営、開発の3部構成になっている。計画部分でアジャイルに適した見積もりの仕方など、運営の部分でイテレーションを単位としたプロジェクトの進め方、開発でTDD、CIなどのアジャイルに親和性の高い各種開発手法を紹介している。今回は計画の中の見積もりに話題を絞ってみる。

アジャイルな見積技法

面白いところは、見積技法として「絶対的な数値として精緻な見積もりを行うことを敢えてせず、何らかの実績のある作業と比較して相対的に（作業Aのx倍）見積もりを行う」という点。これには以下3つの背景が存在する。

プロジェクト初期段階の見積もりはあくまで概算（当てずっぽう）であるので、プロジェクトが進むに従って精緻化していけばいい、と顧客などにも割り切らせる
得てして絶対的数値で見積もるよりも、何かと比較しての相対的な見積もりのほうが案外正確
絶対的な数値で出してしまうと、出した途端にそれが「唯一絶対正しい数値」かのように扱われてしまいがち

1.はアジャイルのそもそもの考え方に通じる。それを見積もりでも体現して、「そもそもアジャイルだとこうなんです、最初から全量が固定する訳じゃないんです」ということを分からせるためにも必要なことだ。これが受け入れられるかがアジャイル採用可否の分かれ道になってしまうとも思う。

2.と3.は人間の性質上陥りがちな過ちを見抜いた素晴らしい洞察だと思う。ウォーターフォール型開発を続けている多くのプロジェクトでもこの2点について苦労をしているプロマネも多いはず。

ウォーターフォール型での対処（苦肉の策）

かくいう僕もこの2点については煮え湯を飲まされつつ、自分なりの対処をしてきた。2.については、今までに自分がリードして見積もったことのない大きな規模の案件に対して、敢えて大中小で見積もり、最後にそれに係数を掛けて工数に換算するという方法を採った。大中小にだいたいの目安の数字（小は1−5人月とか）をつけておけば、実際に見積もり工数を提示する担当者は過去の同規模の案件と比較して大中小どれが妥当かを回答する。これは見積者に対して正確な数字を見積もるという負担を下げるという意味もあった。見積もりのオーダ（単位）を少数の選択肢に絞るという意味では、本書の「ポイントで見積もる」という技法とも整合する。

3.については非常に原始的な方法だが、概算見積時には「これは概算」である旨をとにかく強調することと、詳細見積として自信を持って出せる段階になるまでは書面での工数回答を行わない（口頭でのみ「だいたいこれくらい」と回答する）という回避策を採っている。このあたりは「先ずは見積もり工数を」となってしまうウォーターフォール型の限界だ。