Martin Fowlerが語るレガシー追放パターン

Martin Fowlerといえば「リファクタリング」などの著書で有名だが、レガシーをdisplace(追放)するというタイトルのブログを書いていた。ちょうど仕事でレガシーと格闘しているので、ざっくり読んでみる。

At some point during each programme they hit a crisis point where changing business needs would overtake their current tech strategy and hence trigger the need to start over. Where they had taken a waterfall "big bang" approach to the programme this meant abandoning the majority of the work.

ビジネスニーズが技術戦略をovertake(追い越し)しているので、ツギハギではなくstart over(最初から作り直し)しなければいけないケースというものがある。こういった状況がビッグバン(すべてを一度に開発する)で開発するウォーターフォールで発生してしまうと、多くの仕事を放棄することになりかねない。

こういう状況になってしまう要因を①技術だけ取り替えてビジネスの方を変更していなかったこと、②大規模プロジェクトでプロジェクト開始時点の要求とギャップが生じる、③現状と同じようにしたいと要望してしまうことと書いている。(詳細は原文へ)

こういった状況をLegacy Replacement Treadmill、つまりレガシーを交換するだけのトレッドミルと呼んでいる。トレッドミルは日本ではランニングマシンと呼んだ方がイメージしやすいかも。要するに延々と走り続ける羽目になるということだ。こういったサイクルから抜け出す方法について、次のように書いている。

There are a series of approaches we have found can help with these challenges. They aid with the challenge of breaking the problem into smaller parts to allow delivery of new requirements in parallel with improved technology. Broadly speaking they fit into four categories:
1.Understand the outcomes you want to achieve
2.Decide how to break the problem up into smaller parts
3.Successfully deliver the parts
4.Change the organization to allow this to happen on an ongoing basis

問題を小さなパーツに分解し、技術改善と並行して新しい要求を届ける手順として①達成したいoutcome(結果)を理解する、②問題を小さなパーツに分解する方法を決定する、③正しくパーツを届ける、④継続的に行われるよう組織を変える、の4つを紹介している。

Fortunately there are a number of really useful tools that can be used collaboratively to get a good enough understanding to proceed. These tools are discussed in detail elsewhere but a summary list would include Event Storming, Wardley Mapping, Business Capability Mapping and Domain Mapping.

「②問題を小さなパーツに分解する」に使えるツールとしてEvent Storming、Wardley Mapping、Business Capability Mapping、Domain Mappingなどの手法がある。

Event Stormingに関しては日本語でも情報が多いので参考になりそうだ。

Canary Release
Stop the World cutover
cutting over to new system
Revert to Source
Divert the Flow
Dark Launching
Legacy Mimic
Event Interception

「③正しくパーツを届ける」については、カナリアリリース(一部のユーザだけ新バージョンを使わせ、問題なければ全ユーザに展開する)など8つの手法が示されている。

それぞれ、ざっと紹介すると、こんな感じだ。

Canary Release:一部ユーザのみ新たなシステムを利用させ、徐々に移行する

Stop the World cutover:運用を完全に停止し、新システムへ切り替える

Revert to Source:既存のデータソースを残し、これに新システムを接続する、

Divert the Flow:業務そのものを変革し、既存システムから遠ざける

Dark Launching:画面はそのままで、バックエンドのみ新しくする

Legacy Mimic:新システムがレガシーの模倣をする

Event Interception:古いシステムのイベントを傍受し新システムにルーティングする

実際の現場で「一度に切り替えた方が短期間で終わる」とか「きちんと検証してからやれば問題ない」みたいに、今まで何を学んできたのか不思議なプロマネが多いが、先人たちの工夫を列挙して見せることで、危険なレガシー追放プロジェクトを少しでも安全に進められたらと思う。


この記事が気に入ったらサポートをしてみませんか?