ソフトウェア開発に特有な技術～ソフトウェア見積り

ソフトウェア見積りを読んで考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（1） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（2） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（3） - アークウェブシステム開発SandBox

ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（4） - アークウェブシステム開発SandBox

www.sakuttoly.com - 読書記録#9 スティーブ・マコネル『ソフトウェア見積り 人月の暗黙知を解き明かす』

SEの読書回顧録 ソフトウェア見積り―人月の暗黙知を解き明かす

ソフトウェア見積りを読了

【1】SW開発でプログラマからSEへ役割が変わる時に要求される技術の一つとして、見積もりがある。
このシステムの開発見積をしてくれ、この作業を見積もりしてくれ、その作業のスケジュールの概要を教えてくれ、と言われる。
この見積りはとても難しく、そして見積もられた数値は一人歩きする。

見積が必要な状況は2つあると思う。
一つはシステム提案時の初期見積り。

まだ営業活動中の時、お客さんのラフな要望からある程度の規模見積り・工数見積もりをして、おおまかな金額を知ること。
お客さんは安い方がよいが、SIとしては自分たちの能力以上に値切った見積りをして案件をとっても、赤字プロジェクトになるなら意味がない。
赤字プロジェクトが前提の案件は、よほどの戦略的プロジェクトでなければ、営業する価値もない。
その概要見積りの作業中に、概念モデルやシステムアーキテクチャをあれこれ推測するうちに、システムのリスクや特徴などを知ることもできる。

更に、見積りで顧客とSIで金額や納期が合わない場合、スコープを変化させることでコストや納期を妥協出来るか、という判断にも使いたい。
つまり、コスト・納期・スコープによるマネジメントの三角形で、どの機能(スコープ)を削除したらコストや納期で妥協できるか、顧客のビジネス要件に合致するか、という再見積の作業が更に発生する時も多い。

もう一つは、案件の受注確定後、開発の全作業を詳細見積りする場合だ。
WF型開発なら、設計・開発・テスト・リリースの各工程の作業や成果物をWBSで洗い出し、どれくらいの工数がかかるのか、一つずつ精査して見積もりしていく。
この詳細見積りがまさにプロジェクトの立上げ・計画プロセスで最も重要な作業になる。
何故なら、この時に洗い出したWBSと予定工数から、各工程の作業が確定して、担当者にアサインされていくから。
とはいえ、作業漏れやスコープ漏れも後になって判明するし、技術リスクを見落としてしまう時もあるから、マネジメント上の予備工数(コンティジェンシー予備)を故意に上積みしておく。
しかし、普通はこのバッファも食い潰してしまう時が多い。

「経営陣が欲しているのは、「見積もり」ではなく「計画」である。」という文章からは、「アジャイルな見積りと計画づくり」を連想させる。

【2】「アジャイルな見積りと計画づくり」では、不確実性コーンという図がいきなり最初に出てくる。
この図の意味が正直分かっていなかったけれど、ソフトウェア見積りを読んでようやく腑に落ちた。

不確実性コーンは、プロジェクトスコープ(規模・工数など)の見積りのばらつきを時系列(工程別)にグラフ化したもの。
当然、初期提案時は見積りの誤差は大きく、詳細設計の完了時には誤差はかなり小さくなり、ソフトウェア完了(リリース)ではゼロになる。

不確実性コーンが意味することは、プロジェクトの初期段階における見積りは誤差が大きいため、外れやすいこと。
初期見積りは概算見積りゆえに、システムが象さんレベルなのか、犬猫レベルなのか、ぐらいの判断しかできない。
見積りの正確性は、ソフトウェアの定義を詳細化していくレベルに依存する。
つまり、現在の見積もり作業が不確実性コーンのどの位置にいるのか、を常に意識しなければならないこと。

しかし、時間が立てば見積りの誤差が自然に収束するわけではない。
コーンが収束するには、ばらつきを取り除くための意思決定を経る必要がある。
つまり、スコープを確定するのが重要。

だが、Agile開発のように、スコープが常に揺れるのが普通のプロジェクトの場合、不確実性のコーンは時間が経っても勝手に収束することはない。
そして、変更された要求を追跡(トラッキング)する作業は大抵の場合おろそかにされやすく、再見積が必要なのに、再見積もりされない。
だから、初期のベースラインからどれくらいスコープやコストが変わったのか、をコントロールしにくい。
普通のデスマーチは、不安定な要求をスコープ管理できず、要求がどんどん肥大化してプロジェクトが破綻する時が多い。

ソフトウェア見積りでは、そんな場合は見積りの正確さを求めるよりも、先に混乱を収束させるべきと言っている。
つまり、要求が安定されないことを前提として、プロジェクトコントロールを重視して反復型・漸進型プロセスを採用するなどの手法を勧めている。

【3】「アジャイルな見積りと計画づくり」でまだ理解できておらず、実践出来ていない概念がストーリーポイント。
ソフトウェア見積りでは、ストーリーポイントをファジー見積りの一つとして詳細に説明してくれている。

ストーリーポイントによる見積りは規模見積りの一つだ。
スプリント前に見積もったストーリーポイントはただの代替指標に過ぎない。
初回の反復が完了後、実際の工数が得られると、ストーリーポイントから定量的な工数へ換算することができて、見積りの補正が可能になる。
例えば、ストーリーポイントから工数やカレンダー(納期)へ換算することで、チームのVelocity(開発速度)が得られる。
チームは、そのVelocityを参考にして、次の反復の見積りに生かす。
つまり、Velocity駆動でリリース計画、スプリント計画を作り、計画の精度を上げていく。

ストーリーポイントやVelocityなど、Scrumが従来のAgile開発に無かった概念や枠組みを提供した事実は考察に値する。
Scrumでは、規模見積り(ストーリーポイント)と工数見積もり(理想時間・理想日)を区別して見積もる点はとても重要だと思う。
ScrumはVelocityを経由して、規模見積りと工数見積もりを連携させている点が上手。

そして、Scrumでは、ユーザ(プロダクトオーナー)と開発者(開発チーム)のViewをバックログとタスクボードで意図的に分ける。
更にバックログ上でストーリーカードに対して規模見積り、タスクボード上でタスクカードに対して理想時間の工数見積もりを行い、それぞれの見積りをスプリント計画へ反映して、計画の正確さを上げる。
短い反復を繰り返すごとに、見積もりの精度は理論上上がっていく。

規模見積りの単位がストーリーポイントにするのは僕はまだ理解できてない。
ストーリーポイントは開発規模をフィボナッチ数列の尺度に合わせていることが重要なポイントの一つ。
しかし、ソフトウェア見積りでは、開発規模の見積りの相対関係がフィボナッチ数列の比率に合致してればうまく作用するが、尺度が現実と違えば誤差も大きくなる、と言っている。
実際のプロジェクトでどこまで見積もりの精度が上がるのか、試行錯誤が必要なのだろうと思う。