文藝春秋(2008)

新しい時代の金言集。共感度100%。原文を載せているのがとてもいいです。なぜか原文のほうがしっくり来るのですよね。

ただ、日本語が縦書きで英文は横ですから、時々、本の方向を変えて読まなければいけないのが少し辛かったです。日本語も横書きでよかったのでは？

P102の「その二つを一緒にしてはいけないだ。」は「２つに分かれたラインとスタッフを持ってはいけない」ということではないでしょうか？逆の意味のような気がします。

それから、グーグルのSergey Brinですが、ロシア系ならばサーゲイではなくて、セルゲイになるのではないかな、などと思いました。シリコンバレーの梅田さんのほうが正しい気がしますが。

以下抜粋です。

世界を変えるものも、常に小さく始まる。
理想のプロジェクトチームは、会議もせず、
ランチを取るだけで進んでいく。チームの人数は、
ランチテーブルを囲めるだけに限るべきだ。－－ビル・ジョイ

人事部主導で新卒を一括採用し、本人の意志と関係なく勝手に配属先を振り分けるという日本企業のシステムはもはや完全に制度疲労を起こしていると思います。新卒で入った社員の中にすぐに辞める人が増えていると聞きますが、問題は明らかに企業側にあります。自分の意志とも労働意欲とも関係なく、勝手にある部署に配属されて、行ってみたら到底尊敬できそうにない奴が上司で、興味の持てない仕事をやらされるというのは、いくらそれが社会的に知名度のある会社であっても、やりきれないでしょう。飛び出したくなるほうが当たり前だと、私は若者たちに共感します。

トップレベルのチームはマネジメント重視でなく
行動重視でなければだめだ。－－ゴードン・ベル

政治的になるな、データを使え。－－マリッサ・メイヤー

同じようにモチベーションを高く維持している人たちがチームの中にいて、目標を共有しながら、会社や作品の成長を目指す。自分の能力と仕事に自負を持ちながら、みんなが同じ目標に向かって走る一部になっている－－仕事をする、働くということの本質的な意義は、その幸福感の中にこそあると思います。

シリコンバレーの中核にあるのは、サイエンスやテクノロジーを愛する人たち独特のものの考え方、価値観であり、それが会社と産業全体を牽引しています。いわゆる旧来の資本家や投資家や金融機関、文系的な管理者の論理とはまったく異なる力が働いています。そしてその根底に流れるのは、西海岸特有のカウンターカルチャー（伝統的・支配的な文化に対抗する文化９から強く影響を受けた考え方です。
中枢にあるのは資本の論理ではない。個に力を与えるテクノロジーへの信仰にも似た熱情であり、理系の技術者特有の気質です。

PCは誕生当初から「個が大きな力を持つことのできる道具」として、個がテクノロジーを使って権威と対抗できる革命的な道具として産声を上げたのです。

グーグルはインターネットが体現している、「知と情報をあまねく流通させることで個の自由を徹底的に模索する新しい文化」の先兵としての役割を果たそうとしています。個人がより自由になるために、情報という新しい武器を与えよう、それが「世界をより良い場所に」することになるのだ、とグーグルは考えます。

私は根っからの、テッキーナードだ。そして科学を愛する。
科学はリソースを何乗にも膨らませるから。
正しい方針と正しい市場環境は必要だ。
でもケタ違いにリソースを膨らませるのは科学だけ。
科学は、何かを１０%や２０%良くするのではなく
１００倍良くする可能性を秘めている。
私はその力に興奮を覚える。－－ビノッド・コースラ

私たちは非常に複雑な問題を、その問題がどれほど複雑かを
人々に知らせることなく、解こうと試みている。－－ジョナサン・アイヴ

「ニューノーマル」時代における成功とは、タイムマネジメントに尽きる。
この時代における通貨は、時間なのである。－－ロジャー・マクナミー

Your time is limited,so don't waste it living someone else's life.
Don't be trapped by dogma - which is living with the results of other people's thinking.
Don't let the noise of others' opinions drown out your own inner voice.
And most important,have the courage to follow your heart and intuition.
They somehow already know what you truly want to become.
Everything else is secondary.--Steve Jobs

The only way to do great work is to love what you do.If you haven't found it yet,
keep looking.Don't settle.As with all matters of the heart,you'll know
when you find it. And,like any great relationship,it just gets better and better
as the years roll on.So keep looking until you find it.Don't settle.--Steve Jobs

スティーブン・R・コヴィー
ジェームス・スキナー、川西 茂/訳
キングベアー出版(1996)

今、書店に並んでいるビジネス書100冊以上の価値があります。

その真価は、現代のビジネス書を数多く読んで、次から次へといろいろなテクニックを与えられ、それでも満足を得られないという中毒症状の人が、最もよく理解できるでしょう。私もそうでした。逆にビジネス書や自己啓発書を読まない人にとっては、ピンと来ないかもしれません。

巷のビジネス書が言うような、成功への近道はないのです。表面だけ取り繕っても、いずれ本質が明らかになるからです。

私の人生観に最も影響を与えた最重要な本の1冊です。

----------------

個性主義の各要素（個性の発揮、コミュニケーションのスキル、他に影響を及ぼす戦略、前向きな姿勢など）は成功するのに必要がないと言っているのではない。確かにそれなりに必要だと思う。しかし、それらは一次的なものではなく、二次的なものである。私たちは、前の世代がつくり上げてきた土台の上に自分たちの成功を築くことを繰り返してきた結果、土台そのものを築く大切さを忘れてしまったのだろう。あるいは、種を蒔かずに長年刈り入れを続けてきたせいで、種を蒔く必要性を忘れてしまっているのかもしれない。
自分の人格に基本的な欠陥、二面性、あるいは不誠実を持ちながら、テクニックや手法だけで人を動かしたり、仕事をさせたり、士気を高めようとしたりすれば、長期において成功することはできない。いずれは、その二面性によって相手に不信感が生まれるからである。いくら人間関係を改善させるためのテクニックを使ったとしても、それはすべて相手を操ろうとしている行動にしか見えない。信頼という土台がなければ、永続的に成功することはあり得ない。基礎となる人格の良さがあってはじめて、テクニックが生きてくるのだ。

原則は手法ではない。手法は具体的な活動、あるいは行動である。したがって、ある状況で使える手法が必ずしも別の状況でも使えるとは限らない。二番目の子供を最初の子供と同じように育てようとしたことのある親なら、すぐに分かるはずだ。
手法はある特定の状況においてしか適用できないが、原則は深い基礎的な真理であり、普遍の応用がある。そして、個人、人間関係、家族、あらゆる組織にあてはめることができる。こうした心理を習慣として身につければ、人々は自分が直面している状況に対応できる手法を自分で打ち出すことができるのだ。
また、原則は価値観とも異なる。例えば、強盗団でも価値観を共有することはできる。しかし、その価値観はここで話している基本的な原則とは全く違うものであり、それに相反するものである。原則は”場所”そのものであり、価値観は”地図”である。正しい原則に価値をおけば、真理--物事のあるがままの知識--を手に入れることになる。

私たちの持つパラダイム、頭の中に描く地図が、こうした原則や自然の法則に一致すればするほど、それは正確かつ機能的なものになる。正しい地図を持てば、個人の、または人間関係における効果性に、無限のインパクトを与えることになる。それは行動や態度を改めようとするいかなる努力をも、はるかにしのぐものである。

「現代社会で出会う多くの人々は、まるでロボットのように機械的に振る舞い、自分のことを知りもせず理解することもない。唯一知っているのは、社会が要求しているイメージだけである。真のコミュニケーションをもたらす語らいの代わりに意味のないおしゃべりを繰り返し、心からの笑いの代わりに見せかけだけの笑顔を作り、心底からの痛みの代わりに鈍い絶望感しか味わっていない。こうした人間について言えることが二つある。ひとつは、彼らが治療の施しようがないほど自発性と自分らしさの欠乏に悩んでいるということであり、もうひとつは、実質的にほとんど私たちと変わりがないということだ」（エーリッヒ・フロム）

インサイド・アウトとは、自分自身の内面（インサイド）を変えることから始めるということであり、自分自身の根本的なパラダイム、人格、動機などを変えることから始めるということである。

インサイド・アウトの考え方では、私的成功が公的成功に先立つ。つまり、他人に対して約束をし、それを守る前に、まず自分自身に対する約束をし、その約束を守らなければならないということなのだ。また、人格よりも個性を優先することは愚かなことであり、自分自身を改善せずにほかの人との関係を改善しようとすることは意味のないことだと教えている。

「思いの種を蒔き、行動を刈り取り、行動の種を蒔いて習慣を刈り取る。習慣の種を蒔き、人格を刈り取り、人格の種を蒔いて人生を刈り取る」（古い格言）

習慣は、知識とスキルとやる気という三つの要素からなっている。
知識は、「何をするか」または「なぜそれをするか」という二つの質問に答えてくれる。スキルは「どうやってするか」を示すものである。やる気は動機であり「それを実行したい」という気持ちである。生活の中で習慣を確立するためには、この三つの要素がどれも必要である。

「誰も説得によって人を変えることはできない。すべての人は堅くガードされた心の変化の扉を持っており、その扉は中からしか開けられない。説得や感情に訴えることによって他人の扉を外から開くことはできない」（マリリン・ファーガソン）

人間は刺激と反応の間に選択の自由をもっているということである。この選択の自由の中にこそ、人間の人間たる四つの独特な性質〈自覚・想像力・良心・自由意志〉がある。

本当の意味では、自分の身に起こる出来事によって傷つけられるのではない。自分がその状況を容認するという選択によって、傷を受けるのだ。

「主よ、変えるべき変えられることを変える勇気を、変えられないことを受け入れる平和を、そしてその区別をつける知恵を与えたまえ」

組織のミッション・ステートメントをつくるプロセスには、時間、忍耐、参加、スキル、感情移入が必要なのだ。ここでもまた、応急処置ではだめなのだ。システム、組織、マネジメントのスタイルを、共有化されたビジョンと価値観に合わせるには、時間、誠心誠意、勇気、および誠実といった正しい原則に基づく行動・態度が必要である。正しい原則にさえ基づいていればそれは可能であり、素晴らしい結果を生み出すことができる。
組織の全員の深く共有されたビジョンと価値観を、本当に反映している組織のミッション・ステートメントは、強い一体感と強い決意を作り出すものである。人々の心の中に自律のための基準とガイドラインを植えつけることにより、指示、管理、批評、評価する人は必要でなくなる。なぜなら、従業員はその組織の核心を、自分のものとして受け入れているからである。

「成功者たちの共通点は、成功していない人たちの嫌がることを実行に移す習慣を身につけているということである。彼らにしてみても、必ずしも好きでそれを行っているわけではないが、自らの嫌だという感情をその目的の強さに服従させているのだ」（E・M・グレー）

ピーター・ドラッカーの言葉でまとめれば、「大きな成果を出す人は、問題に集中しているのではなく、機会に集中している」ということである。彼らは機会に時間という餌を与え、問題を餓死させようとするのだ。彼らは予防的に物事を考えるのである。

最も優先すべきことが何なのか、しっかりと決めておかなければならない。そして、気持ちよく、笑顔で、率直に、それ以外のことに対して「ノー」と言う勇気を持つ必要があるのだ。ためらうことなく、「ノー」と言えるようになる秘訣は、自分の中でもっと強い、燃えるような大きな「イエス」を持つことである。小事に振り回されてはならない。「最良」の敵は「良い」なのだ。

信頼は人間にとって究極の動機づけである。それは人の最善の姿を引き出すものである。しかし、それには時間と忍耐が必要だ。そして、人はその信頼にこたえられるレベルまで能力を引き上げるための訓練が、必要になることもある。

