2007年9月アーカイブ
必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。
「ワインバーグのシステム変革法」
設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら、あなたは問題を理解していないのだ。
「ワインバーグのシステム変革法」
設計が障害を起こしてしまう環境を三つ考えつかなければ、その設計についてまだ検討が足りないのだ。
「ワインバーグのシステム変革法」
読者があるホテルにいるとしよう。誰かが火事だと叫ぶのを聞く。消火器のところへ走り、警報気を引いて消防署を呼ぶ。全員外に出る。消火活動はホテルを改善しない。それは品質の改善ではない。それは消化なのだ。
「ワインバーグのシステム変革法」
性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす。
「ワインバーグのシステム変革法」
良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。
「ワインバーグのシステム変革法」
「人助けモデル」を銘記せよ：ほとんどの場合、見かけによらずすべての人びとは協力的たろうと心がけている。一般的に、顧客はただソフトウェア品質ダイナミックスを理解していないだけであり、それは読者の専門で彼らの専門ではない。
「ワインバーグのシステム変革法」
結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。
「ワインバーグのシステム変革法」
士気は、プロジェクトの成功確率についての全メンバーによる総合評価と考えることができる。
「ワインバーグのシステム変革法」
ほとんどの遅延プロジェクトは、コーディングがかなり進捗するかもしくはテスト作業が始まるまで、日程通りにいっているように見える。そのとき、早期に行ったあらゆる便法的作業がテスト作業を遅らせて行き詰まり、プロジェクトが頓挫する。欠陥予防あるいはインスペクションを通じて早期に品質管理をしたプロジェクトは、テスト作業を一気に通過する。---ケイパース・ジョーンズ
「ワインバーグのシステム変革法」
おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。
「ワインバーグのシステム変革法」
プロジェクト途中の管理者の仕事の多くは、不測の事態に対処するために一種類のスラック（余裕）を他の種類のスラックと交換することなのだ。
「ワインバーグのシステム変革法」
計画は、敵の最初の一手までは有効である。----チェスの格言/軍事の格言
「ワインバーグのシステム変革法」
管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として、非難文化において愛好されている。
「ワインバーグのシステム変革法」
問題はしばしば、明確化に対する組織の恐怖に根ざしている。顧客は明確な要求定義を文書化すると、文書化した要件を満たすシステムが現実の必要を満たさなくなる場合、変更を発案した責任を負わなければならなくなる。開発者のほうは明確な要件を文書化すると、それを満たす説明責任を負わなければならなくなる。コストとスケジュールの見積りが不正確だとわかってしまうと、自らをリスクにさらす可能性がある。したがって。顧客と開発者は正反対の動機で動いているにしても、暗黙のうちに共謀して、「成熟度モデル」の要件管理慣行の履行を阻止しかねない。
「ワインバーグのシステム変革法」
プロジェクトを制約する意思決定につながる一連の高レベルの交渉が、すべてのプロジェクトに先行している。情報が揃っていてかつ適合的な交渉でなければ、プロジェクトは開始以前から命運が尽きている。
「ワインバーグのシステム変革法」
多くのソフトウェア組織にとって、高品質実現の主要な障害は不十分な要求定義（要件）プロセスである。
「ワインバーグのシステム変革法」
どんな事柄でも不可視になるのを許すな。要件も、設計も、コードも、とくにテストはいけない。予防は治療よりもはるかに容易なのだ。
「ワインバーグのシステム変革法」
統計的プロセス制御は、ソフトウェア制御に適用できないと主張する人々を信用するな。彼らに欠けているのは、そうした制御を適用する正しいレベルととるべき適切な行動である。たとえば、彼らはコードの欠陥を計測するかもしれないが、その情報を設定されたしきい値を満足しない個人を責め苛むために用いるのだ。
「ワインバーグのシステム変革法」
テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。
「ワインバーグのシステム変革法」
ソフトウェア工学管理は一連の選択であって、一連の強制ではない。良いソフトウェア工学管理とは、ベストプラクティス曲線上かその近辺にある。変数間のもっとも望ましい取捨選択（トレードオフ）を表すある地点に留まる能力のことなのである。
「ワインバーグのシステム変革法」
工学とは、ある環境下でできるだけ多くを獲得するアートであるから、欲しいものすべては獲得できないときにこそ行使するものなのだ。工学とは、何かをあきらめる代わりに何を獲得するか、それはなぜかについての意識的な意思決定を意味するのである。
「ワインバーグのシステム変革法」
リスクアセスメントはリスク管理ではなく、リスク管理の第一ステップにすぎない。第二ステップはリスク低減計画作業、すなわち予測不可能な環境下で予測可能な結果を得るための計画作業である。
「ワインバーグのシステム変革法」
あまりにも性急に速く、多くの変革を組織に押しつける管理者は、加速しようとしているまさにその変革を遅らせてしまう。同時に、もし管理者が「多くの変革を試みよ。そうすればそのうちのいくつかは定着するだろう」という戦略を採用すると、最後にはそれらのいずれも定着しないことを思い知らされる。
「ワインバーグのシステム変革法」
システムは、外部要因を無視しようとはするが、まったくは無視しきれない。組織はふつう外部要因を排除して、「いままでの状況」に戻ろうとする。というのも、サティアが言うように、
慣れは、つねに快適さより強力である。
「ワインバーグのシステム変革法」
見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。
「ソフトウエア見積もり」
コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。
「ソフトウエア見積もり」
ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。
「ソフトウエア見積もり」
バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。
「ソフトウエア見積もり」
「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」
「ソフトウエア見積もり」
最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。
「ソフトウエア見積もり」
計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。
「ソフトウエア見積もり」
中規模の業務システムプロジェクト（35,000～10万LOC）では、チームの人数が7人を超えてはならない。
「ソフトウエア見積もり」
スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。
「ソフトウエア見積もり」
スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。
「ソフトウエア見積もり」
適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる。構築中のシステムの規模は、単体として最も大きなコストドライバである。正確に規模を見積もるためには、複数の見積もり技法を使おう。
「ソフトウエア見積もり」
具体的な開発タスクを配分して割り当てる準備ができしだい、ボトムアップ見積りに切り替えよう。
「ソフトウエア見積もり」
まず、規模の見積もりに焦点を合わせよう。次に、工数、スケジュール、コスト、機能を、規模の見積もりから計算しよう。
「ソフトウエア見積もり」
見積りのアウトプットについて議論してはいけない。アウトプットはそのまま受け入れよう。アウトプットを変更してよいのは、インプットに変更があったときか、または再計算した場合だけである。
「ソフトウエア見積もり」
複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は、見積もりの方を信頼しよう。
「ソフトウエア見積もり」
異なる見積もり技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%以内に集中するまで、再見積りしよう。
「ソフトウエア見積もり」
見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積もりの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積もりの価値を下げてしまう。不確実性に最もうまく対処するためには、見積もりから先入観を排除することだ。それと同時に、根底にある不確実性を正確に表現することも必要だ。
「ソフトウエア見積もり」
新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して、できれば5つ以上の部分に分解して見積もろう。
「ソフトウエア見積もり」
最良ケースと最悪ケースの見積もりを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
「ソフトウエア見積もり」
タスクレベルの見積もりを行うときは、長くても2日程度の工数のタスクにまで見積もりを分解する。それより大きいタスクだと、想定外の作業が隠れる場所が多すぎる。見積もりは4分の1日、2分の1日、丸1日といった粒度で行うとよい。
「ソフトウエア見積もり」
タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう。
「ソフトウエア見積もり」
できるだけプロジェクトのデータまたは過去のデータを使用して、見積もりを補正しよう。できれば業界平均データは避けよう。過去のデータを使用して補正すると、より正確な見積もりができるだけでなく、生産性に関する前提の不確実性から生じる見積りのばらつきを減らすことができる。
「ソフトウエア見積もり」
できるときはいつでも、まず数えよう。数えられないときには、計算しよう。判断だけに頼るのは最後の手段だ。
「ソフトウエア見積もり」
見積りにとって重要なことは。完璧なまでに正確であることより、有用な情報を提供することである。
「ソフトウエア見積もり」
見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること。
「ソフトウエア見積もり」
「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう。
「ソフトウエア見積もり」
開発者の見積もりを削ってはいけない。なぜなら、既に十分楽観的すぎるからだ。
「ソフトウエア見積もり」
多くのプロジェクトは、特定の役割を割り当てられた人々から構成されており、これらの人々は自らの守備範囲を超えた（あるいは自らの役割と誰かの役割の隙間にある）ものごとには責任を取ろうとしない場合がほとんどです。しかしより大きな問題は、私たちのほとんどが他者との衝突を避けようとする点にあるのかもしれません。多くの場合、PMは関係者をどれほど不快にしようとも、質問を行い、前提に疑問を投げかけ、真実を追究しなければならないのです（とは言うものの、関係者にできるだけ不快な思いをさせないようにしつつ、これらのことを実践するのがPMの目標となります）。
「アート・オブ・プロジェクトマネジメント」
こういった状況の難しさは、状況それ自体にあるのではなく、その状況が発生しているコンテキストにある場合がほとんどです。問題の発生がプロジェクトの終盤に近づいているほど、チーム（またはPM）の士気が低下し、問題への対処が難しくなっていくのです。プロジェクトが終盤に近づくにつれて、こういった問題を解決するための手段が少なくなっていく上、そのコストも高くなっていくためです。
「アート・オブ・プロジェクトマネジメント」
気をつけるべき最後の点は、結果ありきの調査です。何かを理解しようとすることと、特定のお気に入り理論を裏付けようとすることとの間には、天と地ほどの差があります。
「アート・オブ・プロジェクトマネジメント」
ほとんどの難しい意思決定において、問題となるのは調査やデータの欠如ではありません。どれだけ情報を持っていたとしても、難しい意思決定というものはこの世から無くならないのです。
「アート・オブ・プロジェクトマネジメント」
熟考という行為は、意思決定のツールとしては不当に過小評価されています。熟考とは、いったん立ち止まり、あなたが扱ってきた全ての情報を十分理解することです。本当の理解というものはしばしば、リラックスし、今までに得たすべての情報を脳に処理させる時間を持てた時のみ可能となります。私の場合、ジョギングや散歩といった身体運動が、頭をリラックスさせる最善の方法になっています。
「アート・オブ・プロジェクトマネジメント」
設計作業や仕様書作成作業といったものは楽観的な観点に立ったプロセスであるため、レビューに参加するメンバーは懐疑的な観点に立って、見落としがないかをチェックすることになります。
「アート・オブ・プロジェクトマネジメント」
誰かの作業を誉めたい時には、面と向かって伝えてください。誰かを誉める場合であっても、チーム全体宛の電子メールを使うべきではありません。本人のところに出向くか、電話を使ってください。どんな電子メールよりも短い対話の方が、感情をこめることができるのです。
「アート・オブ・プロジェクトマネジメント」
懸案事項の効果的なマネジメントは、純粋にやる気の問題となります。誰かが問題になりそうなものごとを調査し、それを文書化するために時間を割かなければならないのです。ここには何の仕掛けもありません。いったん文書化されれば、優先順位を付け、誰かに割り当て、解決することができるのです。
「アート・オブ・プロジェクトマネジメント」
とにかく、さまざまな道を考察し、前提の誤りを見つけ出し、新たな疑問を洗い出しながら行きつ戻りつを繰り返すということが、ものごとを設計するということなのです。
「アート・オブ・プロジェクトマネジメント」
技術革新は滅多なことでは起こらない。技術革新は短期的には過大評価され、長期的には過小評価されるものである。顧客という視点をトレンドという一時的流行に対する切り札とするべきである。
「アート・オブ・プロジェクトマネジメント」
おぼえておいてほしいこと---何も学ばずに日々を過ごせるほど、人生は長くない。
「知能販のプロになれ！」
予算管理はいやでもやらざるをえない。それはたしかに必要だが、巷に氾濫するプロジェクト管理の教科書がのたまうごとく、それがすべてではないし、肝心かなめではない。
すべてにして、肝心かなめのもの、それは挑発だ！
「知能販のプロになれ！」
友人（俳優）から聞いたのだが、演劇業界ではこう言われているという。
「小さい役はない。あるのは、小さい役者だけ」
「知能販のプロになれ！」
教訓一、つまらない報告書の書式変更が、すごいプロジェクトになった。教訓二、精魂を込めれば、すごいプロジェクトにならないものはない。どんなつまらない仕事も、やり方次第でものすごいインパクトをもつ。
「知能販のプロになれ！」
広告の神様デービッド・オグルビーはこう言っていた。「うちの会社がやっていることは２つしかない。お客さんに尽くすこと、人材を育てること、その２つだけだ」
私が付け加えることは何もない。
お客さんに尽くす。
人材を育てる。
あなたはこの２つを、プロジェクトを通じてやるしかない（願わくは、すごいプロジェクトでありますように・・・・・・）。
「知能販のプロになれ！」
仕事中も何か困ったことが出てきたら、すぐに「15分会議」を招集して、すぐに問題を解決しよう。宗教の戒律を守るように「最長15分ルール」を守れば、自分でもびっくりするほど仕事がはかどる。
「セクシープロジェクトで差をつけろ！」
毎朝8時、チーム全員が集まって最長15分の会議を開く効果は計り知れない。その日やるべきこと、その日必要になる助け、昨日やらかしたドジなどが鮮明になるからだ。
「セクシープロジェクトで差をつけろ！」
「構えて撃ってから狙え」---ロス・ペロー
「セクシープロジェクトで差をつけろ！」
「成功にも失敗にも等しく報いる。罰するのは怠慢だけだ」---デービッド・ケリー
「セクシープロジェクトで差をつけろ！」
『プロジェクト管理のエクセレンス』という本を読んでいると、あくびが出てくる。プロジェクト管理とは、これほど眠くなるものなのか。どの本を読んでも、似たようなことしか書いていない。みんな、そう思っているのだろうか。私は違う。私は、プロジェクト管理とは、胸がどきどきわくわくし、鳥肌が立ち、髪が逆立ち、血が騒ぐ、カッコいいものだと思っている。
そして、プロジェクトの実行段階では、「試作に狂う」ことほどカッコいいことはない。
「セクシープロジェクトで差をつけろ！」
どんな仕事も、すごい仕事にできる！
まさかと思うなら、あなたは間違ったチャンネルに周波数を合わせている。
成功するものは、つまらない仕事に目を輝かせる。ウソじゃない。
なぜ？ つまらない仕事は、かなり自由がきくからだ。誰も気にしない。誰も見ていない。だから、やりたいことができる。自分で直接、手を下せる。間違いを犯せる。危険を冒せる。そして、奇跡を起こせる！
「セクシープロジェクトで差をつけろ！」
フォーチュン誌は1998年、全世界を対象に「最も尊敬される企業」のアンケート調査を行い、その結果、尊敬される企業と尊敬されない企業の特徴がはっきり出た。同誌によれば、リスクを最小限に抑え、命令系統を尊重し、上司の顔色をうかがい、予算を重視するするのが、尊敬されない企業に共通した特徴だという。
「セクシープロジェクトで差をつけろ！」
「偉大なリーダーなんて必要ない。私たちが一人ひとり、自分の力を信じて、すばらしいことをやればそれでいい」--- セミナー参加者(1998年12月、ワルシャワ）
「セクシープロジェクトで差をつけろ！」
シリコンバレーはなぜ、かくまで栄えたのか。私の見方はこうだ。それは、シリコンバレーにシラケ鳥は飛んでいないからだ。信じられないほど多くの「従業員」が、自分の仕事に精魂を傾けているからだ。使命感に燃え、自分が作る製品を心から愛し、世界を変えるプロジェクトに夢中になっているからだ（ストックオプションがあるから、みんな必死で頑張っているなどと思う人は、自分の魂の腐臭に気がついた方がいい）。
「セクシープロジェクトで差をつけろ！」
問題と争点と行動のいちばん近くにいて、「風雪が皺に刻まれた連中」がいちばん知恵を持っている。そんなことは言われなくてもわかっているって？それならなぜ、宗教的な情熱を持って現場に直行する人間が、かくも少ないのか。 ブランド人を目指すなら現場に向かって走れ！
「ブランド人になれ！」
人は人生の大半を、厚い壁の前で過ごす。どう体当たりしてもびくともしない壁の前で、死にたくなることもあるかもしれない。しかし人は、その壁の前で、本当の力をつけていくのである。
「ブランド人になれ！」
T.H.ホワイトの『永遠の王』の中で、預言者のマーリンはアーサー王にこう言っている。「打ちひしがれたときの一番の妙薬は、何かを学ぶことよ。決して失望せず、心が決して倦まず、さまよわず、恐れや不信や後悔に決して苦しめられることのない唯一のもの、それは何かを学ぶこと」
「ブランド人になれ！」
スポーツキャスターのキース・オルバーマンはこう言っている。「よしよし、うまく行っている。このまま同じことを続けて、目先だけちょっと変えればいい。そんなことを考えていると、自分が自分のパロディになってしまう危険がある」
「ブランド人になれ！」
蛸壺の中でじっとしていれば、目は見えなくなり、耳も聞こえなくなる。体も頭脳も退化する。あなたの人生がどれだけ豊かになるか、どれだけ色彩に富むか、あなたがどれだけ変わり者になれるか、どれだけカッコよくなれるか、どれだけ時代についていけるかは、外界の刺激や衝撃をどこまで受けるかによって決まってくる。
「ブランド人になれ！」
いつも同じ人と付き合い、いつも同じ雑誌を読み、いつも同じ会議に出ているようでは、蛸壺の中で暮らしているのと変わらない。十年一日のごとく暮らしていれば、あなたのブランド力はいっこうに磨かれない。
「ブランド人になれ！」
いつも同じ仲間と昼食を取り、いつも同じ顔ぶれの会議に出席し、いつも手慣れた仕事だけをやるのは実に楽だ。一方、自分とは全く考え方の違う人と付き合い、自分の信念が揺らぐような発想にいつもわが身をさらすことは実にしんどい。
「ブランド人になれ！」
本日の予定表をもう一度じっくりながめてみよう。その中に、すごくないものがあれば、選択肢は次の2つしかない。(1)それをすごいものに変える。(2)予定を白紙に戻す。
「ブランド人になれ！」
改革とはお題目ではない。人々を安全地帯から引っ張り出すことだ。
「ブランド人になれ！」
政治は人生そのもの。全ての人が満足する改革はない。
「ブランド人になれ！」
モデルやコンセプトを持て。「自分の考え」をいつでも言えるようにしておけ。
「ブランド人になれ！」
待っていれば、事態は悪くなるばかり。戦いを起こせ。
「ブランド人になれ！」
許可を求めるのは、「だめだ」と言ってくれと頼むのと同じ。
「ブランド人になれ！」
だれにだって、多少とも変えられるものがある。まず、自分の手が届くところから始めよ。
「ブランド人になれ！」
要員は成功への鍵である。適切な経験と才能を持ち適切なトレーニングを受けたスキルの高い要員が鍵である。ツール、言語、開発プロセスが不十分でも要員が最適なら、プロジェクトは成功するであろう。しかし、ツール、言語、開発プロセスが適切でも要員が不適切なら、プロジェクトはおそらく失敗するであろう。
「ソフトウェア プロジェクト管理」
優れた管理は優れた技術より重要である。最良の技術でもまずい管理の埋め合わせはできないし、逆に優れた管理者なら乏しいリソースでもすばらしい成果を上げることができる。優れた管理なら要員に最善を尽くす気を起こさせるが、すべての場合の当てはまる「正しい」管理のやり方など存在しない。
「ソフトウェア プロジェクト管理」
ライフサイクルのできるだけ初期に機能間のトレードオフ、品質、コスト、スケジュール間のトレードオフを理解しようと試みる。
「ソフトウェア プロジェクト管理」
重大な、あるいは本質的な設計エラーまたはアーキテクチャ上の問題点は、インスペクションの焦点を特定の問題に絞らない限り、表面的なレビューではまず明らかになりません。
「ソフトウェア プロジェクト管理」
ソフトウエア開発の経済的側面のうち重要な事柄の1つは、労力と規模の関係がスケールデメリットを示していると言うことです。…大半の製造プロセスとは逆に、ソフトウエアを作れば作るほど、単価が上昇します。
「ソフトウェア プロジェクト管理」
ウォータフォール型のライフサイクルにおいて発生する致命的な問題点は、早い段階でのりスク解消が行われないということです。
「ソフトウェア プロジェクト管理」
期限が十分先なら－－例えば半年か１年先なら－－だれも、目標の実現が不可能であると言う現実に立ち向かおうとはしない、ということである。
「デスマーチ」
ソフトウエアの品質は、プロジェクトの１つの要因であり、日程やコスト、人員、開発資源のトレードオフを進める上で十分考慮しなければならないと言うことだ。
「デスマーチ」
デスマーチ・プロジェクトが長期にわたると、例えば「優秀な人がだんだんいなくなり、いずれ会社がつぶれる」のように、ネガティブな雰囲気が醸成させるのが普通だ。しかし、この手のデスマーチ・プロジェクトは、なぜ実現不可能なスケジュールや予算を設定したか質問できる雰囲気にはない。
「デスマーチ」
「ヒステリックな楽観主義」とは、これまでに開発経験が無いので、どう見積もっても３年はかかる複雑なシステムなのに、うまく行けば９ヶ月でできるとプロジェクトの全員がやけくそで信じようとする状態を言う。
「デスマーチ」
ある程度、リスク管理担当者は「誠実な野党」である。つまり、その人物とは、（プロジェクト管理者を含む）プロジェクト・チームの全員が、物事がうまくいくと必死に信じようとしているのに、なぜ物事がうまくいかないのかの理由を冷静に識別し、評価し、追跡し、そして体系づける人だからである。
「プログラマーの復権」
真のボトルネックは、プロジェクト管理の革新なのだ。
「プログラマーの復権」
プロジェクトはどうして一年も遅れるようになるのか？・・・一度に一日ずつ。
「人月の神話」
成功のためには、プロジェクトに携わる人々の質、及びその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因である。
「人月の神話」
１日の遅れにもやっきにならなければならない。この程度の遅延こそが、まさに破局の要素なのだ。
「人月の神話」
マイルストーンの決定に関し、関係する規則は一つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの刃のような鋭さを持って定義しなければならないということである。
「人月の神話」
遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ。
「人月の神話」
ソフトウエアを不安定にさせることは、大部分のバグより更に多くの問題を生じさせる。そのため、どのバグを訂正するかについては非常に慎重でなければならない。
「ソフトウェア開発のダイナミズム」
マイルストーンをヒットする可能性が6つのコンポーネントそれぞれについて90パーセントである場合、マイルストーンをヒットする可能性はトータルでは53パーセントでしかない。全てが90パーセント確実だったとしても、このように厳しい状況なのだ。木を見て森を見ずという諺を思い出そう。
「ソフトウェア開発のダイナミズム」
遅れた後は、何がなんでも次のマイルストーンをヒットしろ。
「ソフトウェア開発のダイナミズム」
絶対やっては行けない最悪の愚行は、現在の遅れの日数を見積もり、その日数をスケジュールの終わりに加算することだ。あなたが確信すべき事は随一、この問題をもう一度徹底的に考えてみる必要がある、という事実だけだ。
「ソフトウェア開発のダイナミズム」
遅れは問題ではない。遅れに慌てふためくことが問題なのだ。
「ソフトウェア開発のダイナミズム」
遅れを利用して効率的な対応を促進しよう。遅れそうだという意識が人の目を覚まし、チームは新しい洞察力、フレッシュな情報、もう一つの見方、以前には想像すらしなかった可能性を模索しようとする。
「ソフトウェア開発のダイナミズム」
遅れはモラルの問題ではない。後れは失敗でもなければ非難されるべき事でもない。知的資産を作る作業における避けがたい結末なのだ。
「ソフトウェア開発のダイナミズム」
開発マネージャの立場として、あなたはたった3つの要素を相手に仕事をする。それはリソース(人と金)、機能（製品とその品質）、そしてスケジュールである。この三角形の中があなたの働く場所なのだ。これら以外に相手にすべきものはない。この三角形のどれか1つの辺を変えれば、残りの少なくとも1つの辺、しかしほとんどの場合2つの辺に影響が出る。
「ソフトウェア開発のダイナミズム」
チームの言動はどんな場合でも分析の対象にするにはあまりに複雑すぎるが、ソフトウエアは嘘をつかない。ソフトウエアには、チームが抱える弱さと強さ、幸運と災い、自覚症状のない病と自覚的な素晴らしさがすべて必然的に現れるのだ。
「ソフトウェア開発のダイナミズム」
必死に働くことではなく、必死に頭を働かせることに重点をおくこと。
「デバッギング ザ デベロップメント プロセス」
プロジェクトが遅れているとしたら、何かが間違っている。原因を無視したり、チームメンバーを長時間働かせたりしないこと。原因を究明し、そして修正すること。
「デバッギング ザ デベロップメント プロセス」
結局はそれほどの根拠がないはずの最終期限を守りたいがために、チームメンバーが製品をだめにしてしまうのを見逃してはならない。
「デバッギング ザ デベロップメント プロセス」
定例会議に注意すること。定例会議がそれ自身がもたらす損害に値するものかどうか確かめること。
「デバッギング ザ デベロップメント プロセス」
予測できたはずの問題で驚くようなはめに陥ってはならない。
「デバッギング ザ デベロップメント プロセス」
毎日、「プロジェクトをあと数ヶ月軌道に乗せておく手助けとして、自分が今日出来ることは何か？」と尋ねること。
「デバッギング ザ デベロップメント プロセス」
レビュー・リーダは、プロダクトの出来、不出来に対して責任は取れないし、とる必要もないが、そのレビュー自身についてだけは、その出来栄えに責任をとれるし、そうしなければならない。
「ソフトウェア技術レビュー・ハンドブック」
レビュー結果を無視するときには危険を覚悟せよ。
「ソフトウェア技術レビュー・ハンドブック」
プロダクトの品質が悪くてもよいレビューには報いること。
「ソフトウェア技術レビュー・ハンドブック」
製作者を評価しないこと。
「ソフトウェア技術レビュー・ハンドブック」
技術的問題点のみを扱うこと。
「ソフトウェア技術レビュー・ハンドブック」
標準に忠実であること、さもなければ標準を捨てること。
「ソフトウェア技術レビュー・ハンドブック」
形式についての議論を避けること。
「ソフトウェア技術レビュー・ハンドブック」
問題点を提起しても、それを解決しないこと。
「ソフトウェア技術レビュー・ハンドブック」
肯定と否定の両面から検討すること。
「ソフトウェア技術レビュー・ハンドブック」
レビュー・リーダの仕事は、レビューがうまくいくようにすることである。さもなければ、なぜレビューがうまくいかなかったかを報告することである。
「ソフトウェア技術レビュー・ハンドブック」
客先で発見されたバグは、あなたのテストシステムへ追加するべき完全な候補である。
「基本から学ぶテストプロセス管理」
テスト計画が現実に合わなくなったら、フレキシブルに対応する。例えばテストスイートの選択をミックスするというような。
「基本から学ぶテストプロセス管理」
新しいファイルがリリースされたら、そのリリースでフィックスされたバグをまずテストする。
「基本から学ぶテストプロセス管理」
テストで問題になる２つの間違い。タイプⅠエラー：実際はバグでないのにテスト実行者がバグだと報告すること。（時間の無駄）タイプⅡエラー：実際のバグを見逃すこと。（品質へのリスク）
「基本から学ぶテストプロセス管理」
ホワイトボックス／ブラックボックスは単純化しすぎていて危険だ、という人もいる。結局、「全てのモデルは間違っているが、いくつかは役に立つ」ということなのであろうか。
「基本から学ぶテストプロセス管理」
どこにいるのか知らなければ、地図はまったく役に立たない。
「ソフトウェアインスペクション」
欠陥発見にはたくましく創造的であれ。欠陥との戦いに勝つためには、何の制約も存在しない。
「ソフトウェアインスペクション」
チェック作業でのチェッカの目標は、ユニークな重大欠陥を最大数見つけ出すことである。ユニークな欠陥とは、ロギングミーティングで他のインスペクタが提示しないものである。重大欠陥とは、テストや運用時に見つけるよりも、今見つけることによって労力を軽減できるものである。
「ソフトウェアインスペクション」
インスペクション自身は、きわめて不合理な納期をも守れることを保証するものではない。しかし、その品質とコストの尺度を通して、阻害要因に関する警告を早い時期に与えることができる。また、品質マイルストーン（完了承認）を示すことにより、早期に危険信号を出すことが可能で、拙速を好む管理者の承認よりはるかに信頼がおける。
「ソフトウェアインスペクション」
問題発見には自動化ツールの利用をまず考える。ただし、発見時期が遅れ、修正コストが自動化の利点を上回るようであれば、迷わず別の手を考える。
「ソフトウェアインスペクション」
インスペクションはテストを代替するものではない。双方は互いにユニークな機能を持っており、それらは他者にとって変えられるものではない。インスペクションはテストで発見できない欠陥を発見し、テストはインスペクションで発見できなかった問題を発見する。
「ソフトウェアインスペクション」
ウォークスルーは訓練に、レビューはコンセンサス作りに！ インスペクションは文章とそのプロセスの品質改善に！
「ソフトウェアインスペクション」
予防は治療に勝る。 つまり1回の予防は何回もの治療に値する。
「ソフトウェアインスペクション」
エラー修正のとき、しばらく設計段階にもどってみよう。
「ソフトウェア・テストの技法」
修正が正しいという確率は１００％ではない。
「ソフトウェア・テストの技法」
エラーの徴候ではなく、エラーそのものをなおそう。
「ソフトウェア・テストの技法」
１つのバグがあるところには、別のエラーもある可能性が高い。
「ソフトウェア・テストの技法」
プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する。
「ソフトウェア・テストの技法」
エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない。
「ソフトウェア・テストの技法」
プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない。
「ソフトウェア・テストの技法」
プログラムをしらべるのに、それが意図されたように動くかどうかをみただけでは、半ば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかをしらべることである。
「ソフトウェア・テストの技法」
テスト・ケースは、正しい予想できる入力条件ばかりでなく、誤った予想しないばあいも考えて書かなければならない。
「ソフトウェア・テストの技法」
それぞれのテストの結果を完全に検査せよ。
「ソフトウェア・テストの技法」
プログラマは自分自身のプログラムのテストをしてはならない。プログラマがプログラムを設計してコーディングするあいだは建設的であり、一夜明ければ突然見かたをかえて、そのプログラムに対して完全に破壊的な心構えをもつようにするということは非常に困難である。
「ソフトウェア・テストの技法」
テスト・ケースの必須条件は、予想される出力または結果を定義しておくことである。なぜなら、”自分に都合のよいように見える”という現象があるからである。
「ソフトウェア・テストの技法」
どんな処方にも二つの部分がある。その一つは薬、もう一つはそれが正しく使われることを保証するための方法だ。
「コンサルタントの秘密」
ある方向に動けば、別の方向についてコストが発生する（トレードオフ）。
「コンサルタントの秘密」
惨事はありえないと言う考えは、しばしば考えられない惨事を引き起こす。
「コンサルタントの秘密」
一見どう見えようとも、それはつねに人の問題である。
「コンサルタントの秘密」
クリスマスプレゼントに金槌をもらった子供は、何でも叩きたがる。
「コンサルタントの秘密」
テスト済みのコードの品質を改善する唯一の効果的な方法は、テスト前のコードに入り込む欠陥の数を減らすことである。
「ソフトウェア開発プロジェクト技法」
品質に関する主要な決定要因は、そのほとんどがテストを開始する以前からソフトウエアに内在している。
「ソフトウェア開発プロジェクト技法」
腕の劣る人を1人、班から外せば、腕のよい人を1人増員するよりも生産性があがることがよくある。
「ソフトウェア開発プロジェクト技法」
政治問題には政治的解決策を；技術問題には技術的な解決策を。
「ソフトウェア開発プロジェクト技法」
許しがたい唯一の怠慢は、過去の失敗から学ぶのを怠ることである。
「ソフトウェア開発プロジェクト技法」
測定できない事柄を、コントロールするわけには行かない。
「ソフトウェア開発プロジェクト技法」
多くの会社が犯しやすい間違いは二つある。ひとつは、間違ったことを測定すること。もうひとつは、正しいことを測定しながら、間違った人に報いることだ。
「大逆転」
目標は夢物語とは違う。達成が不可能なことを目標に掲げれば、従業員はしらけるだけである。逆に、現実的に目標を明確にすると、びっくりするような成果が出てくる。
「大逆転」
何をすべきか従業員がわかっていないとしたら、それをやらなかったからといって、従業員を叱る資格は経営者にはない。経営者がある日、会社の目標を思いつき、退屈な幹部会議でその目標達成を指示し、あとは何もやらなかったら、従業員が目標達成のために何をやればいいのかわからなくても当然である。
「大逆転」
コーチは選手に何をして欲しいかを考えると同時に、どうすればそれをやってもらえるかを考えなければいけない。相手は血が通う人間であり、業務命令の紙ではない。コーチが試合に出て、選手の代わりにプレーすることはできない。パスもできなければ、ブロックもできない。コーチの仕事は何か。それは、選手にプレーさせることである。それを忘れてはいけない。
「大逆転」
みんなで力を合わせるということは、みんなで仲良く飲んで騒ぐことではないし、みんなにやさしくすることではないし、成り行きにまかせることでもない。ポイントは、一日中つきっきりであれこれ指示せず、あとでとやかく言わず、従業員を信頼して、現場の判断は現場に任せることにある。
「大逆転」
問題解決にはどれくらいのコストがかかるかを考える時には、別の問題も考えたほうがいい。道路を直すには、たしかに大変なコストがかかる。しかし、道路を直さなかった場合のコストはどう考えるのか。
「大逆転」
マネージャーの仕事のうち、やさしいほうは制御と調整に関係する。難しいほうは、動機づけ、調和、チームワーク、個人の成長、そして仕事に対する満足度のような人間的な配慮に関係する。模範指導型マネージャーにはとても手が回らないのが、この2番目の範疇、人間的側面なのである。
「デマルコ 大いに語る」
管理とは、社員が生産的に気分良く働けるようにする一連の触媒となる活動である。化学の触媒のように、マネージャーの働きそのものは製品にならないが、他の人の労働が製品になるために絶対不可欠である。
「デマルコ 大いに語る」
あなたが完璧な模範を示そうと頑張れば頑張るほど、部下はとてもじゃないが期待には沿えないから、初めからやってみてもしょうがないと感じるようになる。懸命に働けば働くほど、彼らの仕事の達成感を蝕むことになる。懸命に働けば働くほど、彼らはそれだけ自動機械になり、その日その日を消化するだけの最小の労力しか費やさない。
「デマルコ 大いに語る」
プロジェクト・リーダーの主たる業務は、適切な人が適切なときに適切な意思決定をするようにしむけることである。リーダーがすべてを決定する人になってはいけない。
「デマルコ 大いに語る」
一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の落ち度になると知ったら、こう考えるしかない：どんな間違いだったらボスの落ち度になるのかな、と。
「デマルコ 大いに語る」
たいていのソフトウエア技術者は、予定を達成するために残業するんじゃなくて、達成できないことをやましく感じないように残業している。
「デマルコ 大いに語る」
切迫感ていうのは終わりのほうで痛切になるのに、始めはあまりピンとこない。失った時間の価値は捉えようがない。プロジェクトのメンバーやマネージャーは、問題があっても何日も何週間も平気で寝かせておく。ところが、プロジェクトの初期に稼いだ1週間は、いよいよ駆け込みでおたおたしている大詰めの1週間と同じだけ大切である。
「デマルコ 大いに語る」
成功指数とは、W・エドワード・デミングのいわゆる「外的動機因子」であり、プロ意識や職人の誇り、会社の真の成功との同一化やうまくいった仕事での歓びは「内的動機因子」である。デミングが指摘するように、外的動機因子は内的動機因子を駆逐する傾向にある。社員に数字にしたがって仕事をするように指示すると、彼らはただそのとおりにする。自身の内的価値も会社の真の目標も規範もついついお留守になる。結果は、間違いなく機能不全である。
「デマルコ 大いに語る」
短時間だけなら、品質を犠牲にしてスピードを採るのは効くケ－スがある。数度の戦闘には勝てるかもしれないが、しかし決して戦争には勝てっこないのだ。長期にわたっては、妥協が必須となり、ちょうど1980年代の米国の自動車産業のような破目に陥る：つまり、市場で覇権を失い、新しいグローバルプレーヤーとの競争力を失ってしまう。
「デマルコ 大いに語る」
真の作業ミーティングは、ある事柄を一緒に考えるために、全員を招く本当の理由があるときに開催される。ミーティングの目的は、合意に達することである。単なるセレモニーとの違いに注意する。
「ピープルウエア 第2版」
究極の管理上の罪とは人々の時間を浪費させることである。
「ピープルウエア 第2版」
変化に対する主な反応は、論理的なものでなく、感情的なものである。
「ピープルウエア 第2版」
いたるところの組織が、CMMのレベルを上げるプレッシャーの元にある。これはダークサイドである。なぜなら、それは、ローリスクの安全な行動へと仕向け、それゆえプロジェクトは利益の少ないものとなる。
「ピープルウエア 第2版」
プロセスは、プロジェクトを行う価値が無ければ、推し進める価値は無い。
「ピープルウエア 第2版」
個々人は技量を求めて努力し、よいスキルを積み重ねるが、組織はそれらを規則にすることができるのみである。危険なのは、この規則化である。
「ピープルウエア 第2版」
誰も書かなかった生産性要因…それは「誰とチームを組んでいるか」
「ピープルウエア 第2版」
管理者の役割は､人を働かせることにあるのではなく、人を働く気にさせることである。
「ピープルウエア 第2版」
一般的には、批評は、非難や罰としてではなく情報として与えられた方がもっと受け入れやすい。非難を行っても、人々に非難を回避する方法を見つけようと動機づけるだけである。
「ワインバーグのシステム行動法」
品質とスケジュール目標のトレードオフが出来ないと感じると、管理者は人々の交流の質を犠牲にしたいという気になりがちだが、そうすればすぐに品質とスケジュールの両方に代償を支払わなければならない羽目になる。
「ワインバーグのシステム行動法」
私たちはソフトウエアの仕事はみな論理的だと考えがちであるが、多くの行動が感情に基づいて選択されている。
「ワインバーグのシステム行動法」
みなを同等に扱うことはみなを平等に扱うことを意味しない。
「ワインバーグのシステム行動法」
個人的な経験だけでは、大規模プロジェクト管理にとっては決して十分ではない。というのも一生の間に、異なった大規模プロジェクトを十二分には経験できないからである。２０年の経験の中で５年のプロジェクトをいくつ完成できるであろうか？したがって、大規模プロジェクトの効果的管理者となるためには、他の人々から学習しなければならない。これがうまく出来ないというなら、どのようにして他の人々から学ぶのかを学習しなければならない。
「ワインバーグのシステム行動法」
中間管理職の仕事は「人を育てる」ことである。生気のない書類を作ったり、退屈な会議で半日を費やしたりすることではない。その役割は、率直な心を持って人の話を聞いたり、手助けをしたり、議論のための時間をとったりすることである。人それぞれの幸福に関心を持ち、彼らの潜在力を育成することである。
「ワインバーグのシステム行動法」
端的に言えば、多くの専門家は彼らのやることにほとんど成功しているので、めったに失敗を経験しない。彼らはめったに失敗したことがないから、失敗からどう学ぶかを学習したことがない。したがって、単一ループの学習戦略がうまくいかなくなると、いつも防衛的になり、批判を遮断し、自分以外のあらゆる人に「非難」を浴びせる。要するに彼らの学習能力は、もっともそれを必要とする瞬間にまさしく停止してしまう。
「ワインバーグのシステム行動法」
フィーディーニの手法：こみいった公式と変換で煙に巻き、じっさいになにをやっているのかわからなくする。
「ワインバーグのシステム行動法」
リップ・バン・ウインクルの手法：2年後に目が覚めて「どうしてこのプロジェクトは2年も遅れているんだ？」ということを知りたがる。
「ワインバーグのシステム行動法」
お粗末な管理は他のどんな要因よりもソフトウエアのコストを急速に増大させる。
「ワインバーグのシステム行動法」
レビューは、スケジュール効率を改善し、冗長作業を除去し、テストを補い、そして訓練をもたらす。
「ワインバーグのシステム洞察法」
官僚制のある定義は「一つひとつは管理されているが、全体が管理できていない」。
「ワインバーグのシステム洞察法」
私がこれまでに観察した危機に対するもっとも危険な反応は、危機が実際にどれくらい深刻なものであるかを気づかせるような情報源から自身を切り離すという傾向である。
「ワインバーグのシステム洞察法」
悪い兵士などいない、いるのは悪い将校だ。
「ワインバーグのシステム洞察法」
Xドルの損失はいつでも財務上の責任がXドルを超える取締役の責任である。
「ワインバーグのシステム洞察法」
品質さえ気にしなければ、品質以外のどんな要求でも満たすことができる。
「ワインバーグのシステム洞察法」
慣習的（パターン２）組織のプログラマのほとんどは、何事も規則どおりだ－という錯覚がもはや維持できなくなるまで－管理者を満足させるために始終罪のないうそを創作する。
「ワインバーグのシステム洞察法」
受け取ったものについて少なくとも三つの異なった解釈を思いつかないならば、その意味を十分に考察していないのだ。
「ワインバーグのシステム洞察法」
フィッシュボーン図を展開する活動のほうが出来上がった図よりもずっと重要である。図表は重要ではない、図表を作ることがすべてだ。
「ワインバーグのシステム洞察法」
地図と土地とが一致しないとき、つねに土地を信じよ。
「ワインバーグのシステム洞察法」
生き残るために、管理者は非難を免れるためのこつを知る必要がある。何にも優るこつは気づかないことである。
「ワインバーグのシステム洞察法」
過去の実績統計は変革のために用いられるのではなく、全てがうまくいっていることを証明するために用いられる。
「ワインバーグのシステム洞察法」
品質を手っ取り早く片づけようとすればするほど、問題はますます悪くなる。
「ワインバーグのシステム思考法」
大切なのは出来事ではない、出来事に対する反応だ。次の事象を決定するのはいつでも、その前の事象ではなく、その事象に対する人々の反応である。
「ワインバーグのシステム思考法」
行動は早めに、かつ少しずつ。
「ワインバーグのシステム思考法」
縮尺の錯覚：大きなシステムは､小さなシステムと似たようなもので､単により大きいだけだ。
「ワインバーグのシステム思考法」
他の全ての原因よりもカレンダー時間の切迫が､ソフトウエアプロジェクトにその失敗の現実を直視させる。
「ワインバーグのシステム思考法」
おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
「デッドライン」
初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるを得ない（全員に仕事を与えるため）。
「デッドライン」
致命的なのは知らないことではない…知っているつもりで、実は知らない何かだ。
「デッドライン」
「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。
「デッドライン」
我々は味方同士である。敵は問題そのものだ。
「デッドライン」
入出力の完全なリストのない仕様書は、見込みなしである。仕様を明確にする最初の一歩にもならない。
「デッドライン」
仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
「デッドライン」
管理者が部下を刺激するために屈辱を使うことは、部下ではなく管理者の能力不足のしるしである。
「デッドライン」
管理者の怒りと屈辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる。
「デッドライン」
恐るべき推論：プレッシャーや残業を使う本当の理由は、プロジェクトが失敗したときにごまかすためかもしれない。
「デッドライン」
残業時間を増すのは、生産性を落とす方法である。
「デッドライン」
プレッシャーをかけても思考は早くならない。
「デッドライン」
優れたプロジェクトは、デバッグに費やす時間の割合が,はるかに低い。
「デッドライン」
標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。
「デッドライン」
プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なCMM等級の引き上げ）は,プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に強い
「デッドライン」
一日を無駄にする方法はいくらでもある…・しかし、一日を取り戻す方法は一つもない。
「デッドライン」
プロジェクトの初期に無駄にする一日も、末期に無駄にする一日も等しく打撃になる。
「デッドライン」
新しい仕事を引き受ける意欲のある結束の硬いチームは、プロジェクトの成果の一つと見なす。
「デッドライン」
チームの結束については必要のない賭けはしない。既存のチームを探して利用する。
「デッドライン」
失敗した作業は早く打ち切る勇気をもつ。
「デッドライン」
成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
「デッドライン」
悪い話が上層部に伝わりやすい経路（匿名制など）を作っておくこと。
「デッドライン」
リスクが現実になる前の初期の兆候を予測せよ。
「デッドライン」
それぞれのリスクの実現する確率と予想コストを評価せよ。
「デッドライン」
短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
「デッドライン」
戦闘が始まるときには、管理者の本当の仕事はもう終わっている。
「デッドライン」
正しい管理の本質は、適切な人材を雇用し、適所に当てはめ、士気を保ち、チームの結束を強め、維持する。
「デッドライン」
一生懸命は余分な、不要な努力である。それは、何とかしようとしているが仕事が終わっていないことを示している。効果的なプログラミングにおける最も重要な仕事は考えることであり、人間は考えているときは忙しそうに見えない。もし筆者が、いつも忙しそうにしているプログラマと仕事をすることになれば、筆者は彼がよいプログラマではないと思うだろう。なぜならば、彼は彼の最も勝ちあるツール、脳を使用していないからである。
「コードコンプリート」
読みやすさのガイドラインとして、あなたのコードを変更するのは人間であると言うことを頭に入れておく。プログラミングは、第一には他のプログラマとコミュニケーションをし、第二にコンピュータとコミュニケーションする。
「コードコンプリート」
たとえはじめはエラーがあなたの責任であるように見えなくても、そうであると考えてみるべきである。そう考えることでデバッグが容易になる。エラーを探しているときにはエラーを見つけることは困難であり、エラーがないと仮定しているときにはもっと困難である。
「コードコンプリート」
当初から品質のいかんにかかわらず、最短スケジュールで完了することを目的としたプロジェクトでは、スケジュールと費用の両面で超過する傾向がかなり目立つ。当初から品質と信頼性を第一に完了することを目指したソフトウエアプロジェクトでは、スケジュールが最もよく守られ、高い生産性および市場での成功率の高さが達成された。
「コードコンプリート」
メトリクスは不要だと言う意見は、プロジェクトで実際に何が起きているのかを知らないほうがよいという意見と同じである。
「コードコンプリート」
コードの品質を高め生産性を高めるための唯一の道は、よいコードを再利用することである。ほとんどのアルゴリズムはすでに発明され、検証され、文献において議論され、紹介され、改良されている。
「コードコンプリート」
うまく進行するプロジェクトにおいては、20ないし30%の時間が計画立案、要求仕様、アーキテクチャ設計にかけられている。
「コードコンプリート」
アーキテクチャでは、決定事項の主要なものについてその理由を明記する必要がある。「いつもこういうふうにしている」という正当化に気をつける。
「コードコンプリート」
SELでの研究によれば、コンピュータ使用（エディット、コンパイル、リンク、テスト）の量が多いことと生産性が低いことには相関があることを示している。コンピュータに向かって過ごす時間が少ないプログラマほど、実際にはプロジェクトを早く完遂することが示されている。それが暗示することは、コンピュータを使う時間の長いプログラマーはコーディングや検査の前に計画を立てないと言うことである。
「コードコンプリート」
すでにやる気のある開発者に対して、さらに圧力をかけると動機が急速に下降する。
「ラピッド デベロップメント」
あらゆる要因の中で、「動機づけ」が最も生産性に大きな影響力を与えることが、これまでの多くの調査でわかっている。
「ラピッド デベロップメント」
スケジュールが遅れることそのものより悪いのはただ1つ、スケジュールが送れているということ自体に気がつかないことである。
「ラピッド デベロップメント」
普通以上の残業を当てにしてはならない。それらはこれまでうまく働かなかったし、この先も同じであろう。普通以上の残業を当てにしたスケジュールを計画すると、開発者はスケジュールが送れた場合に、残業をしても追いつくことができなくなる。
「ラピッド デベロップメント」
困難な状態にあるプロジェクトの回復計画で、ほぼ確実に失敗する計画の1つとして、近道を取ることが挙げられる。プロジェクト回復とは近道を取るのではなく、基本に戻ることなのである。
「ラピッド デベロップメント」
最良のプロジェクトは、必ずしも最先端の方法論や広範な自動化またはツールを備えているとは限らない。実際に頼っているのは、強力なチームワーク、プロジェクトのコミュニケーションあるいはプロジェクトコントロールといった基本的な原則である。優良な組織と管理のほうが、技術よりもはるかに重要な成功要因であるように思える。
「ラピッド デベロップメント」
Lakhanpalは、グループの結束力のほうがプロジェクトメンバーの個人の能力または経験よりも、生産性に影響していることを明らかにした。
「ラピッド デベロップメント」
もしチームに対して一度の多くの目標を与えると、それらの目標全てがうまく達成できないことが多い。ITTの調査では、複数の目標を設定すると生産性は急激に低下することがわかっている。
「ラピッド デベロップメント」
重要なことは２つしかない。1つは顧客、もう一つは製品である。顧客を大事にすれば、彼らは再び戻ってくるだろう。製品を大事にすれば、顧客は戻ってこない。
「ラピッド デベロップメント」
全てのソフトウエアエラーの約40%は、ストレスが原因であると判明している。
「ラピッド デベロップメント」
楽観的過ぎるスケジュールは、少しの遅延では終わらない。平均的な小さなプロジェクトの見積もりでは、100%以上の遅延になる。平均的な大きいプロジェクトでは、1年の遅れになる。
「ラピッド デベロップメント」
ほとんどの研究者の間では、0.75または0.80以下のスケジュール圧縮率を実現するのは不可能であると意見が一致している。
「ラピッド デベロップメント」
実際の最短スケジュールは、最も正確な計画されたスケジュールから生まれる。
「ラピッド デベロップメント」
リスクを除こうとすることが無駄な努力であり、リスクを最小化できるかどうかも不確かなら、そのリスクこそは真のリスクである。
「ラピッド デベロップメント」
積極的にリスクを攻撃しなければ、リスクのほうが積極的に攻撃してくる。
「ラピッド デベロップメント」
大きなプログラムについての調査では、査閲（レビュー）に費やした1時間ごとに保守を33時間も削減したことがわかり、査閲はテストの20倍も効率がよいという結果が出た。
「ラピッド デベロップメント」
過度のスケジュールプレッシャーの下で開発され、リリースされた製品では、通常の4倍の欠陥が報告されている。
「ラピッド デベロップメント」
上流工程での作業の時間を惜しんだプロジェクトはたいていの場合、そこから派生する問題のために下流工程で10倍から100倍の時間を割かなければならなくなる。
「ラピッド デベロップメント」
プロジェクトの曖昧な準備に数ヶ月や1年が費やされ、プロジェクトが正式にスタートするときには過酷なスケジュールになっているということもまれではない。
「ラピッド デベロップメント」
プロジェクトチームは計画を立てたのにもかかわらず、スケジュール上のトラブルが発生すると決まってその計画を放棄してしまう。問題は計画を放棄すること自体ではなく、変わりの計画を作成できないままコーディングとその修正を繰り返す状態に陥ってしまうことにある。
「ラピッド デベロップメント」
「なせばなる」姿勢は真の大惨事にいたる小さなつまづきを積み上げていくことになるのである。
「ラピッド デベロップメント」
開発速度を落とすには大きなミスを1つ犯すだけでいいが、効率的開発を実現するには、大きなミスは1つも犯してはならない。
「ラピッド デベロップメント」
ソフトウエアのサイズが増加すると、それ以上の比率で作業が増加するため、サイズを削減することは開発速度のかなりの向上につながる。普通の大きさのプログラムを半分の大きさに削減すると、一般的には必要な作業の2/3近くを削減できる。
「ラピッド デベロップメント」
実際のプロジェクトについての20年間にいたる実験の後、NASAのソフトウエアエンジニアリングラボラトリの調査員はテクノロジーが原因ではないとの結論を得た。もっとも効果的な手法は、開発者自身の潜在能力を引き出すことである。
「ラピッド デベロップメント」
プロジェクト記録の内容を応用しやすい形式に変えておけば、開発チームが記録の作成に要した時間と工数を有効利用でき、次のプロジェクトが成功する確率を高めるための土台になる。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエア プロジェクトの管理にありがちの問題の1つは、特にそんなつもりもなく、計画をないがしろにしてしまうことである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの関係者が最初から再見積の必要性を理解していないと、再見積を行うことはスケジュールの遅れを容認することだと認識されてしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
1991年に300を超えるプロジェクトを調査した結果によると、スケジュールの遅れを取り戻せたプロジェクトは殆どなく、その後更に遅れが拡大する場合が多い。
「ソフトウェア プロジェクト サバイバル ガイド」
初期の段階でプロジェクトの規模を過小評価したり、プロジェクト チームの生産性を過大評価したりするのは仕方ないが、プロジェクトが進んだ時点で、見積違いを発見せず修正しないのは問題である。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクト チームの全員が、各段階の最後にソフトウエアを出荷可能な状態にすることを最優先の課題として扱うべきである。
「ソフトウェア プロジェクト サバイバル ガイド」
一般的なプロジェクトでは時間の約80%が予定外のやり直し作業に費やされている。最小限のやり直し作業を戦略的かつ計画的に行えば、ソフトウエアの品質とプロジェクト全体の生産性を劇的に向上させることができる。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの上流の作業を効果的に実施していれば、構築段階では大きな問題が発生することもなく作業はぐんぐんはかどるだろう。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアの変更を求める圧力が強くなればなるほど、変更に対しては慎重に対応することが重要になる。さもないと、プロジェクトは管理不可能な状態に陥ってしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアの構築作業は非常に詳細なレベルで行う。したがって、この作業で下した何千という判断を後で変更するのは、システム全体のコーディングをやり直すことに等しい。最初の時点で正しい判断をしておかなければ、取り返しのつかないことになるのは明白である。
「ソフトウェア プロジェクト サバイバル ガイド」
過度にコストがかかり信頼性を低くする機能を発見し排除することができるので、技術審査にはそのコストの何倍にも相当する効果がある。
「ソフトウェア プロジェクト サバイバル ガイド」
設計の形式化不足でコストがかかることを考えれば、形式化過剰でコストをかけるほうが賢明である。
「ソフトウェア プロジェクト サバイバル ガイド」
品質保証作業がプロジェクトの終盤まで後回しにされた場合、３，４個の低品質なコンポーネント及び相互関係のデバッグだけではすまない。開発者は、何百、何千の低品質なコンポーネントとその相互関係のデバッグ作業に直面することになる。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアプロジェクトでは、プロジェクトのいたるところで間違いが起きるのは避けられない。プロジェクトが成功するかどうかは、プロジェクトチームがこのような間違いを早く発見して簡単に修正できるような体制を作れるかどうかにかかっている。
「ソフトウェア プロジェクト サバイバル ガイド」
スケジュールの遅れというリスクを最小限に抑えるには、計画に残業時間を組み込まず、プロジェクトの開始時に人的、物的資源を確保しておくべきである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの関係者全員が見積作成手順に同意した後は、見積作成の結果である予算とスケジュールについての無駄な議論を重ねるのを止め、見積作成の基となるデータである機能とリソースについての合理的な話し合いに専心できる。
「ソフトウェア プロジェクト サバイバル ガイド」
以前Algolというプログラム言語を設計したチームに与えられた助言をここに紹介する。「完璧」にこだわると「優良」というレベルさえ達成できなくなってしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトのコストに対する影響が、上流と下流でかなり違うことを考慮すると、ソフトウエアプロジェクトに関する悪い知らせは、早い時期に受け取るに越したことはない。
「ソフトウェア プロジェクト サバイバル ガイド」
アーキテクチャの目標は複雑さを減らすことにあるので、ソフトウエアに組み込む機能ばかりでなく、組み込まない機能についても十分に吟味しなければならない。
ベータテストで効果をあげるためには多くの調整作業が必要である。むしろ、そのために必要な資源を会社内部でのテストに振り向ければ、より大きな品質保証上のメリットを生み出すことができる。
「ソフトウェア プロジェクト サバイバル ガイド」
テストはソフトウエアシステムの品質レベルを調べる手段であり、ソフトウエアの品質を保証する手段ではない。
「ソフトウェア プロジェクト サバイバル ガイド」
速さと品質のどちらを優先するか決めるときに判断材料となるのは、よく言われるように、品質が悪いという評判は、開発が早かったという評判が忘れられてからもずっと後まで残るという点である。
「ソフトウェア プロジェクト サバイバル ガイド」
ユーザーインターフェイスプロトタイプを実際にソフトウエアを作成するときの基礎として使用してはならない。それは、映画撮影所のステージセットを土台にして本物の家を作るのと同じくらいにばかげたことである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロトタイプはあくまでも「単なるプロトタイプ」に過ぎないことをユーザーに理解させなければならない。ユーザーインターフェイスプロトタイプの作成に伴うリスクの1つは、ユーザーに、プロジェクトの今後の進展に対し非現実的な期待を図らずも抱かせてしまうことである。
「ソフトウェア プロジェクト サバイバル ガイド」
要件を収集すときに最も困難なのは、ユーザの要望を記録する作業ではない。ユーザーが自らの漠然とした要望を明確に認識できるように手助けする探索的な開発作業こそが困難なのである。
「ソフトウェア プロジェクト サバイバル ガイド」
成功する組織は、わずかな負担で大幅なリスク回避ができる方法を積極的に捜し求めている。
「ソフトウェア プロジェクト サバイバル ガイド」
成功するプロジェクトには隠された部分が無い。全ての情報は良し悪しにかかわらず、プロジェクトに関係するあらゆる立場の人に制限されること無く伝わらなければならない。
「ソフトウェア プロジェクト サバイバル ガイド」
全体像を説明する場合、組み込む機能と同じくらいまたはそれ以上に除外する機能について明らかにしなければならないところが難しいのだが、除外する機能を明確にしない全体像はプロジェクトにとって有用ではない。
「ソフトウェア プロジェクト サバイバル ガイド」
成功するプロジェクトでは、プロジェクトメンバーが積極的に責任を追及する。これは、自分の作業に対してばかりでなく、自分に関係のあるほかの作業に対しても同様である。
「ソフトウェア プロジェクト サバイバル ガイド」
変更の管理とは、必要な変更は全て行うが、その際、変更の影響をプロジェクト全体に周知徹底することである。
「ソフトウェア プロジェクト サバイバル ガイド」
段階別分納は万能薬というわけではない。しかし、分納に伴う負担と分納によって改善される点を天秤にかければ、負担の増大を補って余りあるメリットがある。進捗状況のわかりやすさ、品質判断のしやすさ、柔軟性、見積もりの正確さ、リスクの削減などの点が大きく改善されるからである。
「 ソフトウェア プロジェクト サバイバル ガイド」
実際に動作するソフトウエアは、紙にかかれたどのような報告書よりも正確に進捗状況を示す。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクト全体にわたってユーザーと連携することは、ソフトウエアプロジェクトのサバイバルに必要不可欠な要素である。
「ソフトウェア プロジェクト サバイバル ガイド」
平均的な管理者の仕事では、数分ごとに頭を切り替えて別の作業をする必要がある。しかし、平均的なソフトウエア開発者の仕事では、最低でも数時間は同じ作業に集中しつづける必要がある。
「ソフトウェア プロジェクト サバイバル ガイド」
不可能な目標によって意欲をかき立てられる人もいる。しかし、開発者は自らが現実的であることを誇りにしているので、手の届かない目標はかえって意欲を失ってしまう傾向がある。
「ソフトウェア プロジェクト サバイバル ガイド」
「管理されたプロジェクト」の逆は「管理されない（自由な）プロジェクト」ではなく、「管理できない（手のつけられない）プロジェクト」である。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの初期段階には、予算とスケジュールを厳密に設定するか一連の機能を厳密に設定することはできるが、同時に両方を厳密に設定することは無理である。
「ソフトウェア プロジェクト サバイバル ガイド」
成功するプロジェクトチームでは、上流の問題は上流で修正できるような手段を講じている。その手段とは要件とアーキテクチャを徹底的に注意深く見直すことである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの最初の段階で工程に時間と労力を傾注しておけば、プロジェクトの後半に大きなメリットとなって戻ってくる。
「ソフトウェア プロジェクト サバイバル ガイド」
