情報システムに対する運用手順の作成を支援する、情報処理装置を用いた運用手順作成支援システムであって前記情報処理装置は、前記運用手順の共通的な手順を部品とした手順部品と、当該手順部品が操作対象とする、前記情報システムを構成する構成要件を記憶しておき、前記情報システムの構成に変更が生じた際に、前記手順部品が操作対象とする前記構成要件に対する修正の必要性を評価し、当該評価結果に基づき、前記情報システムの構成に生じた変更に対する、前記運用手順への修正範囲を提示することを特徴とする運用手順作成支援システム。請求項1に記載の運用手順作成支援システムであって、前記情報処理装置は、前記評価結果に基づき修正した前記情報システムの構成要件と、前記手順部品が操作対象とする、既存の前記構成要件とを比較し、当該比較結果に基づき、修正候補となる新たな手順部品を提示することを特徴とする運用手順作成支援システム。請求項1に記載の運用手順作成支援システムであって、前記情報システムの構成要件が、構成要素と、前記手順部品の利用時に利用する構成情報を含み、前記情報処理装置は、前記評価結果により、前記手順部品が操作対象とする前記構成要件に変更があると判定した場合、前記変更に対応した新たな運用手順を提示することを特徴とする運用手順作成支援システム。請求項1に記載の運用手順作成支援システムであって、前記情報システムの構成要件が、構成要素と、前記手順部品の利用時に決定されるパラメータ要素に対応する構成情報を含み、前記情報処理装置は、前記評価結果により、前記手順部品が操作対象とする前記構成要件に変更がないと判定し、前記情報システムの構成に生じた変更が、前記パラメータ要素に対する変更である場合は、変更後の当該パラメータ要素を前記構成情報に反映させ、前記変更に対応した新たな運用手順を提示することを特徴とする運用手順作成支援システム。請求項1に記載の運用手順作成支援システムであって、前記情報処理装置は、前記手順部品を組み合わせて新たな運用手順を作成し、前記手順部品の作成時に、既存の前記手順部品との順序関係性を定義しておき、前記運用手順作成時の前記手順部品の選択時に、前記順序関連性を持つ前記手順部品を候補として提示することを特徴とする運用手順作成支援システム。請求項5に記載の運用手順作成支援システムであって、前記情報処理装置は、作成した前記運用手順の順序フローを抽出し、前記手順部品間の前記順序関連性と比較することで、作成した前記運用手順で、前記手順部品間の順序関連性と一致しない部分を抽出して提示することを特徴とする運用手順作成支援システム。請求項1に記載の運用手順作成支援システムであって、前記情報処理装置は、表示装置を備え、当該表示装置に、前記運用手順への修正範囲を提示することを特徴とする運用手順作成支援システム。請求項7に記載の運用手順作成支援システムであって、前記情報処理装置は、前記表示装置に、前記運用手順の編集画面として、前記手順部品と、当該手順部品の修正内容を表示することを特徴とする運用手順作成支援システム。情報システムに対する運用手順を作成支援する運用手順作成支援システムにおける運用手順作成方法であって前記運用手順の共通的な手順を手順部品とし、前記手順部品と、当該手順部品が操作対象とする、前記情報システムを構成する構成要件を記憶しておき、前記手順部品を組み合わせて新たな運用手順を作成し、前記情報システムの構成に変更が生じた際に、前記手順部品が操作対象とする前記構成要件に対する修正の必要性を評価し、当該評価結果に基づき、前記情報システムの構成に生じた変更に対する、前記運用手順への修正範囲を出力することを特徴とする運用手順作成方法。請求項9に記載の運用手順作成方法であって、前記評価結果に基づき修正する前記情報システムの構成要件と、前記手順部品が操作対象とする、既存の前記構成要件とを比較することにより、修正候補となる新たな手順部品を出力することを特徴とする運用手順作成方法。請求項9に記載の運用手順作成方法であって、前記情報システムの構成要件が、構成要素と、前記手順部品の利用時に利用する構成情報を含み、前記評価結果により、前記手順部品が操作対象とする前記構成要件に変更があると判定した場合、前記変更に対応した新たな運用手順を出力することを特徴とする運用手順作成方法。請求項9に記載の運用手順作成方法であって、前記情報システムの構成要件が、構成要素と、前記手順部品の利用時に決定されるパラメータ要素に対応する構成情報を含み、前記評価結果により、前記手順部品が操作対象とする前記構成要件に変更がないと判定し、前記情報システムの構成に生じた変更が、前記パラメータ要素に対する変更である場合は、変更後の当該パラメータ要素を前記構成情報に反映させ、変更後の前記構成情報に対応する手順部品を検索し、当該手順部品が有る場合、当該手順部品を出力することを特徴とする運用手順作成方法。請求項9に記載の運用手順作成方法であって、前記情報システムの構成要件が、構成要素と、前記手順部品の利用時に決定されるパラメータ要素に対応する構成情報を含み、前記評価結果により、前記手順部品が操作対象とする前記構成要件に変更がないと判定し、前記情報システムの構成に生じた変更が、前記パラメータ要素に対する変更である場合は、変更後の当該パラメータ要素を前記構成情報に反映させ、変更後の前記構成情報に対応する手順部品を検索し、当該手順部品が無い場合、前記手順部品の修正の必要性を出力することを特徴とする運用手順作成方法。請求項9に記載の運用手順作成方法であって、前記手順部品の作成時に、既存の前記手順部品との順序関係性を定義しておき、前記運用手順作成時の前記手順部品の選択時に、前記順序関連性を持つ前記手順部品を候補として出力することを特徴とする運用手順作成方法。請求項14に記載の運用手順作成方法であって、作成した前記運用手順の順序フローを抽出し、前記手順部品間の前記順序関連性と比較することで、作成した前記運用手順で、前記手順部品間の順序関連性と一致しない部分を抽出して出力することを特徴とする運用手順作成方法。上述の通り、情報システムの運用手順を設計する過程において、その作成を容易化することが求められている。またそれ以上に、作成した運用手順を保守する手間が大きいことが大きな課題となっている。情報システムは一般的にその機器構成やツールやアプリケーションソフトウェアのバージョンアップに伴う機能が頻繁に変更されることが多く、その都度運用手順に反映する必要があり、その手間も非常に大きい。これは、変更に対し運用手順書のどの部分が変更されるかがわからず、机上で運用手順書をチェックしたり、汎用ツールの検索機能を利用して修正箇所を逐次探したり、といった大きな手間がかかるからである。しかしながら、従来技術においては、仕様が変更したときに現マニュアルをどのように効率的に修正変更するかということは検討されていない。本発明の目的は、上記の課題を解決し、情報システムの構成変更に伴う運用手順の作成支援を効率良く行う運用手順作成支援システム、及び方法を提供することにある。上記の目的を達成するため、本発明においては、情報システムに対する運用手順の作成を支援する、情報処理装置を用いた運用手順作成支援システムであって情報処理装置は、運用手順の共通的な手順を部品化した手順部品と、当該手順部品が操作対象とする、情報システムを構成する構成要件を記憶しておき、情報システムの構成に変更が生じた際に、手順部品が操作対象とする構成要件に対する修正の必要性を評価し、その評価結果に基づき、情報システムの構成に生じた変更に対する、運用手順への修正範囲を出力する運用手順作成支援システムを提供する。また、上記の目的を達成するため、情報システムに対する運用手順を作成支援する運用手順作成支援システムにおける運用手順作成方法であって、記運用手順の共通的な手順を手順部品とし、当該手順部品と、当該手順部品が操作対象とする、情報システムを構成する構成要件を記憶しておき、手順部品を組み合わせて新たな運用手順を作成し、情報システムの構成に変更が生じた際に、手順部品が操作対象とする構成要件に対する修正の必要性を評価し、評価結果に基づき、情報システムの構成に生じた変更に対する、運用手順への修正範囲を出力する運用手順作成方法を提供する。情報システムの運用手順を作成支援する際、運用手順において使用されている手順部品の変更必要性を評価することで、運用手順における変更の影響部分と、構成の変更に対応した修正内容を提示することができる。これより、運用手順書の作成のみならず、構成変更時の運用手順書に対する修正作業を効率化でき、運用手順書の保守を容易化できる。以下本発明の実施の形態を図面に従い説明する。なお、本明細書において、手順部品とは、運用手順書から、運用手順を一定の単位で分割抽出したものを意味し、パラメータ要素とは、手順部品を利用するときに決定される各種の項目を示す。構成要件とは、情報システムを構成するサーバ装置、ディスク装置、ソフトウェアツール等の構成に係る要件を意味する。また、構成要件における構成要素とは、サーバ装置、ディスク装置、ソフトウェアツール等を構成する処理部、メモリ、オペレーティングシステム、インタフェース、ソフトウェアツールのバージョン情報等を示し、構成要件における構成情報とは、手順部品におけるパラメータ要素に対応するものであり、情報システムを構成するサーバ装置、ディスク装置、ソフトウェアツール等の識別名、ツール名、ドライブ名、或いは管理番号等を示すものとする。第1の実施例として、運用手順作成支援システムに関する実施例を説明する。<全体の構成>図1は実施例1の運用手順作成支援システムの全体の構成例を示す図である。本システムは、運用手順の設計支援を行う各種機能110~115を実行する運用手順設計サーバ101と、設計支援を行う各種機能が利用/出力する各種データベース120~124を保持するストレージ102にて構成される。運用手順設計サーバ101とストレージ102はネットワーク104を介して接続される。また、運用手順の設計を行うユーザは、運用手順設計サーバ101に接続されたオペレーション端末103にて各種操作を実施する。なお、本システムの構成はこの図で示された構成に限られたものではなく、例えば一部の機能を、ネットワークを介して接続された別のサーバにて実行する、または一部のデータベース情報を、ネットワークを介して接続された別のストレージに保存するという構成にしても良い。手順設計サーバの各機能110~116と各種データベースDB120~126をデータセンタにホストし、オペレーション端末103はネットワークを介してデータセンタに接続することで、クラウドサービスとして遠隔で利用する構成としても良い。本システムの運用支援を行う各種機能には、運用手順を部品として作成する部品作成機能110、運用対象機器の構成情報を管理する構成管理機能111、運用手順を作成編集する手順作成機能112、作成した運用手順を検証する手順検証機能113、運用対象機器の構成や運用内容を修正変更するときに作成した運用手順に対して変更に伴う影響を評価する修正評価機能114、運用手順を作成する際に部品作成機能110で作成した手順部品から当該運用手順の内容や運用対象機器の構成に対し該当する手順部品候補を検索する部品検索機能115、作成した手順を紙や電子端末に対し既定のフォーマットに変換出力する手順出力機能116、で構成される。各機能の詳細に関しては、後段で説明する。また、運用設計支援を行う各種機能が利用する各種データベースには、部品作成機能により作成された手順部品を格納する手順部品DB120、運用対象機器の構成要件を管理するための標準的な構成要素を格納する構成要件ツリーDB121、複数の手順部品間での順序関係を定義する順序定義DB122、部品を利用して作成した運用手順を格納する手順DB123、部品利用時にパラメータ要素に対応する構成情報を格納する部品パラメータDB124、定義した部品に対し前提となる構成要件を格納する構成要件DB125、手順出力時に出力形式やレイアウトを規定する出力フォーマットDBで構成される。各データベースの詳細に関しては、後段で説明する。図2に本実施例の運用手順作成支援システムにおける運用手順設計サーバ101の代表的な構成例を示す。当該サーバは、演算処理を実行する中央演算装置CentralProcessingUnit:CPU151、一時的にプログラムデータを記憶するメモリ152、各種インタフェースに対する制御を行うコントローラ153、各種データプログラムを保持するハードディスクドライブHardDiskDrive:HDDなどの記憶装置154、外部ネットワークと接続するネットワークインタフェース155、ディスプレイやキーボード等の周辺装置を接続する周辺装置インタフェース156から構成される。周辺インタフェース156には一例としてディスプレイである表示装置157を接続して示した。上述のCPU151は、メモリ152に記憶される各種の機能110~116に対応するプログラムを実行することにより、以下に順次説明する機能を実現する。<部品作成機能>本実施例の運用手順作成支援システムの部品作成機能110では、新たに運用手順をある単位でブロック化し、パラメータ要素となる部分を抽出した上で運用手順部品として定義する機能である。図3に部品作成機能の処理フローの一例を示す。まず、既存の運用手順書または作成途中の運用手順書から、運用手順を一定の単位で分割抽出することで、手順部品とする201。手順部品の単位は任意で決められるが、例えば一つの運用手順書内または複数の運用手順書間で共通して繰返しで登場する単位、操作の手順に意味を持たせることができるまとまりの単位、OSツール/ミドルウェア/アプリケーションソフトウェアで共通の操作単位等が考えられる。続いて、抽出された当該手順部品が前提とする運用対象機器の構成要件ツリーを選択する202。構成要件ツリーは、手順部品で定義された操作を実行するに当たり、操作対象とするサーバやディスク装置などの機器や、OS、ミドルウェア、各種ソフトウェアの構成要素を表している。構成要件ツリーの詳細と具体例に関しては、後段で説明する。次に、選択した構成要件ツリーで定義されている構成要素に対し、運用対象機器の具体的な前提構成を設定する。例えば、サーバを対象とした操作で、サーバにUSBUniversalSerialBusディスクを接続するという手順部品を作成するとすれば、サーバはUSB端子を、ディスク装置は接続インタフェースとしてUSB端子を持つ必要があり、構成要件としてサーバの構成要素であるインタフェースに対しUSBを、またディスク装置の構成要素であるインタフェースに対しUSBを設定することになる。次に、手順部品におけるパラメータ要素の抽出と構成要件における構成情報との対応付けを行う204。パラメータ要素とは、手順部品を利用するときに決定される事項を指す。例えばディスク装置を用意するという内容の手順部品とすると、手順部品を利用するときに決定されるディスク装置の所在や管理番号といった項目が、パラメータ要素となる。また、構成要件においてパラメータ要素と対応した構成情報を持たせることができるため、構成要件においてパラメータ要素と対応する構成情報がある場合は、それと対応させる。最後に、既存の運用部品との順序関連性を定義する205。手順部品によっては、当該の部品の前後に順序関連性を持った手順部品が使われることが多い。例えばある運用手順書を作成している場合、サーバにUSBディスクを接続するという手順部品を使う場合、その前にディスク装置を用意するという手順部品を呼び出す必要があると推測できる。そこで、手順部品を利用する場合、順序関連性がある手順部品を同時にユーザに対し提示することで、部品選択の手間を低減することを目的に、手順部品DB120内に格納された既存部品の中に順序関連性を持つものがあれば、それを指定する。<構成要件ツリー>次に、本実施例の運用手順作成支援システムの構成要件ツリー121の一例について説明する。図4A、図4B、図4Cに構成要件ツリーの例を示す。これらの構成要件ツリーは、上述した構成情報を管理する構成管理機能111により、構成要件ツリー121としてストレージ102に形成、管理される。図4Aは、サーバを対象とした構成要件ツリーの例である。ツリー上での構成要素はツリーで表現され、四角形で示した頂点のルートノード251が、ツリーの構成要件の種別SRVを表す。六角形で表したノード252は構成情報を表し、手順部品において例えばサーバの識別名といったパラメータ要素と対応する。楕円のノード253~256は構成要素となり、例えばノード253はOSの種別を構成要素として持つことを表している。つまり、サーバを対象とした構成要件で、サーバに搭載されるOSの種別を構成要素として持つ。同様に、ノード254はサーバが持つインタフェースI/F、ノード255はサーバが持つCPUの種類、ノード256はサーバが持つメモリの容量を構成要素として持つことを表している。また図4Bは、ソフトウェアツールを対象とした構成要件ツリーの例である。同じくルートノード261はツリーの種別、即ちソフトウェアツールTLを示し、ノード262は構成情報となるツール名、ノード263は構成要素となるバージョン、ノード264はツール利用時に設定する項目、ノード265はツールを実行する上で前提とするOSの種別を表している。また図4Cはディスク装置を対象とした構成要件ツリーの例である。同じくルートノード271はツリーの種別、即ち、ディスク装置DKを示し、ノード272は構成情報となるドライブ名、ノード273は構成要素となるディスクが使用するインタフェースの種類、ノード274は構成情報となる管理番号を表している。<手順部品の例>次に、部品作成機能110によって作成された手順部品例を説明する。図5A、図5Bは部品名がディスク装置用意であり、ディスク装置を用意する手順内容である。図5Aは手順部品DB120に格納される手順部品の情報である300。格納される情報の項目として、部品の名前を表す部品名、当該部品が対象とする構成要件、パラメータ要素に対応する構成情報、及び手順内容である。構成要件では、構成要件DB125に保持された当該部品に対応する構成要件の識別子を指定する。構成情報では、構成要件においてパラメータ要素と対応する構成情報が指定されている場合、同じく構成要件DB125に保持された当該部品に対応する構成要件と構成情報の識別子を指定する。図5Bは構成要件DB125に保持される、部品300に対応する構成要件であるDK01311を示す。図4Cで示したディスク装置の構成要件ツリーDK271に対し、各構成要素に対応した情報を付加している。例えば、ノード313はインタフェースに関する構成要素であるが、下位ノード315でUSB、下位ノード316でeSATAExternalSerialATAを指定している。2つのノードを結ぶエッジには点線の弧317が描かれているが、これはOR条件を表している。つまり、インタフェースとしてUSBかeSATAどちらかが構成要素になることを示す。また構成情報となるノード312はディスク装置のドライブ名を定義しているが、当該部品ではドライブ名は使用しないためDCDon’tCareの略を付加している。同じく構成情報であるノード314はディスク装置の管理番号を定義しているが、これは本部品でパラメータ要素として使用しているため、構成情報の識別子P01を付加している。続いて、図6A、図6Bを用いて、別の手順部品例を説明する。図6A、図6Bは部品名がUSBディスク装置接続であり、USBインタフェースを持ったディスク装置をサーバに接続し、OS上で当該接続装置が認識されることを確認する手順内容である。図6Aは手順部品DB120に格納される手順部品の情報である320。構成要件はサーバ要件であるSRV01と、ディスク装置要件であるDK02をAND条件で指定する。構成情報は、当該手順部品のパラメータ要素に対応するものとして、サーバ要件においてはサーバ名P01、ポート番号P02、ディスク装置要件ではドライブ名P03が指定されている。図6Bは構成要件DB125に保持される、部品320に対応する構成要件を示す。ユーザは図4Aで示したサーバ要件SRV251と図4Cに示したディスク装置要件DK271に対し、各構成要素に対応した情報を付加する。例えば、構成要素であるノード334はOSを定義するが、下位ノード314にてWindows登録商標Server2003、下位ノード342にてWindowsServer2007をOR条件で定義している。つまり、これら2種類のOSに対応していることを示している。ノード336ではCPUの種別を定義するが、ノード344はDCを示しており、これはCPUの種別を問わないことを意味している。サーバ要件SRV01331のノード335とディスク装置要件DK02332のノード339はインタフェース種別を表しており、当該サーバ要件と当該ディスク装置双方で共通の構成要素を示している。構成要件作成時に、各要件において共通の構成要素がないかを検索し、もし同じ構成要素で、構成内容も共通であった場合は、共通関係を持つことを示す情報を保持しておく347。なお、共通の構成要素があるが、構成内容が共通で無い場合はユーザに通知し、もし当該部品に対応する構成要件として共通化する必要があるケースの場合は、手動で共通化する構成内容を指定する。例えば、本例でのUSBディスク装置接続は、サーバ装置とディスク装置が共通のインタフェースであるUSB343、348を持つ必要がある。なお、構成情報であるノード346は、ポート番号を定義しているが、構成情報の識別子P02を付加している。続いて、図7A、図7Bにより、さらに別の部品例を説明する。図7A、図7Bは部品名がeSATAディスク装置接続であり、eSATAインタフェースを持ったディスク装置をサーバに接続し、OS上で当該接続装置が認識されることを確認する手順内容である。図6A、Bで説明したUSBディスク装置接続との差異は、インタフェースがUSBではなくeSATAとなっている点のみであり、他は同じである。図7Aは手順部品DB120に格納される手順部品の情報350である。構成要件はサーバ要件であるSRV02361とディスク装置要件であるDK03をAND条件で指定する。図7Bに構成要件DB125に保持される、部品350に対応する構成要件、接続要件を示す。USBディスク装置接続330と異なる点は、まずサーバ要件SRV02361における構成要素であるインタフェース363がeSATA365となっている点、またディスク装置要件DK03362のインタフェース364が同様にeSATA366になっている点である。次に、図8A、図8Bで、さらに別の部品例を説明する。図8A、Bは部品名がバックアップ実行であり、バックアップ元/バックアップ先/バックアップオプションを指定し、バックアップを実行し、正常終了を確認し、バックアップサイズと時間を記録する手順内容である。図8Aは手順部品DB120に格納される手順部品の情報370を示す。構成要件はサーバ要件であるSRV02とツール要件であるTL01をAND条件で指定している。次に構成情報として、ツール要件TL01に対応し、バックアップ元P01、バックアップ先P02、オプションP03を指定している。図8Bは構成要件DB125に保持される、部品370に対応する構成要件、接続要件である。ユーザは図4Aで示したサーバ要件SRV251と、図4Bでツール要件TL261に対し、各種構成要素に対応した情報を付加する。例えば、ツール要件TL01377のノード383はツールの種類としてWinバックアップが指定され、さらに下位ノード385ではバージョンの指定、ノード386では当該ツール利用時の設定項目を示している。設定項目は構成情報として、部品のパラメータ要素に対応する。例えば、構成情報であるノード394はバックアップ元、ノード395はバックアップ先、ノード396はオプションを表す。またオプションの選択肢としてノード396の下位ノードにノード397及びノード398がOR条件で定義され、オプションとして下位階層全てバックアップ397か当該階層のみバックアップ398を選択することができる。なお、ツール要件TL01におけるOS384の種類は、WindowsServer2003387のみの対応のため、サーバ要件SRV02376におけるOS379の種類も同様の指定がなされている389。<部品関連性の定義>図3の部品作成機能のフロー図で示したとおり、部品に対する構成要件の設定203と、手順部品からパラメータ要素の指定、構成情報との対応204を実施後、既存の運用部品に対する順序関連性を定義する205。図9に手順部品の順序関連性定義の一例を示す。上述した通り、部品作成の例として4つの手順部品300、320、350、370の関連性を有向グラフで定義している。これらの手順部品の順序関係を説明すると、まず手順部品300のディスク装置用意400を実施後、手順部品320のUSBディスク装置接続401、または手順部品350のeSATAディスク装置接続402を実施し、手順部品370のバックアップ実行403を実施するという関係になる。従って、ノード400に対し、矢印付きのエッジがノード401とノード402に向かって伸びるが、双方のエッジには点線の弧が書かれOR条件を表すため、どちらか一方のノードを取ればよい。<手順作成機能と部品検索機能>次に図1の運用手順書を作成する手順作成機能112に関して説明する。運用手順書は、運用対象機器に対する運用手順を、一つの操作単位毎に順番に定義していく。運用対象機器に対する操作全体の手順の流れフローを定義し、各操作項目の詳細内容を、手順部品を利用する場合は対応する手順部品を検索し選択することで当該操作項目に当てはめ、手順部品を利用しない場合は当該操作項目の詳細内容を手動で入力する。次に、図1の手順部品利用時の部品検索機能115に関して説明する。図10に部品検索機能の処理フローの一例を示す。手順部品の検索では、まず運用内容、システム構成情報、運用情報を入力する。図11A、図11B、図11Cにそれぞれ、運用内容、システム構成情報、運用情報の一例を示す。運用内容461は、例えばディスクの用意ディスクの接続バックアップといった、運用の内容を表す表現を含む。図11Bに示すシステム構成情報462は、図4A、図4B、図4Cで定義した構成要件における、例えばサーバ名、OSの種類、インタフェース、ツールの種類、ツールのバージョン等の構成要素を表す。図11Cに示す運用情報463は、運用時に決定される、例えば、機器の識別子や管理番号、ツールの設定項目等の情報を表す。図10の部品検索機能115では、これらの入力情報から対応する部品を、手順部品DB120、及び構成要件DB125から抽出する452。まず、運用内容461に関しては、その表現を解析することで運用内容を表すキーワードを抽出し、キーワードベースで対応する手順部品を候補として抽出する。運用内容461からデータベースに対応する運用部品候補の抽出方法に関してはこれに限定されるわけではなく、各種の言語処理手法を活用することで、実現できる。また、構成情報は、部品作成時に手順部品に対応する構成要件が定義され、構成要件DB125に格納されているが、処理451で入力されたシステム構成情報に対し構成要件が一致するものを構成要件DB125上で検索し、抽出された構成要件からさらに対応付けられた部品を候補として、手順部品DB120から抽出する。入力されたシステム構成情報と構成要件DB上での構成要件との一致検索の実現手段は、様々な手法が考えられるが、例えば入力されたシステム構成情報から構成要素とそれに対応する内容、例えば、構成要素がOSであり、対応する内容がWindowsServer2003を抽出する。次に構成要素をキーとして構成要件DB125に格納されている構成要件を検索し、一致した構成要素が存在し、それに対応する内容も一致していれば、構成要件として一致していると判断する。同様に、他の構成要素も一致検索し、定義された要件に対し全ての構成要素が一致していれば完全一致した構成要件として抽出できる。なお、入力されたシステム構成情報に対応する構成要素においては全て一致しているが、構成要件によっては別の構成要素が存在し、入力されたシステム構成情報では当該の別の構成要素に対し一致を判定できないため、完全一致する要件ではないと判断されることも考えられる。その場合は部分一致としてユーザに提示し、構成要件の候補に含めるかをユーザが判断するとしても良い。以上で、抽出された部品候補の有無を判定し453、もし部品候補が有ればその候補の中から適切な部品を選択する454。もし部品候補が無ければ検索を終了する459。この場合は部品作成機能110により新たに部品として作成するか、手順作成機能112で運用手順の詳細内容を手動で入力することとなる。次に手順部品のパラメータ要素に対し、入力された運用情報からパラメータ要素に対応する値が有る場合は、パラメータ要素に対する候補値を自動で設定する455。パラメータ要素に対応する値が無い、または運用情報とパラメータ要素の関係を抽出できない場合は手動でパラメータ要素を設定する455。なお、運用情報とパラメータ要素の対応付けを検索する方法として、構成要件で定義した構成情報とパラメータ要素の対応付けを利用しても良い。例えば、図5Aでディスク装置用意の部品例を示したが、構成情報であるディスクの管理番号が部品のパラメータ要素と対応しており、図5Bの構成要件で、ノード314が管理番号と対応していることを定義している。構成要件を検索するときに、入力された運用情報の項目から、例えば管理番号の対応付けを行っておき、部品生成時にパラメータ要素の候補値として利用できる。続いて、図10のステップ454にて選択した部品に対し、順序定義DB122上で順序関連性を持つ部品を検索する456。順序関連性は図9で示したとおり示されており、例えば手順部品300のディスク装置用意400を選択するとすれば、それに関連したUSBディスク装置接続401、eSATAディスク装置接続402、バックアップ実行403の手順部品が順序関連部品の候補として提示される。順序関連部品の候補がある場合457でYesは、部品候補を選択し458、当該選択部品に対しパラメータ要素の設定を繰り返す455。関連候補が無い場合457でNoは検索を終了エンドする。<作成した運用手順の例>図12に、図11A、図11B、図11Cで示された運用内容、システム構成情報、運用情報を元に、作成した運用手順の一例464を示す。手順部品を利用した部分は波線で囲った部分466、467、469となる。また、波線枠以外の部分は部品を使わず個別に詳細の運用手順を入力した部分465、468である。なお、部品使用時のパラメータ要素には下線を引いてある。作成した運用手順は、出力フォーマットDBに従って、その出力先である紙や電子端末に応じた形式に変換され、最終的な運用手順書として生成される。<手順検証機能>次に本実施例のシステムで作成された運用手順書に対し、部品の順序関連性を利用した手順検証機能113について説明する。手順作成過程において、部品の順序を変えてしまった、本来入力すべき部品を選択していなかった例えばログインはあるがログアウトが無い、等のミスを、手順部品の順序関連性情報を活用して検出することができる。図13に手順検証機能の処理フローの一例を示す。まず、作成した運用手順書から手順フローを抽出する471。図14に、図12で示した運用手順書から抽出した手順フローの一例を示す。四角形は、部品を利用せずに運用手順の詳細内容を定義した手順項目481、484を、丸は部品を利用した手順項目482、483、485を示す。なお手順フローは、ある手順項目を実行した結果によって異なる手順項目を実施する、といった分岐を持つケースもある。このように抽出された手順フローに対し、使用している手順部品から当該の手順部品に関連する順序関連性情報を順序定義DB122から抽出する472。なお、複数の順序関連性が抽出される可能性もあるが、その場合はシステム構成情報から定義された構成要件に対応した順序関連性のみを抽出することにより、候補を絞り込む。例えば、図11A、図11B、図11Cで示した運用内容、システム構成情報、運用情報が入力され、作成された運用手順で使用されている手順部品から抽出される順序関連性が図9で示すものとした場合、図9の関連性定義ではディスク装置接続部品でインタフェースの違い401及び402により順序の取り方が異なるが、部品の構成要件と入力したシステム構成情報から、USBディスク装置接続を含む順序関連性を抽出できる。次に、作成した運用手順フローと手順部品の順序関連性から抽出された順序定義を比較し、マッチング判定をする473。判定の手法には、様々なものが考えられ、適切なものを採用すれば良い。例えば伸縮マッチング手法の一つであるDPDynamicProgrammingマッチングを適用することで、相互の関連性フローがマッチするかを判定できる。もし、マッチング判定474の結果、マッチしないと判定された場合、ユーザに対し作成した手順のうちマッチしていない部品利用部分を提示475し、修正を促す。マッチしていれば、手順検証を終了する。<修正評価機能>次に、本実施例のシステムにおいて作成された運用手順書に対し、運用対象機器のシステム構成や運用情報が変更した場合に、運用手順書のどの部分が修正対象となるかを評価する修正評価機能114について説明する。図15に、修正評価機能の処理フローの一例を示す。まず、修正内容を反映したシステム構成情報、運用情報を入力する500。次に、修正前に対する変更点差分を検出し、現在の運用手順書が前提としている構成要件において、どの構成要素が変更されているかを検出する501。次に現在の運用手順書で利用されている手順部品に対応した構成要件における構成要素とその内容を、構成要件DB125から、また手順部品のパラメータ要素とその内容を部品パラメータDB124から抽出する502。そして、変更内容が構成要件における構成要素図4A、図4B、図4Cにおける丸で表すノードに当たるかを判定する503。構成要件における構成要素に当たらない場合というのは、パラメータ要素または構成要件の構成情報図4A、図4B、図4Cの構成要件ツリーにおける六角形で表すノードに対応するということである。従って、その場合は手順部品利用における前提となる構成要件の変更ではないため手順部品自体の変更は無く、次に変更内容がパラメータ要素または構成要件の構成情報に該当するかを判定する512。この結果該当する場合は、パラメータ要素または構成要件の構成情報に対応する項目を書き換え、ユーザに対し変更内容を提示して504、修正評価を終了し、該当しない場合は部品の修正が無いことをユーザに通知して513、修正評価を終了する。また、もし変更内容が構成要件における構成要素に対応していた場合は、手順部品利用の前提条件が変わるため、変更される構成要件に対応する手順部品を変更する必要がある。まず、現在の手順部品が、システム構成情報運用情報を変更したとしても構成要件を満たすかを判定する505、506。例えば、図11B、図11Cにおけるシステム構成情報運用情報において、使用ディスク装置の接続インタフェースをUSBからeSATAに変更するとする。まず生成された図12の運用手順500に対し構成要件を構成要件DB125から抽出し、インタフェースの変更に対する構成要件の変化を評価する。その結果、構成要件としてインタフェースの変更に対し影響する手順部品としてディスク装置用意300、USBディスク装置接続320が抽出される。まずディスク装置用意の構成要件310を見ると、インタフェースノード313はUSBノード315かeSATAノード316どちらかを取り得るため、インタフェースをUSBからeSATAへ変更しても構成要件を満たすことがわかる。従ってこの場合は、当該部品がそのまま利用可能なことをユーザに提示すれば良い510。また、もし当該部品そのままでは構成要件を満たせない場合は、同じ運用内容で変更後の構成要件に対応した手順部品を検索する507、508。同じ運用内容を判定する手段としては、同じ運用キーワードを持つことが一例として考えられる。もし候補がある場合、つまり変更内容に対し同じ運用内容である別の部品で構成要件を満たすものがある場合は、それを修正候補として提示する509。例えば前記例で、USBからeSATAへの変更に伴い影響がある手順部品としてUSBディスク装置接続が抽出されたが、同じディスク装置接続にはeSATAディスク装置接続の手順部品が存在する。構成要件DBを検索することで、インタフェースをeSATAに変更したときに、それに対応する部品としてeSATAディスク装置接続を抽出でき、それをユーザに変更候補として提示すれば良い509。もし、変更後の構成要件に対応する部品候補が存在しない場合は、部品自体の修正の必要性をユーザに通知する511。その結果、ユーザは手動で部品を修正するか、新たに部品を作成することになる。以上により、システム構成情報や運用情報が変更した場合の、運用手順に対する修正影響を評価することができる。<画面の例>以上で説明した本実施例のシステムの各機能を実現するための、ユーザインタフェースの一例を説明する。このユーザインタフェースは、先に説明した本実施例のシステムを構成する運用手順設計サーバ101の表示装置157等に表示されるものであるが、それに限定するものでないことは先にも説明した通りであり、種々のシステム構成中の表示部に表示可能である。まず、図16に、運用対象とするシステムの構成情報を入力する画面の例を示す。対象システムの構成情報601の各項目は、図4A、図4B、図4Cで示した構成要件ツリーを利用し、定義できる。例えばサーバ1602は、ツリー挿入ボタン603にて、図4Aのサーバ構成要件ツリーSRV251を選択することで、導入される。導入された構成要件ツリーの各項目は、対象とする項目を選択の上編集ボタン604を押すことで、情報を入力する。構成要件ツリーを用いずに、個別に構成情報の項目を定義する場合は、追加ボタン605にて定義する。次に、図17に本実施例のシステムの運用手順書を編集する画面の一例を示す。手順書の内容はフロー図として、手順の流れの概要が手順フロー621として表示される。フロー図の各項目を追加編集削除することで、運用手順書を作成することができる。このとき、フロー図の各項目に対し、手順部品DB120上に保持されている手順部品を導入することができる。例えば、フロー項目USBディスク装置接続622に対し部品を導入する場合は、当該フロー項目622を選択し、部品導入ボタン623を押す。その結果、部品を選択する画面が呼び出される。図18に本実施例のシステムの部品選択画面の一例を示す。部品選択画面では、部品のリスト651と、選択した部品の手順フロー図652と選択した部品の構成要件情報653を表示する。図10に示した部品検索機能のフロー図に従って、予め入力された運用内容、システム構成情報、運用情報から、対応する部品を提示する。本画面例では、部品のリスト651の表示部にて、該当する部品454における検索結果に対応を太字で表示する方式としている。例えば本例では、操作別に整理した部品リストを示しており、ディスク準備接続の操作に属する部品として、例えばディスク装置用意USBディスク装置接続eSATAディスク装置接続等が登録されている。図11で示された内容を図16の画面例で予め入力したシステム構成情報から、例えばUSBディスク装置接続654は使用可能な部品として検索される452に対応ため、太字で表示されている。これに対し、eSATAディスク装置接続655は前記システム構成情報に対応していないつまりサーバのインタフェースがUSBのみしか持たないため、使用可能な部品として検索されず、細字斜体で表示される。次に、図19に、作成された運用手順書に対し、運用対象機器のシステム構成や運用情報が変更した場合に、運用手順書のどの部分が修正対象となるかを評価し、修正対象を表示する画面の例を示す。図15の修正評価機能の処理フローを説明した際に例示した構成変更の例ディスクの接続インタフェースをUSBからeSATAに変更に対応して、インタフェースの変更に対し影響する手順部品としてディスク装置用意USBディスク装置接続が抽出される。ディスク装置用意の構成要件310を見ると、インタフェースノード313はUSBノード315かeSATAノード316どちらかを取り得るため、インタフェースをUSBからeSATAへ変更しても構成要件を満たすことがわかる。従ってこの場合は、運用手順書の手順フロー670の項目上構成変更の項目が構成要件と一致しますが、構成変更後も条件を満たすため、修正せずにそのまま伝えます671とユーザに提示する図15の510に対応。また、USBディスク装置接続においては、同じディスク装置接続にはeSATAディスク装置接続の手順部品が存在する。構成要件DBを検索することで、インタフェースをeSATAに変更したときに、それに対応する部品としてeSATAディスク装置接続を抽出でき、構成変更が構成要件と一致しないため修正が必要ですが、代替の部品があります。→候補:eSATAディスク装置接続672とユーザに提示する図15の509に対応。なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。また、各実施例の構成の一部について、他の構成の追加削除置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、それぞれの機能を実現するプログラムを実行することによりソフトウェアで実現する場合を例示して説明したが、各機能を実現するプログラム、テーブル、ファイル等の情報はメモリのみならず、ハードディスク、SSDSolidStateDrive等の記録装置、または、ICカード、SDカード、DVD等の記録媒体におくことができるし、必要に応じてネットワーク等を介してダウンロード、インストールすることも可能である。