人間関係づくりに最も大切な要素は、私たちが何を言うか、何をするかということではなく、私たちはどういう人間であるのかということである。そして、私たちの言葉や行動が自らの中心（人格主義）からではなく、上辺だけのテクニック（個性主義）に起因するものであれば、人は私たちの二面性を感じとることだろう。そういうやり方では、効果的な相互依存関係をつくり上げ、維持するための土台は絶対にできない。
人間関係に大きな力を発揮するテクニックが本当にあるとすれば、それは真に自立した人格から自然にあふれ出るものでなければならない。だから、関係を築き始めるべきところはまず自分の内面であり、自分の影響の輪の中であり、自分の人格を育てることである。自立するにつれて--主体的になり、正しい原則を生活の中心におき、価値観に基づいて誠実に優先課題を計画し、それを実行する力を育成するにつれて--相互依存を選び、充実した、継続的で生産的な人間関係を築くことができるようになる。

「大衆の救いのために勤勉に働くより、ひとりの人のために全身を捧げる方が気高いのである」（ダグ・ハマーショルド）

Ｐ（目標達成）の問題はＰＣ（目標達成能力）の機会である

相互依存状態において、Ｗｉｎ－Ｗｉｎ以外は、低次元の選択であり、長期においてはお互いの関係に悪影響を及ぼすことになるだろう。その影響からもたらされる弊害を考慮しなければならない。本当のＷｉｎ－Ｗｉｎを達成することができなければ、Ｎｏ Ｄｅａlを選ぶ方が適当である。

Ｗｉｎ－Ｗｉｎの実行協定をつくるには、基礎的なパラダイム転換が要求される。なぜなら、Ｗｉｎ－Ｗｉｎの焦点は、手段ではなく結果にあるからである。しかし、ほとんどの人は、手段を管理する習慣を身につけてしまっている。

Ｗｉｎ－Ｗｉｎの結果を望んでいる人や組織に対しては、次の四ステップのプロセスを勧めている。

１．問題を相手の立場から見る。本当に相手を理解するように努め、相手と同じくらい、あるいはそれ以上に、相手のニーズや心配・関心事を表現する。
２．対処しなければならない課題と心配事（立場ではない）を明確にする。
３．完全に納得できる解決には、どういう結果を確保しなければならないかを明確にする。
４．その結果を達成するための新しい案や選択肢を打ち出す。

私たちは、急いで問題の中に飛び込んで、何かのアドバイスで問題を解決しようとする傾向がきわめて強い。しかも、多くの場合、診断する、あるいは問題を深く理解する時間をとることを忘れてしまっている。
人間関係について私が今まで学んだもっとも大切な教訓を要約すれば、それは「まず相手を理解するように努め、その後で、自分を理解してもらうようにしなさい」ということである。この原則が、人間関係における効果的なコミュニケーションの鍵なのである。

「理解してから理解される」ことは、大きなパラダイム転換が必要である。話をしているとき、ほとんどの人は、理解しようとして聞いているのではなく、答えようとして聞いているのだ。話しているか、話す準備をしているか、二つにひとつである。

優秀な営業マンは、まず顧客のニーズや関心、あるいは状況を理解しようとする。つまり、素人は商品を売り、プロはニーズや問題に対する解決を売るのだ。これは全く異なるアプローチである。プロは診断し、理解する方法を学ぶ。人とのニーズと自分の持つ商品を結び付ける方法も学ぶ。そして、時と場合によっては、「私の商品やサービスは、あなたのニーズを満たさない」という誠実さを示さなければならない。

人は理解されたい。だから、理解することにどんなに大きな時間の投資をしても、必ずそれを上回る時間の回収ができる。なぜならそれは、問題と課題に対する正しい理解と、人が深く理解されていると感じるときに発生する信頼残高をもとに、物事を進めることができるからである。

まず理解することを求めよ。問題が起こる前に、評価したり処方したりする前に、自分の考えを打ち出そうとする前に、まず理解しようとする。それが相互依存の強力な習慣なのである。
真にお互いを深く理解するとき、創造的な解決や第三の扉が開かれる。お互いの相違点が、コミュニケーションや進歩wp妨げる障壁にならなくなる。逆にシナジー、相乗効果への踏み台になっていくに違いない。

運動をすることで得られる最大のメリットは、第一の習慣である主体性という精神的な筋肉を鍛えることだろう。運動を妨げる様々な外的要因に反応せず、健康を大切にする自分の価値観に基づいて反応するとき、自己パラダイム、自尊心、自信、誠実さなどは深く影響を受けるに違いない。

「人生の最大の闘いは、日々自らの魂の静けさの中で闘われるものである」（デイビッド・O・マッケイ）

「いつの日か、いや何年か先のことかもしれないが、あなたは大きな誘惑と格闘し、あるいは人生の深い悲しみの重荷を背負い、その重さに震えることがあるだろう。しかし、本当の闘いは”今”なのだ。どうしようもない悲しみや誘惑の日に立ち向かい惨めにもそれに敗北するか、あるいは栄光をもって勝利するか、それは今決まりつつある。人格は、地道な長期的プロセスによってしか、形成できないものだからである」（フィリップス・ブルークス）

「これこそ人生最大の喜びである--自らが偉大と認める目的のために働くことである。世界があなたを幸せにするために働いてくれないとつねに文句を言い続ける興奮した、わがままな病気と不平の小さな塊ではなく、自然のひとつの力になることである。私が思うには、私の人生はコミュニティー全体のものであり、命があらん限りそれに仕えることは私の特権である。私は死ぬ時に、ことごとく使われ果てていたいのだ。熱心に働けば働くほど私は生きるからである。人生を人生のために喜ぶ。人生は私にとって短いろうそくではない。それは今の瞬間にかかげる素晴らしい松明であり、次の世代にそれを渡すまで、できる限り赤々と燃やし続けたいのである」（ジョージ・バーナード・ショウ）

「奉仕とは、この地球に住む特権を得るための家賃である」（N・エルドン・タナー）

「現在の姿を見て接すれば、人は現在のままだろう。人のあるべき姿を見て接すれば、あるべき姿に成長していくだろう」（ゲーテ）

本当の安定は、財産を持つことではなく、財産をつくり出す能力を持つことである。つまり、外的なものではなく、内的なものなのである。

「良心の声はいかにもか細く、もみ消すことは簡単である。しかしその声はあまりにも明瞭で、聞き違えることはない」（スタール夫人）

アジャイル開発を実践する22の方法

マリー・ポッペンディーク/トム・ポッペンディーク
平鍋健児/高嶋優子/佐野建樹訳
日経BP社

1日30分は勉強することにしているのですが、読む本がなくなったからと言って、期待せずに読み始めた、積読だった本書。「はじめに」と「イントロダクション」だけで衝撃を受けました。実に鋭い考察の数々。そのエッセンスをお送りします。

はじめに

CMMやPMIを非難するわけではない。ただ、産業界でのリーン改革を経験してきたものから見れば、それらはソフトウェア開発にムダな要素を与えやすいように思える。ソフトウェア開発のパラダイムを、プロセスから人へ、ばらばらの個から集団へ、推測からデータにもとづいた決定へ、計画から学習へ、トレーサビリティからテスティングへ、コストとスケジュールの管理からビジネス価値の提供へと変えることが、本書のねらいである。
高品質と低価格とスピードは、本当に共存できないのだろうか？リーン手法を知る前、製造や製品開発を行っていたころには、私たちも「できない」と思っていた。しかし、価値とフローと人に焦点を当てることによって、高品質、低コスト、迅速な出荷を実現できる。それを私たち自身、市場からから逃げ出していった競合他社から学んだのだ。

イントロダクション

メタファを使いあやまった場合にリスクがあることを承知で言えば、ソフトウェア開発は製造ではなく製品開発と似通っていると私たちは信じている。

製造の最終段階での変更による莫大な損失の回避方法として、最初から設計に関して正しい決定を下し、それ以降、変更する必要をなくす、という方法がある。これがデトロイトの手法だ。トヨタやホンダは、設計に関する不適切な決定の損失を避けるのに別の方法を発見した。それは、「取り消しのきかない決定を最初にしないこと」だ。設計に関する決定をできるかぎり先延ばしにし、決定するときには、わかっている情報を総動員して、正しく決定する。この思考は、トヨタが開拓したジャストインタイム生産の背後にある、「顧客の注文を受けるまで、何を作るべきか決めてはいけない。注文を受けてから、できるだけすばやくそれを作れ」という思考に通じるものがある。

「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか、である。原則は普遍的なものだが、それらが特定の環境にどう当てはまるのかが、わかりにくい場合もある。一方プラクティスは、何をすべきかについて明確なガイダンスを示してくれるが、それぞれの分野に適応させる必要がある。私たちは、「ベスト」プラクティスなどというものはない、と信じている。プラクティスは、コンテキストを考慮しなくてはならない。

ムダを排除する。
ムダとは、顧客が認める価値を、製品に付加しないもの、すべてのことだ。リーン思考では、ムダという概念を最大の問題としている。部品がちりの積もった棚に置かれたままになっていたら、それはムダだ。要求を集めた文書が、使われないまま埃をかぶっていたら、それはムダだ。製造工場が、すぐに必要となる以上の量を生産しているのなら、それはムダだ。開発者がすぐに必要となる以上の機能をコーディングしているのなら、それはムダだ。製造の過程で、製品をあちこち移動させるのはムダだ。製品開発において、あるグループから別のグループに開発を引き継ぐのはムダだ。理想は、顧客が欲しがっているものが何かを見つけだし、製造するか開発して、顧客が要求するそのものをただちに納品することだ。顧客のニーズをすぐに満たすのにじゃまとなるものはすべて、ムダなのだ。

決定を遅らせることには価値がある。なぜなら、推測ではなく、事実にもとづいている方が、より的確な決定を下せるからだ。成長中の市場では、早期に確定するよりも、いろいろな設計オプションを選択可能にしておくことに価値がある。複雑なシステムを開発している場合に、決定を遅らせるためにキーとなる戦略は、システムに変更可能性を組み込むことだ。

第2章　学習効果を高める

どういうわけか、可変性は悪であるという考えがソフトウェア開発に入り込んでしまった。ソフトウェア開発では、可変性をおさえ、毎回繰り返し可能な成果を得るために、標準化されたプロセスを作りだそうとしてきた。しかし、開発は繰り返し可能な成果を生み出そうとはしていない。開発とは、それぞれの顧客の問題に適した解決を作りだすものなのだ。

今日では、設計は、調査、実験、結果確認を短いサイクルで繰り返すことを通じて解を発見するという、問題解決のプロセスであることが広く受け入れられている。ソフトウェア開発は、あらゆる設計と同じように、そのような学習サイクルを通して行われるのが一般的である。

ソフトウェア開発の思考には二つの流派がある。一つは、開発者に、最初から確実に設計やコードを一つひとつ完璧にするように、と奨励する流派である。もう一つは、最初から設計やコードを確実に完璧にするよりも、小さく、迅速に試し、テストをし、失敗すれば正しくするというサイクルで進めた方がいい、という流派だ。前者の流派では、経験によって知識を得るのではなく、知識は熟考とレビューによって得られるものと信じている。最初から正しく進める前者の手法は、良構造問題に関してはうまく機能するだろう。しかし、試し、テストをし、直すという後者の手法が、悪構造問題には適している。

リファクタリングをともなったイテレーション、つまり、システムを発展させながらの設計改善は、知識を獲得し、早く答えを見つけだし、統一性のあるシステムを作り出すための、最も効果的な方法の一つであるとわかっている。

仕事をするのなら、それは、「直接顧客」のための仕事でなくてはならない。すなわち、だれかがどこかで、その仕事の成果を待ち望んでいる、という状況でなくてはならない。開発者は、直接顧客を知っているべきだし、その顧客が定期的なフィードバックを返せる方法を用意すべきである。問題が起きたら、最初にすべきことはフィードバックループがすべてうまくいっているかどうかを確認することだ。つまり、各自が自分の直接顧客がだれなのかを知っていることを確認する、ということだ。次にすべきことは、問題領域のフィードバックループを短くすることだ。

