XDDPについての議論 - Yasuo's Notebook

先日、リーンカンファレンスでXDDPについてのセッションがあったためか、アジャイル開発実践者の方がXDDPについて言及されているのをよく見かけます。Facebook上でも議論をしたので、その時に書いた私のXDDPについての個人的な感想を書きます。

XDDPを適用する判断基準

まず、私はアジャイル開発とXDDPの両方の経験があり、プロジェクトによって使い分けています。XDDPを適用する判断基準は次の通りです。

自分達でない誰かが作ったプログラムの変更である。
役に立つドキュメントがない。
長い関数が大量になるなど複雑なコードになっている。
変更にかけることができる期間やコストが少ない

特に組み込み系の開発では、上記のような条件に当てはまるものが多いので、その分野でXDDPが支持されている理由の一つなのではないかと思います。XDDPでは、リファクタリングしたりユニットテストを書いたりしないのか？というと必ずしもそうではありません。変更設計書をレビューする際に、リファクタリングした方が良いという提案があって、チームで検討してリファクタリングすることもよくあります。また、製品の性質上、よく変更が加わるところは、ユニットテストを書くのは効果的です。

XDDPはウォーターフォール？

XDDPは変更設計書を書いてからコードを変更するというやり方なので「XDDPはウォーターフォールだ」という感想も見かけました。私のところでは、XDDPを適用する際は、原則として変更要求仕様毎に反復的に開発を行っています。派生開発自体が、「前からの変更」であり、それを何回も繰り返しているわけですので、反復していると言えます。特にUSDMの形式は変更要求毎に識別可能な番号が付いていて、（書き方によりますが）単独で扱えるので、スクラムのプロダクトバックログと同じような扱いも可能です。XDDPそのものと、変更要求仕様を一度に実装するか、反復的に実装するかはあまり関係ないというのが私の考えです。

XDDPとアジャイル開発の共通点

私はXDDPとアジャイル開発の共通点は、“チームでコードレベルまで共有することに対するこだわり”だと感じています。それがXDDPでは、トレーサビリティマトリクスや変更設計書というドキュメントの作成とレビュー、アジャイル開発では、コードの共同所有、ペアプログラミングやテスト駆動開発というプラクティスを手段としています。どちらの方法が効果的かはコンテキストによって異なりますが、どちらの方法もコードがどのように実装されるかということに対する関心が非常に高いことが特徴です。Facebookでの議論でも話題になりましたがXDDPが効果的な状況のフォースに着目してパタンで表現すると面白いと思っています。

XDDPをやれば変更の影響範囲を見落とさない？

よく、「XDDPをやれば変更影響を見落とさないようになりますか？」ということを聞かれます。私は、XDDPは“良くわからないコードをチームでハッキングするためのプロセスの一つ”と捉えています。もちろん、他にも良い方法はたくさんあると思います。あたりまえのことですが、他人が作った複雑なコードの変更影響を見落とさないためにもっとも必要なスキルは、“コードを読む力”です。XDDPはコードを読んだ結果の残し方を定めたものであり、適用したからと言って、“コードを読む力”が大幅に増すことはありません。なので、メーカーのような派生開発が多い組織では、オープンソース等を使ってコードをハックするスキルを高める訓練をすることが重要だと感じています。

自分たちがやっているやり方と違う方法について、ネガティブな感想を持ってしまいがちだと思いますが、私は、基本的に「うまくいっているということは何らかの必然がある」と思っています。そのうまくいく理由となっている要因（これがたぶんパタンにおけるフォースのようなもの？）を突き詰めていくと、自分たちが現在実践している方法がうまくいく本質的な理由をより深く理解することができると思います。