 |
RUP の拡張: 引退フェーズ |
By Scott W.
Ambler.
目次
図1に示すように、EUP ライフサイクルの最後のフェーズは引退フェーズです。このフェーズの目的はシステムのリリースを(場合によってはシステム全体を)稼動状態から取り除くことで、この作業を「退役 (decommisioning)」や「日没 (sunsetting)」と呼ぶこともあります。システムの引退は、旧システムを廃止したり新しいシステムでリプレースしたりする場合に、今日の多くの組織が直面する重大な問題です。この作業は、業務の運用にできるだけ影響を出さずに終わらせるよう努力しなければなりません。これまでに経験のある人なら、問題なく終わらせるためにどれだけ複雑なことをしなければならないかが分かることでしょう。
図1. EUPのライフサイクル(2004年版)
システムのリリースの稼動を止める理由は、いくつか考えられます。
- システムを完全にリプレースするため: 自社開発の人事システムを、SAP(www.sap.com) や Oracle Financials(www.oracle.com) といった市販パッケージシステムでリプレースするのは珍しいことではありません。
- そのリリースのサポートを中止するため: 組織によっては複数のリリースを同時に稼動させ、古いリリースを順次停止していきます。
- 現在のビジネスモデルではそのシステムが必要でなくなったため: 組織が新しいシステムを開発して新しいビジネス分野を試みたけれども、費用対効果が低いことが判明した、などといったことが考えられます。
- システムが重複しているため: 合併や買収によって大きくなった組織は、運用を一本化したときにシステムが重複することがよくあります。
- システムが時代遅れになったため
ほとんどの場合、旧リリースの引退は新バージョンのシステムの導入と同時に行われ、比較的簡単に実施できます。新しいリリースの導入には、前のリリースを削除するステップが含まれるのが普通です。しかし、新しいバージョンを導入するからといって、単純にリリースを引退させられないこともあります。たとえば、ユーザに対して新しいリリースに移行するよう強制できない場合や、下位互換性を保つために旧システムを保守しなければならない場合などです。
システムを完全に引退させるのは、また別の話です。この場合、引退させるシステムの機能を新しいバージョンで提供することができません。その機能(およびそれに関わるデータ)は、別のシステムで実装するか(たいていはエンドユーザにとってまるで異なる方法で)、完全になくなることになります。それによって、その機能とやり取りしていた他のシステムを変更するために、かなりの作業をやり直す必要が生じるかもしれません。システムの完全引退作業は、通常、そのシステムをリプレースする別のシステムの実装と並行して行います。自社開発のシステムを市販パッケージシステムでリプレースする場合などです。そのような状況では、2 つの作業を緊密に協調させて行わなければなりませんし、場合によっては同じメンバーが担当することもあります。
図2はEUPの引退フェーズのワークフローを示したものです。
図2. 引退フェーズのワークフロー
引退フェーズの主な作業には、次のようなものがあります。
- システムの相互作用を分析する: 単独で存在しているシステムはほとんどなく、通常は何らかの形で他のシステムと相互作用しています。引退フェーズの1つの作業として、相互作用を洗い出し、分析し、レガシー統合モデリングによってそれぞれに対処しなければなりません。
- 引退戦略を決定する: 戦略は状況によって変わります。第 1 に、システムの新しいリリースの場合は、簡単なデータ変換が必要になることがあります。アプリケーションコードのそのリリースや新しいバージョンの開発サイクルで行った一連のデータベースリファクタリングを実施することになるかもしれません。第 2 に、既存システムを社内で開発した新システムでリプレースする場合には、新システムの開発チームが、相互作用のアーキテクチャ、設計、実装を担当することでしょう。この作業は、エンタープライズアーキテクトの指導やレガシー分析の結果に従って行い、他システムへの影響が最小限になるようにしなければなりません。第 3 に、市販パッケージシステムに置き換える場合には、その市販パッケージ製品を拡張する必要があるかもしれません。つまり、市販パッケージベンダーを巻き込んで、必要な追加機能を開発する可能性があるということです。第 4 に、システムを完全に引退させるのがもっとも困難です。外部システムを書き直したり、場合によっては他のシステムまで引退させなければならないこともあります(それらのシステムでどうしても必要な機能がなくなってしまうため)。他システムの所有者と協力して、それらのシステムで必要な情報をどこから手に入れられるかを探す手伝いをしなければなりません。
- ドキュメントを更新する: 運用・サポート手順、エンタープライズアーキテクチャモデル、システムポートフォリオドキュメント、アドミニストレーションドキュメント、システム概要ドキュメントなど、幅広いドキュメントを更新する必要があります(引退したことを書き留めます)。
- テストする: 移行フェーズでシステムをテストするのと同じように、移行用のツールもテストしなければなりません。EUP の発展型のアプローチを取っている場合には、移行や削除用のツールを開発しながらテストもすることになります。すべてのデータを含むシステム全体をサポートできるテスト環境があればよいのですが、それだけの余裕がないこともあります。その場合には、使用するデータがシステム全体を代表するサンプルとなっているよう、気を付けてください。
- ユーザを移行させる: 通常は、ある日突然システムにアクセスできないようにし、それで終わりにするというわけにはいきません。引退についてエンドユーザに前もって適切な情報を知らせ、他のシステムへの移行をサポートする必要があります。
- アーカイブを作成する: これまでのデータや、コード、ドキュメントなどのシステム成果物のアーカイブを適切に作成し、今後必要になった場合に復元できるようにしなければなりません。
- システムを撤去する: これはたいてい複雑な仕事です。データの移行と変換を行い、引退するシステムにアクセスできなくして痕跡をすべて消し去り、引退するシステムと相互作用している他システムをすべて更新しなければなりません。作業を始める前に、システム全体のバックアップを取っておくとよいでしよう。もしかすると、システムを急いで再現する必要が生じるかもしれないからです。
EUP の作業分野という点では、以下の作業が発生します。
- 分析/設計: システムの機能を他のシステムで提供する場合には、その作業の分析と設計を行います。このとき一般的には、既存システムを広範囲に分析し ( レガシー分析と呼ぶことも多い ) 、他システムとの結びつきを洗い出します。引退するシステムに依存しないように、他システムを再設計し、作り変えなければなりません。さらに、システムとそのデータを削除するプログラムも設計します。
- 実装: システムとそのデータを削除するプログラムを開発します。必要に応じて、引退するシステムとやり取りしている他システムを変更したり、データをアーカイブして別の場所に移したりします。
- テスト: システムを引退させるときに使うプログラムをテストします。また、システムとやり取りしている他システムを変更した場合は、それもテストします。
- 導入: 引退フェーズの最終ステップの 1 つは、実際にシステムを撤去することです。このときに、コードとデータを削除し、残りの旧システムのデータを適切に変換し、スケジューリングされたジョブ ( バックアップなど ) を削除します。
- 構成及び変更管理: 引退フェーズで受け取った引退するシステムに対する変更依頼や不具合報告は、一般的には受け付けませんが、別のシステムに割り当て直すこともあります。削除予定のシステムに修正版を適用することはほとんどなく、拡張依頼は完全に却下されます。引退するシステムの最後の構成について適切なアーカイブを作成します。
- プロジェクト管理: 引退フェーズの作業は、他のフェーズの場合と同じように管理します。
- 環境: 引退フェーズでは、必要に応じてサポート環境を変更します。
- 運用及びサポート: 引退予定のリリースも、最終的に削除するまでは、今までどおり運用・サポートを行わなければなりません。ユーザは引退するシステムの使用をやめるよう勧められるため、このフェーズでのサポートは一般的に最低限に抑えられます。
- ポートフォリオ管理: ポートフォリオ管理者は、システムを取り除くことにより会社全体のポートフォリオにどのような影響が及ぶかを評価し、それに対処しなければなりません。たとえば、なくなる主要な機能について調査して、同様のものを提供するプロジェクトを承認することもあります。
- エンタープライズ・アーキテクチャ: エンタープライズ・アーキテクトは、“現状 (as is)”モデルを変更して、システムが取り除かれるという事実を反映させなければなりません。
- エンタープライズ・アドミニストレーション: システムを引退させるときには、システムの撤去を会社のシステム構成に反映しなければなりません。
EUP では 1 つのフェーズになっていますが、実際には引退に関わるほとんどの作業は独立したプロジェクトとして管理されます。単純なシステムの場合、引退は通常 1 回の反復で行われます。その反復で、利害関係者はシステムがなくなることを知らされ、きちんとしたやり方でアクセスが止められ、システムとドキュメントが取り除かれます。もちろん、重要なシステムの場合には、これも大変な作業になります。すべての利害関係者に通知を送らなければなりませんし、継続して必要な機能の代替手段を計画しなければならず、システムの形跡をすべて見つけて消さなければなりません。
システムが大規模であったり、複雑であったり、頻繁に使われている場合には、複数回の反復が必要になるかもしれません。非常に重要なビジネス機能を持ったシステムを引退させる場合には、引退するシステムと後継のシステムとをしばらくの間並行稼動させ、新しいシステムで機能が正しく動くのを確認することも珍しくありません。新しいシステムが満足のいくものだと利害関係者が納得してはじめて、旧システムは停止されます。こうすることで、新システムと旧システムの結果を比較して新システムが正しく機能していることを検証できますし、何かがうまくいかなかった場合にはすぐに旧システムに戻すことができます。ただし、ハードウェアやサポート、複数のシステムを並行稼動させるのに必要な時間など、多大なコストがかかるため、たいていは非常に重要なシステムの場合にしか行われません。
もう 1 つのやり方は、システムを少しずつ引退させる方法です。システムを少しずつ開発するのと同じように、引退も少しずつ行うことがよくあります。システムの一部を取り除くのと並行して、同様の機能を別のシステムに追加していきます。このやり方だと 1 度にすべて行うよりもずっと簡単にできることがありますが、時間はかかります。これを行うときには、ユーザに対する影響も考慮しなければなりません。すべて 1 度に引退させた方がユーザには楽でしょうか。それとも新しいシステムに少しずつ移行する方が好まれるでしょうか。
図3に示すように、引退フェーズはリリース引退 (Release Retirement: RET) マイルストーンで終わります。RET マイルストーンでは、システムの削除が成功したかどうかを判断します。このマイルストーンでは以下の問いに答えなければなりません。
- システムを削除した結果、業務にどのような影響があるか。利害関係者はそれを受け入れてくれるか。
- システムの削除は成功したか。
図3. EUPのフェーズとマイルストーン