あらゆるアジャイルソフトウェア開発手法にも、あらゆる場面で適用するスタート地点がある。それは「イテレーション」だ。イテレーションは、ソフトウェアを設計し、プログラムし、テストし、統合し、提供するための、長さを固定した短いサイクルだ。製品開発でのプロトタイプと非常によく似ているが、イテレーションは最終的な製品の一部を、きちんと動作するように作りだすという点が違う。そのソフトウェアは、後のイテレーションで改善されることになるだろうが、最初からきちんと動作し、テストもされ、統合されてもいるのだ。イテレーションによって、シークエンシャルソフトウェア開発に比べてフィードバックの量が劇的に増加する。そして同時に、顧客やユーザーと開発者の間の、また、そのシステムに関心を持ついろいろな人たちの間のコミュニケーションが大幅に増加する。テスターは最初のイテレーションからプロジェクトの参加し、ハードウエアやソフトウエアの環境も早期に考慮される。設計の問題点は早期に見つかり。変更が入るごとに、変更に対する耐性がシステムに組み込まれていく。

ビジネス価値が最も高い機能を先に提供するため、最優先の機能から先に開発するべきだ。リスクの高いものは、後になってからではなく、早いうちから注意を向けておくべきだ。

スタンディッシュ・グループの研究によれば、典型的なシステムの機能のうち、45パーセントは一度も使われることがなく、19パーセントはほとんど使われることがないそうだ。プロジェクトが始まる時点で、顧客が自分の欲しいものを正確に知っていることはめったにない。そのため、彼らは必要かもしれない機能をすべて求める傾向にある。要求を出すチャンスが一度しかないと思えばなおさらだ。この方法をとると、私たちの経験上、プロジェクトの全体的なミッション以上にスコープを広げてしまう可能性が非常に高い。顧客にプライオリティが最も高い機能だけを要求させ、それをすばやく提供し、それから次にプライオリティの高い機能を要求させれば、重要機能のリストは短くなるはずだ。また、変化していく顧客の事情に対応することもできる。そのため、機能をプライオリティの高い順に並べ、上から順に手をつけていくのがいい。一般的に、この戦略を使えば、確保されたリソースがなくなるまでに、全体的なミッションを達成できるはずだ。

イテレーションは、実現可能な解決の一実証例としてとらえるべきであり、唯一の解決としてとらえるべきではない。早期のイテレーションでは、システムの残りの部分を、実現可能性のある多くの方法で実装できるように、幅広い余裕を残しておくべきだ。イテレーションが進み、さらに選択されていくにつれ、設計の余地は徐々にせばめられていくべきなのだ。

第3章　決定をできるだけ遅らせる

プログラミングは、金型の切削とよく似ている。リスクが高い場合が多く、ミスが大きなコストにつながる。そのため、開発が始まる前に要求を確立しておくシークエンシャル開発が、深刻なエラーを防ぐ方法だと一般には考えられている。シーケンシャル開発の問題は、設計者が「広さを優先した設計手法」ではなく、「深さを優先した設計手法」を取らざるをえないということだ。深さ優先の手法を採ると、高レベルの決定の結果が出る前に、それが依存する低レベルな決定を下さなくてはならなくなる。もっとも費用のかかるミスは、最初の時点で、重要なことを見落とすことによって生まれる。そのような大きなミスは、詳細に速く掘り下げすぎた場合に最もよく起きる。詳細なパスを確定してしまうと、後戻りができなくなるし、後戻りすべきだということにも気付きにくくなる。大きなミスを起こす可能性があるなら、全体を見わたし、詳細な決定は遅らせるべきだ。

賢明な決定を下せる専門知識を備えた人を育てる方が、人の代わりに考えてくれると称する意思決定プロセスを育てるよりも、ずっと重要なのだ。

第4章　できるだけ速く提供する

急な事態では、情報が指揮系統のチェーンを上がり、そして指示として下す余裕はない。そのため、現場での情報伝達とコミットメントの方法を、それにふさわしいものに作り変える必要がある。そのために重要な要素の一つは、スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ。

第5章　チームに権限を与える

ワッツ・ハンフリーは、CMMの初期開発を先導した人物だ。彼は、訓練された、やる気のある人材がいなければ、ソフトウエア開発が成功することはない、と信じている。私たちはこの意見にまったく賛成だ。しかし、その「最も成功を収めやすい」というプラクティスには、敬意は払うが反対する。・・・私たちは、やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている。つまり、決定権を組織のできるだけ下位のレベルに移し、それと同時に、その人たちの聡明な決定能力を開発することだ。

私たちは、ある環境から別の環境へのプラクティスの移植は、間違いである場合が多いと、確信している。そうする代わりに、プラクティスの背後にある基本的な原則を理解し、それらの原則を、新しい環境に合わせた新しいプラクティスに置き換えなくてはならない。

モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神（zero defects mentality）と呼ばれているものだ。ゼロ欠陥精神は、絶対にミスを許さない雰囲気のことである。つまり、どんな些細なことにでも完全性が求められる。軍隊では、ゼロ欠陥精神をリーダーシップの深刻な問題であると考えている。なぜなら、それが戦場での成功に必要な率先力をそこなうことになるからだ。

人は、自分が置かれた組織の期待にこたえるものだ。プロセスやドキュメント、計画の厳守に価値を置く組織では、ソフトウエア開発のリーダーは、多くは生まれてこないだろう。組織が自らの価値を定義すれば、その価値にあったものが手に入る。
第6章　統一性を作りこむ

そこで、チーフエンジニアの役割は、その車の設計が見えてきたら、最大の認知統一性を持たせられるようにトレードオフを判断できる環境を作ることなのだ。だから、チーフエンジニアは、エンジニアたちが多くのトレードオフと闘う中で、何に苦戦しているのかを理解しなくてはならない。そして、自分たちの決定がどのように製品の統一性に影響するかを、彼らが理解できるように手助けをするのだ。

伝統的には、要求は文書化され、アナリストのチームに手渡されるものである。そして、分析を行い、その結果を設計者に手渡す。設計者はソフトウエアを設計し、その結果をプログラマに渡す。どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ。彼らはシステムの統一性について、顧客がどう受け取っているのかを理解した段階から、ドキュメント2,3個分離れている。そのドキュメントを引き継ぐたびに、かなりの量の情報が失われたり、誤解されたりする。最初から理解されていなかった詳細部分のキーポイントや将来の機能については言うまでもない。

あるモデルが有用かどうかを判断する方法の一つは、そのモデルが最新に保たれているかどうかを観察することだ。モデルを最新に保って、使えるようにしておくことが重要であると信じている人がいるが、私たちはその逆だと思っている。モデルが有用でなくなれば、メンテナンスされなくなるはずだ。一時的に役立つモデルを作り、それが最終的に使われなくなるのはかまわない。しかし、ただそれがいい考えのように思えるからというだけで、モデルを作ってメンテナンスをするのは、ムダである。モデルが熱心に参照され、メンテナンスされていたら、有用なモデルを編み出したということがわかる。

設計をテストとして文書化することで、開発者はそれがどう動くと想定されているかを正確かつ明快に理解しながらコーディングすることができる。これは、考えを洗練し、開発者がコンセプト統一性を持ってコーディングする助けとなる良い方法である。

自動テストスイートは、建築中の大きな建物のようなソフトウエアを仕上げる際に、システムの建築者に安全と通路を提供する足場であるといえる。この足場なしに、他のツールを効果的に使うことはできない。テストを作成すると開発が遅くなるように思えるかもしれない。実際には、テストはコストではなく、開発期間中とシステムライフサイクル全体の両方で利益をもたらす。

第7章　全体を見る

多くの人は、新製品を発表し大きな成功を収めている企業が、製品開発プロジェクトのコストやスケジュールを管理していないと聞くとびっくりする。なぜかって？コストとスケジュールがプロジェクト管理では重要なことである、と思い込んでいるからだ。コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない。そのうえ、コストとスケジュールに注目すると。究極の目的、すなわち顧客の要求に合致し、競争優位のある利益の高い新製品を開発して商売する、ということが見えなくなってしまう。

「測定したものしか得ることができない」という基本原則はこの場合でも成り立つ。重要なものすべてを測定できない場合、部分的に測定すると局所最適な計測手段となる可能性が高い。もし、ビジネス全体としての成果を最大化するのに必要な「すべて」を測定できないのであれば、局所最適化した部分的計測などない方がよい。中途半端な計測手段を持っていると、局所最適な行為を助長する大きな危険にさらされるだろう。

全てが測定されるような方法を確実に行うには、全体を測定すべきであり、分解して測定すべきではない。すなわち、測定手段を1段階下ではなく、1段階上へ移動させることだ。ニューコアは、個人ではなくグループの生産性を測定したことを思い出していただきたい。３Ｍは、製品のコストではなく、製品により生み出されるビジネスの利益性を測定する。

リスクは、それに最もうまく対処できる側が持つべきだ。定額契約では、本来顧客が対処すべきリスクが、ベンダーに移されているように見える。問題が技術的に複雑であれば、そのリスクに最もうまく対処できる立場にいるのはベンダーだ。だから、ベンダーがリスクを受けるのが適当だろう。しかし、問題がはっきりしない場合や変化している場合には、顧客がリスクを対処するのに最適の立場にいる。したがって、定額契約は避けるべきリスクである。定額契約が避けられない場合は、変更が入るのは確実なので、コストが決められた額を大きく超えるという事態を顧客自らが招くことになるだろう。

第８章　使用説明書と保証書

考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に。

この本は会社員時代に、ワインバーグに心酔していた時期に購入し、途中まで読んで、数年間そのままになっていたものです。

原題は、ソフトウェア品質管理 Vol.4、「先を見越した変革」。シリーズの4冊目で、組織としての変革に焦点が当てられています。

中身が濃い本で、要約は不可能なのですが、いつものように抜粋でエッセンスを感じてください。

I.　変革の実現をモデル化する

ソフトウェアの管理者は単にソフトウェアを育成するだけではない。同時に、ソフトウェア組織も育成しなければならない。このとき、組織の育成に比べれば、しばしばソフトウェアの育成努力など造作もないように見える。

2.サティアの変革モデル

システムは、外部要因を無視しようとはするが、まったくは無視しきれない。組織はふつう外部要因を排除して、「いままでの状況」に戻ろうとする。というのも、サティアが言うように、
慣れは、つねに快適さより強力である。

3.変革に対する反応

歴史的に、ソフトウェア工学組織において、ほとんどの戦略的な変革計画はうまくいかなかった。ツールは購入されても棚ざらしになった。方法論は何年間も取り組まれた挙句に決して定着しなかった。そこで、ナオミ・カーテンが言う通り次のように一時的流行がやってくる：
人びとは最新かつ最大の一時的流行を信じ込んで、人々が体験すべき変革がとてつもなく大変でめったにうまくいかないのを理解しないで、一時的流行に猪突猛進する。リエンジニアリングが良い（つまりは、悪い）事例である。突然、リエンジニアリングの偉大な導師（グル）たちは、人的要素の問題を過小評価したと尻尾を巻いている次第だ。
これらの事例のいくつかでは、計画がまったくなかった。しかしながら、計画にあったときでさえ、変革に対する個々人の反応が留意されなかった。これが、「予知」（パターン４）組織が変革計画者と変革実線家あるいは変革アーティストの双方を必要とする理由である。

あまりにも性急に速く、多くの変革を組織に押しつける管理者は、加速しようとしているまさにその変革を遅らせてしまう。同時に、もし管理者が「多くの変革を試みよ。そうすればそのうちのいくつかは定着するだろう」という戦略を採用すると、最後にはそれらのいずれも定着しないことを思い知らされる。

第9章　戦術的変革計画

リスクアセスメントはリスク管理ではなく、リスク管理の第一ステップにすぎない。第二ステップはリスク低減計画作業、すなわち予測不可能な環境下で予測可能な結果を得るための計画作業である。

第10章　ソフトウェアエンジニアのように計画する

工学とは、ある環境下でできるだけ多くを獲得するアートであるから、欲しいものすべては獲得できないときにこそ行使するものなのだ。工学とは、何かをあきらめる代わりに何を獲得するか、それはなぜかについての意識的な意思決定を意味するのである。

ソフトウェア工学管理は一連の選択であって、一連の強制ではない。良いソフトウェア工学管理とは、ベストプラクティス曲線上かその近辺にある。変数間のもっとも望ましい取捨選択（トレードオフ）を表すある地点に留まる能力のことなのである。

誰だろうとどんなグループだろうと、上下に安定したシステムから逸れて作業遂行することは全く不可能だ。システムが不安定だと何でも起こる。見てきたように、管理の仕事はシステムを安定化させることだ。不安定なシステムは管理層に対するバツ印なのである。

第11章　安定的ソフトウェア工学の構成要素

しかし最終的にはなすべきことを知るだけでは十分ではない。ソフトウェア障害の最大の原因は、管理層の性格と人格の障害であって、こうしたあまりにも人間的な障害が組織的変革を制限している。階層組織における管理者の職権故に、彼らの小さな愚行すら文化変革の最善の努力を水泡に帰してしまう。管理者は適合的に行動する必要があり、そうでないかぎり結果は破局に到る。

構成要素は根本的なだけに、改善をたやすいものと思ってはいけない。多くの組織で、改善を目指すソフトウェアプロセスを吟味する試みは、強い政治的反対に遭遇する。権力構造が専断的であればあるほど、あからさまな検討がもたらす脅威は大きい。

第12章　プロセス原則

テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。

統計的プロセス制御は、ソフトウェア制御に適用できないと主張する人々を信用するな。彼らに欠けているのは、そうした制御を適用する正しいレベルととるべき適切な行動である。たとえば、彼らはコードの欠陥を計測するかもしれないが、その情報を設定されたしきい値を満足しない個人を責め苛むために用いるのだ。

どんな事柄でも不可視になるのを許すな。要件も、設計も、コードも、とくにテストはいけない。予防は治療よりもはるかに容易なのだ。

第13章　文化とプロセス

長い目で見て社会の強さは、ふつうの人々が自主的に行動するしかたに依存する。ふつうの人々は非常に大勢いるから重要なのであり、始終すべての人びとの監視などできないから、自主的な行動が重要なのである・・・。この自主的な振舞いこそ、わたしのいう「文化」なのだ。----J.ファローズ

管理層が伝達するすべての主題が意図的だとは考えられない。今日のソフトウェア組織に共通する主題は、意思決定してもそれを遵守できないことである。この主題は、管理層がする何かによってではなく、ほとんどは管理層がしない何かによって伝達される。

中間管理者が、自分の仕事を適切にしている場合、何がなされるかではなく、どのようになされるかにかかわっている。つまり彼らは、実際になされる事柄の背後にある理想モデルにかかわっているのだ。

フィル・フーラーの示唆：「わたしが組織文化に使用するリトマス試験は、別種の問題に遭遇した時の彼らの生産性である。たとえば、あるスイッチングシステム開発組織は非リアルタイム・クリティカルシステムにどのように取り組むだろうか？彼らに、新しい状況にどのように取り組むか尋ね、それから学習にどんなプロセスを用意するか注視すれば、多くの事柄を発見できる。」

第16章　要求定義プロセスを改革する

多くのソフトウェア組織にとって、高品質実現の主要な障害は不十分な要求定義（要件）プロセスである。

要件文書はソフトウェア製品によく似ている。それはソフトウェアのように情報製品であるから、
・可視化しなければならない
・安定させなければならない
・制御可能にしなければならない

粗悪な管理状況下では、要件の可視性はコードのそれより低くなったりする。プロジェクト内の人びとは少なくともコードについて考えるが、往々にして要件のことは忘れてしまうのだ。もっともよくあるタイプの要件欠陥はおそらく、プロジェクトの内の誰もある分野の要件について考慮しなかったというものである。よく忘れられる要件はたとえば、性能、操作性、保守性、セキュリティ、現行データの変換、現行システムとの統合、そして製造へのカットオーバーである。

管理者が要件落ちのないように保証する最も効果的な方法は、疑いもなく、要件開発をちょうどソフトウェア開発のように現実のプロジェクトに仕立てることによって可視化することである。

第17章　プロジェクトを正しく開始する

プロジェクトを制約する意思決定につながる一連の高レベルの交渉が、すべてのプロジェクトに先行している。情報が揃っていてかつ適合的な交渉でなければ、プロジェクトは開始以前から命運が尽きている。

以前この企業の「計画作業」たるや、リスク問題を提起した者全員がすでに策定済みの「計画」にコミットするまで、焼きを入れるという意味だった。

問題はしばしば、明確化に対する組織の恐怖に根ざしている。顧客は明確な要求定義を文書化すると、文書化した要件を満たすシステムが現実の必要を満たさなくなる場合、変更を発案した責任を負わなければならなくなる。開発者のほうは明確な要件を文書化すると、それを満たす説明責任を負わなければならなくなる。コストとスケジュールの見積りが不正確だとわかってしまうと、自らをリスクにさらす可能性がある。したがって。顧客と開発者は正反対の動機で動いているにしても、暗黙のうちに共謀して、「成熟度モデル」の要件管理慣行の履行を阻止しかねない。

注力時間報告をプロジェクト追跡に用いるな：それは単なる入力の計測であって、出力の計測ではない。努力ではなく成果を計測せよ。

管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として、非難文化において愛好されている。

第18章　プロジェクトを正しく持続させる

計画は、敵の最初の一手までは有効である。----チェスの格言/軍事の格言

プロジェクト途中の管理者の仕事の多くは、不測の事態に対処するために一種類のスラック（余裕）を他の種類のスラックと交換することなのだ。

逆説的だが、人びとはスラック（余裕）を時間の浪費と考えて嫌悪するが、ほとんどのプロジェクトは、スラックを許容したほうが速く進捗する。

第19章　プロジェクトを正しく終結させる

これらのプロジェクトはスターリンの産業化政策の特徴だった。それは、小規模のプロジェクトよりも巨大プロジェクトを、安全性よりも成果を、人間よりも技術を、現場の自発性よりも硬直した中央集権的計画を、批判的論争を犠牲にする密室的意思決定を、そしてとりわけ狂気じみた猛進を重視したのであった。---L.R.グラハム

おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。

「レビュー可能でない」ということは、それ自体が一つのレビュー結果である。もしレビューできていないなら、それが正しいわけがないし、出荷すべきではない。

ほとんどの遅延プロジェクトは、コーディングがかなり進捗するかもしくはテスト作業が始まるまで、日程通りにいっているように見える。そのとき、早期に行ったあらゆる便法的作業がテスト作業を遅らせて行き詰まり、プロジェクトが頓挫する。欠陥予防あるいはインスペクションを通じて早期に品質管理をしたプロジェクトは、テスト作業を一気に通過する。---ケイパース・ジョーンズ

士気は、プロジェクトの成功確率についての全メンバーによる総合評価と考えることができる。

第20章　小さく構築し、構築を加速する

構築プロセスの加速に活用できる基本戦術が二つある：
・構築能力を増強する
・構築規模を縮小する

結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。

後から出てくる要件を追加するために、わずかな追加時間をやすやすと受け入れる罠にはまるな。システム規模のダイナミックスは非線形だから、後から出てくる要件の影響の見積りにあたっては、かなり気前よく構える必要がある。

これらすべてを勘案すると、当初計画が200人日のプロジェクトは、所要規模が10パーセント増加すると、うまくいっても250人日以上にはやすやすと延長しかねない。既に100日経過した後で新規案件が出てきた場合は、その撹乱効果のために延長分はもっと大きくなる。

「人助けモデル」を銘記せよ：ほとんどの場合、見かけによらずすべての人びとは協力的たろうと心がけている。一般的に、顧客はただソフトウェア品質ダイナミックスを理解していないだけであり、それは読者の専門で彼らの専門ではない。

第21章　情報資産を保護する

通常、標準の影響は多くの小さな節約からなるため、標準の資産価値はややもすると見落とされる。読者に標準があれば、すくなくとも管理すべきコードがはるかに少なくなるので、構成管理ははるかにやさしくなる。

多くの開発者は、コードを書いているときはかなり慎重でも、単体テスト作業のときには修正作業に熱中して、原バージョンが保有していた設計完全性をすべて破壊してしまう。この過程で彼らはまた、モジュール履歴についての価値ある情報も破壊する。

「予知」（パターン4）組織を創造するには、読者は過去を知らなければならないが、それは他に未来予測法がないからだ。マシン上で開発したものはなんであれ、アーカイブに格納できるし格納すべきであり、アーカイブはたえず更新しアクセス可能にしておくべきである。

第22章　設計を管理する

プロセスエラーもまた管理の悪い組織では深刻であるが、ほとんどの欠陥は要件と設計で発生する。重複作業、完全消去、更新不履行、そしてソースコードの版管理のようなプロセスエラーは、開発プロセスが原因となっている。これらの多くはプロセス改善で対処でき、それはまさに管理の責任である。

良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。

人びとに修正モードの思考を強要するな。圧力をかけるな。そうすればシステム寿命は長くなる。これが単体テスト作業をコーダーにさせない一つの理由である。

性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす。

読者があるホテルにいるとしよう。誰かが火事だと叫ぶのを聞く。消火器のところへ走り、警報気を引いて消防署を呼ぶ。全員外に出る。消火活動はホテルを改善しない。それは品質の改善ではない。それは消化なのだ。

設計にスラックを許容せよ。設計を限界までプッシュするな。スラックを性急に譲歩するな。スラックは鬼札のようなものだ：ほとんどどんな手でもそれを使えばよくなるが、一度使えばそれきりである。

要求を小さく、スラックを大きく保つことによって、要求と可能性のギャップをなるべく大きくせよ。多くのソフトウェア企業の没落は、これまでつねに、自社製品にすべての種類の機能を搭載した結果、2年の遅れをきたしてマーケットシェアを失ったことが原因だった。

設計が障害を起こしてしまう環境を三つ考えつかなければ、その設計についてまだ検討が足りないのだ。

設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら、あなたは問題を理解していないのだ。

第23章　技術を導入する

必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。

ＩＶ　エピローグ

誰もが自分の運命を自分なりのやり方でまっとうしようとしており、親切で寛大で忍耐強くある以外に、誰しもそれを手伝うことはできない。---ヘンリー・ミラー

「ソフトウエア見積もり」－人月の暗黙知を解き明かす

日経BPソフトプレス(2006)

★★★★★

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

McConnellの最新作。ソフトウェア関係者の必読書であると思います。さまざまな手法、考え方の集大成ですから、これ1冊読めば、見積もりは、ほぼ完璧です。勘と経験と度胸から決別する最初の1歩でしょう。米国の業界標準のデータも貴重です。これからの見積りが劇的に変わりそうです。

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

第1章　見積りとは

ポイント1：「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう。
ポイント2：見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること。

見積りにとって重要なことは。完璧なまでに正確であることより、有用な情報を提供することである。

第7章　数えて、計算して、判断する

ポイント30：できるときはいつでも、まず数えよう。数えられないときには、計算しよう。判断だけに頼るのは最後の手段だ。

第8章　補正と過去のデータ

