第1章　派生開発の現状

• 1.1　派生開発でのトラブル
  • 1.1.1　動いていたシステムが止まる
  • 1.1.2　わずかな変更でも納期をはずす
  • 1.1.3　結合して動かしてみると動かない
  • 1.1.4　変更モレが頻繁に発生している
  • 1.1.5　デバッグの仕方がおかしい
  • 1.1.6　納期が先に決まっていることがおかしい？
• 1.2　派生開発はなぜ失敗を繰り返すのか？
  • 1.2.1　変更要求をつかんでいない
  • 1.2.2　全体を理解しようとして失敗している
  • 1.2.3　派生開発の特徴を理解していない
  • 1.2.4　市場トラブルを通常のデバッグプロセスで対応している
  • 1.2.5　一人プロジェクトの問題
  • 1.2.6　疑似一人プロジェクトも起きている
  • 1.2.7　「間に合わないモンスター」の襲来
  • 1.2.8　データをとっていない
  • 1.2.9　他人のソースを簡単に理解できるか
  • 1.2.10　崩れた設計思想
  • 1.2.11　忘れられた保守性などの品質要求
  • 1.2.12　恐怖の「ドラえもんのポケット」
  • 1.2.13　スペックアウトの技術を持たない
  • 1.2.14　ソースコードの変更が早すぎる
  • 1.2.15　潜在バグの意味
  • 1.2.16　どこを変更したのか誰も知らない
  • 1.2.17　インクリメンタルモデルでも失敗する
  • 1.2.18　複雑なコンフリクトに対応できていない
  • 1.2.19　既存の分析・設計技法はすべて新規開発向け
  • 1.2.20　「新規開発崩し」で混乱している
  • 1.2.21　構成管理を崩壊させる
  • 1.2.22　CMMでの取り組みの誤り
  • 1.2.23　思考を止めた組織

第2章　派生開発プロセス「XDDP」の提案

• 2.1　XDDPの誕生
  • 2.1.1　厳密な変更制御
  • 2.1.2　変更した行数からわかること
  • 2.1.3　データをとることで見えてくること
  • 2.1.4　派生開発での特徴を知る
  • 2.1.5　「部分理解」を克服する
  • 2.1.6　派生開発に特化したプロセスを提案
• 2.2　ライフサイクルモデルとしてのXDDP
  • 2.2.1　ウォーターフォールモデルからインクリメンタルモデルへ
  • 2.2.2　派生開発専用のライフサイクルモデル
• 2.3　「変更要求仕様書」の導入
  • 2.3.1　変更内容や変更箇所を特定するための文書
  • 2.3.2　変更箇所に関する情報を提供
  • 2.3.3　ソースコードを“変更仕様”として扱う理由
• 2.4　2つのPFD
  • 2.4.1　変更要求と機能追加要求で求められること
  • 2.4.2　変更要求用のPFD
  • 2.4.3　機能追加用のPFD
  • 2.4.4　“差分”に徹する
• 2.5　XDDPの成果物
  • 2.5.1　変更要求仕様書
  • 2.5.2　追加機能要求仕様書
  • 2.5.3　トレーサビリティ・マトリクス
  • 2.5.4　インパクト・マトリクスとの違い
  • 2.5.5　変更設計書
  • 2.5.6　その他の成果物
• 2.6　変更用PFDの各プロセスの説明
  • 2.6.1　変更要求項目を仕様書に記述する
  • 2.6.2　ソース等を調査しながら変更仕様を抽出する
  • 2.6.3　追加機能の変更要求仕様書を作成する
  • 2.6.4　変更要求TMを作成する
  • 2.6.5　変更設計書を作成する
  • 2.6.6　ソースコードを変更する
• 2.7　追加用PFDの各プロセスの説明
  • 2.7.1　追加機能用の要求仕様書を作成する
  • 2.7.2　追加機能を設計する
  • 2.7.3　追加機能の関数設計書を作成する
  • 2.7.4　追加機能のソースコードを書く
• 2.8　XDDPとソフトウェアエンジニアリング
  • 2.8.1　XDDPは100％近い成功率を誇る
  • 2.8.2　変更用PFDは基本的にはウォーターフォールの変形
  • 2.8.3　追加用PFDのプロセスは選択可能

第3章　XDDPによる変更のプロセス

