Cindyとオーストラリアに行ったとき、クイーンズランド州の沿岸にある熱帯雨林でしばらく時間を過ごした。 この辺りの自然の素晴らしさのひとつに、巨大なストラングラーフィグがある。 ストラングラーフィグは、他の木の上の枝に種を蒔き、その木をつたわりながら下りていき、最後には土に根を張るのである。 宿主である木を絞め殺しながら、長い年月をかけて幻想的で美しい姿に成長するのだ。

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

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

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

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

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

参考資料

Paul Hammantは、このアプローチを使用したケーススタディのまとめを提供している。

更新履歴

2019年4月29日にURLと名称を「ストラングラーフィグアプリケーション」に変更した。

素晴らしいメタファーだとは思っていたが、これほど人気がでるとは思ってもいなかった（この数か月は月間3000ページビューを超えている）。人気がでるのはいいのだが、少し問題が出てきた。元の記事では「ストラングラーアプリケーション」にしていたのだが、パターンとして使われるときに「ストラングラー（絞殺）」と呼ばれることが多くなった。これでは比喩的な表現から切り離され、不快で暴力的な意味合いを帯びてしまう。

この名前を回避したり、変更を求める人も出てきた。 それに対して異論はない。私も元の投稿以来、この名前は使っていない。 ただし、一度コミュニティに定着してしまうと、名前を変更するのは非常に難しいという問題がある。

最近、微調整すれば事態が少しでも改善されるのではないかと考えた。 記事のタイトルを「ストラングラーフィグアプリケーション」にして、 できるだけ「ストラングラーフィグ」という用語を使うようにすれば、 暴力的な意味合いが軽減され、本来の比喩的な表現であることが伝わるのではないかと思っている。 小さな変更なので、これなら広まるかもしれない。 手間もかからないので、やってみる価値はありそうだ。