Introduction
社内に、昔に開発した業務システムや基幹システムが残っていませんか?このような古いシステムはレガシーシステムと呼ばれます。誰も設計内容や仕様を把握しておらず、機能が古く、性能が悪いうえに運用管理に手間とコストがかかるなど、負の遺産である側面が強い傾向にあります。
このようなレガシーシステムを段階的に、新しいシステムに置き換えていくことを、ストラングラーパターンと呼びます。
この記事では、ストラングラーパターンとは何か、そのメリットや注意点、実装ステップなどについて解説します。
目次
ストラングラーパターン(ストラングラーフィグパターン)とは

ストラングラーパターンは、ストラングラーフィグパターンとも呼ばれます。ここでは、ストラングラーパターンがどのようなものなのか、その名前の由来や従来のリプレイスとの違いについて解説します。
現行システムから部分的につくり替えを繰り返してシステムを刷新すること
ストラングラーパターンとは、レガシーシステムを段階的に新しいシステムに置き換える設計パターンのことです。
レガシーシステムは、企業の重要な基幹システムや業務システムとして稼働している場合も多く、一度にすべてを新しいシステムに置き換えることはむずかしいでしょう。そのため、段階的に置き換えていくストラングラーパターンを採用すれば、リスクを軽減して業務やユーザーへの影響を最小限に抑えられます。
独立行政法人 情報処理推進機構の『DX 実践手引書 IT システム構築編 完成 第 1.1 版』によると、以下のように説明されています。
ストラングラーパターン
現行システムから、一部の機能を切り出して、作り変えるということを繰り返し行って、段階的に移行を進めていく。
レガシーシステムのほとんどは、古いプログラミング言語で構築されたシステムや、スペックの低いハードウェアで構成されています。機能が古いうえに性能が悪く、メンテナンス性が低いです。それにも関わらず、仕様や設計を知っている担当者が退職しているなど、維持運用が非常に困難な状態にあります。
このようなレガシーシステムは、維持運用に多大なコストがかかる割に、得られるメリットが少ないため、企業としてはすぐにでも新しいシステムに置き換えたいでしょう。
しかし、昔から稼働している基幹システムや業務システムは、業務の中心的な存在を担っていることも多く、そう簡単に置き換えられないケースも多いです。そのため、業務やユーザーへの影響を最小限に抑えて、システムの更改を行う必要があります。そこで役立つのが、段階的にシステムを置き換えていく、ストラングラーパターンの考え方です。
名前の由来
Strangler Fig(絞め殺しイチジク)という言葉が由来となっており、そこから省略されてストラングラー(パターン)と呼ばれます。イチジクには「ツタが古い木に絡みつきながら成長し、やがてその木を覆って枯らしてしまう」という特徴があり、システムを徐々に新しく置き換えていく本手法の名前の由来になっています。
従来のリプレイス手法との違い
従来の一般的なリプレイス手法は、段階的に新システムに移行するという要件を基本的に含んでいません。そのためリプレイス時に業務やユーザー、顧客への影響が大きいのが特徴です。万が一移行作業に失敗した場合は業務が滞り、サービスが停止してしまう場合もあります。
しかし、段階的に移行するストラングラーパターンなら、部門や業務を絞って少しずつ新システムに置き換えていくため、無理なくスムーズに置き換えが可能です。そのかわり何度も移行作業を行う必要があるので、一度に置き換えるよりも作業が複雑になるというデメリットもあります。
関連サービスについて
ストラングラーパターンのメリット
ここでは、ストラングラーパターンのメリットについて解説します。
サービス停止リスクを軽減できる
ストラングラーパターンを採用することで、サービスが停止するリスクを避けることが可能です。
一度にすべてのシステムを更改すると、作業が失敗した場合に影響が大きくなります。場合によっては、サービスが停止するほどの大きな影響が起こることもあり、リスクが伴うでしょう。
そのため、段階的に移行するストラングラーパターンを採用すれば、リスクを抑えて移行を行うことが可能です。
チーム分担しやすく外注と連携しやすい
大規模な基幹システムや業務システム、社内システムなどを一度に移行する場合、大規模なプロジェクトを組む必要があります。その場合、一度に大量の人員が必要になり、作業分担がむずかしくなります。
ストラングラーパターンなら、段階的な移行作業を計画的に何度か行うため、チームの分担がしやすいことがメリットです。作業を切りわけて分担することで、外注企業との連携も可能です。
コストの分散が見込める
一度に大規模のシステム移行を行う場合は大量の人員が必要になり、一度に多くのコストが必要です。しかし、段階的に移行すれば、一回の作業に必要なコストは少なくなり、コストの分散が見込めるでしょう。
ストラングラーパターンの注意点
ストラングラーパターンを採用する際は注意点もあるため、ここでは注意すべき点について解説します。
作業計画や作業内容が煩雑になる
移行作業を段階的に複数回行う場合、綿密な作業計画が必要であり、作業内容が煩雑になります。
たとえば部署ごとにシステムを移行していく場合、ある部署では新システムになり、ある部署はまだ旧システムが稼働しているという状態になります。また、ある機能は新システムに移行し、旧システムを使用している機能もあるという並存状態になるでしょう。
そのため移行期間のみ、新旧両システムに対応するためのシステム変更が必要になったり、業務に影響がでたりすることも十分に考えられます。
このように、移行作業は一度にすべてを移行した方が単純で、段階的に移行すると作業が複雑になってしまうのです。
新旧システムのデータ同期が必要になる
システム移行を段階的に行う場合は、新旧システム間でデータの同期が必要です。移行期間中は新旧システムが混在するため、それぞれが別々のデータベースをもつ期間が発生します。その場合、二つのデータベースの内容に整合性をとるため、データの同期を行う必要があります。
長期運用に伴う管理工数の増加が見込まれる
段階的に作業を行うことで、長期間移行作業を行う必要があります。長期的に移行作業を行う人員を確保しつづける必要があり、そのための管理工数の増加が発生するでしょう。
ストラングラーパターンの実装ステップ

