JP2008242792A - リプレース判断支援システムおよびリプレース判断支援方法 - Google Patents

Abstract

【課題】システムの老朽化対応にあたって顧客の意思決定を支援する必要がある。
【解決手段】基幹システムと個別システムとを含む業務システムのリプレースを管理するリプレース管理システムにおいて、提示部１２は、個別システムの老朽化対応を検討すべき段階で個別システムの移行に関する意思決定を支援する。対話型ユーザインタフェース９０は、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付ける。システム観点選択肢提示部８０は、個別システムの移行に関する客観的事実とシステム観点の価値判断材料とをもとに、システム観点から見た選択肢を提示する。ビジネス観点選択肢提示部８２は、ビジネス観点の価値判断材料をもとに、ビジネス観点から見た選択肢を提示する。
【選択図】図６

Description

この発明は、業務システムのリプレース管理技術に関する。

企業の業務システムのライフサイクルは、要求分析・仕様決定から始まり、設計、実装、テスト、運用、保守を経て、廃棄に至るまでの一連のプロセスである。要求分析の詰めが甘いと、それ以降のシステム設計、実装に顧客の要求が正しく反映されず、テストや運用段階で発見された不具合を修正するために、プログラムを改良したり、システム設計をやり直すなど、システムの保守に時間と労力を費やさなければならない。企業を取り巻く社会の変化やＩＴ（Information Technology）技術の革新により、業務システムのライフサイクルが短くなってきており、新規システムの企画・開発に投資するのがよいか、既存システムの運用・保守に投資するのがよいかは、企業にとって重要な経営判断の一つである。

特許文献１には、設備や施設のデータをデータベース管理する設備管理システムにおいて、利用者との対話的インタフェースによるデータベース構築手段を設け、利用者自身によるデータベースの構築およびメンテナンスができるようにしたシステムが開示されている。
特開平１１−８５２６１号公報

顧客の新規ニーズに応えるための個別システムを開発し、開発された個別システムを基幹システムに連携させることで業務システムが構築されることが多いが、そのような個別システムが増えると、システム間の連携が複雑化し、業務システム全体が肥大化して、運用・保守コストが増大する。顧客としては、とりあえず新規ニーズに応える個別システムを開発して運用し、ビジネスがある程度立ち上がってくれば、正規のシステムに入れ替えればよいと考えがちである。しかし、業務システムの運用・保守にかかるコストの削減がなかなか進まない中、システムの再設計のために新たに投資することはできないのが現状であり、結局は、いったん開発された個別システムを根本的に作り直す機会などなく、最初に開発された個別システムを適宜更新しながら保守していかざるを得ない。

個別システムは、使用しているハードウェアやソフトウェアがそれぞれ異なるため、個別システムを一つ作るたびに個別の維持管理が増え、また、新機能を追加することで連携したシステムの変更箇所が増える。また各個別システムが老朽化時期を迎えれば、個別にサーバのアップグレードやソフトウェアのバージョンアップなどの老朽化対応をしていかなければならない。そのため、個別システムを多く含む業務システムは、変化が非常に緩慢なものとなり、システムの進化のスピードの低下が確実になる。このことは、業務システムが顧客ニーズの変化やＩＴ技術の革新に応じて発展していく上で大きな障壁となっている。

また、個別システムの老朽化対応の際、システム開発者が納入先の顧客に対して一方的にシステムの移行を提案するだけでは十分ではない。顧客が最終的な意思決定に至るまでには、様々な観点で価値判断や評価がなされるため、システム開発者と顧客の間で十分なコミュニケーションを取ることが求められている。

本発明はこうした課題に鑑みてなされたものであり、その主たる目的は、業務システムのリプレースを管理する技術を提供することにある。また別の目的は、業務システムの老朽化対応に当たって利用者とのコミュニケーションを支援する技術を提供することにある。

上記課題を解決するために、本発明のある態様のリプレース判断支援システムは、基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援するシステムであって、個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断部と、前記老朽化対応判断部により個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する提示部とを含む。前記提示部は、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関するビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるユーザインタフェースと、システム観点から見た場合の個別システムのリプレースに関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するシステム観点選択肢提示部と、前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するビジネス観点選択肢提示部とを含む。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、業務システムのリプレースを適切に管理して業務システムの発展を図ることができる。

図１は、実施の形態に係るリプレース管理システム１００の構成図である。リプレース管理システム１００は、基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレースを管理する。ここで、業務システムとは、たとえば、金融や証券などの業務を管理するシステムである。

システムの「リプレース」とは、システムを構成するサーバ等のハードウェアや、オペレーティングシステム、ミドルウェア、アプリケーション等のソフトウェアをよりよいものに改善することでシステムを更新することであり、本明細書で単に「リプレース」というときは、通常使われる意味で用いる。それとは別に、本明細書では、「単純リプレース」という用語と「再構築」という用語を用いる。

「単純リプレース」とは、リプレースの一種で、システムを構成するハードウェアやソフトウェアを極力以前と同じものを利用して性能面を増強することでインフラを更新することである。

