2007年9月アーカイブ
Quality Software Management Volume4 Anticipating Change
Gerald M. Weinberg
Ｇ．Ｍ．ワインバーグ
大野�僅� 監訳
共立出版株式会社(2000)
この本は会社員時代に、ワインバーグに心酔していた時期に購入し、途中まで読んで、数年間そのままになっていたものです。
原題は、ソフトウェア品質管理 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章 技術を導入する
必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。
ＩＶ エピローグ
誰もが自分の運命を自分なりのやり方でまっとうしようとしており、親切で寛大で忍耐強くある以外に、誰しもそれを手伝うことはできない。---ヘンリー・ミラー
「ソフトウエア見積もり」−人月の暗黙知を解き明かす
Software Estimation:Demystifying the Black Art
Steve McConnell
田沢 恵、溝口 真理子 訳
久手堅 憲之 監修
日経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)
★★★★
「そこには莫大な量の試行錯誤が存在している。・・・・・・観察と理論を行きつ戻りつすることになるのだ。理論を持たずして何を探すべきかを知ることはできず、事実を観察せずして理論を確認することはできないのだ。・・・・・・たった一つのことを探求する過程で数千回、あるいは数百万回にも及ぶ試行錯誤が存在していると私は確信している。」----ジョシュア・レダバーグ（ノーベル賞受賞者、1958年）
「大逆転」
コンチネンタル航空−奇跡の復活
ゴードン・ベスーン／スコット・ヒューラー
日経BP社(1998)
FROM WORST TO FIRST(1998)
非常に面白い本である。帯からの言葉を引用してみよう。「憎み合う労使。乗客からは罵声の嵐。三度目の倒産の危機。リストラに怯える日々。こんなボロボロの会社を救おうと1人の男が立ち上がった。」立ち上がったのは、危機を救おうと強引にCEOになったゴードン・ベスーンである。この本はリーダーシップとは何かを教えてくれると同時に、私がいつも言っている「測定していないことは制御できない」の見本のような応用である。全てのリーダに薦めたい。
以下、抜粋である。
いままでのボスとは違う
私はこの十年間で十人目のCEOであり、次々と去っていった九人はいずれも、従業員をだまし、従業員から金を奪い、経営の失敗を従業員のせいにし、従業員に対してやってはいけないことをやり尽くしてきた。私は前の九人とは違うといっても、従業員がそう簡単に信じてくれるはずがない。従業員は馬鹿じゃない。見るところをちゃんと見ている。これまで何回もCEOは代わったが、いっこうに代わりばえがしなかった。トップが代わったぐらいで、ふらふらしている会社が急に元気になるはずがない。私も前の九人と同類だと、従業員は思っているに違いない。従業員からは、いやになるほど冷たい視線を浴びた。しかし考えてみれば、経験から学び、学んだことを生かして環境に適応していけるのは、いい従業員である。だから、コンチネンタルには、いい従業員が揃っていたのである。季節が巡るように経営陣が代わるコンチネンタルの環境に、みんな実によく適応していたのだから。
リーダーシップとチームワーク
象をどうやって食べればいいか。これは昔からある難問だが、答えはこうだ。一口ずつ食べる。だから、まずはがぶりと噛みつくしかない。食べはじめれば、食べる速度はどんどん上がる。
口先だけでなく実行
すばらしいアイデアはどこにでも転がっている。人並み以上に頭を使う人なら、実際にやっていることより、やりたいことのほうが多いはずだ。私だって、あなただって、アイデアはいくらでもある。仕事をしている世界中の人がそうだろう。コンチネンタルが息を吹き返すきっかけになったアイデアは、私が入社する前から、会社の中に息づいていた。いいアイデアを実際にどう生かすかが問題だったのだ。
フットボールを考えてみよう。得点を多く入れたほうが勝ちだということは、誰でも知っている。そして、ゴールラインの向こうに球を運べば得点になることを、誰でも知っている。しかし、知っているだけでは点は入らない。大事なのは、得点をあげるために選手一人ひとりが何をすべきかを考え、しっかりした作戦を立て、それを実行できる力をつけることだ。もちろん、選手のモチベーションをどう高めていくかも大きな問題だ。
お客さんの叛乱
だから私は言いたい。お客さんが欲しいと思うものを、お客さんに教えてやろうと思うなと。
ＣＡＬライトは、発想が逆だった。どんなものが売れたらすばらしいかと考えることから生まれた商品だった。全席エコノミークラス、機内食なし、フライトは二時間半以内という構想が成功すれば、大きな問題を解決できるはずだった。苦戦している市場で突破口が見つかり、収益が上向くはずだった。しかし、いくら商品を売ろうとしても、その商品がいくら立派でも、お客さんが買ってくれなければどうしようもない。
結局、お客さんを追い払うことになり、利益が出るどころか、損失が膨らんでいった。
お客さんが行きたいところに、飛行機を飛ばす
コンチネンタルは取るに足らない市場でビッグ・プレーヤーになった。一部の人が重要と考える市場シェアで他社を寄せつけなかった。グリーンズボロ−グリーンビル線の市場シェアは、九十パーセントにも達していた。飛行機を飛ばせば飛ばすほど赤字は増えていったが、そんなことは問題ではなかった。ビジネス･スクールの卒業生は、市場シェアだけを気にしていたのだから。
グリーンズボロ−グリーンビル線を見ればわかるように、問題は市場シェアではない。どうやって利益をあげるかである。（評者注：サウスウエストのハーブ・ケレハーもまったく同じことを言っている。）
破産裁判所は会社を救ってくれない
愚行とは、同じことを何度も同じやり方で繰り返し、違う結果を期待することである、という定義がある。さて、この定義がコンチネンタルに当てはまるかどうか考えてみよう。一九九三年、更生手続きを終了して再スタートを切ったとき、コンチネンタルは盛大にパーティーを催して、浮かれ騒いだ。「バンザーイ。俺たちは破産しなかった。カンパーイ。」
そう、そのときは破産しなかった。破産しなかったから、問題が片づかなかった。だからこそ、グレッグが帳簿を洗いざらい調べたとき、私たちは破産の一歩手前にいたのである。破産裁判所は会社を救ってはくれない。延命処置はとってくれるかもしれないが、救ってはくれない。会社の人間にしか、会社は救えないのである。
何が起こっているか
財務の健全性を保つ秘訣は簡単である。いま何が起こっているかを知ること−−−それが第一歩。そして、起こっていることと知ることの時間差が縮まっていくほど、病気になる危険から遠ざかっていく。だから私たちは、財務に関して起こっていることすべてを、できるだけ早く把握するために、時間をかけ、お金をかけて、人を揃え、システムを整備したのである。
野球ではよく「ボールから目を離すな」という。私たちにとって、ボールというのは現金収支だった。現金を使い切ったら、ゲームは終わる（私たちはそのことを痛いほど思い知った）。お金はいま、いくらあるか、どこにあるか、昨日と比べ、先週と比べて、お金は増えているか、減っているか。そういう単純なことがすぐに正確にわからないようなら、経理の人間など会社にはいらない。
信頼性を現実に−−エアラインの本来の仕事を思い出す
谷底で死傷者を待つ救急車の話をしよう。
山の中腹に小さな町があり、麓からの道は曲がりくねっている。おそろしく危険なヘアピンカーブがあり、そこでは月に一台の割合で、車が谷底に転落している。
町議会はこの問題を放置するわけには行かず、道路のカーブを緩くし、注意を呼びかける標識を立て、ガードレールを設置するには、どれぐらいの予算が必要かを検討した。試算した結果、大変なお金がかかることがわかった。町の財政ではどうしようもない金額だった。しかし、車は毎月崖から落ち、死傷者があとを絶たない。なんとかしなければならない。そこで、もっと安上がりな方法を思いついた。
谷底に救急車を待機させることにしたのだ。
問題の解決を回避するために、人がいかに馬鹿馬鹿しいことを考えつくかという、お手本のような話である。私が入る前のコンチネンタル航空は、この手の発想が習い性になっていた。問題を解決するには、お金がかかりすぎる。だから、問題は解決できない、という考え方である。
恐れ入ったとはこのことだ。問題解決にはどれくらいのコストがかかるかを考える時には、別の問題も考えたほうがいい。道路を直すには、たしかに大変なコストがかかる。しかし、道路を直さなかった場合のコストはどう考えるのか。
上からの助け
それなら経営陣は遊んでいて、手柄だけ横取りするつもりなのか。
違う。経営陣の仕事は単純なものだと、私は思う。仕事ができる人間を雇い、必要な訓練を行い、必要な資源と支援を与えたら、あとは邪魔にならないようにそこをどく−−−それが経営陣の仕事だ。従業員が何か問題を抱えていたら、従業員が自分の仕事に集中できるよう、その問題の処理はこちらに任せろという。簡単にいえば、従業員にいい仕事をしてもらうために全力を尽くすのが、経営者の仕事である。
企業は人
会社の経営で直面する問題というのはすべて、人間の問題である。資金の問題、信頼性の問題、マーケティングの問題、どんな問題であろうと、正しいことをやらない人間がいるから問題が起こる。間違ったことをやるように、上司が指示している場合もあれば、問題を指摘すると厄介なことに巻き込まれると従業員が思っている場合もあるだろう。あるいは、無能な経営陣に愛想がつきて、従業員が問題解決の意欲を失っている場合もあるかもしれない。
いずれにせよ、仕事をするのは人間であり、人間が集まって会社ができている。だから、会社の中で発生する問題はすべて、その根っこを探していくと、人間に突き当たる。
企業文化の見直し
しかし、問題を解決しようとするとき、木を見て、森を見ない経営者、人間を見ることを忘れている経営者が多いように思う。つまり、従業員からどれだけ搾り取れるか、従業員をどれだけ効率的に使えるかを考える経営者は多いが、従業員が毎日どんな気持ちで出社してくるかを考える経営者は少ない。
「前進プラン」が軌道に乗るまで、コンチネンタルの従業員は毎朝、こう思いながら家を出ていた。何時に帰れるかはわからない（コンチネンタル機はひとたび飛び立てば、いつ、どこに着くかさっぱりわからなかったからだ）。きょうもまた、乗客にさんざん怒鳴られて、なすすべもなく、じっと我慢しなければいけない。やる気をなくした不機嫌な同僚と、また一日中、一緒に仕事をしなければいけない。そう思うと、仕事に向かう足取りは重かった。私はそれを知って、胸が痛んだ。そういう従業員を責めることはできない。だから、なによりもまず、毎朝、仕事に向かう足取りが少しでも軽くなる職場に、コンチネンタルを変えなくてはいけないと思った。
評論はしないが、注意は払う
みんなで力を合わせるということは、みんなで仲良く飲んで騒ぐことではないし、みんなにやさしくすることではないし、成り行きにまかせることでもない。ポイントは、一日中つきっきりであれこれ指示せず、あとでとやかく言わず、従業員を信頼して、現場の判断は現場に任せることにある。
結果を絶えず測定する
ポイントは、結果の測定をやめないことだ。会社がいまどこにいるかを教えてくれるデータはいくらでもある。大事なのは、そのデータから目を離さず、データが教えてくれることを信じることだ。
たった一言のアドバイス
友だちから、こんな話を聞いたことがある。いまは練達のハイカーだが、バックパック一つで初めて旅に出るときは、やはり不安だった。パッキングをしていると、次から次へと悪いことが頭をよぎる。それで、後悔しないよう、準備には万全を期すことにした。・・・しかし、世の中、すべてが計画とおりに行くとは限らず、一週間の道中で何が起こるかはわからない。それで、パーティーのリーダーを質問攻めにした。
リーダーははじめ、丁寧に答えていった。食料は余分に持っていくし、ひとりが足りなくなっても、みんなで分け合えばいい・・・・・・。寝袋が濡れたら、乾かせばいい・・・・・・。テントが破れたら、繕えばいい・・・・・・。ところがだんだんうんざりしてきて、しまいにはため息をついて、何も言わなくなった。そして、しばらく考えてから、次に言うアドバイスさえ守れば、必ず目的地にたどり着けるといった。
友人は息をのんで、そのアドバイスを待った。すべての問題を解決してくれる魔法のごときアドバイスを。
リーダーは言った。「止まるな」
アドバイスはたったこれだけだった。成功を続けたいと思うなら、成功するまでやっていたことを止めてはいけない。これは難しい。難しいが、それなしで成功の継続はありえない。
勝利にリーダーは不可欠
ポイントはこうだ。コーチは選手に何をして欲しいかを考えると同時に、どうすればそれをやってもらえるかを考えなければいけない。相手は血が通う人間であり、業務命令の紙ではない。コーチが試合に出て、選手の代わりにプレーすることはできない。パスもできなければ、ブロックもできない。コーチの仕事は何か。それは、選手にプレーさせることである。それを忘れてはいけない。
何のためのコミュニケーションか？
もちろん、それで終わりではない。そういうシステムが整ったあとも、従業員が情報を得やすい方法で、従業員が理解しやすい言葉で、すべてのことについて、コミュニケーションを図らなければいけない。何をすべきか従業員がわかっていないとしたら、それをやらなかったからといって、従業員を叱る資格は経営者にはない。経営者がある日、会社の目標を思いつき、退屈な幹部会議でその目標達成を指示し、あとは何もやらなかったら、従業員が目標達成のために何をやればいいのかわからなくても当然である。
目標と評価基準を明確にする
株主資本利益率などといった空虚な目標を掲げている会社は多い。こんな会社の経営者にぜひ、お聞きしたい。現場で働いている人たちが、株主資本利益率についてどう考えているというのか。たぶん、それが何を意味するのかさえ知らない人がほとんどだろう。わけのわからないものが目標になっているなら、努力のしようがない。会社の目標に自分はどう貢献できるのか、自分の仕事が業績にどう影響するのかを知っていなければ、仕事に熱は入らない。私たちが定時運行を目標に掲げ、オペレーションのあらゆる努力をその一点に集中しているのはそのためだ。定時運行の意味がわからない人はいないし、努力の結果は、定時到着率という数字になってはっきり現れる。だから何か新しいことをやろうという話が出たとき、問いかけることはただひとつ。定時運行にプラスになるかどうかだけである。
目標は達成可能なものでなければならない
目標は夢物語とは違う。達成が不可能なことを目標に掲げれば、従業員はしらけるだけである。逆に、現実的に目標を明確にすると、びっくりするような成果が出てくる。
コンチネンタルが定時運行のボーナスを出すようになると、雨後の筍のようにそれを真似する航空会社が出てきた。しかし、どこもコンチネンタルのようにはうまくいかなかった。なぜ？基本的なことを何もやらず−−整備の人間もまじえて運行ダイヤを考えることもせず、新しい仕事のやり方を従業員に説明することもなく、仕事に必要な道具を従業員に与えることもせず−−目標とボーナスを決めただけだったからだ。
誰の手柄か
前にも言ったように、多くの会社が犯しやすい間違いは二つある。ひとつは、間違ったことを測定すること。もうひとつは、正しいことを測定しながら、間違った人に報いることだ。
マイクロソフト シークレット （下）
マイケル・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の小冊子です。
その「デザイン魂」から。
- デザイン 新時代の企業の「魂」
- 「美しさや優雅さへの熱い思いが、コンピュータ時代の歴史における最も重要な発見を裏づけてみせた・・・論理的立証や機械の美しさは、簡潔さと才能の幸せな結婚に宿る・・・美しさは複雑さに対抗する最高の防衛手段・・・できるプログラマーは、凡百のプログラマーよりも百倍生産性が高い・・・この差は、技術、数学、あるいは設計の教育トレーニングとはほとんど関係がない。大いに関係があるのは、眼識、優れた見識、持って生まれた美意識だ」デビッド・ゲランター。
- 「美しさや優雅さへの熱い思いが、コンピュータ時代の歴史における最も重要な発見を裏づけてみせた・・・論理的立証や機械の美しさは、簡潔さと才能の幸せな結婚に宿る・・・美しさは複雑さに対抗する最高の防衛手段・・・できるプログラマーは、凡百のプログラマーよりも百倍生産性が高い・・・この差は、技術、数学、あるいは設計の教育トレーニングとはほとんど関係がない。大いに関係があるのは、眼識、優れた見識、持って生まれた美意識だ」デビッド・ゲランター。
- デザインの効用 美しいシステム
- 「何年も前に、ウォルマートは社員コンテストを始めた。あらゆる種類の賞品や景品を山のように積み上げた。その目的は、社員の全員が参加して『自分たちが社内で行っている最もバカげた行為』を見つけ出すことだった。
率直に言えば、この方が”社内提案"システムよりもはるかによいと思う。社内提案システムは、結局（役に立たない）ものの足し算だ。反対に、この制度は引き算にあくまでこだわっている。」
- 「何年も前に、ウォルマートは社員コンテストを始めた。あらゆる種類の賞品や景品を山のように積み上げた。その目的は、社員の全員が参加して『自分たちが社内で行っている最もバカげた行為』を見つけ出すことだった。
- 行動するデザイン 忘れられない経験を与えてくれる
- 経験の一歩先 「夢ビジネス」をものにする。
- かくありたい！
私が想像するのは・・・
かなえられるようになる（それ以上になる）”見果てぬ”夢。
”欠陥ゼロ”の麻薬を排除するだけの「勇気」を持った企業。
”製品”や”サービス”（さえないことばだ、そのうち使う必要もなくなるだろう）の、はるかに、はるかに上を行く、価値の創出。
- 次のブイトーニの言葉を注意深く噛みしめよう。
「夢とは、顧客の人生における完成された瞬間のことだ。顧客に自分の相当な財産を注ぎ込んでもよいという気持ちにさせる、そんな大切な経験のことだ。消費者の欲求の核心。顧客をその本人のなりたいものにしてくれる、そんな機会のことだ」
- 夢のきわみ
本書の卓越したメッセージ。機能にこだわる姿勢は、機能障害を招く。たいていのものは、”機能する”ものだ。全く問題ない。だから問題はこうなる。この”うまく機能する”を超越するものは何か？
興奮。これだ。
驚嘆。これだ。
不可能だと考えられているもの。これだ。
私の主張（繰り返す）。自ら目標のバーを高く上げろ。「もっと上、もっともっと上だ」
デザインを考えよう。あの”美しいシステム”を考えよう。
”製品”そして”サービス”を切り捨てよう。
その代わりにこだわるのは、”経験”だ。”夢”だ。
- 夢を測る尺度：”欠陥ゼロ”の（はるか）先へ
- 「一目惚れ」
- 「五感に訴えかけるデザイン」
- 「『大きな夢』を広げてくれる進歩」
- 「何となく気配でその気にさせるデザイン」
- 「一目惚れ」
- 情熱は情熱を呼ぶ。
総天然色テクニカラー的ことばは、テクニカラー的反応を呼ぶ。
- かくありたい！
- デザインの頂点