ソフトウェア見積もりと納期のいくつかの真実とウソ

ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。

ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである

論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ

ソフトウェア開発における「不確実性のコーン」は、初期コンセプトの時点でのソフトウェア規模の予測が困難であることを示すものであって、これはある意味当たり前であろう。物理的な建築物などであれば平均坪単価などである程度の費用工数を見積もることが可能であるが、ソフトウェアはそうではないということを示しているに過ぎない。

ソフトウェア見積り　人月の暗黙知を解き明かす

真実:初期コンセプト段階でのソフトウェアスコープ(工数、コスト、機能)の正確な見積もりは難しい

これは自明な事であるのでことさらと掘り下げるつもりはない。が、一方で初期コンセプト時点での予算確保などを検討する場合、「過去のプロジェクトの実績」掛ける「予想される生産性の向上」などで割り引いた予算確保を行うことは大きなリスクである。これは最近のソフトウェア開発データ分析でも言及されている事である。過去に書いた以下ブログ記事もあわせて参照。

• 2004年～2012年の間で、SLOC生産性は変化していない(生産性向上も低下もない)

ソフトウェア開発プロジェクトは、低価格と短納期の強いプレッシャーに晒されることが多々ある。また、予算管理や価格交渉等の場面で、年率5%の開発コスト削減や前年度比10%のライン単価低減等が要求されるケースが散見される。しかし、データによる裏付け等の根拠が希薄であると、このような状況は開発プロジェクトのリスク増大や品質低下を招く恐れがある。

IPA/SEC「ソフトウェア開発データが語るメッセージ2015」を読む - 勘と経験と読経

真実：見積もりとスケジューリングは別の活動であり混同すべきではない

混同されがちなので念のため。またスケジューリングの決定は、政治、交渉の問題でもある点を理解すべきだろう。前述の「ソフトウェア見積もり」本でも、まるまる1章を割いてこれを論じている。

交渉がふさわしい情報もあれば、そうでない状況もある。私たちは太陽の表面温度や五大湖の全容積といった事実について交渉することはない。これらは、調べさえすればわかることだからだ。同様に、ソフトウェア見積もりは分析的なアクティビティの結果である。したがって見積もりについて交渉することは道理に合わない。だが、見積もりに関係のあるコミットメントを交渉することは、理にかなっている。
ソフトウェア見積り　人月の暗黙知を解き明かす /第23章 政治、交渉、問題解決

また、政治的なスケジュールの交渉についてはこの本が詳しくて参考になる(アンチパターン集が含まれている)

Manage It! 現場開発者のための達人式プロジェクトマネジメント

スケジューリングと見積もりは2つの異なるアクティビティだ。スケジューリングとは各タスクの順序付けであり、相互依存関係が見えるようにすることである。一方、見積もりとは、特定のタスクに必要な工数を推測する作業のことだ。スケジュールを編成する方法はタスクの工数と必要な人材の見積もりに依存するので、両者は密接に関係している。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/第4章 プロジェクトをスケジュールする

見積もり、計画、スケジューリングをどんなにがんばっても、スケジュールをゲームにしてしまうスポンサーや管理者やチームメンバーが現れるものだ。ゲームプレーヤーを現実に連れ戻すのはプロジェクトマネージャの仕事である。でもその前にスケジュールゲームを見極める必要がある。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/ 第6章 スケジュールゲームを見極めて回避する

ちなみに紹介されているスケジュールゲームのアンチパターン(第6章 スケジュールゲームを見極めて回避する)は以下の通りだけれども、タイトル見るだけでワクワクできる。

• 岩をもってこい
• 願望が最重要の戦略
• 現実否認の女王
• カーペットの下に隠してしまえ
• ご機嫌な期日
• 尻に火をつける
• 焦点の分裂
• スケジュールは確約に等しい
• 行き当たりばったり
• スケジュールツールは常に正しい（スケジュールの夢の時間）
• 何が何でもやってくれ。でないと黒こげだ
• ノーとは言えない
• スケジュールチキンレース
• 90%完了
• これからペースが上がっていく
• スケジュール催眠

ウソ:見積もりが困難だから、計画することには意味はない

そんなことはなく、当然、意味はある。ただし、それはコミットメントをすることにおいてのみではない。

見積もりや計画づくりがそんなにも難しくて、プロジェクトの終わりになるまでは正確に見積もれないのであれば、そもそも見積りや計画づくりをするのはなぜだろうか？ わかりやすい理由として、働いている組織から見積りの提出を求められることが挙げられる。その理由はさまざまだが、いずれももっともなものだ。マーケティングキャンペーンの計画を立てるためだったり、プロダクトのリリース作業の予定を立てるためだったり、組織内のユーザをトレーニングするためだったり。いずれの場合にも計画や見積りが欠かせない。見積もるのが難しいので計画やスケジュールは作成しない、という言い訳は通用しない。しかも、見積りや計画づくりという大変な仕事に取り組むべき理由は、こうした消極的なものだけではない。もっと根源的な動機があるのだ。
見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。計画づくりとは価値の探求なのだ。
アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?/1章 計画の目的

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

同書は見積りからいかに価値を生み出すか、という点で非常に示唆に富んでいて、個人的にはマコネルの見積もり本と合わせてオススメしている。ソフトウェアの見積もりの工学的な側面をマコネル本で学び、適切にコントロールするという観点は本書を読むのが良いと思う。

真実:受発注契約の関係において納期は絶対である

ポイントは「契約の関係に於いて」という点である。つまり

• 自社エンジニアが便宜上「納期」と呼称する単なる作業完了のコミットメント
• 請負契約の関係に無い利害関係者が便宜上「納期」と呼ぶ完成マイルストーン

についてはこの限りではない。
一方で、いうまでも無く契約上で定義された納期は絶対のものであり、これが遅延した場合契約債務不履行になるので「ソフトウェアの見積もりなんて星占いみたいなものだから、納期なんて守れるはずないし、守らなくて良い」なんて思わないように。
参考：システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

ただ、実際はソフトウェア開発の不確定性を考慮して契約するのが適切だろう

• ソフトウェア開発の完了予定日(例えばリリース日)と契約書上の納期は分ける
• スケジュール上のバッファをきちんと設定して、本番稼動後に改めて納入を図る
• 超過の可能性がある場合は、相手先と今後の係争に抗弁できるような合意形成を行う

納期を越えて

冒頭で紹介した記事は、「納期なんて考え方はやめてしまえ」という意見を示しているのだけれども、個人的にはちょっと疑問がある。SIer的な「ソフトウェア開発完了のコミットメント＝納期」は、単純に外注契約を無くしてしまえば回避できるだろう。しかし、ソフトウェア開発を取り巻くすべての利害関係者が期日やコミットメント無く協働していくビジネスというのはちょっとイメージしにくい。経営やマーケティング、運用などの観点ではやはり大小のコミットメントを拠り所として推進せざるをえないのではないだろうか。
ただし「守ることのできないコミットメント(納期、期日)」や「無意味なコミットメント」などは生産性阻害要因であることに変わりない。いま目の前にある期日が何のコミットメントで、最新の状況においてどういう意味があるのか、そして変化がある場合にどのようにすべきなのかについて考えることが必要であるのだと思う。