JP4814935B2 - 業務管理プログラム、業務管理装置、および業務管理方法 - Google Patents

Description

本発明は遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理プログラム、業務管理装置、および業務管理方法に関し、特にフェーズ間でデータを受け渡して連係を図る業務を管理するための業務管理プログラム、業務管理装置、および業務管理方法に関する。

ＩＴ（Information Technology）システムは、サーバ／ストレージ／ネットワークなどのハードウェア機器、ソフトウェア、そしてその上で動く業務（サービス）で構成される。そのＩＴシステムは、商談、設計、構築、運用などのフェーズからなるライフサイクル全てを通して統括的に管理し、各フェーズ内の複数管理システム間で円滑に情報を交換することが必要である。

一般的に、従来のＩＴシステム管理においては、商談、設計、構築、運用などの各フェーズで異なる管理手法を採用している。紙ベースで管理しているフェーズもあれば、まったく独立した管理ソフトウェアを導入しているフェーズもある。同一フェーズ内、例えば運用フェーズにおいて利用される複数の運用管理ミドルウェア間であっても、同様に、異なる管理手法が混在することがある。管理手法が統一されていない場合、各フェーズ間のデータフォーマットも統一されていないことが多い。このように、フェーズ間や同一フェーズ内のミドルウェア間でやり取りされるデータフォーマットに統一性がないため、相互の運用性が極めて低い。

なお、上流フェーズで扱っていたデータをそのまま次のフェーズの入力データとして与えられる製品・ツールなども存在する。このように、データの連係を取ることで、情報の交換が容易となる。例えば、ＸＭＬ（eXtensible Markup Language）を用いてデータ形式を共通化することで、複数システム間での情報交換することが考えられている（例えば、特許文献１参照）。
特表２００４−５３１００６号公報

しかし、特許文献１に記載された技術では、単に情報を共有するためだけにしか用いられず、各システムで生成された情報間の関係などを管理する手段が提供されていない。そのため、複数フェーズに跨るデータの管理には適用できない。すなわち、特許文献１の技術ではデータの連係が可能なのは一部のフェーズ間に限定されており、商談から運用までのライフサイクル全体で一貫した情報の連係は行われていない。

このように、従来技術ではＩＴシステムのライフサイクルを通じた管理データの一貫性が確保できない。そのため、例えば運用開始後に問題が発生し再設計の必要が生じた場合には、その都度フェーズごとに異なる構造のデータを付き合わせる。データを付き合わせた結果から、もとの設計データからどのようにシステムが構築され、そして運用されているのかを、各フェーズに携わった関係者で確認しなければならなかった。

特に近年は、システムの大規模化が進んでいる。また、システム統合、ハードウェア仮想化技術により、システム全体が複雑になってきている。そのため、従来のように、人手によるフェーズ間連係は益々困難となっている。その結果、管理コストが爆発的に増加し、また障害発生時には対処に多くの時間と人手を要している。

これらの問題を解決するためには、各フェーズの管理システム間、もしくは同一フェーズ内の複数管理システム間で円滑にデータ連係できるようにし、相互運用性の向上を図らなければならない。そのためには、ＩＴシステムのライフサイクル全体で利用できるデータ管理手法を確立する必要がある。また、単に複数管理システム間で情報を共有するだけでなく、他管理システムに対して様々な事象発生時の影響波及（伝達）や操作支持を行えるようにすることで、より効率的な連係を取ることが望まれる。

本発明はこのような点に鑑みてなされたものであり、多数のフェーズに跨ったデータ連係が可能な業務管理プログラム、業務管理装置、および業務管理方法を提供することを目的とする。

本発明では上記課題を解決するために、図１に示すような業務管理プログラムが提供される。本発明に係る業務管理プログラムは、遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するために、図１に示す機能をコンピュータに実行させることができる。

スキーマ記憶手段１は、フェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき事項を示す代表データのデータ項目を含むスキーマを記憶する。フェーズごとのフェーズ別業務管理手段２ａ，３ａは、担当フェーズが割り当てられ、前段のフェーズそれぞれにおける代表データと関係情報とを含む交換データ４，５を取得し、ユーザからの操作入力に応答して、取得した交換データ４，５に含まれる代表データを利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータを生成する。代表データ抽出手段２ｅ，３ｅは、フェーズ別業務管理手段２ａ，３ａでフェーズデータが生成されると、スキーマを参照し、スキーマで指定されている代表データのデータ項目に合致するデータを、代表データとしてフェーズデータから抽出する。関係情報生成手段２ｆ，３ｆは、フェーズ別業務管理手段２ａ，３ａで生成された前記フェーズデータを参照し、代表データ抽出手段２ｅ，３ｅで抽出された代表データと、代表データの生成に際して利用された交換データ４，５内の代表データとの利用関係を示す関係情報を生成する。データ合成手段２ｇ，３ｇは、フェーズ別業務管理手段２ａ，３ａが取得した交換データ４，５に、代表データ抽出手段２ｅ，３ｅが抽出した代表データと、関係情報生成手段２ｆ，３ｆが生成した関係情報とを合成して交換データ４，５を更新し、更新された交換データ５，６を次のフェーズを担当するフェーズ別業務管理手段に渡す。

このような業務管理プログラムをコンピュータに実行させることで、フェーズごとのフェーズ別業務管理手段２ａ，３ａにより、担当フェーズが割り当てられ、前段のフェーズそれぞれにおける代表データと関係情報とを含む交換データ４，５が取得され、ユーザからの操作入力に応答して、取得した交換データ４，５に含まれる代表データを利用して担当フェーズ内の業務が実行され、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータが生成される。フェーズ別業務管理手段２ａ，３ａでフェーズデータが生成されると、代表データ抽出手段２ｅ，３ｅにより、スキーマが参照され、スキーマで指定されている代表データのデータ項目に合致するデータが、代表データとしてフェーズデータから抽出される。すると、関係情報生成手段２ｆ，３ｆにより、フェーズ別業務管理手段２ａ，３ａで生成された前記フェーズデータを参照し、代表データ抽出手段２ｅ，３ｅで抽出された代表データと、代表データの生成に際して利用された交換データ４，５内の代表データとの利用関係を示す関係情報が生成される。そして、データ合成手段２ｇ，３ｇにより、フェーズ別業務管理手段２ａ，３ａが取得した交換データ４，５に、代表データ抽出手段２ｅ，３ｅが抽出した代表データと、関係情報生成手段２ｆ，３ｆが生成された関係情報とが合成されることで交換データ４，５が更新され、更新された交換データ５，６が次のフェーズを担当するフェーズ別業務管理手段に渡される。

また、上記課題を解決するために、遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理装置において、前記フェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき事項を示す代表データのデータ項目を含むスキーマを記憶するスキーマ記憶手段と、担当フェーズが割り当てられ、前段の前記フェーズそれぞれにおける前記代表データと前記関係情報とを含む交換データを取得し、ユーザからの操作入力に応答して、取得した前記交換データに含まれる前記代表データを利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータを生成する、前記フェーズごとのフェーズ別業務管理手段と、前記フェーズ別業務管理手段で前記フェーズデータが生成されると、前記スキーマを参照し、前記スキーマで指定されている前記代表データのデータ項目に合致するデータを、前記代表データとして前記フェーズデータから抽出する代表データ抽出手段と、前記フェーズ別業務管理手段で生成された前記フェーズデータを参照し、前記代表データ抽出手段で抽出された前記代表データと、前記代表データの生成に際して利用された前記交換データ内の前記代表データとの利用関係を示す関係情報を生成する関係情報生成手段と、フェーズ別業務管理手段が取得した前記交換データに、前記代表データ抽出手段が抽出した前記代表データと、前記関係情報生成手段が生成された前記関係情報とを合成して前記交換データを更新し、更新された前記交換データを次のフェーズを担当する前記フェーズ別業務管理手段に渡すデータ合成手段と、を有することを特徴とする業務管理装置が提供される。

このような業務管理装置によれば、フェーズごとのフェーズ別業務管理手段により、担当フェーズが割り当てられ、前段のフェーズそれぞれにおける代表データと関係情報とを含む交換データが取得され、ユーザからの操作入力に応答して、取得した交換データに含まれる代表データを利用して担当フェーズ内の業務が実行され、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータが生成される。フェーズ別業務管理手段でフェーズデータが生成されると、代表データ抽出手段により、スキーマが参照され、スキーマで指定されている代表データのデータ項目に合致するデータが、代表データとしてフェーズデータから抽出される。すると、関係情報生成手段により、前記フェーズ別業務管理手段で生成された前記フェーズデータを参照し、代表データ抽出手段で抽出された代表データと、代表データの生成に際して利用された交換データ内の代表データとの利用関係を示す関係情報が生成される。そして、データ合成手段により、フェーズ別業務管理手段が取得した交換データに、代表データ抽出手段が抽出した代表データと、関係情報生成手段が生成した関係情報とが合成されることで交換データが更新され、更新された交換データが次のフェーズを担当するフェーズ別業務管理手段に渡される。

また、上記課題を解決するために、遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理方法において、前記フェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき事項を示す代表データのデータ項目を含むスキーマが、スキーマ記憶手段に予め記憶されており、前記フェーズごとのフェーズ別業務管理手段が、担当フェーズが割り当てられ、前段の前記フェーズそれぞれにおける前記代表データと前記関係情報とを含む交換データを取得し、ユーザからの操作入力に応答して、取得した前記交換データに含まれる前記代表データを利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータを生成し、代表データ抽出手段が、前記フェーズ別業務管理手段で前記フェーズデータが生成されると、前記スキーマを参照し、前記スキーマで指定されている前記代表データのデータ項目に合致するデータを、前記代表データとして前記フェーズデータから抽出し、関係情報生成手段が、前記フェーズ別業務管理手段で生成された前記フェーズデータを参照し、前記代表データ抽出手段で抽出された前記代表データと、前記代表データの生成に際して利用された前記交換データ内の前記代表データとの利用関係を示す関係情報を生成し、データ合成手段が、フェーズ別業務管理手段が取得した前記交換データに、前記代表データ抽出手段が抽出した前記代表データと、前記関係情報生成手段が生成した前記関係情報とを合成して前記交換データを更新し、更新された前記交換データを次のフェーズを担当する前記フェーズ別業務管理手段に渡す、ことを特徴とする業務管理方法が提供される。

