LASSIC Media らしくメディア

長年使ってきた基幹システムを新しくしたい。けれど、業務を止めるわけにはいかず、一度に全部を作り替えるのは、あまりに危険が大きい——。レガシーシステムの刷新を考えるとき、多くの現場がこのジレンマに突き当たります。この難所を乗り越える考え方として知られているのが、ストラングラーフィグ・パターンです。少しずつ新システムに置き換え、最後に古いシステムを撤去する、段階的な移行の進め方を指します。

大がかりな作り替えを一気に進める「ビッグバン移行」と対置される考え方で、リスクを小さく刻みながら移行を進められるのが持ち味です。本記事では、システムの刷新を検討する情報システム部門の担当者に向けて、ストラングラーフィグ・パターンとは何か、一括移行との違い、つまずきやすい点、そして進め方と外注の勘所を整理します。

ストラングラーフィグ・パターンとは——一括移行との違い

ストラングラーフィグ・パターンとは、稼働中の古いシステムを一度に置き換えるのではなく、機能を少しずつ新しいシステムへ移し、最後に古いシステムを撤去していく、段階的な移行の進め方を指します。名前は、木に巻きついて成長し、やがて元の木を覆い尽くす植物になぞらえたものです。新システムが少しずつ育ち、いつしか旧システムを置き換えている——そんなイメージです。

この考え方が対比されるのが、いわゆるビッグバン移行です。ビッグバン移行は、新システムをまるごと作り上げ、ある日をもって旧システムから一斉に切り替える進め方を指します。分かりやすい反面、切り替えの日に問題が起きると影響が全体に及び、後戻りも簡単ではないのが難点です。これに対してストラングラーフィグ・パターンは、機能を小さな単位で移していくため、一度に動かす範囲が限られ、問題が起きても影響を狭い範囲にとどめやすいという違いがあります。

ここで鍵になるのが、新旧の切り替えを利用者に意識させないための「窓口」の存在です。リクエストをいったん受け止め、その機能がすでに新システムへ移っていれば新へ、まだであれば旧へと振り分けます。この窓口（ファサードと呼ばれます）を挟むことで、移行の途中でも利用者は同じ入口を使い続けられるわけです。一気に切り替えるのか、窓口を挟んで少しずつ移すのか——ここに、両者の根本的な違いがあります。

なぜ段階的に進めるのか

そもそも、なぜ手間のかかる段階的な移行が選ばれるのでしょうか。背景には、レガシーシステムの刷新につきまとう、いくつかの現実があります。第一に、業務を止められないという事情です。基幹システムは日々の業務を支えており、長期間の停止は許されません。第二に、一括での作り替えは失敗したときの傷が深いという問題です。すべてを新しくして一斉に切り替える方式では、当日に想定外の不具合が出ると、業務全体が立ち行かなくなりかねません。

そして第三に、古いシステムは全体像が見えにくいという難しさがあります。長年の改修で複雑になり、仕様を知る人も少なくなったシステムを、一度に正確に作り直すのは容易ではないのです。段階的に進めれば、機能を移すたびに動きを確かめられ、想定と違えば立て直せるのが利点です。一度に動かす範囲が小さいぶん、問題が起きても切り分けやすく、後戻りもしやすくなります。刷新という大きな山を、小さな一歩に分割して登っていく——それが、段階的な移行が選ばれる理由です。だからこそ、止められない基幹システムの刷新ほど、この考え方が力を発揮します。

進め方の流れ

ストラングラーフィグ・パターンによる移行は、おおむね決まった流れで進みます。全体像をつかんでおくと、自社の刷新にどう当てはめるかを考えやすくなるはずです。順を追って見ていきましょう。まず、旧システムの前に「窓口」を置き、すべてのリクエストをいったんそこで受けるようにするのが出発点です。この段階では、窓口はすべてを旧システムへ受け渡すだけです。

次に、移しやすい機能を一つ選び、新システムとして作り直します。出来上がったら、窓口の振り分けを切り替え、その機能へのリクエストだけを新システムへ向けるわけです。うまく動くことを確かめながら、これを機能ごとに繰り返していきます。移した機能が増えるにつれて、新システムは育ち、旧システムの役割は少しずつ減っていくのです。そして、すべての機能が移り終えたら、最後に旧システムを撤去します。この関係を図にすると、次のとおりです。

