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

原題は、ソフトウェア品質管理 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ドルを超える取締役の責任である。
・パターン１と２の組織では誤りが起こったときに、非難と処罰に時間を使い、早期に故障を把握し、予防する手順の確立という管理者の責任から注意を逸らす。
・悪い兵士などいない、いるのは悪い将校だ
・もっとも危険な反応は、危機が実際にどれくらい深刻なものであるかを気づかせるような情報源から自身を切り離すという傾向である。
・官僚主義の尺度は、なぜそれをするのか関係者が理解できないパーセンテージである。
・レビューは、スケジュール効率を改善し、冗長作業を除去し、テストを補い、そして訓練をもたらす。

ワインバーグのシステム思考法

"Quality Software Management"の4部作の第1巻。「複雑な状況を理解する能力」に焦点を当てる。
最初に「品質パターン」として、ハンフリーのプロセス成熟度をベースにした６つのソフトウェアサブカルチャーの
パターンが定義される。だがアプローチはCMMと全く違う。ワインバーグはパターン１とパターン２からパターン３
へ移行するために思考パターンを変えなければならず、そのために本書を書いたと言っている。CMMの
アプローチに関しては、「方程式から人の項を消去するようなもの」と批判している。要するにキーは人であり、
優秀な管理者になるためにはどうすればよいかということである。私はワインバーグのアプローチに全面的に賛成する。
ワインバーグの著作では他に「コンサルタントの秘密」「プログラミングの心理学」を強く勧める。（後者は残念ながら絶版のようだが・・・）
以下、印象に残った部分を挙げる。

