はじめに

1章　完成しても，終わりではない

• システムは使い始めてから改善が始まる
• なぜ，ソフトウェアなのに固くなってしまうのか
• プロジェクトからプロダクトの考え方に変える

2章　人を増やしても速く作れるわけではない

• 2倍の予算があっても2倍の生産性にはならない
• 遅れているプロジェクトに人を追加するのはやめて
• 銀の弾丸はないが"金の弾丸"なら有効なときがある
• 速く作ることはできないが，速く作れるチームは作れる
• チームの哲学や文化が揃っていることが大事

3章　たくさん作っても生産性が高いとは言えない

• あらゆる状況を考慮するのに時間がかかる
• プログラムは現実の理解の上に成り立つ
• 影響範囲に気をつけて，重複をなくすことも仕事
• 同じソフトウェアを複数人で同時改修するのは非効率
• 生産性は，手を動かした時間で測らない

4章　人に依存せず同じ品質で作ることはできない

• ソフトウェアは一品モノ，1つずつ中身が違う
• 外から見える品質と，見ることのできない品質
• エンジニアにしかわからないプログラムの美しさ
• クリエイティブな仕事の属人化を解決する

5章　プレッシャーをかけても生産性は上がらない

• 急がせたところで速く作ることはできない
• 一時的な妥協は，永遠の負債になる
• 作れば作るほど，生産性は落ちていく
• 生産性が上がる仕組みを作ることは投資
• 楽をするための苦労はいとわない

6章　見積もりを求めるほどに絶望感は増す

• なぜ，正確な見積もりが出せないのか
• 見積もりを守るためのバッファの功罪
• 見積もりと約束が"受発注"の関係を作ってしまう
• 事業側と開発側が"協働"の関係を築く
• 「納品」をなくせばうまくいく

7章　一度に大きく作れば得に見えて損をする

• プロジェクトが大きくなるとうまくいきにくいのに，なぜプロジェクトは大きくなってしまうのか
• ソフトウェア開発はギャンブルのようなもの，大きく賭けると大きく失敗する
• 小さくすれば不確実さを下げられる
• 小さく作って，大きく育てられるのがソフトウェア
• プロジェクトを小さくするために，作ろうとする機能の範囲を限定する
• 不確実な未来を，少しずつ確実なものにしていく

8章　工程を分業しても，効率化につながらない

• 工程を分離しても生産性は上がらない
• 猫の手を借りても生産性は上がらない
• プログラムは最も低い品質に引っ張られる
• ソフトウェアの設計はだれのものか

おわりに