機能パリティ

レガシーシステムの既存の機能を、新しいテクノロジースタックを使用して再現します。

2021年7月27日

ITエグゼクティブと話す際に、しばしば耳にするのは、寿命が近い、あるいは既に寿命を迎えているテクノロジーで構築された老朽化したアプリケーション群を抱えているという状況です。多くの場合、これらのシステムは、第三者によって管理され、柔軟性のない契約を持つコストのかかるデータセンターでホストされています。これらのアプリケーションは、ビジネスの円滑な運営に不可欠でありながら、同時にビジネスと運用上のリスクの最大の要因の一つにもなっています。

彼らは、改善、プロセスの最適化、新しい機会の創出の可能性を十分に認識しています。しかし、これを完全に実現するには、混乱を招き、多くの依存関係が発生します。たとえば、既存の「BAU」作業、他の変更プログラム、そして特にエンドユーザーが働く部門の既存の計画と予算の制約などがあります。

この状況における一つのアプローチは、他のすべてを「そのまま」にしておきながら、テクノロジーを「単に」置き換えることで、組織全体への置き換えの影響を最小限に抑えようとすることです。これは、機能パリティ、または試みたことがある人によって「機能パリティの罠」と呼ばれることが多いアプローチです。

機能パリティはしばしば合理的な提案のように聞こえますが、私たちは、人々が要求される労力を大幅に過小評価し、したがってこれと他の代替案の間の選択を誤っていることを苦労して学びました。たとえば、「現状」の範囲を定義するだけでも、特にビジネスの中核となっているレガシーシステムの場合、非常に大きな労力がかかる可能性があります。

ほとんどのレガシーシステムは、時間の経過とともに「肥大化」しており、ユーザーによって使用されていない機能（2014年のStandish Groupのレポートによると50％）が多く、古い機能が削除されずに新しい機能が追加されています。過去のバグや制限に対する回避策は、現在のビジネスプロセスにとって「必須」の要件となり、ユーザーの働き方は、他の何よりもレガシーシステムの制限によって定義されています。これらの機能を再構築することは無駄であるだけでなく、今日実際に必要なものを構築する機会を逃すことにもなります。これらのシステムは、しばしば10年または20年前に、以前の世代のテクノロジーの制約の中で定義されており、「現状のまま」複製することはほとんど意味がありません。

機能パリティが真の要件である場合、このパターンは、うまく行うために必要なことを説明します。それは簡単な道ではなく、軽々しく踏み出すべき道でもありません。

仕組み

機能パリティは、述べるのは簡単な概念です。既存のシステムとまったく同じ機能と動作を備えた、より適切なテクノロジースタックで新しいシステムを構築します。新しいシステムが何をすべきかについての質問が出たときはいつでも、「既存のシステムがすることをする」と答えます。パリティがあることを知るには、現在のシステムが何をしているかを完全に理解し、新しいシステムが同じことをしていることを検証できる必要があります。

スコープ内にあるもの - 古いシステムは何をしますか？

機能パリティの最初の部分は、現在のシステムが何をするかの仕様を作成することです。以下の組み合わせが必要になる可能性があります。

システム調査

ユーザーアクション

ユーザーの役割、システムで表示できる機能（メニュー項目）、実行できるアクションは何ですか？各メニュー項目/アクションについて - 関連する画面、データ項目、表示できる検証ロジックは何ですか？アクションを実行するユーザーにどのような観察可能な結果がありますか？

バッチ処理

システムで定義されているバッチジョブは何ですか？いつトリガーされますか？どのような処理を実行しますか？どのような観察可能な結果がありますか？

インターフェースと統合

どのようなシステムが統合されていますか？

このシステムが顧客に提供するインターフェースは何ですか？契約（API、CFR、動作の期待/副作用）は何ですか？
このシステムが消費するインターフェースは何ですか？それらの契約は何ですか？
データベース経由で統合されているシステムまたはシステムの一部に注意してください（レポート/データ、および考古学を参照）。

コアアルゴリズム

ユーザーアクション、バッチ処理によってトリガーされる、複製する必要のあるよく知られたビジネスルールと計算。

レポート/データ

システムはどのようなレポートを、どのような形式で、どのようなデータから、いつ、どのくらいの頻度で作成しますか？