ポイント36：「うちのチームは平均以下かどうか」という前提から議論するような政治的圧力のかかった見積りを避けるために、過去のデータを使用しよう。

ポイント37：見積りに使用する過去のデータを収集するときは、小さな規模で始め、自分が何を収集しているのか理解して、一貫性を持ってデータを収集しよう。

ポイント38：プロジェクトが終わったら、できるだけ早くプロジェクトの過去のデータを収集しよう。

ポイント41：できるだけプロジェクトのデータまたは過去のデータを使用して、見積もりを補正しよう。できれば業界平均データは避けよう。過去のデータを使用して補正すると、より正確な見積もりができるだけでなく、生産性に関する前提の不確実性から生じる見積りのばらつきを減らすことができる。

第9章　専門家の判断

ポイント43：タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう。

タスクレベルの見積もりを行うときは、長くても2日程度の工数のタスクにまで見積もりを分解する。それより大きいタスクだと、想定外の作業が隠れる場所が多すぎる。見積もりは4分の1日、2分の1日、丸1日といった粒度で行うとよい。

ポイント44：最良ケースと最悪ケースの見積もりを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。

ポイント45：見積りのチェックリストを使用して、個々の見積もりを改善しよう。自分の個人的なチェックリストを開発して保持し、自分の見積もりの正確性を改善しよう。

ポイント46：実績を見積もりと比較して、時間とともに個々の見積もりを改善できるようにしよう。

第10章　分解して、また組み立てる

ポイント47：大きな見積もりを小さい部分に分解して、「大数の法則」の恩恵にあずかろう。プラスの誤差とマイナスの誤差は、ある程度まで互いに打ち消しあう。

ときどき、「忘れ去られた機能」という形で、目に見えない作業が隠れていることがある。「忘れ去られたタスク」という形で隠れていることもある。タスクを忘れないようにするには、活動基準WBSを使用するとよい。見積もり対象のプロジェクトと似たような過去のプロジェクトを比較して、大きいか小さいかを考える時の微調整にも役立つ。新しいプロジェクトと過去のプロジェクトをWBSのカテゴリごとに比較すると、どの部分が大きくてどの部分が小さいかを細かく評価できる。

ポイント49：タスクが10個以下の見積もりの場合、最良ケースと最悪ケースから意味のある総見積りを計算するには、簡単な標準偏差の公式を使用しよう。

ポイント51：個々のタスク見積りに使う標準偏差を得る時には、最良ケースから最悪ケースまでの範囲を6で割ってはならない。見積もりの範囲の正確性に応じて、除数を選択しよう。

ポイント52：期待ケースの見積もりを正確にしよう。個々の見積もりが正確ならば、そこから得た値は問題を起こさない。個々の見積もりが正確でなければ、正確に求める方法が見つかるまで、そこから得た値には多くの問題がある。

第11章　類推見積り

ポイント53：新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して、できれば5つ以上の部分に分解して見積もろう。

見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積もりの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積もりの価値を下げてしまう。不確実性に最もうまく対処するためには、見積もりから先入観を排除することだ。それと同時に、根底にある不確実性を正確に表現することも必要だ。

第12章　代替指標による見積り

ポイント59：Tシャツのサイズ分けを使用すると、プロジェクトが「不確実性のコーン」の広い部分にある間、非技術系のステークホルダーが要求機能を線引きして取捨選択するのに役立つ。

第13章　専門家グループによる判断

ポイント62：グループレビューを行うと、見積もりの正確さを改善できる。

ポイント63：プロジェクトの初期の見積もりをするとき、あるいは馴染みのないシステムを見積もるとき、またはプロジェクトそのものにさまざまな分野がかかわるときは、広域デルファイ法を使用しよう。

第14章　ソフトウェア見積もりツール

ポイント64：見積りツールを使用して、手作業で作成された見積もりが正しいかどうかチェックしよう。大規模なプロジェクトほど、市販の見積もりツールを活用すべきである。

ポイント65：ソフトウェア見積もりツールの出力結果を神の信託のように扱ってはならない。見積もりツールのアウトプットも、他の見積もりと同じように、正しさをチェックしよう。

第15章　複数の見積もりの使用

ポイント66：複数の見積もり技法を使用して、それらの結果が集中しているか分散しているかを調べよう。

ポイント67：異なる見積もり技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%以内に集中するまで、再見積りしよう。

ポイント68：複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は、見積もりの方を信頼しよう。

第16章　うまくいく見積りのフロー

ポイント69：見積りのアウトプットについて議論してはいけない。アウトプットはそのまま受け入れよう。アウトプットを変更してよいのは、インプットに変更があったときか、または再計算した場合だけである。

ポイント70：まず、規模の見積もりに焦点を合わせよう。次に、工数、スケジュール、コスト、機能を、規模の見積もりから計算しよう。

ポイント72：プロジェクトの進行に従って、それほど正確でない見積もりアプローチから、より正確な見積もりアプローチへと移行しよう。

ポイント73：具体的な開発タスクを配分して割り当てる準備ができしだい、ボトムアップ見積りに切り替えよう。

ポイント74：デッドラインを達成できなくて再見積りするときには、プロジェクトの進行計画ではなく、実際の進行に基づいて、新しい見積もりを作成しよう。

ポイント75：プロジェクトの進行につれて見積り幅が狭くなるような方法で、見積もりを提示しよう。

ポイント76：プロジェクトのステークホルダーには、前もって再見積りの計画を伝えよう。

第17章　標準化された見積もり手順

ポイント79：プロジェクトの見積もりと見積もりプロセスをレビューしよう。それによって、見積もりの正確性が改善され、見積もりを作成するために必要な工数が最小化される。

第18章　規模の見積もりの課題

ポイント80：規模を見積もるために、コード行を使おう。ただし、簡単な指標が持つ一般的な制限と、コード行特有のハザード（危険性）を忘れてはいけない。

ポイント81：ファンクションポイントを数えて、プロジェクトの初期に正確な規模の見積もりを手に入れよう。

ポイント84：適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる。構築中のシステムの規模は、単体として最も大きなコストドライバである。正確に規模を見積もるためには、複数の見積もり技法を使おう。

第19章　工数の見積りの課題

ポイント85：規模の見積りから工数の見積りを正確に換算するために、見積りのサイエンスに基づくソフトウェアツールを使おう。

ポイント86：業界平均の工数グラフを使って、「不確実性のコーン」の広い部分で、大まかな工数の見積りを手に入れよう。プロジェクトが大規模なほど、強力な見積もり技法へ投資する正当性が容易に証明されることを覚えておこう。

ポイント88：すべての見積り技法が等しい結果を出すとは限らない。見積り間の集中と分散を調べる場合は、もっとも正確な結果を作り出す技法の結果を重視しよう。

第20章　スケジュールの見積りの課題

ポイント90：過去のプロジェクトと非公式に比較する公式をつかって、小～大規模プロジェクトのスケジュールを早い時期に見積もろう。

ポイント93：スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。

ポイント94：スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。

ポイント95：中規模の業務システムプロジェクト（35,000～10万LOC）では、チームの人数が7人を超えてはならない。

ポイント97：見積り間の集中や分散を調べる前に、過度に一般的な見積もり技法の結果をデータセットから取り除くこと。

第21章　計画パラメータの見積り

計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。

最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。

「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」

ポイント102：バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。

事務サポートの工数として、ベースとなる見積もり工数に5～10%を加える。

ITサポート（ラボのセットアップ、新しいソフトウェアのインストールなど）の工数として、ベースとなる見積もり工数に2～4%を加える。

構成管理と構築のサポートには、ベースとなる見積もり工数に2～8%を加える。

月あたり1～4%の要求の増加を想定する。

新しい言語およびツールを使った初めての開発を行う場合は、精通した言語およびツールで同程度の開発を行う場合に比べて、20～40%の工数増加を想定する。

新しい環境で初めての開発を行う場合は、精通した環境で同程度の開発を行う場合に比べて、20～40%の工数増加を想定する。

第22章　見積りのプレゼンテーション

ポイント104：見積りに組み込まれた前提条件は、文書化して伝えよう。

ポイント106：ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。

第23章　政治、交渉、問題解決

ポイント112：コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。

ポイント114：見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。

「富を手にする１０の戦略」

ジャック・キャンフィールド、マーク・ビクター・ハンセン、レス・ヘウィット

福岡佐智子 訳

たちばな出版（2003）

★★★★☆

「こころのチキンスープ」のジャック・キャンフィールド」とマーク・ビクター・ハンセンによる自己啓発本です。
日本語題は、際物っぽいですが、原題は、「The Power of Focus」つまり、集中することの威力、とでも訳すのでしょうか。1度目に読んだ時にも、参考になるところが多々あったのですが、今回、抜粋を作るために読み返して、本当に自己啓発のエッセンスだけを選んで考えた末に注意深く作られた本であると思いました。豊富な実話も「心のチキンスープ」みたいで、とても面白いです。

全10章からなります。
第1章　あなたの習慣が、あなたの将来を決める。

ここでは、「問題なのは1回の行為ではなく、習慣です」から「成功に至る習慣を身につけるのには時間がかかる」こと、「行動をひとつひとつ体系的に改善することによって、同時に自分のライフスタイル全般を飛躍的に改善することができます。」が述べられます。悪い習慣の見分け方や、改善の仕方が、実例をもって示されます。

第2章　手品でもいかさまでもない、フォーカスこそがすべて

この本の中心をなす章です。得意なものを見つけ、生れついた才能にフォーカスする。「どうでもいい仕事」はパーソナル・アシスタンスを雇ってやり過ごす。４つのＤによる仕事の仕訳。１．断る、２．任せる、３、後回しにする、４．すぐにやる。

（会社勤めをしていたころには、オールマイティになることを求められて、苦しんでいましたが、そのうち、欠点を補うことに力を注ぐよりも、得意なことをさらに伸ばすことに注力したほうがいい、という結論に到りました。その考えは、バッキンガム＆コフマンの「まず、ルールを破れ」で裏付けられましたが、今回、さらに、その具体的な方法を提案されたことになります。）

第3章　大きな設計図を描いているか？

１．目標設定のための１０のチェックリストを使う。（３．詳細で数字の裏付けがある、５．挑戦しがいのあるエクサイティングなもの、９．人に貢献するものである）
２.マスタープランを作って目標に優先順位を付ける。
３．目標達成のためのアルバムを作る。（目標に関連した資料をスクラップする）
４．アイデアブックを使う。（思いついたこと、役に立つことを書き留める）
５．イメージを描き、考え、見直し、反省する。
６．メンターとマスターマインド・グループ（定期的に会合し、互いに支えあう）を開拓する。
７．「成功者のフォーカスシステム」を使って週ごとに進捗を確認する。

第4章　ほどよいバランスをとる

Ｂ－ＡＬＥＲＴ。
Ｂ：Blueprint「1日の青写真」前の晩か、当日朝、作る。
Ａ：Action「行動」自分最大の結果をもたらす活動に集中。
Ｌ：Learning「学ぶ」朝、20-30分、読書する習慣を身につける。
Ｅ：(Exercise)「運動」健康に留意。
Ｒ：(Relaxing)「リラックス」充電。25分の昼寝等。定期的な休暇をとること。
Ｔ：(Thinking)「考える」1日の反省。失敗から学ぶ。

第5章　すばらしい人間関係を築く

「有害な人たちは避けること」
バフェット氏の投資するかどうかの判断（3つの質問）「私は彼らが好きか？」「彼らを信頼しているか？」「彼らを尊敬しているか？」
主たる顧客と「ウィン・ウィン」の哲学

第6章　自信は力である

やり残した仕事を片付ける
あなたの望むものはすべて恐怖の向こう側にあります。

自信を築くための6つの戦略
１．自分がうまくやり遂げたことを毎日思い起こす。
２．励ましになる伝記や自伝を読む。
３．感謝する
４．すぐれたサポート体制を築く
５．自分を励まして短期間の目標を達成する
６．毎週自分のために何かしてやる