ストラングラーパターンを実装するためには、作業を綿密に計画する必要があります。ここでは、ストラングラーパターンの実装ステップについて解説します。
①プロキシ層の導入
旧システムと新システムを使いわけるための仕組みである、プロキシ層をどうするか決めます。既存システムと新システムの間にプロキシ層を設け、どの機能を旧システムで処理するのか、どの機能を新システムに移行するのかなどを動的に決めていきます。
プロキシ層を導入することで、ユーザー側からはどの機能も従来と変わらずに利用できているように見えますが、裏ではサーバーが部分的に置き換わっています。プロキシ層により、サーバーが置き換わっていくことによるユーザーへの影響を極力少なくすることが可能です。
②新システムの段階的実装
旧システムの一部機能を新システムで実装します。最終的にはすべての機能を新システムに切り替えますが、最初はログイン認証機能やメインの業務の機能など、重要な機能から実装することが多いです。
③実装テスト
実装した新システムのテストを実施します。基本的には通常のテスト工程と変わりませんが、ストラングラーパターンの導入という観点では新旧システムの同時使用の確認、データ移行のテストなどが追加になります。
▽あわせて読みたい▽
>>システムテスト(総合テスト)とは?その目的・観点・種類、実務で使える手順について解説のページへ
④新システムへの段階移行
テストが完了したら、新システムへ移行を行います。このように、段階的に新システムの実装、テスト、移行を繰り返していきます。
⑤完全移行と旧システムの廃止
すべての機能が新システムに移行したら、旧システムを停止します。一定期間は旧システムを残しておきますが、どこかのタイミングでプロキシとともに廃止します。(一部ケースではプロキシを残しておくこともあります)
ストラングラーパターン導入検討時のポイント
ストラングラーパターンの導入を検討する際に、気をつけておくべきポイントがあります。
開発や移行作業を依頼する外注先を決める際は、ストラングラーパターン開発の実績がある外注先を選ぶべきです。また、そのなかでも自社と同じ業界や、同様のシステムのストラングラーパターン開発を扱った経験がある外注先を選ぶのが望ましいでしょう。
関連サービスについて
まとめ
ストラングラーパターンとは、レガシーシステムを段階的に新しいシステムに置き換える設計パターンのことです。レガシーシステムは、企業内の重要な基幹システムや業務システムとして稼働している場合も多く、一度にすべてのシステムを新しいシステムに置き換えることはむずかしいでしょう。
そのため、段階的に置き換えていくストラングラーパターンを採用すれば、リスクを軽減して、業務やユーザーへの影響を最小限に抑えられます。
「自社にレガシーシステムがまだ残っているが、新システムに一度に移行するのは顧客や取引先、業務に影響が大きい」「安全に新システムに移行したい」という場合は、ストラングラーパターンの導入を検討すべきでしょう。
しかし、ストラングラーパターン開発は複雑な作業であり、長期間におよぶことが多く、簡単に導入できるものではありません。導入時には、実績やノウハウがある外注先に開発を依頼すべきです。
自社のレガシーシステムを安全に新システムに移行したいという場合は、SHIFTのモダナイゼーションサービスをご活用ください。それぞれのニーズやシステム環境にあった対応を行い、業務効率化向上に向けたオペレーショナルエクセレンスを実現します。

監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――