データはデータベース内でどのように変更されますか？データを変更するトリガーはありますか？何がそれらを発生させ、どのような手順を実行しますか？その深い道のりはどこまで続くのでしょうか？

このデータを使用してアクセスまたは統合されている他のシステムは何ですか？それらはどのような方法でそれを変更し、それらの変更にはどのような観察可能な動作がありますか？

考古学

システムが何をするかを完全に理解するには、考古学が必要になることがよくあります。画面AのデータフィールドYを変更すると、バッチジョブNの実行後にレポートCに値Zが表示されることを「考古学的プロセス」を通じて学びます。この考古学を実行するには、時間と、レガシーシステムについて最も経験豊富な人々の頭脳に多大な投資が必要になる可能性があります。

計測 - データに基づいて、何が使用されていますか？

既存のシステムがどのように使用されているかを理解するために、アクセスログやその他のシステムログなどの既存のレポートを分析する時間を費やすことは非常に価値があります。これらが利用できない場合は、データを基にして不必要な作業を回避できるため、既存のシステムを計測することに投資すると、良い結果が得られる可能性があります。

機能の価値 - 低価値の機能を削除できますか？

このパターンを採用する際にビジネスに負担をかけないように努めていますが、どの機能が低価値または使用されていないかを理解するためにユーザーと話し合うことは、スコープを管理するのに役立ちます。ただし、これにより、回避しようとしていた組織への影響/変更が再導入されます。

テストを使用して機能パリティを保証する - 新しいシステムは古いシステムが行ったことを行う

古いシステムが何をするかを知ることは最初の課題ですが、新しいシステムが確かに同じように機能することも確認する必要があります。これを確実に検証するには、新しいシステムに機能パリティがあることを証明するためのテストが必要です。以下は、テストを実装する必要がある領域のリストです。

ユーザージャーニーとユーザーエクスペリエンス

受け入れテストを使用する - 構築した機能がユーザーの視点から期待どおりに動作するかどうかを確認します。これらを主な検証アプローチとして依存しないように注意してください。それらはテストピラミッドの高い位置にあるためです。さらに、システムをユーザー機能、画面、フローに分解すると、これらのタイプのテストが多すぎる可能性が高いことに注意してください。

UIの動作（クライアント側の検証を含む）のテストは、比較的簡単に行うことができます。ここをクリックし、ある状態が表示されることを期待し、そこにデータを入力し、そこをクリックし、異なる状態が表示されることを期待します。選択したテクノロジーに適したツールを使用します。SPAアプリケーションの場合はユニットライクなテストフレームワーク、またはより従来のサーバー側でレンダリングされるアプリケーションの場合はCypressのようなものを使用します。

重要な場合（たとえば「エキスパートユーザー向けに最適化された」UIの場合）、レイアウト（およびルックアンドフィール）のテストはより困難ですが、役立つツールがあります（たとえば、Seleniumを使用したGalen）。

ユーザビリティとレイアウトについては、探索的テストに頼ることになるでしょう。

ビジネスロジック - コアアルゴリズム

コアアルゴリズムとコアビジネスロジックについては、既存システムのこれらの部分の周りに一連のユニットテストを構築していることを確認してください。これらは、既存のシステムで正常に実行されることがわかっているビジネスロジック/アルゴリズムの実行可能な仕様を提供します。これらのテストを新しいテクノロジースタックに移植することを含む修正されたTDDアプローチを使用すると、新しい実装に高い信頼性が得られます。テストを正しく移植したことを知ることに関連するリスクがあります - ミューテーションテストは、追加の保証を提供できます - 同様のミューテーションは、新旧の実装間で同様の失敗を引き起こします。

インターフェース - サービスプロバイダーおよびサービス顧客として

サービスプロバイダーとして：置き換えられる既存のシステムに対して実行するテストスイートを作成します - 実行可能な契約。これらの同じテストを新しい置き換えシステムに対して実行し、契約の遵守を確認します。UIの場合のように、これらのテストの範囲が大きくなりすぎるという罠に注意してください。

顧客として：テストモックを使用して、提供されたサービスと期待どおりに対話していることを検証します。コアビジネスロジックの場合のように、これらのモックを新しいテクノロジースタックに移行して、新しい実装が引き続き同じ方法で提供されたシステムと対話するようにします。さらに、外部システムのスタブを使用して、新しいテストの既知のデータセットを提供します。

