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

スティーブ・マコネルの『ソフトウェア見積り』を読了した。

『ソフトウェア見積り』は、ソフトウェア開発における工数や期間を見積もる方法について詳細に解説した本。見積もりについて学んだことのない私にとっては、実に有用かつ勉強になった。

知識がある人でも、開発計画立案や見積もりに携わるならば読む価値はあるだろう。PMP (Project Management Professional) を持っている上司が、「読み終わったら貸して」と言ってきたくらいだ。

ちなみに、著者は Code Complete コード・コンプリート を書いた スティーブ マコネル氏だ。最初は気づかなかったが、裏表紙裏に書いてあった。

- 『ソフトウェア見積り』を読んだ理由

『ソフトウェア見積り』を読んだ理由は、自分の見積もりの技能を高めて、チームの生産性を向上させるためだ。2007-01-08 の「デッドラインを読了」に引き続き、プロジェクトをよりよく進めるための読書。

プロジェクトの開始前などで、上司からよく「*** の工数を見積もって」と言われる。しかし、見積もりについての知識が乏しいため、私の作成した見積もりには少なくとも以下の問題がある。

・見積もりが自己流。研修などは受けていないし、そもそも組織内で開催されていない。
・どうやって見積もったらいいかわからない。とりあえず人月や人日は出すが、自信が持てない。
・過去データからの推測しての見積もりや、単純にタスクを積み上げて見積もるくらいしかできない。
・見積もりの正確性が低い。タスクの見落としや過小評価のせいで、見積もりと実績が乖離している。
・見積もりの有用性が低いので、計画を立案しにくく、変更にも弱い。結果、作業効率が落ちる。
・見積もりと実績についてどのように効果測定をしたらいいかわからない。また、その時間もない。

要するに、見積もりについての基礎知識がないのに、何とかこなそうとしている状態だ。

上司や先輩に教えを乞えば済むのではないか、という意見もあるかもしれない。しかし、上司や先輩は非常に多忙で、私にそんな指導をしている暇はない。

学ぶ機会がないからといって、このまま自分の成長をのんびり待つというわけにはいかない。プロジェクトはどんどんアサインされる。アサインされたプロジェクトを成功させるためにも、まずは見積もりの基礎を身につける必要がある。

- 『ソフトウェア見積り』で面白かった点

全編に渡ってとても面白く、役に立つ。以下、何点かメモ。ただ、役に立つ部分が非常に多く一度に書ききれない。まずは全23章のうちの5章までについてだけメモ。

- 経営陣が欲しているのは、「見積もり」ではなく「計画」である。

14ページ「見積もりの真の目的」から。

経営陣は「見積もった結果、間に合わないと思われます」という情報が欲しいのではなく、「間に合わせるための計画」や、「間に合わせるために諦める機能を選ぶための判断材料」や「そのための追加コスト」などの情報を必要としているという指摘。

これは私も常々意識するようにしている。どんな方法があるかを考えたり、それらを提案するのが私の仕事で、決断するのは経営陣の仕事。ワインバーグの『コンサルタントの秘密』に書かれていた「オレンジジュース・テスト」にも通ずることだね。

- 過少見積もりの不利益は直線的でなく限界がない

27ページ。

ソフトウェアにおいて、過大見積もりの不利益は直線的で有限である。一方、過少見積もりの不利益は直線的でなく限界がない。

これはたしかにそうだ。上司も最初から少ない見積もりを要求してくるということもあり、私はどうしても少なく見積もってしまう。ただ、その過少見積もりの結果発生するコストの増大については誰も気にしていない。前述の通り、見積もりと実績の効果測定をしていないし、やり方もわからなかったからだ。もっと言うと、「振り返りたくない」のかもしれない。

しかし、トータルで見れば、たぶん過少見積もりの不利益を被っているはずだ。今後はそれを上申して、全体のコストが最小になるように常に配慮しよう。

ちなみに、過大見積もりの問題については、「計画とコントロールを通して対処する」ともある。

- 混乱を修正してから見積もれ

46ページ「混乱した開発プロセス」から。

コントロール不能なプロセスを正確に見積もることは不可能。先に混乱を修復する方が、見積もりを改善するより重要だ。

「要求を曖昧にしたままにする」、「まずい設計」などの「回避できるはずの混乱」をまず修正してから見積もれ。それをしないと正確性が大きく損なわれる。

- 不安定な要求には、プロジェクトコントロールによって対処せよ

47ページ「不安定な要求」から。

不安定な要求に対処するには、プロジェクトコントロールによる対策を考えよう。

XP (Xtream Programing) やスクラムなどを検討すること。それらの対策がとれないときにどうするかについては、もっと考えなければならないだろうけどね。

- アクティビティの見落としを避けよ

見積もりには、単にコーディングとテストだけでなく、必要なソフトウェア開発アクティビティをすべて入れること。アクティビティ (作業) の漏れや見落としを避けることは、正確な計画や見積もりをつくる上で非常に重要だ。WBS (Work Breakdown Structure - 作業分解図) による作業のリストアップにも通ずる。

48ページでは、忘れられがちな機能要求・非機能要求を18項目挙げている。とても有用。実際に私が過去のプロジェクトなどで見落とした項目がたくさんある。今後はこれをチェックリストとして活用したい。

50ページには、見落とされがちな開発アクティビティの36項目の一覧、開発外アクティビティの10項目の一覧を挙げている。たとえば、テストデータ作成や、あらゆる種類のレビューなどだ。私も、WBS を作るときや計画を作るときに、これらを入れ忘れて失敗したことがある。これもチェックリストとして使える。

72ページ。
COCOMOII 見積もりモデルに基づく補正因子。プログラマの経験やスキル、製品の複雑さなど、それらひとつひとつの要因がプロジェクトに及ぼす影響度を数値化したもの。かなり詳細であるため、これらの係数をひとつひとつ評価して見積もりに反映させるのは、ツールの支援がないと大変だろう。しかし、精度は高まるはずだ。

- 開発者の見積もりを削るな

52ページ。

開発者の見積もりを削ってはいけない。なぜなら、既に十分に楽観的すぎるからだ。

これも心当たり大あり。アクティビティの見落としと相まって、かなり楽観的で小さい見積もりを出してしまうことが多い。私、後輩、みんなこの傾向がある。本人に悪気はないのが救いだ。

私の上司でさえ、要求の変更を指示するときに「*** さんならこの程度の機能は5分で書ける。よろしく。」と言う。冗談交じりに言っていることだし、テストの時間は別途加算してくれてはいるので、まだ良心的ではある。

「開発者の見積もりを削るな」という言葉は、表紙にも書かれている。それだけ重要だということだろう。

Don't reduce developer estimates
---they're probably too optimistic already.

- 6章以降はまた後日メモする

ここまでで、全23章中5章だ。300ページ中80ページ。非常に勉強になった。

残りはまた後日。