Landscape - エンジニアのメモ 2007-01

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

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

知識がある人でも、開発計画立案や見積もりに携わるならば読む価値はあるだろう。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ページ。非常に勉強になった。

残りはまた後日。

お年玉付き年賀状の当選番号が発表された。来た年賀状をチェック。今年はメールを使うなどの方法で少なくしたので、来た枚数は少なめ。

当選状況。2006-01-16 と 2005-01-16 と同じように、芳しくない結果となった。2004-01-18 の切手シート当選をまた希望したいところ。いや、もっといいもの当たる方がいいけど。

平成19年用お年玉付郵便葉書及び寄附金付お年玉付年賀切手の当せん番号
http://www.post.japanpost.jp/kitte_hagaki/info/2007/nenga/in ...

1等 100万本に2本 （7,650本）
(1) わくわくハワイ旅行
(2) にこにこ国内旅行
(3) ノートパソコン
(4) DVDレコーダー＋ホームシアターセット
(5) デジタル一眼レフカメラ＋プリンタセット
〈以上5点の中から1点〉
当選番号: 157788
当選番号: 457190


2等 地域の特産品小包(1個) 1万本に4本（1,529,836本）
当選番号: 5161 下4けた
当選番号: 7093 下4けた
当選番号: 7485 下4けた
当選番号: 9614 下4けた


3等 お年玉切手シート 100本に2本（76,491,740本）
当選番号: 64 下2けた
当選番号: 79 下2けた

あれ? 2006-01-16 に書いた去年の抽選結果は4等級に別れてたけど、今年は3等級しかないね。2等の家電がなくなって、それ以下が繰り上げになったのか。

今年は下一桁が 0 1 3 4 5 8 9のどれかなら何か当たってるかも。

『クレジットカードのごほうび』を読了。

カードの有効な使い方と、ポイントや特典が有利なカードを紹介した本。カードをあまり使わない人、特典の恩恵や年会費のコストを気にしていない人向けに、こうすればお得というやり方を説明している。

カードをお得に使うポイントは以下の2点。

・支払いは「一回払い」を使い、手数料や金利がかからないようにする。
・カードは一枚にまとめて、ポイントを集約する。ただし、使い方によってはお得になるカードをもう一枚くらいなら持っても良い。

- 『クレジットカードのごほうび』のおすすめカード

特典が有利なおすすめカードが載っていた。興味を引いたのは以下のカード。

62ページ ANA カード。
マイルをためて航空券に替えられる。飛行機を使うことがわかっているならこれ。

68ページ P-One カード。
常に請求時1%割引。その上ポイントまで付く。公共料金の決済だけでも有利。私が今使ってるのもこれ。2006-11-19 の「すべての買い物が1%割引になるクレジットカード P-One カードを申し込んだ」参照。

70ページ セゾンカード。
ポイントの有効期限が永久。

78ページ 出光カード。
利用額に応じてガソリン代が安くなる。利用額1万円ごとに、リッターあたり1円引き。上限30円引きまで。車をよく使う人向け。

- 少額の支払いでもクレジットカード払いで問題ない

32ページ。

Q.
コンビニでカード払いするのって、ちょっと勇気がいります。

A.
「少額だから、迷惑なのでは」と考える人がいますが、コンビニで130円のおにぎりひとつをカード払いしても、ぜんぜん問題ありません。店員さんだって嫌な顔ひとつしませんよ。
むしろおつりを渡すときのミスがないのでうれしいくらいですと言った店員さんがいました。

カードを使えば自分が小銭を数えたりする必要がなくて楽なんだけど、それは店員さんにとってもおなじ事なんだよね。コンビニやスーパーならばサインも要らないし、便利。

トム・デマルコの『デッドライン ソフト開発を成功に導く101の法則』を読了した。この本では、ソフトウェア開発プロジェクトを成功させるための教訓や考え方が小説形式で書かれている。大いに学ぶところがあり、非常に面白い本だった。

私の上司も過去にこの本を読んだことがあるそうで、「デマルコは読んでおいて損はない」と言っていた。また「言えば貸してやったのに」とも言われた。身近に持っている人がいるとは知らなかったので、今回は自分で購入してしまった。しかし、十分元はとれる良書なので問題ない。

- デッドラインを読んだ理由

私はソフトウェア開発プロジェクトの運営や管理の知識に乏しい。雑誌の特集やコラム、情報処理技術者試験のテキスト、そしてウェブサイト程度でしか学んだことがない。ちなみに誌名を挙げておくと、日経コンピュータ、日経システム構築、ソフトウェアデザインなどだ。文献はほとんどと言っていいほど読んでいない。せいぜい XP (Xtream Programing) 関連の書籍を流し読みした程度だ。

今まではそれでも何とかなっていたが、最近はコードや SQL を書く仕事よりも、設計やチームの運営レベルの仕事が増えてきている。そういった仕事を担当する上で、知識や方法論・考え方の基礎が自分にないことは問題だと感じ、学習が必要だと考えていた。研修や勉強会に参加して学ぶのもよいが、まずは本を読むところから始めようと思い、この『デッドライン』を購入した。

- デッドラインで面白かった7つの点

本書は全編にわたって学ぶべきところが多い。その中でも私がとくに面白いと感じたのは以下7つの部分だ。

・正しい管理の4つの本質
・プロジェクトの数量化の必要性。すべての製品のサイズを測定せよ。
・プレッシャーをかけても思考は速くならない。管理者がプレッシャーを使うことが多いのは、他に何をすべきかわからないから。
・曖昧な仕様書ができる理由は、利害関係者間の対立が解決されていないから。
・設計をしていない開発チームと、なぜ設計をしないのかについての考察。
・部下を尊敬すること、気遣うこと、守ることが、プロジェクトにとっていかに大切か。
・良い目標は実現が難しいところに設定される。良いスケジュールは達成される可能性が高い期日で設定される。

いずれも自分の身の回りの問題として考えることができるテーマだ。とくに、曖昧な仕様書ができる理由と設計をしない理由についての考察は、ここ最近興味を持っているテーマでもあり、何回か読み返した。読んだ結果、設計は一般に考えられているよりも非常に範囲の広い作業であること、上流での設計の善し悪しが、プロジェクトに大きな影響を与えることを痛感した。

- 設計が重要

たとえば、業務の担当を決めるということは一見すると管理者の仕事である。しかし、管理という視点だけで担当を決めてしまうと、開発するシステムの質に大きな影響を及ぼしてしまう。

通常、担当者の決定はシステムの構成や機能の切り分けの後におこなわれることが多い。しかし、これは重大な間違いを含む。なぜなら、担当者を決めるためにまずシステムを切り分けてしまっているからだ。つまり、ここが非常に重要な設計の上流工程だったのだ。これに気づかずに安易に担当を決めたり、担当範囲を曖昧にしたままプロジェクトを開始すると、そのプロジェクトの成果物の品質は格段に落ちる。管理は設計の上流工程であるということを認識した上で、プロジェクトを進めることが必要なのだ。

考えてみれば、今まで設計について学ぶことは少なかった。多少学んだことはあるにしても、実装寄りの部分が多く、プロジェクトを進めるという観点からのものではなかった。デッドラインを読んだおかげで、自分に何が欠けていて、今後どんなことを学んでいくべきかがわかった。

- 一度技術から離れて本を読んでみることにした

今までは純粋な技術書を読むことが多かったが、これからしばらくの間、プロジェクト全体を円滑に進めるにはどうすればよいかという観点から、何冊か本を読んでみるつもりだ。