どちらの場合も：プロキシは、機能/インタラクションパリティを保証するために使用するのに役立つツールです。プロキシを通信パスに挿入することで、古いシステムとのやり取りを記録できます。これらの記録を使用して、次のことができます。

顧客からのメッセージを再生する - そして、新しいシステムの応答を確認します
既知の良好な応答を再生できるスタブを作成する

データベースとレポート：これは非常に難しい場合があります - UIテストのようにピラミッドの頂点に注意してください。ここで、データベース/レポートは別のタイプのインターフェースです。それらを正常にテストするには、大量のテストデータが必要です。通常、作成/管理が困難です。

実装と進捗状況の追跡

スコープを定義するためのシステム調査が完了し、動作の実行可能な仕様を提供する包括的なテストスイートが整っていれば、比較的自信を持って実装を進めることができます。しかし、進捗状況をどのように追跡しますか？

メニュー項目/ユーザーアクション別

(または、システム調査時に特定されたその他の部分) これは危険を伴う可能性があります。なぜなら、追跡しているものがレイヤー（またはアーキテクチャ上の関心事）によってスライスされるリスクがあるからです。アーキテクチャレイヤーによるスライスは、価値の提供に深刻な影響を与え、進捗状況の可視性を低下させます。（つまり、フィーチャーがトップからボトムまで提供されるまで、価値は解放されず、_真の_進捗もありません。）

ここでの重要な前提は、アイテムまたはアクションがそれ自体でエンドユーザーに価値を提供できるということです。残念ながら、これはしばしばそうではありません。個々のプロセスステップの80％を提供したとしても、新しいシステム内でビジネスプロセス全体を完了することができない可能性があります。これは残念ながらよくある状況であり、高い完了レベルが報告されているにもかかわらず、使用可能なソフトウェアをテストまたはリリースできないのです。

垂直スライス

進捗状況の透明性を向上させますが、垂直スライスはシステム調査の出力にはならない可能性が高いです。したがって、マッピングを行う必要があります。より多くの作業が必要になり、要件が抜け落ちるリスクがあります。

エンドツーエンドプロセス

新しいソリューションへの個々のビジネスプロセスの完全な移行に基づいて進捗状況を追跡するため、テストは次のようになります。プロセスが交換システム内で完全に完了できるかどうか。これは、上記のようにユーザーアクションによる追跡と組み合わせることができますが、個々のプロセスステップを提供する作業が「所有」ビジネスプロセスによって優先されることを保証する場合に限ります。

著者の好みとしては、可能な限り、あらゆる作業の完了定義に、すべてのレイヤーにわたる完全なエンドツーエンドスコープを含めることを保証することです。

使用する場面

私たちは、このパターンをうまく適用し、成功の可能性を高めるために必要なものについて、上記の見解を示しました。フィーチャーパリティが目的である場合、フィーチャーの観点から何が必要かを判断するためにかなりの作業が必要であり、テストを通じてフィーチャーパリティの目標が満たされていることを保証するためにさらに多くの作業が関連付けられます。

一般的に、これは推奨しないパターンです。実際、Thoughtworksは、このパターンをテクノロジーレーダーで保留にしました。私たちはこのパターンを大きな機会損失だと考えています。古いシステムは時間の経過とともに肥大化し、ユーザーが使用しない多くの機能（2014年のStandish Groupのレポートによると50％）と、時間の経過とともに進化してきたビジネスプロセスを備えていることがよくあります。これらの機能を置き換えることは無駄です。代わりに、一歩下がって、ユーザーが現在何を必要としているかを理解し、ビジネスの成果と指標に対してこれらのニーズを優先するためのエネルギーを結集してみてください。

ただし、このパターンが特に適用可能なケースをいくつか見てきました。

パワーユーザー向けの高度に最適化されたユーザーインターフェースは、そっくりそのまま再現するのに適した候補です。高速で取引を実行するためにショートカットキーを使用するエージェントを考えてみてください。彼らが仕事で効果的であるためには、キーボードのみを使用して操作できる、ハイパー最適化されたユーザーインターフェースが必要になる場合があります。熟達するまでにかなりの時間がかかる可能性があり、効果の低下につながる変更は容認できません。
既知の仕様に基づく動作： パターンを適用するもう1つの使用例は、エンジニアリングまたは科学モデリングをサポートするシステムです。たとえば、有限要素解析ソルバーの場合、特定の入力で特定の出力が生成される必要があります。近代化プロジェクトの一環として、物理法則は変化しません。