• 3.1　変更要求をまとめる
  • 3.1.1　変更依頼の内容を変更要求と変更仕様に振り分ける
  • 3.1.2　カテゴリに分類する
  • 3.1.3　「before」「after」で“変更要求”を表現する
  • 3.1.4　変更要求も「範囲」を持つ
  • 3.1.5　変更する“理由”が必要なわけ
  • 3.1.6　変更要求を分割・階層化する
  • 3.1.7　変更要求における分割基準
  • 3.1.8　下位層の変更要求にも「理由」が必要
  • 3.1.9　必要なら変更要求をグループ分けする
  • 3.1.10　変更依頼が「仕様」でされることへの対応
  • 3.1.11　変更仕様にふさわしい変更要求を立てる
  • 3.1.12　積み残しのバグを変更要求として対応
  • 3.1.13　変更でいくか追加でいくか
• 3.2　ソースコードから変更仕様を探す
  • 3.2.1　文書やソースファイルの情報を整理する
  • 3.2.2　変更要求単位で該当箇所を探す
  • 3.2.3　ソースコードを探して変更仕様を拾う
  • 3.2.4　スペックアウトで変更仕様を拾う
  • 3.2.5　スペックアウト作業の注意
  • 3.2.6　システムのアーキテクチャを確認する
  • 3.2.7　仕様も「before」と「after」を表現する
• 3.3　関連文書から変更仕様を探す
  • 3.3.1　ベースとなる機能仕様書などから変更仕様を拾う
  • 3.3.2　関連箇所を漏らさない工夫
  • 3.3.3　TMにマークしてから，あとでソースコード上で確認する
  • 3.3.4　変更要求仕様書でテストケースを更新する
  • 3.3.5　変更内容に応じた耐性を確認するテストが可能
• 3.4　追加の機能仕様から変更仕様を探す
  • 3.4.1　機能追加を“変更”としても扱う
  • 3.4.2　機能追加の実現方法を明らかにする
  • 3.4.3　変更要求仕様と追加要求仕様書との連携
• 3.5　変更仕様の抽出時に注意が必要なこと
  • 3.5.1　変更要求の下に変更仕様を記述する
  • 3.5.2　仕様変更としての追加と削除
  • 3.5.3　意外と書けない「before」「after」
  • 3.5.4　変更要求の表現が適切でないと変更仕様が拾えない
  • 3.5.5　完成後の機能仕様を作ってみることも
  • 3.5.6　補助資料の効能
  • 3.5.7　グループ化で変更のテーマを整える
  • 3.5.8　先にグループを設定する効果
  • 3.5.9　変更内容を文章で書くことが難しい？
  • 3.5.10　変更要求仕様にソースを書かない理由
• 3.6　変更要求TMを作成する
  • 3.6.1　列方向に持ってくるもの
  • 3.6.2　クラス名では小さすぎる
  • 3.6.3　TMの「列」情報を固定する効果
  • 3.6.4　XDDPの“要”としての役割
  • 3.6.5　変更要求TMにマークする
  • 3.6.6　新規開発時に作るトレーサビリティ・マトリクスとの関係
  • 3.6.7　トレーサビリティ・マトリクスにこだわる理由
  • 3.6.8　理解の食い違いに気づく
  • 3.6.9　「TM」部分は省かれる傾向がある
• 3.7　変更方法を変更設計書にまとめる
  • 3.7.1　変更設計書に記入すること
  • 3.7.2　変更方法を文章で書く
  • 3.7.3　異なる変更仕様で同じ関数に変更が重なるケース
  • 3.7.4　変更で新たな関数が作られるケース
  • 3.7.5　変更設計書はいつ書くのか？
  • 3.7.6　間違った変更を防止する最後の砦
  • 3.7.7　変更方法の適正さを検証するための単体テスト
  • 3.7.8　マージできるだけの情報があればよい
  • 3.7.9　変更仕様の粒度の問題
  • 3.7.10　バグも書き残す
• 3.8　ソースコードの変更は足並みを揃える
  • 3.8.1　抜けがけ禁止のルール
  • 3.8.2　ソースファイル単位に集める
  • 3.8.3　3度目の訪問
  • 3.8.4　ソースファイルを共有しているケース
  • 3.8.5　変更作業に費やした時間を記録する
  • 3.8.6　書き直しがない
  • 3.8.7　変更後の単体テスト
  • 3.8.8　ソースコードの合体
  • 3.8.9　ソースコード変更後にすること

第4章　追加のプロセスとXDDPを支えるものたち