一方、システムの「再構築」とは、新規のハードウェアやソフトウェアを導入することで、インフラを設計、構築することである。特に、個別システムを「基幹システムとして再構築する」とは、基幹システムのインフラ上に、個別システムを構築することを意味し、個別システムは基幹システムのハードウェアやソフトウェアに合わせて設計、構築し直される。なお、個別システムを基幹システムに組み込まずに、単体で新しいプラットフォームの上に移行する場合は、単に「再構築する」ということがある。

個別システムを「単純リプレースする」場合と「再構築する」場合とを包含する概念が、通常使われる意味における「リプレース」に相当する。

リプレース管理システム１００は、業務システムの機器構成、オペレーティングシステムの種類とバージョン、ソフトウェア構成、トラフィックデータ、システム要件などの各種情報を記憶装置に保持しており、業務システムのリプレースのタイミングを検出したり、リプレースにかかるコストを評価することにより、業務システムのリプレースを管理する。リプレース管理システム１００は、プロセッサ、メモリ、二次記憶装置をもつコンピュータシステムで構成される。リプレース管理システム１００はネットワークを介してユーザの業務システムと接続され、業務システムからリプレース判断に必要な情報をネットワーク経由で取得できるように構成されてもよい。

業務システムは、個別のニーズに応じて臨機応変に開発される個別システムと、長期間運用することを前提として開発され、運用・保守される基幹システムとを含み、個別システムと基幹システムが連携して業務処理が行われる。

評価時期管理部３０は、個別システムをリプレースするかどうかを評価する時期を管理する。一例として、個別システムのリプレースの評価時期を以下のように設定する。
（１）定期的チェック
たとえば、半年に一回、見直す。
（２）ユーザ数チェック
たとえば、金融システムであれば、口座数が一万に達したときに見直す。
（３）制度変更時チェック
金融や証券に関する法律の改正により、業務範囲が広がったり、顧客層が広がることがある。また、株券の電子化などの新制度の導入により顧客からの株券の持ち込みが増大することがある。このような業務に関する制度の変更時期をリプレースの評価時期に設定する。
（４）外部接続機関の仕様変更・性能増強時チェック
業務システムが接続している外部機関のシステムが仕様変更されたり、性能増強が図られるなど、外部機関のシステムのリプレース時に合わせて、個別システムをリプレースするかどうかを評価する。
（５）新製品の発表時期
ハードウェア、オペレーティングシステム、アプリケーション等の新製品が発表されると、たとえば２世代前の製品はサポート対象外となる。新製品の発表時期にサポート対象外となる世代のハードウェアやソフトウェアを使用している個別システムは、新製品の発表時期にリプレースするかどうかを評価する。
（６）新しい規格の普及時期
個別システムが独自に開発した技術が標準化されたり、デファクトスタンダードとなった場合、今後の保守を容易にするため、標準化された技術に置き換えるべきである。標準化された技術が普及する時期を個別システムのリプレースの評価時期に設定する。

評価時期管理部３０は、上記の各種のチェックの時期を記憶装置にリプレースの評価時期として記憶しておき、各評価時期が来ると、リプレースコスト評価部１０に通知する。

リプレースタイミング判定処理部２０（以下、単に「判定処理部」という）は、個別システムが扱う処理量が当初のシステム要件の想定範囲を逸脱しているかどうかを調べ、逸脱した場合に、個別システムをリプレースすべきクリティカルタイミングであると判定する。判定処理部２０は、クリティカルタイミングであると判定すると、リプレースコスト評価部１０に通知する。また、判定処理部２０は、リプレースすべきクリティカルタイミングになると、警告部２２にアラートメッセージなどを表示させ、ユーザに通知する。

システム要件保持部５０は、個別システムの設計当初のシステム要件が保持されている。システム要件には次のようなものがある。
（１）信頼性要件
システムは２４時間稼働していなければならないなど、システムの信頼性に関する要件。
（２）運用要件
営業日のみ稼働、毎日稼働など、運用に関する要件。
（３）性能要件
一秒間に１０件処理できる能力など、システムの処理性能に関する要件。
（４）データ規模要件
数千件、百万件など処理規模に関する要件。
（５）取引数量、売上金額、利益額
システムを利用する顧客の取引数量、売上げ、利益などに関する要件。
（６）システム年齢
システムが構築されてからの年数に関する要件。システム年齢は最大７年を限度とするなどの要件が定められる。

トラフィックデータ保持部６０には、過去から現在までの個別システムの処理件数や処理頻度などトラフィックに関するデータを保持している。判定処理部２０は、個別システムの現在のトラフィックがシステム要件保持部５０に保持されたシステム要件に合っているかどうかをチェックし、システム要件から逸脱する利用がなされている場合、個別システムをリプレースするすべきクリティカルタイミングであると判定する。判定処理部２０は、トラフィックデータ保持部６０に保持された過去のトラフィックデータを参照して、将来のトラフィックの増加を見込んで、クリティカルタイミングを予測してもよい。

リプレースコスト評価部１０（以下、単に「コスト評価部」という）は、評価時期管理部３０リプレースの評価時期の通知を受けるか、または判定処理部２０からクリティカルタイミングの通知を受けたとき、個別システムを基幹システムとして再構築する場合の再構築コストを評価する。

