Agileと仕様変更

なんか「Agile=仕様変更OK」みたいな感じに捕らえている人が多いと思う。Agile採用しているからいつでも仕様変更できる…というか、それが出来なきゃAgile採用している意味ないでしょ？っていう。
Agile=仕様変更OKって関係式が成り立つのは、たぶんそのプロジェクトが単一、または少数の顧客しか相手にしていないときだ。仕様変更するかどうかは顧客に聞けばいい。顧客が望む形にどんどん仕様変更していく。これはOK。Agileの力を遺憾なく発揮できる。
でもそれがパッケージ開発だとそうはいかない。少なくともすでにリリース済みのパッケージである場合、仕様変更は既存ユーザに多大なる影響を与えるからだ。ユーザはしばしば開発者が考えてる枠を超えた使い方をしていたりする。ここを変更してもだれも困らないだろう…というか、きっと誰もが喜ぶはずだ…と、大した洞察もせずに仕様変更すると痛い目に会う。ま、独占的にユーザを支配している一部のソフトウェアやサービスなんかは、平気で仕様変更するけどね。仕様変更で困ったユーザがいても、そのユーザが他のサービスに移れないことを知ってるからだ。
そういうわけで、極力後方互換性を維持しながらパッケージを修正することになる。これはアジャイルだからどーのこーのという問題ではない。一般的なソフトウェアの保守の問題。開発者としてはこうしたほうが絶対いい！！と思う仕様変更でも、後方互換性のために身動きが取れなくなってしまう場合もある。それは仕方がない。どうしても変更したいなら既存ユーザに聞いて回るってのもアリだ。全てのユーザがOKといえば、仕様を変更することには全く問題ないわけだ。
パッケージ開発以外にも仕様を変更できないシーンってあるよね。たとえばフレームワークを開発している場合。すでにリリース済みのフレームワークを修正する際、そのフレームワークを利用しているユーザへの影響を考慮しなきゃいけない。privateなmethodは基本的に変更しても問題ない。問題はpublicなメソッド（Javaで考えればprotectedとかもしかり）。それらを変更する際は最新の注意を払わなければならない。「このメソッド、誰も使ってねーだろ。こうしたほうがBeautifulだから変えちゃおう」って安直に考えるのはNGなわけだ。古いメソッドを残して別名の新しいメソッドを作るとか、後方互換性を維持する方法はいくつかある。後方互換性を維持するために最大限の努力をしなければならない。
逆にわざとメソッドを変えてエラーを起こさせて、フレームワーク利用者を早々に新しいフレームワークへ移行させるって手もある。その場合でもユーザに対する告知や移行手順、移行時期などは詳細に説明する責任があると思う。
要するに、パッケージにせよフレームワークにせよ、そのユーザに対して仕様変更に伴う影響を最大限に考慮する必要があるってことだ。ユーザとは、パッケージならばそれを利用するエンドユーザになるだろうし、フレームワークならそれを利用する開発者ってことになる。それを考慮せずにAgileだから…という単純な理由で仕様を変更していいわけがない。Agile以前に、その仕様が正しいかどうか…という複雑で慎重な議論が最も重要だ。