• 4.1　機能追加のプロセス
  • 4.1.1　追加機能要求仕様書を作成する
  • 4.1.2　仕様間の衝突に注意する
  • 4.1.3　変更要求仕様書と要求番号でつなぐ
  • 4.1.4　追加機能だけで設計を進める
  • 4.1.5　機能追加分のTM（トレーサビリティ・マトリクス）を作る
• 4.2　移植を扱う
  • 4.2.1　移植は“機能追加”の変形
  • 4.2.2　2種類の変更仕様で対応する
  • 4.2.3　仕様の確認を忘れずに
  • 4.2.4　機能の一部を流用するケース
  • 4.2.5　ペーストシンドロームを回避する
• 4.3　派生開発における品質要求のあり方
  • 4.3.1　追加機能に対する品質要求
  • 4.3.2　変更要求に対する品質要求
• 4.4　XDDPにおけるレビュー
  • 4.4.1　3つの成果物の役割とレビューポイント
  • 4.4.2　What−Where−How　の関係
  • 4.4.3　変更要求仕様でのレビュー
  • 4.4.4　追加機能要求仕様書のレビュー
  • 4.4.5　トレーサビリティ・マトリクス（TM）でのレビュー
  • 4.4.6　変更設計書でのレビュー
  • 4.4.7　その他の成果物のレビュー
  • 4.4.8　変更作業をストップさせる
  • 4.4.9　一人プロジェクトでのレビュー
  • 4.4.10　レビューの効果
• 4.5　XDDPにおける要件管理
  • 4.5.1　派生開発での要件変更の難しさ
  • 4.5.2　派生開発における要求仕様書のベースライン設定
  • 4.5.3　ベースライン設定後の変更の可能性は減っている
  • 4.5.4　追加機能への変更は変更仕様も変わる可能性がある
  • 4.5.5　慎重な要件管理で対応する
  • 4.5.6　CCBに最終決定権を持たせる
  • 4.5.7　一人プロジェクトにおける要件管理
  • 4.5.8　暫定仕様に対する仕様変更
  • 4.5.9　変更が仕様で届いたときの対応
  • 4.5.10　作業の中断に工夫が必要
  • 4.5.11　追跡リストへの登録と運用
  • 4.5.12　もう一つの追跡リストの活用
  • 4.5.13　ぎりぎりまでソースコードを変更していないことの効果
• 4.6　ドキュメントの維持
  • 4.6.1　公式文書はテスト中に差分によってマージする
  • 4.6.2　機能仕様書に戻す
  • 4.6.3　スペックアウト文書の扱い
• 4.7　サイズ見積りについて
  • 4.7.1　変更要求からソースコードの変更規模を見積る
  • 4.7.2　「before」「after」が見積りの根拠となる
  • 4.7.3　変更要求仕様書を書いたあとのサイズ見積りの調整
  • 4.7.4　変更要求TMのセルをサイズ見積りにも活用する
  • 4.7.5　変更設計書でさらに調整する
  • 4.7.6　見積り値と実績値の乖離の意味
• 4.8　XDDPのプロセスを変化させる
  • 4.8.1　PFDを使ったプロセスの表現
  • 4.8.2　PFDはシミュレーションの道具
  • 4.8.3　リファクタリングとのコラボレーション
  • 4.8.4　共通のベースから複数の並行開発も可能
  • 4.8.5　インクリメンタル開発も派生開発の特性を持つ
• 4.9　運用時の注意
  • 4.9.1　1回目のコンサルティングでの成功を勘違いしない
  • 4.9.2　文書を減らそうという圧力に対抗すること
  • 4.9.3　サイズ見積りも計測も省かない
  • 4.9.4　親和性に注意
  • 4.9.5　「原典」に戻って
  • 4.9.6　偽装工夫に注意すること

第5章　XDDPの効果

• 5.1　とても間に合わない……と思われたのに
• 5.2　XDDPで納期が遅れない理由
• 5.3　工数が大幅に短縮する仕組み
• 5.4　バグの件数からも大幅な時間の削減が可能
• 5.5　仕様変更と変更ミスの大幅な減少
• 5.6　バグの根源を絶っている
• 5.7　レビューでバグの過半が発見される
• 5.8　デバッグ時にも大きな効果が得られる
• 5.9　「デスマーチ」から脱出できる
• 5.10　一人プロジェクトでも失敗しない
• 5.11　アウトソース先と連携する
• 5.12　次のプロジェクトへの準備ができる
• 5.13　将来への備え
• 5.14　日本版SOX法への対応
• 5.15　ソフト以外への応用