目次

第1章 まえがき　─なぜほとんどのソフトウェア開発は失敗するか─

1.1 本書のゴール
　─改善─
　1.1.1 改善ができないプロジェクトマネージャー
　1.1.2 改善ができないエンジニア
1.2 本書で伝えたいこと 　─Tips─
1.3 本書の対象となる読者
　─毎日忙しいあなた─

第2章 典型的な失敗例　─失敗に学ぶ─

2.1 著しい遅延とコストの上昇問題
　─ デンバー空港のプロジェクトに代表される古典的なプロジェクトトラブルの例─
　2.1.1 トラブル耐性の弱いプロジェクトとコミュニケーション問題
2.2 非機能要求の不備問題
　─みずほ銀行のシステムダウンに見られる例─
　2.2.1 非機能要求の取り扱い誤りは致命的
2.3 致命的なバグによる大きな損害の問題
　─アリアン5ロケットの爆発事故における例─
　2.3.1 ミスを犯す前提で品質を担保できるようなプロジェクト
2.4 まとめ
　2.4.1 モチベーションの欠如を嗅ぎ分ける能力

第3章 人が全て　─個々の開発者の効率の最大化─

3.1 個々のエンジニアの効率化
　─開発者の生産性を上げる─
　3.1.1 これだけの差がつくソフトウェアエンジニアの生産性
　3.1.2 ミスコミュニケーションの弊害
3.2 プロジェクトは全体の効率をあげる
　─小さい方がうまくいく─
　3.2.1 訳の判らないマネージャーが増える問題
　3.2.2 コミュニケーションコストが発生し、生産には寄与しない問題
3.3 じゃあどうすればいいですか？
　─プロジェクトと製品リリースの考え方のスタイル─

第4章 はじめよければ全てよし　─そもそも要求定義って？─

4.1 漠然たるユーザー要求を機能要求に落とし込む
　─然るべきスタートラインに立つために─
4.2 要求に優先順位をつける
　─自分たちの身を自分たちで守るためにも─
4.3 テスト可能な要求を書く
　─要求を分解するノウハウとテストのポイント─
　4.3.1 要求の網羅（要求のテスト）
4.4 非機能要求をちゃんと書く
　─複雑であいまいで困難な作業─
　4.4.1 外部インターフェイス
　4.4.2 制約
　4.4.3 品質特性
　4.4.4 パトリオットはなぜ誤爆したか
　4.4.5 プロジェクト責任者の役割
4.5 要求の変更の耐性
　─アジャイル時代の要求管理─
　4.5.1 イテレーティブな要求仕様
　4.5.2 テスト駆動開発
4.6 まとめ

第5章 ちゃんと設計しろって言うけど　─アーキテクチャ─

5.1 アーキテクチャとは
5.2 パターン
　5.2.2 アーキテクチャパターン
5.3 品質特性
　5.3.1 セキュリティ
　5.3.2 信頼性
5.4 ステークホルダ
5.5 アーキテクチャ品質
5.6 まとめ

第6章 オーソドックスか？ アジャイルか？　─開発スタイル─

6.1 アジャイル開発
6.2 短期リリース
6.3 シンプルな設計
6.4 テスト！テスト！自動化！自動化！テスト駆動開発
　6.4.1 プロなテスト担当者を入れる
　6.4.2 煩雑なリファクタリング
　6.4.3 ペアプログラミング
　6.4.4 コーディング規約
6.5 40時間労働
6.6 アジャイル開発のデメリット
　6.6.1 大規模開発
　6.6.2 アーキテクチャ V.S. アジャイル
　6.6.3 顧客がそこにいます？
　6.6.4 成熟度の低い組織
6.7 うまい開発例

第7章 PMBOK使えばいいの？　─プロジェクト管理─

7.1 時間管理
　─日本人の一番苦手なスケジュール管理─
　7.1.1 WBS ─ちゃんとスケジュール引こうぜ！─
　7.1.2 時間管理術
7.2 コスト管理
　─プロジェクト・コスト・マネージメント─
　7.2.1 見積り手法（フォーマルモデル）
　7.2.2 見積り手法（エキスパートモデル）
　7.2.3 バグが与える見積りへの影響
　7.2.4 まとめ
7.3 品質管理
　─プロジェクト・クォリティ・マネージメント─
　7.3.1 悪い品質のモジュールを徹底的に叩く
　7.3.2 品質メトリクス
7.4 リスク管理
　─プロジェクト・リスク・マネージメント─
7.5 まとめ

第8章 それでもプロジェクトマネージメントがうまくいかない理由

8.1 オフショアリングによるコスト削減
　─多拠点での開発─
　8.1.1 やはりオフショアは生産性に寄与しない？
8.2 人員コントロール
　─人を選ぶのに方法論は存在しない─
8.3 プレッシャーの塩梅
　─銀の弾丸はいまでも「ない」─
8.4 水曜で終わらせて、木曜からスタートしましょう
　─金曜にプログラムはしない！─
　8.4.1 金曜にコーディングはしない！
8.5 エンドゲーム
　─終わりよければ全て良し─
　8.5.1 Do Not Change Code（コード変更するべからず）
　8.5.2 失敗したら検死をしましょう（ポストモーテム：postmortem）
8.6 問題解決のためのフレームワーク
　─MECE（ミーシー）に処理しよう─
Postscript（最後の一言）
結び