■■はじめに


■■1章　完成しても、終わりではない
■システムは使い始めてから改善が始まる
■なぜ、ソフトウェアなのに固くなってしまうのか
■プロジェクトからプロダクトの考え方に変える


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


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


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


■■5章　プレッシャーをかけても生産性は上がらない
■急がせたところで速く作ることはできない
■一時的な妥協は、永遠の負債になる
■作れば作るほど、生産性は落ちていく
■生産性が上がる仕組みを作ることは投資
■楽をするための苦労はいとわない


■■6章　見積もりを求めるほどに絶望感は増す
■なぜ、正確な見積もりが出せないのか
■見積もりを守るためのバッファの功罪
■見積もりと約束が"受発注"の関係を作ってしまう
■事業側と開発側が"協働"の関係を築く
■「納品」をなくせばうまくいく


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


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


■■おわりに