『Ship It!』読者の声
まえがき
序
謝　辞
日本語版監訳者より
目　次
第1章　はじめに
　1.1 習慣の美徳
　1.2 現実的な視点
　1.3 本書のロードマップ
　1.4 本書を読んだ後にしてほしいこと
　1.5 本書の読み進め方
第2章　ツールとインフラストラクチャ
　誰も知らないFred の悩み
　こんな風に暮らせたら
　Fred がはまった罠を避けるには
　1 砂場（サンドボックス）での開発
　2 資産管理
　3 ビルドスクリプトの作成
　4 自動ビルドを実行する
　5 問題の追跡
　6 機能の追跡
　7 テストハーネスを使う
　8 ツールを選ぶときの注意
　9 実験をしてはならない局面
第3章　実践的なプロジェクト管理技法
　10 作業リストに基づいた作業
　11 技術主任
　12 日々の協調とコミュニケーション
　13 あらゆるコードをレビューする
　14 コード変更通知の送信
　15 まとめ
第4章　曳光弾開発
　曳光弾開発
　一般に広く使われているプロセスの問題点
　プロセスを定義する
　曳光弾開発の概要
　システムオブジェクトを定義する
　複数のチームが協力してインタフェースを定義する
　インタフェーススタブを記述する
　各層間の呼び出しや応答を可能にする
　実機能を持つコードをスタブに追加する
　リファクタリングによる改良
　簡潔な具体例
　曳光弾開発を売り込む
第5章　一般的によく見られる問題とその解決方法
　16 レガシーコードをサポートしなければならない
　17 テスト不能なコードをテストする
　18 修正したはずの機能の不具合が何度も再発する
　19 テスト？ さっぱり使ってないなあ
　20 バグを再現できない
　21 コードを統合することに苦痛を感じる
　22 ビルドプロセスの信頼性が低く、処理を何度か繰り返さない製品をビルドできない
　23 顧客の満足度が低い
　24 チーム内に不良開発者がいる
　25 マネージャが不満を抱いている
　26 メンバー間の関係が希薄でチームワークが欠けている
　27 不可欠の手法やプロセスをチームメンバーや関係者が積極的に取り入れようとしない
　28 新しい手法が役に立たなかった
　29 自動テストの体制が整っていない
　30 指導役を務めることができるベテラン開発者がわずかしかいない
　31 プロジェクトが「デスマーチ」に陥っている
　32 機能の追加を頻繁に要求される
　33 いつまでたっても作業が終わらない
付録A　ヒントのまとめ
付録B　ソースコード管理
　利用可能なソースコード管理システム
　キーコンセプト
　ソースコード管理システムの選び方
　より詳しい情報
付録C　ビルドスクリプトツール
　入手可能なスクリプト言語
　キーコンセプト
　ツールの選び方
　より詳しい情報
付録D　CI システム
　入手可能なCI ツール
　キーコンセプト
　ツールの選び方
　より詳しい情報
付録E　問題追跡ソフトウェア
　入手可能な問題追跡ソフトウェア
　キーコンセプト
　ツールの選び方
　より詳しい情報
付録F　開発の方法論
　利用可能な方法論
　キーコンセプト
　方法論の選び方
　より詳しい情報
付録G　テストフレームワーク
　入手可能なテストフレームワーク（テストハーネス）
　入手可能なテストフレームワーク（テストツール）
　キーコンセプト
　テストフレームワークの選び方
　より詳しい情報
付録H　おすすめの本と参考文献
　全般
　Ruby
　Java
　方法論
　ソースコード管理
　その他
　リーダーシップと人間
参考文献
索　引