ソフトウェア見積り の感想

242 人が閲覧しました

本書は開発者やマネージャーを対象として、ソフトウェア見積りの正確性を上げるため、およびプロジェクトの特性を見積もるために有益なアドバイスを提供する。

例えば、以下のような内容。
■見積りとは：　「見積り」と「ターゲット」と「コミットメント」は別。
「ターゲット」は、実現したいビジネス上の目標を明文化したもの（例：年末までにVer.1をリリース）。
「コミットメント」は、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束。
「見積り」は、期間やコストを予測することだが、開発に影響を与える要素とコントロールとの間の相互作用として変わり得るもの。
これを念頭に置き、見積りを求められたときには、実際に見積りを行うのか、ターゲットの達成方法を尋ねられているのかを判断することが重要。

■良い見積り：　プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積り。

■見積りの基本：　数えられるものは、まず数える。数えた結果は、専門家の判断によって調整すべきではない。
過去のデータを使用するときは、次のプロジェクトと前のプロジェクトが同じように進むことを前提とする（生産性の改善を期待しない）。
タスクレベルで見積もる場合は、長くても2日程度のタスクに分解する。
最良ケースと最悪ケースの見積りを作成し、最初の1点見積りがその範囲に含まれるか確認する（他にも最良／最悪を使う手法がある）。

■見積り誤差の要因と対策：　
①プロジェクト自身に関する不正確さ
②プロジェクトを遂行する組織の能力に関する不正確さ
③プロジェクト内の混乱、ターゲットの変更
④見積りプロセス自体の不正確さ
誤差を減らすことは、プロジェクト内のばらつきを減らすことであり、それには各フェーズにおいて、する／しないことのコミットメントが必要である。
要求の増大による影響が大きいならば、見積りではなくプロジェクトコントロールによる対策が望ましい。

■過小見積りの悪影響：

数学的な背景を持った見積もり技法を「サイエンスとしての見積もり」、経験則と単純な公式による見積もりを「アートとしての見積もり」とマコネルは区分けしている。本書では両方を取り扱うが、より「アートとしての見積もり」に重点を置くとしている。

プロジェクトのサイズを大中小と分けるなら、中小プロジェクトが圧倒的に多数を占めるものと思う。こうしたプロジェクトでも当然見積もりは必要とされるが、「サイエンスとしての見積もり」を行うのは少々スペックオーバーに思える。ほとんどの現場では経験則や貧弱な根拠による見積もりが行われ、プロジェクトに混乱をきたしているのではないだろうか。

第1部では、良い見積もりとはなにかの考察が行われる。マコネルは、見積もりとターゲットとコミットメントが異なるものであることを最初に示し、様々なデータを元に見積もりに対する考察を行う。その中で良い見積もりと適切なプロジェクトコントロールは不可分のものであるというメッセージが度々語られている。

第2部では、プロジェクトの規模や種類、ステージに応じた具体的な手法がまとめられている。

第3部では規模、工数、スケジュールなどのそれぞれの見積もりごとの手法と課題がまとめられている。

本文はわずか300ページ足らずなのだが詳細な見積もり技法の本を何冊も読むよりも。現場に立つ開発マネージャーにとって（ただし、中小規模のプロジェクトの）、この本を読み込んだ方が役に立つ実践的な知識と考察が得られるように思う。