コスト評価部１０は、再構築コストを評価するにあたり、コスト関数保持部４０に保持されたリプレース判断関数を用いる。リプレース判断関数は、個別システムを単純リプレースするべきか、基幹システムとして再構築するべきかを判断するための関数であり、その判断のためにリプレースにかかる下記のコストを評価する。
（１）維持管理コスト
（２）エンハンス対応コスト
（３）新規関連案件対応コスト
（４）移行コスト
以下これらのコストについて説明する。

維持管理コストは、ハードウェア維持管理コストとソフトウェア維持管理コストを含む。ハードウェア・ソフトウェア維持管理コストは、障害発生率、障害ランク、平均障害対応工数、バージョンアップ発生率、平均バージョンアップ対応工数、保守契約費用などの要因を評価することで算定されるハードウェア・ソフトウェアの維持管理コストである。

エンハンス対応コストは、方式・環境・運用設計コスト、標準化コスト、ミドルウェア開発コスト、ＡＰＬ開発コスト、環境構築コスト、追加総合テストコスト、追加環境総合テスト（ＮＮＴ）コスト、追加リリースコストなどのコストを評価することで算定される、システムのエンハンスにかかるコストである。

ここで、方式・環境・運用設計コストは、ソフトウェア製品数、新規ソフトウェア数、接続プロトコル数、新規接続プロトコル数、耐障害性要求レベル、運用時間要求レベル、性能要求レベル、データ量要求レベルなどの要因を評価することで算定されるコストである。

新規案件対応コストは、新規システムの追加に伴い、その新規システムに連携するシステムを変更するときの対応コストであり、方式・環境・運用設計コスト、設計修正規模、標準化修正規模、ミドル変更規模、ＡＰＬ変更規模、環境変更規模、追加総合テストコスト、追加ＮＮＴコスト、追加リリースコストなどの要因を評価することで算定される。

移行コストは、システムを新しいプラットフォームに移行するのにかかるコストである。

個別システムを単純リプレースする場合のコストは、システムのプラットフォームをグレードアップするときの維持管理コスト、エンハンス対応コスト、新規案件対応コスト、移行コストを評価することで得られる。個別システムを基幹システムとして再構築する場合のコストは、個別システムの機能を基幹システムのプラットフォームに移植したり、基幹システムに統合するときの維持管理コスト、エンハンス対応コスト、新規案件対応コスト、移行コストを評価することで得られる。

コスト評価部１０は、単純リプレースコストと基幹システムへの再構築コストの比較結果を出力する。

提示部１２は、個別システムを基幹システムとして再構築するか、さもなければ個別システムを廃棄するかのいずれかの二者択一を業務システムの納入先のユーザ（以下、「顧客側担当者」または単に「担当者」という）に促すために、コスト評価部１０により算定された単純リプレースコストと再構築コストをメッセージを表示するなどの形で担当者に提示する。

担当者は、個別システムのリプレースの評価時期もしくはリプレースすべきクリティカルタイミングにおいて、個別システムを基幹システムとして再構築する場合のコストを提示され、再構築するか、さもなければ個別システムを廃棄するかのどちらかの選択を促される。

コスト評価部１０と提示部１２による個別システムのリプレースの具体的な判断例を以下に示す。

（１）個別システムを再構築する判断例
老朽化したシステムＡのリプレースタイミングにおいて、以下の判断がなされる。
システムＡのサーバ上の業務は今後も利用する必要があり、サーバを同等のサーバに単純に置き換える（「単純リプレース」）だけでは、今後の予想されるトラフィックの増大に耐えられない。ハードウェア・ソフトウェアのサポート切れまでの時間の余裕から、リプレース方法を検討すると、同一種類の上位サーバにリプレースする方法（「単純リプレース」）と、同一種類の上位サーバよりもさらにスケール性のある別プラットフォームに移行する方法（「再構築」）がある。コスト評価部１０により、上位サーバへのアップグレードコスト（「単純リプレースコスト」）と、別プラットフォームへの移行コスト（「再構築コスト」）を比較する。コスト比較の結果は提示部１２に提示され、担当者は、今後の業務面の拡大を想定して、別プラットフォームへの移行（再構築）を決断する。

（２）個別システムをリプレースしないで廃棄する判断例
老朽化したシステムＢのリプレースタイミングにおいて、以下の判断がなされる。
システムＢのサーバ上の業務は今後も利用する必要があり、この業務と類似の業務を支えるシステムＣが、別プラットフォームで稼動している。システムＣを拡張してシステムＢが担っていた業務にも対応することが可能である。コスト評価部１０によって、システムＣを拡張した場合の拡張システムの維持管理コスト増加と、システムＢを単純リプレースした場合のシステムＢの今後の維持管理コストとを比較する。コスト比較の結果は提示部１２により提示され、担当者は、単純リプレース後のシステムＢの今後の維持管理コストがシステムＣの拡張による維持管理コスト増加よりも大きいことから、システムＣの拡張とシステムＢの既存サーバの廃止を決断する。