スランプから抜け出す方法
１．自分が１人ではないことを確かめる
２．最高の業績を思い起こす
３．基本に戻る

第７章　自分の望むものを求める

求めよ、さらば与えられん

求めることによってビジネスを拡大させる７つの方法

１．情報を求める
２．取引を求める
３．推薦状を求める
４．ハイクラスの人の紹介を求める
５．追加の取引を求める
６．再交渉を求める

いかに求めるか

１．はっきりと求める
２．自信を持って求める
３．一貫して求める
４．創造的に求める
５．誠実に求める

第８章　一貫した頑固さを守る

人生には、やらなくてはいけないことは何ひとつない。

人生はすべて選択によって決まります。文字どおりすべてです。

未熟児で、小児マヒで生まれたウィルマ・ルドルフが家族の信念によってオリンピックの金メダリストになる逸話は感動的です。（人生の選択の例です）

やらなくてはいけないことはプレッシャーになり、自分で選択したことは前向きな力となる。
かしこく選べ！

２つのＡの法則
Agreement（取り決め）とAccountability（責任）
真の誠実さの基本は、取り決めを守ることです。

第9章　断固とした行動をとる

ものごとを先延ばしにする習慣になっていませんか？
先延ばしの6つの理由
１．退屈している
２．仕事に圧倒されている
３．自信を失っている
４．自己評価が低い
５．心から楽しいとは言えない仕事をしている
６．簡単に気が散る、または全くの怠慢！

あなたを後押ししてくれる2つの法則
ＴＡ－ＤＡの法則
１．考える(Think)
２．求める(Ask)
３．決断する(Decide)
４．実行する(Action)

問題解決の手引き
１．私が解決する問題は何か？
２．問題に向き合い、それと取り組む決心をする
３．わたしはどんな結果を望むか？
４．問題が解決されたらどう感じるか？一言で。
５．問題解決にはどんな情報が必要か？
６．自分にできることは何か？
７．他にどんなことが助けになるか？
８．具体的には、どんなアクションステップをとるべきか？
９．開始予定日と終了予定日
１０．結果を見直し、祝おう！

第10章　目的をもって生きる

ガンに侵され、片足を失った、テリー・フォックスがカナダを走って横断したエピソードを理想として。

３つのキーポイント
１．目的は自分の天分の延長線上になくてはならない
２．確固たる決意を持つ
３．謙虚な姿勢を保つ

人生は短いです。今日からは世の中に貢献することにフォーカスしましょう。

アート・オブ・プロジェクトマネジメント

スコット・バークマン

村上雅章 訳

オライリー・ジャパン(2006)

★★★★

「大逆転」

コンチネンタル航空－奇跡の復活

ゴードン・ベスーン／スコット・ヒューラー

日経BP社(1998)

FROM WORST TO FIRST(1998)

マイクロソフト シークレット （下）

マイケル・A・クスマノ/ルチャード・W・セルビー

山岡洋一 訳

日本経済新聞社(1995)
★★★★★

下巻からの抜粋です。

製品の開発と出荷のための５つの戦略
(1) いくつかのチームに分かれ､同時並行して仕事を進める。ただし、毎日｢同期｣をとり、デバッグを行う。
(2) 主要なプラットフォーム、主要な市場の全てに対応した各バージョンの製品を、理論的には常に出荷できる状態で用意しておく。
(3) 開発は一つの場所で行い､共通の言語を使用する。
(4) ビルド（ファイル化）のたびに、絶えず繰り返しテストを行う。
(5) 中間目標の達成､製品の出荷といった重要な決定を下す際に､数量データを利用する。

毎日のビルド―――チームの調整を保つ厳しいルール
毎日のビルドによって､プロジェクトがどのように進んでいるかを迅速に､チームにフィードバックできる。ウインドウズＮＴのソフト工学責任者、ロウ・ペラゾーリは、毎日のビルドを「苦労を伴うが実りも多いもの」と、とらえている。「毎日のビルドほどつらいものはない。しかし、これほど偉大なものもない。このため、すぐにフィードバックができるのだから。」。マイクロソフトには規則らしい規則はごくわずかしかないが、頻繁にビルドを行う規則は厳密に守っているプロジェクトが多い。

進捗状況を把握する

「仕様書作成、コーディング、テスト、保守」という局面を順次進めていく古い考え方では、完成までどれぐらいの段階にあるのかの判断が非常に難しくなる。プロジェクトの期間の80パーセントが、進捗度を80パーセントから100パーセントに引き上げるのにつかわれるケースが多いそこで、これとは違う中間目標プロセスを開発した。達成が少々難しい作業をいくつか選んで、それを中間目標までに100パーセント完成させる。この段階で、プロジェクトの進捗状況を見直す。…中間目標には、その段階で開発した機能だけで製品を出荷すると想定した場合、…製品として出荷するのに必要なこと全てをやる。…このプロセスを使っていれば、製品を完成させてから、出荷するまでの期間は極めて短くなる。…これで、すれジュールがはるかに立て易くなる。問題が起こった時は、プロセスの早い段階にわかる。…進捗状況をしっかりつかめる。

コードの半減期は短い

開発チームは常にソフトを書き直しており、一つのコードにこだわりすぎることはない。デーブ・ムーアによると、マイクロソフトでは、ソフトのコードの「半減期」は18ヶ月ほどだ。つまり、わづか18ヶ月ほどで、コードの半分が変更されたり、他と置き換えられたりしている。…クリス・ピーターズによると、再利用できるようにコードを書くことには余り重点を置いていない。コードがすぐに時代遅れになることがその理由だ。「再利用できるコードにするために時間を使っても、2年もすれば古くなっている。変化がそこまで早く、めまぐるしい世界で、どんなコードを再利用しようというのだ」

機能を変更するのは、2倍よくなる時

「ＯＳ／２は、何もかも変更しようとした。…１０パーセントの改良のために、コードを完全に書き換えたが、１０パーセントの改良ではユーザーは喜ばない。今では、製品の整合性を大切にする場合、２倍は改良されていなければ、違いは出てこないというのが、経験則になっている」クリス・ピーターズ

２０パーセントの税金としてのコードの書き直し

製品を出荷できる状態にしておくことの別の面として、次のバージョンの発売までの間に、コードの書き直しに投資している（他の祖父と開発会社で行われている「保守」、「リエンジニアリング」の作業に似ているが、マイクロソフトで箱の作業のために独立したグループは作っていない）。開発責任者は、開発時間の２０パーセントを製品の弱い部分を作り直すために当てるようにするべきだとされている。バージョン後とに確実にこれを実行していけば、製品の質は確実によくなっていく。

ビルドのたびに、絶えず繰り返してテストを行う

マイクロソフトのテストの方針を決める原則はいくつかあるが､いずれも､チームが開発と並行して絶えずテストを進められるようにするものだ。このように､開発と同時並行で絶えずテストを行う考え方は､マイクロソフト独自のものだ。ソフト会社の殆どは､開発サイクルの最後に集中してテストを行っているが､この時期にバグを処理するのは極めて難しく､時間がかかる。また､同社は製品のテストに当たって､幅広い視点を取るようになっている。
　　例えば､自動テスト・ツールを作成し､開発者はこれを使って､各自のコードを毎日テストできるほか､マスター・ソース・コードへの変更をチェックインする前には､必ずテストしなければならない。このテスト・ツールは､各製品のマクロ言語を使うか､キー入力を再現して自動的にテストをする。開発者は､バグを検出したり､特殊な条件をチェックするための特別なルーチンを入れた｢デバッグ版｣を作成し、更にコードをレビューして､コードを読むことによってエラーを探し出す。ユーザビリティ・テストでは､一般の消費者に依頼し､専用ラボで機能の使いやすさを評価する。また開発者とテスト担当者が一人づつ組むようにする（同社では､開発者一人に対して､ほぼ一人の割合でテスト担当者がいる）。テスト担当者は､まず仕様書を読み､早い段階でテスト・ケースとテスト戦略を準備する。…
　　テスト担当者が使う方法はいくつかある。一つは､体系化されたテスト・スクリプトを使う方法だ（「シナリオに基づくテスト」と呼ぶ）。スクリプトに従わず､製品を｢壊す｣ために考えられる限りの操作を試す｢ゴリラ・テスト｣もある。また､様々な人が参加してバグを探す｢バグ・パーティ｣を開く。更に､開発中の製品を自分たちで使い､初期バージョンを社内に配布し､数千本のベータ版を主なユーザに送る。これらは全て､製品を発売する前にバグを発見するためだ。

開発者中の製品の品質や効率を高めるために、開発者がデバッグコードを使う例は多い。小さな製品でも､合計で一万行のデバッグ・コードを組み込む場合がある。中でも重要なのは､メモリーとデータ構造のチェック､アサーション､検査版だ。

メモリーとデータ構造のチェック

「メモリーもチェック」ではプログラムが使用するか割り当てるメモリーを全て計算する。例えば､メモリーの自動検査でエラーが発生すると｢MIF｣(メモリーの完全性のエラー)というメッセージが表示される。これに煮た｢データ構造のチェック｣では､特別なルーチンを使って､製品のほぼあらゆるデータ構造の一貫性を確認する。これによって､プログラムがデータを正しく保存し､取り出しているかどうかを確認できる。

アサーション

きわめて一般的なデバッグ・コードに､｢アサーション｣がある。これは､ユーザーが入力するデータに関係なく､必ず結果が真になるはずの「if～then」文を実行するテストだ。…「アサーションが極めて重要なのは､…コードを書く時に､グローバル状態を理解していなかったり､グローバル状態に関して何らかの想定があることが､バグのおおきな原因の一つになっているためだ。…グローバル状態について何かを想定する場合には､コードにアサーションを組み込む習慣をつけるようにしている。…アサーションを十分に使えば､バグをすぐに見つけられるようになる。」

ベータテスト

　　ウインドウズ3.1のデータは､ベータ・テストがいかに効果的であるかを示している。最終ベータによって､発売前に発見された全てのバグのうち､22パーセントが見つかっている。

数量データに基づく機能と製品の完成のチェックリスト

マイクロソフトのプロジェクトでは､数量データに基づくチェックリストを作成し､機能と製品が完成したかどうかを決定するために使っている。

エクセル5.0の数量的データに基づき出荷準備の完了を判断するチェックリスト
Ａ．テストの完了
(1) 自動テストでエラーが発見されなかった。
(2) 手動でテストケースを実行した。
(3) マスター・ワークシート[製品の機能の概要がかかれている]できめられたテスト分野が、いづれも「完了した」とされている。
(4) 二人のテスト担当者による各分野の特別テストが完了している。
(5) すべてのバグを回帰テストし（2回以上の再テスト）､終了した。
(6) 最新の200個の重要度1と2のバグについて､再度回帰テストを行った。
(7) 製造部門に引き渡す出荷日の1ヶ月前に､セットアップと全てのコンポーネント(EXCEL.EXEを除く)が確定している。
(8) 評価の高い｢ガッツ・フィール｣調査の結果､テスト・グループは､出荷準備ができたと考えている。
Ｂ．バグの発見・処理データ
(1) バグ発見のペースが､ゼロ・バグ版（ＺＢＲ）まで鈍化傾向になり、ＺＢＲ以降は横ばいである。
(2) バグの重要度の分布が変化し､重要度3と4のバグの割合が増え､重要度1と2のバグの報告が減少し続けている。
(3) 最初のリリース候補（ＲＣ１）の「決定会議」（報告のあったバグを､現在のリリースで処理するか､次のリリースに持ち越すかについて､「処理」、「持ち越し」、「未定」に分類する会議）の後で、すべてのバグが報告され、バグが解決された際、バグの回帰テストで参考にする様々なコメントを、バグ・レポートに追加している。
(4) 製造開始日までの１週間に、テストを続けているが、「必ず処理しなければならない」バグが報告されていない。