このような業務管理方法によれば、フェーズごとのフェーズ別業務管理手段により、担当フェーズが割り当てられ、前段のフェーズそれぞれにおける代表データと関係情報とを含む交換データが取得され、ユーザからの操作入力に応答して、取得した交換データに含まれる代表データを利用して担当フェーズ内の業務が実行され、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータが生成される。フェーズ別業務管理手段でフェーズデータが生成されると、代表データ抽出手段により、スキーマが参照され、スキーマで指定されている代表データのデータ項目に合致するデータが、代表データとしてフェーズデータから抽出される。すると、関係情報生成手段により、フェーズ別業務管理手段で生成された前記フェーズデータを参照し、代表データ抽出手段で抽出された代表データと、代表データの生成に際して利用された交換データ内の代表データとの利用関係を示す関係情報が生成される。そして、データ合成手段により、フェーズ別業務管理手段が取得した交換データに、代表データ抽出手段が抽出した代表データと、関係情報生成手段が生成した関係情報とが合成されることで交換データが更新され、更新された交換データが次のフェーズを担当するフェーズ別業務管理手段に渡される。

本発明では、後続のフェーズに送る交換データ内の代表データと、その代表データの生成に際して利用されたデータとの利用関係を示す関係情報を含めるようにした。そのため、後続のフェーズで何らかの問題が発生した場合、関係情報に基づいて、問題の生じたデータの利用元となるデータを容易に特定することができる。

本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

本実施の形態における機能の概略を示す図である。 交換データのデータ構造例を示す図である。 第１の実施の形態のシステム構成例を示す図である。 本実施の形態に用いるサーバのハードウェア構成例を示す図である。 第１の実施の形態の機能を示すブロック図である。 スキーマの作成手順を示すフローチャートである。 商談フェーズのデータベースから抽出される代表データを示す図である。 設計フェーズのデータベースから抽出される代表データを示す図である。 構築フェーズのデータベースから抽出される代表データを示す図である。 スキーマの例を示す第１の図である。 スキーマの例を示す第２の図である。 スキーマの例を示す第３の図である。 商談／設計フェーズでの処理手順を示す図である。 構築／運用フェーズでの処理手順を示す図である。 見積もりデータの例を示す図である。 商談ＸＭＬ文書の例を示す図である。 設計データの例を示す図である。 設計ＸＭＬ文書の例を示す図である。 実システムデータの例を示す図である。 構築ＸＭＬ文書の例を示す第１の図である。 構築ＸＭＬ文書の例を示す第２の図である。 第２の実施の形態のシステム構成を示す図である。 第２の実施の形態の機能を示すブロック図である。 サーバ機器管理情報の例を示す図である。 ストレージ機器管理情報の例を示す図である。 ネットワーク機器管理情報の例を示す図である。 サーバ管理ＸＭＬ文書の例を示す図である。 ストレージ管理ＸＭＬ文書の例を示す図である。 ネットワーク管理ＸＭＬ文書の例を示す図である。 リソース管理ＸＭＬ文書の例を示す第１の図である。 リソース管理ＸＭＬ文書の例を示す第２の図である。 リソース管理ＸＭＬ文書の例を示す第３の図である。 運用フェーズからのフィードバックの対処フローを示す図である。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、本実施の形態における機能の概略を示す図である。図１に示すように、本実施の形態は、スキーマ記憶手段１と複数の業務管理装置２，３で構成される。この例では、業務がｎ個（ｎは自然数）のフェーズで行われる。図１には、フェーズ１，２，３，…，ｉ，ｉ＋１，…，ｎ（ｉは、２以上ｎ未満の自然数）からなるライフサイクルの一部の業務管理装置のみが代表として示されている。業務管理装置２は、ｉ番目のフェーズに対応する業務を管理する。業務管理装置３は、ｉ＋１番目のフェーズに対応する業務を管理する。

スキーマ記憶手段１は、フェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき事項を示す代表データのデータ項目を含むスキーマを記憶する。図１の例では、フェーズごとのスキーマ１ａ，１ｂ，１ｃ，１ｄが記憶されている。

業務管理装置２は、フェーズ別業務管理手段２ａ、データ受信手段２ｂ、データ管理手段２ｃ、データ記憶手段２ｄ、代表データ抽出手段２ｅ、関係情報生成手段２ｆ、およびデータ合成手段２ｇを有している。同様に、業務管理装置３は、フェーズ別業務管理手段３ａ、データ受信手段３ｂ、データ管理手段３ｃ、データ記憶手段３ｄ、代表データ抽出手段３ｅ、関係情報生成手段３ｆ、およびデータ合成手段３ｇを有している。

フェーズごとのフェーズ別業務管理手段２ａ，３ａは、担当フェーズが割り当てられ、前段のフェーズそれぞれにおける代表データと関係情報とを含む交換データ４，５を取得し、ユーザからの操作入力に応答して、取得した交換データ４，５に含まれる代表データを利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して参照されたデータを示すフェーズデータを生成する。

データ受信手段２ｂ，３ｂは、前段のフェーズに対応する他の業務管理装置から送信される前記交換データ４，５を受信する。受信した交換データ４，５は、データ管理手段２ｃ，３ｃを介してデータ記憶手段２ｄ，３ｄに格納される。

データ記憶手段２ｄ、３ｄは、フェーズデータや交換データ４，５を記憶する。
データ管理手段２ｃ，３ｃは、フェーズ別業務管理手段２ａ，３ａで作成されたフェーズデータや、データ受信手段２ｂ，３ｂが受信した交換データ４，５を、データ記憶手段２ｄ，３ｄに格納する。また、データ管理手段２ｃ，３ｃは、フェーズ別業務管理手段２ａ，３ａからの要求に応じて、データ記憶手段２ｄ，３ｄに格納された交換データ４，５をフェーズ別業務管理手段２ａ，３ａに渡す。さらに、データ管理手段２ｃ，３ｃは、フェーズ別業務管理手段２ａ，３ａで生成されたフェーズデータを、代表データ抽出手段２ｅ，３ｅに渡す。

代表データ抽出手段２ｅ，３ｅは、フェーズ別業務管理手段２ａ，３ａからフェーズデータを受けると、スキーマを参照し、スキーマで指定されている代表データのデータ項目に合致するデータを、代表データとしてフェーズデータから抽出する。

関係情報生成手段２ｆ，３ｆは、フェーズ別業務管理手段２ａ，３ａで生成されたフェーズデータを参照し、代表データ抽出手段２ｅ，３ｅで抽出された代表データと、データ受信手段２ｂ，３ｂで受信された交換データ４，５内の代表データとの利用関係を示す関係情報を生成する。

データ合成手段２ｇ，３ｇは、データ受信手段２ｂ，３ｂで受信された交換データ４，５に、代表データ抽出手段２ｅ，３ｅが抽出した代表データと、関係情報生成手段２ｆ，３ｆが生成された関係情報とを合成して交換データ４，５を更新し、更新された交換データをそれぞれ交換データ５，６として次のフェーズを担当するデータ受信手段２ｂ，３ｂに渡す。

図２は、交換データのデータ構造例を示す図である。この例は、「ｉ」番目のフェーズで生成される交換データ５を示している。交換データ５は、「ｉ−１」番目のフェーズまでの代表データと関係情報とを有する交換データ４、「ｉ」番目のフェーズの代表データ５ａ、および「ｉ−１」番目までの代表データと「ｉ」番目のフェーズの代表データとの利用関係を示す関係情報５ｂで構成される。

図１示した構成による業務管理手順を以下に示す。
まず、業務管理装置２において、データ受信手段２ｂが上流のフェーズ（ｉ−１番目）から交換データ４を受信する。データ管理手段２ｃでは、データ受信手段２ｂが受信した交換データ４をデータ記憶手段２ｄに格納する。その後、フェーズ別業務管理手段２ａが、交換データ４内の所定の代表データを利用しながら担当業務を遂行し、フェーズデータを生成する。生成されたフェーズデータは、データ管理手段２ｃによってデータ記憶手段２ｄに格納されると共に、代表データ抽出手段２ｅに渡される。

代表データ抽出手段２ｅでは，「ｉ」番目のフェーズに対応するスキーマ１ｂを参照し、フェーズデータの中から後続のフェーズで利用する代表データを過不足なく抽出する。この時、フェーズデータ内の全てのデータが代表データとなることも有り得る。

一方、関係情報生成手段２ｆでは、データ受信手段２ｂから交換データ４を受け取り、代表データ抽出手段２ｅから担当フェーズの代表データを受け取る。そして、関係情報生成手段２ｆは、フェーズ別業務管理手段２ａで生成されたフェーズデータを参照し、関係情報を生成する。

データ合成手段２ｇは、データ受信手段２ｂから交換データ４を受け取り、代表データ抽出手段２ｅから担当フェーズの代表データを受け取り、関係情報生成手段２ｆから関係情報を受け取る。そして、データ合成手段２ｇは、交換データ４に、代表データと関係情報とを合成し、更新後の交換データ５を生成する。さらに、データ合成手段２ｇは、交換データ５を、次のフェーズのデータ受信手段３ｂに送信する。

「ｉ＋１」番目のフェーズを担当する業務管理装置３では、データ受信手段３ｂが交換データ５を受信し、データ管理手段３ｃに渡す。データ管理手段３ｃは、受け取ったデータをデータ記憶手段３ｄに格納すると共に、フェーズ別業務管理手段３ａに渡す。

フェーズ別業務管理手段３ａは、交換データ５に含まれている前フェーズまでの代表データを適宜利用して、担当フェーズの業務を実行する。その際、前のフェーズまでの代表データが原因で問題が発生した場合、フェーズ別業務管理手段３ａ、該当フェーズのフェーズ別業務管理手段に対して、障害の内容・箇所を示す障害情報を通知する。フェーズ別業務管理手段３ａによる業務で問題が発生しなければ、以後、業務管理装置２で行われた処理と同様の手順で交換データ６が生成され、後続のフェーズを担当する他の業務管理装置に送信される。