従来は、リプレース評価時期もしくはクリティカルタイミングにおいて、個別システムのサーバを上位機種にアップグレードするなどにより単純リプレースがなされることが多いが、そのような単純リプレースを繰り返すと、個別システムを基幹システムとして再構築する機会を失い、業務システムの複雑化、肥大化につながる。それに対して、本実施の形態では、リプレース評価時期もしくはクリティカルタイミングにおいて、単純リプレースをしないで、個別システムを基幹システムとして再構築することを再構築コストを提示して担当者に提案するため、担当者に個別システムを基幹システムに組み入れて再構築する決断する機会を与えることができる。老朽化対応時期を迎えた個別システムを基幹システムとして再構築することは、業務システム全体の運用・保守コストを下げることにつながり、先進システムの企画、開発などに投資する余裕が生まれる。

図２および図３を参照して、本実施の形態によるリプレース管理による効果を説明する。比較のため、図２は、従来の方法で業務システムのリプレースを行った場合の業務システムの発展形態を示す。図２（ａ）のように一台のサーバからなる最初のシステムを開発したとする。新機能に対応した個別システムを追加し、図２（ｂ）のような３台のサーバからなる連携システムが開発される。以後、新機能を追加するたびに新しい個別システムを追加していくと、図２（ｃ）のように多数のサーバが複雑に接続された連携システムが形成される。同図はサーバ間の物理的な接続関係を示すが、論理的なシステム間のつながりはさらに複雑なものとなる。このような複雑な連携システムを運用・保守するにはたいへんな労力を要する。

図３は、本実施の形態のリプレース管理システム１００を用いた場合の業務システムの発展形態を示す。個別システムは捨てる前提で開発され、老朽化対応時期が来ると、リプレース管理システム１００は個別システムを基幹システムとして再構築することをユーザに提案する。

図３（ａ）に示すように、業務システムを個別システムと基幹システムに分けて設計する。個別システムは、その時々のニーズに合わせて作り変えるシステムであり、半ば捨てる前提で保守期間を気にせず新しい技術を使って開発される。基幹システムは、長期的なビジネスを支えるために開発されるものであり、使い続ける前提で保守期間の長いハードウェア・ソフトウェアを用いて作られ、規模拡大に備えて継続的に整理・統合される。

個別システムは、リプレースのタイミングが来ると、位置づけを変更して基幹システムに組み入れるために再構築するか、さもなければ廃棄する。同図では、符号２００ａで示す個別システムは基幹システムとして再構築され、符号２００ｂで示す個別システムは廃棄される。

このようにして、各個別システムのリプレース判断時点で、基幹システムに組み入れるか、廃棄するかの二者択一をユーザに迫るようにすれば、新規ニーズに応じて次々に個別システムが開発、追加されても、業務システムが複雑化、肥大化するのを防ぐことができる。図３（ｂ）は、個別システムが多数追加されて発展した業務システムの形態を示す。増え続ける個別システム群については、各個別システムの老朽化対応時期に廃棄されるか、基幹システムとして再構築されるため、基幹システムとの接続関係は複雑にならない。一方、基幹システムは適宜個別システムの機能を取り入れながら整備されていく。個別システムが増えていっても、個別システムと基幹システムの境界が保たれるため、運用・保守が容易である。

上記の実施の形態のリプレース管理システム１００において、個別システムをリプレースすべきクリティカルタイミングは、トラフィック予測にもとづいて判定されてもよい。図４および図５を参照して、トラフィック予測にもとづいてクリティカルタイミングを判定するための判定処理部２０の構成と動作について説明する。

図４は、判定処理部２０の構成図である。ピーク検出部７０は、トラフィックデータ保持部６０から個別システムの過去のトラフィックデータを取得し、トラフィック変動のピーク群を抽出する。

図５に示すように、一般に業務システムのトラフィック量は何度かのピークを迎えながら増えていくことが経験的に知られている。たとえば、証券システムでは、市場の期待感の高まりからトラフィックが増えていき、相乗効果からピークを迎える。その後、市場の興奮が収まるにつれてトラフィックが減少するが、再び市場で期待感が高まると次のピークに向かってトラフィックが成長する。

ピーク検出部７０は、抽出したトラフィックのピーク群をもとに、ピークの高さλと出現周期Ｔを検出する。図５の例では、符号２１０で示すトラフィック変動において白丸で示したトラフィックのピーク群２２０ａ、２２０ｂ、２２０ｃが抽出され、ピークの高さλ１、λ２と、ピークの出現周期Ｔ１、Ｔ２が検出される。

ピーク推定部７２は、検出されたピークの高さλ１、λ２と出現周期Ｔ１、Ｔ２をもとに、次に起こるべきピークの高さλ３と出現周期Ｔ３を推定する。ピーク推定部７２は、点線２３０で示すようにピーク間に近似曲線を当てはめて補間することで次のピークを推定してもよい。これにより、次のピークの発生タイミングｔｄとそのときのトラフィック量Ｘｄ（図中のピーク２２０ｄ）が推定される。

クリティカルトラフィック設定部７４は、個別システムを基幹システムとして再構築するためにかかる時間Ｌをコスト評価部１０から取得する。これはシステム再構築のいわゆる「リードタイム」である。クリティカルトラフィック設定部７４は、次に起こるピークの推定タイミングｔｄからシステム再構築のリードタイムＬだけ遡ったタイミングｔｃにおけるトラフィック量Ｘｃをトラフィック変動曲線２１０にしたがって求め、このトラフィック量Ｘｃを、個別システムのリプレースを検討すべきクリティカルトラフィック量に設定する。

