http://martinfowler.com/bliki/StranglerApplication.html

Cindyとオーストラリアに行ったとき、 クイーンズランド州の沿岸にある熱帯雨林でしばらく時間を過ごした。 この辺りの自然の素晴らしさのひとつに、 巨大なストラングラーヴァイン(strangler vine)がある。 この木は、イチジクの木の上のほうの枝に種を蒔き、 木をつたわりながらだんだんと下に下りていく。 そして、最後には自分の根を土に下ろしてしまう。 そうやって何年もかけて、幻想的で美しい形へと成長していくのだ。 一方、この木のホストとなったイチジクの木は、 ストラングラーに絞め殺されてしまう。

このメタファーは、重要なシステムの書き換えの方法を表すのに使えるんじゃないかと私は思った。 私のキャリアの大半は、クリティカルなシステムの書き換えであった。 書き換えなんて、新しいシステムに古いシステムと同じ動作をさせればいいだけの簡単なものだと思うかもしれない。 だが、書き換えは思ってるよりもずっと難しいし、リスクがいっぱいなのである。 移行日が不気味に迫る。お尻に火がつく。 新しい機能が好まれているのに(新しい機能は常にあるものだ)、 既存の機能もそのまま使えるようにしておかなければならない。 バグもそのまま新しいシステムに残さなきゃならない(!)なんてこともある。

新しいシステムを古いシステムの周りにじょじょに作っていき、 数年かけてゆっくりと成長させ、 最後には古いシステムを窒息死させるという方法もある。 この方法は難しそうに聞こえるが、私はこう思うようになってきた。 「それって、ちゃんとやってないだけなんじゃねーの?」 私はいくつかの基本戦略がうまくいくのではないかと思っている。 まずは、イベントインターセプション。 これは段階的に機能を移行する際に使える。 また、財産確保を可能にしてくれる。

最近、同僚のChris Stevensonがあるプロジェクトで非常に大きな成功をあげた。 このプロジェクトについての最初の論文XP 2004発表していたが、 私はこのプロジェクトの様々な側面についてもっと記述してもらいたいと思っている。 彼らはまだ古いアプリケーションを窒息死させるところまでは出来ていない。 だが、彼らは価値ある機能をビジネスにもたらした。 そのことで彼らは、チームへの信頼性をも獲得した。 プロジェクトが休止している今も、彼らは巨額の投資対効果をもたらしている。 これは、多くの書き換えプロジェクトが成し遂げたものよりも大きい。

ストラングラーアプリケーションが書き換えアプリケーション よりも優れているといえるのは、リスクが減少した点にこそある。 ストラングラーを使えば着実に価値を提供することができ、 頻繁なリリースによって、進捗をより注意深く観測することができる。 だが、多くのひとはストラングラーをまだ認めていない。 コストがかかると思っているからだ(私もまだ確信していない)。 しかし、ストラングラーを使って短期リリースを行うことが出来れば、 書き換えで頻発する大量の「不必要な機能」を作らなくても済むだろう。

重要な考えがもうひとつある。 以上の理由から、新しいアプリケーションを設計する際には、 将来的に窒息死しやすいように設計するということだ。 今日作っているシステムは、明日のレガシーシステムである。 そのことから目をそむけてはならない。 将来的に窒息死しやすくすることで、 君は、今日の仕事から安らかにフェイドアウトすることが出来るのである。