事後分析

1980年代後半以降、マイクロソフトのプロジェクトのうち、半分から3分の2が事後分析レポートを書いており､レポートを書かなかったプロジェクトも､殆どが事後分析のための会議を開いている。事後分析レポートでは､驚くほど率直に自分たちの動きが批判されており､経営陣にまで配布されるレポートであることを考えると、なおさらそのその率直さに驚かされる。ビル・ゲイツすら､ワード､エクセルなどの大型の製品と、マルチメディアなどの新しい分野では、事後分析レポートを熱心に読んでいる。
「プロジェクトのスケジュールが不適切で､現実性を欠くスケジュールを守ろうとして圧力がかかったため、テスト過程の統一性が保てなくなった。スケジュールが非現実的であったため､出荷モードのテストが始まったのは11月であった。これが4月半ばまで続いた。つまり、テストに使った時間の40パーセントが出荷モード（6ヶ月）に費やされたことになる。疲労困憊したこの過程で、生産性が落ちたことに気づいた。…コード変更､コード1000行当たりのバグ数､コードの複雑さを示す数値等を現実的に見積もってスケジュールを立てていれば､出荷モードに移る前に､出荷モードに移る前に､後3ヶ月､組織立った徹底したテストを行えただろう。」マック・ワード4.0プロジェクトの事後分析より。

製品ではなく､プロセスに焦点を当てた事後分析

事後分析レポートは､問題を列挙していく点ではすばらしい成果を挙げてきたが、問題が起こった理由を分析し､どのような解決策がありうるかを考える点では､不十分なケースが少なくなかった。その上､同じグループで将来､同じ間違いを繰り返さないようにする方法も､別のプロジェクトの経験を組織的に学ぶ方法も確立されていなかった。ウイリアムズによれば､例えば､どのグループでも毎回のように､チームのメンバーが機能を次々の増やしていったために、スケジュールが管理できなくなったと事後分析レポートで指摘しているという。…私は、「測定していないものは管理できない」（デマルコ）という言葉が大好きだ。数量データばかりにこだわることはないし､あらゆる物を測定するべきだとも思わないが、これまで、様々な点を一貫して測定する点では、あまりいい仕事をしてこなかったように思う。例えば、開発者の1週間当たりのバグ数といったデータだ。…今、追及しているものの一つに、見積もりと現実の差の検討が甘すぎた点が挙げられる。特にスケジュールの遅れに甘すぎた。例えば、開発者が「多分、3週間でできる」といったとする。4週間半たって、「まだ終わっていないのか」と聞くと、「もう終わるところだ」という答えが返ってくる。そして、仕事が終わると、皆でその開発者のところへ行って、「よくやった」という。「3週間のはずが4週間半かかった。どうしてなんだ。何処に問題があったんだ。どんな問題にぶつかったんだ」とは、誰も聞かない。

マイクロソフト シークレット （上）

マイケル・A・クスマノ/ルチャード・W・セルビー

山岡洋一 訳

日本経済新聞社(1995)
★★★★★

マイクロソフトの内部を分析したものです。ソフト開発手法という点からも学ぶべきことがあります。
上巻から、印象にのこるインタビュー部分を書き抜きました。

マイクロソフトの幹部・社員へのインタビューによる調査、社外秘資料による同社の戦略、組織、開発プロセスを分析
した「マイクロソフト・シークレット」の概要を紹介致します。

ここでは開発プロセスに焦点をあてました。開発プロセス以外にもいろいろなアイディアの詰まった本ですので、
一読をお勧めします。

第１章　マイクロソフトの組織と管理

ＩＢＭには品質保証部門はあったが、規模はマイクロソフトには遠くおよばないし、独立した
立場から検査するという性格が強かった。ＩＢＭは対立をつくりだす経営法式を意図的にとっ
ていた。各部門がそれぞれ狭い立場から主張をするようにすれば、あらゆる角度からの事実が
報告されるので、正しい判断を下せるというわけだ。・・・ＩＢＭの開発部門で学んだことは
、悪いニュースの隠しかただった。・・・最後の最後になって悪いニュースを知らせる。
・・・これでは悲惨な結末になる。・・・当社は「手持ちの札を見せ合う」方式をとっており、
とても風通しがよい。ワードの開発者のひとりから「この部分がおかしくなっている」などと
伝える電子メールが送られてくるし、意見を交換するのが裏切り行為だとは考えられていない。
（メープルズ）

メープルズによる開発プロセスの基本原則
１．自分のスケジュールは自分で立てる。
２．プロジェクトには予見できない遅れがつきものだとの前提に立って、
　　スケジュールに予備期間を組み込む。
３．仕様書は変更されるものと考え、最初から完璧な仕様書を書こうと
　　して時間を無駄にするようなことはしない。
４．中間目標を設定し、とくに難しい部分からはじめる。
５．技術でもプロセスでもなく、ユーザーの問題に焦点をあてる。
６．社員を移動させ、よい部分と悪い部分がまじりあうようにする。

わたしのグループにはいくつかのルールがあり、それをまもるようにしている。第１に、グループ
のメンバは全員、コードのある部分を担当しており、管理だけを仕事にしている人間はいない。
・・・管理だけをやっていると、目標を見失うようになり、問題を察知できず・・・すばやい対応
がとれなくなる。・・・わたしの場合、勤務時間のたぶん５０パーセントは問題の解決と
コーディングにあてている。
（ペラゾーリ　NT3.0のソフト工学責任者）

頭のにぶい連中が大勢いて、管理者がたくさんの規則をつくって社員を管理している企業とは違う。
当社では、優秀な人材が大勢いて、だれもが正しいことをしようと必死になっている。・・・社員
の頭数だけをそろえ、たくさんの規則をつくってその埋め合わせをしようとする愚かな企業もある。
それで問題の一部は解決するかもしれないが、規則がないことが問題の根源なのではない。たくさ
んの規則をつくらなければ仕事ができない者をやとっていることこそが問題なのだ。
（クリス・ピーターズ）

規則をきらったり、規則をひつようとしない人材の雇用には欠点もある｡こうした人材は、手痛い
失敗を通じてしか学べないことが多い。われわれの印象として、マイクロソフトの開発者とテスト
担当者は、一部に例外はあるものの、ソフトウエア工学に関する論文をあまり読まず、先駆者と
解決策を再発見し、他社がはるかまえから重要と考えていた効率的なソフト開発方法に､何年も
たってようやく気づくことが多い。

第2章　創造性と技術力のある社員の管理

全体的に見ると､マイクロソフトでは開発者一人につきテスト担当者一人がついている勘定になる。
全社で約4100人の開発スタッフ（プログラム管理者、製品計画担当者を含む）のうち、1850人が
テスト担当者である。（これに対して､大型ソフトを開発している日本や米国の企業で､開発
スタッフのうちテスト担当者の比率は､高くても10から15パーセントであり､通常はこれよりはるか
に低い｡ただし、ロータスではマイクロソフトに匹敵する高さだ。）

第3章　製品と標準の競争
第4章　製品と開発プロセスの決定

これが、回転の速い消費者向けソフト開発の特異な点だと思う。開発中、すべての作業を平行して
進める。仕様書がある程度できたら､おおまかなスケジュールで作業を始め､作業を進めながら
仕様書に磨きをかけ、スケジュールを調整し､テストの方法も同時に変更していく｡しかし、すべて
をできるだけはやく、確実に先へ進めている。一瞬も止まらない。
（クリス・ピーターズ）

同社のチームは、まず、ユーザーのニーズを理解し、そのニーズから個々の機能を組み立てる。
次に、これらの機能の優先順位を決め、開発プロジェクトを3から4段階の中間目標サイクルに分けた
サブプロジェクトに機能を割り当てる。また、仕様書と製品開発の創造性を高めるため、管理者は
プロジェクトの資源を「固定」する、つまり、プロジェクトにつぎ込む人数と時間を制限するように
している。こうして固定された資源は、製品開発スケジュールを決める主要な要因になる。

開発と安定化の機関のうち、通常は約3分の2を開発段階に、3分の1を安定化段階に当てる。オフィス
製品部門担当副社長のクリス・ピーターズは、一般的なスケジュール管理方針について、
「スケジュール全体の中で、機能を開発する時間は半分で、後の半分はデバッグと予見できない事態に
備えておくのが通常だ。つまり、2年間のプロジェクトを始めるなら、1年間の予測を作成する。・・・
計画通り進まなければ、重要度が低いと思われる機能を削除する」と語る。この中間目標プロセスに
よって、管理者は製品の進捗状況を十分に把握でき、開発サイクル後期に、柔軟に機能を取捨選択
できる。

中間目標は、エクセルで始めて採用したものだ。今では、他のグループも全て使っていると思う。
・・・要するに、プロジェクトを3段階ぐらいに分け、・・・各段階が終わった時点で、製品を
出荷すると想定する。
（ピーターズ）

我々のグループでは、開発期間を3段階の中間目標に分けている。中間目標の期間は、6週間のことも
あるし、10週間のこともある。・・・中間目標時点の目標は、それまでに開発した機能を全て完成し、
・・・そのリリースのバグをなくすことだ。そして、そのリリースが「出荷レベルの品質」に達した
時点で、次の中間目標期間に移行する。この方法の最大の利点は、プロジェクトが完全な混乱状態に
なるのを防ぐことだ。つまり何千ものバグが残り、いつ完成するのか分からない状況になるのを防ぐ
ことだ。（マイク・コンテ）

コードの完成は、30から40人のプロジェクトでは判断しにくい。たとえば、一つのバグの処理に3日も
かかったとすれば、実際にはコードを書いているのだ。コードはまだ完成していない。・・・
プロジェクトの完成を急ぐと、バグの数は増えていく。次に、数時間で処理できるような本当のバグの
処理へと移行すると、バグの数は毎日減るようになり、出荷にこぎつける。こうなれば、バグは
はっきりと減少しはじめる。そうなったら、コードの完成だと分かる。・・・これはごまかしようが
ない。（ピーターズ）

開発者が深く考えずに「1週間かかる」といっただけで、1週間のスケジュールを組んでしまうことが
多すぎる。そこで、作用の規模をつかみ、スケジュールに予備期間を組み込むには、どのような質問を
すればいいのかを考えてきた。以前は、スケジュールに予備期間を組み込まない人が多かった。ソフト
の開発を始めてまもなく、予備期間を組み込んだスケジュールを社長に提出すると、「なんだ、釣りに
でも行く気か。この予備期間に何をするつもりだ」といわれたことがある。「経験から行って、多分
バグを処理するために必要です」と答えると、「そんなあいまいな話ではなく、具体的に何をするのか
話してみろ」といわれた。そこで「具体的に何をするのか、分かっていないから予備期間としています。
とにかく必要なので信用してください」と答えた。古いタイプの管理者にとってスケジュールに予備
期間をいれるのは常識はずれなので、開発責任者が出したスケジュールから、予備期間が消されること
も多い。「これではだめだ、もっと短縮しよう。出荷する必要がある。予備期間を減らせばいい」。
そうなると、スケジュールは非現実的になる。何に必要になるのかはわからないが、何度も何度も、
必要性を思い知らされてきた。バグを処理するためかもしれないし、途中で何か思い付いて「この機能
は是非追加するべきだ」ということになるかもしれない。・・・だから2ヶ月あるなら、1ヶ月は予備
期間にすべきだ。予備期間を50パーセントにすると、ちょうどよい。その理由はうまく説明できないが
・・・。
（ブラッド・シルバーバーグ）