クリティカルタイミング判定部７６は、トラフィックデータ保持部６０から読み出した個別システムのトラフィックがクリティカルトラフィック量Ｘｃに達するときを、個別システムをリプレースすべきクリティカルタイミングと判定し、コスト評価部１０と警告部２２に通知する。

このように、図４に示した判定処理部２０のトラフィック推定機能により、将来のピークに備えて、システム再構築のリードタイムも考慮に入れてあらかじめ個別システムをリプレースすべきクリティカルタイミングを判定することができ、トラフィックの急成長に対して予防的に対処して、個別システムの再構築をユーザに提案することができる。

上記の説明では、提示部１２は、単純リプレースコストと比較する形で再構築コストを提示することにより、個別システムを基幹システムとして再構築するか、さもなければ廃棄するかの二者択一をユーザに迫った。しかし、再構築コストの提示だけでユーザに二者択一の意思決定をすることは現実には難しいことがある。そこで、提示部１２は、ユーザの二者択一の意思決定を支援するために、対話型のユーザインタフェースを備えてもよい。以下、提示部１２がもつ対話型ユーザインタフェース機能について詳しく説明する。

図６は、提示部１２の機能構成図である。提示部１２は、システム観点選択肢提示部８０、ビジネス観点選択肢提示部８２、および対話型ユーザインタフェース９０を有する。図１のリプレースタイミング判定処理部２０、評価時期管理部３０は、個別システムの老朽化対応を検討すべき段階であるかどうかを判断する「老朽化対応判断部」の一例である。提示部１２は、老朽化対応を検討すべき段階であると判断された個別システムについて、システム観点とビジネス観点の両方から見た場合のリプレースに関する価値判断材料の入力を支援する。

上記の説明では、図１のリプレースコスト評価部１０は、老朽化対応時期を迎えた個別システムについて、単純リプレースコストと再構築コストを出力したが、ここでは、ユーザの意思決定を支援するために、リプレースに関するコストだけでなく、システム観点から見た場合のリプレースに関する客観的な事実全般を提示部１２に与える。

老朽化対応時期を迎えた個別システムについてのシステム観点から見たリプレースに関する客観的事実として、移行を促進するもの、抑制するもの、中立的であるものに分けると、以下のような項目がある。

（１）システム観点から見たリプレースに関する客観的事実
（１−１）移行を促進する事実
ハードウェア、ソフトウェアのサポート切れ、
ハードウェア、ソフトウェアのバグ、セキュリティホールの発生または発生頻度、
移行コストの増加量、新規案件対応コストの増加量、
維持管理コストの増加量、エンハンス対応コストの増加量、
担当チームの老齢化と移行による担当チームの若返り、
担当チームのシステム把握度低下と移行による担当チームのシステム把握度向上、
限界性能を超える負荷の到来。

一般に、個別システムを新しいプラットフォームに移行させてシステムを再構築する際、担当チームが入れ替わることが多く、担当チームのメンバー構成が若返ることがある。また、移行を機に担当者のシステムの理解度が一気に高まる。

（１−２）移行を抑制する事実
移行後に想定される、維持管理コスト、エンハンス対応コスト、新規関連案件対応コスト、移行コスト、およびこれらの増加量

個別システムを新しいプラットフォームに移行すると、コスト評価部１０が用いるリプレース判断のために評価していた維持管理コスト、エンハンス対応コスト、新規関連案件対応コストおよび移行コストが変わる。コスト評価部１０は移行後の個別システムについてこれらのコストを求め、移行前のコストからの増加量を算定する。

（１−３）中立的な事実
システムの使用年数、システムの償却年数。

個別システムの開発者は、対話型ユーザインタフェース９０を介して、老朽化対応時期を迎えた個別システムについて、システム観点から見た場合のリプレースに関する主観的な価値判断材料を提供する。システム観点から見たリプレースに関する主観的価値判断材料として、移行を促進するもの、抑制するものに分けると、以下のような項目がある。

（２）システム観点から見たリプレースに関する主観的価値判断材料
（２−１）移行促進材料
新技術の登場・普及、
新標準の登場・普及、
新機能追加要望、
新たなシステム間接続、
担当チームのリソース余剰、
担当チームの変更・追加による担当チームのスキルセットの変化（たとえばプログラミング言語が変更される場合の担当者チームがもつプログラミング技術の変化）。

（２−２）移行抑制材料
移行によって新たなバグが作りこまれるなどシステムの安定性の変化、
担当チームのリソース不足、
新制度への対応を含む計画済みのエンハンス。

システム観点選択肢提示部８０は、コスト評価部１０から入力されたシステム観点のリプレースに関する客観的事実と、開発者から対話型ユーザインタフェース９０を介して提供されたシステム観点の主観的な価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を当該業務システムのユーザ（顧客側の担当者）に提示する。システム観点の選択肢として、移行を促進するもの、抑制するものに分けると、以下の選択肢がある。