これらの両方の場合において、フィーチャーパリティの必要性は、ある程度局所的である、つまりシステムの一部に限定されていると主張できます。システム全体の近代化のスコープを管理するアプローチが、これらの局所的なユースケースによって制約されるのは疑問です。

しかし、これらのケースは有効ですが、依然として例外的です。圧倒的に、フィーチャーパリティの取り組みは、フラストレーションの物語であることがわかっています。既存のフィーチャーを適切に理解するために必要なコストと労力が膨れ上がり、手抜きにつながり、それらのいくつかは使用されていないカットされるべきフィーチャーですが、通常、いくつかの重要なフィーチャーも犠牲になります。すべてがうまくいくと、ビジネスはビジネスのサポートの改善なしに多額の費用を支払います。これは、企業が将来がより良いテクノロジーエンゲージメントにかかっていることを知っている場合、良い話ではありません。

代替アプローチ

製品ラインの抽出または価値ストリームの抽出は、既存のシステムを通じて薄いスライスを識別するための戦略を提供するパターンです。主な違いの1つは、両方とも、レガシー要素を無効にして、より早くオフにすることを可能にしながら、フィードバックサイクルを短縮する方法を提供することです。
ビジネス価値を見て、それがアーキテクチャ上の意思決定に反映されていることを確認することで、フィーチャーパリティ主導のアプローチの問題点を強調できます。
より「全体的な」アプローチは、テクノロジーとビジネスプロセスを同じ問題の一部として扱うことで、フィーチャーパリティの問題点を強調するのに役立ちます。特にフィーチャーパリティの場合、これは多くの場合、現在のビジネスプロセスがレガシーテクノロジーに必要な回避策と妥協の結果であることを強調できます。テクノロジーを置き換えるだけでは、少なくとも問題の半分は解決されないままになります。
ユーザー調査は、既存のビジネスプロセスがもはや目的に適合していないことを強調するのに役立ちます。あるケースでは、既存のスタッフの数日間のシャドウイングだけで、現在のプロセスが非常に壊れていたため、フィーチャーパリティが不適切であることが明らかになりました。エンドユーザーに話を聞くことは常に良いことです。

事例：物流システムの置き換え

ある物流組織は、荷物の受け入れ、経路計画、配送に使用される老朽化したソフトウェアを置き換える計画に従事していました。この一環として、ビジネス関係者との関わりが比較的低いIT主導のイニシアチブに合意しました。テクノロジーの観点からは、「フィーチャーパリティ」を実行するだけで、時代遅れのテクノロジーを置き換えるという差し迫ったニーズを解決できると考えていました。このプログラムの一環として、クライアントから荷物を受け入れるシステムを置き換えるために主要な作業が行われました。私たちはこのプログラムの終わりに近づいて関与しました。

ビジネス関係者との関わりが低いことはプログラムにとってリスクであると感じました。特に、別のプロジェクトを通じて、ビジネスが開発の取り組みに不満を感じていると聞いたからです。この一環として、財務チームを含む主要な関係者と話しました。これは、組織にとって比較的少数の顧客しか収益性が高くないことを示すレビューが行われたことを知ったときです。次に、これは「パッケージタイプ」のごく一部のみが収益性が高く、特別な取り扱い要件のために多くが組織のお金を失っていることを意味しました。そのため、ビジネスにはこれらのパッケージの取り扱いを停止する計画がありました。

「フィーチャーパリティ」プロジェクトの非常に多くの労力が、まさにこれらのパッケージ、つまりビジネスがもはや必要がないと言ったパッケージに対処するために費やされたことが判明しました。ビジネスは、これらの困難なエッジケースがなければ、プロセスとそれに伴うソフトウェアがはるかに単純になることを期待していました。この場合、「フィーチャーパリティ」は、ビジネスがもはや必要としない要件を処理するために多大な時間とお金が費やされることになり、同時にビジネスの観点からITの評判をさらに損なうことになりました。