経験からいって、開発者には自分のかいたコードを動くようにする責任がある。・・・最初は混乱して
いるようにみえるが、最後には、各自がどうすればいいのかを分かっている。そこで短い期間を取る
ことにした。この期間を「中間目標0」と呼ぶようにしている。これは製品のあるバージョンが完成
してから、次のバージョンのコーディングが正式に始まるまでの間で、開発者がわかっているまちがい
をあらいだし、一掃する期間だ。
（ジョン・デ・バーン）
例えば、エクセル4.0から5.0の間に、開発者は1から2ヶ月かけて、このような修正を行った。

機能を開発する詳細な過程や取捨選択は、事前には分からないことが多いため、プログラム管理者は、
仕様書の各部を意識して不完全にしておく。プロジェクトが進むと、機能の動き、開発方法の選択、
パフォーマンスとの兼ね合いについて、開発者が更に詳しい情報を提供する。クリス・ピーターズは、
適切な機能を決めるには、直接ソースコードを見る必要があると強調する。

機能を正しく扱うには、コードを見て、コードの中で技術的に取捨選択を考える必要がある。また、
我々が開発している機能はきわめて複雑なので、実際に動かしてみなければ、その機能がどのように
なるのか、正確には分からない。ＩＢＭには頭のきれる人間がいないから、仕様書どおりにコードを
書いていた。おそろしい話だ。仕様がどのようになるのかを理解し、変更し、完璧にする、つまり、
ユーザーのニーズに合ったものにする必要がある。（ピーターズ）

1週間以上かかる作業と見積もった場合、開発者が十分考えていないとみて、ほぼ間違いない。半日
以下の作業と見積もった場合、・・・考えすぎている。プログラミングの時間を増やし、考える時間は
減らすべきだ。たとえば、何かの作業にどれぐらいかかるかと開発者にたずねると、相手は1ヶ月と
答える。1ヶ月というのは、無限の時間と同じだ。そこで、「1ヶ月には22日ある。この22日間に作業
することを、22個あげてみろ」というと、「そうだな、やっぱり2ヶ月くらいかな」と答える。それを
22個の作業に分けているうちに、「ああ、思っていたよりずっと大変だ」とわかる。そこで、通常は、
3日以内の作業にまで細分化するようにしている。

出荷日を確定しようとするのは、出荷日が未確定だと行われない創造や厳しい決定を、行わざるをえな
くなるからだ。「機能は30個にしようか、20個にしようか」と考える。出荷日が決まっていなければ、
いつも答えは30個だ。「大きくて複雑な製品にしようか、中ぐらいの製品にしようか、小さくて機能の
少ない製品にしようか、」「よし、複雑な製品にしよう。出荷日は変えればいい。」・・・そこで、
ふつうは出荷日を確定し、製品の利用価値の8割をもたらす2割の中心機能を考えるようにする。・・・
問題はアイデアの不足ではない。アイデアが多すぎることだ。アイデアの中で特に重要なものを見つけ
るための規律を、どうやって作り出すかだ。
（ピーターズ）

プログラミングの心理学

著   ジェラルド・M. ワインバーグ
翻訳   木村 泉
翻訳   久野 靖
翻訳   角田 博保
翻訳   白浜 律雄
出版社/レーベル   毎日コミュニケーションズ
出版日  2005-02
★★★★★

ソフト開発に携わる全ての方に強く本書を薦める。いろいろなところで言及される古典です。出てくる技術は古いが、本質的な議論は現在でも的を得ている。豊富な実例とユーモアで飽きさせない。今回出版されたのは、「25周年記念版」。今までの原稿はそのままに、各章でワインバーグがコメントを書いている。ただ私には余計なことのように思われる。その記述の是非は読者が判断すればよいのである。それにもかかわらず、十分面白いので、エピソードのひとつと、エピローグを紹介します。

第６章 プログラミングプロジェクト

「閉会の前に、もう一度確認したい。」と彼はいった。「分担したところが今週中に終わらない可能性のある人はいますか。」
返事はなかったが、管理者はたっぷり六十秒間待ちつづけた。ついにチームリーダーの一人がかすかに、まるで気づかれたくないかのように手を動かした。だが管理者は見逃さなかった。「ジョージ、何か問題があるのかい。」
ジョージはもじもじしながらこういった。「ほんのちょっとですが・・・。」
「どのくらいほんのちょっとなの？」
「ちょっと遅れてるんです。」
「どのくらい？」
「ううむ、多分六週間。」
部屋中が大騒ぎになった。「六週間だって？」と全員が一斉に叫んだ。「みんなでシステムテストの準備をしているときに、六週間も遅れていながら、よくもそこでそうやって、会議の間中黙っていられたもんだ！」
管理者は他のチームリーダーたちを静まらせ、システムテスト部隊をホテルに待機させるための出費が実際に発生してしまう以前に、問題があることを認めたジョージの勇気をたたえた。しばらく話し合った後彼は、担当部分を四週間で完成させるようにジョージを説得し、システムテストのスケジュールを改訂した。そして、今度こそ閉会にしようというとき、もう一度何か問題はないか、と問いかけた。
「いやあ、あのう、」と別のチームリーダーが、言いにくそうに切り出した。「ジョージが四週間もらえるんだったら、ウチも欲しいんですがねえ。」
「ということは、君のところもできていないということ？」と管理者はたずねた。
「厳密に言えばですが・・・。」
「厳密に言えばどのくらい？」
「多分六週間だけど、でも四週間で何とかやってみますよ。」
こうして堰が切れてみれば、結局のところ六つのサブシステムは、全部スケジュール遅れを起こしている、ということがわかった。にもかかわらずもしジョージが、全員わかっていることを自認する口火を切らなかったとしたら、問題があろうなどとは露知らない、という形で会合が終わり、実りのないシステムテストが莫大な費用を費やして開始されるところだったのである。


第５部 エピローグ

人の頭脳は、いつもは容量のわずか１０パーセントしか働いていない。残りはオペレーティングシステムのオーバーヘッドだ。

この本に動かされるところのあった人々は、コンピュータのオペレーティングシステムにばかり気を使うのをやめて、彼が自分の中央処理装置、つまり彼自身の頭脳と一緒に持ち歩いているオペレーティングシステムに注意を向け始めるのだ。

ソフトウェア開発プロフェッショナル

著   スティーブ・マコネル
著   松原 友夫
著   山浦 恒央
出版社/レーベル   日経BP社
出版日  2005-01-20

★★★★☆

本書の基となった"AFTER THE GOLD RUSH"のINTRODUCTIONより。
テキサス州で１９３７年にはじめてプロフェッショナル・エンジニアの免許が作られたのは、ボイラーの爆発で３００人以上の学童が死亡した後であった。その当時、ボイラーの故障した部分は、機械であった。今日、その機能をつかさどるのはソフトウエアである。よいソフトウエアは、私たちの生活を大いに良いものにしうるが、悪いソフトウエアでは非常に悪くしうる。よいソフトウエアを作るのに必要なプラックティスは完全に確立され、すぐにでも利用することができる。しかし、平均的なプラックティスと、最良のプラックティスの間には、大きな隔たりがある。次の統計を考えてみよ。

・航空宇宙産業の企業のソフトウエア開発は、プロジェクトの３パーセントが予算を超過し、１００のうち、９７がスケジュールを守る。一般的なビジネスソフトウエア開発では、１００パーセントが予算を超過し、たったの1/4が、当初のスケジュールの２５％以内の遅れでリリースされる。

・米空軍のためにソフトウエアを開発した、あるチームは、1年のスケジュールと2百万ドルの予算をコミットしたが、そのプロジェクトの最も信頼できる入札条件は、2年のスケジュールと1千万ドルの予算であった。積極的なリスク管理と、しっかりした基本開発によって、そのチームは予定より1ヶ月速くプロジェクトを完成させた。そのソフトはユーザーを喜ばせ、1年後、稼動中にわずか２つの欠陥が発見されたのみであった。プロジェクト管理者は、次のように指摘した。すなわち、このプロジェクトは、何年も前から知られている手法を使った。が、実際にはそれらの手法はほとんど使われていないものである、と。対照的に、平均的なソフトウエアプロジェクトでは全く何のリスク管理もなされず、100パーセント以上、スケジュールを超過する。

・ある組織は、開発期間を短縮すると決定し、体系的なプロセス改善に焦点を当てた。6年に渡り、毎年平均23パーセントづつのスケジュール短縮を達成した。合計91パーセントの短縮である。ほとんどの組織では適切なプロセス改善プログラムを持っていない。最悪の組織では生産性は毎年悪くなっているように見える。

・ある組織は、高品質を達成するとコミットし、9年にわたって、リリース後の欠陥率を平均39パーセント削減した。累積では99パーセントの削減である。平均的な組織では、リリース後の欠陥率がどのくらいかも知らない。

ラピッド デベロップメント

Steve McConnell
出版社/レーベル   アスキー
出版日  1998-05
★★★★★

「コードコンプリート」や「ソフトウエアプロジェクト
サバイバルガイド」のMcConnellの2冊目の著作。「サバイバルガイド」と共に管理者、リーダーの必読書。サブタイトルは「無茶なソフトウェアスケジュールを軌道に乗せる」。本書は３編から成る。「効率的開発の基本」「考慮すべき事項」「最良の手法（ベスト・プラックティス）」。実例と共に、いくつかの架空のケーススタディがちりばめられているが、私は「２－２」のケーススタディを読んで素直に感動してしまった。そうだ、ソフトウェア開発はこうでなくては・・・。テクニカルリーダーであるサラのプロジェクトのスタートにあたってのメンバーへの言葉である。



「このチームにあなた達を選出したのは、それぞれが開発の基本をよくわかっているからです。あなた達は,要求の収集と設計においてどうすればよい仕事ができるかわかっているはずです。ですから,下流工程で必要のない修正作業に時間を浪費することはないはずです。このプロジェクトに関連する全ての人に一生懸命ではなく、賢く仕事をしてもらいたいのです。働きすぎる人は非常に多くのミスをします。私達には、ミスをしている時間はありません」

「また、リスク管理の計画も一緒に立てます。スケジュールが非常にきついため、避けることができるリスクはきちんと回避しなければなりません。このリストの最も高いリスクは,スケジュールが達成できないかもしれないことです。週末にスケジュールを再評価して、達成できない可能性があれば,問題が何かをはっきりさせます」

コードコンプリート　第2版　下

著   スティーブ マコネル
原著   Steve McConnell
翻訳   クイープ
出版社/レーベル   日経BPソフトプレス
出版日  2005-03

★★★★☆

下巻では、品質、インスペクション、テスト、デバッグ、リファクタリング、コード・チューニング、統合、ツール、ソフトウェア職人気質について、豊富な実例とデータで解説されます。

百科事典的な内容ですが、より深く理解したい人向けに300以上の参考文献が参考になります。
中級以上のプログラマの方は下巻のみでも十分だと思います。

初版にあった、この言葉に止めを刺すと思っていた次の言葉は変っていました。
「一生懸命は余分な、不要な努力である。それは、何とかしようとしているが仕事が終わっていないことを示している。効率的なプログラミングにおけるもっとも重要な仕事は考えることであり、人間は考えているときは忙しそうに見えない。もし筆者が、いつも忙しそうにしているプログラマと仕事をすることになれば、筆者は彼がよいプログラマではないと思うだろう。なぜならば、彼は彼の最も価値あるツール、脳を使用していないからである。」

新版では、以下のようになっていました。
「ひときわ優れたパフォーマンスを達成するには、一生懸命働くことに加えて、賢く働く必要がある。プロジェクトのデバッグ作業が多いことは、人々が賢く働いていないことを示す危険信号である。大量のコードを1日で書き上げ、そのデバッグに2週間かけるとしたら、賢く働いているとはいえない。」

「ラピッド・デベロップメント」でも「賢く」働くことが強調されていましたが、そうするためのヒントをたくさん、本書から見つけることが出来るでしょう。