（３）システム観点から見た選択肢
（３−１）移行促進
個別再構築、
共通基盤への再構築、
サービスレベル変更（たとえば２４時間稼働から平日の日中稼働に変更するなど）、
システム統合（たとえば一台のマシンで３つのシステムを実行させるなど）、
システム廃止（個別システムは破棄し、基幹システムを拡張するなど）。

ここで、個別再構築、共通基盤（基幹システム）への再構築には、即時再構築、一定期間内に再構築、トラフィックが特定条件を満たしたときに再構築などのバリエーションがある。

（３−２）移行抑制
単純リプレース、
現状のまま継続。

個別システムの顧客側の担当者は、対話型ユーザインタフェース９０を介して、システム開発者が提示したシステム観点のリプレースに関する主観的な価値判断材料に対して重み付けを与えることができる。システム観点選択肢提示部８０は、顧客側担当者が与えた重み付けにしたがって、システム観点の選択肢に優先順位を付けて提示することもできる。

顧客側の担当者は、さらに、老朽化対応時期を迎えた個別システムについて、企業のビジネス観点から見た場合のリプレースに関する主観的な価値判断材料を対話型ユーザインタフェース９０を介して提供する。ビジネス観点から見たリプレースに関する主観的な価値判断材料として、移行を促進するもの、抑制するものに分けると、以下のような項目がある。

（４）ビジネス観点から見たリプレースに関する主観的な価値判断材料
（４−１）移行促進材料
コスト抑制圧力（外部要因、経営目標など）、
業務提携などに伴う当該業務の位置付け変化（業務の重要度の上昇または低下、業務形態変化、業務廃止など）、
予算の余剰、予想外の利益。

（４−２）移行抑制材料
予算不足

たとえば、証券業務の自由化により、新しい金融商品が生まれたり、証券業務への新規参入が可能となるなど、ビジネスを取り巻く環境が大きく変化し、ビジネスチャンスが期待できる状況は、ビジネス観点から見て移行を促進する材料として働く。

ビジネス観点選択肢提示部８２は、顧客側の担当者から対話型ユーザインタフェース９０を介して提供されたビジネス観点の主観的な価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示する。ビジネス観点選択肢提示部８２は、システム観点選択肢提示部８０からシステム観点の選択肢の入力を受けており、システム観点の選択肢とともにビジネス観点の選択肢を提示する。ビジネス観点の選択肢には以下のようなものがある。

（５）ビジネス観点の選択肢
予算追加または削減
人員追加または削減
業務フローの高度化または単純化
業務品質の向上または低減

個別システムの顧客側の担当者は、対話型ユーザインタフェース９０を介して、ビジネス観点のリプレースに関する主観的な価値判断材料に対して重み付けを与えることができる。ビジネス観点選択肢提示部８２、顧客側担当者が与えた重み付けにしたがって、ビジネス観点の選択肢に優先順位を付けて提示することもできる。

システム観点選択肢提示部８０が提示するシステム観点の選択肢は、業務システムの顧客側の担当者向けであるのに対して、ビジネス観点選択肢提示部８２が提示するビジネス観点の選択肢は、企業の経営者向けである。老朽化対応時期を迎えた個別システムの再構築の意思決定を促すためには、再構築の必要性を顧客側担当者に訴えるだけでなく、経営者に訴えることも重要となる。

そこで、顧客側担当者向けに再構築の必要性を説得するためのキーワードや文章などのフレーズと、企業経営者向けに再構築の必要性を説得するためのフレーズとをそれぞれ用意しておき、システム観点の選択肢を提示するときには顧客側担当者向けのフレーズを添えるようにし、ビジネス観点の選択肢を提示するときには企業経営者向けのフレーズを添えるようにすることが一層効果的である。

担当者向けフレーズ記憶部８４は、顧客側担当者向けのフレーズを格納しており、システム観点選択肢提示部８０は、システム観点の各選択肢に適した担当者向けフレーズを担当者向けフレーズ記憶部８４から読み出し、選択肢を提示する際に利用する。担当者向けフレーズは、たとえば、開発期間、開発コスト、先進技術、新機能に関するものであり、「再構築すると開発コストが下がる」、「先進技術を用いることで開発期間が短縮される」など、担当者にアピールするキーワードを用いた文章である。このようなフレーズを用いることでシステム観点から見た選択肢を担当者にとってより説得力のあるものにすることができる。

経営者向けフレーズ記憶部８６は、担当者の上司や経営者向けのフレーズを格納しており、ビジネス観点選択肢提示部８２は、ビジネス観点の各選択肢に適した経営者向けフレーズを経営者向けフレーズ記憶部８６から読み出し、選択肢を提示する際に利用する。経営者向けフレーズは、たとえば、ビジネスニーズへの合致、ＴＣＯ（総所有コスト）、安定性、法令遵守、監査性に関するものであり、「今、再構築に投資することによって運用・保守の無駄な経費が抑制され、ＴＣＯ削減につながる」、「ここで再構築しておかなければ、ビジネスニーズに応えられず、ビジネスチャンスを失う」、「法令遵守（コンプライアンス）のためには新規システムに移行する必要がある」など、経営者にアピールするキーワードを用いた文章である。このようなフレーズを用いてビジネス観点の選択肢を提示することで、担当者が上司や経営者に説得力のある説明をすることができるようになる。

