JP2009093569A - 業務サービス利用システム、業務サービス実行システム、業務サービス利用方法およびプログラム、並びに業務サービス実行方法およびプログラム - Google Patents

業務サービス利用システム、業務サービス実行システム、業務サービス利用方法およびプログラム、並びに業務サービス実行方法およびプログラム Download PDF

Info

Publication number
JP2009093569A
JP2009093569A JP2007265897A JP2007265897A JP2009093569A JP 2009093569 A JP2009093569 A JP 2009093569A JP 2007265897 A JP2007265897 A JP 2007265897A JP 2007265897 A JP2007265897 A JP 2007265897A JP 2009093569 A JP2009093569 A JP 2009093569A
Authority
JP
Japan
Prior art keywords
business service
business
data
service providing
providing device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007265897A
Other languages
English (en)
Other versions
JP4863959B2 (ja
Inventor
Satoshi Yashiro
聡 屋代
Chiaki Kato
千昭 加藤
Daisuke Miyamoto
大輔 宮本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007265897A priority Critical patent/JP4863959B2/ja
Publication of JP2009093569A publication Critical patent/JP2009093569A/ja
Application granted granted Critical
Publication of JP4863959B2 publication Critical patent/JP4863959B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】ＳａａＳ環境からＳＩ環境へ変更する場合、ＳａａＳ形態で利用を始めた業務サービスにおいて、埋没コストや機会損失の発生を軽減する。
【解決手段】業務サービスをＳａａＳ事業者環境（Ａ社（１０１））からＳＩ形態の環境（Ｂ市（１０２））に移行する場合、Ｂ市（１０２）に業務サービスのアドレスを記録するサービスアドレスリスト（３４３）を設け、業務サービスの移行に合わせてサービスアドレスリスト（３４３）のアドレスを更新する。また、Ａ社（１０１）に蓄積された業務データも移行する場合、Ａ社（１０１）及びＢ市（１０２）に業務データのアドレスを記録するデータアドレスリスト（３１４、３３４）を設け、業務データの移行に合わせて双方のデータアドレスリスト（３１４、３３４）のアドレスを更新する。それらの更新においては、アドレスが論理的に同一になるようにアクセス方法を変更する。
【選択図】図１１

Description

本発明は、ネットワークを介してアプリケーションを用いた業務サービスを提供または利用するシステムの技術に関し、特に、業務サービスを提供するシステムをプロバイダ環境および利用者環境の双方に設置する形態において、業務サービスの利用者が業務サービスを提供するシステムの設置場所を意識せずに業務サービスを利用可能にする技術、プロバイダ環境および利用者環境の双方に任意の割合で業務サービスを移行可能とする技術、ならびに業務サービスの移行割合変更を行う適切なタイミングを把握する技術に関する。
近年、インターネットやWeb技術の発展により、アプリケーションを用いた業務サービスを提供するシステムを利用者環境に設置せずに、プロバイダ環境に設置する形態の利用が拡がっている。従来このような形態は、アプリケーション・サービス・プロバイダ（ＡＳＰ：Application Service Provider）と呼ばれていたが（例えば、特許文献１参照。）、近年では「ＳａａＳ」（Software as a Service）と呼ばれることも多い。ＡＳＰとＳａａＳの違いについては様々な解釈があるが、アプリケーションや業務サービスを提供するシステムを利用者環境に設置しないという特徴は同じである。そこで、ここではＡＳＰもＳａａＳも含めて「ＳａａＳ」と呼び、（１）ＳａａＳによる業務サービスの提供・利用形態を「ＳａａＳ形態」と呼び、（２）利用者環境に業務サービス提供システムを構築する形態を「ＳＩ（System Integration）形態」と呼ぶ。また、ＳａａＳを提供する者を「ＳａａＳ事業者」、ＳａａＳを利用する者を「ＳａａＳ利用者」、利用者環境にシステムを構築する者を「ＳＩ事業者」、ＳＩを利用する者を「ＳＩ利用者」と呼ぶ。なお、ＳＩ形態とＳａａＳ形態とを比較した場合、一般に利用規模が小さい場合や利用期間が短い場合はＳａａＳ形態がコスト面で有利であり、逆に規模が大きい場合や利用期間が長い場合はＳＩ形態がコスト面で有利であると言われている。
特開２００２−１６３２３２号公報
組織が新たなシステムを導入する場合、小規模ではじめることが多く、またどのくらい長期に利用するか不確実であることが多い。そのため、まずはＳａａＳ形態で利用を始めることは十分に合理的である。一方、ＳａａＳ形態で利用を始めた業務サービスが組織の実態に即したものであれば、次第に利用規模が大きくなり利用期間も延びてくる可能性が高く、いずれはＳａａＳ形態よりもＳＩ形態を採用した方がコスト面で有利になる。
上記の背景から、利用規模の増大、利用期間の長期化を見込み、はじめからＳＩ形態を採用する方法も考えられる。しかし、利用開始当初に規模の増大や期間の長期化を正確に予想することは難しい。そのため、せっかく構築したシステムが無駄になるといったリスクを考慮すると、ＳＩ形態で利用を開始することに抵抗を感じるケースは多い。
一方、ＳａａＳ形態で利用を始めた業務サービスを、利用規模が大きくなり、利用期間が長期化してきたところでＳＩ形態に変更しようとした場合、ＳＩ形態に変更しようとするＳａａＳ利用者がＳａａＳ事業者からデータを買い取ることができないという場合がある。この場合、ＳａａＳ事業者環境に蓄積されたデータ等、それまでＳａａＳ形態で利用していた資産を捨てなければならないという埋没コストが発生し、この埋没コスト発生の恐れからＳＩ形態への変更を進めにくいという現状がある。また、ＳａａＳ事業者からデータを買い取ることができて埋没コストを発生させずにＳＩ形態に変更できた場合でも、ＳａａＳ事業者環境にあるデータを利用者環境に移行し、利用者が業務サービスの接続先の変更を行う間は、実質的な業務サービスの利用および提供を停止しなければならない。そのため、その停止期間に利益を上げる機会を失うという機会損失が発生し、この機会損失の発生の恐れからＳＩ形態への変更を進めにくいという現状がある。
本発明は上記事情を鑑みたものであり、本発明の目的は、ＳａａＳ環境からＳＩ環境へ変更する場合、ＳａａＳ形態で利用を始めた業務サービスにおいて、ＳａａＳ事業者環境に蓄積したデータを捨てることによる埋没コストや、その変更により発生しうる機会損失の発生を軽減し、ＳａａＳ環境からＳＩ環境への変更を支援する手段の提供にある。
また、ＳａａＳ形態からＳＩ形態に変更するためには、業務サービスや必要なデータの移行等、やはりそれなりの経済的、時間的負担が生じる。そして、その変更を行っている間であっても、利用者による業務サービスの利用になるべく支障をきたさないように移行を調整する必要がある。そこで、本発明のさらなる目的は、上記手段を用いてＳａａＳ形態からＳＩ形態への変更を行うべき契機や、業務サービスや必要なデータの移行の把握を容易にする手段の提供にある。
上記手段として、以下のものを採り上げる。
（１）ＳａａＳ利用者環境にＳＩ形態を構築して、業務サービスをＳａａＳ事業者環境からＳＩ形態の環境に移行する場合、ＳＩ形態の環境（元のＳａａＳ利用者環境）に業務サービスのアドレスを記録するリスト（サービスアドレスリスト）を設け、業務サービスの移行に合わせてサービスアドレスリストに記録されるアドレスを更新する。すなわち、サービスアドレスリストにおいて、まだＳＩ形態の環境に移行せず、ＳａａＳ事業者環境にある業務サービスのアドレスは、ＳａａＳ事業者環境にあるように示すアドレスのままにしておき、ＳＩ形態の環境に移行した業務サービスのアドレスはＳＩ形態の環境にあるように示すアドレスに書き換える。
また、ＳａａＳ事業者環境に蓄積され、業務サービスを実行するときに用いるデータ（業務データ）をＳａａＳ事業者環境からＳＩ形態の環境に移行する場合、ＳａａＳ事業者環境およびＳＩ形態の環境（元のＳａａＳ利用者環境）に業務データのアドレスを記録するリスト（データアドレスリスト）を設け、業務データの移行に合わせて双方のデータアドレスリストに記録されるアドレスを更新する。すなわち、データアドレスリストにおいて、まだＳＩ形態の環境に移行せず、ＳａａＳ事業者環境にある業務データのアドレスは、ＳａａＳ事業者環境にあるように示すアドレスのままにしておき、ＳＩ形態の環境に移行した業務データのアドレスはＳＩ形態の環境にあるように示すアドレスに書き換える。
ただし、ＳａａＳ事業者環境とＳＩ形態の環境はネットワークを介して接続されているため、業務サービスや業務データの移行により業務サービスや業務データへのアクセス方法が変更してしまう。よって、上記アドレスの書き換えにおいては、アクセス方法の変更に伴い、アドレスの解決の方法も合わせて変更する点に留意する。詳細は後記する。
（２）ＳａａＳ形態からＳＩ形態への変更の契機として、ＳａａＳ形態で事業を行う場合の損益とＳＩ形態で事業を行う場合の損益とを比較して、双方の損益から損益分岐点を求める。その損益分岐点を形態変更の契機として使用する。詳細は後記する。
（３）ＳａａＳ利用者環境に構築したＳＩ形態の稼動状況等を考慮して、業務サービスや業務データの移行の移行率および移行時期を調整する。詳細は後記する。
本発明により、ＳａａＳ形態で利用を始めた業務サービスを、ＳａａＳ事業者環境に蓄積したデータを捨てることによる埋没コストや、ＳａａＳ環境からＳＩ環境へ変更する場合に発生しうる機会損失の発生を軽減し、ＳａａＳ環境からＳＩ環境への変更を支援することができる。また、ＳａａＳ形態からＳＩ形態への変更を行うべき契機や、業務サービスや必要なデータの移行の把握を容易にすることができる。
以下、本発明の業務サービス実行システム（以下、単に、「システム」という。）を実施するための最良の形態（以下、「実施の形態」という。）について説明する。説明する際には、本明細書と同時に提出する図面を適宜参照する。
１．概略；
本実施の形態として、業務サービスをＳａａＳ形態で提供するＡ社（ＳａａＳ事業者）と、一部門でＡ社の業務サービスを利用するＢ市（ＳａａＳ利用者）があり、Ｂ市の他部門でもＡ社の業務サービスの利用が増えてきた際に、Ａ社の関連会社でＳＩ事業を手がけるＣ社（ＳＩ事業者）がＢ市に対しＳＩ形態の構築を行いＳａａＳ形態からＳＩ形態に変更する場合を一例として採り上げ、本発明が適用される状況の概略について説明する。
まず、図１と図２を用いて、ＳａａＳ事業者であるＡ社と、ＳａａＳ利用者であるＢ市と、ＳＩ事業者であるＣ社との関係を、システムのハードウェアの構成の説明も含めて説明し、その関係における業務サービスの提供または利用に関するビジネスの大きな流れを説明する。
１．１．Ａ社、Ｂ市、Ｃ社の関係；
図１は、ＳａａＳ事業者Ａ社と、ＳａａＳ利用者Ｂ市と、ＳＩ事業者Ｃ社との関係を示した概念図である。Ａ社（１０１）とＢ市（１０２）の関係は、Ａ社がＢ市に対してＳａａＳ形態により業務サービスを提供するという（１）ＳａａＳの提供と、Ｂ市がＡ社の業務サービスを利用するという（２）ＳａａＳの利用、という関係となる。また、Ａ社とＣ社の関係は、Ａ社がＣ社に対してＡ社の経営状況を示す経営情報を提供するという（３）経営情報の提供と、Ｃ社がＡ社の経営情報を基にしてＡ社の事業に関する損益を損益情報として取り扱い監視するという（４）損益情報のモニタリング、という関係となる。また、Ｂ市とＣ社の関係は、Ｂ市がＣ社に対しＳＩ形態の構築を委託するという（５）ＳＩの委託と、Ｃ社がＢ市に対してＳＩ形態の構築をし、その保守を行うという（６）ＳＩの提供、という関係になる。
１．２．システムのハードウェアの構成；
Ａ社（１０１）は、ネットワーク（３０１）に接続した業務サーバＡ（１１１）を所有している。業務サーバＡ（１１１）は、例えば、キーボードやマウス等で実装された入力部１１１ａ、ＣＰＵ（Central Processing Unit：中央制御装置）等で実装された制御部１１１ｂ、読み書きされるデータを展開するための記憶領域を確保するＲＡＭ(Random Access Memory)や外部記憶装置としてのＨＤＤ（Hard Disk Drive）等で実装された記憶部１１１ｃおよびディスプレイやプリンタ等で実装された出力部１１１ｄといったハードウェア資源を備えた、一般的なコンピュータである。そして、制御部１１１ｂは、（１）ＳａａＳの提供や（３）経営情報の提供等に関する情報処理を実行するためのプログラムを格納したＲＯＭ（Read Only Memory）等の業務サーバＡ（１１１）用の記録媒体から、そのプログラムを読み出す。
Ｂ市（１０２）は、ネットワーク（３０１）に接続したプロキシサーバ（１１２）とプロキシサーバ（１１２）に接続した（一または二以上の）業務クライアント（３４１）とを所有している。なお、本実施の形態では、ＳａａＳ利用者であるＢ市（１０２）が所有する、プロキシサーバ（１１２）、業務クライアント（３４１）から構成される情報処理システムを「ＳａａＳ利用者システム」（ＳａａＳ形態における業務サービス利用システムに相当）と呼ぶ。
プロキシサーバ（１１２）は、例えば、キーボードやマウス等で実装された入力部１１２ａ、ＣＰＵ等で実装された制御部１１２ｂ、読み書きされるデータを展開するための記憶領域を確保するＲＡＭや外部記憶装置としてのＨＤＤ等で実装された記憶部１１２ｃおよびディスプレイやプリンタ等で実装された出力部１１２ｄといったハードウェア資源を備えた、業務クライアント（３４１）の代理で要求や応答する一般的なコンピュータである。そして、制御部１１２ｂは、（２）ＳａａＳの利用や（５）ＳＩの委託によりＢ市（１０２）内に構築されるＳＩ形態において行われる情報処理等に関する情報処理を実行するためのプログラムを格納したＲＯＭ等のプロキシサーバ（１１２）用の記録媒体から、そのプログラムを読み出す。
また、業務クライアント（３４１）は、例えば、キーボードやマウス等で実装された入力部３４１ａ、ＣＰＵ等で実装された制御部３４１ｂ、読み書きされるデータを展開するための記憶領域を確保するＲＡＭや外部記憶装置としてのＨＤＤ等で実装された記憶部３４１ｃおよびディスプレイやプリンタ等で実装された出力部３４１ｄといったハードウェア資源を備えた、一般的なコンピュータである。そして、制御部３４１ｂは、業務サービスを利用するための情報処理を実行するためのプログラムを格納したＲＯＭ等の業務クライアント（３４１）用の記録媒体から、そのプログラムを読み出す。
Ｃ社（１０３）は、ネットワーク（３０１）に接続した業務サーバＣ（１１３）を所有している。業務サーバＣ（１１３）は、例えば、キーボードやマウス等で実装された入力部１１３ａ、ＣＰＵ等で実装された制御部１１３ｂ、読み書きされるデータを展開するための記憶領域を確保するＲＡＭや外部記憶装置としてのＨＤＤ等で実装された記憶部１１３ｃおよびディスプレイやプリンタ等で実装された出力部１１３ｄといったハードウェア資源を備えた、一般的なコンピュータである。そして、制御部１１３ｂは、（４）損益情報のモニタリングや（６）ＳＩの提供によりＢ市（１０２）内に構築されるＳＩ形態において行われる情報処理等に関する情報処理を実行するためのプログラムを格納したＲＯＭ等の業務サーバＣ（１１３）用の記録媒体から、そのプログラムを読み出す。
もし、Ｂ市（１０２）がＳａａＳ形態からＳＩ形態に変更する場合には、２点鎖線で示すように、Ｂ市（１０２）は、ネットワーク（３０１）およびプロキシサーバ（１１２）に接続した業務サーバＢ（１１４）を所有することになる。業務サーバＢ（１１４）は、例えば、キーボードやマウス等で実装された入力部１１４ａ、ＣＰＵ等で実装された制御部１１４ｂ、読み書きされるデータを展開するための記憶領域を確保するＲＡＭや外部記憶装置としてのＨＤＤ等で実装された記憶部１１４ｃおよびディスプレイやプリンタ等で実装された出力部１１４ｄといったハードウェア資源を備えた、一般的なコンピュータである。そして、制御部１１４ｂは、ＳＩ形態により業務サービスを提供するための情報処理を実行するためのプログラムを格納したＲＯＭ等の業務サーバＢ（１１４）用の記録媒体から、そのプログラムを読み出す。なお、本実施の形態では、ＳＩ形態に変更してＳＩ利用者となったＢ市（１０２）が所有することになる、プロキシサーバ（１１２）、業務クライアント（３４１）および業務サーバＢ（１１４）から構成される情報処理システムを「ＳＩ利用者システム」（ＳＩ形態における業務サービス利用システムに相当）と呼ぶ。
１．３．業務サービスの提供または利用に関するビジネスの大きな流れについて；
図２は、Ａ社、Ｂ市、Ｃ社の関係を時間軸に沿って示した概念図である。Ａ社（１０１）はＢ市（１０２）にＳａａＳを提供し（ステップＳ２０１、図１（１）参照）、一方のＢ市（１０２）はＡ社（１０１）からＳａａＳを利用する（ステップＳ２０２、図１（２）参照）。Ｂ市（１０２）がＡ社（１０１）からＳａａＳの提供を受けている間、Ｃ社（１０３）はＡ社（１０１）の損益情報をモニタリングし（ステップＳ２０３、図１（４）参照）、Ｂ市（１０２）の利用状況からＳａａＳ形態とＳＩ形態のどちらがＢ市にとって低コストであるかという損益に関する分析をする。
分析の結果、ＳａａＳ形態よりもＳＩ形態の方がＢ市（１０２）にとって低コストであることが分かると、Ｃ社（１０３）はＡ社（１０１）に対してＳＩ形態への変更を勧めるように形態変更提案を行う（ステップＳ２０４）。Ｂ市（１０２）にとってＳａａＳ形態よりもＳＩ形態の方が低コストであり、Ｂ市（１０２）が移行したことにより空いたキャパシティで新規顧客を受け入れた方が、Ｂ市（１０２）の利用規模が増大することによる追加投資のリスクを回避できるとＡ社（１０１）が判断した場合、Ａ社（１０１）はＢ市（１０２）に対して形態変更の提案を行う（ステップＳ２０５）。Ｂ市（１０２）はＳａａＳ形態からＳＩ形態に変更した方が低コストであると判断した場合、Ｃ社（１０３）とＳＩ形態の構築を委託して、Ｂ市（１０２）がＳＩによる業務サービスを実施するという契約（ＳＩ契約）を結び（ステップＳ２０６、図１（５）参照）、Ｃ社（１０３）はＢ市（１０２）に対してＳＩ形態を構築する（ＳＩ実施）（ステップＳ２０７）。
ＳＩ実施後、Ａ社（１０１）が提供する業務サービスと業務データの一部をＢ市（１０２）に移行し（ステップＳ２０８）、Ｃ社（１０３）は、Ａ社（１０１）とＢ市（１０２）双方の稼働状況をモニタリングする（ステップＳ２０９）。稼働状況のモニタリングの結果、移行がうまくいっていることが分かり、業務サービスと業務データを更に移行させてもよいことが分かると、Ｃ社（１０３）はＡ社（１０１）とＢ市（１０２）に対して移行率の調整を行う（ステップＳ２１０）。移行率の調整を受けたＡ社（１０１）とＢ市（１０２）は、さらに業務サービスと業務データをＡ社（１０１）からＢ市（１０２）へ移行させる（ステップＳ２１１）。この稼働状況のモニタリング（ステップＳ２０９）から業務サービスと業務データの移行（ステップＳ２１１）までのステップを、すべての業務サービスと業務データがＡ社（１０１）からＢ市（１０２）へ移行されるまで繰り返し行う。
２．ＳａａＳ形態における業務サービスの提供および利用について；
次に、図３から図７を用いて、ＳａａＳ事業者Ａ社とＳａａＳ利用者Ｂ市との間で、業務サービスの提供および利用がどのように行われるかを示す。Ａ社（１０１）からＢ市（１０２）へのＳａａＳの提供（ステップＳ２０１）から、Ａ社（１０１）からＢ市（１０２）への形態変更提案（ステップＳ２０５）までに行われる情報処理について説明する。
２．１．システムの機能構成（形態変更前）；
図３は、Ｃ社によるＳＩ実施がされる前の、Ａ社、Ｂ市、Ｃ社に設置されるシステムの機能構成を示した図である。Ａ社（１０１）の業務サーバＡ（１１１）と、Ｂ市（１０２）のプロキシサーバ（１１２）と、Ｃ社（１０１）の業務サーバＣ（１１３）との間は、インターネット等のネットワーク（３０１）で接続されている。
Ａ社（１０１）の業務サーバＡ（１１１）は、業務サービス提供部（３１１）、データ連携部（３１２）、業務データ（３１３）、データアドレスリスト（３１４）、ログ（３１５）、データ同期部（３１６）、経営データ（３１７）およびモニタリング部（３１８）を備えている。
業務サービス提供部（３１１）は、ＳａａＳ形態として提供されるアプリケーションを実行して、その実行内容を業務サービスとしてＢ市（１０２）に提供する。業務サービスを提供する場合は、業務データ（３１３）を読み書きすることでアプリケーションを実行する。このとき、業務データ（３１３）に直接アクセスするのではなく、データ連携部（３１２）を経由して業務データ（３１３）に間接的にアクセスする。
データ連携部（３１２）は、業務サービス提供部（３１１）がアクセスしようとする業務データ（３１３）のアドレス(ロケーション）やアクセス方法（プロトコル）が登録されたデータアドレスリスト（３１４）を参照することで、実際にアクセスするアドレスやアクセス方法を解決する。
例えば、業務サービス提供部（３１１）からデータ連携部（３１２）に対してＳＱＬ（Structured Query Language）文を発行すると、データ連携部（３１２）は発行されたＳＱＬ文からテーブル名などを抽出し、データアドレスリスト（３１４）に登録された値と照合し、実際にデータが登録されているアドレスやアクセス方法を解決し、データを取得し、業務サービス提供部（３１１）に取得したデータを返す。
データ同期部（３１６）は、業務データ（３１３）の中身のデータをコピーし、およびコピーしたデータを他の情報処理装置へ移動（送信または受信）する。業務データ（３１３）の中身のデータに移動があった際は、移動したデータに基づいてデータアドレスリスト（３１４）を更新するように制御部（１１１ｂ）に指示する。制御部（１１ｂ）はその指示に従ってデータアドレスリスト（３１４）を更新する。
モニタリング部（３１８）は、サービス価格体系や追加投資をせずに受入可能な顧客キャパシティ等といった、業務サービスの提供において経営にかかわる事業形態を定めたデータである経営データ（３１７）を取得し、また、業務サービス提供部（３１１）が出力する、利用者（この場合はＳａａＳ利用者）による業務サービスの利用状況の履歴を示すログ（３１５）を取得する。そして、取得した経営データ（３１７）とログ（３１５）とに対して所定の統計処理をして、利用頻度などの統計情報として生成する。生成した統計情報はＣ社（１０３）の業務サーバＣ（１１３）に送信して、Ｃ社（１０３）が損益分析や予測のために利用する情報として提供する。このような処理を行い、Ａ市（１０１）による業務サービスの提供を監視する。
以上、Ａ社（１０１）内に配置されるサービス（つまり、業務サービス提供部（３１１）、データ連携部（３１２）、データ同期部（３１６）およびモニタリング部（３１８））とは、計算機上で実行されるプログラムである。また、データ（業務データ（３１３）、経営データ（３１７））とは、データベースプログラムおよびデータベースプログラムがデータベースに登録するデータである。また、ログ（３１５）およびデータアドレスリスト（３１４）とは、計算機上のファイルである。これらのサービス、データ、及びファイルは一台以上の計算機（本実施の形態では業務サーバＡ（１１１））上に配置される。
Ｃ社（１０３）の業務サーバＣ（１１３）は、損益分析・予測部（３５１）および移行率調整部（３５２）を備えている。
損益分析・予測部（３５１）は、モニタリング部（３１８）から統計情報を受信して取得し、所定の演算処理を行って損益分析や損益予測を行う。Ｃ社（１０３）はこの損益分析や損益予測から形態変更の契機を判断する。
移行率調整部（３５２）は、Ｂ市（１０２）がＳａａＳ形態からＳＩ形態へ変更する場合に、業務サービスや業務データの移行の移行率及び移行タイミングを調整する。
以上、Ｃ社（１０３）内に配置されるツール（損益分析・予測部（３５１）、移行率調整部（３５２））とは、計算機上で実行されるプログラムであり、これらのプログラムは一台以上の計算機（本実施の形態では業務サーバＣ（１１３））上に配置される。
ＳａａＳ利用者であるＢ市（１０２）のプロキシサーバ（１１２）は、Proxy（３４２）およびサービスアドレスリスト（３４３）を備えている。業務サービスを利用する業務クライアント（３４１）は、Proxy（３４２）を経由して業務サービス提供部（３１１）にアクセスする。その際、アクセスする業務サービス提供部（３１１）が提供する業務サービスのアドレスが記載されたサービスアドレスリスト（３４３）からそのアドレスを読み出すことにより、Proxy（３４２）は接続先を知ることができる。
以上、業務クライアント（３４１）とプロキシサーバ（１１２）とはそれぞれ独立した計算機であり、Proxy（３４２）はプロキシサーバ（１１２）という計算機上で実行される、主に業務クライアント（３４１）からのアクセスの要求や応答を代理するプログラムである。また、サービスアドレスリスト（３４３）とはProxy（３４２）のファイルシステム上のファイルである。
なお、各プログラムと、サービスと、データとの間では、必要に応じて暗号化や認証といったセキュリティ対策を講じることが好ましい。例えば、モニタリング部（３１８）と損益分析・予測部（３５１）との間では、経営情報が第三者に漏洩するとＡ社の競争力が失われるため、ネットワーク（３０１）上で通信内容を盗み見られないよう暗号化を施す必要がある。また、Ｃ社以外は経営情報を見ることができないようにするための認証を行うが必要である。同様に、業務サービス提供部（３１１）とProxy（３４２）や業務クライアント（３４１）の間でも、暗号化を施したり、認証を行うことが必要である。この場合、暗号化や認証の情報処理は、Proxy（３４２）において実行することが好ましい。本実施形態では、このような暗号化や認証が実行されているものとして説明を続ける。しかし、暗号化や認証に関する詳細な説明は省略する。
２．２．サービスアドレスリストについて；
図４は、サービスアドレスリスト（３４３）の概要を示した図である。サービスアドレスリスト（３４３）は、業務サービスを識別する情報が登録されるサービスＩＤ（Identification）フィールド（４０１）、業務サービスの名称が登録されるサービス名フィールド（４０２）、および業務サービスの場所を示すアドレスが登録されるサービスアドレスフィールド（４０３）を備えたデータベースとして構成される。図４のサービスアドレスフィールド（４０３）に登場する「SaaSorSI.com」は、Ａ社（１０１）が提供するＳａａＳのドメインであり、システムはまだ、ＳａａＳ形態であるので、Proxy（３４２）はすべての業務サービスをＡ社（１０１）の業務サービス提供部（３１１）へ接続する。この場合において、ネットワーク（３０１）を介して接続するので、サービスアドレスフィールド（４０３）に登録されるすべての業務サービスのアドレスはhttpsスキーマで書かれる。
２．３．データアドレスリストについて；
図５は、Ａ社（１０１）内のデータアドレスリスト（３１４）の概要を示した図である。データアドレスリスト（３１４）は、業務サービスを実行するときに用いる業務データ（３１３）を構成するデータベース（ＤＢ（Data Base））を識別する情報が登録されるＤＢＩＤフィールド（５０１）、そのデータベースの名称が登録されるＤＢ名フィールド（５０２）、そのデータベースの場所を示すデータアドレスが登録されるデータアドレスフィールド（５０３）、ＳａａＳ事業者であるＡ社（１０１）が業務サービスを提供する場合に、その業務サービスを実行するときに用いる業務データ（３１３）を構成するデータベースへアクセスするＳａａＳ事業者を識別する情報が登録されるＩＤフィールド（５０４）およびそのＳａａＳ事業者がアクセスするときに用いるパスワード（ＰＷ：Password）が登録されるＰＷフィールド（５０５）を備えたデータベースとして構成される。
形態変更前の段階では、すべての業務データ（３１３）はＡ社（１０１）内にあるため、データアドレスフィールド（５０３）に登録されるデータアドレスはすべてＡ社（１０１）内の計算機（業務サーバＡ（１１１））を示している。つまり、ネットワーク（３０１）を介して接続するわけではないので、データアドレスフィールド（５０３）に登録されるデータアドレスはjdbcスキーマで書かれる。なお、本実施の形態では、業務サービスを実行するプログラムはＪａｖａ（登録商標）で作成したものとし、業務データ（３１３）にアクセスするためのインターフェース仕様はＪＤＢＣ（Java DataBase Connectivity）を用いることとする。しかし、本発明を適用するにあたり、プログラムやインターフェース仕様の種類はこれに限定するものではない。
２．４．業務データについて；
業務データは、データアドレスリスト（３１４）のデータアドレスフィールド（５０３）に登録されたアドレスを解決することにより実行することが可能な業務サービスを提供する場合に用いられる。業務サービスには、利用者が各種の業務サービスの利用を開始する場合に行う利用者の認証を実行するユーザ認証サービス（図４参照）も含まれる。ユーザ認証サービスを実行する場合には、業務データ（３１４）として、データアドレスリスト（３１４）においてアドレスが登録されているユーザＤＢ（図５参照）が用いられる。
なお、ユーザ認証サービスを含め、すべての業務サービスにおいて、Ｂ市（１０２）内のサービスアドレスリスト（３４３）に登録されているレコードと、Ａ社（１０１）内のデータアドレスリスト（３１４）に登録されているレコードとは、周知の技術を用いて紐付けられているものとする。例えば、上記のように、ユーザ認証サービスのサービスＩＤ「s00001」（図４参照）は、ユーザＤＢのＤＢＩＤ「d00001」（図５参照）と紐付けられている。他のサービスＩＤやＤＢＩＤについても同様である。
図６は、業務データ（３１３）内の一項目であるユーザＤＢ（６００）の概要を示した図である。先に、業務サービス提供部（３１１）とProxy（３４２）、業務クライアント（３４１）の間で適切な認証が必要であることを説明したが、ユーザＤＢ（６００）は利用者認証のために業務サービス提供部（３１１）からデータ連携部（３１２）経由で利用される。
ユーザＤＢ（６００）は、利用者を識別する情報が登録されるユーザＩＤフィールド（６０１）、利用者が業務サービスの利用を開始する場合に用いるパスワードが登録されるＰＷフィールド（６０２）、およびその利用者が利用を許可された業務サービスを識別する情報が登録される許可サービスＩＤフィールド（６０３）を備えたデータベースとして構成される。許可サービスＩＤフィールド（６０３）に登録された許可サービスＩＤは、サービスＩＤフィールド（４０１）に登録されたいずれかの値（情報）と一致している。
図７は、業務クライアント（３４１）の画面例を示しており、例えば、出力部３４１ｄとして実装されるディスプレイ上にユーザ認証サービス画面（７１０）が表示されている。ＳａａＳを利用するクライアントアプリケーションは、Ajax（Asynchronous JavaScript And XML）などの手法を用いてWebブラウザ上で動作させることが一般的であり、図７もWebブラウザをイメージしている。業務クライアント（３４１）の出力部３４１ｄにはアドレス表示・入力欄（７０１）があり、このアドレス表示・入力欄（７０１）に入力されているアドレスを変えることにより、利用する業務サービスを選択することができる。Webブラウザ上での動作となるため、入力するアドレスの表記はＵＲＬ（Uniform Resource Locator）形式となる。アドレスの入力は、入力部３４１ａを用いることが一般的であるが、必ずしも利用者による手入力とは限らず、ボタン操作などにより自動的にアドレスが入力されて画面が遷移する場合もある。
ユーザ認証サービス画面（７１０）には、ユーザＩＤ入力欄（７１１）、パスワード入力欄（７１２）、ログインボタン（７１３）、及びキャンセルボタン（７１４）が配置されている。例えば、「u00001」という値で識別されている利用者が、Ａ社（１０１）の業務サービスの利用を開始する場合、まず、ユーザ認証サービス（図４参照）を実行することになるので、利用者は、ユーザＩＤ入力欄（７１１）には「u00001」と、パスワード入力欄（７１２）にはパスワード「p00001」とそれぞれ入力する。パスワード入力欄（７１２）に入力される文字等は、外部に見せないようにするため、「＊＊＊＊＊＊」と表示される。その後、その利用者がログインボタン（７１３）を押すと、サービス要求が行われ、業務サービスのうちユーザ認証サービスが動作し、業務データ（３１３）のユーザＤＢ（６００）に適合しているか否かの確認がなされる。その確認の際には、ユーザＩＤ入力欄（７１１）に入力された「u00001」という値がユーザＤＢ（６００）のユーザＩＤフィールド（６０１）に登録された値と一致するか否かを判定する。また、パスワード入力欄（７１２）に入力された「p00001」値がＰＷフィールド（６０２）に登録された値と一致するか否か判定する。また、ユーザ認証サービスであることを示すサービスＩＤフィールド（４０１）に登録された値「s00001」が許可サービスＩＤフィールド（６０３）に登録された値と一致するか否か判定する。その確認により、すべて一致すれば、登録ユーザであると判定し、認証が許容される。登録ユーザであることが認証されると、ユーザ認証サービス画面（７１０）において、許可サービスＩＤフィールド（６０３）に登録された値（「s00001」、「s00002」、「s00003」、「s00004」）に従い、利用を許可された業務サービス（「ユーザ認証サービス」、「スケジューラサービス」、「電子メールサービス」、「掲示板サービス」）のメニューが表示される。
２．５．Proxy（３４２）によるアドレスの解決方法について；
ここで、アドレス表示・入力欄（７０１）に入力されたアドレス「https://SaaSproxy/common/login」は、サービスアドレスフィールド（４０３）に登録されたアドレス「https://SaaSorSI.com/common/login」（図４参照）と異なっている。アドレス表示・入力欄（７０１）に入力されたアドレスが示すホスト名（SaaSproxy）は、Proxy（３４２）を示している。従って、アドレス表示・入力欄（７０１）に入力されたアドレス（https://SaaSproxy/common/login）により、業務クライアント（３４１）からのサービス要求は入力されたアドレスとともに、まずProxy（３４２）に送られる。
Proxy（３４２）は、業務クライアント（３４１）から送られたアドレスのうちパス名（/common/login）がサービスアドレスフィールド（４０３）のパス名と一致するものをサービスアドレスリスト（３４３）から見つけ出し、見つかったサービスアドレス（http://SaaSorSI.com/common/login）（図４参照）に要求を送る。このサービスアドレスは業務サービス提供部（３１１）のアドレスを示しているため、業務クライアント（３４１）からのサービス要求はProxy（３４２）を経由して業務サービス提供部（３１１）に送信される。その後、Proxy（３４２）は業務サービス提供部（３１１）からのサービス応答を受け取ると、業務クライアント（３４１）に応答を転送する。
このようにして、業務クライアント（３４１）からのサービス要求は、業務クライアント（３４１）が業務サービス提供部（３１１）のアドレスを知らなくとも、Proxy（３４２）を経由し、Proxy（３４２）がサービスアドレスリスト（３４３）によりアドレスを解決することで、業務サービス提供部（３１１）に転送される。
また、Proxy（３４２）におけるアドレス解決の別の方法として、業務クライアント（３４１）のアドレス表示・入力欄（７０１）に入力するアドレスのうち、パス名にサービスＩＤを指定する方法もある。つまり、ユーザ認証サービスを利用する場合に、図７のようにアドレス表示・入力欄（７０１）には「https://SaaSproxy/common/login」を指定するのではなく、「https://SaaSproxy/s00001」を指定する。この場合Proxy（３４２）は、パス名として指定された「s00001」に一致したサービスＩＤフィールド（４０１）を持つサービスアドレスをサービスアドレスリスト（３４３）のサービスアドレスフィールド（４０３）から探し出すことができる。
同様の変形として、アドレス表示・入力欄（７０１）に指定するパス名にサービス名（４０２）を指定してもよい。つまり、「https://SaaSproxy/ユーザ認証サービス」と指定する。この場合Proxy（３４２）は、パス名として指定された「ユーザ認証サービス」に一致したサービス名フィールド（４０２）を持つサービスアドレスをサービスアドレスリスト（３４３）のサービスアドレスフィールド（４０３）から探し出すことができる。
２．６．形態変更タイミングについて；
次に、図８から図１０を用いて、ＳＩ事業者Ｃ社がどのようにして利用形態変更の適時（形態変更タイミング）を把握するか示す。
図８は、業務サービス提供部（３１１）が出力するログ（３１５）に記録される内容を示した図である。通常、ＳａａＳ形態で提供されるアプリケーションはWebアプリケーションであり、Webアプリケーションのプログラムは処理が実施される度に、処理が実施された日時（８０１）、処理を実施したプログラム名（８０２）（サービスアドレスリスト（３４３）のサービスＩＤフィールド（４０１）に登録される値と一致）、処理を依頼したユーザ名（８０３）（ユーザＤＢ（６００）のユーザＩＤフィールド（６０１）に登録される値と一致）、その他メッセージ（８０４）（例えば、処理が成功したことを示す「ＯＫ」、処理が失敗したことを示す「ＮＧ」等）を一レコードとしてログファイルとして追記しながら出力する。一件のレコードは処理が呼び出されたタイミング、処理が終了したタイミングなど適宜出力されるので、ログ（３１５）に記録された情報を解析することで、業務サービスの利用率やよく利用される業務サービス、処理に時間を要している業務サービスなどを把握することができる。
図９は、経営データ（３１７）に記録される内容を示した図である。ＳａａＳ形態とＳＩ形態とのどちらが低コストであるかは、ＳａａＳ利用者にとっては主に利用ユーザ数や利用アプリケーション数によって決まる。そのため、図９では、経営データ（３１７）として、利用ユーザ数に応じて利用者一人あたりに課す月額基本料金を示す月額基本料金体系（９０１）、業務サービスの一つである電子メールサービスにおいて、利用者が使用するメールボックスの容量に応じて利用者に課す月額料金を示すメール月額料金体系（９０２）、業務サービスに応じて一のＳａａＳ利用者（Ｂ市やＤ市等）にどのくらいの利用者が登録されているかを示す利用ユーザ数（９０３）などのデータが記録されている。
一方、ＳａａＳ事業者にとっては、どちらの形態が低コストであるかということは、業務サービスの性能やキャパシティ（現在のシステムで受入が可能な利用者数等）によって決まる。そのため、図９では、経営データ（３１７）として、業務サービスに応じて、クライアント端末（３４１）とＳａａＳ事業者であるＡ社（１０１）の業務サーバＡ（１１１）との間でサービス要求、サービス応答が転送されるのに要する最長の期間であることを示すサービス応答保証時間（９０４）が記録されている。
図１０は、損益分析・予測部（３５１）の画面例を示している。Ｃ社（１０３）の業務サーバＣ（１１３）は、損益分析・予測部（３５１）による処理を実行する場合、出力部１１３ｄとして実装されるディスプレイ上に図１０に示した画面が表示される。損益分析・予測部（３５１）は、モニタリング部（３１８）から取得した経営データ（３１７）や業務サービス提供部（３１１）のログ（３１５）に関するデータを解析し、損益に関する予測結果を画面出力する。Ａ社（１０１）のＳａａＳを利用しているＳａａＳ利用者（Ｂ市やＤ市等）ごとに損益を分析するため、タブ表示（１００１）で表示をＳａａＳ利用者単位で切り替えることができる。画面には、損益予想（１００２）、登録ユーザ予想（１００３）、利用アプリケーション数（１００４）をはじめとする情報がグラフ表示され、現在までの実測値と今後の予測値の違いが分かるよう、線の種類や色等を変えて表示される。
損益予想（１００２）では、横軸に年月日をとり、縦軸に業務サービスの提供事業を行ったときの損益をとってグラフ表示している。そのグラフには、ＳａａＳ形態時における損益の推移（１００６）（事業開始時から現在（２００７年４月１日）までに実際に上げた損益の実測値（実線で表示）および現在から数ヶ月先までに上げることになると予想される予測値（破線で表示））と、ＳＩ形態時における損益の推移（１００５）（仮に事業開始時から現在（２００７年４月１日）までにＳＩ形態を利用していれば要したであろう損益の見積値（実線で表示）と現在からのＳＩ形態への変更の準備期間を考慮してＳＩ形態に変更した場合に今後要するであろう予測値（二点鎖線で表示））とが表示されている。これらの損益の推移は、登録ユーザ予想（１００３）と利用アプリケーション数（１００４における予想にも基づいて算出される。
登録ユーザ予想（１００３）では、横軸に年月日をとり、縦軸に業務サービスの提供事業を行ったときの登録ユーザ数をとってグラフ表示している。事業開始時から現在までに実際に登録したユーザ数の実測値は実線で表示してあり、現在から数ヶ月先までに登録すると予想されるユーザ数の予測値は破線で表示している。また、利用アプリケーション数（１００４）では、横軸に年月日をとり、縦軸に業務サービスの提供事業において利用者が利用可能なアプリケーション数をとってグラフ表示している。事業開始時から現在までに実際に利用可能なアプリケーション数の実測値は実線で表示してあり、現在から数ヶ月先までに登録すると予想される利用可能なアプリケーション数の予測値は破線で表示している。
損益予想（１００２）における損益の推移のグラフ（１００５、１００６）が交差する点が、予測に基づく損益分岐点（ＬＧ）である。この予想が正確であるとすると、移行コスト（ＳａａＳ形態からＳＩ形態に変更する場合に業務サービス及び業務データの移行に要するコスト。埋没コストや機会損失により発生する損失を含めても良い。）が限りなく小さければ損益分岐点（ＬＧ）付近でＳａａＳ形態からＳＩ形態に変更した方がＢ市（１０２）にとってはメリットがある。そこで、Ｃ社（１０３）はＳａａＳ形態からＳＩ形態への形態変更提案をＡ社（１０１）に対して行い（図２のステップＳ２０４）、Ａ社（１０１）はＢ市（１０２）が形態変更することで新規顧客受入のキャパシティを確保できることにメリットを感じた場合、Ｂ市（１０２）に対して形態変更提案を行う（図２のステップＳ２０５）。Ｂ市（１０２）が形態変更提案を受け入れると、Ｂ市（１０２）とＣ社（１０３）との間でＳＩ契約が結ばれる（図２のステップＳ２０６）。
３．ＳＩ形態に変更した場合の業務サービスの提供および利用について；
次に、図１１から図１３を用いて、Ｂ市とＣ社でＳＩ契約が結ばれた後にＳＩ実施（図２のステップＳ２０７）されたことによるシステム構成の変化について説明する。
３．１．システムの機能構成（形態変更後）；
図１１は、Ｃ社によるＳＩが実施された後の、Ａ社、Ｂ市、Ｃ社のシステム構成の概要を示している。ＳＩ実施前のシステム構成である図３からの変更点は、主にＢ市（１０２）のＳＩ対象範囲（１１０１）であるので、ＳＩ対象範囲（１１０１）を中心に説明する。なお、ＳＩ対象範囲（１１０１）を備えることにより、Ｂ市（１０２）は、ＳａａＳ利用者からＳＩ利用者に変化した。
Ｃ社（１０３）は、Ａ社（１０１）の業務サーバＡ（１１１）が有するＳａａＳ形態を実現する機能構成のうちＢ市（１０２）が利用している範囲と同等の機能を持つ機能構成をＢ市（１０２）内に構築する。すなわち、業務サービス提供部（３１１）、データ連携部（３１２）、業務データ（３１３）、データアドレスリスト（３１４）、データ同期部（３１６）、およびモニタリング部（３１８）のそれぞれと同等の機能を有する業務サービス提供部（３３１）、データ連携部（３３２）、業務データ（３３３）、データアドレスリスト（３３４）、データ同期部（３３６）、およびモニタリング部（３３８）をＳＩ対象範囲（１１０１）に構築する。ログ（３３５）も対象範囲（１１０１）に構築し、ログ（３１５）と同等の機能を有するが、業務サービス提供部（３３１）が利用される場合に出力されるログである。
これら、ＳＩ対象範囲（１１０１）内に配置されるサービス（つまり、業務サービス提供部（３３１）、データ連携部（３３２）、データ同期部（３３６）、およびモニタリング部（３３８））とは計算機上で実行されるプログラムである。また、業務データ（３３３）とはデータベースプログラムおよびデータベースプログラムが記録するデータである。ログ（３３５）及びデータアドレスリスト（３３４）とは計算機上のファイルである。これらのサービス、データ、及びファイルは一台以上の計算機（本実施の形態では業務サーバＢ（１１４））上に配置される。
ＳＩを実施したばかりの状態では、業務データ（３３３）はデータベース領域が存在するだけで中身は空である。また、サービスアドレスリスト（３４３）に記録されたサービスアドレス（４０３）は、全てＡ社（１０１）側の業務サービス（３１１）のアドレスを示している（つまり、httpsスキーマで書かれている。図４参照）。また、データアドレスリスト（３１４、３３４）は、論理的に同じ内容が記録される必要があり、ＳＩを実施したばかりの状態では全てのデータが業務データ（３１３）を指し示している（つまり、データアドレスリスト（３１４）のデータアドレスがすべてhttpsスキーマで書かれている。）。
３．２．論理的に同じ内容が記録されることについて；
データアドレスリスト（３１４、３３４）に記録されたデータアドレスが表記上は一致していないのに、論理的には同一のデータを指し示す仕組みについて、図１２を用いて説明する。
図１２は、データアドレスリストの概要を示した図である。（ａ）は、データアドレスリスト（３１４）に記録される内容を示しており、図５の再掲である。一方、（ｂ）はデータアドレスリスト（３３４）に記録される内容を示しており、（ａ）と比べてデータアドレスフィールド（１２０３）、ＩＤフィールド（１２０４）、ＰＷフィールド（１２０５）の内容が異なっている。データアドレスフィールド（１２０３）に登録される値は、スキーマが「jdbc」から「https」に変更されるために変更されている。また、ホスト部も「db1:9999」から「db.SaaSorSI.com」へと変更されている。
Ａ社（１０１）内のデータ連携部（３１２）から業務データ（３１３）を見た場合、同一ＬＡＮ（Local Area Network）上にありjdbcスキーマでのアクセスが可能である。一方、Ｂ市（１０２）内のデータ連携部（３３２）から業務データ（３１３）を見た場合、ネットワーク（３０１）を間に挟むためjdbcスキーマでのアクセスができない。
そこで、Ｂ市（１０２）内のデータ連携部（３３２）は、業務データが存在するＡ社（１０１）内の業務データ（３１３）に直接アクセスするのではなく、Ａ社（１０１）のデータ連携部（３１２）に要求を送り、データ連携部（３１２）を経由して業務データ（３１３）内の目的とするデータを入手するようにする。このとき、データ連携部（３３２）はネットワーク（３０１）越しにデータ連携部（３１２）を呼び出すことになるため、Webサービスでアクセスを行う。その結果、データアドレスフィールド（１２０３）に登録されるアドレス（ロケーション）は、データ連携部（３１２）のWebサービスエンドポイントを示しており、ＩＤフィールド（１２０４）とＰＷフィールド（１２０５）はそれぞれ、Webサービスを利用するためのＩＤ（hoge）とパスワード（wspw）になっている。このようにして、データアドレスリスト（３１４、３３４）に論理的に同じ内容が記録されるということは、ＳＩ形態に変更することで業務データにアクセスするときのスキーマが変更しても、データアドレスのホスト部も変更する（必要に応じてその他のデータも変更する）ことにより、利用する業務サービスのアドレスがどうであれデータ連携部（３１２、３３２）が直接アクセスできるようにするということを意味する。
データアドレスリスト（３１４、３３４）は、上記のようにデータベース単位でロケーションとプロトコルを記録する以外に、テーブル単位、レコード単位でロケーションとプロトコルを記録してもよい。図１３は、データアドレス（５０３）をテーブル単位、レコード単位で記録したデータアドレスリスト（３１４）の例である。業務サービスの一つであるスケジューラサービスが利用する業務データのうち、ＤＢＩＤフィールド（５０１）に登録された「d00002-1」という値を持つレコードに着目する。このレコードにおいて、テーブル名「daily」で指定されるテーブルに記録されたデータは業務データ（３１３）内に記録されている（例えば、スケジューラサービスの処理内容を１日単位で１つのレコードを作成する状況を想定すればよい。）。そのため、データ連携部（３１２）からはローカル環境へのアクセスとなるため、データアドレス（１２１０）はjdbcスキーマで書かれている。
一方、ＤＢＩＤフィールド（５０１）に登録された「d00002-2」という値を持つレコードに着目する。このレコードにおいて、テーブル名「monthly」で指定されるテーブルのうち、列名「month」の値が「１−６」のデータはＢ市（１０２）環境の業務データ（３３３）に移行して記録されている（例えば、スケジューラサービスのある年の１月〜６月までに処理されたデータは、既にＳＩ形態としてのＢ市（１０２）に移行された状況を想定すればよい。）。そのため、データアドレス（１２１１）はhttpsスキーマで書かれ、データ連携サービス（３１２、３３２）間のWebサービスでアクセスされる。
同様に、テーブル名「monthly」で指定される列名「month」の値が「７−１２」のデータはＡ社（１０１）の業務データ（３１３）内にある（例えば、スケジューラサービスのある年の７月〜１２月までに処理されたデータは、まだＳＩ形態としてのＢ市（１０２）に移行されていない状況を想定すればよい。）。そのため、データアドレス（１２１２）はjdbcスキーマで書かれ、データ連携部（３１２）からはローカル環境へのアクセスとなる。
このように、ＳａａＳ形態からＳＩ形態への変更の過渡期においては、データアドレスのテーブル名を当該業務データの移行状況に合わせて書き込むことにより、データ連携部（３１２、３３２）が業務データに直接アクセスする対象を絞り込むことが可能になり、形態の変更に伴う不具合（移行したことによりデータが存在しないアドレスにアクセスしてしまう等）を解消することができる。
なお、データアドレスリスト（３３４）についても同様に、テーブル単位、レコード単位でロケーションとプロトコルを記録することが可能である。ただし、ＳａａＳ形態からＳＩ形態への変更の過渡期において、データアドレスリスト（３３４）のデータアドレス（５０３）に登録される値は、移行先のものについては、jdbcスキーマで書かれたアドレスであり、移行元のものについては、httpsスキーマで書かれたアドレスである。
４．移行率の調整について；
次に、主に図１４から図１９を用いて、Ｃ社（１０３）がＢ市（１０２）にＳＩ実施（図２のステップＳ２０７参照）した後、業務サービスや業務データの一部をＡ社（１０１）のＳａａＳ環境からＢ市（１０２）のＳＩ環境に移行し（図２のステップＳ２０８）、モニタリング部（３３８）および移行率調整部（３５２）を用いてＢ市（１０２）のＳＩ環境の稼働状況をモニタリングし（図２のステップＳ２０９参照）、移行率調整部（３５２）を用いて移行率の調整を行い（図２のステップＳ２１０参照）、調整された移行率に基づき業務サービスや業務データの移行（図２のステップＳ２１１参照）を行う手順について説明する。
図１１において、Ａ社（１０１）のＳａａＳ環境からＢ市（１０２）のＳＩ環境に業務サービスや業務データの一部移行（図２のステップＳ２０８参照）を行う場合、業務データ（３１３）内のデータを業務データ（３３３）に移行する処理は、データ同期部（３１６、３３６）により行われる。データを正常に移行した後、データ同期部（３１６、３３６）はデータアドレスリスト（３１４、３３４）を更新することで、図１２に示した場合と同様に、データアドレスリスト（３１４、３３４）に記録された内容は異なるものの、そのリストが示すデータの実体は論理的に同じものとなる。
また、業務サービス提供部（３１１、３３１）による業務サービスの提供については業務データ（３１３、３３３）と異なり、Ａ社（１０１）とＢ市（１０２）に同じ業務サービスが重複して存在しても、Proxy（３４２）での振り分けができれば問題ない。例えば、業務サービスとしてユーザ認証サービスを実行する場合、形態変更前では、サービスアドレスリスト（３４３）のサービスアドレスにはhttpsスキーマで定まるアドレス（https://SaaSorSI.com/common/login）（図４参照）だけが登録されるが、形態変更の過渡期では、jdbcスキーマで定まるアドレスもサービスアドレスリスト（３４３）に登録する。必要に応じてサービスＩＤやサービス名も変更する（図４参照）。Proxy（３４２）は、業務クライアント（３４１）のサービス要求（例えば、ユーザ認証サービスのサービス要求）から、当該利用者に関する業務データがＡ社（１０１）とＢ市（１０２）のいずれに存在するかを解析し、存在する方のサービスアドレスをサービスアドレスリスト（３４３）から抽出し、抽出したサービスアドレスに従い、業務サービス提供部（３１１、３３１）にサービス要求する。最終的には、業務サービスの移行は、移行率調整部（３５２）からProxy（３４２）へ移行コマンド（業務サービスを移行するように指示するコマンド）を送信し、Proxy（３４２）がサービスアドレスリスト（３４３）を更新する（移行先のサービスアドレスのみ登録する）ことで達成される。これら、業務サービス（３１１、３３１）と業務データ（３１３、３３３）の移行を実施するタイミングは、モニタリング部（３３８）と移行率調整部（３５２）により行う。
モニタリング部（３３８）は、業務サービスのログ（３３５）および業務データ（３３３）を取得し、その取得されたログ（３３５）および業務データ（３３３）に対して所定の演算処理をし、移行した業務サービスと業務データがうまく動作しているか、応答性能などについて十分なパフォーマンス（性能）が得られているか否かを定めた稼働情報（つまり、Ｂ市（１０２）のＳＩ利用者システムの稼動状況を示す情報である。詳細は後記する。）を生成する。このような処理を行い、Ｂ市（１０２）による業務サービスの提供を監視する。
移行率調整部（３５２）は、モニタリング部（３３８）において生成された稼働情報を取得して業務サービスおよび業務データの移行の性能を判定し、その判定結果を元に移行率の調整（図２のステップＳ２１０参照）をデータ同期部（３１６、３３６）とサービスアドレスリスト（３４３）に対して行う。そして、データ同期部（３１６、３３６）による同期処理により、調整された移行率に基づく移行（図２のステップＳ２１１参照）が行われる。
４．１．移行率の調整の処理手順について；
図１４は、移行率調整部（３５２）で移行率の調整を行う処理手順の概要を説明した図である。移行率調整部（３５２）はまず、Ｂ市（１０２）のモニタリング部（３３８）から稼働情報を取得する（ステップＳ１４０１）。取得した稼働情報から、一定以上の性能が得られているか否か判断し（ステップＳ１４０２）、性能を満たさない場合は（ステップＳ１４０２でＮｏ）、その原因となるボトルネック箇所を、業務サーバＣ（１１３）の出力部１１３ｄとして実装されるディスプレイ上の画面に提示する（ステップＳ１４０３）。その後、一定の期間スリープ処理（ステップＳ１４０４）を行い、再びＢ市（１０２）の稼働情報をモニタリングする（ステップＳ１４０１）。ボトルネック箇所を提示されたＣ社（１０３）は、必要に応じ、Ｂ市（１０２）のＳＩ利用者システムのチューニングを実施する。
一定以上の性能が得られた場合は（ステップＳ１４０２でＹｅｓ）、全ての業務サービスおよび業務データがＢ市（１０２）に移行されているかどうかを判断し（ステップＳ１４０５）、移行が完了していれば（ステップＳ１４０５でＹｅｓ）処理を終了する。まだ移行が完了していない場合は（ステップＳ１４０５でＮｏ）、稼働情報から更に業務サービスや業務データを移行してもよいと判断し、ステップＳ１４０６及びステップＳ１４０８に進む。
業務データを移行する場合、移行する業務データの移行率を設定し（ステップＳ１４０６）、データ同期部（３１６、３３６）へ移行コマンドを送信し（ステップＳ１４０７）、スリープ処理（ステップＳ１４０４）の後、再びＢ市（１０２）の稼働情報をモニタリングする（ステップＳ１４０１）。一方、業務サービスを移行する場合、移行する業務サービスの移行率を設定し（ステップＳ１４０８）、Proxy（３４２）へ移行コマンドを送信し（ステップＳ１４０９）、スリープ処理（ステップＳ１４０４）の後、再びＢ市（１０２）の稼働情報をモニタリングする（ステップＳ１４０１）。このように、すべての業務サービスと業務データが移行されるまで実行される。
４．２．稼働情報について；
図１５は、移行率調整部（３５２）がモニタリング部（３３８）から取得する稼働情報の稼働情報メッセージ（１５０１）の例を示す図である。移行率調整部（３５２）とモニタリング部（３３８）はネットワーク（３０１）で接続されており、ネットワーク（３０１）がインターネットに代表されるオープンネットワークであることも考慮し、稼働情報メッセージ（１５０１）はWebサービスを通じて取得されるＸＭＬ（eXtensible Markup Language）メッセージ形式を例に説明する。
稼働情報メッセージ（１５０１）は、大きく、ロケーション情報部（１５０２）とパフォーマンス情報部（１５０３）と移行情報部（１５０４）とから構成される。
ロケーション情報部（１５０２）は、業務サービスの所在を示す業務サービスロケーション情報部（１５０５）と業務データの所在を示す業務データロケーション情報部（１５０６）とから構成される。ロケーション情報部（１５０２）のすべてのlocation属性値が「Ｂ」となっていれば、すべての業務サービスおよび業務データがＢ市（１０２）に移行されていることが分かる。
パフォーマンス情報部（１５０３）は、スループット情報部（１５０７）とキャパシティ情報部（１５０８）から構成される。スループット情報部（１５０７）には、ログ（３３５）から抽出された時間（response time）のかかった処理のリストが記録されている。キャパシティ情報部（１５０８）には、Ｂ市（１０２）環境のサーバ単位（ウェブサーバ（web）、アプリケーションサーバ（ap）、データベースサーバ（db））で平均負荷率（loadaverage）やディスク容量（volume）等の情報が記載されている。パフォーマンス情報部（１５０７）およびキャパシティ情報部（１５０８）に記載された情報から、移行率調整部（３５２）は一定の性能（パフォーマンス）が得られているか否かを判断することができる。
移行情報部（１５０４）は、業務サービスや業務データの移行の履歴を記録した移行ログ情報部（１５０９）から構成される。移行ログ情報部（１５０９）に記載された情報から、移行が行われた日時（move date）と移行の方向（from）、および移行率（change）が分かる。
４．３．データの同期の処理手順について；
図１６は、データ同期部（３１６）の処理フローを示した図である。データ同期部（３１６）は、移行率調整部（３５２）からの移行コマンドを受信（ステップＳ１６０２）するまでは待機処理（ステップＳ１６０１）を行う。移行コマンド受信後、モニタリング部（３１８）から稼働情報を受信して取得し（ステップＳ１６０３）、移行対象データ候補を選定する（ステップＳ１６０４）。選定した移行対象データ候補を記録した移行対象データ候補リストをデータ同期部（３３６）に送信し（ステップＳ１６０５）、そのリストの良否が判断される（ステップＳ１６０６）。
リストの候補でＯＫであるという応答がデータ同期部（３３６）から得られなければ（ステップＳ１６０６でＮｏ）、ステップＳ１６０４に戻り、再び移行対象データ候補の選定を行う（ステップＳ１６０４）。リストの候補でＯＫであるという応答が得られれば（ステップＳ１６０６でＹｅｓ）、移行対象データ候補として選定した移行対象データをデータ同期部（３３６）に送信し（ステップＳ１６０７）、移行対象データの移行において実行したコピーが正常に行われたか否かが判断される（ステップＳ１６０８）。
コピーが正常に行われず、移行対象データの移行の要求に対する応答が返らなかった場合（ステップＳ１６０８でＮｏ）、再度移行対象データを送る（ステップＳ１６０７）。正常にコピーが行われ、移行対象データの移行の要求に対する応答を受け取った場合（ステップＳ１６０８でＹｅｓ）には、移行対象データに基づいてデータアドレスリスト（３１４）を更新するように制御部（１１１ｂ）に指示し、移行済みのデータを削除する（ステップＳ１６０９）。制御部（１１１ｂ）はその指示に従い、移行済みのデータを削除する。
以上の処理の後、移行率調整部（３５２）から指定された移行率を達成したか否か確認し（ステップＳ１６１０）、達成できた場合は（ステップＳ１６１０でＹｅｓ）待機処理（ステップＳ１６０１）に戻り、達成できていない場合は（ステップＳ１６１０でＮｏ）モニタリング部（３１８）から稼働情報を取得する処理（ステップＳ１６０３）に戻る。
なお、移行するデータを受け取るＢ市（１０２）のデータ同期部（３３６）は、上記のデータ同期部（３１６）の処理に対応した処理を実行することにより、業務データの移行処理において、Ａ市（１０１）とＢ市（１０２）とでその移行の状況を揃える（同期する）ことができる。データ同期部（３３６）は、ステップＳ１６０７により、移行対象データを受信した場合、受信した移行対象データに基づいてデータアドレスリスト（３３４）を更新するように制御部（１１４ｂ）に指示する。制御部（１１４ｂ）はその指示に従い、移行したデータを更新する。
４．４．移行対象データの選定について；
ここで、移行対象データ候補の選定（ステップＳ１６０４）には、業務データの移行に伴う業務サービスのパフォーマンス（稼働情報のパフォーマンス情報部（１５０３）から取得される）の低下を回避する工夫が必要となる。移行対象データをデータ同期部（３３６）に送信する（ステップＳ１６０７）処理を開始してから、データアドレスリスト（３１４）が更新される（ステップＳ１６０９）までの間（更新処理中）は、データ連携部（３１２、３３２）がデータアドレスリスト（３１４、３３４）および業務データ（３１３、３３３）にアクセスするタイミングによっては、データの一意性が保たれなく恐れがある。
そこで、更新処理中にはデータ連携部（３１２、３３２）によるアクセスを受け付けないようにするという方法を採る。その方法について図１７を用いて説明する。
図１７は、データアドレスリスト（３３４）に記録される内容を示した図である。図１２（ｂ）のデータアドレスリスト（３３４）と比較すると、更新フィールド（１２２０）を設けた点で相違する。この相違点について説明する。なお、データアドレスリスト（３１４）についても同様のことが言えるので、まとめて説明する。
更新フィールド（１２２０）は、データアドレスリスト（３１４、３３４）にデータが移行中であるか否かを設定することができるフィールドである。データ連携部（３１２、３３２）はアクセスしようとするデータが更新中でない場合のみ業務データ（３１３、３３３）にアクセスする必要がある。そのために、情報処理としては、まず、データ同期部（３１６、３３６）は移行対象データを相手のデータ同期部（３３６、３１６）に送信する（ステップＳ１６０７）前に更新フィールド（１２２０）の値を「１」にして更新中であることを示すようにする。そして、データアドレスリスト（３１４、３３４）を更新（ステップＳ１６０９）し終えた後には、更新フィールド（１２２０）の値も「０」に書き換えて非更新中であることを示すようにする。本実施の形態では、更新フィールド（１２２０）にデータ移行中であることを示す情報が登録され、データ連携部（３１２、３３２）が業務データ（３１３、３３３）にアクセスできないようにする処理のことを「業務データロック」と呼ぶ。
データ連携部（３１２、３３２）が業務データ（３１３、３３３）にアクセスする際に、対象とするデータに業務データロックがかかっていると、データ連携部（３１２、３３２）は処理を進めることができず、業務サービス提供部（３１１、３３１）も処理を進めることができない。そのため、業務データロックがかかる時間を短くすることが、業務サービスのパフォーマンスを低下させないためには重要である。
そこで、移行対象データ候補の選定（ステップＳ１６０４）を行う際、その移行タイミングではデータ連携部（３１２、３３２）からのアクセスが発生する可能性の低いデータを選定する必要がある。どのデータがよく利用されるか、またどのタイミングで利用されるかは、業務サービス（３１１、３３１）が出力するログ（３１５、３３５）や、業務データ（３１３、３３３）に関する稼働情報を調べることで、ある程度の予想がつく。そのため、データ同期部（３１６、３３６）はモニタリング部（３１８、３３８）から業務データ（３１３、３３３）のアクセス頻度やアクセス履歴に関する情報を得ることで、この移行タイミングで業務データロックが発生してもデータ連携部（３１２、３３２）への影響が低いと予想される移行対象データ候補を選定することができる。
図１８は、移行率調整部（３５２）の画面例を示す図である。Ｃ社（１０３）の業務サーバＣ（１１３）は、移行率調整部（３５２）による処理を実行する場合、出力部１１３ｄとして実装されるディスプレイ上に図１８に示した画面が表示される。タブ（１７０１）により、調整を行う対象利用者（Ｂ市やＤ市等）を指定する。画面には、横軸に年月日をとり、縦軸には移行率をとり、これまでの移行率の遷移状況を示した移行率遷移グラフ（１７０２）が表示されている。稼働情報取得ボタン（１７０３）を押すことでモニタリング部（３３８）に問い合わせを行い、稼働情報を取得する。移行率遷移グラフ（１７０２）は、移行率調整部（３５２）がモニタリング部（３３８）から取得する稼働情報メッセージ（１５０１）内の移行情報部（１５０４）を元に作成され、一定期間毎に更新する。
また、画面には移行率遷移グラフ（１７０２）以外に、現在の移行率と設定する移行率とを入力する移行率入力欄（１７０４）と、次回の移行までに推奨される確認期間（入力した移行率でデータの移行を進めても良いかどうかを、移行率調整部（３５２）を用いる者（ここでは、Ｃ社（１０３））に確認する期間）と設定する確認期間とを入力する確認期間入力欄（１７０５）があり、送信ボタン（１７０６）を押すことでデータ同期部（３１６、３３６）とProxy（３４２）に移行コマンドが送信される。なお、移行率や確認期間等の入力は、例えば、入力部１１３ａからの入力により達成される。また、移行率入力欄（１７０４）は、業務サービスの移行率を入力する欄と業務データの移行率を入力する欄との２部に分けて、業務サービスの移行率と業務データを移行率を個別に設定することができるようにしても良い。
確認期間入力欄（１７０５）に入力された日数は、移行対象データ候補の選定（ステップＳ１６０４）で利用される。確認期間を長く指定した場合、データ同期部（３１６、３３６）は一回あたりの対象データ件数を少なく選定し、確認期間を短く指定した場合は一回あたりの対象データ件数を多く選定する。従って、確認期間を長く指定した方が業務データロックは発生しにくくなるため、業務サービスのパフォーマンス劣化が少なく、また一回あたりのデータの移行による影響が少ないので信頼性が高くなるというメリットがある。その反面、ＳａａＳ形態とＳＩ形態の共存期間が長くなり、ＳａａＳ利用料金を支払う期間が長くなるというデメリットがある。
４．５．移行コマンドについて；
図１９は、移行率調整部（３５２）からデータ同期部（３１６、３３６）、Proxy（３４２）に送信する移行コマンドの移行コマンドメッセージの例（ａ）〜（ｃ）を示している。稼働情報（図１５）の場合と同様、移行コマンドもWebサービスのＸＭＬメッセージ形式として表現している。
（ａ）に示すように、移行コマンドメッセージ（１８０１）には、移行コマンド（１８０２）を記載する。移行コマンド（１８０２）には、実施日（move date）、移行元（from）、移行先（to）、移行率（change）、および確認期間（duration）を含める。また、（ｂ）に示す移行コマンド（１８０３）のように「move type」という属性を設け、業務サービスと業務データとで移行率を変えてもよい。また、（ｃ）に示す移行コマンド（１８０４）のように業務サービスと業務データとで移行する方向を変えてもよい。つまり、移行元（from）および移行先（to）において「Ａ（Ａ市（１０１）を意味する。）」と「Ｂ（Ｂ市（１０２）を意味する。）」とを入れ替えて、移行コマンド（１８０４）に示すように、業務サービスの移行は、Ｂ市（１０２）からＡ市（１０１）に対して行う。このような逆の移行は、例えば、移行のパフォーマンスが十分でなく、ボトルネックが発生している（図１４のステップＳ１４０３参照）場合に、Ｂ市（１０２）のＳＩ利用者システムのチューニングとして有効な処理である。
５．まとめ；
本実施の形態の業務サービス実行システムにより、以下の効果を奏する。すなわち、ＳａａＳ利用者環境（Ｂ市（１０２））の業務クライアント（３４１）はProxy（３４２）経由で業務サービスを利用するため業務サービスがＳａａＳ事業者環境（Ａ市（１０１））とＳａａＳ利用者環境（Ｂ市（１０２））のどちらに設置されていても論理的に同じサービスアドレスを指示することで、業務サービスの利用者が接続先の変更を意識することなく、業務サービスを利用することができる。
また、業務サービス提供部（３１１、３１３）はデータ連携部（３１２、３３２）経由で業務データ（３１３、３３３）にアクセスするので、業務データ（３１３、３３３）がＳａａＳ事業者環境（Ａ市（１０１））とＳａａＳ利用者環境（Ｂ市（１０２））のどちらに設置されていても業務データ（３１３、３３３）にアクセスすることができる。このため、埋没コストや機会損失を軽減したＳａａＳ形態からＳＩ形態への変更が可能となる。
また、モニタリング部（３１８、３３８）と損益分析・予測部（３５１）により、ＳａａＳ形態とＳＩ形態の損益分岐点と現在の状況を把握することができるため、ＳａａＳ形態からＳＩ形態への適正な変更時期を判断することができる。
また、データ同期部（３１６、３３６）と移行率調整部（３５２）により業務データと業務サービスのアドレスを柔軟に変更できるため、ＳａａＳ形態とＳＩ形態の共存およびＳａａＳ形態からＳＩ形態への変更に伴う業務サービスや業務データの連続的な移行（移行率や移行時期の調整）が可能となる。このため、ＳａａＳ形態からＳＩ形態への変更を行っている間であっても、利用者による業務サービスの利用に支障をきたさないようにすることができる。
６．その他；
以上、本発明の一実施の形態として、業務サービスをＳａａＳ形態で提供するＡ社と、一部門でＡ社の業務サービスを利用するＢ市があり、Ｂ市の他部門でもＡ社の業務サービスの利用が増えてきた際に、Ａ社の関連会社でＳＩ事業を手がけるＣ社がＳＩを行いＳａａＳ形態からＳＩ形態に変更する場合の例を説明したが、本発明は上記の実施の形態に限定されるものではなく、その趣旨の範囲内で数々の変形が可能である。
例えば、データアドレスリスト（３１４、３３４）は、ファイルではなく、データの論理名で問い合わせると物理アドレスを応答するプログラムにより実現することができる。同様に、サービスアドレスリスト（３４３）も、サービスの論理名で問い合わせると物理アドレスを応答するプログラムにより実現することができる。
また、他の変形として、サービスアドレスリスト（３４３）の書き換えは、移行率調整部（３５２）からProxy（３４２）に移行コマンドを送信することで行うのではなく、手作業により（プロキシサーバ１１２の入力部１１２ａから）サービスアドレスリスト（３４３）を書き換えてもよい。
また、他の変形として、移行率調整部（３５２）をＣ社（１０３）に設置するのではなく、Ｂ市（１０２）内に設置することもできる。その際、移行率調整部（３５２）を業務サーバＢ（１１４）が備えても良いし、プロキシサーバ（１１２）が備えても良い。
また、他の変形として、Ｂ市（１０２）業務サービスの利用者がＳＩ形態からＳａａＳ形態に変更しようとする場合であっても、本発明を適用することができる。利用ユーザ数が減少してきてＳＩ形態の規模が小さくなった場合に、ＳａａＳ形態のほうが低コストで済むと判断するのは合理的である。この場合、本実施の形態で説明したようなやり方で、ＳＩ形態からＳａａＳ形態への変更についても埋没コストや機会損失を軽減するように業務サービスや業務データを移行することが望ましい。また、損益分析・予測部（３５１）や移行率調整部（３５２）を用いて上記のような形態変更を支援することができる。
ＳａａＳ事業者Ａ社と、ＳａａＳ利用者Ｂ市と、ＳＩ事業者Ｃ社との関係を示した概念図である。 Ａ社、Ｂ市、Ｃ社の関係を時間軸に沿って示した概念図である。 Ｃ社によるＳＩ実施がされる前の、Ａ社、Ｂ市、Ｃ社に設置されるシステムの機能構成を示した図である。 サービスアドレスリスト（３４３）の概要を示した図である。 Ａ社（１０１）内のデータアドレスリスト（３１４）の概要を示した図である。 業務データ（３１３）内の一項目であるユーザＤＢ（６００）の概要を示した図である。 業務クライアント（３４１）の画面例である。 業務サービス提供部（３１１）が出力するログ（３１５）に記録される内容を示した図である。 経営データ（３１７）に記録される内容を示した図である。 損益分析・予測部（３５１）の画面例である。 Ｃ社によるＳＩが実施された後のＡ社、Ｂ市、Ｃ社のシステム構成の概要を示す図である。 （ａ）は、データアドレスリスト（３１４）に記録される内容を示した図である。（ｂ）は、データアドレスリスト（３３４）に記録される内容を示した図である。 データアドレス（５０３）をテーブル単位、レコード単位で記録したデータアドレスリスト（３１４）の例である。 移行率調整部（３５２）で移行率の調整を行う処理手順の概要を説明した図である。 移行率調整部（３５２）がモニタリング部（３３８）から取得する稼働情報の稼働情報メッセージ（１５０１）の例を示す図である。 データ同期部（３１６）の処理フローを示した図である。 データアドレスリスト（３３４）に記録される内容を示した図である。 移行率調整部（３５２）の画面例を示す図である。 移行率調整部（３５２）からデータ同期部（３１６、３３６）、Proxy（３４２）に送信する移行コマンドの移行コマンドメッセージの例（ａ）〜（ｃ）を示している。
符号の説明
１０１ Ａ社（ＳａａＳ事業者）
１０２ Ｂ市（ＳａａＳ利用者）
１０３ Ｃ社（ＳＩ事業者）
１１１ 業務サーバＡ
１１２ プロキシサーバ
１１３ 業務サーバＣ
１１４ 業務サーバＢ
３０１ ネットワーク
３１１、３３１ 業務サービス提供部
３１２、３３２ データ連携部
３１３、３３３ 業務データ
３１４、３３４ データアドレスリスト
３１５、３３５ ログ
３１６、３３６ データ同期部
３１７ 経営データ
３１８、３３８ モニタリング部
３４１ 業務クライアント
３４２ Proxy
３４３ サービスアドレスリスト
３５１ 損益分析・予測部
３５２ 移行率調整部

Claims (18)

  1. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムにおいて、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶する記憶手段と、
    前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する制御手段と、を有する
    ことを特徴とする業務サービス利用システム。
  2. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムにおいて、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶する記憶手段と、
    前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する制御手段と、を有する
    ことを特徴とする業務サービス利用システム。
  3. 前記第二の業務サービス提供装置は、
    前記第一の業務サービス提供装置から移行される業務データを受信し、前記移行された業務データに基づいて前記データアドレスリストを更新するように前記制御手段に指示するデータ同期手段を有する
    ことを特徴とする請求項２に記載の業務サービス利用システム。
  4. 前記第一の業務サービス提供装置が提供する一の業務サービスを実行するために用いる業務データの一部である第一の部分業務データが前記第二の業務サービス提供装置に移行されたとき、
    前記制御手段は、
    前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された第一の部分業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新し、前記移行がされていない業務データの一部である第二の部分業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第一の業務サービス提供装置であることを示すアドレスに更新する
    ことを特徴とする請求項２に記載の業務サービス利用システム。
  5. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    を有する業務サービス実行システムであって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶する第一の記憶手段と、
    前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する第一の制御手段と、を有し、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶する第二の記憶手段と、
    前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する第二の制御手段と、を有する
    ことを特徴とする業務サービス実行システム。
  6. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムであって、
    前記第一の業務サービス提供装置は、
    前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログおよび前記第一の業務サービス提供装置による業務サービスの提供において経営にかかわる事業形態を定めた経営情報を記憶した記憶手段と、
    前記ログおよび前記経営情報を前記記憶手段から取得し、前記取得した前記ログおよび前記経営情報に対して所定の統計処理をして統計情報を生成し、前記生成した統計情報を前記支援装置に送信して前記業務サービスの提供を監視する監視手段とを有し、
    前記支援装置は、
    前記監視手段から前記統計情報を受信し、前記統計情報に対して所定の演算処理を行うことにより、前記業務サービス利用システムに前記第二の業務サービス提供装置を追加しない場合に業務サービス実行システムを運営するときに予想される第一の損益の推移、および前記業務サービス利用システムに前記第二の業務サービス提供装置を追加した場合に業務サービス実行システムを運営するときに予想される第二の損益の推移を算出し、前記第一の損益の推移と前記第二の損益の推移とから、双方の場合を比較して損益分岐点を求める損益分析・予測手段を有する
    ことを特徴とする業務サービス実行システム。
  7. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムであって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶する第一の記憶手段と、
    前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する第一の制御手段と、を有し、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストおよび前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログを記憶する第二の記憶手段と、
    前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する第二の制御手段と、
    前記第一の業務サービス提供装置から移行される業務データを受信し、前記移行された業務データに基づいて前記データアドレスリストを更新するように前記第二の制御手段に指示するデータ同期手段と、
    前記ログおよび前記移行された業務データに基づいて対して所定の演算処理をして、業務サービス利用システムにおける前記業務サービスおよび前記業務データの移行の性能を定めた稼働情報を生成し、前記生成した稼働情報を前記支援装置に送信して前記業務サービスの提供を監視する監視手段と、を有し、
    前記支援装置は、
    前記監視手段から前記稼働情報を受信し、前記業務サービスおよび前記業務データの移行の性能を判定し、一定以上の性能が得られた場合には、前記支援装置が備える入力手段から入力された前記業務サービスの移行の移行率に従って前記中継装置に対して前記業務サービスの移行コマンドを送信し、前記入力手段から入力された前記業務データの移行の移行率に従って前記データ同期手段に対して前記業務データの移行コマンドを送信する移行率調整手段を有する
    ことを特徴とする業務サービス実行システム。
  8. 前記第二の業務サービス提供装置において、
    前記データアドレスリストは、前記業務データアドレスフィールドに登録されているアドレスに所在する業務データへのアクセスを受け付けず、当該アドレスの更新の可否を定める値が登録される更新可否フィールドを備え、
    前記第二の制御手段は、前記データ同期手段が前記移行コマンドに従って前記第一の業務サービス提供装置から移行される業務データを受信した場合、前記データアドレスリストを読み出し、前記更新可否フィールドに登録された、前記移行される業務データと同一の業務データのアドレスの更新の可否を定める値を、当該アドレスの更新を不可にする値に更新する
    ことを特徴とする請求項７に記載の業務サービス実行システム。
  9. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムにおける業務サービス利用方法において、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段が、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップ、を実行する
    ことを特徴とする業務サービス利用方法。
  10. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムにおける業務サービス利用方法において、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶し、
    前記第二の業務サービス提供装置の制御手段が、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップ、を実行する
    ことを特徴とする業務サービス利用方法。
  11. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    を有する業務サービス実行システムにおける業務サービス実行方法であって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段が、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップ、を実行し、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶し、
    前記第二の業務サービス提供装置の制御手段が、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップ、を実行する
    ことを特徴とする業務サービス実行方法。
  12. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムにおける業務サービス実行方法であって、
    前記第一の業務サービス提供装置は、
    前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログおよび前記第一の業務サービス提供装置による業務サービスの提供において経営にかかわる事業形態を定めた経営情報を記憶し、
    前記ログおよび前記経営情報を前記記憶手段から取得し、前記取得した前記ログおよび前記経営情報に対して所定の統計処理をして統計情報を生成し、前記生成した統計情報を前記支援装置に送信して前記業務サービスの提供を監視するステップを実行し、
    前記支援装置は、
    前記第一の業務サービス提供装置から前記統計情報を受信し、前記統計情報に対して所定の演算処理を行うことにより、前記業務サービス利用システムに前記第二の業務サービス提供装置を追加しない場合に業務サービス実行システムを運営するときに予想される第一の損益の推移、および前記業務サービス利用システムに前記第二の業務サービス提供装置を追加した場合に業務サービス実行システムを運営するときに予想される第二の損益の推移を算出し、前記第一の損益の推移と前記第二の損益の推移とから、双方の場合を比較して損益分岐点を求めるステップを実行する
    ことを特徴とする業務サービス実行方法。
  13. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムにおける業務サービス実行方法であって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段が、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップ、を実行し、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストおよび前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログを記憶し、
    前記第二の業務サービス提供装置の制御手段が、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新するステップと、
    前記第一の業務サービス提供装置から移行される業務データを受信し、前記移行された業務データに基づいて前記データアドレスリストを更新するように前記第二の制御手段に指示するステップと、
    前記ログおよび前記移行された業務データに基づいて対して所定の演算処理をして、業務サービス利用システムにおける前記業務サービスおよび前記業務データの移行の性能を定めた稼働情報を生成し、前記生成した稼働情報を前記支援装置に送信して前記業務サービスの提供を監視するステップと、を実行し、
    前記支援装置は、
    前記第二の業務サービス提供装置から前記稼働情報を受信し、前記業務サービスおよび前記業務データの移行の性能を判定し、一定以上の性能が得られた場合には、前記支援装置が備える入力手段から入力された前記業務サービスの移行の移行率に従って前記中継装置に対して前記業務サービスの移行コマンドを送信し、前記入力手段から入力された前記業務データの移行の移行率に従って前記データ同期手段に対して前記業務データの移行コマンドを送信するステップを実行する
    ことを特徴とする業務サービス実行方法。
  14. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムのコンピュータとして機能させる業務サービス利用プログラムにおいて、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段に、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理、を実行させる
    ことを特徴とする業務サービス利用プログラム。
  15. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置と、
    前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置と、
    を有する業務サービス利用システムのコンピュータとして機能させる業務サービス利用プログラムにおいて、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶し、
    前記第二の業務サービス提供装置の制御手段に、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理、を実行させる
    ことを特徴とする業務サービス利用プログラム。
  16. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    を有する業務サービス実行システムのコンピュータとして機能させる業務サービス実行プログラムであって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段に、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理、を実行させ、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストを記憶し、
    前記第二の業務サービス提供装置の制御手段に、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理、を実行させる
    ことを特徴とする業務サービス実行プログラム。
  17. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムのコンピュータとして機能させる業務サービス実行プログラムであって、
    前記第一の業務サービス提供装置は、
    前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログおよび前記第一の業務サービス提供装置による業務サービスの提供において経営にかかわる事業形態を定めた経営情報を記憶し、
    前記ログおよび前記経営情報を前記記憶手段から取得し、前記取得した前記ログおよび前記経営情報に対して所定の統計処理をして統計情報を生成し、前記生成した統計情報を前記支援装置に送信して前記業務サービスの提供を監視する処理を実行させ、
    前記支援装置に、
    前記第一の業務サービス提供装置から前記統計情報を受信し、前記統計情報に対して所定の演算処理を行うことにより、前記業務サービス利用システムに前記第二の業務サービス提供装置を追加しない場合に業務サービス実行システムを運営するときに予想される第一の損益の推移、および前記業務サービス利用システムに前記第二の業務サービス提供装置を追加した場合に業務サービス実行システムを運営するときに予想される第二の損益の推移を算出し、前記第一の損益の推移と前記第二の損益の推移とから、双方の場合を比較して損益分岐点を求める処理を実行させる
    ことを特徴とする業務サービス実行方法。
  18. 業務サービスを提供する第一の業務サービス提供装置に、ネットワークを介して業務サービス利用要求を送信して業務サービスを利用する業務サービス利用装置および前記業務サービス利用要求を、前記第一の業務サービス提供装置に、ネットワークを介して送信し、前記第一の業務サービス提供装置から前記業務サービス利用要求に対する応答を、前記ネットワークを介して受信し、前記業務サービス利用装置による業務サービスの利用および前記第一の業務サービス提供装置による業務サービスの提供を中継する中継装置を有する業務サービス利用システムと、
    前記ネットワークに接続した前記第一の業務サービス提供装置と、
    前記ネットワークに接続され、前記業務サービス利用システムに前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置を追加することを支援する支援装置と、
    を有する業務サービス実行システムのコンピュータとして機能させる業務サービス実行プログラムであって、
    前記中継装置は、
    少なくとも前記業務サービスのアドレスが登録される業務サービスアドレスフィールドを備えるサービスアドレスリストを記憶し、
    前記中継装置の制御手段に、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスが前記第二の業務サービス提供装置に移行されたとき、前記サービスアドレスリストにおいて、前記業務サービスアドレスフィールドに登録された、前記移行された業務サービスと同一の業務サービスのアドレスを、前記登録された業務サービスの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理、を実行させ、
    前記第二の業務サービス提供装置は、
    少なくとも前記業務サービスを実行するために用いる業務データのアドレスが登録される業務データアドレスフィールドを備えるデータアドレスリストおよび前記業務サービス利用装置による業務サービスの利用状況の履歴を示すログを記憶し、
    前記第二の業務サービス提供装置の制御手段に、前記業務サービス利用システムにおいて、前記第一の業務サービス提供装置と同等の機能を備える前記第二の業務サービス提供装置が前記ネットワークに追加され、前記第一の業務サービス提供装置が提供する業務サービスを実行するために用いる業務データが前記第二の業務サービス提供装置に移行されたとき、前記データアドレスリストにおいて、前記業務データアドレスフィールドに登録された、前記移行された業務データと同一の業務データのアドレスを、前記登録された業務データの所在が前記第二の業務サービス提供装置であることを示すアドレスに更新する処理と、
    前記第一の業務サービス提供装置から移行される業務データを受信し、前記移行された業務データに基づいて前記データアドレスリストを更新するように前記第二の制御手段に指示する処理と、
    前記ログおよび前記移行された業務データに基づいて対して所定の演算処理をして、業務サービス利用システムにおける前記業務サービスおよび前記業務データの移行の性能を定めた稼働情報を生成し、前記生成した稼働情報を前記支援装置に送信して前記業務サービスの提供を監視する処理と、を実行させ、
    前記支援装置に、
    前記第二の業務サービス提供装置から前記稼働情報を受信し、前記業務サービスおよび前記業務データの移行の性能を判定し、一定以上の性能が得られた場合には、前記支援装置が備える入力手段から入力された前記業務サービスの移行の移行率に従って前記中継装置に対して前記業務サービスの移行コマンドを送信し、前記入力手段から入力された前記業務データの移行の移行率に従って前記データ同期手段に対して前記業務データの移行コマンドを送信する処理を実行させる
    ことを特徴とする業務サービス実行プログラム。
JP2007265897A 2007-10-11 2007-10-11 業務サービス実行システム、業務サービス実行方法および業務サービス実行プログラム Expired - Fee Related JP4863959B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007265897A JP4863959B2 (ja) 2007-10-11 2007-10-11 業務サービス実行システム、業務サービス実行方法および業務サービス実行プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007265897A JP4863959B2 (ja) 2007-10-11 2007-10-11 業務サービス実行システム、業務サービス実行方法および業務サービス実行プログラム

Publications (2)

Publication Number Publication Date
JP2009093569A true JP2009093569A (ja) 2009-04-30
JP4863959B2 JP4863959B2 (ja) 2012-01-25

Family

ID=40665469

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007265897A Expired - Fee Related JP4863959B2 (ja) 2007-10-11 2007-10-11 業務サービス実行システム、業務サービス実行方法および業務サービス実行プログラム

Country Status (1)

Country Link
JP (1) JP4863959B2 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011150563A (ja) * 2010-01-22 2011-08-04 Accenture Global Services Gmbh クラウドコンピューティング評価ツール
JP2012048386A (ja) * 2010-08-25 2012-03-08 Fujitsu Ltd 配置決定プログラム、方法及び装置
US8782241B2 (en) 2008-11-19 2014-07-15 Accenture Global Services Limited Cloud computing assessment tool
CN113055254A (zh) * 2020-01-10 2021-06-29 深圳优克云联科技有限公司 一种地址配置方法、装置、接入服务器及存储介质

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11143836A (ja) * 1997-11-05 1999-05-28 Nippon Telegr & Teleph Corp <Ntt> アプリケーションプログラム移動位置決定方法及びデータファイル移動位置決定方法並びにその装置
JP2002163241A (ja) * 2000-11-29 2002-06-07 Ntt Data Corp クライアントサーバシステム
JP2004246702A (ja) * 2003-02-14 2004-09-02 Toshiba Corp 計算機システム、計算機装置、計算機システムにおけるデータアクセス方法及びプログラム
JP2005100387A (ja) * 2003-09-02 2005-04-14 Toshiba Corp 計算機システム及びクラスタシステム用プログラム
JP2005182641A (ja) * 2003-12-22 2005-07-07 Hitachi Information Systems Ltd 動的負荷分散システム及び動的負荷分散方法
JP2005250823A (ja) * 2004-03-04 2005-09-15 Osaka Gas Co Ltd 複数コンピュータ運用システム
JP2005353035A (ja) * 2004-05-10 2005-12-22 Hitachi Ltd ストレージシステムにおけるデータ移行
JP2006146476A (ja) * 2004-11-18 2006-06-08 Hitachi Ltd ストレージシステム及びストレージシステムのデータ移行方法
JP2007249470A (ja) * 2006-03-15 2007-09-27 Nec Biglobe Ltd クラスタサーバシステム、課金装置、課金方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11143836A (ja) * 1997-11-05 1999-05-28 Nippon Telegr & Teleph Corp <Ntt> アプリケーションプログラム移動位置決定方法及びデータファイル移動位置決定方法並びにその装置
JP2002163241A (ja) * 2000-11-29 2002-06-07 Ntt Data Corp クライアントサーバシステム
JP2004246702A (ja) * 2003-02-14 2004-09-02 Toshiba Corp 計算機システム、計算機装置、計算機システムにおけるデータアクセス方法及びプログラム
JP2005100387A (ja) * 2003-09-02 2005-04-14 Toshiba Corp 計算機システム及びクラスタシステム用プログラム
JP2005182641A (ja) * 2003-12-22 2005-07-07 Hitachi Information Systems Ltd 動的負荷分散システム及び動的負荷分散方法
JP2005250823A (ja) * 2004-03-04 2005-09-15 Osaka Gas Co Ltd 複数コンピュータ運用システム
JP2005353035A (ja) * 2004-05-10 2005-12-22 Hitachi Ltd ストレージシステムにおけるデータ移行
JP2006146476A (ja) * 2004-11-18 2006-06-08 Hitachi Ltd ストレージシステム及びストレージシステムのデータ移行方法
JP2007249470A (ja) * 2006-03-15 2007-09-27 Nec Biglobe Ltd クラスタサーバシステム、課金装置、課金方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782241B2 (en) 2008-11-19 2014-07-15 Accenture Global Services Limited Cloud computing assessment tool
JP2011150563A (ja) * 2010-01-22 2011-08-04 Accenture Global Services Gmbh クラウドコンピューティング評価ツール
JP2012048386A (ja) * 2010-08-25 2012-03-08 Fujitsu Ltd 配置決定プログラム、方法及び装置
CN113055254A (zh) * 2020-01-10 2021-06-29 深圳优克云联科技有限公司 一种地址配置方法、装置、接入服务器及存储介质

Also Published As

Publication number Publication date
JP4863959B2 (ja) 2012-01-25

Similar Documents

Publication Publication Date Title
JP4251645B2 (ja) 情報処理方法及び装置
JP2009217314A (ja) 情報処理装置、サーバ、データ処理方法、記憶媒体、プログラム
JP2005266916A (ja) サーバ差分管理システム及び情報処理装置の制御方法
JP5271925B2 (ja) キャッシュ情報の更新方法、コンピュータ、プログラムおよび記憶媒体
JP4863959B2 (ja) 業務サービス実行システム、業務サービス実行方法および業務サービス実行プログラム
JP4319971B2 (ja) セッション情報管理システム、セッション情報管理方法およびそのプログラム
JP2016018339A (ja) システム、及びシステムの制御方法
JP6807239B2 (ja) タイムスタンプ管理システム、タイムスタンプ管理方法、およびタイムスタンプ管理プログラム
JP4766127B2 (ja) 情報処理装置、ファイル管理システムおよびプログラム
JP2016144186A (ja) 通信情報制御装置、中継システム、通信情報制御方法、および、通信情報制御プログラム
JP5086820B2 (ja) サービス管理方法とシステムおよびプログラム
JP6205946B2 (ja) サービス提供システム、情報収集方法及びプログラム
JP6021651B2 (ja) 管理システム、管理方法およびコンピュータプログラム
WO2006043322A1 (ja) サーバ管理プログラム、サーバ管理方法、およびサーバ管理装置
US20080055662A1 (en) Computer readable medium, information processing apparatus, image reading apparatus, and information processing system
JP2019212223A (ja) 情報処理システム、およびその制御方法
JP4632450B2 (ja) 通信装置及びその制御方法
JP5026130B2 (ja) メール管理方法およびメール管理システム並びにメール管理プログラム
JP4204493B2 (ja) データ中継プログラム
JP5979223B2 (ja) 分散処理におけるサービス検索方法、プログラム、およびサーバ装置
JP6252114B2 (ja) 印刷制御システム
JP2019128816A (ja) デバイスデータ管理システム、制御方法、およびプログラム
JP7095429B2 (ja) 情報処理装置
JP5498547B2 (ja) バックアップ仲介装置、バックアップ仲介方法及びバックアップ仲介プログラム
JP6000639B2 (ja) 画像処理装置、画像処理装置の制御方法、及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091104

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110421

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111011

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111108

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141118

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees