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

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

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

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