事例：eコマース組織のプラットフォーム再構築

この組織は急速な成長期を享受していましたが、数年間IT支出を優先していませんでした。これにより、現在のソリューションの多くの要素を置き換えるという比較的緊急のニーズが生じました。たとえば、特定の期間中、コアシステムを圧倒しないように、販売数を減速させる必要がありました。ビジネスの観点からは理想的ではありません。

主要なビジネスオペレーションの多くは同じメインフレームによって処理されていましたが、これは彼らの電子商取引業務の初期段階で最初に委託されました。このシステムから要素を抽出することは、技術的に困難になることは明らかでした。同時に、ビジネスリーダーは、いくつかの破壊的な失敗したプロジェクトを見て、スタッフへのこれ以上の混乱を最小限に抑えたいと考えていました。さらなる課題は、より段階的なアプローチが使用された場合、現在のプロセスとシステムでは、移行する製品ラインの優先順位を付けることが非常に困難であることです。要するに、販売しているものがお金を稼いでいるのか、そうでないのかを理解することが非常に困難だったため、すべてを一度に移動するしかないと感じられました。これらの課題に基づいて、持っていたものを複製することが最善かつ最もリスクの低いアプローチであると感じられました。

現在のビジネスプロセスは、一見すると、同じメインフレームにまとめて実装されていたため、「フィーチャーパリティ」の交換のスコープは、本質的にビジネス全体のすべての主要な活動とプロセスを意味していました。彼らは、これをベンダー選定プロセスの入力として使用するという計画で、交換システムの「スコープ内」の現状プロセスを文書化する取り組みに着手しました。

すぐにいくつかのことが明らかになりました。1つは、ビジネスが行ったほとんどすべての活動を本当に実行する必要があるということでした。「現状」機能を文書化するたびに、「フィーチャーパリティ」を提供するために含める必要のあるものがさらに明らかになりました。次に、歴史的な回避策、長年の変化する要件、多くの未解決のバグのために、レガシーシステムで実際に作業した人々が望んでいたのは、同じものではありませんでした。それはほとんどの場合、彼らの仕事をより困難にし、エラーと遅延の主な原因でした。最後に、バグと回避策のために、いくつかの主要なプロセスが実際には手作りのスプレッドシートで「システム外」で実行されていることが明らかになりました。主要なビジネスデータがメインフレームから抽出され、スプレッドシートを介してビジネスプロセスを実行するために使用され、その後、変更されたデータがメインフレームにアップロードされました。

この時点で、「フィーチャーパリティ」はリスクが高すぎ、スコープが拡大し続けていると感じる人もいました。これは、要件収集プロセスが完了する前であり、その取り組みの明確な終了日はありませんでした。「フィーチャーパリティ」を継続することはリスクが高すぎ、ビジネスが必要とするものを提供しないと感じたため、私たちの関与はこの段階で終了しました。特に、重要なビジネス指標が不足しているため、より段階的なアプローチを優先することが不可能になりました。数年後、彼らはまだ元の期限を過ぎて「現状」要件プロセスを行っていました。

適切な指標と、ビジネスの観点から機能の要素を優先する能力が不足していると、組織は「フィーチャーパリティ」アプローチを余儀なくされることがよくあります。この場合、さまざまな製品ラインに関する主要なビジネス指標を収集するための初期の取り組みは、問題を解決する方法を示唆できたと考えています。これは、適切なビジネスコンテキストと関与なしでは、適切な技術的決定を下すことができないことを示す素晴らしい例です。

事例：金融計算サービスの置き換え成功

私たちのチームの1つは、大規模な金融機関のために働いていました。彼らは、複雑な財務計算を実行する既存のサービスを近代化したいと考えていました。財務計算の仕様は固定されており、サービスへのインターフェイスは類似しており、テクノロジーのみを更新する必要がありました。J2EE Session EJB実装から、最新バージョン（当時）のJavaのSOAP Webサービスへ。

チームは、セットアップ、実行、アサーションの責任を明確に分離して、既存の実装の周りに豊富なテストスイートを作成しました。

図1：tests_for_feature_parity

テストが完了したら、実行アダプターを最小限のリスクで置き換えることができ、古いシステムと同じ実行可能な仕様を満たす新しい実装を作成できます。

重要な修正

2021年7月27日