このように、業務管理装置では、ＩＴシステム・ライフサイクルのどのフェーズにおいても同様のシステム構成となる。そして、業務管理装置において、先行フェーズのみが保持し、受け取った交換データにも含まれていない詳細情報が必要となった場合には、各フェーズを担当する業務管理装置は、受け取った交換データに含まれる関係情報により、前フェーズの管理システムで生成された代表データを特定できる。さらに、前フェーズの業務管理装置に特定した代表データを照会することで、詳細情報を入手できる。

例えば、装置の位置情報は通常時は必要としないが装置故障などの緊急時においてどこに配置されているのかを知るために必要となるかもしれない。そのような場合に、交換データに含まれる故障装置のＩＤをキーとして位置情報を持つ業務管理装置に問い合わせることで情報を取得できる。さらに、交換データ内の情報もしくは照会して入手した詳細情報をもとに、前フェーズの業務管理装置に対してデータ更新リクエストを送ることもできる。

なお、図１では、各フェーズの受信および送信で利用されるスキーマとして、フェーズごとに独立したスキーマを用意しているが、全体で統一したスキーマを用意してもよい。
フェーズごとに独立したスキーマを用意する場合は、送受信を行う２つのフェーズの管理システム間で必要とされる情報を過不足なく定義したスキーマとなる。ただし、前フェーズまでの情報の中で，当該フェーズにおいては利用しなくても当該フェーズより後のフェーズにおいて利用される情報も交換データに含めるよう、スキーマを策定する。

全フェーズで統一したスキーマを用いる場合、全てのフェーズの代表データと、さらに全フェーズ間の関係情報を含めた内容・構造のスキーマが定義される。
また、図１では、フェーズごとの業務管理装置２，３を設けているため、データ受信手段２ｂ，３ｂが必要となっている。遂行順が連続する複数のフェーズの業務が１つの業務管理装置で行われる場合、その業務管理装置内の２つめ以降のフェーズに対応するデータ受信手段は不要となる。

すなわち、前のフェーズのデータ合成手段が次のフェーズのデータ管理手段などへ直接交換データを入力すればよい。
また、図１ではスキーマ記憶手段１が独立しているが各フェーズの業務管理装置内に各々スキーマ記憶機能を備えてもよい。スキーマがフェーズごとに用意されていた場合には受信、送信時に使用する２つのスキーマ（「ｉ」番目のフェーズの業務管理装置の場合は「ｉ−１」番目のフェーズ用のスキーマおよび「ｉ」番目のフェーズ用のスキーマ）を保持する。一方、全フェーズで統一したスキーマの場合は、各リソース管理システムに設けるスキーマ管理手段はまったく同一のスキーマを保持することになる。

なお、管理システム間で交換するデータの形式は、共通のものであればよい。ところで、近年、上記のようなデータ交換や保存に用いるメタ言語としてＸＭＬが注目されている。ＸＭＬは拡張性に優れ、特定のプラットフォーム・言語に依存しないので高い相互運用性を確保できる。また、構造を持ったテキスト形式表現が可能であるため、人間・マシン双方にとって扱い易いというメリットがある。さらに、ＸＭＬ文書の内容および構造を規定するＸＭＬスキーマを作成することで、文書の内容が妥当かどうかを容易に検証できる。よって、以下の実施の形態ではＸＭＬを交換データフォーマットとして利用し、さらにスキーマ管理システムで管理するスキーマもＸＭＬスキーマを利用するものとする。

［第１の実施の形態］
次に、第１の実施の形態の詳細を説明する。
図３は、第１の実施の形態のシステム構成例を示す図である。第１の実施の形態は、商談フェーズ、設計フェーズ、構築フェーズ、および運用フェーズを経て、ＩＴシステム構築を行う場合の例である。図３の例では、商談フェーズ管理システム１００、設計フェーズ管理システム２００、構築フェーズ管理システム３００、運用フェーズ管理システム４００、およびスキーマ管理システム５００がネットワーク１０を介して接続されている。

商談フェーズ管理システム１００は、顧客との商談を取りまとめる際に使用するコンピュータシステムである。商談フェーズ管理システム１００は、ストレージ機器１１０とサーバ１２０とで構成される。ストレージ機器１１０には、商談結果を示すデータが格納される。

設計フェーズ管理システム２００は、商談結果に基づいて、顧客の希望するシステムを設計する際に使用するコンピュータシステムである。設計フェーズ管理システム２００は、ストレージ機器２１０とサーバ２２０とで構成される。ストレージ機器２１０には、設計結果を示すデータが格納される。

構築フェーズ管理システム３００は、設計内容に従って、実際の機器の接続およびソフトウェア導入などを行いシステムを構築する際に使用するコンピュータシステムである。構築フェーズ管理システム３００は、ストレージ機器３１０とサーバ３２０とで構成される。ストレージ機器３１０には、構築結果を示すデータが格納される。

運用フェーズ管理システム４００は、構築されたシステムの運用中に、運用状況の管理などのために使用するコンピュータシステムである。運用フェーズ管理システム４００は、ストレージ機器４１０とサーバ４２０とで構成される。ストレージ機器４１０には、運用状況を示すデータが格納される。

スキーマ管理システム５００は、スキーマを管理するためのコンピュータシステムである。スキーマ管理システム５００は、ストレージ機器５１０とサーバ５２０とで構成される。ストレージ機器５１０には、フェーズごとのスキーマが格納される。すなわち、スキーマには、フェーズごとに、次フェーズ用に引き継ぐ生成するデータの内容や構造が規定されている。

このように、本システムでは、ＩＴシステムのライフサイクルを商談、設計、構築、運用の４フェーズに分け、フェーズごとにリソース管理システムを用意する。ただし、ライフサイクルがこの４フェーズに限定されるわけではなく、より多くもしくは少ないフェーズから成り立っていてもよい。

図４は、本実施の形態に用いるサーバのハードウェア構成例を示す図である。サーバ１２０は、ＣＰＵ（Central Processing Unit）１２０ａによって装置全体が制御されている。ＣＰＵ１２０ａには、バス１２０ｇを介してＲＡＭ（Random Access Memory）１２０ｂ、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１２０ｃ、グラフィック処理装置１２０ｄ、入力インタフェース１２０ｅ、および通信インタフェース１２０ｆが接続されている。

ＲＡＭ１２０ｂには、ＣＰＵ１２０ａに実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１２０ｂには、ＣＰＵ１２０ａによる処理に必要な各種データが格納される。ＨＤＤ１２０ｃには、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１２０ｄには、モニタ１１が接続されている。グラフィック処理装置１２０ｄは、ＣＰＵ１２０ａからの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１２０ｅには、キーボード１２とマウス１３とが接続されている。入力インタフェース１２０ｅは、キーボード１２やマウス１３から送られてくる信号を、バス１２０ｇを介してＣＰＵ１２０ａに送信する。

通信インタフェース１２０ｆは、ネットワーク１０に接続されている。通信インタフェース１２０ｆは、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図４には、商談フェーズ管理システム１００内のサーバ１２０のハードウェア構成を示したが、他のサーバ２２０，３２０，４２０，５２０も同様のハードウェア構成で実現することができる。

図５は、第１の実施の形態の機能を示すブロック図である。商談フェーズ管理システム１００は、商談ＤＢ１１１、商談管理部１２１、データ管理部１２２、データ受信部１２３、代表データ抽出部１２４、関係情報生成部１２５、およびデータ合成・送信部１２６を有する。

商談ＤＢ１１１は、ストレージ機器１１０内に構築されたデータベースである。商談ＤＢ１１１には、商談に利用されたデータおよび商談結果を示すデータが格納される。
商談管理部１２１は、営業担当による顧客との商談を支援するための処理機能である。例えば、見積書作成機能が含まれる。商談管理部１２１は、商談を支援するために、データ管理部１２２を介して商談ＤＢ１１１内のデータを参照すると共に、商談結果などの情報を商談ＤＢ１１１に格納する。

データ管理部１２２は、商談ＤＢ１１１へのデータの入出力を行う。例えば、データ管理部１２２は、商談管理部１２１から商談結果を示す情報（商談ＸＭＬ文書）を受け取ると、その情報を商談ＤＢ１１１に格納する。

データ受信部１２３は、上位のフェーズからの交換データを受信する。受信した交換データは、データ管理部１２２を介して商談ＤＢ１１１に格納されると共に、関係情報生成部１２５およびデータ合成・送信部１２６に渡される。また、データ受信部１２３は、受信した交換データが正しいデータかどうかを予め規定したスキーマ３０と照らし合わせて検証し、その後、必要であれば当該フェーズにおいて扱い易いデータ形式に変換することができる。なお、図５の例では、業務の遂行順において商談フェーズが最上位であり、商談フェーズ管理システム１００のデータ受信部１２３に入力される交換データはない。

代表データ抽出部１２４は、後続フェーズで必要とするデータを商談ＤＢ１１１から抽出する。抽出されたデータは、関係情報生成部１２５とデータ合成・送信部１２６とに渡される。どのデータが後続フェーズで必要とされるのかは、スキーマ管理システム５００内の商談データ用スキーマ３０ａに基づいて判断される。

関係情報生成部１２５は、データ受信部１２３から受け取った上位フェーズのデータと、代表データ抽出部１２４から受け取ったデータとの関連づけを定義する関係情報を生成する。生成された関係情報は、データ合成・送信部１２６に渡される。

データ合成・送信部１２６は、データ受信部１２３から受け取った上位フェーズのデータ、代表データ抽出部１２４から受け取った代表データ、および関係情報生成部１２５から受け取った関係情報を合成し、交換データを生成する。そして、データ合成・送信部１２６は、生成された交換データを設計フェーズ管理システム２００に対して送信する。また、データ合成・送信部１２６は、生成した交換データをデータ管理部１２２を介して商談ＤＢ１１１に格納する。