大切なのは、一つずつ移すたびに動作を確かめ、問題があればその機能だけを戻せるようにしておくことです。小さく進めて確かめる、この繰り返しが、段階的な移行の背骨になります。

つまずきやすい難所

段階的な移行にも、あらかじめ想定しておきたい難所があります。踏まえておくと、「途中で止まって旧システムが残り続ける」という事態を避けやすくなります。

一つ目は、新旧の並行稼働に伴うデータの扱いです。移行の途中では、新システムと旧システムが同時に動く期間が生まれます。両者が同じデータを見たり書いたりする場合、どちらを正とするか、どう同期するかを決めておかないと、内容が食い違ってしまいます。二つ目は、窓口の作り込みです。振り分けを担う窓口は移行の要ですが、ここが複雑になりすぎたり、性能の妨げになったりしないよう、設計に配慮が要ります。三つ目は、移行が途中で止まることです。段階的だからこそ、優先度の高い機能を移した時点で満足してしまい、残りが古いまま放置される、ということが起こりがちです。新旧が並行したままだと、二重の運用負担が続きます。四つ目は、区切り方の難しさです。機能どうしが密に絡み合っていると、きれいに切り出せず、一つ移すのに大がかりな作業が必要になることがあります。いずれも、始める前に「どこで区切り、どう並行期間を乗り切り、いつ旧を撤去するか」を描いておくと、避けやすくなる落とし穴です。

向く場面・向かない場面

ストラングラーフィグ・パターンは万能ではなく、向く場面とそうでない場面があります。自社の状況に照らして見極めると、進め方を選びやすくなるはずです。整理しました。

おおまかにいえば、止めることが許されない大規模なシステムで、機能をある程度切り分けられるなら、段階的な移行が向きます。逆に、規模が小さく短時間の停止が許され、一気に作り替えられるなら、一括移行のほうが早く済むこともあるでしょう。どちらが正しいというより、システムの規模と業務の事情しだいで、適した進め方は変わるものです。たとえばモノリスからマイクロサービスへの移行や、メインフレームからの移行でも、この段階的な進め方がよく用いられます。

外注時に確認しておきたい点

段階的な移行を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、機能をどの順序で、どの単位で移すかという計画です。どこから手を付け、どこで区切るのかは移行の成否を左右するため、現状の把握を踏まえて一緒に描いておきたいところです。次に詰めておきたいのが、新旧が並行する期間のデータの扱いになります。どちらを正とし、どう同期するのかを決めておかないと、移行の途中で内容が食い違います。

さらに、旧システムをいつ撤去するかという出口も、はじめに描いておきたい点です。ここが曖昧だと、移行が途中で止まり、新旧の二重運用がずるずると続きます。あわせて、各機能を移したあとの動作確認や、問題が起きたときに戻せる備えも確認しておくとよいでしょう。設計と最初の一歩だけを頼むのか、撤去までの移行全体を伴走してもらうのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：段階的移行で押さえる3つの視点

ストラングラーフィグ・パターンは、稼働中のレガシーシステムを一度に置き換えるのではなく、機能を少しずつ新システムへ移し、最後に旧システムを撤去する、段階的な移行の進め方です。押さえておきたい視点は3つに整理できます。第一に、一括で切り替えるビッグバン移行との違いを理解し、止められない基幹システムほど段階的な移行が力を発揮すると捉えること。第二に、新旧を振り分ける窓口を挟み、機能を一つずつ移しては動作を確かめる、という小さな繰り返しで進めること。第三に、新旧が並行する期間のデータの扱いと、旧システムを撤去する出口を、始める前に描いておくことです。この3点を踏まえておけば、「途中で止まって旧システムがいつまでも残る」という事態を避けやすくなります。自社に適した進め方の見極めや計画づくりに不安があれば、外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　参考：Martin Fowler「StranglerFigApplication」（https://martinfowler.com/bliki/StranglerFigApplication.html）。考え方の一般的な解説の参考として。

Tweet