・他の全ての原因よりもカレンダー時間の切迫が､ソフトウエアプロジェクトにその失敗の現実を直視させる。
・縮尺の錯覚-大きなシステムは､小さなシステムと似たようなもので､単により大きいだけだ。
・行動は早めに、かつ少しずつ-パターン２のマネージャーは楽天的であり、物事がまずくなった時、自ずと良くなっていくだろうと想像する。問題を認め、かつ非線型システムが、それ自身では直らないことを悟った時、彼らはとてつもなく大きな訂正を試み、さらに悪い非線型サイクルをはじめる。
・大切なのは出来事ではない、出来事に対する反応だ（火災に見舞われた２つのプロジェクトを比較する。片方は成功し、他方は失敗した例を分析する）
・欠陥フィードバック率(ＦＦＲ＝生成された欠陥／解決された欠陥）の適用例。ある企業では規模の小さい訂正の方が大きいFFRを持っていたことが分かり、規模によらずレビューするようになった。
・ブーメラン効果-品質を手っ取り早く片づけようとすればするほど、問題はますます悪くなる。

自分の仕事 好きですか

「こころのチキンスープ」シリーズの1冊。このシリーズは好きで全部読んでいるのだが、中でも本書はビジネスをテーマにしたものである。"Heart at Work"という原題が示すように「ハート」が大事だと言う、モチベーションを刺激する感動的な話がいっぱいである。

私が気に入っている話は、

・「ジョニーの場合」・・・著者は大手スーパーチェーンで「職場に心を」というテーマについて、従業員に話をしたことがきっかけで、ダウン症のレジ係、ジョニーは、父親にワープロを教えてもらい、「今日思ったこと」の3行の文章を毎日「心を込めて」お客さんの袋に入れるようになった。ジョニーのレジには行列が出来るようになり、さらに他の従業員たちもそれぞれ工夫を凝らすようになる。売り場は一変した。
・「自分の仕事が好きですか？」二つのグループ、総計千五百人に対する調査。被験者の８３％を占めるＡ群は、将来やりたいことがあって、とりあえず資金稼ぎのために働いている人々、残りの１３％のＢ群は、お金のことは後回しにして、自分が今やりたいことをする人々である。二十年後、千五百人中１０１人が富豪になった、その１０１人中１００人までは、好きなことを追求する道を選んだＢグループの人々だった。
・「ジェシーのグローブ」・・・著者が行ったコンビニチェーンでの管理者研修での出来事。サービス業界の低賃金を思えば、「よその会社の移らなかった理由は何か」という質問に対して、新人店長のシンシアには決定的理由があった。彼女は声を詰まらせ、涙ながらに言った。「私を会社につなぎとめたのは、１９ドルのグローブです」・・・（あとは本を読んでくださいね）

「リファクタリング」

原書の副題は「既存のコードのデザインを改善する」というものです。

リファクタリングの定義は、「外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること」です。

多くの手法のカタログ的な構成になっていて、各手法は以下のような構成です。

(1)まず概要が簡単なコードの例やクラス図を使って説明されます。
(2)「動機」：なぜこのコードはリファクタリングされなければいけないのかが説明されます。ある種のアンチパターンのようなものです。
(3)「手順」：リファクタリング手順が詳細に示されます。少し修正して、少しテストというXPの見本のような手順がくどいほど繰り返されます。
(4)「例」：実際のコードの例が示されます。

デザインパターンもよく参照されますし、各手法も相互に関連していて、Javaの中級～上級者向けの本だと思います。

得る所が大きいのは、まず、Javaで、こうコーディングしてはいけない、というアンチパターンと、それをリファクタリングした結果の、
こうあるべきだという常識が、コードのサンプルから学べるところです。その意味ではJavaのプログラム作法的な本でもあります。

読み方としては、プログラム作法の勉強のために精読するもよし、どんな手法があるのか、ざっと眺めた上で、リファクタリングが必要になったときに、必要な部分を精読するのもよいと思います。

「リファクタリングはなぜ有効か---Kent Beck

今できることを作り込めばそれで終わりと考えているのであれば、長くプログラマを続けていくことはできないでしょう。
今日はできたからといって、明日には通用しないかもしれないそのやり方を通せば、いつかは敗者となってしまいます。
重要なのは、今の時点で何が必要かが把握できても、明日については何もわからないということです。
多分こうだろうと推測しても、想像もしなかったことが起こるかもしれません。

今日については十分把握できますが、明日については不十分なままです。
しかし、今日のためにしか仕事をしないとすれば、やがて明日には何もできないことになるでしょう。

リファクタリングは、この苦境から抜け出すための手段です。
昨日の決定が、今日には意味を持たなくなったと気づいたならば、過去の決定を変更してしまえばいいのです。
そうすれば今日の仕事ができるようになります。
明日には、今日の理解が多少未熟だったと思うかもしれません。だったらまた変更すればいいのです。」


実際に中規模のリファクタリングをやってみた感想としては、リファクタリングとして、特別に作業を行うのではなく、
普段のプログラミングの一部として、少しづつ行うのが効果的であると思います。
ファウラーさんの本にも書いてあるのですが、大きなリファクタリングは、小さなリファクタリングを価値あるものとしている多くのメリットを欠いています。
（例えば、即座の満足、目に見える進捗）
実際、リファクタリング中の3日間は、外から見たら目に見える進捗は有りません。
しかし、その後のコーディングの進み具合には大いに貢献しましたし、コードレビューをやったのと同じ効果がありました。（バグもいくつか発見しました）

使ったのはTemplate Methodだったのですが、具体的な手順として、

(1)類似したコードから異なるコードを分離し、差異部分を抽出
(2)差異部分を同じシグニチャを持つメソッドを作成する
(3)メソッドの引き上げ

とあり、例題のコードを使って説明されていて、分かりやすいものでした。

XP エクストリームプログラミング 入門

Amazon.comでソフト関係の本を何冊か買ったことがあるのだが、第一のお勧めに、この本があがっていた。Amazon.comでの評価は４つ★である。書店で翻訳を見つけたので早速買った。
私なら、この本で述べられている手法を、究極のソフトウェア開発と言う勇気はない。著者も言うように個々の手法のほとんどは、昔から言われていることである。著者がこの方法の組み合わせで成功したのは、プロジェクト規模が小さかったことと、コンペティタがいなかったからではないか。共感できる部分もあるが、かなり読みにくい本である。ペアを組んで作業する方法や、テスト可能にするためにコードをシンプルにする等、参考にできそうなところもある。レビューやインスペクションについて、全く述べていないところが面白い。
どの手法に対してもそうであるが、重要なのは、XPの通りに実行することではなく、状況に応じて必要な部分を取り入れる柔軟さであろう。

・必要なことは、数回の大きな修正ではなく、多数の小さな修正である。
・XPは今日の問題を解くために、今日いい仕事をする。そして、複雑な機能は将来必要なときに、追加できると自分の能力を信じればよい。作りこんで結局使われない場合が多い。
・最良の戦略は実際に差し迫った問題を解く間、多くのオプションを保留しておくことである。
・プロジェクト初期に多くの投資を行うことは、災難を起こすレシピである。
・負けないために仕事をするのではなく、勝つために仕事をする。勝つために必要なことは何でもやる。そうでないことは何もしない。
・シンプルなシステムをすばやく稼動（運用）させる。そして新しいバージョンのリリースを極めて短いサイクルで行う。
・まず単体テストのコードを書き、コーディング、テストを繰り返す。
・二人のプログラマーが1台のマシンに向かい、コーディングする。
・リファクタリング
・誰でも全てのコードを変更できる
・タスク完了の度に、システムを結合しビルドする。
・週40時間以上働かない。
・ユーザをチームに加える。
・テストを自動化し、テスト結果を機械的に判定できるようにする。

達人プログラマー

実践的な開発手法。役に立ちそうなアイディアとアドバイスがたくさん詰まっており、開発者に強く勧める。DRY、直交性、リファクタリング・・・すぐにでも使いたいものがたくさんある。

私が参考になった部分を書き出すと、

・常にあなたの知識ポートフォリオに投資すること。例えば毎年新しい言語を学習する。月に1冊は読書する等。
・DRY(Don't Repeat Yourself)原則。同じことを2箇所以上に記述し、片方を修正するときに、もう片方も修正しなければいけない場合、DRY原則に反している。
・直交性。ある種の独立性のこと。例えばデータベースのアルゴリズムとユーザーインタフェースは直交しているべきである。
・目標を見つけるには曳光弾を使う。発展的なプロトタイピング。（撃ってから狙えと言う言葉を思い出します）
・GUIのメリットはWYSIWYG--What You See Is What You Get（見たとおりのものが結果として得られる）。デメリットはWYSIAYG--What You See Is All You Get（見たとおり以上のものは得られない）。
　つまり設計時に意図された以上のことはできないと言うことです。（AccessのQueryのデザインビューがよい例でしょう。UNIONとか副問い合わせを考えると。）
・起こりえないことは表明(assertion)を用いてそれを証明すること。
・抽象概念はコード上に、詳細はメタデータ上に置くこと。全般的なことをプログラムし、それ以外の特殊なことはどこか他の所（つまりコンパイル済みコードの外側）に持っていく
・コーディングは機械的な作業ではない。機械的な作業ならば、プログラマはCASEツールによって駆逐されていただろう。
・いつリファクタリングを行うべきか？①DRY原則に反している②直交性の原理に反している③時代遅れの知識④パフォーマンスの改善
・コーディングの際にはテストすると言うことを意識してコードを書く
・早めにバグが見つかるほど修正は安く上がる。「少しコーディングして少しテスト」する。
・コードとドキュメントは同じモデルの２つのビュー。DRY原則に反しないよう例えば仕様書をデータベース・スキーマに変換する等。
・あなたの作品に署名すること

等などです。

テスト技法に関する古典。テストにかかわるすべての人に薦めたい。理論面に偏ることなく、心理学的、経済学的な考察も貴重である。数学の証明のように、論理を追うのに少々疲れるところもあるが、結論だけにでも目を通す価値は十分ある。

参考になった部分を挙げると、

・テストとはプログラムが正しく動くことを示すことではなく、エラーを見つけるつもりでプログラムを実行する過程である。
・テストは破壊的な過程であり、建設的な考えを持った一般的な人間には難しい作業である。
・テストの原則
○結果が自分に都合のよいように見えると言う現象があるので、テスト結果をきちんと定義しておく。
○プログラマは自分の作ったプログラムをテストしてはならない。プログラミングは建設的な過程であり、一夜明けて破壊的なテストをすることは不可能である。
○テスト結果を完全に検査する
○テスト・ケースは、正しい予想できる入力条件だけでなく、誤った予想しない場合も考えて書く。
○プログラムが意図されたように動くかどうかと同時に、意図されなかった動きをするかどうかをしらべる。
○テスト・ケースも使い捨てにしてはならない。
○エラーは見つからないだろうという仮定のもとにテストの計画を立てない。
○プログラムのある部分でエラーが存在する確率は、その部分ですでに見つかったエラーの数に比例する。
・レビュー、ウォークスルーは、ターゲットを使わないテストである。
・テストケースの設計では、どの方法でも、それ単独では不十分であり、さらにほかの方法と組み合わせても完全とは保証されない。
・モジュールテストでは例えば論理網羅（ホワイトボックス・テスト）を基本として、ブラックボックス・テストの集合で補足し、次に限界条件をカバーするテストケースを追加する。
・モジュール同士の結合を、トップダウンで行う方法と、ボトムアップで行う方法のメリット、デメリットを検討し、ボトムアップが有利な点が多いと結論付けている。
・エラー位置発見の原則
○考えよ。
○いきづまったときは、明日までのばそう。
○いきづまったときは、その問題を他人に説明しよう。
○デバッグ道具は２番目の手段としてつかおう。
○ 実験を避けよう。実験は最後の手段である。

等である。

「はじめの一歩を踏み出そう」

All Aboutのフリーランスの塚田裕子さんも五つ星をつけていました。

スモールビジネスをはじめた人にとって、とても刺激的な本です。

私もショックを受け、方向転換を迫られています。でもそれがより楽しいことのように感じています。

第一のショックは、

『致命的な仮説：「事業の中心となる専門的な能力があれば、事業を経営する能力は十分に備わっている」』

が、間違いであること。

人の中には、

「起業家」未来の世界に住む革新者、戦略家
「マネジャー」過去に住む管理が得意な現実主義者
「職人」現在に生きる、手に職をもった個人主義者

の3つの人格があって、職人は決して主導権を持つべきではない。

起業家の視点と職人の視点との違いは

・起業家は「事業が成功するにはどうするべきか？」を考え、職人は「何の仕事をするべきか？」を考えている。
・起業家にとって、会社とは顧客に価値を提供する場所である。その結果、利益がもたらされる。職人にとって、会社とは自己満足のために好きな仕事をする場所である。その結果として、収入がもたらされる。
・起業家は自分の描く将来像から逆算して現在の自分の姿を決めるが、職人は現在の自分を基準に将来の自分の姿を決めてしまう。

これも結構ショックでした。でも本当に自己満足のために仕事をしていたかも・・・。

続いて成功へのカギですが、

「事業のパッケージ化」収益を生み出す事業を定型化して、パッケージにする。

「商品」の代わりに「事業」を売る

誰が始めても失敗しないような事業モデルを作る

そこで事業については、

他の人に任せてもうまくいくような事業をつくろう。
どこでも誰でも、同じ結果が出せるような事業の試作モデルをつくるところからはじめよう。
事業とは、あなたとは別の独立した存在だ。それはあなたの努力の成果であり、特定の顧客のニーズを満たす機会であり、あなたの人生をより豊かにする手段である。
事業とは、多くの部品から構成されたシステムであり、ライバルとは明確に差別化されたものであり、顧客の問題を解決するものである。

事業発展プログラム
(1)イノベーション（革新） 創造との違いは実行するかどうか。レイ･クロックはイノベーションの対象を商品ではなく、その売り方であると考えた。
(2)数値化 イノベーションの効果を測定するための数値の把握
(3)マニュアル化 商品やサービスの質を安定させるため。現場レベルの裁量の自由を否定。

7つのステップ
(1)事業の究極の目標を設定する
(2)戦略的目標を設定する 基準----売上、取り組む価値はあるのか？等。
(3)組織戦略を考える 個人に依存した組織には限界がある----仕事の役割分担を明確にする（組織図を作る）
(4)マネジメント戦略を考える 管理システムがポイント
(5)人材戦略を考える 事業とはゲームである----自分でもやりたくないゲームを従業員に押し付けてはいけない----ゲームは長い間、楽しめなければならない----ゲームに意味を与える
(6)マーケティング戦略を考える 顧客の属性分析と心理分析
(7)システム戦略を考える ハードシステム、ソフトシステム（例えば販売管理システム）、情報システム

他に心に残った言葉として、

「オーナーは、事業とは自分を鍛錬する道場のようなものだと考えています。道場での戦いは、敵との戦いではなく、自分自身との内面的な戦いなのです」

「道場とは、宇宙の縮図である。私たちは道場で、自分自身と向き合うことになる。道場とは、閉ざされた戦いの空間である。しかし、対戦相手を敵と考えてはいけない。対戦相手は自分を理解するためのパートナーなのである。道場とは、己を知り、人生の難題への対処方法を学ぶ場である。武道で身に付けた集中力と自制心は日常生活にも生かせるのだ。また道場では、絶えず新しい試みが求められる。それゆえ、道場は学習の場でもある。禅の世界では、これを自己啓発の源と呼んでいる。」

「聞いたことは忘れてしまうが、見たものは記憶に残る。しかし、自ら実践しないかぎりは、何も理解することはできない。」

「買いたい心」に火をつけろ！

顧客を引きつけるための法則集。各法則は、1文か2文からなり、1ページから2ページの解説がついている。
「ビジネスの発火点を探せ」「コミュニケーションはすっきりと」「魅力的なメッセージで語れ」「『刺さる』ブランドで勝負！」「絆を深めるサービスとは？」「顧客に愛される秘訣とは？」の6章からなる。どんな業種であっても、どこから読んでも役に立つと思います。

・「『顧客のハートに火をつけるには、どうすればよいか』と、常に質問し続けよう。自分の胸に、何度も、いつでも。」
・「いつも『わが社を潰しにかかるには、どうすればよいか』を自問しよう」
・「リサーチなど信用しないことだ・顧客のハートに火をつける方法を、リサーチが教えてくれるはずがない。」
・「価格を売るのは最後の最後」
・「専門分野を見きわめよう。ブランドがとんがる狭い一点を。」
・「時間が鍵、顧客に対し、手間暇かけよう。」
・「３、２４、５、魔法の数字だ。しっかり励もう。」（最初の3秒の印象、顧客に接触した後の24時間以内のフォロー、顧客訪問の5日後の礼状）
・「『貸しすぎ』よう」

スモールビジネス　マネジメント

スランプになると読み返す本があります。デブラ・クーンツ・トラベルソの「スモールビジネス マネジメント」（翔泳社）です。
スモールビジネスが大企業と渡り合うための、細部にこだわった、いくらか裏技的な内容の本です。

会社名（屋号）の決め方から、立地条件、パートナーの選び方、人脈の作り方から電話のかけ方まで多岐にわたります。
例えば電話については、
「こと電話と周辺機器、それにまつわるサービスに関しては、お金に糸目をつけてはならない。できる限りベストの（そして、一般的にいって最も高価な）システムやサービスを手に入れよう。」と、言い、
大企業と渡り合うための裏技的なものが多いのですが、例えば一人しかいなくても総合受付のメッセージを作る（総合受付は１のボタンを、担当者がお分かりの場合には担当者氏名の最初の文字を押してください）、とかバックグランドにオフィスの効果音を流すとか・・・、といった具合です。

ただしビジネス内容については、読者がユニークなサービス・商品を持っていることが前提となっていて著者は教えてくれません。ただしニッチを見つけるヒントはくれます。
全て著者と知人の経験に基づいたもので理論的なものではありません。ちりばめられた経験談は日本とは事情が違うかもしれませんが、説得力があり、元気付けられるものばかりです。

何回読んでも得るところがあり、読むたびに初心に帰らされる本です。私はSOHOを始める人に1冊だけ勧めるとしたら、この本を薦めます。
最後にデブラはこう言って締めくくります。

「でっかい相手をぶっ飛ばそうとするあなたの努力に幸いあれ。」

知能販のプロになれ！

トム･ピーターズの挑発シリーズ第3弾。「あの仕事は、あの人しかいない」といわれるように自分をブランドにし、「すごい」ことがわかるお客さんといっしょに、全ての仕事を、「すごい」プロジェクトに変えよう！

・「うちの会社がやっていることは２つしかない。お客さんに尽くすこと、人材を育てること、その２つだけだ」デービッド・オグルビー
・国防総省に勤めていたころ、私は報告書の書式を変える仕事を仰せつかった（ちなみに、それは殆ど誰も読まない報告書だった）。その（つまらない）仕事を真剣にやってみようと思い、その仕事に全力投球した。一年後、数多くの野外演習が、基本的に、私が書式を変えた報告書によって査定されることになった。教訓一、つまらない報告書の書式変更が、すごいプロジェクトになった。教訓二、精魂を込めれば、すごいプロジェクトにならないものはない。どんなつまらない仕事も、やり方次第でものすごいインパクトをもつ。
・「小さい役はない。あるのは、小さい役者だけ」

・購買部だろうがナニ部だろうが、ナイキやマッキンッゼーやアーサーアンダーセンに負けないくらい、カッコよくなるべきである。カッコよくなって、なぜいけない？
・プロというのは、素人にはできない芸当をやり、署名入りの仕事をし、自分のポジションを意識し、自分らしさ（アイデンティティー）を失わないことだ。

・どれだけ型破りの仕事をやったか。クレージーな時代に、どれだけクレージーなことをやったか。それが問題だ。時代の要請に応えられない「無難なプロ仕事」を、私はなによりも軽蔑している。無難にやるか、あぶないことをやるか、それが私の価値判断基準である。すべてにして、肝心かなめのもの、それは挑発だ！

・何も学ばずに日々を過ごせるほど、人生は長くない。

１．誰もかれもが、何かで有名になろう。「あの仕事は、あの人しかいない」と言われるようになろう。
２．プロである以上、自分の名前がブランドである（少なくとも、ブランドになる過程にある）。
３．自分は個人事業主であり（たった一人の企業のCEOであり）、いまはたまたま○○部に頼まれて仕事をしていると考えよう。
４．全員がリニューアルに本気で取り組まざるをえないように、人間として、プロとして、日々成長したいと言う強い願望を持ち、リニューアルが強迫観念になるように、プレッシャーをかけよう。
・ホワイトカラー革命で、無芸徒食の「労働者」は粛清され、一芸に秀でたプロフェッショナルには「我が世の春」が来る。人事部や情報システム部や総務部で、憂き世の勤めをする人たちの中には「そんなことは初耳だ」といって驚く人もいるかもしれないが、コックや大学教授や俳優や歌手や医師やフットボール選手や庭師に聞いてみれば、「なにをいまさら」といって一蹴されるだろう。もう、会社人間に出番はない。サラリーマン根性を捨てよう。

セクシープロジェクトで差をつけろ！

トム･ピーターズのシリーズ第2弾。原題は「全ての仕事を、すごいプロジェクトに変える５０の方法！」。

・人事部長は、社員を一人前のプロに育て上げる責任がある。その責任をまっとうするならば、その人事部長は、デンバー・ブロンコスのQB、ジョン・エルウェイよりもカッコいい。
・シリコンバレーはなぜ、ここまで栄えたのか。それは、シリコンバレーにシラケ鳥は飛んでいないからだ。多くの「従業員」が、使命感に燃え、自分が作る製品を心から愛し、世界を変えるプロジェクトに夢中になっているからだ（決してストックオプションのためではない）。
・「すごい」という言葉自体にすごいパワーがある。、「しかし、この程度のすごさでいいんだろうか」「どんなことをやれば”すごい”といってもらえますか」
・フォーチュン誌のアンケート調査の結果、リスクを最小限に抑え、命令系統を尊重し、上司の顔色をうかがい、予算を重視するするのが、尊敬されない企業に共通した特徴だという。
・小さな問題はない。背後に大きな問題が隠れている。例えば残業規定の改訂の仕事は企業文化を変えるという大きな仕事の第一歩である。
・小さなプロジェクトにも企業のDNAが組み込まれている。ビッグ・プロジェクトのほうが成功する確率は低い。小さなプロジェクトなら、警報を鳴らすことなく、大きな改革を進めやすい。
・成功するものは、つまらない仕事に目を輝かせる。つまらない仕事は、かなり自由がきくからだ。誰も気にしない。誰も見ていない。だから、やりたいことができる。自分で直接、手を下せる。間違いを犯せる。危険を冒せる。そして、奇跡を起こせる！
・「権限のない人」は、自分にそんな「自由」は与えられていないと嘆く。これは、自分は「能なし」だといっているに等しい。「自由」はいつもそこにある。ほとんどの人がそれを使おうとしないだけなのだ。
・飢えていると、創造力が研ぎ澄まされる。贅沢が許されないと、大事なことだけに力を集中できる。お金があると、動きが鈍くなり、昼食の時間が長くなり、現場に足を運ばなくなる。
・『プロジェクト管理のエクセレンス』という本を読んでいると、あくびが出てくる。プロジェクト管理とは、これほど眠くなるものなのか。私は、プロジェクト管理とは、胸がどきどきわくわくし、鳥肌が立ち、髪が逆立ち、血が騒ぐ、カッコいいものだと思っている。
・プロジェクトの実行段階では、「試作に狂う」ことほどカッコいいことはない。テスト→フィードバック→修正のサイクルが目が回るほど速く回転していくのが、すごいプロジェクトなのだ。
・「成功にも失敗にも等しく報いる。罰するのは怠慢だけだ」---デービッド・ケリー
・「構えて撃ってから狙え」---ロス・ペロー
・CNNやロッキードで採用された「会議は最長15分ルール」は超おすすめ。15分しかなければ15分で話し合ってしまうもの。
・電光石火の試作は電光石火の失敗を生む。電光石火の失敗は、電光石火の修正をもたらし、電光石火の修正は電光石火の成功をもたらす。大企業のほとんどに、電光石火の失敗も修正も成功もない。

ブランド人になれ！

チャンス到来、大ブレイクせよ！君はグッとくる人になれるか
TBSブリタニカ(2000)
ビジネス
トム・ピーターズ
★★★★★

ホワイトカラーを元気付けるための本だが、とにかく元気付けられモチベーションが上がる。トム・ピーターズはアジテーションが実にうまい。これに味をしめたら「セクシープロジェクトで差をつけろ！」「知能販のプロになれ！」「経営創造」「経営破壊」もどうぞ。くじけそうになったらトム･ピーターズを読もう！
ブランド人とは誰にも頼らず自分の力で生きていける人、ひとめで違いがわかるもの、お客さんの期待を裏切らないもの、人の心を癒すもの、グッとくるもの。ホワイトカラーはブランドになるか、お払い箱になるか、どちらかである。
私の独立を後押ししてくれた本でもあり、最初に読んだ当時を思い出すと胸が熱くなる。仁平和夫氏の訳がまた最高にすばらしい。次の文章に私は感動してしまった。（仕事場に額に入れて飾ってあります）

人間いたるところに青山あり。いたるところにステージあり。
会社は、あなたがすごいことをやる手段であって、その逆ではない。
ブランド人になろうと思えば、仕事はきつくなるだろうか。当たり前さ。会社のために働いていたときよりはるかにきつくなる。
人事部の、総務部の、経理部の中田英寿が誕生して何が悪い。
あなたがいま立っているところ、そこがあなたのステージだ。さあ、力の限りを尽くして、ひとさし舞ってみろ。あなたのステージを、みんなが見ている。誰も見ていなくても、天が見ている。

私が感心したところを要約します。

・これは革命である。ホワイトカラーの9割以上が、今後10年から15年以内に消え失せるか、全く姿を変えるだろう。要するに、自分の才覚だけで生きるしかない。新しい時代とは「ルールのない乱闘」のことだ。
・会社勤めを続けるとしても、個人事業主のように考え、行動しよう。個人事業主の売り物は、自分の実績と自分のプロジェクトしかない。
・自分は何を大切にしているのか。名人芸。人間としての成長。ひととは違うこと。しびれるようなプロジェクト。自主独立。自己管理。
・やってみよう（演習）本日の予定表の中に、すごくないものがあれば、選択肢は次の2つしかない。(1)それをすごいものに変える。(2)予定を白紙に戻す。
・やってみよう。「すげえ」と心の底から叫びたくなるまで、「そこまでやるかあ」とひとに言われるまで、プロジェクトを練り直す。
・いつも同じ人と付き合い、いつも同じ雑誌を読み、いつも同じ会議に出ているようでは、目は見えなくなり、耳も聞こえなくなる。体も頭脳も退化する。ブランドを磨くためには、外界の刺激や衝撃をどこまで受けるかによって決まってくる。
・「よしよし、うまく行っている。このまま同じことを続けて、目先だけちょっと変えればいい。そんなことを考えていると、自分が自分のパロディになってしまう危険がある」キース・オルバーマン
・人はだれしも、心のどこかに陰をもち、悩みを抱え、重荷を背負って生きている。問題は、それをどうコントロールするかだ。人はだれしも、希望と才能と元気を神様から授かっている。問題は、それをどう引き出すかだ。
・問題と争点と行動のいちばん近くにいて、「風雪が皺に刻まれた連中」がいちばん知恵を持っている。ブランド人を目指すなら現場に向かって走れ！
・ブランド人は会社を頼らず、自分の腕を頼りに、輝く個性を頼りに、同志のネットワークを頼りに、プロジェクト（すごいプロジェクト）を頼りに、成長を頼りに、生きる。
・商品（うりもの）なくして、ブランドはなく、マーケティングなくして、ブランドはない。あなたの商品は何か？

まず、ルールを破れ

原題はもっと過激で、「まず、全てのルールを破れ」。ギャラップが２５年に渡って１００万人以上の従業員にインタビューした結果をベースに調査・統計的分析により、結論付けた優秀なマネージャの考え方。説得力のある論旨である。トム・ピーターズのブランド人やワインバーグの触媒の考え方を裏付けている。短所を直そうとするよりも長所を伸ばすことに力をいれるべきだという私の持論も支持してくれた。
印象に残った部分を要約する。

・「働きたいと思う企業ベスト１００社」といような調査が行われると、その基準は「福祉施設」「休暇」「利益の分配措置」「従業員教育」等であるが、それらよりもはるかに重要なことは、すぐ上のマネージャがどういう人物か、である。
・人はそんなに変わりようがない。足りないものを植えつけようとして時間を無駄にするな。そのなかにあるものを引き出す努力をしろ。
・一般的な間違った考え方-経験や知識、意志の強さをもとにして人を選び、正しい手順を定めることで、要求を設定し、弱点を克服するよう動機付けをし、昇進できるよう手助けする。
・すぐれたマネジャーは才能で人を選び、成果を適切に定義し、部下の強みを活かすことに専念し、部下の強みに適した場所を探り当てる。
・経験よりも、知識よりも、そして意志の強さよりも、すべての職務で最高の能力を発揮するために不可欠なのが、それに適した才能以外にはない。
・技能と知識の利点は、それが伝達可能なことであり、限界は、教えられた以外の局面でどう行動したらよいかわからない点である。才能に力があるのは状況への応用が効くからだ。
・「唯一最高の方法」の押しつけは、第一に、効果がない。個人一人ひとりが持っている独自の４車線道路（成長期に形成され、特に強化された脳の回路）と戦わなければならない。第二に、人の品位を傷つける。第三に、学習を阻害する。
・失敗を研究したところで優秀さについてたいしたことは学べない。間違った方法をなくすことによって、正しい方法を見つけ出す力が身につくというわけではない。優秀さは失敗の反対ではないからだ。
・「あなたの部下で才能のある人が遅刻の常習犯だとします。その部下にどんな注意をしますか」-答えは「その理由を聞く」
・従業員を生産的な人材に「変える」ことができるマネジャーはいない。マネジャーは触媒だ。つまり従業員の才能と顧客／会社の要求との相互反応を加速させることのできる存在だ。