著者が独自に生み出した、派生開発プロセスであるXDDPについて説明している。

　まず本の前半で、派生開発が成功しない理由を、「部分理解の罠」を中心に、多くの事例をもとに分析している。
（部分理解の罠とは、XDDPプロセスを無視して十分な検討を行わずに、場当たり的にソースを修正して、工数を膨らましてしまう
事だと説明している）

　本の後半では、派生開発専門のプロセスである、XDDPの具体的な活用法を述べている。
・XDDPでは派生開発を「変更要求」と「追加機能要求」の２つに大別し、それぞれのプロセスをPFD（Process Flow Diagram）で定義
・成果物は、変更要求仕様書（What）、TM：トレーサビリティ・マトリクス（Where）、変更設計書（How）の３つが必須
・ソースの解析や仕様書をインプットとした中間成果物であるミニ・スペック仕様書も有用

　僕自身の経験だと、ある機能を修正／追加したい場合、関係しそうなソースを洗い出して解析し、ミニスペックを作成し、改修範囲を確定させ、工数を算出する。
（仕様書がしっかりしていれば、そこから知識を得られるが、大抵の派生開発では仕様書が古かったり、無かったりするので、今動いているソースを正として解析せざるを得ない）。

つまりボトムアップなアプローチであるため、漏れが発生しやすい。また、なぜその変更や追加が必要なのか、本質的な問題をとらえにくい。

　これに対してXDDPは、トップダウンアプローチにより、まず変更を要求としてとらえ、前後左右の関係を考慮しながら何（What）が求められているか、またその理由は何かを記述する。これをもとに修正範囲（Where）をTMで分析して、最後にどのように（How）改修を行うかを、変更設計書に記述する。こうすることで工数の信頼性もあがり、漏れや重複無く開発を進めることができる、というのが著者の主張であり、なるほどと思わせる内容と思う。

　僕も含めて、現場で日々、派生開発で悪戦苦闘している開発者にとって、たくさんのヒントが書かれていると思う。

　最後に一言だけ付け加えると、全体的に帰納法で書かれているせいだと思うが、もう少し説明が簡潔であれば、と感じた。

「レガシーコード改善ガイド」の時と同じく、日々の保守開発業務を改善したいと思い、この本を手に取りました。
「レガシーコード改善ガイド」は「オブジェクト指向 + 自動化テスト」が基本なので若干理想論っぽいところがありますが、この本はもっと実践的というか、「現場によくある風景」を強く反映している点が評価できると思います。

本の冒頭に書かれていた、

・現場の大半は派生開発(保守開発)である。新規開発なんて滅多にない。
・ところが世の中に出回っている有名な開発プロセスはほとんどが新規開発をターゲットとしている。

という記述にも「まさにその通り！」といった感じで大きく頷いてしまいました。

さて、筆者の提唱する派生開発のためのXDDPというプロセスですが、私なりにまとめてみると以下のようになります。

・要求(顧客の意図や目的)と仕様(要求を実現するための方法、機能)を明確に分ける。
・要求/仕様(What)と変更箇所(Where)、変更方法(How)をそれぞれ文書化する。
・文書は基本的に自然言語で書く。ソースコードを貼り付けて説明するのはNG。(影響範囲をレビューする際に視野が狭くなるため)
・文書を他の開発メンバーとレビューし、認識ミスや変更箇所のモレ、重複、デグレードの危険性等がないか確認する。
・Howの文書にしたがってソースを変更する。
・Howの文書にしたがってソースが変更されていることを他のメンバーが確認する。
・What/Where/Howの文書の内容を必要に応じて公式文書(新規開発時から存在する機能仕様書等)に更新する。

いくつかは新しい発見がありましたが、基本的な流れは私も実際に実践している方法に近かったです。(「ここだ！と思った箇所をすぐ修正」はやっぱり危険ですよね)
とはいえ、本の中では作業フローや成果物を詳しく説明してあるので、この本の内容をベースに社内の業務プロセスを改善していけそうだと感じました。

ちなみにこの本ではほとんど触れられていませんが、私の場合、業務において以下のような点で苦労することもよくあります。

・前回の開発からかなり時間が経過しているため、開発環境やテスト環境(テストデータの用意を含む)が再現できない。
・デグレードしていないことを証明するためのテストケースが分からない。(現行バージョンの仕様が不明確)

この部分についても何かアイデアがあればさらに嬉しかったです。

本の内容自体は非常に実用的だと思うので星5つですが、最後に少し気になった点を挙げておきます。

・あちこちで「USDM」という筆者の提唱している要求仕様化技法の話が出てくる。しかし、この手法はポピュラーなものとはいえず、別途筆者の本を購入しないと確認できない。簡単にでも説明してほしかった。(「これは商売か？」と勘ぐってしまった)
・文章が若干まわりくどい。似たような話が何度も出てくる。もっと内容を整理して再構成すれば短時間で読めるのに、と思った。
・本のレイアウト(見た目)が若干うるさい。ページ中の余白をもっと増やしたり、変な装飾(?)をもっと減らせばすっきりして読みやすいのに、と思った。

非常に具体的かつ実際的な内容。
組込系のシステム開発の例が多いが、あらゆるシステム開発プロジェクトに応用できる内容だと思う。

手戻りが多く予定の工数を大幅に超過してしまうのも、品質が悪く結局使えないシステムになってしまうのも、多くのSEが日々の無駄な作業に追われて疲弊しスキルアップに励む余地が無くなってしまうのも、極論すれば全て「要求仕様書」の“書き方”の拙さに起因していることが反論の余地の無いほどズバリと指摘されている。

その上で、具体的にどこをどのように改善すれば良いのか、非常に具体的な仕方で示されているので思わず「ああ、なるほど！」とうなずいてしまう。

しかも、決して筆者の独りよがりな方法論を押し付けるというのではなく、コンサルティングの現場での多くの経験を通し、実際に適用するに当たってどこが難しいのか、どこから取
掛かれば良いかなども指摘されていて、よしがんばろう！という気持ちにさせてくれる。

これまでいくつか「派生開発」プロジェクトに関わったが、その失敗や困難の背景に本書で指摘されている多くの原因があったと気づかされた。

筆者の語り口について“説明が冗長で分かりにくい”という印象を持つ方もいらっしゃるようだが、問題の本質をしっかりと突いているので、ポイントを抑えながら読めば苦にはならないと思う。

日本のシステム開発の現場では、「ゼロからの新規開発」より、「動いているシステムの変更・機能追加」の仕事が多いはずです。

その一方で、従来よく知られている開発方法論・開発プロセス論は、新規開発に偏った構成になっています。また、新入社員などがシステム開発を学ぶ場合を見ても、新規開発のための方法論、プロセスが学習されていました。

本書は、こうした「仕事の現状」と「開発方法論」との間の乖離を埋める目的で、変更・機能追加を扱う「派生開発」のためのプロセス、方法論を論じています。

派生開発で陥りやすい失敗が示された後、派生開発の特徴が論じられます。これらは、著者の現場での豊富な経験に基づいて書かれており、真実味があります。

その上で派生開発の方法論（プロセスや成果物）が述べられています。他の方法論・プロセス論と同様、各現場でカスタマイズが必要なのは言うまでもありません。ですが、一般原則として述べられる内容に、私は「なるほど！」と感じることが多かったですね。

「１，２ヶ月の短納期で、機能の変更・削除・追加を行うミニプロジェクト」に追われている、多くのエンジニアにお勧めします。