設計フェーズ管理システム２００は、設計ＤＢ２１１，システム設計管理部２２１、データ管理部２２２、データ受信部２２３、代表データ抽出部２２４、関係情報生成部２２５、およびデータ合成・送信部２２６を有する。

設計ＤＢ２１１は、ストレージ機器２１０内に構築されたデータベースである。設計ＤＢ２２１には、設計に利用されたデータ、および設計結果を示すデータが格納される。
システム設計管理部２２１は、商談結果に基づいてシステム設計を支援するための処理機能である。システム設計管理部２２１は、設計を支援するために、データ管理部２２２を介して設計ＤＢ２１１内のデータを参照すると共に、設計結果などの情報を設計ＤＢ２１１に格納する。

設計フェーズ管理システム２００内のデータ管理部２２２、データ受信部２２３、代表データ抽出部２２４、関係情報生成部２２５、およびデータ合成・送信部２２６に関しては、以下に示す相違点を除き、商談フェーズ管理システム１００内の同名の構成要素と同様の機能を有する。

商談フェーズ管理システム１００との相違点は次の通りである。データ受信部２２３には、商談フェーズ管理システム１００のデータ合成・送信部１２６が出力した交換データが入力される。代表データ抽出部２２４は、代表データの抽出の際には、設計データ用スキーマ３０ｂを参照する。データ合成・送信部２２６は、生成された交換データを構築フェーズ管理システム３００に対して送信する。

構築フェーズ管理システム３００は、構築ＤＢ３１１、システム構築管理部３２１、データ管理部３２２、データ受信部３２３、代表データ抽出部３２４、関係情報生成部３２５、およびデータ合成・送信部３２６を有する。

構築ＤＢ３２１は、ストレージ機器３１０内に構築されたデータベースである。構築ＤＢ３２１には、システム構築に利用されたデータ、およびシステム構築結果を示すデータが格納される。

システム構築管理部３２１は、設計結果に基づいてシステム構築を支援するための処理機能である。システム構築管理部３２１は、システム構築を支援するために、データ管理部３２２を介して構築ＤＢ３１１内のデータを参照すると共に、システム構築結果などの情報を構築ＤＢ３１１に格納する。

構築フェーズ管理システム３００内のデータ管理部３２２、データ受信部３２３、代表データ抽出部３２４、関係情報生成部３２５、およびデータ合成・送信部３２６に関しては、以下に示す相違点を除き、商談フェーズ管理システム１００内の同名の構成要素と同様の機能を有する。

商談フェーズ管理システム１００との相違点は次の通りである。データ受信部３２３には、設計フェーズ管理システム２００のデータ合成・送信部２２６が出力した交換データが入力される。代表データ抽出部３２４は、代表データの抽出の際には、構築データ用スキーマ３０ｃを参照する。データ合成・送信部３２６は、生成された交換データを運用フェーズ管理システム４００に対して送信する。

運用フェーズ管理システム４００は、運用ＤＢ４１１，運用管理部４２１、データ管理部４２２、データ受信部４２３、代表データ抽出部４２４、関係情報生成部４２５、およびデータ合成・送信部４２６を有する。

運用ＤＢ４２１は、ストレージ機器４１０内に運用されたデータベースである。運用ＤＢ４２１には、システム運用に利用されたデータ、およびシステム運用結果を示すデータが格納される。

運用管理部４２１は、設計結果に基づいてシステム運用を支援するための処理機能である。運用管理部４２１は、システム運用を支援するために、データ管理部４２２を介して運用ＤＢ４１１内のデータを参照すると共に、システム運用結果などの情報を運用ＤＢ４１１に格納する。

運用フェーズ管理システム４００内のデータ管理部４２２、データ受信部４２３、代表データ抽出部４２４、関係情報生成部４２５、およびデータ合成・送信部４２６に関しては、以下に示す相違点を除き、商談フェーズ管理システム１００内の同名の構成要素と同様の機能を有する。

商談フェーズ管理システム１００との相違点は次の通りである。データ受信部４２３には、構築フェーズ管理システム３００のデータ合成・送信部３２６が出力した交換データが入力される。代表データ抽出部４２４は、代表データの抽出の際には、運用データ用スキーマ３０ｄを参照する。データ合成・送信部４２６は、生成された交換データの出力先はない。

スキーマ管理システム５００は、フェーズごとのスキーマを管理する。図５の例では、スキーマ管理システム５００において、商談データ用スキーマ３０ａ、設計データ用スキーマ３０ｂ、構築データ用スキーマ３０ｃ、および運用データ用スキーマ３０ｄが管理されている。商談データ用スキーマ３０ａ、設計データ用スキーマ３０ｂ、構築データ用スキーマ３０ｃ、および運用データ用スキーマ３０ｄは、具体的には、スキーマ管理システム５００内のストレージ機器５１０内に格納される。なお、図５では、管理システムとスキーマとの対応関係を分かりやすくするためにフェーズごとのスキーマが示されているが、本実施の形態では、全ライフサイクルで共有のスキーマ３０を利用するものとする。

以上のような構成のシステムにより、異なるフェーズ間の連係を取って、ＩＴシステムの導入から運用管理に至るまでのデータの管理が可能となる。なお、図５に示したシステムの運用を開始する前に、各フェーズのデータベース（商談ＤＢ１１１、設計ＤＢ２１１、構築ＤＢ３１１、運用ＤＢ４１１）で管理されるデータのデータ構造（データの項目名や階層構造など）は予め定義されているものとする。また、ユーザは、各データベースのデータ構造を参照して、予めスキーマ作成する。

図６は、スキーマの作成手順を示すフローチャートである。以下、図６に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］ユーザはスキーマ管理システム５００内のサーバ５２０を利用し、全てのフェーズに関し、各フェーズで運用管理上利用する情報を全て抽出する。例えば、サーバ５２０から各フェーズのデータベース（商談ＤＢ１１１、設計ＤＢ２１１、構築ＤＢ３１１、運用ＤＢ４１１）にアクセスし、各データベース内に定義されているデータ項目を抽出する。抽出されるデータ項目には当該フェーズで新規に入力・生成した情報以外に、先行フェーズから引き継ぐ情報も含まれる。

［ステップＳ１２］ユーザはサーバ５２０を利用し、ステップＳ１１で抽出した情報をモニタの画面で確認する。そして、ユーザは、最後尾フェーズから順に、先行する任意のフェーズから受け取るべき情報（代表データ）のデータ項目を全て抽出する。

具体的には、ユーザは、運用ＤＢ４１１内のデータ項目を参照し、先行する構築フェーズから受け取るべき情報（構築フェーズの代表データ）か否かを判断する。そして、ユーザは、運用ＤＢ内のデータ項目から、構築フェーズから受け取るべき情報をサーバ５２０のモニタ画面上で選択する。以降、構築ＤＢ３１１、設計ＤＢ２１１の順で情報の抽出を行う。なお、商談フェーズが最上位であるため、商談ＤＢ１１１からの情報の抽出作業は不要である。

ステップＳ１２の処理により、各フェーズで生成した情報が後続でも必要とされるのかどうかが明らかになる。このステップで抽出された情報は、その情報を最初に生成するフェーズの代表データとする。

［ステップＳ１３］ユーザはサーバ５２０を利用し、先頭フェーズから順に、１つ前のフェーズまでの代表データと当該フェーズから新たに次フェーズに送る代表データとの間の関係情報を設定するためのデータ項目を生成する。

ここでいう関係情報とは、注目しているデータを生成する際に参照したり基となったりしたデータにリンクを張ることを意味する。後続フェーズにおいて何らかの障害が発生した場合、もしくは詳細情報を参照したくなった場合などに、このリンクを辿ることで関係するデータをすべて導くことが可能となる。

以上の代表データと関係情報とが後述のデータ送信手段を用いて後続フェーズへと送られることになる。ただし、現段階ではそれらのデータをどのような形式で送るかまでは決定されていない。そこで、次のステップＳ１４が行われる。

［ステップＳ１４］ユーザはサーバ５２０を利用し、各フェーズについて、代表データと関係情報とを送る際の交換データの内容・構造を規定したスキーマを生成する。本実施の形態では、ＸＭＬ形式によって次フェーズへデータを送るものとする。このスキーマが、フェーズ分用意されて、スキーマ管理システム５００のストレージ機器５１０に登録される。

以上のような手順で、スキーマが作成される。以下、スキーマの具体的な作成例を説明する。まず、図７〜図９を参照して、各フェーズのデータベースからの代表データの抽出例を説明する。

図７は、商談フェーズのデータベースから抽出される代表データを示す図である。図７において、上段に商談ＤＢ内データ項目２１が示されており、下段に設計ＤＢ内データ項目２２が示されている。

図８は、設計フェーズのデータベースから抽出される代表データを示す図である。図８において、上段に設計ＤＢ内データ項目２２が示されており、下段に構築ＤＢ内データ項目２３が示されている。

図９は、構築フェーズのデータベースから抽出される代表データを示す図である。図９において、上段に構築ＤＢ内データ項目２３が示されており、下段に運用ＤＢ内データ項目２４が示されている。

図７〜図９中、下線を引いたデータ項目が、後続のフェーズで利用されるデータ項目である。また、フェーズ間で引き継がれるデータ項目（代表データ）同士の関係を、破線で示している。これらの情報から作成したスキーマ（RELAX NG Compact Syntaxを利用）を、図１０〜図１２に示す。なお、今回はすべてのフェーズで利用できる共通スキーマとした。そのため、本スキーマ１つで、全フェーズで生成されるＸＭＬ文書の検証を行う。

図１０は、スキーマの例を示す第１の図である。図１１は、スキーマの例を示す第２の図である。図１２は、スキーマの例を示す第３の図である。スキーマ３０は、図１０から始まり、図１１、図１２へと続く。

スキーマ３０中の要素（element）に設定されている「attribute ID ｛ xsd:ID ｝」が、代表データのデータ項目に該当する各データのＩＤ（識別情報）を示している。また、「attribute 参照 ｛ xsd:IDREF｝」という記述が、関連情報のデータ項目に相当し、各データ項目に設定されるデータの参照先のデータのＩＤ（識別情報）を示している。