システム観点選択肢提示部８０とビジネス観点選択肢提示部８２により、システム観点およびビジネス観点からの選択肢が提示され、顧客側担当者が対話型ユーザインタフェース９０を用いて、システム観点およびビジネス観点の主観的な価値判断材料の重み付けを変更していくことで、最終的に個別システムを単純リプレースするのか、再構築するのか、それとも破棄するのかといった意思決定をしていくことができる。また、システム開発者がシステム観点の主観的な価値判断を入力し、顧客側担当者がビジネス観点の主観的な価値判断を入力するため、システム開発者と顧客担当者の価値判断の違いをとりうる選択肢の優先度に反映させることができる。

以下、対話型ユーザインタフェース９０を用いた判断事例を挙げる。
（１）システム観点では移行すべきと考えられるが、ビジネス観点まで考えると今は移行すべきではないと判断された事例
（１−１）システム観点の判断
オペレーティングシステムのサポート切れが６箇月後に迫ったサーバＡがあった。システム観点選択肢提示部８０には、このようなサーバのサポート切れの情報がシステム観点のリプレースに関する客観的事実として入力される。
オペレーティングシステムのサポート切れとなると、それ以降、オペレーティングシステムのバグやセキュリティホールに対するパッチが提供されないなどの不具合が予想される。システム開発者はこういったシステム観点から見た主観的な判断材料を対話型ユーザインタフェース９０を介してシステム観点選択肢提示部８０に与える。
システム観点選択肢提示部８０は、サポート切れという客観的事実とサポート切れに伴う不具合についての主観的判断材料をもとに、システム観点の選択肢として、６箇月以内の早期移行を顧客側担当者に推奨した。

（１−２）ビジネス観点の判断
一方、当該サーバＡ上の業務は、１年後に社内制度の変更により見直しが予定されている。このようなエンハンスの計画はシステム開発者は知らないため、システム観点の判断段階では考慮に入れることができなかった。顧客側担当者はこのようなビジネス観点の判断材料を対話型ユーザインタフェース９０を介してビジネス観点選択肢提示部８２に与えることができる。ビジネス観点選択肢提示部８２は、１年後の社内制度の変更タイミングでアプリケーションの修正を行うことをビジネス観点の選択肢として提示する。

（１−３）ビジネス観点を鑑みたシステム観点の判断の再考
顧客側担当者は、システム観点選択肢提示部８０が提示するサポート切れになる前の６箇月以内の早期移行と、ビジネス観点選択肢提示部８２が提示する１年後の社内制度の変更タイミングでの移行の２つの選択肢を提示される。当該サーバＡは、数年前にコンピュータセンタ内に設置され、社内利用に閉じる使い方をしている。このため、新たなオペレーティングシステムのバグが発生する可能性や、ウィルス等によるセキュリティ上の脅威は、可能性が低いと考えることができる。顧客側担当者は、これらを鑑み、６箇月後から１年後まではオペレーティングシステムのサポート切れの状態で利用を継続し、１年後に移行することを意思決定した。

このようにして、システム開発者によるシステム観点からの見解が顧客側担当者によるビジネス観点の見解によって修正される。システム開発者の一方的な考えだけで移行すべきかどうかが判断されるのではなく、顧客側の事情や意見も採り入れて最終的に意思決定される。

（２）システム観点では移行すべきではないが、ビジネス観点まで考えると移行すべきであると判断された事例
（２−１）システム観点の判断
システムとして安定しているシステムＡとシステムＢがある。システムＢはシステムＡと連携して稼動している。ビジネスの拡大に伴って、システムＡの機能拡充・キャパシティ拡大が予定されている。システム観点選択肢提示部８０には、このようなシステムの稼働状況や機能拡張予定などの客観的事実が入力される。
システム開発者は、このような状況に鑑みて、システムＡの刷新に伴い、強力かつ保守年限の長いサーバを導入することにし、システムＢについては、当面、機能拡充やキャパシティ拡大は不要であると判断した。システム観点選択肢提示部８０にはシステム開発者によるこのようなシステム観点からの価値判断が入力される。
システム観点選択肢提示部８０は、システム観点の客観的事実とシステム観点の価値判断材料をもとに、現時点では、システムＢの移行は不要であるという判断を顧客側担当者に提示した。

（２−２）ビジネス観点の判断
一方、顧客側担当者は、システムＢのサーバが設置されている部屋は狭く、システムＡのサーバが設置されている部屋は広いなどの事情から、この機会にシステムＢをシステムＡと同じサーバに移行しておけば、今後、キャパシティ拡大があった場合にも対応できると判断した。また、システムＡをテストするタイミングで、システムＢのテストもかなりの範囲実施することとなるため、システムＢをシステムＡと同時に移行する場合にかかる移行コストは、システムＢを単独で移行する場合の移行コストの合計に比べて低いことがわかった。ビジネス観点選択肢提示部８２には、顧客側担当者のこのようなビジネス観点の価値判断材料が入力される。ビジネス観点選択肢提示部８２は、システムＢをシステムＡのプラットフォーム提供者に移行することをビジネス観点の選択肢として提示する。

