(57)【要約】【課題】ＩＴサービスの構成を解析する際に参照される参照値である制約条件の定義漏れを防止する。【解決手段】制約条件項目生成部２０１４が、サービス提供形態情報２０２２１の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態に対して、制約条件の設定対象となる設定対象構成アイテムをサービス提供形態情報２０２２１から抽出し、抽出した設定対象構成アイテムと組になっている構成アイテムを構成管理モデル情報２０２２２から抽出する。そして、画面表示部２０１１が、ＩＴサービスの種類ごとに、制約条件項目生成部２０１４により抽出された構成アイテムの組が制約条件を設定する構成アイテムの組であることを、構成管理担当者に提示する。【選択図】図１
2014228874.tif 000002
【特許請求の範囲】
【請求項１】
ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）サービスの構成の雛型である構成管理モデルに従ってＩＴサービスの構成が定義されている構成管理情報を用いてＩＴサービスの構成を解析する際に参照される参照値を構成管理モデルに含まれる構成アイテムの組の単位で設定する参照値設定処理が行われる構成管理装置であって、
ＩＴサービスの提供形態であるサービス提供形態ごとに、対応する構成管理モデルが、ＩＴサービスの構成要素の類型である複数の構成アイテムの組により定義される構成管理モデル情報を記憶する構成管理モデル情報記憶部と、
ＩＴサービスの種類ごとに、対応するサービス提供形態が定義され、サービス提供形態ごとに、対応する構成管理モデル情報に含まれている構成アイテムのうち、参照値の設定の対象となる構成アイテムが設定対象構成アイテムとして定義されるサービス提供形態情報を記憶するサービス提供形態情報記憶部と、
前記参照値設定処理が行われる際に、前記サービス提供形態情報の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態の設定対象構成アイテムを前記サービス提供形態情報から抽出し、抽出した設定対象構成アイテムと組になっている構成アイテムを前記構成管理モデル情報から関係構成アイテムとして抽出する構成アイテム抽出部と、
ＩＴサービスの種類ごとに、前記構成アイテム抽出部により抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記構成管理装置の利用者に提示する設定対象組提示部とを有することを特徴とする構成管理装置。
【請求項２】
前記サービス提供形態情報記憶部は、
サービス提供形態ごとに、複数の設定対象構成アイテムが定義されているサービス提供形態情報を記憶し、
前記構成アイテム抽出部は、
抽出した関係構成アイテムが、前記サービス提供形態情報で定義されている、抽出した設定対象構成アイテム以外の他の設定対象構成アイテムのいずれかに該当するか否かを判断し、
前記設定対象組提示部は、
前記構成アイテム抽出部により、関係構成アイテムが他の設定対象構成アイテムのいずれかに該当すると判断された場合に、
前記構成アイテム抽出部により抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記構成管理装置の利用者に提示することを特徴とする請求項１に記載の構成管理装置。
【請求項３】
前記サービス提供形態情報記憶部は、
設定対象構成アイテムごとに、参照値の数が１つであるか複数であるかが定義されているサービス提供形態情報を記憶し、
前記構成アイテム抽出部は、
抽出した関係構成アイテムが、前記サービス提供形態情報で定義されている、抽出した設定対象構成アイテム以外の他の設定対象構成アイテムのいずれかに該当すると判断した場合に、
前記サービス提供形態情報に基づき、抽出した設定対象構成アイテムの参照値の数が１つであるか複数であるかを判断し、抽出した関係構成アイテムの参照値の数が１つであるか複数であるかを判断し、
前記設定対象組提示部は、
前記構成アイテム抽出部により、設定対象構成アイテムの参照値の数及び関係構成アイテムの参照値の数がともに１つであると判断された場合に、
前記構成アイテム抽出部により抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であり、設定対象構成アイテムと関係構成アイテムとの組に対して１つの参照値が設定されることを、前記構成管理装置の利用者に提示し、
前記構成アイテム抽出部により、設定対象構成アイテムの参照値の数及び関係構成アイテムの参照値の数の少なくともいずれかが複数であると判断された場合に、
前記構成アイテム抽出部により抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であり、設定対象構成アイテムと関係構成アイテムとの組に対して複数の参照値が設定されることを、前記構成管理装置の利用者に提示することを特徴とする請求項２に記載の構成管理装置。
【請求項４】
前記サービス提供形態情報記憶部は、
サービス提供形態ごとに、複数の設定対象構成アイテムが定義されているサービス提供形態情報を記憶し、
前記構成アイテム抽出部は、
前記参照値設定処理が行われる際に、前記サービス提供形態情報の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態の複数の設定対象構成アイテムを前記サービス提供形態情報から抽出し、抽出した複数の設定対象構成アイテムの各々に対して、関係構成アイテムを抽出し、
前記設定対象組提示部は、
ＩＴサービスの種類ごとに、前記構成アイテム抽出部により抽出された複数の設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記構成管理装置の利用者に提示することを特徴とする請求項１〜３のいずれかに記載の構成管理装置。
【請求項５】
前記構成管理装置は、更に、
前記参照値設定処理により参照値が設定された後に、解析対象のＩＴサービスの構成管理情報を用い、当該ＩＴサービスの種類に対応する参照値を参照して、当該ＩＴサービスの構成を解析する構成解析部を有することを特徴とする請求項１〜４のいずれかに記載の構成管理装置。
【請求項６】
前記構成アイテム抽出部は、
ＩＴサービスの種類ごとに、対応するサービス提供形態の構成管理モデル情報に前記設定対象構成アイテムに該当しない設定対象外構成アイテムが含まれているか否かを判断し、
対応するサービス提供形態の構成管理モデル情報に前記設定対象外構成アイテムが含まれているＩＴサービスの種類について、前記設定対象外構成アイテムと組になっている構成アイテムを前記構成管理モデル情報から関係構成アイテムとして抽出し、当該ＩＴサービスの種類に対応するＩＴサービスの構成管理情報を解析して、前記設定対象外構成アイテムと前記関係構成アイテムとの組に対する参照値を生成することを特徴とする請求項１〜５のいずれかに記載の構成管理装置。
【請求項７】
前記構成管理装置は、更に、
前記構成アイテム抽出部により参照値が生成されたＩＴサービスの種類に対応するＩＴサービスの構成管理情報を用い、前記構成アイテム抽出部により生成された参照値を参照して、当該ＩＴサービスの構成を解析する構成解析部を有することを特徴とする請求項６に記載の構成管理装置。
【請求項８】
ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）サービスの構成の雛型である構成管理モデルに従ってＩＴサービスの構成が定義されている構成管理情報を用いてＩＴサービスの構成を解析する際に参照される参照値を構成管理モデルに含まれる構成アイテムの組の単位で設定する参照値設定処理が行われるコンピュータによる構成管理方法であって、
ＩＴサービスの提供形態であるサービス提供形態ごとに、対応する構成管理モデルが、ＩＴサービスの構成要素の類型である複数の構成アイテムの組により定義される構成管理モデル情報を所定の記憶領域から前記コンピュータが読み出す構成管理モデル情報読み出しステップと、
ＩＴサービスの種類ごとに、対応するサービス提供形態が定義され、サービス提供形態ごとに、対応する構成管理モデル情報に含まれている構成アイテムのうち、参照値の設定の対象となる構成アイテムが設定対象構成アイテムとして定義されるサービス提供形態情報を所定の記憶領域から前記コンピュータが読み出すサービス提供形態情報読み出しステップと、
前記参照値設定処理が行われる際に、前記コンピュータが、前記サービス提供形態情報の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態の設定対象構成アイテムを前記サービス提供形態情報から抽出し、抽出した設定対象構成アイテムと組になっている構成アイテムを前記構成管理モデル情報から関係構成アイテムとして抽出する構成アイテム抽出ステップと、
前記コンピュータが、ＩＴサービスの種類ごとに、前記構成アイテム抽出ステップにより抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記コンピュータの利用者に提示する設定対象組提示ステップとを有することを特徴とする構成管理方法。
【請求項９】
ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）サービスの構成の雛型である構成管理モデルに従ってＩＴサービスの構成が定義されている構成管理情報を用いてＩＴサービスの構成を解析する際に参照される参照値を構成管理モデルに含まれる構成アイテムの組の単位で設定する参照値設定処理が行われるコンピュータに、
ＩＴサービスの提供形態であるサービス提供形態ごとに、対応する構成管理モデルが、ＩＴサービスの構成要素の類型である複数の構成アイテムの組により定義される構成管理モデル情報を所定の記憶領域から読み出す構成管理モデル情報読み出しステップと、
ＩＴサービスの種類ごとに、対応するサービス提供形態が定義され、サービス提供形態ごとに、対応する構成管理モデル情報に含まれている構成アイテムのうち、参照値の設定の対象となる構成アイテムが設定対象構成アイテムとして定義されるサービス提供形態情報を所定の記憶領域から読み出すサービス提供形態情報読み出しステップと、
前記参照値設定処理が行われる際に、前記サービス提供形態情報の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態の設定対象構成アイテムを前記サービス提供形態情報から抽出し、抽出した設定対象構成アイテムと組になっている構成アイテムを前記構成管理モデル情報から関係構成アイテムとして抽出する構成アイテム抽出ステップと、
ＩＴサービスの種類ごとに、前記構成アイテム抽出ステップにより抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記コンピュータの利用者に提示する設定対象組提示ステップとを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）サービスの構成管理に関する。
【背景技術】
【０００２】
ＩＴＩＬ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｌｉｂｒａｒｙ）は、ＩＴサービスマネジメントのベストプラクティスをまとめたフレームワークであり、ＩＴサービスを運用するにあたってのデファクトスタンダードとなっている。
ＩＴＩＬの構成管理プロセスでは、ＩＴサービスを構成する全ての要素が構成管理の対象であると説明している。
構成情報は、構成アイテム（ＣＩ：Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｉｔｅｍ）とＣＩ間の関係を表わす関係情報によって表現される。
ＣＩと関係情報によって表現された構成情報は、構成管理データベース（ＣＭＤＢ：Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｄａｔａｂａｓｅ）に格納され、管理される。
【０００３】
正確な構成情報の維持管理を行うことは、構成情報を参照するＩＴＩＬの他のプロセス（例えば、インシデント管理プロセス等）の効率化に寄与し、ＩＴサービスの品質向上に繋がる。
逆に、正確な構成情報の維持管理を行えなかった場合、誤った構成情報を元にＩＴサービスを提供することになるため、ＩＴサービスの品質は低下する。
例えば、ＣＭＤＢで管理していたネットワークの構成情報が誤っていた場合、障害発生時のインシデント管理プロセスにおいて、障害箇所の特定に余計な時間がかかってしまう恐れがある。
そのため、構成管理において、構成情報を正しく維持管理することは非常に重要である。
【０００４】
正確な構成管理を行う方法として、管理対象である実際のシステムから直接構成情報を収集してＣＭＤＢに格納するディスカバリという方法がある。
ディスカバリでは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）やＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、ＷＭＩ（Ｗｉｎｄｏｗｓ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）等を使用して、管理対象のシステムを構成する機器から直接情報を収集する。
一般的に、ＣＭＤＢ製品にはディスカバリ機能が付属しており、正確な構成情報の維持管理を容易に出来るように工夫されている。
しかし、ディスカバリの実行によって詳細な構成情報を収集するためには、機器の管理者権限のユーザＩＤ、パスワードが必要であるという制約がある。
自社システムの構成管理を行う情報システム部門等においては、この制約はそれほど問題にならないかもしれない。
しかし、自社システムだけでなく顧客システムの構成情報の管理を行うＩＴサービスプロバイダ等にとっては大きなハードルとなる。
多くの場合、顧客システムの管理者権限は入手することが出来ず、ディスカバリ機能を使用することが出来ない。
【０００５】
ディスカバリ機能を使用せずに構成管理を行う場合は、例えば、スプレッドシートに管理したい構成情報をＣＩと関係情報という形式で書き並べ、それをＣＭＤＢが提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）等を利用してＣＭＤＢへ登録する。
このような人手による構成情報の管理では、構成情報、特に関係情報の登録誤りや登録漏れが発生しやすくなる。
【０００６】
従来技術では、予め定義しておいた制約条件を元に、制約条件に該当しない関係情報の定義漏れ候補を抽出するという方法が提案されている（例えば、特許文献１）。
また、構成管理されている構成情報を元に、制約条件を自動生成する従来技術も提案されている（例えば、特許文献２）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−１３８４０６号公報
【特許文献２】特開２０１２−１９８６４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＩＴサービスプロバイダが構成管理を行う場合、従来技術をそのまま適用して複数のサービスに対して制約条件を一意に決定してしまうと、構成情報の誤り候補を抽出する精度が低下してしまうという課題があった。
理由としては２つある。
１つめの理由は、ＩＴサービスプロバイダでは、構成の特徴が異なるサービスを数多く提供していることである。
例えば、ホスティングサービスでは、ＩＴサービスプロバイダの拠点に、ＩＴサービスプロバイダが用意した機器を設置して、顧客に提供する。
そのため、ホスティングサービスを提供するための構成は、自由度の低い決まりきった構成となる特徴がある。
一方、ハウジングサービスでは、ＩＴサービスプロバイダの拠点に、顧客が用意した機器を持ち込んでシステムを構築する。
そのため、ハウジングサービスの構成は、顧客毎に構成が全く異なる自由度の高い構成となる特徴がある。
２つめの理由は、サービスの提供形態によって、ＩＴサービスを提供する自社システムの構成情報だけでなく、ＩＴサービスを利用する顧客システムの構成情報も管理しなければならないことである。
例えば、ＩＴサービスプロバイダがＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）型サービスを提供する場合、ＩＴサービスプロバイダは、ハードウェア、ノード、ソフトウェア等を全て設計し、これらの設計情報を構成情報の一部として管理する。
一方、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）型サービスを提供する場合、ＩＴサービスプロバイダは、ハードウェア、物理ノード（ホストＯＳ）までを提供し、サービスを利用する顧客が自由に仮想ノード（ゲストＯＳ）を作成したり、ソフトウェアをインストールしたりする。
ＩＴサービスプロバイダは、顧客が自由に作成した仮想ノード等の構成情報を管理する必要はない。
しかし、例えば、仮想ノードの運用監視を行う等の契約により、顧客の構成情報を自社の構成情報と合わせて管理する必要が出てくる場合も多々ある。
【０００９】
以上の理由により、ＩＴサービスプロバイダでは、異なる構成の特徴や顧客システムの情報が入り混じった構成情報を管理する必要があるため、複数のサービスに対して制約条件を一意に決定してしまうと、制約条件による構成情報の誤り候補の抽出精度が低下する。
【００１０】
以上の課題を考慮した方法として、サービス毎に制約条件を作成するという方法が考えられる。
この場合、各サービスの構成の特徴を考慮しながら制約条件を定義出来るようになるため、上記の課題は解決される。
しかし、構成の特徴を考慮しながら、全てのサービスに対する制約条件をひとつひとつ手動で定義する必要があり、制約条件の定義漏れが発生しやすくなる。
例えば、ＳａａＳ型サービスの場合、ＳａａＳ型サービスの担当者は提供しているソフトウェアに関係する構成情報は常に意識しているため制約条件を正しく定義することが出来る。
しかし、ソフトウェアがインストールされているノードやハードウェア等のソフトウェアよりも下位の構成については普段あまり意識しておらず、定義漏れが発生しやすくなる。
【００１１】
この発明は上記のような課題を解決することを主な目的としており、ＩＴサービスの構成を解析する際に参照される参照値である制約条件の定義漏れを防止することを主な目的とする。
【課題を解決するための手段】
【００１２】
本発明に係る構成管理装置は、
ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）サービスの構成の雛型である構成管理モデルに従ってＩＴサービスの構成が定義されている構成管理情報を用いてＩＴサービスの構成を解析する際に参照される参照値を構成管理モデルに含まれる構成アイテムの組の単位で設定する参照値設定処理が行われる構成管理装置であって、
ＩＴサービスの提供形態であるサービス提供形態ごとに、対応する構成管理モデルが、ＩＴサービスの構成要素の類型である複数の構成アイテムの組により定義される構成管理モデル情報を記憶する構成管理モデル情報記憶部と、
ＩＴサービスの種類ごとに、対応するサービス提供形態が定義され、サービス提供形態ごとに、対応する構成管理モデル情報に含まれている構成アイテムのうち、参照値の設定の対象となる構成アイテムが設定対象構成アイテムとして定義されるサービス提供形態情報を記憶するサービス提供形態情報記憶部と、
前記参照値設定処理が行われる際に、前記サービス提供形態情報の定義に基づき、ＩＴサービスの種類ごとに、対応するサービス提供形態を特定するとともに、特定したサービス提供形態の設定対象構成アイテムを前記サービス提供形態情報から抽出し、抽出した設定対象構成アイテムと組になっている構成アイテムを前記構成管理モデル情報から関係構成アイテムとして抽出する構成アイテム抽出部と、
ＩＴサービスの種類ごとに、前記構成アイテム抽出部により抽出された設定対象構成アイテムと関係構成アイテムとの組が参照値を設定する構成アイテムの組であることを、前記構成管理装置の利用者に提示する設定対象組提示部とを有することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ＩＴサービスの種類ごとに、参照値を設定する構成アイテムの組を利用者に提示することができるので、利用者は定義すべき参照値を把握することができ、参照値の定義漏れを防止することができる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係るサービス提供形態情報の例を示す図。
【図３】実施の形態１に係るサービス提供形態情報の例を示す図。
【図４】実施の形態１に係る構成管理モデルの例を示す図。
【図５】実施の形態１に係る構成管理モデル情報の例を示す図。
【図６】実施の形態１に係る制約条件情報の例を示す図。
【図７】実施の形態１に係る構成管理装置の新規サービス追加時の動作例を示す図。
【図８】実施の形態１に係る構成管理装置の制約条件入力時の動作例を示す図。
【図９】実施の形態１に係る構成管理装置の構成情報更新時の動作例を示す図。
【図１０】実施の形態１に係る制約条件項目生成部の動作例を示すフローチャート図。
【図１１】実施の形態１に係る制約条件項目生成部の動作例を示すフローチャート図。
【図１２】実施の形態１に係るＣＭＤＢへ登録または更新する構成情報を記入するスプレッドシートの例を示す図。
【図１３】実施の形態１に係るＣＭＤＢへ登録または更新する構成情報を記入するスプレッドシートの例を示す図。
【図１４】実施の形態１に係る制約条件確認部の動作例を示すフローチャート図。
【図１５】実施の形態１に係る制約条件確認部の動作例を示すフローチャート図。
【図１６】実施の形態１に係る制約条件確認部の動作例を示すフローチャート図。
【図１７】実施の形態１に係る顧客毎の制約条件生成手順を示すフローチャート図。
【図１８】実施の形態１に係る構成管理装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１５】
実施の形態１．
本実施の形態では、人手によって構成情報を管理する際に、構成情報の誤り候補を抽出するための制約条件を漏れなく定義することを可能にする構成管理装置を説明する。
より具体的には、本実施の形態では、サービス提供形態毎に制約条件を適用する構成情報の範囲を定義したサービス提供形態情報と、ＣＭＤＢで構成管理している構成管理モデルの情報を元に、構成管理装置がＩＴサービス毎に制約条件項目を自動生成する。
【００１６】
制約条件は、ＩＴサービスの構成を解析して構成情報の誤り候補を抽出する際に参照される参照値である。
また、制約条件項目は、制約条件を設定する構成アイテム（ＣＩ）の組である。
構成アイテム（ＣＩ）は、ＩＴサービスの構成要素の類型である。
例えば、あるＩＴサービスに、構成アイテムとして、「サービス」、「システム」、「ハードウェア」、「物理ノード」、「仮想ノード」、「ソフトウェア」が含まれている場合に、構成管理装置は、例えば、制約条件項目として、「ハードウェア」と「物理ノード」との組、「物理ノード」と「仮想ノード」の組、「仮想ノード」と「ソフトウェア」の組を抽出する。
【００１７】
このように、本実施の形態によれば、ＩＴサービス毎に定義すべき制約条件項目を漏れなく生成することが可能となる。
制約条件を設定する担当者は、構成管理装置により生成された制約条件項目に合わせて制約条件の値を設定すればよいため、制約条件を漏れなく定義することが可能となる。
前出の例では、担当者は、構成管理装置により提示された「ハードウェア」と「物理ノード」との組、「物理ノード」と「仮想ノード」の組、「仮想ノード」と「ソフトウェア」の組の各々に対して、制約条件を定義することができる。
サービス毎に制約条件を定義するため、全ての構成情報に対して一意に定義された制約条件と比較して、精度のよい制約条件を定義することが可能となる。
定義された制約条件を元に、構成情報の誤り候補を抽出、結果の提示をすることにより、正確な構成情報の維持管理が促進される。
つまり、ＩＴサービスの品質向上にも繋がる。
【００１８】
図１は、実施の形態１に係るシステム構成例を示す。
実施の形態１に係るシステムは、クライアント装置１０と、構成管理装置２０とから構成される。
【００１９】
クライアント装置１０は、構成管理を行う担当者（構成管理担当者）が使用する端末装置である。
構成管理担当者は、クライアント装置１０を使用して、構成管理装置２０を利用する。
【００２０】
構成管理装置２０は、構成情報の管理を行う構成管理システムである。
構成管理装置２０は、構成情報の記憶や、記憶している構成情報の参照、更新等の構成情報の管理を行うシステムである。
また、構成管理担当者が構成管理装置２０に対して、構成情報の更新を行った場合、制約条件を元にした構成情報の誤り候補の抽出と、その結果の表示も行う。
構成管理装置２０は、情報処理装置２０１と情報記憶装置２０２から構成される。
【００２１】
情報処理装置２０１は、クライアント装置１０からの入力に従い、構成情報の情報記憶装置２０２への格納、情報記憶装置２０２からの構成情報の取得、構成情報の誤り候補の抽出等の処理を行う。
また、情報処理装置２０１は、処理の結果をクライアント装置１０へ表示する。
情報処理装置２０１の構成の詳細は後述する。
【００２２】
情報記憶装置２０２は、クライアント装置１０から入力された構成情報や、構成情報の誤り候補の抽出に使用する制約条件等の情報を記憶する装置である。
情報記憶装置２０２は、ＣＭＤＢ２０２１、制約条件ＤＢ２０２２から構成される。
【００２３】
ＣＭＤＢ２０２１は、構成情報を格納する構成管理データベースである。
構成情報をＣＩとＣＩ間の関係を表わす関係情報によって表現し、管理を行う。
制約条件ＤＢ２０２２は、構成管理担当者が入力した構成情報に対して誤り候補を抽出するための制約条件を格納するデータベースである。
制約条件ＤＢ２０２２は、サービス提供形態情報２０２２１、構成管理モデル情報２０２２２、制約条件情報２０２２３から構成される。
これらの情報の詳細は後述する。
制約条件ＤＢ２０２２は、サービス提供形態情報記憶部及び構成管理モデル情報記憶部の例に相当する。
【００２４】
次に、情報処理装置２０１の構成について説明する。
情報処理装置２０１は、画面表示部２０１１、構成情報取得部２０１２、構成情報更新部２０１３、制約条件項目生成部２０１４、制約条件更新部２０１５、制約条件確認部２０１６から構成される。
【００２５】
画面表示部２０１１は、構成管理担当者が構成管理装置２０を利用する際に、クライアント装置１０へ表示する画面を生成する。
構成管理担当者はクライアント装置１０から、画面表示部２０１１が表示する画面を利用して、構成管理装置２０を使用する。
また、画面表示部２０１１は、制約条件項目生成部２０１４が生成した制約条件項目（制約条件を設定するＣＩの組）を表示する画面を生成し、構成管理担当者に制約条件項目を提示する。
画面表示部２０１１は、設定対象組提示部の例に相当する。
【００２６】
構成情報取得部２０１２は、指定された検索キーを元に、ＣＭＤＢ２０２１より構成情報を検索し、取得する。
ＣＭＤＢ製品が提供するＣＭＤＢから構成情報を取得するＡＰＩ等をこの機能として使用することも可能である。
【００２７】
構成情報更新部２０１３は、ＣＭＤＢ２０２１に格納された構成情報を、構成管理担当者が入力した構成情報によって更新する。
ＣＭＤＢ製品が提供するＣＭＤＢから構成情報を取得するＡＰＩ等をこの機能として使用することも可能である。
【００２８】
制約条件項目生成部２０１４は、サービス提供形態情報２０２２１、構成管理モデル情報２０２２２を読み出し、サービス提供形態情報２０２２１、構成管理モデル情報２０２２２を元に、ＩＴサービス毎の制約条件項目を生成し、制約条件情報２０２２３として保存する。
制約条件項目生成部２０１４は、構成アイテム抽出部の例に相当する。
【００２９】
制約条件更新部２０１５は、制約条件項目生成部２０１４により生成された制約条件項目に対して、構成管理担当者がクライアント装置１０を通して入力した制約条件の値を、制約条件情報２０２２３に格納する。
【００３０】
制約条件確認部２０１６は、制約条件項目生成部２０１４と制約条件更新部２０１５によって作成された制約条件情報２０２２３を元に、構成管理担当者が更新する構成情報に対して誤り候補を抽出する。
制約条件確認部２０１６は、構成解析部の例に相当する。
【００３１】
次に、サービス提供形態情報２０２２１、構成管理モデル情報２０２２２、制約条件情報２０２２３の詳細について説明する。
【００３２】
サービス提供形態情報２０２２１は、図２及び図３に示すデータ構造を持っている。
構成管理モデル情報２０２２２は、図４及び図５に示すデータ構造を持っている。
制約条件情報２０２２３は、図６に示すデータ構造を持っている。
図２〜図６において、「（ア）項目の説明」は、各データの項目名および各項目の内容を説明しており、「（イ）データの例」は、実際のデータの内容例を示している。
【００３３】
図２及び図３に示すように、サービス提供形態情報２０２２１は、ＩＴサービスプロバイダが提供するＩＴサービスのサービス名とその提供形態に関する情報である。
サービス提供形態情報は、「（１）サービス名とサービス提供形態の対応」（図２）、「（２）サービス提供形態毎の制約条件適用範囲」（図３）の２種類の情報から構成される。
【００３４】
図２に示す「（１）サービス名とサービス提供形態の対応」は、ＩＴサービスプロバイダが顧客に提供しているＩＴサービスの名称と、そのＩＴサービスの提供形態の対応を示した情報である。
（ア）に項目名を示す。
項目は、サービス名、サービス提供形態から構成される。
サービス名は、ＩＴサービスプロバイダが提供するＩＴサービスの名称、サービス提供形態はＩＴサービスプロバイダが提供するＩＴサービスの提供形態の名称である。
（イ）にデータ例を示す。
メールサービス（クラウド型）が、顧客にソフトウェアをサービスとして提供するサービスである場合、メールサービス（クラウド型）には、サービス提供形態としてＳａａＳ型サービスが定義される。
また、ホスティングサービスが顧客にサーバを提供するサービスである場合、ホスティングサービスには、サービス提供形態としてＩａａＳ型サービスが定義される。
データ例では、サービス提供形態として、ＳａａＳ型サービス、ＰａａＳ（Ｐｌａｔｆｏｒｍ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）型サービス、ＩａａＳ型サービス、ハウジングサービスのいずれかを定義しているが、これ以外の提供形態を定義してもよい。
例えば、「ＩａａＳ型サービス＋運用監視サービス」のようにサービスの提供形態を表わす名称を自由に付けてよい。
本実施の形態においては、サービス提供形態は、あくまで提供形態のパターン名として利用するため、サービスの提供形態に合わせた独自の名前で定義して問題ない。
【００３５】
図３に示す「（２）サービス提供形態毎の制約条件適用範囲」は、構成情報の更新時において、制約条件による誤り候補の抽出を行う範囲を、サービス提供形態毎に定義した情報である。
顧客が自由に構成を決定した範囲については、その構成情報をＩＴサービスプロバイダが管理していたとしても、制約条件による抽出の範囲外とし、ＩＴサービスプロバイダが設計した範囲に対してのみチェックを実施出来るようにするための定義である。
顧客範囲に対しても制約条件による誤り抽出を行いたい場合には、そのように範囲を設定してもよい。
（ア）に項目名を示す。
項目は、サービス提供形態、１つ以上のＣＩ型名から構成される。
サービス提供形態は、図２の（１）のサービス提供形態と同じである。
ＣＩ型名は、ＣＭＤＢ２０２１にて管理しているＣＩの型名であり、例えば、ノード、ハードウェア等である。
ここで項目名とするＣＩ型名は、制約条件による誤り候補抽出の対象としたいＣＩの型名であるため、ＣＩ型名は１つ以上、構成管理しているＣＩ型数以下となる。
例えば、誤り候補抽出の対象としたいＣＩ型名が１０個の場合、ＣＩ型名の項目数は１０となる。
（イ）にデータ例を示す。
ここでは、ＣＩ型名として、ハードウェア、物理ノード、仮想ノード、ソフトウェアの４つを誤り候補抽出の対象としている。
制約条件適用範囲は、「◎」、「○」、「×」の３パターンで表わしている。
「◎」はＩＴサービスプロバイダにて設計したＣＩであり、かつ、他ＣＩへの関係情報（関係情報の数）も一意に決まっているＣＩである。
「○」はＩＴサービスプロバイダが設計したＣＩであり、他ＣＩへの関係情報が一意に決まっていないが、関係情報の傾向が決まっているＣＩである。
「×」はサービスを利用する顧客が独自に設計を行ったＣＩであり、他ＣＩへの関係情報への傾向が全く決まっていないＣＩである。
「◎」及び「○」が記述されているＣＩは、制約条件項目の対象となるＣＩであり、設定対象構成アイテムの例に相当する。
【００３６】
例えば、ＳａａＳ型サービスにおいて、提供するソフトウェアの関係情報については一意に決まっているが、仮想ノード、物理ノード、ハードウェアは設計しているものの一意には決まっていない場合、（イ）のデータ例に示すように、ハードウェアは「○」、物理ノードは「○」、仮想ノードは「○」、ソフトウェアは「◎」となる。
ＰａａＳ型サービスにおいては、ハードウェア、物理ノードは一意に決まっているが、仮想ノードは一意には決まっておらず、ソフトウェアについては、サービスを利用する顧客が独自に設計していた場合、ハードウェアは「◎」、物理ノードは「◎」、仮想ノードは「○」、ソフトウェアは「×」となる。
ＩａａＳ型サービスにおいては、ハードウェアは一意に決まっているが、物理ノードは一意には決まっておらず、仮想ノードとソフトウェアについては、サービスを利用する顧客が独自に設計していた場合、ハードウェアは「◎」、物理ノードは「○」、仮想ノードは「×」、ソフトウェアは「×」となる。
なお、これらはあくまで例であり、全てのＳａａＳ型サービス、ＰａａＳ型サービス、ＩａａＳ型サービスがこのような適用範囲になるという意味ではない。
「◎」、「○」、「×」はこの３種類に限らず、適用範囲を判断出来る情報であれば他の書き方でもよい。
また、３パターン以上あってもよい。
【００３７】
図４は、ＣＭＤＢ２０２１で管理している構成情報の構成管理モデルの例である。
楕円がＣＩ型名、矢印が関係情報を表わしており、矢印の元がソースＣＩ、矢印の先がターゲットＣＩとなる。
ソースＣＩとターゲットＣＩの関係は、１対Ｎ（０以上）である。
【００３８】
図４の例を説明する。
図４の（１）より、ＩＴサービスプロバイダが提供するサービス下にそのサービスを構成する複数のシステムが存在する。
図４の（２）より、システム下には複数の物理ノードと仮想ノードが存在する。
図４の（３）より、物理ノードの上には複数の仮想ノードが存在する。
図４の（４）より、仮想ノードの上には複数のソフトウェアが存在する。
図４の（５）より、ハードウェアの上には複数の物理ノードが存在する。
構成管理モデル情報２０２２２の説明においては、構成管理モデルの例として図４を用いる。
【００３９】
図５は、構成管理モデル情報２０２２２の例である。
（ア）に項目名を示す。
項目は、ソースＣＩ、ターゲットＣＩから構成される。
（イ）にデータ例を示す。
データ例は、図４に示した構成管理モデルを表形式で表わしたものである。
図４の（１）が、図５（イ）のサービス（ソースＣＩ）−システム（ターゲットＣＩ）に対応する。
同様に、図４の（２）がシステム−物理ノード、システム−仮想ノード、図４の（３）が物理ノード−仮想ノード、図４の（４）が仮想ノード−ソフトウェア、図４の（５）がハードウェア−物理ノードと対応する。
【００４０】
図６は、制約条件情報２０２２３の例である。
制約条件は、構成管理担当者が更新しようとしている構成情報の誤り候補を抽出するために使用される制約条件である。
（ア）に項目名を示す。
項目は、サービス名、ソースＣＩ、ターゲットＣＩ、関係の最小値、関係の最大値、関係の規定値である。
サービス名、ソースＣＩ、ターゲットＣＩは前述した通りである。
関係の最小値は、１つのソースＣＩに対して関係するターゲットＣＩの最小の数、関係の最大値は１つのソースＣＩに対して関係するターゲットＣＩの最大数、関係の規定値は１つのソースＣＩに対して関係するターゲットＣＩの一意に決まった数である。
（イ）にデータ例を示す。
例えば、メールサービス（クラウド型）において、仮想ノードが３個、３個、５個、８個作成されている物理ノードがあったとする。
この場合、物理ノード（ソースＣＩ）と仮想ノード（ターゲットＣＩ）の関係の最小値は３、関係の最大値は８となり、関係の数は一意に決まっていないため「−」とする。
実際には、制約条件項目としてサービス名、ソースＣＩ、ターゲットＣＩは制約条件項目生成部２０１４により生成するが、制約条件の値である関係の最小値、関係の最大値、関係の規定値は構成管理担当者より入力してもらうため生成しない。
【００４１】
次に、構成管理装置２０の全体の動作について説明する。
【００４２】
構成管理装置２０を使用した構成管理では、構成情報の登録や更新を実施する前に、事前に制約条件ＤＢ２０２２内に制約条件情報２０２２３を定義しておく必要がある。
構成管理装置２０の利用手順としては、まず、ＩＴサービスプロバイダが新規サービスの提供を開始する際に、サービス名、サービス提供形態（サービス提供形態情報２０２２１の（１）サービス名とサービス提供形態の対応）の情報を構成管理装置２０へ入力する。
新規サービスに該当するサービス提供形態の情報がない場合には、サービス提供形態情報とその制約条件適用範囲（サービス提供形態情報２０２２１の（２）サービス提供形態毎の制約条件適用範囲）も合わせて定義する。
初めて構成管理装置２０を使用する場合には、構成管理モデル情報２０２２２の定義も必要となるが、１回定義をすれば、ＣＭＤＢ２０２１の構成管理モデルが変更されない限り、更新する必要はない。
これらの情報を元に、構成管理装置２０によって制約条件項目が生成される。
構成管理担当者はその制約条件項目に対して制約条件の値を設定する（制約条件情報２０２２３）。
事前準備は以上で完了となる。
事前定義された制約条件情報２０２２３を元に、構成情報の更新時において、構成情報の誤り候補の抽出が行われる。
【００４３】
図７は、ＩＴサービスプロバイダが新規サービスの提供を開始する際に、構成管理担当者がサービス名、サービス提供形態の情報を構成管理装置２０へ入力し、サービス提供形態情報２０２２１と構成管理モデル情報２０２２２を元に、制約条件項目が生成される処理に関係する機能を示した図である（図７の太線部分）。
【００４４】
画面表示部２０１１は、まず、新規サービスの情報をサービス提供形態情報２０２２１へ追加するための画面を表示する。
例えば、追加するサービス名の入力、サービス提供形態の選択等が行える画面を表示する。
入力されたサービス名とサービス提供形態は、制約条件項目生成部２０１４を通して、一旦サービス提供形態情報２０２２１へ保存される。
制約条件項目生成部２０１４では、追加したばかりのサービス提供形態情報２０２２１と構成管理モデル情報２０２２２を元に制約条件項目を生成し、制約条件情報２０２２３として保存する。
制約条件項目生成部２０１４の動作については、フローチャートを用いて後ほど詳細に説明するため、ここでは省略する。
処理の結果として、画面表示部２０１１は生成した制約条件項目を表示する。
構成管理担当者は、クライアント装置１０を通して、生成された制約条件項目を確認することが出来る。
【００４５】
図８は、図７により生成された制約条件項目に対して、構成管理担当者が制約条件の値を入力する際に関係する機能を示した図である（図８の太線部分）。
構成管理担当者は、生成された制約条件項目に対して、設計書等を元に、制約条件の値を定義する。
画面表示部２０１１は制約条件の値を入力する画面を表示し、構成管理担当者はクライアント装置１０より、制約条件の値を入力する。
入力された値は、制約条件更新部２０１５によって制約条件情報２０２２３へ登録される。
画面表示部２０１１はその処理の結果として更新後の制約条件情報２０２２３を表示する。
構成管理担当者は、クライアント装置１０を通して、制約条件項目に対する値が設定されたことを確認出来る。
【００４６】
図９は、図７と図８により制約条件の定義が完了した後、構成情報を新規登録または更新する際に関係する機能を示した図である（図９の太線部分）。
構成情報の新規登録、または、ＣＭＤＢ２０２１で管理している構成情報の更新をする場合、構成管理担当者はスプレッドシート等の形式にて登録または更新する構成情報を準備しておく。
準備された構成情報は、クライアント装置１０から画面表示部２０１１が提供する構成情報を更新する画面を通して、構成管理装置２０へ入力される。
入力された構成情報は、構成情報更新部２０１３によりＣＭＤＢ２０２１へ保存される。
制約条件確認部２０１６では、制約条件情報２０２２３を取得し、構成管理装置２０へ入力された構成情報に対して誤り候補を抽出する。
制約条件確認部２０１６では、制約条件情報２０２２３にて設定されたソースＣＩとターゲットＣＩ間の関係の最小値と最大値、または、規定値を元に、入力された構成情報の各ＣＩ間の関係の数をカウントし、制約条件を満たしているかどうかを確認する。
満たしていない場合は、誤り候補として抽出する。
制約条件確認部２０１６の動作については、フローチャートを用いて後ほど詳細に説明する。
抽出した結果は、画面表示部２０１１によって表示される。
構成管理担当者は、画面表示部２０１１によって誤り候補を確認することが出来る。
また、ＣＭＤＢ２０２１へ登録された構成情報も確認することが出来る。
構成情報更新部２０１３によるＣＭＤＢ２０２１への更新は、誤り候補が無い場合のみＣＭＤＢ２０２１を更新してもよいし、誤り候補があってもＣＭＤＢ２０２１を更新してしまってもよい。
【００４７】
次に、制約条件項目生成部２０１４の動作について説明する。
図１０は制約条件項目生成部２０１４のフローチャートである。
図１０を用いて、制約条件項目生成部２０１４の動作を詳細に説明する。
また、動作の説明と合わせて、メールサービス（クラウド型）について、制約条件項目を生成する場合の例も説明する。
【００４８】
Ｓ０１では、制約条件項目生成部２０１４は、構成管理担当者から入力された新規サービスのサービス名をキーとして、制約条件ＤＢ２０２２のサービス提供形態情報２０２２１の（１）サービス名とサービス提供形態の対応より、該当サービスの提供形態を取得する。
例えば、構成管理担当者よりメールサービス（クラウド型）が入力された場合、図２の（１）（イ）のデータ例より、メールサービス（クラウド型）のサービス提供形態がＳａａＳ型サービスであることを取得する。
【００４９】
Ｓ０２では、制約条件項目生成部２０１４は、Ｓ０１で取得したサービス提供形態名をキーとして、サービス提供形態情報２０２２１の（２）サービス提供形態毎の制約条件適用範囲より、該当サービス提供形態の適用範囲を取得する。
例えば、ＳａａＳ型サービスの場合、図３の（２）（イ）のデータ例より、各ＣＩの制約条件適用範囲として、ハードウェアは「○」、物理ノードは「○」、仮想ノードは「○」、ソフトウェアは「◎」であることを取得する。
【００５０】
Ｓ０３では、制約条件項目生成部２０１４は、Ｓ０２で取得した全ＣＩ型名に対して、制約条件項目が生成済かどうかを判断する。
全ＣＩ型名に対して生成済である場合は、Ｓ０９へ進む。
生成済でない場合は、Ｓ０４へ進む。Ｓ０３は、Ｓ０２で取得したＣＩ型名によるループ処理となっている。
例えば、Ｓ０２で取得した制約条件適用範囲の場合、ＣＩ型名である、ハードウェア、物理ノード、仮想ノード、ソフトウェアそれぞれに対して制約条件項目が生成済かどうかを判断し、生成済でない場合は、その都度Ｓ０４へ進む。
【００５１】
Ｓ０４では、制約条件項目生成部２０１４は、ＣＩ型名の制約条件適用範囲の値が「○」または「◎」であるかどうかを判断する。
「○」または「◎」の場合、Ｓ０５へ進む。
それ以外（「×」）の場合、Ｓ０３へ戻る。
例えば、ＳａａＳ型サービスの場合、まず１つめのＣＩ型名であるハードウェアについて確認する。
ＳａａＳ型サービスのハードウェアは「○」であるため、Ｓ０５へ進む。
別の例として、ハウジング型サービスの場合、ハードウェアは「×」であるため、制約条件を作成する必要がない。
そのため、Ｓ０３へと戻り、次のＣＩ型名である物理ノードに対する確認へと移る。
なお、Ｓ０３において制約条件適用範囲の値が「○」または「◎」のＣＩは、設定対象構成アイテムの例に相当する。
また、Ｓ０３において制約条件適用範囲の値が「×」のＣＩは、設定対象外構成アイテムの例に相当する。
【００５２】
Ｓ０５では、制約条件項目生成部２０１４は、構成管理モデル情報２０２２２より、制約条件適用範囲のＣＩ型名がソースとなっている関係情報を取得する。
ＳａａＳ型サービスのハードウェアの場合、図５の構成管理モデル定義の例の（イ）データ例より、ソースＣＩがハードウェア、ターゲットＣＩが物理ノードである関係情報を取得する。
構成管理モデルによっては、複数の関係情報が取得される場合もある。
【００５３】
Ｓ０６では、制約条件項目生成部２０１４は、Ｓ０５で取得した関係情報のターゲットＣＩそれぞれに対して、制約条件項目が生成済かどうかを判断する。
生成済でない場合、その都度Ｓ０７へ進む。
全ターゲットＣＩに対して生成済の場合、Ｓ０３へ戻る。
Ｓ０６は、Ｓ０５にて取得した関係情報のターゲットＣＩによるループ処理となっている。
例えば、ソースＣＩがハードウェア、ターゲットＣＩが物理ノードの場合、ターゲットＣＩである物理ノードに対して制約条件項目が生成済かどうかを判断する。
生成済でない場合はＳ０７へ進む。
【００５４】
Ｓ０７では、制約条件項目生成部２０１４は、ターゲットＣＩの制約条件適用範囲の値が「○」または「◎」であるかどうかを判断する。
「○」または「◎」の場合、Ｓ０８へ進む。
それ以外（「×」）の場合、Ｓ０６へ戻り、次のターゲットＣＩへと処理が移る。
ＳａａＳ型サービスの場合、物理ノードは「○」であるため、Ｓ０８へ進む。
なお、Ｓ０７において制約条件適用範囲の値が「○」または「◎」のＣＩは、関係構成アイテムの例に相当する。
【００５５】
Ｓ０８では、制約条件項目生成部２０１４は、関係情報と制約条件適応範囲の値より、制約条件項目を生成する。
詳細は図１１を用いて後で説明する。制約条件項目生成後はＳ０６へ戻る。
【００５６】
Ｓ０９では、制約条件項目生成部２０１４は、生成した全ての制約条件項目を制約条件ＤＢ２０２２の制約条件情報２０２２３として格納する。
メールサービス（クラウド型）の場合、図６の（イ）データ例で示した上から３行が制約条件項目として制約条件ＤＢへ格納される。
この時点では、関係の最小値・最大値、規定値の値は空欄である。図６では値の例を示すために数字を記載している。
【００５７】
図１１は、Ｓ０８である関係情報と制約条件の適用範囲の値より、制約条件項目を生成するフローチャートである。
【００５８】
Ｓ１０では、制約条件項目生成部２０１４は、関係情報のソースＣＩとターゲットＣＩの制約条件適用範囲の値が両方とも「◎」であるかどうかを判断する。
両方とも「◎」の場合、Ｓ１１へ進む。
それ以外（ソースＣＩが「◎」でターゲットＣＩが「○」、または、ソースＣＩが「○」でターゲットＣＩが「◎」、または、ソースＣＩが「○」でターゲットＣＩが「○」）の場合、Ｓ１２へ進む。
例えば、ＳａａＳ型サービスの関係情報であるハードウェアと物理ノードは、ソースＣＩが「○」でターゲットＣＩが「○」であるため、Ｓ１２へ進む。
別の例として、ＰａａＳ型サービスの関係情報であるハードウェアと物理ノードは両方とも「◎」であるため、Ｓ１１へ進む。
【００５９】
Ｓ１１では、制約条件項目生成部２０１４は、関係情報のソースＣＩとターゲットＣＩを制約条件項目とし、関係の最小値と最大値には「−」を入力する。
これは、ソースＣＩとターゲットＣＩの設計の仕様が共に一通りに決まっており、規定値にて制約条件の値を設定することが可能であるためである。
例えば、ＰａａＳ型サービスであるアプリケーションプラットフォームサービスのハードウェアと物理ノードの関係では、図６の（イ）データ例の５行目のように、ソースＣＩがハードウェア、ターゲットＣＩが物理ノード、関係の最小値と関係の最大値が「−」となる。
図６の例では、関係の規定値に値が入っているが、制約条件項目を生成した時点では空欄である。
【００６０】
Ｓ１２では、制約条件項目生成部２０１４は、関係情報のソースとターゲットのＣＩを制約条件項目とし、規定値には「−」を入力し、関係情報の最小値と最大値を設定出来るようにする。
例えば、ＳａａＳ型サービスであるメールサービス（クラウド型）のハードウェアと物理ノードの関係では、図６の（イ）データ例の１行目のように、ソースＣＩがハードウェア、ターゲットＣＩが物理ノード、関係の規定値が「−」となる。
図６の例では、関係の最小値と最大値に値が入っているが、制約条件項目を生成した時点では空欄である。
【００６１】
制約条件確認部２０１６の動作について説明する前に、図１２及び図１３に、構成管理担当者からクライアント装置１０を通してＣＭＤＢ２０２１へ登録または更新される構成情報の形式の例を説明する。
図１２及び図１３は、図４で示した構成管理モデルの例に対応した構成情報の登録・更新形式である。
ＣＩ、関係情報１つに対して１枚のシートが対応しており、複数シートから構成される構成情報の登録・更新形式の例である。
登録・更新形式はこの例に限らない。
【００６２】
図１２の（ア）にシート例を示す。
前述した通り、図４で示した構成管理モデルの例に対応した構成情報の登録・更新形式の例である。
図４は、ＣＩ６個、関係情報６個から構成される管理モデルであるため、ここでは計１２枚（ＣＩ６個＋関係情報６個）のシートから構成される例となっている。
シート名や枚数、種類は、構成管理モデルによって異なるため、この通りである必要はない。
図１３の（イ）にデータ例を示す。
ここでは、ＣＩであるサービス、ハードウェア、物理ノード、関係情報であるハードウェア・物理ノードの例を示している。
ＣＩの情報は、主キーと属性から構成される。
サービスシートの例は、サービス名が主キーとなり、属性として管理部署名を持つ例を示している。
属性は各ＣＩにおいて管理したい項目であり、構成管理の目的により変わってくるものであるため、この例の通りである必要はなく、管理部署名以外の属性をいくら管理してもよい。
関係情報については、ソースＣＩの主キー情報、ターゲットＣＩの主キー情報を管理することとなる。
例えば、図１３の（イ）データ例では、サービスシートは、メールサービス（クラウド型）の管理部署名がＡ部署であることを記載した例である。
ハードウェアシートは、Ａ製品のメーカーがＡ社、モデル番号がａａａ０１、シリアル番号が１２３４５６７８、ファームウェアバージョンがファーム０５であることを記載した例である。
物理ノードシートは、ｎｏｄｅ０１のＯＳ名がＸＸＸ、ＯＳバージョンが３．５．７、ＣＰＵモデルがＣＰＵ１、内蔵ディスク容量が５００ＧＢであることを記載した例である。
ハードウェア・物理ノードシートは、Ａ製品は物理ノードであるｎｏｄｅ０１とｎｏｄｅ０２、Ｂ製品はｎｏｄｅ０３のハードウェアとして使われていることを記載した例である。
【００６３】
次に、制約条件確認部２０１６の動作について説明する。
図１４は、制約条件確認部２０１６のフローチャートである。
図１４を用いて、制約条件確認部２０１６の動作を詳細に説明する。
【００６４】
Ｓ２１では、制約条件確認部２０１６は、クライアント装置１０から入力されたスプレッドシート等の形式に記載された構成情報の中からサービス名を読み込む。
例えば、図１２及び図１３で示した例の場合、サービスシートの主キーであるサービス名から、「メールサービス（クラウド型）」、「アプリケーションプラットフォームサービス」を読み込む。
【００６５】
Ｓ２２では、制約条件確認部２０１６は、読み込んだ全てのサービス名に対して誤り候補の抽出が完了したかどうかを判断する。
完了している場合はＳ２７へ進む。
完了していない場合は、Ｓ２３へ進む。
Ｓ２２は、Ｓ２１で取得したサービス名によるループ処理となっている。
【００６６】
Ｓ２３では、制約条件確認部２０１６は、サービス名をキーとして、該当するサービスの制約条件を制約条件ＤＢから取得する。
例えば、サービス名が「メールサービス（クラウド型）」の場合、図６の制約条件の例の（イ）のデータ例より、サービス名が「メールサービス（クラウド型）」の３つの条件である、ハードウェア−物理ノード、物理ノード−仮想ノード、仮想ノード−ソフトウェアの関係の最小値、関係の最大値、関係の規定値を取得する。
【００６７】
Ｓ２４では、制約条件確認部２０１６は、クライアント装置から入力された構成情報が新規登録か、更新かを判断する。
ここでの更新とは、ＣＭＤＢ２０２１へ格納されている構成情報の変更だけでなく、ＣＭＤＢ２０２１へ格納されているサービスやシステムへのノード等追加、削除も含む。
登録と更新の判断は、例えば、スプレッドシート内に新規登録と更新を判別するためのフラグ情報を付加して判断してもよいし、ＣＭＤＢ２０２１へ検索を行って確認する等、どのような方法でもよい。
新規登録の場合はＳ２５へ進む。更新の場合はＳ２６へ進む。
Ｓ２５では、制約条件確認部２０１６は、新規登録する構成情報に対して、制約条件を元にした誤り候補の抽出を行う。
処理が完了した後でＳ２２へ戻る。
Ｓ２５の処理の詳細は、図１５にて説明する。
【００６８】
Ｓ２６では、制約条件確認部２０１６は、更新する構成情報に対して、制約条件を元に誤り候補の抽出を行う。
処理が完了した後でＳ２２へ戻る。
Ｓ２６の処理の詳細は図１６にて説明する。
Ｓ２７では、抽出した誤り候補を画面表示部２０１１へ渡す。
画面表示部２０１１へ渡された誤り候補は、構成管理担当者に向けて、画面表示部２０１１にて表示される。
【００６９】
図１５は、新規登録時において誤り候補を抽出するフローチャートである。
【００７０】
Ｓ２８では、制約条件確認部２０１６は、取得した全ての制約条件を用いた誤り候補の抽出が完了したかを判断する。
完了した場合は、処理が終了となる。
完了していない場合は、Ｓ２９へ進む。
Ｓ２８は、Ｓ２３で取得した制約条件によるループ処理となっている。
サービス名が「メールサービス（クラウド型）」の場合、取得した制約条件である、ハードウェア−物理ノード、物理ノード−仮想ノード、仮想ノード−ソフトウェアの順にループ処理を繰り返し行っていく。
【００７１】
Ｓ２９では、制約条件確認部２０１６は、制約条件のソースＣＩに対応するスプレッドシートの主キーの値を一覧として取得する。
例えば、制約条件がハードウェア−物理ノードの場合、ソースＣＩはハードウェアであるため、ハードウェアシートから主キーであるハードウェア製品名称を取得する。
図１３の（イ）のデータ例の場合、「Ａ製品」、「Ｂ製品」という情報を取得する。
【００７２】
Ｓ３０では、制約条件確認部２０１６は、取得した主キーの値に対する誤り候補抽出が完了したかを判断する。
完了した場合、Ｓ２８へ戻る。
完了していない場合、Ｓ３１へ進む。
Ｓ３０は、Ｓ２９で取得した主キーによるループ処理となっている。
例えば、「Ａ製品」、「Ｂ製品」に対して、順に誤り候補の抽出を行う。
【００７３】
Ｓ３１では、制約条件確認部２０１６は、制約条件に対応する関係情報のスプレッドシートのソースの値が、Ｓ２９で取得した主キーの値と一致する関係情報を取得する。
例えば、確認しようとしている制約条件がハードウェア−物理ノードで値が「Ａ製品」である場合、それに対応する関係情報であるハードウェア・物理ノードシートから、主キーが「Ａ製品」である関係情報を取得する。
図１３の（イ）のデータ例の場合、ソースであるハードウェアの主キーが「Ａ製品」であり、ターゲットの物理ノードが「ｎｏｄｅ０１」、「ｎｏｄｅ０２」である２つの関係情報を取得する。
【００７４】
Ｓ３２では、制約条件確認部２０１６は、Ｓ３１で取得した関係情報の数をカウントする。
例えば、Ｓ３１で、ソースであるハードウェアの主キーが「Ａ製品」であり、ターゲットの物理ノードが「ｎｏｄｅ０１」、「ｎｏｄｅ０２」である２つの関係情報を取得した場合、その数は２となる。
【００７５】
Ｓ３３では、制約条件確認部２０１６は、カウントした関係情報の数が制約条件を満たしているかを判断する。
満たしている場合、Ｓ３０へ戻る。
満たしていない場合、Ｓ３４へ進む。
例えば、図６の（イ）データの例のメールサービス（クラウド型）のハードウェア−物理ノードの関係の場合、関係の規定値が１であるため、Ｓ３２でカウントした数が１でない場合は制約条件を満たしていないと判断され、Ｓ３４へ進む。
【００７６】
Ｓ３４では、制約条件確認部２０１６は、誤り候補として、Ｓ３３を満たさなかった構成情報を一時データとして記憶する。
例えば、ハードウェア−物理ノードの関係情報として、「製品Ａ−ｎｏｄｅ０１」、「製品Ａ−ｎｏｄｅ０２」が誤り候補として記憶される。
この情報がＳ２５の処理結果となり、最終的にはＳ２７にて画面表示部２０１１へと渡され、表示される。
【００７７】
図１６は、更新時において誤り候補を抽出するフローチャートである。
処理の流れは図１５で説明した新規登録時と同じであるが、更新の場合は、クライアント装置１０から入力される構成情報だけでなく、既にＣＭＤＢ２０２１へ格納されている構成情報も含めた誤り候補の抽出を行わなければならない点が異なる。
【００７８】
Ｓ３５では、制約条件確認部２０１６は、取得した全ての制約条件を用いた誤り候補の抽出が完了したかを判断する（Ｓ２８と同様）。
【００７９】
Ｓ３６では、制約条件確認部２０１６は、制約条件に対応する関係情報の更新があるかを判断する。
更新がある場合は、Ｓ３７へ進む。
更新がない場合は、Ｓ３５へ戻る。
例えば、確認しようとしている制約条件がハードウェア−物理ノードの場合、入力された構成情報のハードウェア・物理ノードシートに更新する情報が記入されているかどうかを確認し、ある場合のみ処理を行う。
これは、更新する構成情報のみをスプレッドシートへ記入する前提であるが、ＣＭＤＢ２０２１へ格納されており今回更新を行わない構成情報も含めたスプレッドシートを用意し、更新を行う情報のみにフラグを立てることで判断してもよい。
【００８０】
Ｓ３７では、制約条件確認部２０１６は、確認しようとしている制約条件に対応する関係情報のシートからソースの主キーの値から重複を取り除いた一覧を取得する。
例えば、確認しようとしている制約条件がハードウェア−物理ノードの場合、入力された構成情報のハードウェア・物理ノードシートからソースであるハードウェアの主キーを取得する。
図１３の（イ）データ例の場合、「Ａ製品」、「Ａ製品」、「Ｂ製品」であるが、重複を取り除いて、「Ａ製品」、「Ｂ製品」を取得する。
【００８１】
Ｓ３８では、制約条件確認部２０１６は、Ｓ３７で取得したソースの値に対する誤り候補抽出が完了したかを判断する。
完了した場合、Ｓ３５へ戻る。
完了していない場合、Ｓ３９へ進む。
Ｓ３８は、取得したソースの値（例えば、「Ａ製品」、「Ｂ製品」）によるループ処理となっている。
【００８２】
Ｓ３９は、制約条件確認部２０１６は、制約条件に対応する関係情報のシートのソースの値が、先程取得したソースの値と一致する関係情報を取得する。
例えば、Ａ製品についての誤り候補抽出を行おうとしている場合、図１３の（イ）データ例から、ソースが「Ａ製品」でありターゲットが「ｎｏｄｅ０１」、「ｎｏｄｅ０２」である関係情報を２つ取得する。
【００８３】
Ｓ４０では、制約条件確認部２０１６は、ＣＭＤＢ２０２１に格納されている関係情報から、先程取得したソースの値と一致する関係情報を取得する。
ＣＭＤＢ内のハードウェア・物理ノードのテーブルから情報を取得する。
【００８４】
Ｓ４１では、制約条件確認部２０１６は、Ｓ２９で取得した関係数である２と、Ｓ３０で取得した関係数を合計する。
例えば、ＣＭＤＢから取得した関係数が１であった場合、関係数の合計は３となる。
もし、更新情報のうちの１つが、ＣＭＤＢに格納されている関係情報の削除依頼であった場合、相殺されて、合計は１となる。
【００８５】
Ｓ４２では、制約条件確認部２０１６は、カウントした関係情報の数が制約条件を満たしているかを判断する（Ｓ３３と同じ）。
満たしている場合、Ｓ３８へ戻る。満たしていない場合、Ｓ４３へ進む。
【００８６】
Ｓ４３では、制約条件確認部２０１６は、誤り候補として、その構成情報を一時データとして記憶する（Ｓ３４と同じ）。
【００８７】
ハウジング型サービスのように、顧客が全ての構成を決定するため、図１０で示した制約条件項目生成部のフローチャートでは構成情報に対する誤り候補のチェックが行えない場合もある。
その場合、顧客毎の実際の構成情報から制約条件を生成し、誤り候補チェックを行うことも可能である。
【００８８】
図１７は、あるサービスにおいて、生成しようとしている制約条件のソースＣＩ型名、ターゲットＣＩ型名の制約条件適用範囲の値のいずれか一方、または、両方が「×」であると判明した場合において、構成情報から顧客毎の制約条件を生成するフローチャートである。
例えば、図３の（２）サービス提供形態毎の制約条件適用範囲の（イ）データ例のハウジング型サービスにおいては、ハードウェア、物理ノード、仮想ノード、ソフトウェアが全て顧客独自の構成である。
この場合、ハードウェア−物理ノード、物理ノード−仮想ノード、仮想ノード−ソフトウェアのいずれの関係においても、ソースＣＩ型名、ターゲットＣＩ型名の制約条件適用範囲の値は「×」となる。
【００８９】
図１７は、あるサービスにおいて、生成しようとしている制約条件のソースＣＩ型名、ターゲットＣＩ型名の制約条件適用範囲の値のいずれか一方、または、両方が「×」であると判明したことを前提としたフローチャートであるため、値が「×」であるかどうかの判断は図１７には含めていない。
実際には、図１０と図１７を組み合わせた１つのフローチャートとして処理を行ってもよい。
図４、図５の構成管理モデルの例、図６の制約条件の例では顧客情報を構成管理に含めていないが、顧客毎の制約条件生成を行う場合においては、その項目を追加する必要がある。
図４、図５の構成管理モデルにおいては、例えば、サービスより上位に顧客を配置し、サービス−顧客という関係情報を定義する。
図６の制約条件の例においては、顧客名の列を追加することで、サービス名と顧客名毎の制約条件を管理出来るようにする。
【００９０】
Ｓ５０では、制約条件確認部２０１６は、顧客毎の制約条件生成が全て完了したかどうかを判断する。完了した場合はＳ５７へ進む。完了していない場合はＳ５１へ進む。
【００９１】
Ｓ５１では、制約条件確認部２０１６は、ソースＣＩに対応する構成情報のシートの主キーの値を一覧として取得する。
例えば、ハードウェア−物理ノードに対する顧客毎の制約条件を生成する場合、ソースＣＩであるハードウェアの構成情報シートから主キー一覧を取得する。
図１２及び図１３の場合、ハードウェアシートから「Ａ製品」、「Ｂ製品」を一覧として取得する。
【００９２】
Ｓ５２では、制約条件確認部２０１６は、取得した主キーの値に対する関係情報の数のカウントが完了したかを判断する。
完了した場合はＳ５５へ進む。
完了していない場合はＳ５３へ進む。
Ｓ５２は、Ｓ５１で取得した一覧の値によるループ処理であり、「Ａ製品」のカウントが完了したら「Ｂ製品」と繰り返す。
【００９３】
Ｓ５３では、制約条件確認部２０１６は、ソースＣＩ型名、ターゲットＣＩ型名に対応する関係情報シートのソースＣＩの値が取得した主キーと一致する関係情報を取得する。
例えば、ハードウェア−物理ノードの場合、ハードウェア・物理ノードのシートから関係情報を取得する。
図１３の場合、ソースが「Ａ製品」でありターゲットが「ｎｏｄｅ０１」、「ｎｏｄｅ０２」である関係情報を２つ取得する。
【００９４】
Ｓ５４では、制約条件確認部２０１６は、取得した関係情報の数をカウントする。
Ｓ５３で示した例の場合、関係情報の数は２となる。
Ｓ５４の処理の後はＳ５２へ戻る。
【００９５】
Ｓ５５では、制約条件確認部２０１６は、カウントした関係情報の数から、最小値と最大値を求める。
例えば、ソースＣＩが「Ａ製品」の関係情報の数が２、ソースＣＩが「Ｂ製品」の関係情報の数が１である場合、最小値は１、最大値は２となる。
【００９６】
Ｓ５６では、制約条件確認部２０１６は、求めた最小値と最大値を設定した制約条件を生成する。
例えば、サービス名が「ハウジング型サービス」、顧客名が「Ａ社」、ソースＣＩが「ハードウェア」、ターゲットＣＩが「物理ノード」、関係の最小値が「１」、関係の最大値が「２」、関係の規定値が「−」となる。
Ｓ５７では、生成した制約条件を制約条件ＤＢへ格納する。
【００９７】
顧客毎の制約条件についても、制約条件確認部２０１６において図１４、図１５と同様の手順にて誤り候補の抽出を行う。
抽出された誤り候補が正しい場合、図１７のフローチャートにて生成した制約条件の最小値、最大値の値を更新するようにしてもよい。
【００９８】
以上の処理により、サービス提供形態情報、構成管理モデルの情報を元に、サービス毎の制約条件項目を生成する。
【００９９】
本実施の形態により、サービス毎に定義すべき制約条件項目を漏れなく生成することが可能となる。
制約条件を設定する担当者は、本実施の形態により生成された制約条件項目に合わせて制約条件の値を設定すればよいため、制約条件を漏れなく定義することが可能となる。
サービス毎に制約条件を定義するため、全ての構成情報に対して定義された一意な制約条件と比較して、精度のよい制約条件を定義することが可能となる。
【０１００】
以上、本実施の形態では、ＣＭＤＢへ登録するまたは更新する構成情報に対して、サービス提供形態に考慮した制約条件を設定することができ、その制約条件を元に、構成情報の誤り候補をチェックすることが可能な構成管理装置を説明した。
【０１０１】
また、利用者から入力されたＣＭＤＢへ登録するまたは更新する構成情報、制約条件ＤＢに格納されたサービス提供形態情報、ＣＭＤＢの構成管理モデルより、制約条件項目を作成する制約条件項目生成部を持つ構成管理装置を説明した。
【０１０２】
また、制約条件項目生成部が作成した制約条件項目に対して設定された制約条件の値を元に、利用者から入力される構成情報に対する誤り候補をチェックする制約条件確認部を持つ構成管理装置を説明した。
【０１０３】
また、サービス提供形態毎の制約条件適用範囲において、サービスを利用する顧客が独自に設計を行った場合に、顧客毎の制約条件を自動生成することが可能な制約条件項目生成部を持つ構成管理装置を説明した。
【０１０４】
また、制約条件項目生成部が自動作成した顧客毎の制約条件を元に、利用者から入力される構成情報に対する誤り候補をチェックする制約条件確認部を持つ構成管理装置を説明した。
【０１０５】
最後に、本実施の形態に示した構成管理装置２０のハードウェア構成例を図１８を参照して説明する。
構成管理装置２０はコンピュータであり、構成管理装置２０の各要素をプログラムで実現することができる。
構成管理装置２０のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。
【０１０６】
演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。
図１に示すＣＭＤＢ２０２１及び制約条件ＤＢ２０２２は、例えば、外部記憶装置９０２や主記憶装置９０３により実現される。
通信装置９０４は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
【０１０７】
プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１に示す「〜部」の機能を実現するプログラムを実行する。
また、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の取得」、「〜の設定」、「〜の特定」、「〜の参照」、「〜の解析」、「〜の合計」、「〜の選択」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
また、暗号鍵・復号鍵や乱数値やパラメータが、主記憶装置９０３にファイルとして記憶されてもよい。
【０１０８】
なお、図１８の構成は、あくまでも構成管理装置２０のハードウェア構成の一例を示すものであり、構成管理装置２０のハードウェア構成は図１８に記載の構成に限らず、他の構成であってもよい。
また、本実施の形態に示す手順により、本発明に係る構成管理方法を実現可能である。
【符号の説明】
【０１０９】
１０  クライアント装置、２０  構成管理装置、２０１  情報処理装置、２０２  情報記憶装置、２０１１  画面表示部、２０１２  構成情報取得部、２０１３  構成情報更新部、２０１４  制約条件項目生成部、２０１５  制約条件更新部、２０１６  制約条件確認部、２０２１  ＣＭＤＢ、２０２２  制約条件ＤＢ、２０２２１  サービス提供形態情報、２０２２２  構成管理モデル情報、２０２２３  制約条件情報。
【図１】
2014228874.tif 000003
【図２】
2014228874.tif 000004
【図３】
2014228874.tif 000005
【図４】
2014228874.tif 000006
【図５】
2014228874.tif 000007
【図６】
2014228874.tif 000008
【図７】
2014228874.tif 000009
【図８】
2014228874.tif 000010
【図９】
2014228874.tif 000011
【図１０】
2014228874.tif 000012
【図１１】
2014228874.tif 000013
【図１２】
2014228874.tif 000014
【図１３】
2014228874.tif 000015
【図１４】
2014228874.tif 000016
【図１５】
2014228874.tif 000017
【図１６】
2014228874.tif 000018
【図１７】
2014228874.tif 000019
【図１８】
2014228874.tif 000020