このようなスキーマ３０がスキーマ管理システム５００内のストレージ機器５１０に格納される。
次に、図５のシステムにおける商談／設計／構築／運用フェーズでの処理手順を説明する。

図１３は、商談／設計フェーズでの処理手順を示す図である。以下、ステップ番号に沿って、図１３に示す処理を説明する。
［ステップＳ２１］営業などの商談を担当するユーザが、商談フェーズ管理システム１００の商談管理部１２１を用いて、構築するシステムの見積もりを行う。ステップＳ２１は、商談フェーズ管理システム１００のサーバ１２０にユーザが必要な情報を入力することによって実行される。なお、商談管理部１２１では、例えば、顧客が希望する機能や性能の入力を受け付け、機能および性能を満たす最適な構成を決定する。見積もり処理の結果、見積もりデータ４１が生成される。

［ステップＳ２２］代表データ抽出部１２４が、見積もりデータ４１から代表データを抽出する。見積もりデータ４１中の各データが代表データか否かは、スキーマ３０を参照して判断される。すなわち、代表データ抽出部１２４は、スキーマ３０に定義されたデータ項目に相当するデータであれば、代表データとして抽出する。

［ステップＳ２３］データ合成・送信部１２６は、代表データ抽出部１２４が抽出した代表データをＸＭＬ形式に文書化する。その結果、商談ＸＭＬ文書４２が生成される。生成された商談ＸＭＬ文書４２は、設計フェーズ管理システム２００のデータ受信部２２３に渡される。

［ステップＳ２４］設計フェーズ管理システム２００のシステム設計管理部２２１は、商談フェーズで生成された商談ＸＭＬ文書４２を入力として、ネットワーク構成などのより詳細な設計を行う。

［ステップＳ２５］システム設計管理部２２１は、もし見積もりデータに誤りがあった場合には、受け取った商談ＸＭＬ文書４２の情報をキーとして商談管理部１２１にフィードバックする。見積もりデータに問題がなければ、システム設計管理部２２１は、詳細な設計データ４３を生成する。設計データ４３は、データ管理部２２２によって設計ＤＢ２１１に格納される。

［ステップＳ２６］代表データ抽出部２２４は、スキーマ３０を参照し、設計データ４３から代表データを抽出する。
［ステップＳ２７］データ合成・送信部２２６は、代表データ抽出部２２４で抽出された設計フェーズの代表データと、データ受信部２２３から受け取った交換データとを付き合わせて、関係情報を生成する。

［ステップＳ２８］データ合成・送信部２２６は、データ受信部２２３から受け取った交換データに、設計フェーズの代表データと関係情報とを合成し、設計ＸＭＬ文書４４を生成する。生成された設計ＸＭＬ文書４４は、構築フェーズ管理システム３００のデータ受信部３２３に渡される。

図１４は、構築／運用フェーズでの処理手順を示す図である。以下、ステップ番号に沿って、図１４に示す処理を説明する。
［ステップＳ３１］構築フェーズ管理システム３００のシステム構築管理部３２１は、設計フェーズで生成された設計ＸＭＬ文書４４を入力として、実際のシステムを構築する。

［ステップＳ３２］システム構築管理部３２１は、もし見積もりデータに誤りがあった場合には、受け取った設計ＸＭＬ文書４４の情報をキーとして商談管理部１２１にフィードバックする。また、システム構築管理部３２１は、接続関係などの設計データに誤りがあった場合には、受け取った設計ＸＭＬ文書４４の情報をキーとしてシステム設計管理部２２１にフィードバックする。例えば、システム構築管理部３２１は、どの部分の接続が誤っているのかという情報をシステム設計管理部２２１に伝達する。これにより、システム設計管理部２２１で再設計が行われる。

見積もりデータと設計データとに問題がなければ、システム構築管理部３２１は、設計ＸＭＬ文書４４に記載されているデータに基づいて、システムを構築設計する。その結果、実システムデータ４５が生成される。実システムデータ４５は、データ管理部３２２によって構築ＤＢ３１１に格納される。

［ステップＳ３３］代表データ抽出部３２４は、スキーマ３０を参照し、実システムデータ４５から代表データを抽出する。
［ステップＳ３４］データ合成・送信部３２６は、代表データ抽出部３２４で抽出された構築フェーズの代表データと、データ受信部３２３から受け取った設計ＸＭＬ文書４４とを付き合わせて、関係情報を生成する。

［ステップＳ３５］データ合成・送信部３２６は、データ受信部３２３から受け取った設計ＸＭＬ文書４４に、構築フェーズの代表データと関係情報とを合成し、構築ＸＭＬ文書４６を生成する。生成された構築ＸＭＬ文書４６は、運用フェーズ管理システム４００のデータ受信部４２３に渡される。

［ステップＳ３６］最終の運用フェーズでは、運用フェーズ管理システム４００の運用管理部４２１は、構築フェーズで生成された構築ＸＭＬ文書４６を受け取ってシステムの運用および監視を行う。

［ステップＳ３７］運用管理部４２１は、運用中に特に問題がなければ、そのままシステム運用を続行する。
［ステップＳ３８］運用管理部４２１は、システム状態を監視した結果、もし何らかの不具合が発生した場合には、当該フェーズ内で解消できるならば、ステップＳ３９に進める。運用管理部４２１は、当該フェーズで解消できない場合には、適切なフェーズにまで戻って問題を解決する。

［ステップＳ３９］不具合を解消して運用を再開する。
以下に、図１３，図１４に示した処理の内容を、具体例を用いて説明する。
図１５は、見積もりデータの例を示す図である。見積もりデータ４１にはサービス内容やシステム構成の他に、顧客情報やトータルコストなどの情報が含まれる。見積もりデータ４１に含まれる情報は、データ管理部１２２によって全て商談ＤＢ１１１に格納される。しかし、後続フェーズではこれら全ての情報が必要というわけではなく、むしろプライバシー／セキュリティ保護の観点から、外部に公開しないよう積極的に省くべき情報もある。そこで、代表データ抽出部１２４で、後続のフェーズで利用する代表データのみが抽出される。そして、データ合成・送信部１２６によって、商談ＸＭＬ文書４２が生成される。

図１６は、商談ＸＭＬ文書の例を示す図である。図１６に示した商談ＸＭＬ文書４２を、図１５の見積もりデータ４１と比較すると、商談ＸＭＬ文書４２には顧客情報およびコスト情報が含まれていないことが分かる。一方で、サービス構成や各ハードウェア／ソフトウェア構成情報は後続フェーズで必要である。そのため、それらの情報は、商談ＸＭＬ文書４２に含まれている。

このような商談ＸＭＬ文書４２に基づいて、システム設計管理部２２１によってシステムの設計が行われる。ここで、見積もりに問題があった場合、例えば、ＷＥＢ層のサーバ数が不足していた場合には、システム設計管理部２２１は、商談ＸＭＬ文書４２中のID『hw1』と問題点（『サーバ台数の不足』）および不足台数を、商談管理部１２１に障害情報として返す。商談ＸＭＬ文書４２に問題がなければ、システム設計管理部２２１で設計データ４３が生成される。

図１７は、設計データの例を示す図である。この設計データ４３は、商談ＸＭＬ文書４２から得られたハードウェア情報を基に、各装置の具体的な接続関係および配置情報（どのパーティションに属するか）が決定されている。

この例では、システムが複数のパーティション４３ａ，４３ｂ，４３ｃに分けられている。
パーティション４３ａには、ファイアウォール５１とスイッチ５２が属している。ファイアウォール５１のＩＤは「nw1」である、スイッチ５２はギガバイトイーサネット（登録商標）スイッチであり、ＩＤは「nw2」である。

パーティション４３ｂには、３台のサーバ５３〜５５とスイッチ５６とが属している。サーバ５３のＩＤは「svr1」である。サーバ５４のＩＤは「svr2」である。サーバ５５のＩＤは「svr3」である。スイッチ５６はギガバイトイーサネットスイッチであり、ＩＤは「nw3」である。

パーティション４３ｃには、３台のサーバ５７，５８，６０、スイッチ５９、およびストレージ装置６１が属している。サーバ５７のＩＤは「svr4」である。サーバ５８のＩＤは「svr5」である。サーバ６０のＩＤは「svr6」である。スイッチ５９はギガバイトイーサネットスイッチであり、ＩＤは「nw4」である。ストレージ装置６１のＩＤは「str1」である。

設計データ４３のうち配置情報は、後続フェーズでは不要である。そのため、代表データ抽出部２２４により、設計データ４３から配置情報を除いた他のデータが、代表データとして抽出される。そして、関係情報生成部２２５により、必要最小限となった設計フェーズの代表データと商談フェーズから送られてきた商談ＸＭＬ文書４２とが照合され、関係情報が生成される。さらに、データ合成・送信部２２６によって、商談ＸＭＬ文書４２に、代表データと関係情報とが合成され、設計ＸＭＬ文書４４が生成される。

なお、図１７には示していないが、各装置が図１６に示す商談ＸＭＬ文書４２内のどのデータを参照して設定されたのかを示す情報が、設計データ４３に含まれている。例えば、サーバID="hw1"を参照して、サーバ５３〜５５が設定されたことを示す情報が、設計データ４３に含まれている。

図１８は、設計ＸＭＬ文書の例を示す図である。設計ＸＭＬ文書４４には、前フェーズから送られてきた情報に加えて、『システム詳細テンプレート』タグで囲まれた情報が追加されている。なお、図１８は新たに追加された情報のみを示しており、省略された部分には、図１６に示す商談ＸＭＬ文書４２の内容が含まれる。

設計ＸＭＬ文書４４には、各装置の必要最小限の情報と接続関係情報とが含まれる。また、各ハードウェア、ソフトウェア情報には、見積もり時のハードウェア、ソフトウェアのどれに対応するのかを示す『参照』属性が各々に付与されている。『参照』属性が、関連情報であり、先行するフェーズのどの代表データが参照されたのかを示している。例えば、<サーバID="svr1" 参照="hw1" タイプ="Windowsサーバ" 型名="model A"/>という記述により、商談ＸＭＬ文書４２のサーバID="hw1"を参照して、設計フェーズにおいてサーバID="svr1"のサーバが設定されたことが分かる。これにより、設計フェーズ以降でなんらかの問題が発生し、結局商談フェーズにまで波及するような場合でも、見積もりしたどの情報に関係するのか容易に辿ることができる。

設計ＸＭＬ文書４４は構築フェーズに渡される。そして、システム構築管理部３２１において、実際のシステム構築が行われる。この時、装置が足りないという問題が発覚した場合には、システム構築担当者は、どの部位に不足が生じているのかを突き止める。

例えば、サーバ５７，５８の処理能力が不足していれば、サーバ５７，５８と並列で動作するサーバを追加する必要がある。設計ＸＭＬ文書４４の『システム詳細テンプレート』タグ内の記載を参照すると、サーバ５７，５８のＩＤ「svr4」，「svr5」は、「hw2」を参照している。

そこで、設計ＸＭＬ文書４４の『サービス構成』タグ内（図１８では省略されており、図１６と同様の内容が記述されている）を参照すると、サーバＩＤが「hw2」のハードウェアが見つかる。そのハードウェアは、「タイプ="UNIXサーバ" 台数="2"」である。すると、商談において、アプリケーションサーバの構成をUNIXサーバ２台としていたことに誤りがあることが分かる。

システム構築担当者は、システム構築管理部３２１を利用して、商談管理部１２１に対して、アプリケーションサーバを構成するUNIXサーバが、２台では不十分であることを示す障害情報を伝える。すると、商談担当者が、商談管理部１２１を用いて見積もりからやり直す。

構築フェーズにおいて設計ＸＭＬ文書４４で示される設計データに問題が見つからなければ、構築担当者により、その設計データに基づいてシステムの構築・設定が行われる。そして、構築担当者は、システム構築管理部３２１を用いて、実際に組みあがったシステムの実システムデータ４５を作成する。

図１９は、実システムデータの例を示す図である。実システムデータ４５では、設計フェーズまでで扱っていた装置情報に加えて、どのような部品で構成されているのか、ソフトウェアの設定をどう変更したのか、といった実システムに関するより詳細な情報が設定されている。なお、図１９には示していないが、各構成品が設計ＸＭＬ文書４４内のどの代表データを参照して設定されたのかを示す情報が、実システムデータ４５に含まれている。例えば、「サーバpsvr1」がサーバID="svr1"を参照して設定されたことが、実システムデータ４５に含まれている。

ここで、各装置の型番から構成部品が自明の場合には後続フェーズに構成部品情報まで送る必要はない。そのため、スキーマ３０には、各装置の型番から構成部品が、後続フェーズへ引き継ぐべきデータとして設定されていない。そのような場合には、代表データ抽出部３２４は、構成部品情報を除くデータを代表データとする。そして、関係情報生成部３２５により、設計ＸＭＬ文書４４内のデータと構築フェーズの代表データとの関係情報が生成され、データ合成・送信部３２６により、構築ＸＭＬ文書４６が生成される。

図２０は、構築ＸＭＬ文書の例を示す第１の図である。図２１は、構築ＸＭＬ文書の例を示す第２の図である。図２０に構築ＸＭＬ文書４６の前半が示されており、図２１に構築ＸＭＬ文書４６の後半が示されている。なお、図２０、図２１は新たに追加された情報のみを示しており、省略された部分には、図１８に示す設計ＸＭＬ文書４４の内容が含まれる。

図２０に示すように、構築ＸＭＬ文書４６では、設計ＸＭＬ文書４４に『実システム情報』タグ以下が追加されている。『実システム情報』タグ以下では、システムを構成する実際のハードウェアやソフトウェアの情報と、提供サービスがこれらのハードウェアやソフトウェアをどのように組み合わせているのかという情報が入っている。

また、実際のハードウェアやソフトウェア、そして稼動サービスが設計情報のどれに相当するのかという関係を示す『参照』属性が各々に付与されている。例えば図２１に示すように、<実サーバID="psvr1" 参照="svr1" タイプ="Windowsサーバ" 型名="model A"/>という記述により、設計フェーズのサーバＩＤ"svr1"を参照して、構築フェーズの実サーバID="psvr1"が設定されたことが分かる。

このように、設計情報と実システム情報とを分離して各々保持することにより、設計図通りに構築されたかどうかを検証するのが容易になる。また、なんらかの障害によりサービスを再構築する場合やもしくは同一サービスを複数稼動させる場合に、同じ設計情報を再利用することができる。

最終の運用フェーズでは、運用管理部４２１が、構築フェーズで生成された構築ＸＭＬ文書４６を受け取って、システムの運用および監視を行う。運用中に特に問題がなければ、そのままシステム運用が続行される。システム状態を監視した結果、もし何らかの不具合が発生した場合には、運用フェーズ内で解消できるならば不具合を解消して運用が再開される。運用フェーズで解消できない不具合の場合には、運用担当者は、適切なフェーズが構築ＸＭＬ文書４６に基づいて判断する。そして、運用担当者は、運用管理部４２１を用いて、不具合の原因となったフェーズの管理部に対して、問題の解決を依頼する。

以上のようにして、一連のリソース管理をシームレスに連係することが可能となる。なお、第１の実施の形態では上流フェーズから送られてきたＸＭＬ文書にさらに情報を追加する形で下流のフェーズへ送るＸＭＬ文書を作成している。この際、当該フェーズより後のフェーズでは上流フェーズの情報の一部を不要としていることが明らかである場合は、それら不要情報を削除して送ってもよい。

［第２の実施の形態］
次に第２の実施の形態について説明する。第２の実施の形態は、階層化されたリソース管理システムによって構築フェーズ直後の運用フェーズを管理する場合に、運用フェーズ内でさらに階層的なデータ連係を行うものである。すなわち、第１の実施の形態では、各フェーズの管理システムが１つずつ直列に決められている場合を示したが、同一フェーズが複数の管理システムによって階層的に管理される場合もある。

図２２は、第２の実施の形態のシステム構成を示す図である。図２２は、図３に示した運用フェーズ管理システムを具体化したものである。図２２には示されていないが、商談フェーズ管理システム、設計フェーズ管理システム、構築フェーズ管理システムもネットワークで接続されているものとする。

この運用フェーズでは、運用フェーズ管理システム７１、サーバ管理システム７２、ストレージ管理システム７３、ネットワーク管理システム７４、およびスキーマ管理システム７５が連係して動作し、ネットワーク７０を介して接続されたサーバ機器８１〜８３、ストレージ機器８４〜８６、およびネットワーク機器８７〜８９の動作が管理される。

サーバ管理システム７２は、ストレージ機器７２ａとサーバ機器７２ｂとによって、サーバ機器８１〜８３を管理する。ストレージ管理システム７３は、ストレージ機器７３ａとサーバ機器７３ｂとによって、ストレージ機器８４〜８６を管理する。ネットワーク管理システム７４は、ストレージ機器７４ａとサーバ機器７４ｂとによって、ネットワーク機器８７〜８９を管理する。運用フェーズ管理システム７１は、ストレージ機器７１ａとサーバ機器７１ｂとによって、サーバ管理システム７２、ストレージ管理システム７３、およびネットワーク管理システム７４で管理されている情報を収集し、システム全体を管理する。スキーマ管理システム７５は、ストレージ機器７５ａとサーバ機器７５ｂとによって、他の管理システムに提供するスキーマを管理する。

なお、各管理システム内のサーバ機器７１ｂ，７２ｂ，７３ｂ，７４ｂ，７５ｂは、一般的なコンピュータシステムである。各サーバ機器７１ｂ，７２ｂ，７３ｂ，７４ｂ，７５ｂは、所定の管理機能を有している。具体的には、運用フェーズ管理システム７１のサーバ機器７１ｂは運用管理部７１ｃを有している。サーバ管理システム７２のサーバ機器７２ｂはサーバ管理部７２ｃを有している。ストレージ管理システム７３のサーバ機器７３ｂはストレージ管理部７３ｃを有している。ネットワーク管理システム７４のサーバ機器７４ｂはネットワーク管理部７４ｃを有している。スキーマ管理システム７５のサーバ機器７５ｂはスキーマ管理部７５ｃを有している。

また、各管理システムは、図５に示すデータ管理部１２２、データ受信部１２３、代表データ抽出部１２４、関係情報生成部１２５、およびデータ合成・送信部１２６と同様の機能を有する。

管理対象のサーバ機器８１〜８３では、動作状態を示す情報をサーバ管理システム７２に送信するためのエージェント８１ａ，８２ａ，８３ａが稼働している。管理対象のストレージ機器８４〜８６では、動作状態を示す情報をストレージ管理システム７３に送信するためのエージェント８４ａ，８５ａ，８６ａが稼働している。管理対象のネットワーク機器８７〜８９では、動作状態を示す情報をネットワーク管理システム７４に送信するためのエージェント８７ａ，８８ａ，８９ａが稼働している。

図２３は、第２の実施の形態の機能を示すブロック図である。なお、図２３では、下位構造の管理システムのうち、代表としてサーバ管理システム７２の構成のみを示している。他のストレージ管理システム７３とネットワーク管理システム７４も、内部構成はサーバ管理システム７２と同じである。

図２３に示すように、運用フェーズ管理システム７１は、運用管理部７１ｃ、運用ＤＢ７１ｄ、データ受信部７１ｅ、データ管理部７１ｆ、代表データ抽出部７１ｇ、関係情報生成部７１ｈ、データ合成・送信部７１ｉを有している。これらの各要素の機能は、運用管理部７１ｃとデータ受信部７１ｅとを除き、図５に示した運用フェーズ管理システム４００内の同名の要素と同じ機能を有している。

運用管理部７１ｃは、図５に示した運用フェーズ管理システム４００内の運用管理部４２１と同じ機能を有していると共に、階層構造の下位の管理システムから取得した情報に基づいて、システムの運用管理を行う機能を備えている。また、データ受信部７１ｅは、図５に示した運用フェーズ管理システム４００内のデータ受信部４２３と同じ機能を有していると共に、下位構造の管理システムから各種情報を受信し、データ管理部７１ｆを介して運用管理部７１ｃに渡す機能を有している。