（２−３）ビジネス観点を鑑みたシステム観点の判断の再考
顧客側担当者は、システム観点選択肢提示部８０がシステム観点から提示する移行不要の選択肢に対して、ビジネス観点選択肢提示部８２がビジネス観点から提示する移行推奨の選択肢を優先して、システムＢは早めに除却し、システムＡとあわせてシステムＢを新サーバへ移行する決定を最終的に行った。

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

リプレース管理システム１００において、ＩＴＩＬ（Information Technology Infrastructure Library）管理を導入してもよい。ＩＴＩＬ管理では、ハードウェア、ソフトウェア、アプリケーション、ネットワークなどの構成要素を管理する「構成管理」、システムリリース後の変更履歴を管理する「変更管理」、障害の履歴を管理する「インシデント管理」などが行われる。ＩＴＩＬ管理の各種情報をリプレースの際の判断材料に用いることができる。

実施の形態に係るリプレース管理システムの構成図である。 従来の方法で業務システムのリプレースを行った場合の業務システムの発展形態を示す図である。 本実施の形態のリプレース管理システムを用いた場合の業務システムの発展形態を示す図である。 図１の判定処理部の構成図である。 業務システムにおけるトラフィック変動を示す図である。 図１の提示部の機能構成図である。

符号の説明

１０ リプレースコスト評価部、 １２ 提示部、 ２０ リプレースタイミング判定処理部、 ２２ 警告部、 ３０ 評価時期管理部、 ４０ コスト関数保持部、 ５０ システム要件保持部、 ６０ トラフィックデータ保持部、 ７０ ピーク検出部、 ７２ ピーク推定部、 ７４ クリティカルトラフィック設定部、 ７６ クリティカルタイミング判定部、 ８０ システム観点選択肢提示部、 ８２ ビジネス観点選択肢提示部、 ８４ 担当者向けフレーズ記憶部、 ８６ 経営者向けフレーズ記憶部、 ９０ 対話型ユーザインタフェース、 １００ リプレース管理システム。

Claims (6)

1. 基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援するシステムであって、
   個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断部と、
   前記老朽化対応判断部により個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する提示部とを含み、
   前記提示部は、
   個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるユーザインタフェースと、
   システム観点から見た場合の個別システムの移行に関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するシステム観点選択肢提示部と、
   前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するビジネス観点選択肢提示部とを含むことを特徴とするリプレース判断支援システム。
2. 前記担当者向けに移行を推奨するフレーズと、経営者向けに移行を推奨するフレーズとをあらかじめ用意して格納したフレーズ記憶部をさらに設け、
   前記システム観点選択肢提示部は、システム観点の選択肢を提示する際、前記フレーズ記憶部から担当者向けフレーズを読み出して選択肢とともに提示し、
   前記ビジネス観点選択肢提示部は、ビジネス観点の選択肢を提示する際、前記フレーズ記憶部から経営者向けフレーズを読み出して選択肢とともに提示することを特徴とする請求項１に記載のリプレース判断支援システム。
3. 前記老朽化対応判断部は、
   個別システムをリプレースするかどうかを評価する時期を管理する評価時期管理部と、
   個別システムが扱う処理量が当初のシステム要件の想定範囲を逸脱した場合に、個別システムをリプレースすべきクリティカルタイミングであると判定する判定処理部とを含み、
   前記老朽化対応判断部は、前記評価時期管理部からリプレースの評価時期の通知を受けるか、または前記判定処理部からクリティカルタイミングの通知を受けたとき、個別システムの老朽化対応を検討すべき段階であると判断することを特徴とする請求項１または２に記載のリプレース判断支援システム。
4. 前記評価時期管理部は、個別システムのリプレースの評価時期を、業務に関する制度の変更時期に設定することを特徴とする請求項３に記載のリプレース判断支援システム。
5. 前記評価時期管理部は、個別システムのリプレースの評価時期を、当該個別システムが接続されている外部機関のシステムのリプレース時期に設定することを特徴とする請求項３に記載のリプレース判断支援システム。
6. 基幹システムと個別ニーズに応じて作られた個別システムとを含む業務システムのリプレース判断を支援する方法であって、
   個別システムの老朽化対応を検討すべき段階であるかどうかを判断する老朽化対応判断ステップと、
   前記老朽化対応判断ステップにおいて個別システムの老朽化対応を検討すべき段階であると判定された場合に、個別システムの移行に関する意思決定を支援する意思決定支援ステップとを含み、
   前記意思決定支援ステップは、
   ユーザインタフェースを介して、個別システムの移行に関してシステム観点から見た判断材料の入力を当該業務システムの開発者から受けつけ、個別システムの移行に関してビジネス観点から見た判断材料の入力を当該業務システムの納入先の担当者から受け付けるステップと、
   システム観点から見た場合の個別システムのリプレースに関する客観的事実と、前記開発者から提供されたシステム観点の価値判断材料とをもとに、システム観点から見た場合のとりうる選択肢を前記担当者に提示するステップと、
   前記担当者から提供されたビジネス観点の価値判断材料をもとに、ビジネス観点から見た場合のとりうる選択肢を担当者に提示するステップとを含むことを特徴とするリプレース判断支援方法。

Images