複数種類の処理主体が連携して提供する複数種類の情報処理サービスを示す情報と、各情報処理サービスの利用者を示す情報とを対応づけて保持する関連保持部と、前記複数種類の処理主体の少なくとも1つにおいて実施されるべき構成変更に関する情報をシステム管理の担当者から受け付ける変更情報受付部と、構成変更の対象となる処理主体が関わる情報処理サービスの利用者に対して、構成変更に関する情報を提示する変更情報提示部と、を備えることを特徴とするシステム管理支援装置。上記特許文献1における運用管理装置の情報提供対象は情報処理システムの開発者や維持管理者であった。そのため、情報処理システムにより提供されるサービスの利用者は、当該システムの構成変更の実施について容易に把握することができなかった。また、情報処理システムの構成変更をサービスの利用者へ通知する場合には、システムの開発者や維持管理者による手作業が必要であり、通知の漏れが発生することもあった。本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムが提供するサービスの利用者の利便性を向上させるための技術を提供することである。上記課題を解決するために、本発明のある態様のシステム管理支援装置は、複数種類の処理主体が連携して提供する複数種類の情報処理サービスを示す情報と、各情報処理サービスの利用者を示す情報とを対応づけて保持する関連保持部と、複数種類の処理主体の少なくとも1つにおいて実施されるべき構成変更に関する情報をシステム管理の担当者から受け付ける変更情報受付部と、構成変更の対象となる処理主体が関わる情報処理サービスの利用者に対して、構成変更に関する情報を提示する変更情報提示部と、を備える。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、情報処理システムが提供するサービスの利用者の利便性を向上させることができる。図1は、実施の形態の運用管理システム100の構成を示す。運用管理システム100は、ITサービス企業例えばSI企業に構築されたコンピュータシステムである。運用管理システム100は、情報処理システム10に対する運用管理サービスを提供し、言い換えれば、ITサービス企業の運用部門による情報処理システム10に対する運用管理業務を支援する。具体的には、情報処理システム10で発生したインシデントや、情報処理システム10が抱える問題、情報処理システム10で実施される構成変更を管理するための処理を実行する情報処理システム10で総称される情報処理システム10a、情報処理システム10b、情報処理システム10c、は、様々な企業の基幹系システムや情報系システムを含む。情報処理システム10は、LANWANインターネット等を含む通信網20を介して種々の情報処理サービスをユーザ端末18へ提供する。情報処理サービスには、例えば、通販サイトを提供する通販サービス言い換えれば、オンラインショッピングサービスや、企業の勤怠管理サービス営業支援サービス等が含まれる。ユーザ端末18で総称されるユーザA端末18a、ユーザB端末18b、ユーザC端末18c、ユーザD端末18dは、情報処理システム10により提供される情報処理サービスの利用者により操作されるPCである。典型的には、通販サービスの利用者は通販サイトを利用する消費者であり、勤怠管理サービスや営業支援サービスの利用者は企業の社員である。運用管理システム100は、監視装置12と、運用担当者端末14と、運用管理支援装置16を含む。運用管理支援装置16は、情報処理システム10に関するインシデント問題構成変更を管理する情報処理装置である。本実施の形態の説明では、運用管理支援装置16の構成変更に関わる構成を図3に関連して後述する。また運用管理支援装置16は、通信網20を介してユーザ端末18と接続される。監視装置12は、複数の情報処理システム10の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム10の動作状態が所定の異常状態になった場合、監視装置12は、新たなインシデントを起票してそのインシデントの情報を運用管理支援装置16へ送信する。また監視装置12は、インシデントを起票済の情報処理システム10の動作状態が変化した場合、そのインシデントの更新情報を運用管理支援装置16へ送信する。運用担当者端末14は、運用管理業務を遂行すべき担当者以下、運用担当者とも呼ぶ。により操作される情報処理端末である。運用担当者端末14は、情報処理システム10に関するインシデントや問題、構成変更の情報例えば起票情報や更新情報の入力を運用担当者から受け付け、それらの情報を運用管理支援装置16へ送信する。典型的には、インシデントや問題を解決するために、運用担当者は情報処理システム10の構成を変更することを決定し、構成変更の起票情報を入力する。図2は、図1の情報処理システム10を詳細に示す。情報処理システム10は、仮想マシン群40に分類される処理主体DBサーバ、ウェブサーバAおよびBと、ブレード群42に分類される処理主体ブレードA~C、NWネットワークスイッチ群44に分類される処理主体スイッチAおよびB、ストレージ群46に分類される処理主体ストレージAおよびBを含む。個々の処理主体は、ハードウェア、もしくはハードウェアおよびソフトウェアの連携により実現されるものであり、情報処理システム10の構成要素であると言える。例えば、ブレードはハードウェアとしてのコンピュータを意味し、典型的にはサーバマシンである。また仮想マシンは、ブレードのOS上に起動されたサーバプロセスであると言える。また、図2に示す複数種類の処理主体が連携することにより情報処理サービス以下、単にサービスとも呼ぶ。が実現される。例えば通販サービスは、通販サービス関連装置群48に含まれる処理主体の連携により実現されることとする。図2には不図示であるが、例えば勤怠管理サービスは、図2の複数種類の処理主体の別の組み合わせにより実現されてもよい。また実施の形態の構成変更は、例えば、ブレードやスイッチ、ストレージ等のハードウェアの置き換えや増設、ソフトウェアにおける各種設定値の変更やバージョンアップ等を含む。図3は、図1の運用管理支援装置16の機能構成を示すブロック図である。運用管理支援装置16は、データ保持部50とデータ処理部66を備える。データ保持部50は、各種の情報を保持する記憶領域であり、メモリ等により実現される。データ処理部66は、各種のデータ処理を実行し、例えばCPUがコンピュータプログラムを実行することにより実現される。データ保持部50は、変更情報保持部52と、サービス管理マスタ54と、構成管理マスタ56と、ユーザ管理マスタ58と、関連管理マスタ60と、カレンダー保持部62と、通知予定保持部64を含む。データ処理部66は、変更情報受付部68と、通知対象特定部70と、カレンダー更新部72と、変更情報通知部74と、カレンダー提供部76を含む。なお、インシデント問題構成変更を管理するための他の機能、例えば構成変更のステータスを管理する機能等は公知であるため、以下の説明を省略する。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図3の各機能ブロックは、システム管理支援プログラムとして記録媒体に格納され、情報処理システム10のストレージへインストールされてもよい。そして、システム管理支援プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてCPUにより実行されてもよい。変更情報保持部52は、情報処理システム10における各処理主体に対して実施されるべき構成変更の内容を示す情報以下、構成変更情報とも呼ぶ。を保持する。例えば図2のストレージAの構成変更情報として、ストレージAに対してハードディスクを増設する予定を示す情報を保持する。構成変更情報は、少なくとも構成変更対象の処理主体を示す情報と、構成変更を実施する予定日を含む。なお図3には不図示の変更管理部は、変更情報保持部52に格納された構成変更情報にしたがって、一般的な構成変更の管理処理、例えばステータス管理処理や、運用部門の管理者への通知処理等を実行する。サービス管理マスタ54は、情報処理システム10が提供するサービスに関して予め定められた属性情報以下、サービス属性情報とも呼ぶ。を保持する。図4はサービス属性情報の例を示す。サービス属性情報は、サービスのIDと、サービスの名称と、サービスに関わる処理主体が構成変更される場合に、その旨を利用者へ通知するタイミングを示す変更通知タイミング、サービスの開始日時、等の情報を含む。図3に戻り、構成管理マスタ56は、情報処理システム10を構成する各処理主体に関して予め定められた属性情報以下、構成情報とも呼ぶ。を保持する。図5は構成情報の例を示す。構成情報は、処理主体のIDである構成情報IDと、処理主体の名称、等を含む。図5には不図示であるが、構成情報は、処理主体を構成するハードウェアの種類やスペック、ソフトウェアにおける各種設定値をさらに含んでもよい。図3に戻り、ユーザ管理マスタ58は、サービスを利用するユーザ以下、サービス利用者と呼ぶ。に関して予め定められた属性情報を保持する。図6は、サービス利用者の属性情報の例を示す。サービス利用者の属性情報は、ユーザIDと、ユーザ名と、メールアドレス、等の情報を含む。図3に戻り、関連管理マスタ60は、サービス属性情報と、構成情報と、サービス利用者の属性情報との間で予め定められた関連づけを示す情報以下、関連情報とも呼ぶ。を保持する。図7は関連情報の例を示す。構成管理とサービス管理との関連づけは、情報処理システム10の処理主体と、その処理主体が関わるサービス、言い換えれば、その処理主体を構成要素の1つとして実現されるサービスの対応関係を示す。例えばレコード80は、構成情報のID0006のストレージAが、サービス属性情報のID0001の通販サービスに関わることを示している。また、サービス管理とユーザ管理との関連づけは、サービスと、そのサービスの利用者の対応関係を示す。例えばレコード82は、サービス属性情報のID0001の通販サービスに対して、サービス利用者の属性情報におけるID0001のヤマダタロウが利用者であることを示している。なおサービス管理マスタ54、構成管理マスタ56、ユーザ管理マスタ58、関連管理マスタ60に格納されたデータを総称する場合、マスタデータと呼ぶこととする。図3に戻り、カレンダー保持部62は、情報処理システム10が提供する1以上のサービスそれぞれについて、1ヶ月等の所定期間における各サービスの提供状況を示すカレンダー情報を保持する。例えば、通販サービスのカレンダー情報、勤怠管理サービスのカレンダー情報を保持する。このカレンダー情報には、サービスの営業日、言い換えれば情報処理システム10がサービスを提供する日付を含み、またサービスのメンテナンスが行われる日付を含む。企業の勤怠管理サービスの場合、サービスの営業日は、企業の営業日と同じであってもよい。図8はカレンダー情報を模式的に示す。同図は、運用管理支援装置16から提供されたカレンダー情報が表示された画面イメージであるとも言える。同図は、情報処理システム10が提供する勤怠管理サービスについて、6月8日にディスク追加のメンテナンスがあり、6月29日にウェブサーバのバージョンアップがあり、それぞれのメンテナンス中はサービスを利用できないことを示している。図8には不図示であるが、カレンダー情報では、サービスの営業日と非営業日とが区別して記録される。例えば、図8において勤怠管理サービスの営業日と非営業日とが異なる態様で表示されるようカレンダー情報が設定されてもよい。図3に戻り、通知予定保持部64は、サービス利用者に対してサービスに関わる構成変更を通知する予定を示す情報を保持する。具体的には、構成変更の影響を受けるサービスのIDと、そのサービスの利用者のユーザIDと、サービスに関わる構成変更予定日と、サービスの利用者に対して構成変更を通知すべき日付を対応づけて保持する。変更情報受付部68は、情報処理システム10の構成変更情報として、情報処理システム10の処理主体の構成変更に関する起票情報や更新情報を運用担当者端末14から受け付ける。そして、構成変更の起票情報を新規に変更情報受付部68へ格納し、また構成変更の更新情報にもとづいて変更情報受付部68に格納済みの構成変更の情報を更新する。既述したように、構成変更情報には少なくとも、構成変更対象の処理主体を示す情報と、構成変更予定日とが含まれる。通知対象特定部70は、データ保持部50のマスタデータにしたがって、構成変更対象の処理主体に関わるサービス以下、構成変更関連サービスとも呼ぶ。と、その利用者以下、通知対象ユーザとも呼ぶ。を特定する。具体的には、構成管理マスタ56の構成情報を参照して構成変更対象の処理主体のIDを特定し、関連管理マスタ60の関連情報を参照して構成変更対象の処理主体と対応づけられた1以上のサービスをそれぞれ構成変更関連サービスとして特定する。また関連情報において構成変更関連サービスと対応づけられた1以上のユーザをそれぞれ通知対象ユーザとして特定する。複数の構成変更関連サービスを特定した場合、各サービスにおける通知対象ユーザを特定する。また通知対象特定部70は、サービス管理マスタ54を参照して、構成変更関連サービスにおいて定められた変更通知タイミングを特定する。そして、カレンダー保持部62が保持する構成変更関連サービスのカレンダー情報と、変更通知タイミングと、構成変更予定日とにしたがって、通知対象ユーザに対する構成変更の通知日を決定する。例えば勤怠管理サービスの場合、勤怠管理サービスのカレンダー情報で定められた構成変更予定日から5営業日前の日付を構成変更の通知日として決定する。通知対象特定部70は、構成変更関連サービスのIDと、通知対象ユーザのIDと、構成変更予定日と、構成変更の通知日とを対応づけた通知予定情報を通知予定保持部64へ格納する。複数の構成変更関連サービスを特定した場合、各サービスの通知予定情報を通知予定保持部64へ格納する。カレンダー更新部72は、通知対象特定部70と同様に構成変更関連サービスを特定する。そして、カレンダー保持部62が保持する構成変更関連サービスのカレンダー情報における構成変更予定日のスケジュールとして構成変更を示す情報を記録する。例えば、勤怠管理サービスに関わる処理主体において6月8日にディスク追加のメンテナンスがなされる場合、図8で示したように、6月8日と対応づけてメンテナンスディスク追加の情報を記録する。複数の構成変更関連サービスを特定した場合には、各サービスのカレンダー情報に対して構成変更を示す情報をそれぞれ記録する。変更情報通知部74は、通知予定保持部64に保持された通知予定情報のうち構成変更の通知日に至った、言い換えれば、構成変更の通知日=現在日付となった通知予定情報を特定する。そして、その通知予定情報が示す通知対象ユーザについてユーザ管理マスタ58に保持されたメールアドレスを宛先として、その通知予定情報が示す構成変更関連サービスについて構成変更予定日を記載した電子メールを送信する。例えば、勤怠管理サービスに関わる処理主体において6月8日にディスク追加のメンテナンスがなされるとする。この場合、変更情報通知部74は、6月8日の5営業日前に至ったことを検出すると、6月8日にメンテナンスが行われることを記載した電子メールを通知対象ユーザのユーザ端末18へ送信する。カレンダー提供部76は、特定のサービスを指定したカレンダー提供要求をユーザ端末18から受け付ける。そして、要求元であるユーザ端末18に対して、指定されたサービスのカレンダー情報を送信する。これにより、図8で示したように、ユーザ端末18においてカレンダー情報を表示させる。以上の構成による動作を以下説明する。変更情報受付部68は、情報処理システム10に対する構成変更情報を運用担当者端末14から受け付け、変更管理のために変更情報保持部52へ格納する。構成変更情報が受け付けられた場合、通知対象特定部70は、構成変更関連サービスと通知対象ユーザを特定し、構成変更関連サービスの営業日を示すカレンダー情報にしたがって通知対象ユーザへの通知予定日を決定する。例えば、図2の情報処理システム10のストレージAに対して6月8日にディスク追加がなされる場合、通知対象特定部70は、図7の関連情報のレコード80にしたがって構成変更関連サービスを通販サービスと特定する。また、図7の関連情報のレコード82にしたがって通知対象ユーザとしてヤマダタロウを特定する。また、通販サービスの属性情報において定められた変更通知タイミングにしたがって、6月8日の5営業日前を通知予定日として決定する。通知対象特定部70は、通知対象ユーザへの通知予定日を示す通知予定情報を通知予定保持部64へ格納する。それとともにカレンダー更新部72は、構成変更関連サービスのカレンダー情報へ構成変更予定日を記録する。変更情報通知部74は、通知予定日に到達した通知予定情報を特定し、その通知予定情報に記録された通知対象ユーザの端末へ、構成変更関連サービスのメンテナンスが行われること、および構成変更予定日を記載した電子メールを送信する。カレンダー提供部76は、情報処理システム10で提供されるサービス個々のカレンダー情報をサービス利用者の端末へ送信する。実施の形態の運用管理支援装置16によれば、情報処理システム10を構成する処理主体において構成変更がなされる場合に、構成変更関連サービスの利用者に対して構成変更の情報を自動で事前通知する。構成変更関連サービスの利用者は、構成変更の予定、例えばメンテナンスによりサービスを利用できない日程を予め把握することができる。また、情報処理システム10の運用担当者が手動でサービス利用者へ通知する必要がなく、メールの誤送信や通知漏れ等の人為的なミスの発生を抑制することができる。また、サービス利用者に対する構成変更の通知日は、構成変更関連サービスの営業日を単位として決定するため、構成変更の実施を利用者に確実に把握させやすくなる。例えば、勤怠管理サービスのメンテナンスが連休明けに行われる場合、営業日を考慮せずに暦の日付の単位で通知日を決定すると、連休中は利用者が通知を確認できず、構成変更の実施を事前に把握できないことがあり得る。営業日を考慮して通知日を決定することで、構成変更の実施までに比較的余裕を持って構成変更の旨をユーザへ通知することができる。以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。上記実施の形態においてカレンダー保持部62は、情報処理サービスごとの営業日を示すカレンダー情報を保持することとした。変形例では、企業の営業日を示すカレンダー情報を保持してもよく、複数の情報処理サービス例えば同一企業の勤怠管理サービスと営業支援サービスに対する共通のカレンダー情報を保持してもよい。上記実施の形態においては、構成変更の通知日を決定するための変更通知タイミングが、サービスの属性として定められていることとした。変形例では、変更通知タイミングが、ユーザの属性としてユーザごとに任意の値が定められてもよい。通知対象特定部70は、複数の通知対象ユーザを特定した場合、各ユーザの変更通知タイミングに応じて、各ユーザへの通知日を決定してもよく、各ユーザへの通知日をそれぞれ通知予定保持部64へ記録してもよい。上記実施の形態においては言及していないが、変更情報受付部68は構成変更の更新情報として、構成変更予定日を変更することを示す情報を受け付けてもよい。この場合、通知対象特定部70は、通知予定保持部64に対して構成変更の管理IDをさらに含む通知予告情報を格納する。通知対象特定部70は、通知予定保持部64に対して新たな通知予告情報を記録する際に同一の管理IDを含む通知予告情報が格納済みの場合、その格納済みの通知予告情報が含む通知予定日を、変更後の構成変更予定日にもとづいて算出した通知予定日で上書き更新する。これにより変更後の構成変更予定日にもとづいて算出した通知予定日にメールが送信されることになる。通知対象特定部70は、通知予定保持部64に対して新たな通知予告を記録する際に同一の管理IDを含む通知予告が格納されていなければ、その新たな通知予告をそのまま格納する。同様に、カレンダー更新部72は、カレンダー保持部62のカレンダー情報に対して構成変更情報を記録する場合、構成変更の管理IDもあわせて記録する。カレンダー更新部72は、カレンダー情報に対して新たな構成変更情報を記録する際に同一の管理IDを含む構成変更情報が格納済みの場合、その格納済みの構成変更情報を削除して、新たな構成変更情報を、変更後の構成変更予定日と対応づけて記録する。カレンダー更新部72は、カレンダー情報に対して新たな構成変更情報を記録する際に同一の管理IDを含む構成変更情報が記録されていなければそのまま記録する。この変形例によれば、情報処理システム10の構成変更の予定日が変更された場合でも、メール通知とカレンダー表示の両方で対応することができる。上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。