サーバ管理システム７２は、サーバ管理部７２ｃ、サーバＤＢ７２ｄ、データ受信部７２ｅ、データ管理部７２ｆ、代表データ抽出部７２ｇ、関係情報生成部７２ｈ、データ合成・送信部７２ｉを有している。これらの各要素の機能は、サーバ管理部７２ｃ、データ受信部７２ｅおよびデータ合成・送信部７２ｉを除き、運用フェーズ管理システム７１内の同名の要素と同じ機能を有している。

サーバ管理部７２ｃは、管理対象のサーバ機器８１〜８３から運用状況に関する各種情報に基づいて、サーバの運用状態を管理する機能を備えている。データ受信部７２ｅは、管理対象のサーバ機器８１〜８３から運用状況に関する各種情報を受信する。データ合成・送信部７２ｉは、運用フェーズ管理システム７１のデータ合成・送信部７１ｉと同様の機能を備えている。ただし、データ合成・送信部７２ｉが交換データであるＸＭＬ文書を送信する相手は、階層の上位に位置する運用フェーズ管理システム７１である。

このような構成により、下位階層の管理システム（サーバ管理システム７２、ストレージ管理システム７３、およびネットワーク管理システム７４）は、各々が管理する管理対象装置ごとからＸＭＬ文書形式で情報を受け取る。下位階層の各管理システムは複数台の管理対象装置を束ねているので、各々複数台の管理対象装置から情報を受信する。よって、各独自ＤＢにはそれら複数台分の管理対象装置情報が格納される。

サーバ管理システム７２、ストレージ管理システム７３、およびネットワーク管理システム７４は、収集した情報の中から上位の運用フェーズ管理システム７１が必要とする情報を抽出し、そして管理対象装置同士間の関係を生成して、運用フェーズ管理システム７１に情報を合成したＸＭＬ文書を送信する。

運用フェーズ管理システム７１の次フェーズがある場合、運用フェーズ管理システム７１は、下位管理システムおよび前フェーズの管理システムからＸＭＬ文書を受け取り、それらの代表データおよび関係情報を生成して、次フェーズへと送る。

なお、図２２、図２３では下位管理システムとして３つの管理システムが設けられているが、１つ以上いくつでも存在することができる。また、３階層以上の階層構造を構成することもできる。

次に、管理対象の各機器から、対応する管理システムに送られる情報について説明する。
図２４は、サーバ機器管理情報の例を示す図である。このサーバ機器管理情報９１は、管理対象のサーバ機器８１〜８３からサーバ管理システム７２に送られる。サーバ機器管理情報９１には、サーバ機器のＩＤ、型名、シリアル番号、ＩＰアドレス、部品構成などの情報が含まれている。

図２５は、ストレージ機器管理情報の例を示す図である。このストレージ機器管理情報９２は、管理対象のストレージ機器８４〜８６からストレージ管理システム７３に送られる。ストレージ機器管理情報９２には、ストレージ機器のＩＤ、型名、シリアル番号、ＩＰアドレス、構成部品などの情報が含まれている。

図２６は、ネットワーク機器管理情報の例を示す図である。このネットワーク機器管理情報９３は、管理対象のネットワーク機器８７〜８９からネットワーク管理システム７４に送られる。ネットワーク機器管理情報９３には、ネットワーク機器のＩＤ、型名、シリアル番号、ＩＰアドレス、構成部品などの情報が含まれている。

サーバ管理システム７２、ストレージ管理システム７３およびネットワーク管理システム７４は、それぞれの管理対象装置から上がってきた管理情報を独自ＤＢに保存する。その際、サーバ管理システム７２、ストレージ管理システム７３およびネットワーク管理システム７４は、上位の運用フェーズ管理システム７１の運用管理部７１ｃに対して、通常のシステム管理に必要最小限の情報（代表データ）のみを伝達する。

具体的には、サーバ管理システム７２から運用フェーズ管理システム７１へは、代表データが含まれたサーバ管理ＸＭＬ文書が送信される。ストレージ管理システム７３から運用フェーズ管理システム７１へは、代表データが含まれたストレージ管理ＸＭＬ文書が送信される。ネットワーク管理システム７４から運用フェーズ管理システム７１へは、代表データが含まれたネットワーク管理ＸＭＬ文書が送信される。

図２７は、サーバ管理ＸＭＬ文書の例を示す図である。図２８は、ストレージ管理ＸＭＬ文書の例を示す図である。図２９は、ネットワーク管理ＸＭＬ文書の例を示す図である。システムから伝達される。

運用フェーズ管理システム７１の運用管理部７１ｃは、図２７〜図２９に示した情報に加え、１つ前の構築フェーズから送られてきた情報をもとにシステム全体を運用する。また、次のフェーズに対しては、さらに不要な情報を削除したリソース管理ＸＭＬ文書を送る。

図３０〜図３２にリソース管理ＸＭＬ文書の例を示す。図３０は、リソース管理ＸＭＬ文書の例を示す第１の図である。図３１は、リソース管理ＸＭＬ文書の例を示す第２の図である。図３２は、リソース管理ＸＭＬ文書の例を示す第３の図である。図３０、図３１、図３２に示した情報が記載されたリソース管理ＸＭＬ文書９７が運用フェーズ管理システム７１から、後続のフェーズ（例えば、遠隔地においてシステム管理を行う遠隔監視システム）に対して送信される。

以下、障害発生時に各フェーズの管理システムが連係する仕組みについて説明する。以下の例では、『検索サービス』を提供するために、ＩＴシステムが図３０〜図３２のＸＭＬ文書に示すとおりに構築され、そして運用されていたものとする。しかし、実際には検索リクエストを毎分８００トランザクションしか処理できていなかった状況を想定する。その場合、運用フェーズから設計フェーズに、問題の内容がフェードバックされる。

図３３は、運用フェーズからのフィードバックの対処フローを示す図である。以下、図３３に示す処理をステップ番号に沿って説明する。なお、設計フェーズの処理については、図５に示す設計フェーズ管理システム２００が行うものとして、図５に示した符号を付して説明する。

前提条件として、運用フェーズの運用フェーズ管理システム７１は、構築フェーズから受け取った構築ＸＭＬ文書の情報から、『検索サービス』のサービス要件として、毎分１，０００トランザクション処理できるだけの性能を維持する必要があることを知っているものとする。

［ステップＳ５１］運用時には、運用フェーズ管理システム７１は、サーバ管理システム７２、ストレージ管理システム７３、およびネットワーク管理システム７４と連係して、常にサービス運用状況を監視する。

［ステップＳ５２］運用フェーズ管理システム７１は、運用監視中に障害が検出されたか否かを常に判断する。障害が検出されなければ、システムの運用監視を継続する。
［ステップＳ５３］運用フェーズ管理システム７１は、監視情報に基づいてサービス要件が満たされていないことを検出すると、関係する部位の詳細な情報を取得しようとする。ここでいう「関係する部位」とは、検索サービスを提供するために利用されるＩＴシステム全体を指す。

具体的には、サーバ管理システム７２が、利用ＩＴシステムに含まれる各サーバ機器８１〜８３の負荷状況を調べ、運用フェーズ管理システム７１に負荷状況を示す情報を送る。また、ストレージ管理システム７３が、利用ＩＴシステムに含まれる各ストレージ機器８４〜８６の負荷状況を調べ、運用フェーズ管理システム７１に負荷状況を示す情報を送る。同様に、ネットワーク管理システム７４が、利用ＩＴシステムに含まれる各ネットワーク機器８７〜８９の負荷状況を調べ、運用フェーズ管理システム７１に負荷状況を示す情報を送る。

そして、運用フェーズ管理システム７１（もしくは管理システムが提供する監視ビューから情報を得て人手）により、根本原因が分析される。以降では、管理システム自身が分析を行うものとして説明する。

ここで、運用フェーズで対応可能なケースと、設計フェーズで対応すべきケースとについて、その後の処理方法を説明する。
・第１のケース
本障害はシステム構築時の設定ミスが原因だったとする。その場合、運用管理担当者が、過去の変更内容を検証することで、設定ミスの原因を判断できる。その結果、「psvr1」に対して他のWebサーバ「psvr2」、「psvr3」よりも多くリクエストが割り当てられ、この部分での処理がボトルネックとなっていたとする。これは、ハードウェアまたはソフトウェアに障害が生じたか、設定が誤っていることが原因でサーバの負荷に偏りが生じているものと判断できる。

さらに、運用管理担当者が、ハードウェアまたはソフトウェアのステータス異常や詳細パラメータ・エラーを調べることにより、ハードウェアまたはソフトウェアに障害が発生しているのか、もしくは設定が誤っていたのかを機械的に特定することができる。その結果、運用管理担当者は、管理システム自身により設計ミスと判断し、そしてシミュレーションなどにより設定を正すことで予定通りにサービスを提供することが可能であると検証できる。

・第２のケース
各部位に均等に負荷が分散されているが、「psvr1」、「psvr2」、「psvr3」はいずれも高負荷であるという状況の場合には、これらサーバの絶対処理能力が不足していると考えられる。システムは全体の性能・負荷情報の相関や履歴情報を利用して慎重に判断しなければいけないが、処理能力不足であると管理システムが自律的に断定することは可能である。本ケースの場合には、システム設計フェーズから見直す必要がある。

［ステップＳ５４］分析の結果、運用フェーズで対応可能な場合（第１のケース）、処理がステップＳ５５に進められる。先行する他のフェーズでの対応が必要な場合（第２のケース）、該当フェーズに対して、障害の内容・箇所情報を示す障害情報２０１が通知される。

［ステップＳ５５］第１のケースのような検証結果が得られた場合には、運用管理担当者が、運用管理部７１ｃの機能を用いて、設定内容の検証を行う。
［ステップＳ５６］さらに、運用管理担当者は、運用管理部７１ｃの機能を用いてシステム設定を変更し、ステップＳ５１に処理を進めサービスを再開する。

