レガシー・システムの発展にRUPは使えるか

コンテンツ: レガシー・システムを評価する 発展させるレガシー・システムの特徴は? レガシー・システムをどのように発展させるか? その計画は健全なビジネス・ディシジョンか？ ラショナル統一プロセスの使用 RUPと親和性のあるベースラインの設定 発展: RUPで進めていきましょう RUPベースの発展サイクル 変更の制限 謝辞 参考文献 著者について 原文: 原文

既存システムに対してRUPを使用できないでしょうか? よく考えてください。

ラショナル統一プロセス- (RUP)について一部からは、新規システムの開発を何もないフィールドでゼロから行う新規開発においてのみ有効とする声が聞かれます。こうした意見では、RUPは拡張開発や「レガシー」システムの発展には使用できないと主張されますが、私はこれに強く異を唱えます。私は、RUPのかなりの部分が既存システムの発展に使用できることを知っていますし、実際に現在RUPを使用する現場の約80%で何らかの形のレガシー・システムが使用されているのです。

1. 発展させるレガシー・システムの特徴は何か?
2. レガシー・システムをどのように発展させるか?
3. その計画は健全なビジネス・ディシジョンか？
   

以下、これらの点について詳細を話していきます。

レガシー・システムとは、「新規の絶えず変化を続けるビジネス要件を満たすための変更や発展に強く逆らうもの…」1と定義されています。通常これは、システムが大規模で旧式であることを意味します。この点から、こうした問いを発する場合、「当初の開発がRUPを使用せずに行われたシステム」であることも意味しています。

当初の開発がRUPを使用して行われていれば、必要とされるほとんどの成果物は何かしらの形で存在しています。この場合、システムを発展させるには、完全な開発サイクル(方向付け、推敲、作成、および移行)をさらに1つ追加するだけで、方向付けと推敲は計画の複雑さによるものの比較的小規模に済みます。たとえば、アーキテクチャーに大きな影響のない場合のケースで、このようなケースは保守サイクル(別記事で解説)として分類されます。

ここでは、RUPを使用せずに開発されたレガシー・システムを考えます。つまり、開発の成果物が存在しても、通常のRUPにおける成果物名を持たなかったり、RUPにおける形式ではなかったりします。またしばしば、成果物が紛失していたり、非常に古かったりして、誰もがシステムに適切であるとは思えない場合が多くあります。RUPではない他の手法が用いられることもあり、設計はオブジェクト指向テクノロジーを使用せずに行われ、要求にはユースケースが使用されていないなどが考えられます。

