こんな本を仕事に役立てています

文藝春秋(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

宮崎伸治/訳
キングベアー出版(2000)

「７つの習慣」のコヴィーの２作目です。「７つの習慣」のうちの「第三の習慣（重要事項を優先する）」を掘り下げたものです。テクニックではなく「原則」に則った考え方は、現代のほとんどのビジネス書が１－２年で消えていくのに対し、１０年、２０年と読み継がれるであろうと確信します。「農場の法則」には特に共感しました。

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

従来の時間管理は、「物事を効率的に行っていれば、いずれ人生をコントロールできるようになる。そして、コントロールできるようになればなるほど、安定感と充実感が得られる」というものでした。

私たちはこの意見に賛同できません。

何もかもコントロールできる能力を身につけて幸せになろうとしても無駄なことです。自分の行動を選択することはコントロールできても、自分の行動から生じる結果は、自分ではコントロールできません。なぜなら、それをコントロールするのは「原則」だからです。

自分の人生をコントロールするのは自分ではなく、「原則」なのです。

本書では、従来とはかなり違った時間管理法を紹介します。それは原則中心のアプローチであり、従来の「より速く」「より懸命に」「より機敏に」「より多く」という方法を超えるものです。この方法は、あなたに新しい時計ではなく、羅針盤を与えます。なぜなら、いかに速くやるかよりも、何をどうするかの方向性の方が大切だからです。

自分がどのようにして重要事項を優先しようとしているかは、自分が二つの強力なツール（時計と羅針盤）をどのように使っているかを考えてみればわかる。
「時計」とは、時間をどのように使い、管理するかを表す「約束・予約・スケジュール・目標・活動」のことである。「羅針盤」とは、自分の人生をどう生きていくかといったことを表す「ビジョン・価値観・原則・ミッション・良心・方向性」のことである。
時計と羅針盤の間にギャップがあること（自分がやっていることが、自分の重要事項に役立っていないこと）を強く感じた時に葛藤は生じる。

皆いつも忙しくしていたいのである。忙しいほど価値のある人間であるという考え方が当たり前となり、忙しいことは今や一種のステイタスとなっている。忙しくないことに恥ずかしさを感じ、誰もが忙しさを求め、忙しくすることで安心感を得ているのである。忙しさは心の防衛手段でもあるのだ。またそれは、重要事項を実行できない格好の言い訳にもなっている。

「緊急度」そのものが問題なのではない。問題なのは、「重要度」に代わって「緊急度」が生活を支配する要因になることであり、緊急なことをすることが「重要事項」になってしまうことである。

「私は、難しくなってしまった問題には手を触れません。難しくなる前の簡単なことに取り組むのです。」（オリバー・ウェンデル・ホームズ）

人間としての「四つのニーズ」の満たし方
ニーズの本質は、「生きること、愛すること、学ぶこと、貢献すること」という言葉で表すことができる。生きるニーズとは、肉体的ニーズ（衣食住・お金・健康など）である。愛するニーズとは、他人と接し、帰属し、愛し愛されるための社会・情緒的ニーズである。学ぶニーズとは、成長したいという知的ニーズである。貢献するニーズとは、意義を持ち、目的を持ち、社会や人のために役に立ちたいという精神的ニーズである。

マネジメントは問題志向（問題のあるものや人自体を重視する考え方）だが、リーダーシップは機会志向（問題が何と関連しているのか、その結びつきの機会を重視する考え方）である。

現代心理学の父の一人、アブラハム・マズローは「欲求の階層」を考え出し、人間の最も高度な欲求を「自己実現」とした。しかし彼は後年、理論を改め、最も高度な欲求は「自己実現」ではなく、「自己超越」（自己よりも高次の目的のために生きること）であるとした。

「原則」の力は、時代を超えた普遍的な真実である。もし、原則を理解し、原則に基づいた人生を歩めば、どこにでも応用できるだろう。方法ではなく、「原則」を子供に教えれば（あるいは方法を支えている原則を教えれば）、その子は将来どんな問題が生じても対処できるようになる。方法だけを理解することは、その場の要求（難題）に対応することだが、原則を理解することは、その場の要求（難題）により効果的に対応するだけでなく、将来起こりうる何千もの難題をも対処可能にさせてくれるのである。

何がこの世を支配しているかを理解するには、「農場の法則」を考えてみればよい。農場においては、「自然の法則」が農作業と収穫を支配していることが容易に理解できる。だが、企業においては、プロセスを飛ばしたり、システムをごまかしたりしても成功することがある。そして、目的さえ達成すればそうしたやり方でもいいのだ、と思わせることが多々ある。
例えば、学生時代に「一夜漬け」の勉強をしたことはないだろうか。ふだんは勉強せず、試験の前日に徹夜で知識を詰め込もうとしたことはないだろうか。

農場で「一夜漬け」ができるだろうか。春に田植えをせず、夏の間は放っておいて、秋にすべてのこと（土を掘り起こし、種を蒔き、水をやり、除草することなど）を一夜ですませることができるだろうか。
農場のような「大自然のシステム」には「一夜漬け」は通用しない。そこに「社会システム」と「大自然のシステム」の大きな違いがある。「社会システム」は価値観に基づいているが、「大自然のシステム」は原則に基づいている。短期的には、「社会のシステム」では「一夜漬け」が通用しそうに思える。応急処置やテクニックで成功を収めることができそうに思える。
しかし、長い目で見れば、「農場の法則」が人生のすべてを支配するのである。どれだけ多くの人が、学生時代に「一夜漬け」をしなければよかったと後悔しているだろうか。学位だけは取っても、それだけの教養が身についていない人は、いずれ「学校のシステム」における成功と、本当の自己啓発（分析力・創造力・想像力・伝達能力・表現能力・問題解決能力を身につけること）とは違う、ということに気づくだろう。

刺激と反応のスペースに存在する自覚・良心・自由意志・想像力という四つの独特な能力が、人間としての自主性（選択肢、反応し、変化する力）を作りだす。これらの能力が羅針盤を形成するのである。

学び、聴き、反応することで「良心」を養う

「良心に従わないでいると、良心とは何かが分からなくなる」（C・S・ルイス）

約束を守ることで「自由意志」を育てる

イメージ化によって「想像力」を開発する

「超越的ビジョンの力」は、心に染みついている脚本（道筋・動機づけ・先入観など）よりもはるかに強力であり、そのビジョンを達成する過程で、そうした考えを服従させ、覆い隠してしまう。
個人から生まれたビジョンは、やがて個人を超越し「共有のビジョン」となる。そのエネルギーは、人々に、「非常に多くの時間とエネルギーを消費し、生活の質を損なう否定的な作用」を払拭する力を与えてくれる。

強力なミッション・ステートメントの特徴

(1)心の最深かつ最良のものを表している。内面生活としっかり結びついている。
(2)独自の才能を発揮できるようになっている。
(3)自らの利害関係を超えたものになっている。
(4)人間の4つの基本的な（肉体的、社会・情緒的、知的、精神的）ニーズと独特な能力（自覚・良心・自由意志・想像力）のすべてに関わっている。
(5)質の高い生活を生み出す原則に基づいている。目的も手段も「真北の原則」に基づいている。
(6)「ビジョン」と「原則に基づいた価値観」の双方と関わっている。・・・強力なミッション・ステートメントには性格の要素（どんな人になりたいか）と能力の要素（どんなことを成しとげたいか）が必要である。
(7)人生の重要な役割のすべてに関わっている。「個人」「家族」「仕事」「地域社会」のそれぞれの役割のバランスが取れるようになっている。
(8)他人に印象づけるためではなく、自分を奮い立たせるために書かれている。心の底から鼓舞される内容になっている。

強力なミッション・ステートメントを作り、それに従って生きれば、時間の使い方が劇的に変わる。時間管理について考えるとき、方向性よりもスピードについて心配するのはバカげている。数分の努力を惜しんで、何年という長い年月を無駄にするようなものである。
ビジョンは、人生のすべてを動かす基本的な力である。それは、自分にしかできないことを教えてくれるものである。それは、重要事項を優先する能力（時計よりも羅針盤を優先し、スケジュールや「もの」よりも「人」を優先する能力）を与えてくれる。

そして、より大きな価値観を持って、生き、愛し、学んでいくうちに、自分が残せる最も重要な遺産とは「ビジョン」であることが分かる。子供たちが自分自身のことをどう思い、どのような夢を描くかは、私たちみんなの生活の質に多大な影響を及ぼすのである。

「自分の時間と才能を他人と惜しみなく分かち合う」

責任から逃れることはできない。私たちが行うことはいずれにせよ周囲に影響が及ぶのである。自分の人生は自分に責任がある。自分の持っているもの（お金・所有物・才能・時間）で何をしようとも、後世に生きる人々に遺産を残すことになる。私たちは、自分の脚本（先入観）がどんなものであれ、自分独自の能力を使い、自分が望んでいる責任行動を選ぶことができる。次の世代に、借金、資源の枯渇、幻想、自己中心的な考え方、虐待といったものを残すべきではない。健全な環境、人々に愛されてきた物、責任感を大切にする考え方、原則中心の価値観・貢献のためのビジョンなどを遺産として残すことができる。そうすることによって、現在だけでなく将来の生活の質も高めることができる。

「性格を鍛えること」は「体を鍛えること」に似ている。試練が訪れたとき、もし力がなければ、どんなに取り繕っても力がないことをごまかすことはできない。大胆な目標を設定するにはそれに応じた力が必要である。慢性的な問題に、応急処置をするのではなく真っ向から取り組むには、それなりの力が必要である。みんなが反対しているのに自分の信念を貫くにも、それなりの力が必要である。

私たちは、目標を設定するために「想像力」を使い、それを実行するために「自由意志」を使うのである。
「想像力」と「自由意志」には驚異的な力がある。「自由意志」の力によって決断力が持て、「想像力」の力によって意識が変わるのである。しかし、それは私たちが持つ力のほんの一部にすぎない。
私たちは、目標を設定するとき、他の二つの能力を無視してしまいがちである。

・「良心」とは---目標と、ミッション・原則・ニーズとを深く結びつけているものである。
・「自覚」とは---自分の能力と「信頼口座」とのバランスを的確にとらえているものである。

自分に負けそうになったとき、持続力を与えてくれるのは「目的意識（なぜ）」なのである。心の奥のより深い「イエス」が燃えていれば、諦めの気持ちに対して「ノー」と言えるのだ。

「コントロール」というパラダイムで見るか「リリース」というパラダイムで見るかは、他人を見る見方を反映していることが多い。もし「コントロール」の見方をすれば、何かを成しとげるには自分たちを厳しく管理しなければならないと思うだろう。もし「リリース」の見方をすれば、リーダーシップとしての主な仕事は、内的な能力を開放するのに最適な状況を作り出すことだと思うだろう。目標設定の際、「頑張り通す」「厳しく鍛える」「どんなことをしても実行する」という考え方の「自由意志」に焦点が合わせられていれば、その考え方は、基本的なパラダイムが「コントロール」であることを物語っている。

多くの企業は、あまりに経済的次元や肉体的次元に焦点を合わせすぎているため、めったに深い動機を引き出すことはない。企業が、社会的ニーズ・知的ニーズ・精神的ニーズを認識したり、取り組んだりすることはない。したがって、従業員が心の中で感じていること（愛するためのニーズ、学ぶためのニーズ、崇高な目的のために生きるニーズ）と企業側の考えとが結びつくことはない。しかし、従業員の求めているものこそがエネルギー・創造性・忠誠心の源となっていくのである。

正しいことを正しい理由のもとに、正しい方法で行うことが、質の高い生活を送るための秘訣である。それは、ビジョンとミッションと「真北の原則」とを一致させることのできる、鍛えられた「良心」を通してのみ実行可能なことである。

誠実さとは、どんなことがあっても目標にしがみつくことではない。それは、選択の瞬間にミッションに基づいた行動をとることである。

「原則に基づいた目標」を設定するには、人間の持つ四つの独特な能力すべてを相乗効果的に使うことが必要となる。

・良心を通して、自分と「ビジョンが発するエネルギー」「ミッション」「原則」とを結びつける。
・創造力を用いて、目標を達成すための相乗効果的・創造的な方法をイメージする。
・自覚によって、現実的な目標を設定する。
・自由意志を用いて、意義のある選択をし、それを実行に移す。約束したことは誠実さをもって必ず実行する。

効果的な「週単位の目標」の五つの特徴

(1)良心に従っている
(2)第二領域に含まれる事柄が多い
(3)人間として基本的なニーズと能力を反映している
(4)「集中の輪」の中にある---「集中の輪」とは、関心があり、影響を及ぼすことができ、自分のミッションに合致している事柄のことである。
(5)「決意」と「専念」のどちらなのかがはっきりしている

第二領域時間管理とは、スケジュールに優先順位をつけることではなく、優先課題をスケジュールに入れることである。時間帯のすべてをスケジュールで満たすことではなく、「大きな石（優先事項）」を先に入れ、それから必要に応じて「砂利」や「砂」や「水」を入れることである。
容器をいっぱいに満たすことが目的ではない。目的は、まず最初に「大きな石」を入れ、あとで良心に従って変更することもできるように少し隙間を空けておくことである。

どの週も、どの日も、どの瞬間も、未知の領域であり、すでに過ぎ去った時間ではない。私たちは、落下傘で未知の領域に降下していくのである。自分が作った道路地図は役には立つものの、効果的に車を運転できるかどうかはほとんど自分自身の羅針盤にかかっており、いかなるときにも「真北」に合わせることを可能にする四つの能力が試される。だから、第二領域時間管理の目的は、「選択の瞬間に誠実になれる力を身につけること」なのである。そうすれば、どんなに寄り道をしようが、新たにどんな道が造られようが、自分の羅針盤を頼りに自分の進むべき道が見えてくる。

「私たち強制収容所に入れられていた者は、最後のパンを人に譲って、他人を慰めながら歩き回っていた男たちのことを覚えています。そのような人たちはごく少数でしたが、それでも、そのような人がいるということは、『人間には奪うことのできないものが一つある』という十分な証拠になります。その『奪うことのできない唯一のもの』とは、人間の持つ自主性（ある状況に置かれたとき、自分独自の態度を選択する自由）です。
選択の自由は常にあるのです。毎日、毎時間、選択の機会が存在しています。あなたの自主性（心の自由）を奪うような高圧的な力が立ちはだかったとしても、それに屈するか屈しないかはすべてあなたの選択になるのです。もし屈してしまえば、あなたはもう周囲の状況に左右される人間になってしまうのです。」（ビクター・フランクル）

第二領域時間管理の重要な目的は、物事に対して反応的（被害者意識を持ち、感情的）にならず、誠実に行動する力を高めることである。そのために私たちは、個人のミッション・ステートメントを作ったり、週間計画を立てることによって実践していくのだ。計画を立てるとき、私たちは、原則・ニーズ・能力に基づき主体性をもって決定するためにも、反応的になってはならない。
私たちは、毎日の出来事、瞬間瞬間の出来事に対して、刺激と反応の間のスペースで立ち止まることにより、誠実に実行する能力を高めることができる。自分に対して素直な気持ちで、(1)意図をもって尋ね、(2)言い訳をせずに聴き、(3)勇気をもって行動する、という人間の独特の能力を使えば、誠実さが生まれてくるのだ。

第二領域時間管理の威力

１．やろうとしていることがミッションに結びついているかどうかを考える---それによって、人生の重要事項を知ることができ、心の中に燃えている「イエス」を引き出すことができる。その「イエス」は情熱とエネルギーを生み出し、「重要度」の低いことに対して「ノー」という力を与えてくれる。
２．役割を見直す---それによって、各役割同士のつながりが見え、相乗効果的な方法を再確認できる。
３．目標を確認する---それによって、ミッション達成に向かって、毎週自分の役割の中で最も重要なことは何なのかを見すえ、生活の質を高める原則に基づいた目標を設定することができる。
４．週の予定を組み立てる---それによって、「大きな石（第二領域の目標）」を最優先して入れ、その周りにそれ以外のものを入れることができるようになる。
５．誠実さを行使する---それによって、刺激と反応の間のスペースで冷静に考えることができるようになる。また、選択の瞬間において、誠実さを持って重要事項を実行できるようになる。
６．評価する---それによって、一週間を「人生から学ぶ」上向き螺旋の成長状態に変えることができる。

以上のことを実践していけば、従来の「より多くのものを、より少ない時間で行う」やり方ではなく、「重要事項を、バランスよく相乗効果を発揮しながら行う」方法へと、パラダイムを変更できるようになる。それが、「生きること、愛すること、学ぶこと、貢献すること」に対する総合的なアプローチとなるのである。

ほとんどの人は、眼を覚ましている時間の大部分を他人と接すること（あるいは悪化した人間関係を修復すること）に費やしている。効果的な相互依存とは、結局、時間管理の問題なのである。しかし、従来の時間管理方法は、相互依存の問題を扱っていないか、扱っていたとしてもそれを取り引きと見なしてしまっている。
この取引的な相互依存は、人間を機械的・支配的に「もの」のように扱うパラダイムから生まれたアプローチである。つまり、「人」とは「より多くのことをこなすために自分の仕事を押し付けてしまえるもの」であったり、「できるだけ早く本来のスケジュールに戻れるよう簡単に処理されるべき邪魔なもの」と見なされているのだ。
しかし、第二領域時間管理における相互依存は取引的ではなく、変容的である。それは、周りの人々を劇的に変えてしまうものだ。それは、個々人の独自性・能力・想像力を活かし、相乗効果的な第三案の可能性を考慮に入れている。
第二領域時間管理における相互依存とは、スケジュールよりも人を優先することで人間関係を豊かにし、周りの人と一緒に新しいものを創造することである。それは、究極的な「エンパワーメント」といえるもので、多くの人のエネルギーと能力を相乗効果的に組み合わせることによって、創造性・能力・生産性を急激に伸ばせるものである。

従来の時間管理法は、監督・管理することに焦点をあわせており、それは「人」を「もの」に格下げする考え方である。従来の時間管理法で考える人は、組み立て、計画し、優先順位を決め、自分を鍛え、コントロールするために、最後には自分自身さえも効率化するようになる。
しかし、第二領域時間管理のパラダイムは、「人」が第一であり、「もの」は第二という考え方である。すなわち、リーダーシップが第一であり、マネジメントは第二となる。以下、効果性が第一、効率性は第二、ビジョンが第一、組織は第二、目的が第一、方法は第二である。

ほとんどの人は「勝つ(WIN)ということは相手が負けることである」という先入観を持っている。しかし「勝つ(WIN)」ことは、必ずしも相手が負けることだけを意味しているわけではない。相手に勝つ(WIN)のではなく、自分の目的を達成(WIN)するということも意味しているのである。そこに考えが至れば、競争するよりも協力し合った方がより多くの目的を達成(WIN)できるということも理解できるだろう。

誰もが皆、何とか安心感を得ようと、狂わんばかりに忙しく立ち回って、組織における自分の立場を保とうとしていました。その根底にあるパラダイムは、「もし業績が悪化しても私は解雇されるはずがない。なぜなら私は最も多忙であり、最も勤勉であり、みんなそれを知っているからである」というものでした。

皆に十分権限が与えられている信頼度の高い環境の中にいられれば、それはすばらしいことである。しかし現実はなかなかそうはならない。多くの組織には、規則や約款や形式主義が氾濫している。方向性は統一されておらず、システムとシステムがぶつかり合っている。権限の範囲は狭く、仕事以外のことから満足感を得ており、仕事をしている時間の多くを第三領域（政治工作・陰口・叱責・責任追及・罪の告白など）に費やしている。職場にたむろしてお互いの傷をなめ合っているだけなのだ。

私たちは、実際には他人を「エンパワー」することはできない。できるのは、エンパワーメントの条件を満たすことによって、人が四つの独特な能力を使えるような環境を作り出していくことだ。

エンパワーメントの本質は信頼性（人格と能力）である。人格とは、私たちの「人となり」のことであり、能力とは、私たちが「できること」である。信頼性を高めるには人格も能力もともに必要となる。

信頼はすべてのものをくっつける「接着剤」である。
繰り返すが、信頼は信頼性から生まれてくるものである。だから、信頼を生み出すためにできる最大にことは、約束を守り自分自身の信頼性を高めることである。

多くの組織は「三百六十度のフィードバック」を得ているわけではない。彼らは数字（損得勘定）にのみ焦点を合わせているのである。数字は、短期における厳然たるデータであるが、そのようなデータは、情報システムとしては不完全である。なぜなら「人」を扱っていないからだ。また、扱おうともしていない。それは「人の活動や費用」を記録しているかもしれないが、「人の心・力・能力」については何も言及していない。数字の損得だけで判断してしまう「実利的な考え方」を作り上げてしまい、数字では計れない重要な要素（例えば、人材開発、品質改善、システム、長期投資、チーム精神、信頼度の高い環境など）を無視する形で組織を動かしてしまうのだ。

信頼度の高い環境では、まじめに働いた結果犯したミスは、「学習するための機会」として捉えられる。もしあなたが何かに失敗したときは、その原因を考えてほしい。そして話し合うことである。その経験から何が学べるか考え、一歩前進することである。そこで働く人々が失敗に対するリスクを恐れているとすれば、組織にとってそれはWINとはならない。人は、失敗が許されないとき、厳密な意味で自分をコントロールすることはできないからだ。

あなたの職場環境には、ほかには真似できない強みがあるはずだ。技術は真似できる。情報は得られる。資本は買うことができる。しかし、「組織集団として働く能力」「第二領域で働く能力」「重要事項を優先する能力」は、買ったり、移したり、植えつけたりすることはできない。信頼感にあふれ、エンパワーされた環境は常に自家製なのである。

原則中心の生き方は、それ自体が目的なのではない。それは、手段であると同時に目的なのである。それは、人生の旅路を決めるものであり、私たちが一日一日「重要事項」を成しとげようとしているいる間に経験する「力と安らぎ」となるものである。
原則中心の生き方を実践すれば、羅針盤の進路と目的地は一致する。

このように行動することで、システムを変えていくのである。単に仕事をこなすだけでなく、自分を含めた全員のために将来の時間を節約するのだ。信頼関係を結び、顧客のニーズに最も効果的な方法で応えるのである。

皆を巻き込み、一緒になって問題を解決することである。今後とも、問題を効果的に解決できる力をつけるためには、問題を解決する過程において人間関係を築いていくことである。

「私たちは、何が起こるか分からないこともあって、将来の計画を数多くたてることは不可能だろう。しかし、正しい行動が要求される重大な局面において、どんな時でもそうした行動がとれるよう、心身ともに高潔に保つことはできるし、高い理想を持ち続けることは可能である。身に付いた習慣や常に抱いている考え方に反する行動を、その時になっていきなり実行できる人などいないのだ。」（ジョシュア・L・チェンバレン）

意識しているいないにかかわらず、多くの人は一日が計画通りに進むことを期待している。だから、予期しなかった問題が生じたときや、誰かが予期しなかったことを求めてきたとき、フラストレーションを感じるのである。つまり気品的に「人」を「邪魔者」として見ており、「変化」を「敵」として見ているのだ。ここでいう安らぎと幸福に基準は、「一日をうまく過ごせるかどうか」「日課としてリストしたものがすべてチェックできるかどうか」という点にかかっている。
しかし、期待を変えてみたらどうなるだろうか。一日一日を、刺激的な新しい冒険だと考えたらどうなるだろうか。冒険とはいえ道路地図だけでなく、地図のないところも移動できるよう羅針盤も準備されている。他人を助けるための機会として問題を考えてみたり、自分の最優先課題に挑戦できる機会を楽しんだりするとき、羅針盤が「最良」の道を教えてくれるはずだ。一日を通して重要事項を優先したかどうかに安らぎと幸福がかかっているとしたらどうだろうか。そうした冒険に期待することは、その日の現実の生活にどのような影響力の違いをもたらすであろうか。

「プライドは精神的ながん細胞である。それは、愛情を歪め、満足感や常識すらも食いつくしてしまうものである。」（C・S・ルイス）

プライドの毒を溶かしてくれるのは「謙虚さ」である。私たちは孤島に住んでいるのではないということを悟る謙虚さ、自分の生活は他人の生活と切っても切り離せないようにつながっているということを悟る謙虚さを持つことだ。自分自身が今まで囚われていた競争心や、さまざまな慣習に縛られないことだ。原則の価値を認めれば認めるほど、より大きな心の安らぎが得られることが分かるだろう。

スティーブン・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週間かけるとしたら、賢く働いているとはいえない。」

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

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

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

1993年に出版されたMcConnellの最初の著作の第2版。
上巻はプログラミングの初級から中級者を対象に、主にコーディング規約について述べています。
旧版ではコーディング･サンプルは、Basic、C、Pascalでしたが、新版では、C++、VB、Javaになっています。

読みやすさに工夫が凝らしてあって、「キーポイント」「ハード･データ」「コーディング・ホラー」のマークがあります。

ベテランの方は、章末の「まとめ」、「キーポイント」「ハード・データ」を拾い読みすることでも十分価値はあると思います。
「コーディング・ホラー」は悪いコーディングの見本です。

正直言ってコーディングのサンプルは、単純な例で、量も少なく、あまり参考にはならないと思います。

その中で、特に、論文でしか読めない「ハード･データ」が貴重であると思います。
例えば、

エラーを修正するコストは、大規模なプロジェクトでは一般に、アーキテクチャーの作成時に検出された要求のエラーを修正するコストが、要求の策定時に検出されたエラーの3倍に及ぶことが示されている。コーディング時に検出された場合のコストは5～10倍、システムテストの段階では10倍、そしてリリース後は10～100倍に跳ね上がる。(Boehm and Turner 2004)

という具体的な数字が示されます。

しかし、中級者以上にとっては、下巻に本書の価値があります。下巻は是非目を通していただきたいです。

トム･ピーターズのマニフェスト(3) タレント魂

著   トム・ピーターズ
翻訳   宮本 喜一
出版社/レーベル   ランダムハウス講談社
出版日  2005-12-18
★★★★★

あなたは自らの人生のストーリーテラー。
自分ならではの伝説を作り出せるかどうかは、あなた次第。

-----小説家 イサベル・アジェンデ

差をつけろ、できなければ絶滅だ
(DISTINCT OR EXTINCT.)

”そんなもんだ”にノーと言え。
”十分な出来だ”に思い切り蹴りを入れよう。凡庸な成功には罰を与えよう。

怠慢を捨て自慢を手に入れろ。
どんなプロジェクトの場合にも、それを自慢するための権利を手に入れる方法だと考えて仕事をしよう。”気楽に行こう”は忘れよう。”自分の仕事を自慢しろ！”

ヨハン・ヴォルフガング・フォン・ゲーテは言う。「ある人が覚悟を決める前には、躊躇がある。つまり腰を引いてしまうことがある。最初にとりかかる（そして創造のための）行動のすべてに関して、本質的な事実がひとつある。これを無視すれば、無数のアイデアやすばらしい企画の息の根がとまってしまう。それは、人が必死になるとき、自然の摂理も動くという事実だ。あらゆるものは、それが支えなければ生まれないはずのものを支えるために生まれる。自分に何ができても、あるいはどんな夢を見られるにしても、とにかくそれを始めよう。大胆さには、本来、天賦の才、力、そして魔力が備わっている。今こそ、それを発揮させよう」

チャーチルの言。「成功とは、情熱を全く失わずに失敗を重ねられる能力のことだ」

私の大好きな飛んでるアイデアは、「失敗するだろうということに手を出せ、周りの人全員を間違いなく成功すると説得しろ」。

私はどんな危険を冒しても、飛んでる思考法はたったひとつの成功間違いなしの戦略だと訴えたい。「絶え間ない個人の再生」と「急激な組織的なイノベーション」のための戦略だ。

飛んでる働き方をしろ。
成功の源泉は「タレント」にある、そして「タレント」の源泉は「すごい」と「飛んでる」というふたつの軸に沿って仕事をすることにある、ということを、日々思い起こそう。

トム･ピーターズのマニフェスト(2) リーダーシップ魂

著   トム・ピーターズ
翻訳   宮本 喜一
出版社/レーベル   ランダムハウス講談社
出版日  2005-09-10
★★★★★

１　リーダーシップの真髄５０

リーダーは「わからない」という。
忘れるな。これは「穏やか」ではない、典型的な「厳しい」経営の考え方だ。「私にはわからない」の本当の意味は、「われわれは未知への冒険をしている。君の仕事は『命令にしたがう』ことではない。何かを考え出せ。形にしろ。絶対に手ぶらで帰ってくるな」。

リーダーはビジョンの持ち主だ。
「リーダーは希望の商人」元高級官僚のJ・ガードナーはナポレオンの金言に忠実だ。曰く「リーダーの第一の義務は、希望の火を燃やし続けることだ」。

雇用の効用
「あなたがどれほど偉大であるかは、自分より優秀な人間をどれほど意欲的に雇うかでわかる」

リーダーは矛盾を糧に成長する。
ハーバード・ビジネススクールで学んだことは忘れよう。イリノイ大学のビジネスカレッジ、スタンフォード・ビジネススクール、そしてウォートン・ビジネススクールで学んだことも。経営は科学ではない！経営は、それに取り組むときはいつも、芸術だ。
経営はある種の・・・・・・芸術。矛盾の芸術だ。

リーダーは混乱状態が大好きだ。
本物の偉大なリーダーシップの定義とは？それは「恐れていた事態が起こった」とき最高に燃えるリーダーのことだ。

常に「撃て！」
1965～80年：戦略的計画の時代。その時代のモットー：「構え、狙え、撃て」
1980～95年：世界的競争激化の時代。新しいモットー：「構え、撃て！狙え」
1995～？？：非連続的変化の時代。この時代のモットー：「撃て！撃て！撃て！」

クールな友人、スティーブ・ファーバー
「あなたのしていることが大好きな人たちに奉仕するにあたって、あなたの大好きなことをすること。」

２　ボスの仕事　ヒーロー、デモ、ストーリー

命令からの脱却：「ボス」にならない方法
あれこれ指示する管理、こと細かな計画による経営、といった昔からの習慣と縁を切るのは信じられないほど難しいことがある。マネージャーの間にしつこく残っている、高圧的な命令の出し方の習慣を考えてみよう。次のような命令の仕方だ。
「もっと起業家精神を発揮しろ」
「リスクを負え」
「欠陥ゼロ運動を浸透させろ」
「部下に権限を委譲しろ」
あほ。
あほ。
あほ。

「最高のストーリーが勝つ」
「法律家の駆け出し時代、私は、最高のストーリーを語る者が勝つことを学んだ。君のストーリーを教えてくれ」


究極の”すごい”プロジェクト？（連邦政府の場合）
「失敗したことを見つけて、それを修復しようとする人もいる。私は逆に成功したことを見つけて、それを足がかりにする」

４　ボスの第一の仕事　２５の才能

８．評価作業を真剣に考える。
私はソフトウェア企業の”できる”経営者と仕事をしたことがある。聞けば、100日間部下の評価作業に没頭するという（100日だ！）。ひとりに2日、年に2回、直属の部下25人が対象だ。2日のうち1日はデータの収集にあて、2日目はまる1日かけて、社外で部下と1対1の評価作業をする。
　私は100日という数字に驚いた。この経営者は反対に、私が驚いたことに驚いていた。「人を育てる以上に重要なことがあるでしょうか。仕事をするのは私ではなく、他でもない社員ですよ」

１１．トレーニング！トレーニング！トレーニング！
ASTD(全米人材開発協会）での講演の準備をしているとき、私は平均的アメリカ人労働者が学習の場にいる時間の年平均の数字を記録したデータを見つけた。その時間、26.3時間。


２６．３

長い長い長い人生で、これほど不愉快きわまる数字に出くわしたことはない。。


”あのことば”について考えてみよう。つまり「才能」についてだ。
次のような人の場合、年に26.3時間のトレーニング時間を想像できるか？
プリマドンナ、バイオリニスト、スプリンター、ゴルファー、パイロット、兵士、外科医、宇宙飛行士。


もちろん、想像できないはずだ。
それはなぜだ？
プリマドンナが、バイオリニスト、スプリンター、ゴルファー、パイロット、兵士、外科医、宇宙飛行士が、長い時間をかけてトレーニングするのに、なぜ”ビジネスパーソン”だけが必要ないと思うのか？

金を使う。
才能の主が働いているところには、金を注ぎ込め。給与体系を見直して、間違ったところで節約していないか確かめる。マントラ「適切な報酬が支払われる仕事は、適切に達成される」

トム・ピーターズのマニフェスト(1) デザイン魂

著   トム・ピーターズ
翻訳   宮本 喜一
出版社/レーベル   ランダムハウス講談社
出版日  2005-09-10

トム･ピーターズによれば、大規模な雇用縮小の不安を克服する方法は、自分と会社の両方をバリューチェーンの高みに引き上げ、ニューエコノミーの核心部に飛び込む方法を見つけること。

その核心を突く新シリーズ、マニフェストの4冊。

• リーダーシップ
  
• デザイン
  
• 才能
  
• トレンド
  

現在、日本では、リーダーシップ魂とデザイン魂というタイトルで刊行されています。
ページのデザイン、フォント、写真、色彩、全てに凝ったハードカバー、フルカラーの160Pの小冊子です。
その「デザイン魂」から。

1. デザイン　新時代の企業の「魂」
   
   
   
   • 「美しさや優雅さへの熱い思いが、コンピュータ時代の歴史における最も重要な発見を裏づけてみせた・・・論理的立証や機械の美しさは、簡潔さと才能の幸せな結婚に宿る・・・美しさは複雑さに対抗する最高の防衛手段・・・できるプログラマーは、凡百のプログラマーよりも百倍生産性が高い・・・この差は、技術、数学、あるいは設計の教育トレーニングとはほとんど関係がない。大いに関係があるのは、眼識、優れた見識、持って生まれた美意識だ」デビッド・ゲランター。
     
   
   
2. デザインの効用　美しいシステム
   
   
   
   • 「何年も前に、ウォルマートは社員コンテストを始めた。あらゆる種類の賞品や景品を山のように積み上げた。その目的は、社員の全員が参加して『自分たちが社内で行っている最もバカげた行為』を見つけ出すことだった。
     率直に言えば、この方が”社内提案"システムよりもはるかによいと思う。社内提案システムは、結局（役に立たない）ものの足し算だ。反対に、この制度は引き算にあくまでこだわっている。」
     
   
   
3. 行動するデザイン　忘れられない経験を与えてくれる
   
4. 経験の一歩先　「夢ビジネス」をものにする。
   
   
   
   • かくありたい！
     
     私が想像するのは・・・
     
     かなえられるようになる（それ以上になる）”見果てぬ”夢。
     
     ”欠陥ゼロ”の麻薬を排除するだけの「勇気」を持った企業。
     
     ”製品”や”サービス”（さえないことばだ、そのうち使う必要もなくなるだろう）の、はるかに、はるかに上を行く、価値の創出。
     
     
   • 次のブイトーニの言葉を注意深く噛みしめよう。
     
     「夢とは、顧客の人生における完成された瞬間のことだ。顧客に自分の相当な財産を注ぎ込んでもよいという気持ちにさせる、そんな大切な経験のことだ。消費者の欲求の核心。顧客をその本人のなりたいものにしてくれる、そんな機会のことだ」
     
     
   • 夢のきわみ
     
     本書の卓越したメッセージ。機能にこだわる姿勢は、機能障害を招く。たいていのものは、”機能する”ものだ。全く問題ない。だから問題はこうなる。この”うまく機能する”を超越するものは何か？
     
     興奮。これだ。
     
     驚嘆。これだ。
     
     不可能だと考えられているもの。これだ。
     
     私の主張（繰り返す）。自ら目標のバーを高く上げろ。「もっと上、もっともっと上だ」
     
     デザインを考えよう。あの”美しいシステム”を考えよう。
     
     ”製品”そして”サービス”を切り捨てよう。
     
     その代わりにこだわるのは、”経験”だ。”夢”だ。
     
     
   • 夢を測る尺度：”欠陥ゼロ”の（はるか）先へ
     
     
     
     • 「一目惚れ」
       
     • 「五感に訴えかけるデザイン」
       
     • 「『大きな夢』を広げてくれる進歩」
       
     • 「何となく気配でその気にさせるデザイン」
       
     
     
     
   • 情熱は情熱を呼ぶ。
     総天然色テクニカラー的ことばは、テクニカラー的反応を呼ぶ。
     
   
   
   
5. デザインの頂点　心からわき出るブランディング
   
   
   
   • われわれは”ブランド”を、企業や製品あるいはサービスの”外面のイメージ”としてとらえることにこだわっている。
     ●違う。われわれは、ブランディングとは企業の心に真っ直ぐ突き刺さる（そしてその心から真っ直ぐ飛び出してくるもの）ものだということを、学ばねばならない。
     ●結論。効果的なブランディングとは、外面的というよりも、ずっとずっと内面的なものだ。
     
     
   • この紅茶共和国のふたり組みは続ける。「わが国の自由で解放的な移民政策によって、コーヒー狂いの生活の暴虐から逃れ、そのコーヒー生活が原因の、疲労困憊型ハイペース居場所確保レース的存在から足を洗いたいという人を、すべて喜んで受け入れる。この小国でわれわれは、コーヒーとは、本来速さと視界不良の象徴であり、一方、紅茶は遅い速度と視界良好の象徴だということを学んできた。紅茶は単なる飲み物ではないからこそ、飲む人の意識を変え、人生の機微に触れたり楽しんだりする余裕を与えてくれるわけだ」
     
     そんなことはナンセンスの塊だと思う人もいるかもしれない。私の考えは逆だ。これは金の塊ではないか。
     
     私の要点。”紅茶共和国の主張”こそが、ブランディングの核心をついている。つまり”ブランドのお約束の本質”だ。人々がこだわること。大事なこと。共感すること。
     
     
   • 「ブランディングはマーケティングと同じだと解釈している企業もある。目にも鮮やかな新しいロゴをデザインし、派手なマーケティングキャンペーンを展開すれば、ほら一丁上がり、また元の成長軌道に戻れるぞ。それは間違いだ。ブランディングはもっと、もっと大仕事だ。その本質は企業がその潜在能力を最大限に発揮することだ。新しいロゴではない。」
     
     
   • 「自分自身の人生における使命は何か？　周りの人たちに何を伝えたいのか？　自分が世の中に与えるものが、実際に自分ならではのものかどうかを確認する手段は？　ブランドはそのもてる力を最大限発揮しなければならない。企業は企業の力を、そして経営者は経営者自身の持てる力を。はっきり言えば、それは、あなた自身が世界で唯一の存在になりたいか（なりたくないか）どうかの問題だ」
     イェスパー・クンデ
     
     
   • 「ファンキー村では、現実の競争の対象はもはやマーケットのシェアではなくなっている。われわれの競争の対象は、人の関心だ。つまり、気持ちのシェア、そして心のシェアだ」シェル・ノードストレム ヨーナス・リッデルストラレ
     
     
   • 「アップルは反抗し、IBMは答えを出し、ナイキは熱く語り、ヴァージンは啓発し、ソニーは夢を見て、ベネトンは抵抗する。つまり、ブランドとは名詞ではなく、動詞だ。」ジャン=マリー=ドルー
     
     
   • それは単純な話だ。
     それは不可能だ。
     そのためには全身全霊を傾けなければならない。
     そのテーマは・・・
     われわれは何者なのか？
     われわれの目的は何か？
     どのようにユニークなのか？
     どうすれば圧倒的な違いを生み出せるのか？
     誰が気にしてくれるのか？（われわれは気にしているか？）
     
     
   • 心からわき出るブランディング
     
     「本物の」ブランディングとは、ひとりひとりのものだ。「本物の」ブランディングとは、誠実さだ。「本物の」ブランディングとは、記憶に刻まれるものだ。「本物の」ブランディングとは、偉大なストーリーだ。「本物の」ブランディングとは（社員にとって、顧客にとって、サプライヤにとって）大いにかかわりのあることだ。「本物の」ブランディングとは、情熱と感情だ。「本物の」ブランディングとは、われわれが朝、ベッドから起き出す理由だ。「本物の」ブランディングとは、決してごまかしのきかないものだ。「本物の」ブランディングとは、年中無休で、全部署をあげて、全員が取り組むことだ。

思考と行動における言語

ソフトウエア開発者において、自国の言語を習得する重要性は、ダイクストラに指摘されるまでもなく、明らかである。しかし、これはソフトウエア開発に特有なことではなく、全ての業種、もっと広く、政治、社会に共通する。

本書を紹介しようと思ったきっかけは、「日経コンピュータ」の書評である。とはいっても新刊ではなく40年以上も読み継がれている名著で、言語とコミュニケーションに関する研究で、豊富な例を交えたわかりやすい説明であり、実用的な価値も大きい。思考、話し合い、議論、説得において言語の果たす役割、陥りやすい誤りを指摘している。

これがソフトウエア開発にどう関係するかというと、人間同士のコミュニケーションを、偏見を排除して建設的に行う方法を示しているからだ。大規模なプロジェクトになるほど、個人の時間でコミュニケーションに費やす時間が増える。この時、例えば議論の中で「よい」「悪い」の2値論に陥らずに、建設的なアウトプットを出すにはどうすればよいか、抽象レベルの混同による混乱を避けるには何に注意すればよいか、といった事などである。ワインバーグのアプローチに通じるところがあると言える。もっとも著者の意向はもっと大きな、社会の問題、国家間の問題、さらに文明の問題を例に取っている。

さて本書からいくつかの規則をひろってみると、

○記号は物そのものでなない。地図はそれが代表する現地ではない。コトバは物ではない。

○文脈が意味を決定する

○二値的考え方は、考えの初まりにはなるが、舵とりの要具にはならない。

○定義に用心せよ。それはコトバについてのコトバである。できるだけ、定義で考えるよりも、実例で考えよ。

いずれも表現は簡潔だが、深いことを言っているし、実践もなかなか難しい。
訳者の大久保忠利は後書きで、「コトバの魔術破り」の方法を示している、とうまいことを言っている。

ソフトウェアテスト 293の鉄則

私は、ソフトウェアの開発者としての立場から、効果的にデバッグできるHOWTO本のようなものを期待して本書を読みました。
内容はまったく違いました。本書はテスト技術者によるテスト技術者のための本です。

本書でテストに対してのイメージが変りました。
今までは、最初に作るテスト項目と手順に従って行う、機械的な作業だという認識だったのですが、テストとはバグを検出することを目的とした創造的な活動であり、あるテスト結果によって、次に何をするかは、テスターの創造力に任されます。

具体的なデバッグのノウハウはほとんどありませんが、筆者たちが長い経験で得た293の経験則です。
ちなみに「鉄則」というのはLessonの訳だと思うのですが、意味が違うのではないでしょうか？

内容は非常に多岐にわたり、テスト技法、バグの報告などから自動化、ドキュメント、SWEBOK批判、キャリアの積み方、転職の仕方まで幅広いです。

対象はある程度大きな組織でテスト部門が独立しているところのテスターあるいはテスト責任者といったところでしょうか？
しかし、SOHOの私が読んでも損はなかったと感じています。読む人の立場によって、また別の発見があると思います。
最初に抽象的な説明がありますが、それにめげずに、５０ページは我慢して読むことをお勧めします。


共感した部分は
「著者たちは”ベストプラクティス”というものを信頼しない。理由は、最適な手法は状況に応じて異なると信じているからだ。ベストプラクティスの名を冠して売り出されている多くのものが、本来ふさわしくないところに無批判で適用されている、その状況を著者たちは憂いているくらいだ。」
「鉄則００５　重大なバグを素早く見つけよう」
「鉄則０２１　技術的、創造的、批判的、実践的な思考が優れたテストのカギ」
「鉄則０４０　騙されやすいと自覚することが騙されない秘訣」
「鉄則１０８　手動テストと自動テストを同格に扱うな」
「鉄則１４５　IEEE ８２９ 標準規格も使い方次第」
「鉄則１８５　『十分なテスト』とは『正しい状況判断を下すのに十分な情報を得られること』である」
「テスト作業は、計画どおりに実行していく作業というよりも、むしろアイデアを生み出す活動である。」
「鉄則１９９　バグ総数によるプロジェクト進捗測定はするな」
「鉄則２０１　進捗報告にバランススコアカードを適用せよ」
「鉄則２８０　テストケースの項目数からは何も分からない」
「鉄則２８６　『どうすればより良いテストができるか』を常に問い続けよ」
「異なるタイプの欠陥は異なるタイプのテストによって見つかる。テストは挑戦的であるべきであり、できる限りプログラムが安定するように、あらゆるリスクに着目して行うべきである。」

コンサルタントの道具箱

ワインバーグの著作の中では、ベストだと思っている、「コンサルタントの秘密」の続編である。コンサルタントのための１６の道具（これらは物の名前がついているが全て抽象的なものである）と、それを補足する多くの法則からなっている。
例えば、正しいこと、そうでないことを見分ける能力を「知恵の箱」と呼んでいるが、その中には、「ケアリーのゴミ警報」という法則がある。それは「やる価値のないことは、きちんとやる価値もない。ゴミにのしをつけるな。」というものである。これらのワインバーグの経験から出た法則が、その法則の名前の元になった面白い逸話とともに紹介されている。
これらの道具は、文章にすると、自分でも使えそうな錯覚を抱くが、実際に使おうとすると、相当に難しいと思われる。それは人の頭とこころの使い方であるから。
コンサルタント以外の人々には、無用と思われるかもしれないが、本書はコンサルタントと依頼主との人間関係や自分の成長に焦点をあてているので、例えばコンサルタントをフリーランスや、SEに読み替えても十分に通じる。
法則ではないが、私が願う理想の姿を描いた次の文章は忘れられない。そもそもこれこそが、この本が書かれた理由だと思う。
「自分が尊重され、最高の自分を見せる機会のある適正な労働条件のもとで、自分の得意とする楽しい仕事をして、いつも忙しくしていよう。」
前著に比べ、内容が薄くなった感じを受けたことと、翻訳が木村泉さんに比べ、いまひとつでちょっとがっかりである。しかしこの本に投資するお金と時間は決して無駄にならないと思う。

他に役に立ちそうに思える法則が多数ある。

・新しく学ぶことがなくなったら、次へ移るときだ。（ダニーの決断のコツ）
・行動に挫折したら、情報を収集せよ。情報収集に挫折したら、眠れ。（ルグインの法則）
・(1)言葉、口調、ボディーランゲージを使って、心から感謝を示す。
(2)残念そうに、しかしはっきりと、言い訳せずにノーと言う。
(3)将来、別の関係を作るきっかけを示す。
（サティアの物柔らかな一蹴 ：依頼を断る際の方法）
・相手が奇妙な行動をとっていたら、たぶん奇妙なものに反応しているのだ。それはたぶん自分である。（パーソンの特異性原則）

ピープルウエア 第2版

様々な所で参照されている古典です。副題はPRODUCTIVE　PROJECTS　AND　TEAMSで、ソフトウエア開発におけるプロジェクト、チームのあり方です。現代では少し古くなったところもありますが、デマルコとリスターの着目点は完全に正しいと思います。デマルコの名前だけで無条件に買ってしまう信頼できる著者の一人です。第2版で8章が追加されました。

・デマルコが開発者としてシャロン・ワインバーグが管理するプロジェクトで仕事をしていたころ。彼はある日病床から足を引き摺ってオフィスへ行き、不安定なシステムを立て直そうとしていた。シャロンは、コンソールの前で倒れそうになったデマルコを見つけ支えてくれた。やがてスープを持って戻ってきて、彼にに飲ませ、元気付けた後で、彼は彼女に、どうしてこんなことまでしてくれるのか、と尋ねたところ、「トム、これが管理というものよ」…つまり管理者の役割は､人を働かせることにあるのではなく、人を働く気にさせることである。
・残業の本当の目的は、品質向上のためである。昼間はオフィスが騒々しく仕事に没頭できないなどの理由で。
・生産性と無縁な要因（プログラミング・コンテストによる結果から）① プログラミング言語② 経験年数③ 残存バグ数（つまり、生産性の高い人が低い人よりバグが多い或いは少ないことはない）④ 年収
・誰も書かなかった生産性要因…「誰とチームを組んでいるか」
・プログラミングコンテストの結果､生産性、作業速度ともに優れた上位のグループの作業環境は、オフィスは静かで､個人の空間が保護され、無駄な割り込みも無く、その他あらゆる点で下位グループよりも恵まれていた。（各参加者は、通常の就業時間内に自分の作業場所で競技を行う）
・チーム殺し、7つの秘訣① 仕事がうまく行かないことを部下のせいにする② 官僚主義③ 作業場所の分散④ 時間の分断：人を同時に２つ以上のプロジェクトに割り当てる⑤ 品質低減製品：短期間での出荷⑥ さばを読んだ納期⑦ 人々を次々とチームから引き剥がす

・チーム殺し再考-チーム内の競争は、コーチングを難しく、あるいは不可能にする。チームの中の競争を助長する管理者のいかなる行動も、チーム殺しと見なされる。例えば○年俸制あるいは業績レビュー○目標による管理（MBO)○顕著な業績に対して特定の作業者を賞賛すること等。
・CMM批判-CMMはローリスクの安全な行動へと仕向け、それゆえプロジェクトは利益の少ないものとなる。最も実行する価値のあるプロジェクトは、あなた方のプロセスレベルを下げるようなプロジェクトである。
・人々は変化を嫌う。変化は、失敗が認めらられる場合にのみ成功のチャンスがある。
・学習センターが存在する最も確率の高い場所は、中間管理者の間にある空白の中である。（組織図の箱の外の空白である）
・究極の管理上の罪とは人々の時間を浪費させることである。例えば定例会議が単なるセレモニーになるように。
・コミュニティに対する必要性は、人間のファームウエアに組み込まれた何かである。

ソフトウェア職人気質

従来のソフトウエア工学を補完するものとしてソフトウエア職人気質(Software Craftsmanship)を提唱している。全面的に賛成というわけではないが、ソフトウエア工学に対する問題点の提起は、うなずくところが多い。ソフトウエア工学の問題点すべてがソフトウエア職人気質のメタファで解決できるとは思えないが、ソフトウエア工学で捉えそこなっている、優秀な個人に依存するするプロジェクトを見るにつけ、双方を両立させる方法はないものかと悩みは尽きない。

・ソフトウェア工学はもともと200人以上の大規模チームの開発のための手法であり、小規模開発に適用すると数々の問題を起こす。
・ソフトウェア工学は個人が技術を磨くことに関しては何も述べていない。
・ソフトウェア工学は全ての問題を、人を投入することで解決しようとする。
・ソフトウエア工学は「体系的」かつ「規則化」された「定量的アプローチ」が唯一可能なアプローチであると仮定していて、人々が新たな方法を考える妨げになっている。
・体系的・定量的プロセスがあったとしても、ひときわ優れた開発者の存在がプロジェクトの成否を握っており、そのような開発者を生み出せる育成方法に注目しなければならない。
・プロジェクトの遅れは過度のプレッシャーによって引き起こされるが、これはソフトウェア工学メタファによって生み出されたものである。なにかに時間がかかりすぎている場合、作業員をより熱心に、より長く働かせるだけで良いのです。この考えをソフトウェア開発に持ち込もうとするのは間違っている。
・測定できるものは、パフォーマンスを向上させることとは無関係である。パフォーマンス向上を目指して精神活動について話す場合、事例証拠を用いるしか方法がない。ソフトウェア工学が危険なのは、事例証拠の価値を重要視していないからである。

熊とワルツを

第1部 なぜリスク管理をするのか
まったくリスクのないプロジェクトに手を出すのは負け組みだ。かならずといっていいほど、何も得るものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。時間と労力を節約して、もっと価値のあることに使ったほうがいい。
リスク管理の反対を「危機管理」といい、問題が発生した後に何をするべきかを考えることを意味する。

リスク管理を構成する主な活動
・リスク発見・・・ブレーンストーミングによるリスク選別と、新しいリスクを発見するための継続的なプロセスの導入
・エクスポージャー分析・・・それぞれのリスクが実現する確立と、その影響を数量化する。例えばリスクの発生確率が20パーセントで、発生した場合に100万ドルのコストがかかるとしたら、リスク・エクスポージャーは20万ドルである。
・危機対応計画・・・リスクが実現した場合に何をするべきかを計画する。これのみをリスク管理と誤解されることが多い。
・軽減・・・リスクの発生を検出する指標を考え、発生までにとる処置を計画する。例えば火災のリスクに対し、消火器、火災報知機の設置避難訓練など。
継続的な移行監視・・・管理するリスクを追跡し、実現しないかどうかを監視する。

デンバー国際空港 この失敗は、言われているようなソフトウェアの開発プロセスの問題ではなく、リスク管理がなされなかったことが問題である。

第3章 リスク管理の方法

「測定していないものはコントロールできない」のデマルコの言葉通り、数量化し、リスク図で考える方法が示される。
リスク図とは縦軸に確率、横軸にスケジュール、あるいはコストをあらわしたグラフである。
例えばプロジェクトの完了を、「プロジェクトは年内に完了します。」という代わりに「年明けまでに完了する確率は０です。完了する確率が最も高いのは来年4月の始めです。少なくとも5月以降でしたら５分以上です。」などと説明する。

いくつかの原因リスクおよび、開発規模のパラメータと技術要因が合成されて、結果としての全体リスクの図ができる。
例として、ソフトウェア・プロジェクトのスケジュールのリスク図を作成するExcelのマクロで作られたRISKOLOGYの使い方が示される。（無償で使える）
RISKOLOGYでの原因リスク（コア・リスク）としているのは、
(1)スケジュールの欠陥
(2)要求の増大
(3)人員の離脱
(4)仕様の崩壊
(5)生産性の低迷
の５つである。

リスク発生の検出における、進捗メトリック、特にEVR（稼得価値）の重要性。
さらにリスク軽滅のためのインクリメンタル手法の説明。
究極のリスク軽滅戦略は「早くスタートすること」。

第4章 数量化の方法

プロジェクトのスケジュールとコストをリスク図を使って考えるのと同時に、発注者は、プロジェクトの利益をリスク図を使って同じ精度であらわさなければいけない。


本書は会社の中でのソフトウェア・プロジェクトのリスク管理の方法を述べていますが、SOHO事業者の立場から、リスク管理を考えるきっかけになりました。
SOHOとしては、いいニュースは、リスク管理に反対する人は誰もいないこと、悪いニュースは、人員の離脱（健康の問題でしょうか）等に対応するすべをもたないことです。
この辺の弱点を、パートナーとのコラボレーションで補うというのが、今後のあり方かなと考えさせられました。
内容はソフトウェア･プロジェクトに特化されていますが、業種、業態を問わず、全ての方にお勧めです。

ワインバーグのシステム行動法

ワインバーグの4巻本の3冊目。Congruent Actionとは、”適合的行動”と訳されているが、要は状況にふさわしい適切な行動である。どのようにしたら適合的に行動できるかがテーマである。CMMとのアプローチとの違いを鮮明にしている。すなわち「人」に焦点を当てるのである。

ソフトウエア開発において、適合的でない例は次のようなものである。
・時間とおりプロジェクトを完成させる見込みがほとんどないとわかっていながら、それを認めて上司に報告し、代わりの計画や手法を議論できない。
・遅れているプロジェクトに新たに開発者を投入しても、さらに遅らせるだけだと知りながら、何もしないように見えるのが我慢できない。
・どなりつけると事態はさらに悪化すると知りながら、やめられない。
・解決すべき問題を明確に理解しなければプロジェクトは進展しないと知っていながら、開発者のコードを書きはじめたいという熱意に抵抗できない。

・「定義された工学プロセスは、健全な管理慣行の欠如から生じる不安定性を克服できない。ごく希にとびきり有能で、力強い管理者だけが、そのような圧力に抵抗できる。」（ハンフリーとカーティス）
これより以下が導かれる。
1.無能で力のない管理者しかいなくても、不安定性を克服するために定義された工学行動を組織的に導入する。(CMMのアプローチ）
2.非常に有能で力のある管理者を組織内で発掘し養成する。（ワインバーグのアプローチ）

・SEIや他の学会が1の方針を追求しているのは誠に重要である。それは、この方針がコンピュータに携わっている私たちがいつもよく追求し、よく知っているものだからである。すなわち、方程式から人を消去して、品質達成の方法を理解しようとするからだ。

・「お粗末な管理は他のどんな要因よりもソフトウエアのコストを急速に増大させる」（ベーム）

・リップ・バン・ウインクルの手法：2年後に目が覚めて「どうしてこのプロジェクトは2年も遅れているんだ？」ということを知りたがる。
・フィーディーニの手法：こみいった公式と変換で煙に巻き、じっさいになにをやっているのかわからなくする。

・適合性へ移行するために内なるメッセージを再構成する例

非適合的：誰かが私を批判するだろう
適合的 ：批判は避けられないものだ。贈り物として受け取ろう。

非適合的：私はよくないと思われるかもしれない。
適合的 ：誰かが私をよくないと思ったとしても、私は生き残る。

非適合的：私は完全でないと思われるかもしれない。
適合的 ：私は完全ではないので、完全であるとみなされる必要がない。


・多くの専門家は彼らのやることにほとんど成功しているので、めったに失敗を経験しない。彼らはめったに失敗したことがないから、失敗からどう学ぶかを学習したことがない。したがって、単一ループの学習戦略がうまくいかなくなると、いつも防衛的になり、批判を遮断し、自分以外のあらゆる人に「非難」を浴びせる。要するに彼らの学習能力は、もっともそれを必要とする瞬間にまさしく停止してしまう。（ハーバード・ビジネス・レビュー）

・私たちはソフトウエアの仕事はみな論理的だと考えがちであるが、多くの行動が感情に基づいて選択されている。

・性格の差異を資産と認識する--ソフトウエアの仕事は、多様な仕事から構成されているので、ある一つの性格やタイプや一連の技術や、一つの見解だけでは仕事のすべての部分に適応できそうもない。これこそ、私たちがソフトウエアに携わる人々の間の差異を必要とする理由である。

・品質とスケジュール目標のトレードオフが出来ないと感じると、管理者は人々の交流の質を犠牲にしたいという気になりがちだが、そうすればすぐに品質とスケジュールの両方に代償を支払わなければならない羽目になる。

・非難の中毒をやめさせる--一般的には、批評は、非難や罰としてではなく情報として与えられた方がもっと受け入れやすい。非難を行っても、人々に非難を回避する方法を見つけようと動機づけるだけである。

・ＭＯＩモデルはチームや個人がうまく機能していないときには、失われた要素が何かあるかもしれないことを示す。動機（Ｍ）かもしれないし、組織（Ｏ）かのしれないし、情報（Ｉ）かもしれない。読者の仕事はどれであるかを見つけ、それに応じて介入することである。

・私自身にしたところで、気分がよくないとき、人をいじめ、無視し、非難し、自分を非難し、困難な状況から逃げ出し、抽象の中に雲隠れしたことがある。こうしたことを通し、自分が適合的でないとき、ソフトウエア工学の問題を解決しようとしたり、ソフトウエア工学の組織を作ろうとしたりすることは無意味だということを学習したのだった。それでわたしは、まず最初に適合的になると言う要の行動をとる、読者にもそうしてもらいたいと希望しているのである。

デマルコ　大いに語る

「ピープルウエア」のデマルコのエッセイ集。PowerPCプロジェクトの担当プログラム・マネージャーであったシーラ・ブラディとの対談は必読である。デマルコの著作の中では本書を第一に勧める。

・ソフトウェア開発の作業の大部分は圧縮できない。圧縮されたスケジュールに対しては、まず無駄な作業を省こうとする。次に残業するようになる。最後には品質を犠牲にしてスケジュールを守ろうとする。このようなアプローチは数回の戦闘には勝てるかもしれないが戦争には勝てない。かつての米国の自動車産業のように。
・計測性機能不全の例（日立ソフトウェア・エンジニアリング）単体テストでの発見バグ数が多いほどシステムテストで多くのバグを発見しなければならないと言うプレッシャーから、開発者は単体テストのバグを隠すようになった。
・作業者にプロであることと、実績評価の単純な計測値表示も追及せよと両方を追求するのは無理である。
・自分たちの成功や失敗を分析しない本当の理由は「怖いから」。
・ソフトウェアプロジェクトの納期遅れは、生産性が低いことが問題とされるが、もっと妥当なスケジュールを設定することに焦点を当てなければいけない。
・大切なのは貴重な資源つまり時間の燃焼率を測ることである。プロジェクトの初期に稼いだ1週間は、大詰めの1週間と同じだけ大切である。
・人は失敗からの逃避として否認の態度を続ける場合がある。計測が高くついても割に合うのは、否認が始まる前に対応できるからだ。納期まであと3ヶ月になっても不具合発生率がこうだったらどうなるかと言う質問が出来る。
・残業は短距離走ではよいかもしれないがマラソンには向かない。
・たいていのソフトウエア技術者は、予定を達成するために残業するんじゃなくて、達成できないことをやましく感じないように残業している。
・一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の落ち度になると知ったら、こう考えるしかない：どんな間違いだったらボスの落ち度になるのかな、と。
・出荷日が近づくにつれて仕事量の減る人が出てくる。納期前に全員まだ多くのやるべき作業があったとしたら、それは工程計画が全部間違っていたということである。
・過剰機能の例。部下の仕事までも何でも完璧にこなそうとする模範指導型管理職。本来マネージャーは触媒である。マネージャーの仕事のうち、やさしいほうは制御と調整に関係する。難しいほうは、動機づけ、調和、チームワーク、個人の成長、そして仕事に対する満足度のような人間的な配慮に関係する。模範指導型マネージャーにはとても手が回らないのが、この人間的側面なのである。
・「何か一つだけ手を打つとしたら」・・・4対1の確率で次が役に立つ。「部下に一度に一つの仕事だけをさせること」

人月の神話

有名な本の20周年記念増訂版。「ソフトウエア開発の神話」に、「狼男を撃つ銀の弾丸はない」を加え、さらに現在の時点で、これらが正しかったかどうか検証している。
前者は人と月は交換可能ではないという主張を中心にした考察。（つまり、3人で4ヶ月かかる開発は、6人にかければ2ヶ月でできるわけではない。）後者は、ソフトウエア生産性を飛躍的に向上させる特効薬はない、という主張。

・遅れているプロジェクトに人を追加した場合に発生する本来の作業以外の工数は、経験ある人から受ける教育・訓練、仕事の再分割により既に完了している仕事で無駄になるものも出てくる上、システムテストをより長くしなければならない。ブルックスの例では人を追加しなかった場合と同じ遅れとなる。
・ブルックスの法則-遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ
・マイルストーンを鋭利な刃のようにあいまいさをなくすこと。こうすることで人は、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司は異なる意味に解釈してしまう。ごまかそうというつもりはなくても表現を和らげてしまいがちだ。
・「どうせ他のところも遅れているのだから」-１日の遅れにもやっきにならなければならない。この程度の遅延こそが、まさに破局の要素なのだ。
・成功のためには、プロジェクトに携わる人々の質、及びその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えている。

ソフトウェア　プロジェクト　サバイバル　ガイド

マイクロソフトプレスの1冊。私が読んだプロジェクト管理の教科書の中で最良の１冊。全てのリーダー、管理者に強く薦める。
数十年にわたるソフトウエア業界の知識を凝縮した、銀の弾丸に頼らないオーソドックスな手法である。
計画・準備に時間をかけ、工程をきちんと定義し、各工程内で間違いが流出しないよう管理された段階別分納（「中間目標アプローチ」）による開発である。

以下、参考になった部分を挙げる。

・十分に検討され設定された開発工程は、不可欠である。開発工程を明確にすることで、時間を生産的な活動に使うことができる。工程が不完全だと誤りの訂正に時間を割くことになる。
・プロジェクトを成功の鍵となる作業は、プロジェクトの上流で行われる。
・工程の定義は創造力や勤労意欲を妨げることはない。
・上流の問題は上流で修正できるよう、要件［要求仕様］とアーキテクチャを徹底的に注意深く見直す。
・プロジェクトの初期段階では、予算とスケジュール、及び作りこむ機能の両方を厳密に設定することは不可能である。
・平均的なプロジェクトでは、時間の80%を計画になかったやり直し作業に費やしている。その時間の数パーセントを計画立案に当てればよい。
・危機管理-最良の結果を期待しながら最悪の結果に備える。
・ソフトウエア　プロジェクトのリスクには先手を打って対処する。
・「管理されたプロジェクト」の逆は「管理されない（自由な）プロジェクト」ではなく、「管理できない（手のつけられない）プロジェクト」である。
・段階別分納では、重要な機能を早い段階でリリースでき、リスクを早い段階で排除でき、問題を早い段階で明確にできる。
・８分の２法則：工程の作業の８割が完了してから次工程の作業を開始する。
・変更管理の要点-変更管理委員会の設置、変更は前もって決めた点に制限すること、作業の成果を変更管理の下に置くこと。
・全ての情報は良いものも悪いものも,あらゆる立場の人に制限されずに伝わらなければならない。
・危機管理では危機管理計画を作成し、担当者を選任し、トップ１０リスク一覧を使用し、個々のリスクに対する危機管理計画を作成し、匿名によるリスク報告経路を設定する。
・品質が悪いという評判は,開発が早かったという評判よりももずっと後まで残る。
・テストはソフトウエアの品質を調べる手段であり,ソフトウエアの品質を保証するものではない。
・アーキテクチャの目標は複雑性を減らすことにあり、組み込む機能だけでなく、組み込まない機能についても十分な吟味が必要。
・プロジェクトのコストに対する影響が上流で大きいことを考えると、悪い知らせは,早い時期に知らされるほうがよい。
・見積もりは、プロジェクト完了までに何度か再見積りを行うことを計画し、変更管理の下に置く。
・小規模マイルストーンを採用し、完全なマイルストーン一覧を作る。
・プロジェクトが成功するかどうかは,チームがどれだけ間違いを速く発見して簡単に修正できるような体制を作れるかどうかで決まる。
・技術審査［レビュー］にはそのコストの何倍もの効用がある。
・ソフトウェアがほとんど完成するまでテストの計画を立てる人がいないため、テストは,しばしばプロジェクトの完成を遅らせるネックになる。テスト計画は、一朝一夕には作れない。結果的にテストはどうしても簡略化される。
・ソフトウエアの欠陥については、便りのないのは悪い知らせである。欠陥が見つからないのは、開発作業が優れているのではなくテストが不充分であることの証拠である。
・進捗状況と品質に関する情報は公開する。
・スケジュールの遅れを取り戻せるプロジェクトはほとんどなく、その後さらに遅れが拡大する場合が多い(1991年の300以上のプロジェクトの調査結果)。

ワインバーグのシステム洞察法

ワインバーグの４巻シリーズの２巻目である。ここでは、“１次計測(First-Order Measurement)－ソフトウエア開発で何が起こっているかを観察し観察の意義付けを理解する能力－”がテーマである。
「1次」の意味は、ラフスケッチのようなものである。２次はもっと精密な計測になるが、管理者の日々の問題には焦点を当てていない。「自分が何について話しているのか分からないときに、正確であっても何にもならない。」本書は２次計測を有効に利用できるように支援するものである。
本書はサティアの交流モデルに沿って展開される。これは観察から行動にいたるモデルで、「情報の取り込み」->「意味付け」->「意義付け」->「反応」の流れからなる。「意味」は取り込んだデータにはないものである。また「意義」は「意味」の「意味」であり、私たちの頭脳が扱える大きさに変えるフィルターである。

印象に残った部分を挙げる。

・パターン２（慣習的文化）では、過去の実績統計は変革のために用いられるのではなく、全てがうまくいっていることを証明するために用いられる。
・なぜ観察は重要か-危機の突然さは危機の尺度ではなく、管理者の気づきの尺度である。もし管理者が効果的に観察しつづけていたのであれば－彼らはがっかりさせられたかもしれないが、驚かされはしなかっただろう。
・文化パターンを見分ける方法は、“病気”の処方を観察することである。舵とり（パターン3）組織は病気をうまく扱うほうだが、ときどき同じ症状を繰り返す。組織が健康であること（プロセスレベル）よりもそれぞれの病気を治すこと（製品レベル）に注力するからである。慣習的（パターン2）組織は病気を罪悪のように扱い、人々が症状を隠すのを望むようになり、病気を悪化させる。
・あることが繰り返して起こるとき、それは偶然の出来事であるはずがない。
・慣習的文化(パターン２)では、管理者の非難を免れるための何にも優るこつは気づかないことである。
・あることを監察しているという単なる事実が、開発に使われる努力の大部分を、計測システムを打ち倒すのに注がれる恐れがある。例えば、LM中のビット”1”の割合を増やせという理不尽な指示を出すと、増えた実績があがってくるであろう――。
・製品を可視化する-可視でなければ、制御は不可能であり、制御できなければ、品質を保証することはできない。
・地図と土地とが一致しないとき、つねに土地を信じよ。地図とは測定値に対する複数の像である。ソフトウェアに対する像は地図であり、これは土地そのものではない。
・図表は重要ではない、図表を作ることがすべてだ。
・顧客満足度を計測できるが、 5.0の満足度はよいのか、悪いのか、知ることができるのは、トレンド図の助けを借りて、率が時間的にどのように変わるかである。変化は、管理者がもっと調査すべきだと言う信号である。
・受け取ったものについて少なくとも三つの異なった解釈を思いつかないならば、その意味を十分に考察していないのだ。
・慣習的（パターン２）組織のプログラマのほとんどは、何事も規則どおりだ－という錯覚がもはや維持できなくなるまで－管理者を満足させるために始終罪のないうそを創作する。
・品質さえ気にしなければ、品質以外のどんな要求でも満たすことができる。
・“努力は計算できるものに注がれる。”（デマルコ）。コスト計算はコスト削減を導く。価値計算は価値の増大を導く。コストと価値は異なる。
・Xドルの損失はいつでも財務上の責任がXドルを超える取締役の責任である。
・パターン１と２の組織では誤りが起こったときに、非難と処罰に時間を使い、早期に故障を把握し、予防する手順の確立という管理者の責任から注意を逸らす。
・悪い兵士などいない、いるのは悪い将校だ
・もっとも危険な反応は、危機が実際にどれくらい深刻なものであるかを気づかせるような情報源から自身を切り離すという傾向である。
・官僚主義の尺度は、なぜそれをするのか関係者が理解できないパーセンテージである。
・レビューは、スケジュール効率を改善し、冗長作業を除去し、テストを補い、そして訓練をもたらす。