［ステップＳ５７］分析の結果、設計フェーで対応すべきと判断された場合（第２のケース）、運用フェーズ管理システム７１は、構築フェーズから送られてきたＸＭＬ文書を参照して、これら３台のサーバが設計情報のどの要素に対応するのかを特定する。その結果、設計情報のサーバ「svr1」、「svr2」、「svr3」に問題があるとわかる。そこで、運用フェーズの運用管理部７１ｃから設計フェーズのシステム設計管理部２２１に対して、『サービス要件”req2”を満たしていない。現状800トランザクション/分であり、これはWebサーバ「svr1」、「svr2」、「svr3」の処理能力が限界に達したことが原因である』という内容のインシデント報告（障害情報２０１の通知）を行う。

この内容で指定される「req2」、「svr1」、「svr2」、「svr3」というＩＤは設計フェーズにおいて設定したものである。したがって設計フェーズのシステム設計管理部２２１を用いて、システム設計担当者は、どの部位に問題があったのか容易に把握できる。設計フェーズでは、システム設計担当者が、この報告を受けて、要件を満たす、より高性能なサーバを用いるように再設計する。

［ステップＳ５８］設計フェーズでは、ステップＳ５９とステップＳ６０との処理を並列で進められる。
［ステップＳ５９］データ管理部２２２が再設計された設計データ２０２を代表データ抽出部２２４に渡す。すると、代表データ抽出部２２４が、スキーマ管理システム７５に設定されているスキーマを参照して、代表データを抽出する。

［ステップＳ６０］データ管理部２２２は、設計ＤＢ２１１から商談ＸＭＬ文書を取得し、商談ＸＭＬ文書２３０を関係情報生成部２２５に渡す。
［ステップＳ６１］関係情報生成部２２５は、商談ＸＭＬ文書と代表データとの利用関係を示す関係情報を生成する。

［ステップＳ６２］データ合成・送信部２２６は、商談ＸＭＬ文書２３０に関係情報と代表データとを追加して修正済設計ＸＭＬ文書２０４を生成する。そして、データ合成・送信部２２６は、修正済設計ＸＭＬ文書２０４を次の構築フェーズへ渡す。

以後、構築フェーズでは、Webサーバが新しいサーバに置き換えられ、そして最終的に運用フェーズにおいてサービスが再開される。なお、設計フェーズにおいて再設計したシステムをＸＭＬ文書化した情報は、文書全体ではなく、障害発生前のＸＭＬ文書との差分情報として送ってもよい。

以上のように、第１のおよび第２の実施の形態によれば、後続フェーズもしくは同一フェーズ上位のリソース管理システムで必要な情報のみを過不足なく送ることでデータ量を削減し、内部処理、および通信処理を軽減できる。さらに、前フェーズのデータとの関係情報も抽出した代表データとの間でのみ生成することで、交換データ量をより一層圧縮できる。

また、データ形式としてＸＭＬ文書を採用したことにより、スキーマによる文書妥当性の検証が容易に行える。ＸＭＬ文書は人間・マシン双方にとって扱い易いので、管理システムの各部位が人手による手作業であってもシステムによる自動処理であっても効率よく連係できる。

さらに、各フェーズで追加されるＸＭＬ情報間の関係情報を保持することで、通常は必要としないが故障発生などの緊急時にＸＭＬ文書に含まれない詳細情報が必要となった場合でも、ＸＭＬ文書中のキー情報を指定して詳細情報を保持する管理システムに問い合わせることができる。また、同様に、キー情報とさらに付加情報をフィードバックすることで、上流フェーズからのやり直しも円滑に行える。

以上のようにライフサイクルのフェーズ間およびフェーズ内の複数リソース管理システム間をシームレスにデータ連係できるようにすることで、ＩＴシステム管理が効率化され、サービス構築／提供までの期間が短縮でき、また問題が発生した場合でも即座に対応できる。つまり、管理コストの低減や安定したサービスの提供が実現される。また、データ内容や管理手法を統一することにより送受信するデータ検証などの処理が簡単になるので、従来は人手で行っていたリソース管理の自動化や、システム自身の判断に基づく自律化の実現が容易となる。

以上のように、上流フェーズから送られてきたＸＭＬ文書の情報をベースとして各管理システムをつなぐフィードバック機構を利用して情報をやり取りすることにより、障害に対してシステム自身で対応することが可能となる。ただし、実運用においては、構成変更や他フェーズへの情報通知の前に、管理者に対して承認を得る処理が入ってもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、業務管理装置、各種フェーズ管理システムおよびスキーマ管理システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

符号の説明

１ スキーマ記憶手段
１ａ，１ｂ，１ｃ，１ｄ スキーマ
２，３ 業務管理装置
２ａ，３ａ フェーズ別業務管理手段
２ｂ，３ｂ データ受信手段
２ｃ，３ｃ データ管理手段
２ｄ，３ｄ データ記憶手段
２ｅ，３ｅ 代表データ抽出手段
２ｆ，３ｆ 関係情報生成手段
２ｇ，３ｇ データ合成手段
４，５，６ 交換データ

Claims (7)

1. 遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理プログラムにおいて、
   コンピュータを、
   前記複数のフェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき決定事項を示す代表データのデータ項目を含むスキーマを記憶するスキーマ記憶手段、
   担当フェーズが割り当てられ、前段のフェーズそれぞれにおける決定事項と、該決定事項の生成に際して利用された他のデータとの利用関係を示す関係情報とを含む交換データを取得し、ユーザからの操作入力に応答して、取得した前記交換データに含まれる決定事項を利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して利用された決定事項を示すフェーズデータを生成するフェーズ別業務管理手段、
   前記フェーズ別業務管理手段で前記フェーズデータが生成されると、前記スキーマを参照し、前記スキーマで指定されている代表データのデータ項目に合致する決定事項を、代表データとして前記フェーズデータから抽出する代表データ抽出手段、
   前記フェーズ別業務管理手段で生成されたフェーズデータを参照し、前記代表データ抽出手段が抽出した代表データと、該代表データの生成に際して利用された前記交換データに含まれる決定事項との利用関係を示す関係情報を生成する関係情報生成手段、
   前記フェーズ別業務管理手段が取得した前記交換データに、前記代表データ抽出手段が抽出した代表データと、前記関係情報生成手段が生成した前記関係情報とを合成して前記交換データを更新し、更新された前記交換データを送信するデータ合成手段、
   として機能させることを特徴とする業務管理プログラム。
2. 前記スキーマ記憶手段が管理する前記スキーマには、後続のフェーズにデータを送る際のデータ構造が規定されており、
   前記データ合成手段は、前記フェーズ別業務管理手段の担当フェーズに対応する前記スキーマを参照し、前記スキーマに定義されているデータ構造に従ったデータ構造の前記交換データを作成することを特徴とする請求項１記載の業務管理プログラム。
3. 前記コンピュータを、さらに、
   前段のフェーズに対応する他のコンピュータから送信される前記交換データを受信するデータ受信手段として機能させ、
   前記データ合成手段は、更新された前記交換データを次のフェーズに対応する他のコンピュータに送信する、
   ことを特徴とする請求項１または２のいずれかに記載の業務管理プログラム。
4. 前記フェーズ別業務管理手段は、フェーズの遂行順が１フェーズずつ直列に決められている業務の直前のフェーズの前記交換データを取得することを特徴とする請求項１乃至３のいずれかに記載の業務管理プログラム。
5. 前記フェーズ別業務管理手段は、階層構造の下位の構造から順に遂行することが決められている業務の直下の構造に相当するフェーズの前記交換データを取得することを特徴とする請求項１乃至４のいずれかに記載の業務管理プログラム。
6. 遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理装置において、
   前記複数のフェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき決定事項を示す代表データのデータ項目を含むスキーマを記憶するスキーマ記憶手段と、
   担当フェーズが割り当てられ、前段のフェーズそれぞれにおける決定事項と、該決定事項の生成に際して利用された他のデータとの利用関係を示す関係情報とを含む交換データを取得し、ユーザからの操作入力に応答して、取得した前記交換データに含まれる決定事項を利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して利用された決定事項を示すフェーズデータを生成するフェーズ別業務管理手段と、
   前記フェーズ別業務管理手段で前記フェーズデータが生成されると、前記スキーマを参照し、前記スキーマで指定されている代表データのデータ項目に合致する決定事項を、代表データとして前記フェーズデータから抽出する代表データ抽出手段と、
   前記フェーズ別業務管理手段で生成されたフェーズデータを参照し、前記代表データ抽出手段が抽出した代表データと、該代表データの生成に際して利用された前記交換データに含まれる決定事項との利用関係を示す関係情報を生成する関係情報生成手段と、
   前記フェーズ別業務管理手段が取得した前記交換データに、前記代表データ抽出手段が抽出した代表データと、前記関係情報生成手段が生成した前記関係情報とを合成して前記交換データを更新し、更新された前記交換データを送信するデータ合成手段と、
   を有することを特徴とする業務管理装置。
7. 遂行順があらかじめ決まっている複数のフェーズで構成される業務を管理するための業務管理方法において、
   コンピュータが、
   担当フェーズが割り当てられ、前段のフェーズそれぞれにおける決定事項と、該決定事項の生成に際して利用された他のデータとの利用関係を示す関係情報とを含む交換データを取得し、ユーザからの操作入力に応答して、取得した前記交換データに含まれる決定事項を利用して担当フェーズ内の業務を実行し、担当フェーズ内での決定事項および決定に際して利用された決定事項を示すフェーズデータを生成し、
   前記フェーズデータが生成されると、前記複数のフェーズそれぞれにおける決定事項のうち後続のフェーズに通知すべき決定事項を示す代表データのデータ項目を含むスキーマを記憶するスキーマ記憶手段を参照し、該スキーマで指定されている代表データのデータ項目に合致する決定事項を、代表データとして前記フェーズデータから抽出し、
   生成されたフェーズデータを参照し、抽出した代表データと、該代表データの生成に際して利用された前記交換データに含まれる決定事項との利用関係を示す関係情報を生成し、
   取得した前記交換データに、抽出した代表データと、生成した前記関係情報とを合成して前記交換データを更新し、更新された前記交換データを送信する、
   ことを特徴とする業務管理方法。

Images