また、レガシー・システムには、すべて破棄してしまうのでなく、何かしらの形で再利用する価値のある相当の資産(「レガシー(遺産)」があることも考えられます。このため、現行資産の価値を評価する必要があります。価値があるのはコードなのか、設計か、要求か-アルゴリズムやデータか-あるいは製品が有する市場シェアなのか? 残念なことに、システムが旧式化するほど、既存の資産を把握し利用するのは困難になります。ソフトウェア関連の文書は廃版となっていることが多く、多くの場合、設計はコードそのものからリバース・エンジニアリングしなければなりません(「設計のリカバリー」を必要とする)。

レガシー・システムを扱うことは、一般的に否定的にとらえられますが、比較を行い情報ソースとして使用できる「先行」システムが存在することは、実際には大きな価値があります。先例のないシステムを定義して開発することは、より困難な作業といえるでしょう。

レガシー・システムでは特に、以下の点の識別が容易に行えます。

• 要求とビジネス・ルール
• アーキテクチャー上、重要な項目
• 主要なユースケース
• ユーザーの優先順位、希望、および振る舞い

唯一危険な点として、レガシー・システムが足かせになり、斬新なアプローチを検討し考慮する上での障害となることがあげられます。

発展のための変更は、単純な機能拡張から根本的なアーキテクチャーの変更、完全な設計のやり直しや再実装に至るまで広い範囲に及びます。そして、それぞれに異なる技術上のソリューションや異なるプロセスの公式度レベルが適用されます。以下は、レガシー・システム発展の例です。

• 拡張
• 外観上の変更
• マイグレーション
• 再設計
• 「上記すべて」

拡張　単純なケースでは、機能やフィーチャーを追加するだけで済みます。規制の変更、新しいビジネス・ニーズや、競合他社が導入した新規フィーチャーなどが存在する場合、いずれの場合もこれに対応して既存のシステムの発展が必要になります。レガシー・システムでは多くの場合、システムが旧式化するほど、単純な機能追加ですら困難になります。拡張が長年に渡り蓄積した結果、システム・アーキテクチャーの整合性が失われることになり、システム拡張がより困難になります。

外観上の変更　システム全体を破棄してしまわず、外観を新しくしたり、新しいGUIテクノロジーやインターフェースを取り入れたりすることは頻繁に行われます。システムの特定のコンポーネントをラッピングして新しいインターフェースを導入したり、再実装を可能にしたりすることで、開発を最小限にとどめながら満足のゆく結果を収めることができます。このケースは、たとえば素早く「Web対応」を図りたい多くのアプリケーションの場合に該当します。

マイグレーション　システムが、基盤となるハードウェア、オペレーティング・システム、またはミドルウェアの有効期間を超過する場合があります。依存するテクノロジーの保守期間が過ぎていたり、維持に非常にコストがかかる場合のソリューションとして、レガシー・システムを新しいプラットフォーム(ハードウェアまたはソフトウェア)に移行して、既存のソフトウェアの多くをそのまま使用します。たとえば、DEC VAX VMS環境用に開発したソフトウェアはUNIXおよびLinuxベースの各種プラットフォームに迅速にマイグレーションされるでしょう。このようなケースとして、私たちのプロプリエタリー・プラットフォームから各種のUNIXベースのプラットフォームにRational Environment(200万行コードにおよぶ製品)をマイグレーションし、現在Rational Apexとして知られる製品が存在します。拡張は新しいドメイン固有の振る舞いを追加するのに対し、マイグレーションはレガシー・システムを異なるテクノロジー・プラットフォームに適合させるものです。マイグレーションにおいては、ドメイン固有の価値はあまりありませんが、タイミングよく効率のよい形で行わないと、システム全体を終わらせてしまうことになりえます。

再設計　レガシー・システムがミッション・クリティカルなシステムであり、進化させることが極めて困難で、スケールアップできず、廃止されたハードウェア/ソフトウェア・テクノロジーに依存している場合、再設計が必要になります。通常これは、現存する顧客のシステムを失くす訳にはいかないので、段階的に行う必要があります。Canadian Automated Air Traffic Systemのケースでは、20年以上も昔の非常に旧式のハードウェアとオペレーティング・システムで稼動するシステムが使用されていました。再設計については、本論で論じる内容でないと思われるかもしれませんが、スクラッチからシステムの発展を計画する場合でも、レガシー・システムを利用して新しいシステムの主要な側面を理解することができます。これには、プラス、マイナス両方の経験と知識が豊富に含まれているのです。

「上記すべて」　最後に、企業ではマイグレーション、外観上の変更、そして再設計を連続して行う場合があります。これは、レガシー・システムから新しいプラットフォームに素早く移行して、市場からの需要に応えるためシステムの外観を刷新した上で、システムの再設計を行い、新しいテクノロジー-ソフトウェア・コンポーネント、新しい言語、ミドルウェア-を基に旧コードを固まりごとに段階的に置き換えて、システムを発展させるものです。これは最も困難でリスクを伴うアプローチですが、達成は可能です。私の記憶では、IBM AS/400プラットフォーム上で開発された数百万行のRPG (Report Program Generator)コードを含む大規模なMIS(経営情報システム)アプリケーションを使用する顧客で、Java環境に移行してWebと各種のWindowsおよびUNIXシステムでの稼動を図ったことがあります。このケースでは、すでにインストールされたシステムを大きく混乱させることなく、2〜3年の期間でJava環境のアプリケーションを再設計して実装することができました。

レガシー・システムを発展させるのは、システムが存在するからではありません。システムの変更に意義があるかを問わねばなりません。一般的に、レガシー・システムを存続させることは実際に妥当なのでしょう。それらの開発および取得は典型的な埋没コストであり、そして多くの場合、ビジネス上においてシステムを破棄する正当な理由がありません。一方、機会原価も存在します。リソースが制限され、限りない新規要求がある場合、レガシー・システムを維持することは、わずかなリソースを新規項目に費やさないための意思決定と言えます。もし、システムの維持だけを図るのであれば-意義のあるビジネス上の理由でなく感情的、伝統的理由のため、あるいは代替策を検討していないためにシステムにリソースを割いているのであれば-おそらくシステムの維持を続ける理由はないでしょう。

上記のいずれかによるレガシー・システムの発展を行う場合、最初に適用すべきはRUPの基本原則です。

• 初期リスク軽減
• 反復型開発
• 具体的で測定可能な証拠に基づく進行状況の評価
• 小規模で権限を持つチームを中心とした組織
• 継続した品質の検証
• スコープの管理
• 必要とされる成果物のみの作成

これらの原則は、新規開発に固有の原則ではなく、どのようなタイプのソフトウェア開発にも当てはまります。RUPライフサイクルの基本的な雛形(方向付け、推敲、作成、および移行の4フェーズ)は、レガシー・システム・プロジェクトに完全に適用することができます。言い換えれば、RUPのプロジェクト管理の多くの作業はそのまま適用することができます。レガシー・システムであるからと言って、期待する達成内容を記述した開発構想書、主要マイルストーンと達成内容を示すプロジェクト計画、反復とその固有の目標、およびリスク・リストを持たない理由はありません。また、開発企画書を作成して、プロジェクトを行う利点と採択したアプローチを説明できるようにする必要があります。この開発企画書は、コストの見積り、要員配置およびその他要求(ツール、ミドルウェア、トレーニング)に基づくもので、言い換えると、行うべき作業の範囲に依存するものでもあります。移行フェーズへと進むにつれ、旧システムに替わる新しいシステムの展開方法を示した導入計画書が必要になります。

単にRUPのライフサイクルを適用するだけでなく、RUPの他の作業分野を使用して発展を進めるには、開始点を設定します。レガシー・システムを表現した重要な成果物の最小セットを識別する必要があります。発展の範囲に応じて、次のものが(あるいはこれ以上のものが)必要になります。

• 要求
• アーキテクチャーと設計
• テスト
• ユーザー文書

一旦、RUP成果物のベースラインを設定したら、RUPの発展サイクルと同様のやり方でレガシー・プロジェクトを進めることができます。

RUPに沿ってプロジェクトを進めるために、最小セットの成果物を設定するには、レガシー・システムのリバース・エンジニアリングが必要になります。もともとRUPを使用して開発された場合と同様にプロジェクトを進めるために十分な情報を、リバース・エンジニアリングを用いて識別、抽出または再作成を行います。この段階は、多くのプロジェクト・マネージャーは、レガシー・プロジェクトに合わせたRUPの使用を放棄しがちなポイントです。このリバース・エンジニアリング作業が大きな時間の浪費と考えるからです。しかし、それほど労力を費やす必要はありません。ここで意図するのは、成果物を1つずつ作り直すことではなく、現行システムの主要な特質を理解し、何を保持し、何を置換・更新するかを決めることにあります。

要求　レガシー・システムの価値として最も重要なのは、新しいシステムに最低限の仕様を用意することにあります。たとえば私たちがRational Apexを開始した際、開発構想書の第1稿には「…最初にRational Environment (デルタ・バージョン)の機能をすべて網羅し、速度を低下しないこと」と記されていました。続いて我々は、Rational Environmentとの差異(追加するフィーチャー、除去するフィーチャー)を記しました。効率のよいチームは、レガシー・システムの要求を回顧して記述するようなことはしないものです。つまり、何もない状態から要求をし直す必要はなく、主要ユースケースを識別すればよいのです。これらは、既に現行のユーザー・マニュアルに記載されているはずです。ユースケースの一覧(ユースケースの概要)があれば十分です。詳細を記すのは、変更の必要があるユースケースだけです。機能外の要求の多くは、マーケティングやインストールの文書から派生させることができます。これらは、機能、サイズやパフォーマンス特性、オペレーティング・システム、メモリー、周辺機器、他のソフトウェア、一般的な制約、「〜性」といったものの多くです。要求管理ツールを使用してしないのであれば、この時点で一覧の作成を始めるとよいでしょう。

アーキテクチャーと設計　レガシー・システムをオブジェクト指向(OO)テクノロジーを使用して完全に再設計する必要はありません。ただし、最低限のアーキテクチャー上の情報は必要になります。実装ビューから始まる最低限のソフトウェア・アーキテクチャー・説明書を作成することができます。各種サブシステムやコードの主要な部分は? 重要なインターフェースは何か? などの情報から、レガシー・システムが分散している場合は配置ビューおよびプロセス・ビューを識別できます。既存のソフトウェアの一覧を詳細化し、各要素と要素間の関係を明確に識別する必要があります。ソフトウェアが構成管理下にない場合は、この時点で管理を開始すべきです。

インターフェースとインターフェースがどのように使われるかのシナリオを記述することが重要です。後ほど、発展による影響を受けないサブシステム(レガシー・システムの安定したコアとなる再利用可能な固まり)の識別を行います。詳細なソフトウェア設計文書やインターフェースの記述は必要でしょうか? これらが既に存在し信頼できるのであれば結構ですが、どの部分を変更するか分からないうちに手間をかけて作成することのないようにしてください。その場合でも対応はケース・バイ・ケースです。ツールを使用してこのリバース・エンジニアリングを行えば、作業は数日に収まるでしょう。

テスト　レガシー・システム用に作成したテスト、テスト・スクリプト、テスト・ケース、およびテスト・ハーネスは、多くの場合新しいシステムに適用できます。

ユーザー文書　完全な改訂を行うのでなければ、レガシー・システムのユーザー文書は、新しいシステムの良いベースラインとなります。一部の関連するガイドラインおよびチェック・ポイントとともに、これら成果物用のRUPテンプレートを使用できます。ただし、不要な要素を文書化することのないように、最初にテンプレートを調整する必要があるでしょう。多くの場合、参照を示す(既存の文書のどの部分に対応する情報があるかを示す)ことにより、テンプレートを埋めるすることができます。既存の文書がHTML形式でオンラインにある場合はURLを使用できるでしょう。

最後に、このリバース・エンジニアリングを行いながら作成する便利な追加成果物として、レガシー・システムで使用される用語集があります。これは、登場する用語を集めたもので、以降の作業で役に立つことでしょう。

このベースライン設定のステップはRUPに固有ではありません。どのようなプロセスまたは方式を使って進める場合でも、既存システムのリバース・エンジニアリングが必要になります。リバース・エンジニアリングについては、「Renaissance」のWebサイト(ソフトウェア・リエンジニアリングのEspritプロジェクト)が参考になります。1

最小限のRUP成果物のベースラインを設定したら(その大部分は既存情報の参照による)、次に進むことができます。新規の開発プロジェクトにおける作成および移行の反復と同様に、RUPのほとんどの作業が適用できます。ただし、この場合も、RUPからの採用にあたってはできる限り軽く済ませるように努め、不要な作業を行ったり不要な成果物を作成することのないようにしてください。

要求管理 新規要求をユースケースで表します。変更内容を正確に示すよう、既存の機能のユースケースを作り直さなければならない場合があります。複数のユースケースを追加または変更する場合は、用語集から小さなドメイン・モデルを派生させると便利です。

アーキテクチャーと設計 新規開発用にオブジェクト指向テクノロジーやUML (統一モデリング言語)を使用する場合があるでしょう。便利な方法として、特にシーケンス図を作成する場合に、最も影響を受けにくいサブシステムの一部を大きな複合クラスと見なすことができます。ユースケースで行ったのと同じように、設計モデルを作成できますが、詳細を検討するのはアーキテクチャー上重要なクラスや発展の必要があるクラスだけにします。これらのクラスには、その機能を既存のコードにマッピングしてプロキシーを作成できます。

長期的に大きな目標を持ち、レガシー・システムを段階的に完全に置き換えるのであれば、新しいシステムのアーキテクチャー設計を行い、既存システムへのマッピングを行う必要があります。既存のコードを包むラッパーを作成し、OOテクノロジーを使用して設計したように見せることができます。各種のラッパーを使用した完全なシステムの再アセンブリーは、推敲フェーズの内部マイルストーンとすることができます。ユースケース設計に進むにつれ、ユースケースの実現の中で既存の各種サブシステムに対する影響が示されます。これにより、これらの「ラップされたサブシステム」のどれを変換、移植、または再作成するかを決めることができます。

ある限られたケースでは、Rational Roseなどのツールを使用して、既存のコード要素をUMLにリバース・エンジニアリングできます。ただし、結果をそのまま使用することは避けてください。これらは必ず熟練した人間による解釈が必要です。

導入 発展のスコープ次第で、新しいシステムの配置はまったくの新規開発の場合よりも困難な作業になります。システムを新しいアーキテクチャーに移行した場合や、その大部分を再開発した場合は、旧システムから新しいシステムに「即座に」移行するか、段階的な戦略により漸進的に移行を行うか、戦略を選ぶ必要があります。あるいは、新しいシステムを完全に信頼できるようになるまで、両方のシステムを並行して稼動することも可能です。実際に導入は、新しいアプリケーションの場合よりもレガシー・システムの方が注意を要することが多く、データ変換、運用の継続性、要員の再トレーニングなどの問題に対処する必要があります。

その他の作業分野 すべての作業、ガイドライン、技法、およびツールと合わせ、他のソフトウェア開発の原則も適用されます(たとえばテストや実装)。構成管理はより関連性を持ち、新規開発の場合よりもプロジェクトの初期から必要とされ、第1日目から既存の多くの成果物や、これらの複雑な依存関係について管理する必要があります。レガシー・システムの更新では、変更管理が中心的な作業になります。

多くの場合、レガシー・システムの再開発を決定することは、ビジネス・モデリングを使用したビジネス・プロセスのリエンジニアリングを行う機会でもあり、新しいシステムに異なる要求セットが生じる場合があります。

RUPの完了 レガシー・システムの発展プロジェクトで開発個別定義書を作成する場合、RUPにはリバース・エンジニアリング、設計のリカバリー、データベース変換、または「ラッパー」使用の技法のための作業やガイドラインが含まれていないことに気が付くでしょう。これらの技法は、レガシー・システムの状態と使用されるテクノロジーに大きく依存しており、一般化することは困難です。各種のアプローチおよび技法への参照は、末尾の参考文献1、2、および4をご覧ください。

RUPの方向付けフェーズは、開発構想書および開発企画書、および再作成する成果物を指定した初期の開発個別定義書を作成するよう指定します。このフェーズでは、一部の成果物(主に要求およびアーキテクチャー)のリバース・エンジニアリング・プロセスも開始し、適切な発展戦略を選択し、コストを予測できるようにします。

推敲フェーズでは、作業を進める上で必要な最小限の成果物セットであるRUPベースラインを完成させます。これには、一部の旧成果物から新しいツール・セットへの変換も含まれます。単純な拡張の場合、これは1度の短い反復で行うことができます。ただし、マイグレーションや再設計などのように多数のアーキテクチャー変更が必要な場合は、この推敲フェーズで何度か反復を行い、新しいアーキテクチャー・ベースラインを実装します。また、この推敲フェーズが中心的なフェーズとなり、作成および移行フェーズで行うことがわずかである場合もあります。テストは新しい環境に配置され、早い段階で回帰テストを開始できます。まったくの新規開発における推敲フェーズと異なり、当初から管理すべき多数の成果物-とりわけコード-が存在し、変更および構成管理の原則による作業を早くから強調する必要があります。

作成フェーズは、他のRUPプロジェクトと大きく異なることはありません。追加要素のリバース・エンジニアリング、再設計、および文書化を必要に応じて行います。あるいは、他言語への移植または翻訳を行います。

移行フェーズは、旧システムから新システムへの配置戦略に応じて、より慎重に行う必要があります。上記の導入のセクションを参照してください。

明らかにRUPは、レガシー・システムの発展のステージングにとって有効であり、反復ごとに具体的で測定可能な目標を設けることができます。Rational Apexのプロジェクト・マネージャーJoe Marascoは、次のように記しています。

どの機能を最初に移行するか、どのパーツをそのままの形で移行するか、どれを後の反復で移行するかを決定した。一旦AIXバージョンが安定すると、Sun OSバージョンは後の反復に持ち越された。蝶がサナギから一日のうちに羽化するのを見ると言うより、その変態を計画し、反復ごとに進化を追跡するのである。この他の方法で複雑なレガシー・システムの発展を管理できるとは思わない。

どのようにレガシー・システムへRUPを適用するか？

• 最初に、何をしようとしているのかを理解する
• 次に、所有している資産を有効に活用する
• そして、RUPの原則(必ずしも詳細でない)に重点を置く

予想される発展のタイプや、レガシー・システムについてどの程度の情報が利用できるかに応じて調整や公式レベルは変化しますが、RUPの多くの部分をレガシー・システムの発展に使用することができます。既存のシステムから、どのくらいの成果物を引き出し、リバース・エンジニアリングし、そして実際に開発に必要があるかは、発展の複雑さと、許容されるリスクの度合いにより異なります。

1つ注意点をあげるならば、私たちは、一度にあまりに多くの変更を試みようとして失敗したプロジェクトを目にしてきました。レガシー・システムの大きな改良(例えば、新しいプラットフォームへのマイグレーション)をプロセスの変更と同時に行い(例えば、RUPへの移行)、ツール・セットを変更する(例えば、Rational Suitesへの移行)といった具合です。新しいプロセスやツールの導入は、レガシー・システムを大きく改良する前に、プロジェクトの初期に行い、開発者がRUPとその哲学、内容、そしてこれをサポートするツールに習熟できるようにするのが好ましい方法です。多くの不確定要素や変更を同時に導入して、プロジェクトのリスクを増幅させるのは避けてください。

本文書の構成にあたり、独自の経験に基づき手助けをしてくれた友人と同僚のDean Leffingwell、Bruce MacIsaac、Joe Marasco、Walker Royce、John Smith、Grady Booch、Craig Larman、そしてRational内のプロセス検討フォーラムの多くの参加者に感謝します。彼らから繰り返し受けた質問は、RUPをレガシー・システムの発展に使用できるのか、本稿で回答を示す上で貴重な材料となりました。また、私のフランス語まじりの英語を指摘してくれたCatherine Southwoodにも感謝をします。

1. Jesus Bisbal et al, "Legacy Information Systems: Issues and Directions." IEEE Software 16 (5), Sept. 1999, 103-111.

2. Michael Brodie and Michael Stonebraker, Migrating Legacy Systems. San Francisco: Morgan Kaufmann Publishers, 1995.

3. Rational Unified Process 2001. Cupertino, California: Rational Software Corporation, 2001.

4. The RenaissanceWeb:www.comp.lancs.ac.uk/projects/renaissance.

1.Michael Brodie and Michael Stonebraker, Migrating Legacy Systems.San Francisco: Morgan Kaufmann Publishing, 1995.

2.Renaissance Webサイトを参照: http://www.comp.lancs.ac.uk/projects/renaissance.

IBMの提供するRationalソフトウェアは、ソフトウェア開発能力の向上を通じて、組織のビジネス・バリューの創造をお手伝いします。Rationalソフトウェア開発プラットフォームは、ソフトウェア・エンジニアリングのベスト・プラクティス、ツールおよびサービスを統合します。Rationalプラットフォームは、組織の応答性、回復性、集中力を向上させ、オンデマンド世界での成功を確約します。Rationalの標準ベースのクロス・プラットフォーム・ソリューションは、ソフトウェア開発チームによるビジネス・アプリケーション、組み込みシステムおよびソフトウェア製品の作成と拡大を支援します。詳細はRational Webにてご確認ください。