原文: https://agilefromthegroundup.blogspot.com/2011/03/strangulation-pattern-of-choice-for.html
アプリケーションを「少しずつ閉鎖する（Strangler）」最も重要な理由は、作り直してカットオーバーするリスクを減らすことです。 少しずつ閉鎖するやり方は、絶え間なく定期的に価値をリリースすることで、より細かく進み具合を把握できるようにします。 もっと多くのコストがかかるという思い込みに囚われた多くの人たちは、いまだに少しずつ閉鎖するやり方を検討してくれません。 私にはそんな状況が耐えられないのです。 少しずつ閉鎖するやり方ならリリースサイクルをより短くできるので、作り直してカットオーバーするときにありがちな、大量の不必要なフィーチャを作り込んでしまうこともありません。 Martin Fowler, Chief Scientist, ThoughtWorks, on The Strangler Pattern
システムを新しい技術要素で作り直そうとするとき、最初に作った時より作業は簡単になるし、早く終わるだろうと考えがちです。 そのせいで、ビジネススポンサーも「ウォーターフォール型」や「ビッグバンリリース」の開発手法が上手くいくだろうと考えてしまいます。 しかし、作り直しが求められるだけの必要性と規模ならどんなプロジェクトでも、上手くいく可能性はほとんどありません。 どんな場合でも、フィードバックループを回す反復的でインクリメンタルな開発プラクティスが重要なのです。 大規模なアプリケーションを作り直すときのほうがより重要になります。 この記事ではその裏付けとなる経験を説明しましょう。 長期間のマイグレーションを成功させるには、プロジェクトスポンサーやチームメンバーに守ってもらわないといけない（理解してもらわないといけない）根本的な原則があります。 この記事から、次のような原則を学ぶことができるでしょう。
2006年2月、著者は .NET技術のコンサルティングをする会社に入社しました。 間もなく、既存のeコマースプラットフォームを分析して、新しいバージョンを設計、開発するプロジェクトに参加することになりました。 既存システムはニッチな市場を代表するオークションサイトで、700,000 近い登録ユーザーが存在していました。 既存システムは伝統的な ASP + C++/COM + SQL Server 2000 で構成されており、リリースしてから7年間経過していました。 ASP のぺージがおよそ 330 画面ありました。 クライアントには2つの目標がありました。 1つ目はより優れたユーザー体験をもたらすeBay的な新機能を追加することです。彼らは “My Auctions” と呼んでいました。 既存の画面を 30 画面くらい書き換える必要がありました。 2つ目は残りの300画面を元の機能性やユーザビリティを保ちつつ ASP.NET の WebForm へ移行することです。 クライアント自身の設計、開発した COM ベースの包括的ビジネスオブジェクトを COM Interop で再利用したいとのことでした。
最初に請け負ったのは既存の ASP と C++ のソースコードを分析し、移行戦略を提案することでした。 作成したドキュメントには、.NET プラットフォームと C# への移行に関する社内の専門家の意見を明記しておきました。 個人的なお勧めは垂直型移行でした（MyAuction に関連する機能について、アーキテクチャレイヤーの上から下まで切り出すということです）。 「達人プログラマー」で言うところの「曳光弾」です。 Microsoft の公式ドキュメントでも推奨されている方法でした（大規模システムのアーキテクチャ移行で調べていたら見つけました）。 ASP.NET と C# の新基盤を構築し、サービスに価値を追加する新機能をできる限り早く提供するため、クライアントに私たちを雇用することを勧めました。 新機能を提供してから、残りの 300 画面を ASP.NET で置き換えていけばいいと考えていました。
私の提案の根拠は、新基盤を構築し、その上で動作する My Auction 機能を提供することで、クライアントは早い段階で投資対効果を上げられるし（売上を増やせるし）、COM Interop の有用性を評価してリスクを緩和できるということです。 価値を追加するフィーチャだけを追加したシステムを並列に動かして、一部ユーザーが先行して評価できるようにすれば、既存システム全体を新しい技術スタックで置き換える前に、早い段階で有用なフィードバックを得られるはずなのです。
私がこのやり方を学んだのは、サンフランシスコの QCon 2010 における Dan North の講演で、Martin Fowler によると The Strangler Pattern と呼ぶそうです。この記事のタイトルにも使っています。
クライアントは私の提案を慎重に検討してくれたけど、別のやり方を希望しました。 My Auctions だけをデプロイするのではなく、全システムを隣り合わせにデプロイしたいというのです。 著者たちのメンバーがサービスに価値を追加する機能を作っている間に、残りの 300 画面を自社の社員に改修させるというのです。 330画面以上の改修を完了させるのに、私は1年どころか2年以上かかるのではないかと予想しました。 クライアントと私の上司（マネージャー）は期間を短縮する方法を検討し、4人か5人の作業者の増員を決断しました。 実際に、社内で他の開発者と一緒に作業することになりました。 私たちは4か月以内に C# の新基盤とサービスに価値を追加するフィーチャの開発を完了し、ベータテストを始められる状態になりました。
全ての楽しい出来事はここから始まりました。
ソフトウェア業界で数年仕事をしたことがあるなら誰でもご存じでしょうけど、最高の計画を立てたとしても決して計画通りにはいくことはありません。 クライアントの会社で C# 開発者のリーダーを務めていた人は会社を辞めました。 しばらくして私の上司（マネージャー）も会社を辞めました。数か月後にクライアントの会社に入社してプロジェクトの開発管理をすることになっていましたが。プロジェクトについて十分詳しくなっていたので驚きはありませんでした。 それからしばらくして、クライアントの会社で HTML やグラフィックや CSS を担当していた開発者が会社を辞めました。ASP.NET の開発がやりたかったそうです。 クライアントの会社では C# 開発者のリーダーを新たに雇用して、私の担当しているのとは別の巨大なスライスを構築する作業をすることになりました。 5か月後、新たに C# 開発者を雇用し、残されたいくつものスライスを構築する作業をすることになりました。
プロジェクトを成功させるため、著者はクライアントの会社に入社してプロジェクトの筆頭アーキテクトとしてやっていくことにしました。
「大規模展示会」が関係しない開発ストーリーなんて存在しません。 たまたまですが、2008年の初頭に大きな展示会が開催されることになっていました。 そして、私たちのブースを訪問するであろう 25,000 人の顧客に向けて、新しいシステムを実演しなければならないことになりました。 さらに、それぞれの顧客は自分の売り買いする商品を リアルタイムで見れる ことが何よりも重要だということです。 もちろん、問題は既存システムを置き換えられる状態になっていなかったということです。 法的環境の変更に応じたセキュリティ要件に対応できていませんでしたし、新システムで6ノードのデータベースを使用するには、既存システムの2ノードのデータベースに登録したデータを再パーティションしなければならなかったのです。 展示会が始まる前に。 展示会まで残り2か月の時点で本番環境のデータベースに「手を入れる」のはどう考えても高リスクな対応でした。 新システムのデータベーススキーマの 95% は既存システムと同じでした。 しかし、長すぎるカラム名や、外部キー参照の不整合など、解決しなければならない問題も存在していました。 これは特に移行を極めて難しくする要因でした。
私たちはいろんな意見を交わしました。
2つ目の選択肢ならほとんどのリスクは回避できそうです。 既存システムの本番環境のデータベースにおけるシステム設定テーブルを、新システムのための設定値で「上書き」すれば、実現できるでしょう。 シノニムとビューを追加し、「パススルー」オブジェクトに行った全ての書き込みと読み取りを本番環境のデータベースへと解決することで、ベータ版の新システムを、既存システムと並行して実行できるようになるはずです。
多少の PoC やプロトタイピングの結果、この戦略で上手く行く見通しが立ちました。 それから数週間、開発チームの4人のメンバーは毎日「作戦指令室」に集まって、シノニムやビューによる魔法のような切り替えを実現するために必要なSQLスクリプトやシェルスクリプトを作成しました。 スクリプトは何回でも再実行できるようにして、全ての対応関係が正しい権限と構成になっていることのチェックを自動化しました。 自信を持って実行できるだけの十分な検証を行いました。 5つの BAK ファイルと T-SQL スクリプトを含む zip ファイルをデータベース管理チームのリーダーに提供し、実行してもらいました。 何もかも計画通りにいきました。
展示会では何一つ問題が起こりませんでした。 私たちは、ブースにやってきた顧客がシステムにログインし、苦労して開発した新機能を使うのを手助けしました。 即席の計画が成功してとても満足でした。 何より重要なのは、実際のデータを使った新しい機能を実演しながら、売上に直結するシステムに起こりうるあらゆるリスクを避けられたことです。 私たちのプラットフォームでビジネスを展開している人たちにとって、新機能が大いに役立つものであることを実感できて、とても嬉しかったです。
実際に顧客に使用してもらうことで、新機能がシステムに価値を追加することを確かめることができました。 素晴らしい成果です。 ただし、展示会が終わった後にやらなければならないことが残っています。 残りの300画面の移行と検証です。 全部終わるまでとても時間がかかりましたが、最終的に私の提案した段階的な移行戦略を実施できたのでよかったです。
実際にやったこと
その後も旧システムを www で、「ベータ版」を v2 で運用しています。 開発チームは新システムの能動的に監視して、より多くのユーザーを v2 へ誘導するようになりました。 プロジェクトの最初からシステムに価値を追加する My Auction に取り組んできたので、安心して本番環境に提供できる状態になっていました。 新機能が本番環境に提供できるようになり「棚上げ」されてから2年後、新しくチームに参加したメンバーが中心になって、My Auction の基本機能のモバイルバージョンを、ASP.NET MVC と My Auction 機能に対応しているビジネスオブジェクトで開発することになりました。 彼はプロトタイプを「上司」に見せたくないようでしたが、他のチームメンバーは見せるべきだと後押ししていました。 数か月後、本番環境全体を「切り替え」る前にモバイルアプリをリリースすることになりました。 いい仕事でした。
それから数年間、チームは v1 と v2 の使用状況を観測し続けました。 そして、レイトアダプターやストラグラーが新システムへ移行するのを積極的に後押し始めました。 最終的に「切り替え」は完了し、www から v2 へアクセスできるようになりました。 この時点で v1 へのリンクは全て無くなり、仮想マシンしか残っていませんでした。 さらに数か月後、仮想マシンも廃棄され、v1 も COM も無くなりました。
旧システムを完全に廃止した直後に、会社は10周年と10億ドルの売り上げ達成をお祝いしました。
このプロジェクトで過ごした最近3年間を思い起こして、素晴らしい考え方を学ぶことができました。 当初の「全て同時に移行する」計画は成功したものの、私の助言した段階的にリスクを避けながら ROI を最大化するやり方も間違っていなかったのです。 結果として、「予想したとおり」発生した予期せぬ問題を解決するためのアプローチが必要になったからです。
全てのプロジェクトに売上目標が伴うわけではないということは理解しています。 私もこのプロジェクトへ参加する前は、アメリカの疾病対策センターで働いていました。 そこでは、ROI について考えたことはありませんでした。 代わりにユーザーやステークホルダーにとっての使い勝手とか価値のことを考えていました。 適切に評価するには、実際のユーザーの使い方を観測することも必要だし、隣に座って大変さや不満を体験することも必要でした（時には喜びも）。 私たちのチームはそういう評価や効果測定、公衆衛生緊急事態における訓練などを定期的に行っていました。
このブログではアジャイル開発についてもっといろんなことを書いてきたけど、この投稿は Why が中心で「仕組み」についてはあまり説明していません。 しかし、ここではアジャイルマニフェストの第一の原則について言及しておきたいと思います。
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
私のクライアントのように、継続的な提供ではなく「ビッグバンリリース」を求めているとき、どのように取り組んだのか質問されたことがあります。 簡単に答えられないいい質問ですよね。 私から助言できるのは、クライアントとクライアントにとっての顧客の両方について言葉と目的を学ばなければならない、というものです。 クライアントが売上に価値を見出しているなら、何がその売上を生み出しているのか聞いてみないといけません。
私のクライアントの場合、システムを利用してより多くの商品を購入してもらうことが売上の増加につながるようになっていました。 次は「売上を増加するための最短ルートは何でしょうか」と聞いてみることです。 システムを完全に作り直すことかもしれませんし、大規模な改修をビッグバンリリースすることかもしれません。 いずれにしても、価値を向上できるより小さな単位が分かるまで問題分割を繰り返すことになります。 クライアントがビジネス価値に基づいて優先順位を付けてくれないなら、論点をすり替えて価値につながらない提案をしなければならないこともあるでしょう。 最終的には現実世界の制約が一番の重荷になるでしょう。 それでも、ビジネスの価値を考慮して段階的にシステムを開発することに最善を尽くして、実際に価値を提供して、あなたの責任範囲で最善の成果を出すことに努めるのです。 自分で実演できるようになるまでやって見せることが、あなたにできる最善の行動になるでしょう。