JP2018010415A - サービス管理システム、方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】ソリューションプログラムを構成する各サービスプログラムの価値を算出する。【解決手段】サービス管理システムは、複数のサービスプログラムの所在と、当該複数のサービスプログラムの組み合わせで構成されるソリューションプログラムとを管理し、ソリューションプログラムを構成する各サービスプログラムの、当該ソリューションプログラムの開発又は運用に対する貢献度を算出し、その算出した貢献度に基づいて、各サービスプログラムの価値を算出する。【選択図】図２

Description

本発明は、サービスを管理する計算機システムに関する。

近年、ビジネスのスピードが高速化しており、ビジネスを支援するＩＴシステムの開発においても高速化が求められている。それに対応するため、クラウドサービスを用いて高速にサービスを開発することも増えてきている。特許文献１には、顧客毎のクラウドサービスの価格を容易に決定可能なクラウドサービス料金提示システムが開示されている。特許文献２には、知識コンテンツの価値をポイント単位で定量化し、組み合わせ利用時の課金方式を確立する知識コンテンツの登録管理システムが開示されている。

特開２０１５−１９１６４６号公報 特開２００４−２２７４３６号公報

特許文献１は、サービス利用時におけるリソース使用量によって料金を算出している。しかし、リソース使用量が必ずしもサービスの価値を正当に評価できるとは限らない。他の指標の方が、サービスの価値をより正当に評価できる場合も多い。また、特許文献２は、ソリューション開発者が、ソリューションを構成する各サービスの価値を評価している。しかし、ソリューション開発者が独自の判断基準で各サービスの価値を評価するため、サービス提供者が納得する評価とならない場合も多い。

そこで本発明の目的は、ソリューションを構成する各サービスの価値を適切に評価するサービス管理システム、方法及びコンピュータプログラムを提供することにある。

一実施例に係るサービス管理システムは、複数のサービスプログラムの所在と、当該複数のサービスプログラムの組み合わせで構成されるソリューションプログラムとを管理し、ソリューションプログラムを構成する各サービスプログラムの、当該ソリューションプログラムの開発又は運用に対する貢献度を算出し、その算出した貢献度に基づいて、各サービスプログラムの価値を算出する。

本発明によれば、ソリューションを構成する各サービスの価値を適切に評価することができる。

管理システムの構成の概要を示す。 情報処理システムが有する機能の例を示す。 サービス等の登録処理例を示すフローチャートである。 サービスプロファイル情報の登録画面の例を示す。 サービスプロファイルテーブルの例を示す。 ソリューション開発処理の例を示すフローチャートである。 ソリューション利用処理の例を示すフローチャートである。 サービスの料金表の一例を示す。

以下の説明では、「ｘｘｘテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。

さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信インターフェイスデバイスのうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ、そのプロセッサを有する装置とされてもよい。プロセッサが行う処理の一部又は全部が、ハードウェア回路で行われてもよい。コンピュータプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

以下、実施例の概要について説明する。

マーケットプレイスなどの場を介してサービスプログラム（以下、単に「サービス」という）を連結させてソリューションプログラム（以下、単に「ソリューション」という）を構築する環境が整いつつある。そして、リソースの利用分だけ課金する従量課金方式によって、サービスの対価を徴収する仕組みも整いつつある。将来は、サービスがマーケットプレイス上で売買され、そのサービスの価値が市場の評価によって決定されることも想定される。

また、企業で生成されるデータが市場で売買されることも想定される。従来、企業内のデータは、コンプライアンス等の問題から、その企業内でのみ利用されていた。しかし近年は、事業の幅を広げるために、企業グループ間でデータを交換することも始められている。

また、一企業が所有するだけでは１つの点に過ぎないデータを、複数の企業から収集してまとめて分析することにより、１つのデータからではわからなかった特性や傾向を導出することも考えられる。そして、その導出された特性や傾向を情報化することによって、新たなサービスを創出することも考えられる。例えば、ＮＤＡ（Ｎｏｎ−Ｄｉｓｃｌｏｓｕｒｅ Ａｇｒｅｅｍｅｎｔ）を結んだグループ内の同業他社間においてデータを交換し、その交換したデータを本業に活用することも考えられる。

将来は、業務を構成するサービス及びデータが同業他社などの垣根を超えて市場で売買され、便利な新しいサービスが次々と提供されることも考えられる。

そのような中で、市場で取引されるサービス及びデータは、その技術的価値又は希少性等によって高値がついたり、市場のニーズによって価値が定義されたりすることが考えられる。すなわち、これまではサービス及びデータの提供者が対価を設定していたが、今後は市場のニーズによって価値が決定されることが考えられる。

上述のような状況を踏まえ、本実施例に係るサービス管理システムは、サービス毎、及び／又は、複数のサービスから構成されるソリューション毎の料金表を管理し、サービスの利用条件とサービス利用者の属性情報とのマッチング度合、及び／又は、サービスの市場価値などを考慮しながら、サービスの価格を設定する。

このようなサービス管理システムを提供することにより、高速なビジネススピードに合わせてＩＴシステムを開発することが容易になる。また、サービスの売買が可能なマーケットプレイスを提供することができる。これにより、サービスの流通が促進され、サービスの新陳代謝が活性化され、新しいサービスが次々と生まれる可能性が高くなる。また、サービス及びソリューションを適切に測定及び評価することにより、高品質のサービスが短いサイクルで生まれる可能性が高くなる。

例えば、サービス提供者（関係会社又はサードパーティなど）は、開発したサービスをマーケットプレイス上に登録する。ソリューション開発者は、サービス提供者とサービス使用料（例えばライセンス料）を締結し、サービスを組み合わせてソリューションを開発し、その開発したソリューションを顧客へ提供する。このような場合において、従来は、ソリューション開発者が、顧客から徴収したソリューション利用料とは無関係に、その締結したサービス使用料をサービス提供者に支払う場合が多かった。しかしそれでは、ソリューション開発者が事業責任のリスクをとることになってしまう。すなわち、ソリューション開発者は、将来、大きなビジネスになる可能性のあるアイデアを得ても、初期投資のリスクが大きいため、それを実行に移し難い。これでは、新しいビジネスを生みだすための場としてのマーケットプレイスが活性化しない。

また、サービスの利用時間に応じて課金する従量課金も考えられる。例えば、モバイル通信サービスにおいて、通信パケット単位の料金が設定されており、送受信したパケット数（つまり通信量）に応じて課金される従量課金プランが知られている。これは、ユーザとモバイル通信サービス会社との間の契約に応じてパケット単価が異なり、また、その契約内容に対応する料金表に基づいて使用料が算出される。ユーザが送受信したパケット数と、パケットが発生した時刻とを記録しておくことにより、契約内容が変更されても利用料を算出することができる。しかし、サービス及びデータの価格が市場価値によって変動する場合、パケット数だけを管理しても、最終的な利用料を算出することはできない。

複数の当事者が存在するとき、サービス及びデータをカテゴライズし、２つのカテゴリの一方に対する他方の価値の倍率を設定し、市場の取引量に応じて倍率を変動させる仕組みを取り入れてもよい。すなわち、為替のような仕組みを取り入れてもよい。このときの取引量は、交換したパケット量でもよいし、トランザクション量でもよい。

マーケットプレイスにおいて、ソリューション、及び、そのソリューションを構成するサービス及びデータは、市場によって価値が評価されてよい。サービスは、ソリューションに対する貢献度によってその価値が評価されてよい。これにより、サービスが様々な観点から評価されるようになり、マーケットプレイスが活性化される可能性が高まる。

本実施例に係る管理システムは、上述の内容を実現するために、サービス評価機能、利用料決定機能、マッチング機能、及び、チェイニング機能を有してよい。

サービス評価機能は、ソリューションに対する貢献度及び／又は市場評価などによって、サービス及び／又はデータの価格を決定してよい。以下、サービス及び／又はデータをまとめてサービス等と表現する場合がある。サービス評価機能は、マーケットプレイスにおけるマッチング成功率、機能異常の報告の多寡、信頼性の高低、及び／又は、顧客からのクレーム数、などに基づいて、サービスの評価（例えばポイント）を算出してよい。

サービス価格は、上記の評価ポイントとサービス単価との積に基づいて決定されてもよい。市場価格は、サービス価格＋αとして決定されてもよい。

ソリューションに対する貢献度は、ソリューション開発者が初期値を設定した後、顧客の利用状況、及び／又は、ソリューション開発者とサービス提供者との間の交渉などにより、変動してよい。

データ評価機能は、上記のサービス評価機能と同様、マッチング成功率、及び／又は、データの希少性などにより、データの評価を算出してよい。

以下、上述の内容に係る実施例について説明する。

図１は、本実施例に係る管理システム１の構成の概要を示す。

管理システム１は、登録端末１０１と、開発端末１０３と、利用端末１０２と、情報処理システム１００とを有してよい。

登録端末１０１は、サービス提供者及び／又はデータ提供者が、情報処理システム１００にサービス及び／又はデータを登録するために利用する。以下、サービス提供者及び／又はデータ提供者をまとめてサービス等提供者と表現することがある。

開発端末１０３は、ソリューション開発者が、情報処理システム１００に登録されたサービス又はデータを利用してソリューションを構成するために利用する。

利用端末１０２は、ソリューションの利用者が、情報処理システム１００に対して、利用登録／解除、及び決済などを行うために利用する。

情報処理システム１００は、当該システムに登録されたサービス等を管理する。情報処理システム１００は、プロセッサ１００、メモリ１１２、ストレージ１１３、及び、ネットワークＩ／Ｆを有してよい。これらの構成要素は、双方向通信可能な内部バスで接続されてよい。情報処理システム１００の有する各種機能は、メモリ１１２及び／又はストレージ１１３に格納されたプログラムがプロセッサ１１１で実行されることにより、実現されてよい。メモリ１１２の例は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）及びＲｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。ストレージ１１３の例は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。ネットワークＩ／Ｆは、ネットワーク３を介するデータの送受信を制御する。ネットワーク３は、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）及び／又はＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等であってよい。

登録端末１０１から登録されたサービス等が情報処理システム１００の外部に存在する場合、当該サービス等が蓄積されている外部システムと、ソリューション開発者から提供されたソリューションと、利用者が所有するシステムとが連結してもよい。この連結構成は、利用者の情報処理システムが存在する利用者システム１０４によって構成されてもよい。マーケットプレイスを提供する管理システム１の構成要素は、ネットワーク３によって接続されてよい。

利用端末１０２、登録端末１０１、及び開発端末１０３は、それぞれ、プロセッサ、メモリ、ストレージ、入力Ｉ／Ｆ、出力Ｉ／Ｆ、及びネットワークＩ／Ｆを有してよい。これらの構成要素は、双方向通信可能な内部バスで接続されてよい。メモリには、データ及びプログラムが格納される。メモリの例は、ＤＲＡＭ、ＭＲＡＭ及びＦｅＲＡＭである。ＣＰＵは、メモリからデータ及びプログラムを読み出して実行することにより、端末の有する各種機能を実現する。出力Ｉ／Ｆは、ＣＰＵの実行結果に関する情報を出力する。出力Ｉ／Ｆの例は、ディスプレイモニタ及びスピーカ等である。入力Ｉ／Ｆには、端末の使用者から各種情報が入力される。入力Ｉ／Ｆの例は、キーボード、マウス及びマイクなどである。ストレージには、データ及びプログラムが格納される。ストレージの例は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤなどである。ネットワークＩ／Ｆは、ネットワーク３を介するデータの送受信を制御する。各端末は、ネットワーク３を介して、外部の情報処理装置とデータを送受信してよい。

情報処理システム１００、利用者システム１０４、及び外部システム１０５は、それぞれ、クラウドシステム上に構成された業務システムであっても良いし、オンプレミスで構成された業務システムであってもよい。これらのシステムは、所定のネットワークを介して接続されている複数のサーバ及びストレージによって構成されてよい。サーバ及びストレージは、いわゆる仮想サーバ及び仮想ストレージであってもよい。利用者システム１０４及び外部システム１０５は、所定のネットワークを介してデータを送受信することによって連結してよい。

図２は、情報処理システム１００が有する機能の例を示す。

情報処理システム１００は、機能として、カタログ機能２０１と、チェイニング機能２０６と、開発環境機能２０５と、利用料決定機能２０４と、サービス評価機能２０７と、マッチング機能２０３と、プロファイル分析機能２０２とを有してよい。情報処理システム１００は、データとして、料金表ＤＢ（ＤａｔａＢａｓｅ）２０８と、サービス利用量ＤＢ２０９と、提供者情報ＤＢ２１０と、プロファイルＤＢ２１１とを有してよい。

カタログ機能２０１は、開発端末１０３から、ソリューションの開発に利用可能なサービス等を閲覧可能とする機能を提供する。

チェイニング機能２０６は、カタログ機能２０１から選択したサービス等を連結させてソリューションを構成するための機能を有する。

開発環境機能２０５は、チェイニング機能２０６によってサービス等同士を連結させてソリューションを開発する際に必要となる、サービス間のデータ変換機能（インタフェースプログラム）を開発するための環境を提供する機能を有する。また、開発環境機能２０５は、その連結させたソリューションをクラウドシステム上等にデプロイメントするための機能を有してもよい。

マッチング機能２０３は、ソリューションの要件と、登録端末１０１から入力されたサービス等のプロファイルとを評価し、ソリューションの要件に適合する可能性のあるサービス等を抽出する機能を有する。マッチング機能２０３は、その抽出したサービス等を、一覧として出力する機能を有してもよい。

利用料決定機能２０４は、サービス等の利用料を決定するための機能を有する。利用料決定機能２０４は、その決定した利用料を利用者から徴収するための根拠となるデータを導出する機能を有してもよい。利用料決定機能２０４は、その決定した利用料を、どのような契約形態で利用者から徴収するかを決定するための機能を有してもよい。

サービス評価機能２０７は、ソリューションを構成する各サービスを評価する機能を有する。サービス評価機能２０７は、料金表に記載された根拠となるデータを収集するための機能を有してもよい。

チェイニング機能２０７は、ソリューションを開発するにあたって、複数のサービスを連結させるための機能を有する。

料金表ＤＢ２０８は、ソリューションの利用者ごとに決定した料金と、利用料を収集する根拠となるデータ等とを保持する。

サービス利用量ＤＢ２０９は、サービス評価機能２０７によって収集された、利用料を徴収する根拠となるデータを保持する。

提供者情報ＤＢ２１０は、サービス提供者に関する情報を保持する。

プロファイルＤＢ２１１は、サービス等のプロファイル情報を保持する。

上述の機能及びデータの更なる説明については後述する。

次に、図２を参照しながら、本実施例に係るサービスの概要を説明する。

（Ａ１）サービス等の提供者は、登録端末１０１を通じて、提供可能なサービス等を情報処理システム１００に登録する。

（Ａ２）サービス等の提供者は、登録端末１０１を通じて、それら登録するサービス等のプロファイル情報も情報処理システム１００に登録する。

（Ａ３）ソリューション開発者は、情報処理システム１００の開発環境機能２０５を利用して、その情報処理システム１００に登録されているサービス等を用いてソリューションを開発する。このとき、開発者は、ソリューションの要件を入力してもよい。情報処理システム１００は、そのソリューションの要件に適合するサービス等の候補の一覧を、開発端末１０３に出力してよい。

（Ａ４）開発者は、この候補の一覧から、より要件に適合するサービス等を選択し、ソリューションのコンポーネントセットを開発する。

（Ａ４）開発者は、情報処理システム１００の開発環境機能２０５を利用してサービス同士を連結させ、ソリューションを開発する。このとき、開発者は、開発環境機能２０５を利用して、サービス間を連結するためのインタフェースを開発してよい。開発者は、その開発したソリューションを、情報処理システム１００に登録する。

（Ａ５）ソリューションの利用者は、利用端末１０２を通じて、情報処理システム１００に要件を入力し、その要件に適合するソリューションを検索する。そして、利用者は、その検索によって見つけた所望のソリューションを利用してよい。

（Ａ６）情報処理システム１００は、利用者がソリューションを利用するとき、ソリューションを評価するためのデータ、及び、ソリューションを構成する各サービスを評価するためのデータなどを計測する。そして、情報処理システム１００は、例えば決済日に、ソリューションの利用者に対して、ソリューション及び／又はサービスの料金表に基づいて、決済処理を行う。

図３は、サービス等の登録処理例を示すフローチャートである。

サービス提供者は、登録端末１０１を介して、情報処理システム１００に対して、サービス提供者情報の登録要求を発行する（ステップ３０１）。サービス提供者情報は、サービス提供元の住所及び担当者名、並びに、決済に必要な情報を含んでよい。情報処理システム１００は、サービス提供者情報の登録が完了すると、その提供者の登録端末１０１に対して、当該提供者に付与したＩＤ（サービス提供者ＩＤ）を通知してよい。

情報処理システム１００は、登録端末１０１から発行されたサービス提供者情報を、提供者情報ＤＢ２１０に登録する（ステップ３０２）。

サービス提供者は、登録端末１０１を介して、情報処理システム１００に対して、サービスプロファイル情報の登録要求を発行する（ステップ３０３）。情報処理システム１００は、登録端末１０１から発行されたサービスプロファイル情報を、プロファイルＤＢ２１１に登録する。サービスプロファイル情報は、登録されたサービスを識別するための情報、及び、ソリューション開発者からの要件とのマッチングに必要となる情報を含んでよい。

情報処理システム１００は、プロファイル分析を行う（ステップ３０４）。プロファイル分析とは、例えば、ソリューションのアジャイル開発における、イテレーション数の増減とサービスプロファイル情報との関係を分析することであってよい。又は、プロファイル分析は、サービスのコード量とソリューション品質との関係を分析することであってよい。又は、プロファイル分析は、過去の実績データに基づいて、ソリューションとの適合性及び問題が発生しやすい箇所を推測することであってよい。又は、プロファイル分析は、これらの少なくとも２つ以上の組み合わせであってもよい。情報処理システム１００は、この分析結果を、サービスプロファイル情報に含めて保持してよい。この保持されたサービスプロファイル情報は、ソリューション開発者からの要件とのマッチングに利用されてよい。これにより、ソリューション開発者が、比較的少ない工数で問題の少ないソリューションを開発できる可能性が高まる。

サービス提供者は、登録端末１０１を介して、情報処理システム１００にサービスイメージを登録する（ステップ３０５）。サービスイメージは、別な開発環境機能２０５で開発されたものであってもよいし、情報処理システム１００の開発環境機能２０５を利用して開発されたものであってもよい。サービスイメージの登録とは、サービスに係るＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）又はコンテナを、情報処理システム１００にデプロイすることであってもよい。

情報処理システム１００は、サービス提供の準備を行う（ステップ３０６）。例えば、情報処理システム１００は、実行環境（例えばＣｌｏｕｄ Ｆｏｕｎｄｒｙなど）上で、ステップ３０５においてデプロイしたサービスイメージを起動し、サービスプロファイル情報に設定されているリソースを割り当ててもよい。

サービス提供者は、登録端末１０１を介して、サービス公開に関する設定を行う（ステップ３０７）。例えば、サービス提供者は、サービス公開の範囲及び期間などを設定する。

情報処理システム１００は、そのサービス公開の設定に従うように、サービスプロファイル情報を更新する（ステップ３０８）。

情報処理システム１００は、そのサービス公開の設定に適合するソリューション開発者に対して、当該サービスが公開されたことを通知する（ステップ３０９）。通知はどのように行われてもよい。例えば、開発端末１０３へのプッシュ配信、又は、開発者が情報処理システム１００にログインしたタイミングでの通知などであってよい。

開発者は、ステップ３０９の通知を受領することにより、そのサービスの公開を知ることができる（ステップ３１０）。

図４は、サービスプロファイル情報の登録画面４００の例を示す。図５は、サービスプロファイルテーブル５００の例を示す。

サービスプロファイルテーブル５００は、サービスプロファイル情報を管理するためのテーブルである。サービスプロファイル情報は、ステップ３０４で記載したプロファイル分析の元になる情報である。サービスプロファイルテーブル５００は、サービスプロファイルＤＢ２１１に格納されてよい。

サービスプロファイル情報は、データ項目として、プロファイル名５０１、サービス名５０２、サービスカテゴリ５０３、課金種別５０４、サービス評価データ５０５、公開先種別５０６、サービスＵＲＬ５０７、サービスイメージ５０８、機能又は性能対応情報５０９、製品対応情報５１０、インタフェース５１１、ソリューション利用実績５１２、重点イテレーション名５１３、及び、注意事項５１４を有して良い。

プロファイル名５０１には、サービスプロファイル情報を識別するための情報が格納される。

サービス名５０２には、サービスの名称が格納される。このサービス名５０２は、サービスの公開時に表示されてよい。

サービスカテゴリ５０３には、サービスのカテゴリを示す情報が格納される。サービスカテゴリ５０３には、サービス名のサービスが、ＤＢのような蓄積サービスなのか、データ間の依存関係を分析するサービスなのか、又は、利用者システムで発生したデータを情報処理システム１００に送信する送受信サービスなのか、などを識別するための情報が格納されてよい。

課金種別５０４には、サービスの課金の方法（種別）を示す情報が格納される。

サービス評価データ５０５には、サービスの評価又は利用料の算出に用いるデータの情報が格納される。

公開先種別５０６には、サービスの公開範囲を示す情報が格納される。

サービスＵＲＬ５０７には、サービスのアクセス先のＵＲＬ（サービスの所在）が格納される。

サービスイメージ５０８には、サービスが搭載されたＶＭ又はコンテナのイメージデータの所在などを示す情報が格納される。

機能又は性能対応情報５０９には、サービスの機能又は性能の対応情報を示す情報が格納される。

製品対応情報５１０には、サービスが利用可能な言語体系及び／又はサポート範囲等の商流を示す情報が格納される。

インタフェース５１１には、サービスの入出力に関するプロトコル又はフォーマットを示す情報が格納される。

ソリューション利用実績５１２には、サービスが過去にどのようなソリューションに利用されたことがあるのかを示す情報が格納される。

重点イテレーション５１３には、ソリューション利用実績５１２のソリューションをアジャイル開発した際に、当該サービスが関連したイテレーションを示す情報が格納される。

注意事項５１４には、重点イテレーション５１３のイテレーションで発生した問題点、及び／又は、分析により導出された注意点などの情報が格納される。

サービス提供者によって登録されるサービスプロファイル情報とは別に、情報処理システム１００の内部で管理されるサービスプロファイル情報（内部サービスプロファイル情報）も存在してよい。内部サービスプロファイル情報には、ソリューション開発時の問題点として登録されたデータとの依存関係に関する情報が含まれてよい。この依存関係は、ソリューション開発者がサービスを利用してソリューションを開発した際の実績データに基づいて導出されてよい。

情報処理システム１００は、開発時の暗黙知として、この内部サービスプロファイル情報を管理してよい。そして、情報処理システム１００は、イテレーション数を少なくできるようなＴＩＰＳなどを、当該サービスを利用する開発者に提供してよい。これにより、ソリューションのアジャイル開発時におけるイテレーション数を削減し得る。情報処理システム１００は、サービスプロファイル情報及び内部サービスプロファイル情報を、プロファイルＤＢ２１１において管理してよい。

次に、情報処理システム１００の開発環境機能２０５について説明する。開発環境機能２０５は、サービス又はソリューションを開発する際に利用可能な様々な機能を提供する。開発環境機能２０５は、開発者がソリューションを開発するために必要な開発言語のランタイム、実行環境及びサービス開発を簡易化するツール、及び、サードパーティーが提供するサービス、などを提供してよい。ツールの例としては、開発したソリューションのオペレーション画面の開発を簡易化するダッシュボードのテンプレートがある。ツールの他の例としては、サービス間を接続するためにインタフェースを変換して接続するＮｏｄｅ−ＲＥＤやＰｅｎｔａｈｏ ＤＩなどがある。開発環境機能２０５は、開発されたソリューションに係るイメージを、ＶＭ又はコンテナに載せ、適切な実行環境にデプロイする機能も提供してよい。

次に、情報処理システム１００のカタログ機能２０１について説明する。カタログ機能２０１は、情報処理システム１００に登録されているサービス、データ、及び／又は、ソリューションを、端末に公開する機能を有する。カタログ機能２０１は、図４のようなサービスプロファイル情報の登録画面４００を、登録端末１０１に提供してよい。カタログ機能２０１は、プロファイル分析機能２０２とサービスプロファイル５００とに基づいて、図３のようなサービス等の登録処理を実行してもよい。

次に、情報処理システム１００のチェイニング機能２０６について説明する。チェイニング機能２０６は、開発環境機能２０５を利用してソリューションを開発する際に、サービス間の処理フローと、サービス間のインタフェースのフォーマット変換のロジックとを記載することにより、ソリューションを開発することを可能とする機能を有する。例えば、開発環境機能２０５において、Ｎｏｄｅ−ＲＥＤやＰｅｎｔａｈｏ ＤＩを利用することによって処理の順序を規定し、フォーマット変換もツールの中で定義して処理させることによって、複数のサービス間を連携させ、ソリューションを開発する。

ただし、サービスが別々の言語で開発されており、其々のサービスの実行環境が異なる場合、全てのサービスを連結させることは難しい。そこで、サービス間の連結インタフェースには、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）などのアプリケーション層のインタフェースを利用してよい。これにより、各サービスの実行環境に対する依存性がなくなり、外部システム又は利用者システムと連結することが可能になる。

情報処理システム１００は、各サービスの料金表に登録されているサービス評価データを取得することにより、各サービスの課金の根拠を測定してよい。また、情報処理システム１００は、ＶＭ又はコンテナを用いて複数の同じサービスを動作させることも可能である。

チェイニング機能２０６は、サービスの入出力であるデータストリームと、そのデータストリームを処理したＶＭ又はコンテナと、を対応付けて管理してよい。これにより、情報処理システム１００は、ソリューション利用者のＩＤに紐づけて、ソリューションの処理をモニタリングすることができる。

情報処理システム１００は、サービスの入出力データを、利用料を算出するための評価データとして利用する場合、ソリューション利用者のＩＤと紐付けられたトランザクションデータ又は交換したパケットデータを、評価データとしてもよい。

次に、情報処理システム１００のマッチング機能２０３について説明する。マッチング機能２０３は、ソリューションの要件に適合するサービス等の組合せを返す機能である。情報処理システム１００は、カタログ機能２０１によって登録されたサービス等と、そのサービスプロファイル情報とを合わせて登録する。情報処理システム１００は、既に登録されているサービスプロファイル情報に基づき、ソリューションとの依存関係を分析してもよい。そして、情報処理システム１００は、新規サービスが登録された場合、その新規サービスと同じ傾向を有する既存のサービスを特定してよい。そして、情報処理システム１００は、その特定した既存のサービスを利用した過去のソリューションの開発において、インタフェースの調整が難しかった、テストの段階で問題が発生した、又は、イテレーションが延長されたなど、何らかの問題が発生したことがあるか否かを確認してよい。そして、情報処理システム１００は、この新規サービスを利用するソリューション開発者に対して、当該新規サービスと同じ傾向を有する既存のサービスにおいて発生した上述のような問題を提示し、注意喚起を行ってもよい。

また、データ登録時において、マッチング機能２０３で提供される相関分析を実施するＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）が、マッチング機能２０３に与えられる目的関数に対してデータ間の相関分析を行ってもよい。相関を取るデータは、マーケットプレイス上に登録された様々なデータであってよい。そして、ＡＩは、目的関数を基に、関連するデータ項目を抽出してよい。そして、ＡＩは、それによって得られた依存関係を有する複数のデータ項目を利用して、新しいサービスを提供してよい。サービスの例は、機器保守サービスである。機器保守サービスでは、保守対象の機器に接続された様々なセンサによって収集される大量のデータ項目が存在する。例えば、１つの機器に１万点程度のセンサが付与されることもある。その大量のデータ項目から、機器の異常に対して何らかの依存関係が存在するデータ項目を、人間が手動で抽出することは難しい。そこで、上述のようなＡＩを用いてデータの依存関係を自動的に分析し、それらのデータ項目を人間が評価したり、他の分析ツールで分析したりする。これにより、異常の原因究明が容易になる。

次に、情報処理システム１００のサービス評価機能２０７について説明する。サービス評価機能２０７は、料金表に記載されているサービスの課金対象となる利用履歴を収集し、ソリューションの利用料を算出する。また、サービス評価機能２０７は、例えば決済日に、ソリューション利用者に対して、その算出した利用料を請求する。この利用料の算出において、ソリューションを構成する各サービス等の、当該ソリューションに対する貢献度が用いられてよい。そして、各サービスの決済価格は、その貢献度に基づいて算出されてよい。

ソリューションに対する貢献度とは、開発時及び／又は運用時における、サービスのソリューションに対する貢献度であってよい。貢献度は、サービスを用いた場合の開発容易性及び／又は運用容易性などを評価する値であってもよい。又は、貢献度は、開発におけるイテレーションの短縮を評価する値であってもよい。又は、貢献度は、障害が発生せずに継続的にソリューションを提供し続けることを評価する値であってもよい。又は、貢献度は、ソリューションの売上に対するサービスの影響を評価する値であってもよい。ソリューションに含まれる各サービス等に対する報酬の比率は、サービスの貢献度に基づいて決定されてよい。

ソリューション提供の当初において（ソリューション登録時に）、貢献度は、そのソリューションに含まれる各サービス等に等分に配分されても良いし、ソリューション開発者がその配分を決定してもよい。貢献度の配分は、ソリューションが多くの利用者に利用されるにつれて、適宜変更されてよい。例えば、情報処理システム１００は、所定の期間、ソリューションの利用状況をモニタリングし、そのモニタリング結果から、各サービス等がソリューションの売り上げにどの程度貢献しているかを評価し、その評価に応じて、各サービス等に対する貢献度を再配分してよい。

例えば、或るサービスの障害によってソリューション運用を一時停止する状況が発生したとする。その場合、情報処理システム１００は、そのサービスに配分していた貢献度の一部を、残りのサービスへ等分に再配分してもよい。

例えば、イテレーションを回して機能を拡張していくアジャイル開発において、或るサービスに新規のサービスを容易に連結できたため、イテレーション期間が短縮されたとする。その場合、情報処理システム１００は、当該或るサービスに、他のサービスに配分していた貢献度の一部を再配分してよい。

上述の再配分及び評価は、ソリューション利用に対する決済のタイミングで実行されてもよい。このようにして、ソリューションに対する各サービス等の貢献度は調整される。なお、サービスの売上は、ソリューションへの貢献度の他に、市場価格によっても左右され得る。

図６は、ソリューション開発処理の例を示すフローチャートである。

ソリューション開発者は、開発端末１０３を通じて、情報処理システム１００に、ソリューション開発者情報を送信する。ソリューション開発者情報は、ソリューションの提供元の住所、担当者名、及び、決済に必要な情報などを含んでよい。情報処理システム１００は、そのソリューション開発者情報を受領すると、開発端末１０３に対して、ソリューション開発者を識別するためのＩＤを返信する（ステップ６０１）。

情報処理システム１００は、開発端末１０３から受領したソリューション開発者情報を、提供者情報ＤＢ２１０に登録する（ステップ６０２）。

ソリューション開発者は、開発端末１０３を通じて、情報処理システム１００に、ソリューションに関する情報（ソリューション情報）を送信する。ソリューション情報は、ソリューションを識別するためのＩＤ、及び、ソリューションを構成するサービスとのマッチングに必要となる情報などを含んで良い（ステップ６０３）。

情報処理システム１００は、その送信されたソリューション情報を、サービスプロファイルＤＢ２１１に登録する（ステップ６０４）。

ソリューション開発者は、開発端末１０３を通じて、ソリューション要件を入力する。ソリューション要件は、情報処理システム１００に登録されているサービスの中から、要件に適合するサービスを抽出するために必要な情報を含んで良い（ステップ６０５）。

情報処理システム１００は、登録されている複数のサービスの中から、その入力されたソリューション要件に適合するサービスを、サービス候補群として抽出する（ステップ６０６）。

情報処理システム１００は、ステップ６０６で抽出したサービス候補群と、ステップ６０５で入力されたソリューション要件と、ステップ６０３で入力されたソリューション情報と、サービスプロファイル情報とに基づいて、ソリューション開発において問題が発生しやすい観点を導出する（ステップ６０７）。

情報処理システム１００は、その抽出したサービス候補群と、その導出した問題が発生しやすい観点とを、開発端末１０３へ送信する（ステップ６０８）。

開発端末１０３は、情報処理システム１００から受領した、そのサービス候補群と、問題が発生しやすい観点とを合わせて表示する。ソリューション開発者は、その問題が発生しやすい観点を参考にしながら、ソリューション開発に利用する複数のサービスを選択する（ステップ６０９）。

ソリューション開発者は、ステップ６０９で選択した複数のサービスを連結させてソリューションを開発する（ステップ６１０）。このとき、ソリューション開発者は、サービス同士を連結させるためのインタフェース部分を、開発環境機能２０５が提供するツールを用いて開発してよい。

ソリューション開発者は、ソリューションの開発に使用した各サービスの貢献度を設定する（ステップ６１１）。上述の通り、各サービスの貢献度は、ソリューション開発者によって設定されてもよいし、自動的に均等に設定されてもよい。しかし、ソリューションの稼働中に、或るサービスが安定に動作しなかったり障害を発生させたりする可能性がある。スピード重視で開発されたサービスは、十分に動作が検証されていない可能性もある。すなわち、ソリューションの稼働に影響を及ぼすサービスも存在し得る。情報処理システム１００は、このようにソリューションの稼働に問題を発生させたサービスの貢献度を下げてもよい。情報処理システム１００は、このように問題が発生したサービスの提供者に対して、問題点を報告してもよい。これにより、サービス提供者に対して、早期の対策及びサービスの改善を促すことができる。

ソリューション開発者は、開発端末１０３を通じて、情報処理システム１００に、開発したソリューションを登録する（ステップ６１２）。ここで登録される情報は、例えば、サービスの処理手順、サービス同士を連結するためのインタフェース部分、及び、各サービスの貢献度などであってよい。

情報処理システム１００は、開発端末１０３から、ソリューションの登録情報を受領すると、当該ソリューションの提供の準備を行う（ステップ６１３）。

ソリューション開発者は、開発端末１０３を通じて、そのソリューションを公開設定する（ステップ６１４）。

情報処理システム１００は、開発端末１０３からソリューションの公開設定がなされると、当該ソリューションの登録されているカタログ機能２０１と、チェイニング機能２０６とに対して、公開設定情報を登録する（ステップ６１５）。

これにより、ソリューション開発者によって開発されたソリューションが、情報処理システム１００に登録及び公開される。

図７は、ソリューション利用処理の例を示すフローチャートである。

情報処理システム１００は、ソリューションの公開が設定されると、その設定された公開の期間、ソリューションを公開する（ステップ７０１）。

情報処理システム１００は、事前に設定されている、利用者システム１０４とソリューションとの間のインタフェースを利用して、データを送信する（ステップ７０２）。ここで定義されるソリューションの例は、利用者システム１０４における業務システムの稼働情報を収集し、生産量を最大化し、かつ、最適なエネルギーで稼働するソリューションなどである。

情報処理システム１００は、ソリューションの利用開始後、ソリューション利用者毎の、各サービスに係る評価データを取得する（ステップ７０３）。評価データは、サービスの利用状況を計測するために設定された課金単位に依存するものであってよい。なお、ソリューション利用者のＩＤに紐づけて利用者システムから送受信されるデータと、ソリューションを構成する各サービスの入出力データとを統合的に管理するチェイニング機能２０６によれば、トランザクション又は送受信パケットも評価データとなる。

情報処理システム１００は、評価データを、随時サービス利用量ＤＢ２０９に登録する（ステップ７０４）。

例えば決済の締め日に、情報処理システム１００は、蓄積された評価データからソリューション利用者ＩＤに紐づく評価データを抜き出し、サービスの料金表に従って、ソリューション利用者に請求する金額を算出する（ステップ７０５）。ソリューション利用者に請求するトータルの金額は、評価データとして測定された課金単位数と、料金表に記載された課金単価と、ソリューションへの貢献度と、に基づいて決定されてよい。上述の通り、各サービスの貢献度は、ソリューションに対する貢献度に基づいて決定されてよい。ソリューションに含まれる各サービスの貢献度は、合計されると「１００」となってよい。サービス提供者は、ソリューション開発者から、サービスの利用料を受け取る。このサービスの利用料は、課金単位と課金単価の積として算出されてもよい。又は、このサービスの利用料は、市場評価分によって調整されたものであってもよい。サービス提供者は、ソリューションに対するサービスの貢献度に応じて、追加の料金を受け取ってよい。貢献度に応じて支払う料金は、ソリューション開発者が決めてもよい。サービス提供者は、最終的に、サービスの利用料と、サービスの貢献度に応じた追加分の料金とを受け取ってよい。ソリューション提供者は、サービス提供者と交渉して、貢献度に応じた料金の支払いを不要とした場合には、ソリューションに紐づくサービスの貢献度を「０」に設定してもよい。

情報処理システム１００は、ステップ７０５で算出した決済情報を、ソリューション利用者へ通知する（ステップ７０６）。例えば、情報処理システム１００は、ソリューション利用者のメールアドレス宛にその決済情報を送信する。

情報処理システム１００は、例えば指定日に、その確定した支払い請求を執行する（ステップ７０７）。

情報処理システム１００は、ソリューションの利用期間が終了するまで、上述の計測と決済を、繰り返し行う（ステップ７０８）。

情報処理システム１００は、ソリューションの公開期間経過後、ソリューションを非公開とし、チェイニング機能２０６の計測を終了する（ステップ７０９）。

図８は、サービスの料金表９００の一例を示す。

サービスの料金表９００は、データ項目として、サービス名９０１、評価データ種別９０２、課金単位９０３、課金単価９０４、市場評価分９０５、及び、市場評価分種別９０６を有してよい。ソリューションに組み込まれたサービスの料金表９００は、データ項目として、そのソリューションに対する貢献度９０７をさらに有してよい。

サービス名９０１には、課金対象となるサービスの名称が格納される。サービス名９０１には、サービスを識別可能なＩＤが格納されてもよい。

評価データ種別９０２には、課金単位として計測されるデータの種別が格納される。評価データ種別９０２の例は、サービスの利用回数、サービスのトランザクション数、及び、送受信したパケット数等である。

課金単位９０３には、計測される評価データにおいて１単位とされる換算値が格納される。

課金単価９０４には、課金単位９０３の１単位分の価格が格納される。

市場評価分９０５には、市場評価によるマージンが格納される。マージンは、市場の評価が高ければ大きくなり、市場の評価が低ければ小さくなってよい。

市場評価分種別９０６には、市場評価分９０５を、１単位の価格に対して反映させるのか、それとも、決済時における割増割引率として反映させるのか、などを識別するための情報が格納される。

サービスがソリューションに組み込まれると、上述の貢献度９０７がデータ項目として、サービスの料金表９００に追加されてよい。この貢献度９０７も、サービスの価格に反映されてよい。

プライシング方法の例は、競合基準方式、コスト基準方式、及び、マーケティング戦略基準方式などがある。さらなる例としては、データそのものの価値を交換する為替方式、及び、仮想評価方式などがある。

競合基準方式は、市場から一番近いサービス等を探し出し、その探し出したサービス等の価格帯から登録したサービス等の価格を算定する。競合基準方式はさらに、市場価格追従法、プライスリーダ追従法、及び、慣習価格法に分類される。競合基準方式を採用する場合、サービス登録をしたときに設定したサービスカテゴリの情報を元に、同一のカテゴリに存在する他のサービスの価格帯を参考にしてプライシングを行ってよい。したがって、競合基準方式を採用する場合は、価格に対する顧客からのフィードバックについてはあまり考慮せず、サービスの利用数（一定期間内の利用数）を評価データとしてモニタリングするとよい。

コスト基準方式は、サービスの開発コストに係る変動費及び固定費に基づいて利益を設定し、その設定した利益を確保するためのサービス提供期間及びサービス利用量を想定し、その想定に基づいて、サービス価格を決定する。次々と新しいサービスが提供されるマーケットプレイスにおいて、利益確保するためのサービス提供期間の設定は、市場の動向に左右される。そのため、最初は比較的高めの価格に設定し、市場の動向を見ながら値下げを行い、利用率向上に向けた施策が求められる。したがって、コスト基準方式を採用する場合も、サービスの利用数を評価データとしてモニタリングするとよい。

マーケティング戦略基準方式は、現在の対抗するサービスに対して自分のサービスが何倍の価値があるかを算出し、それを価格に反映させる。同サービスカテゴリ内において、他のサービスの価格と、当該他のサービスと自分のサービスとの間の付加価値の差分に基づいて、自分のサービスの価格を算出する。

仮想評価方式は、ソリューション開発者及び／又はソリューション利用者にサービスを評価してもらい、その評価に基づいて、サービスの価格を感覚的に決定する。例えば、ソリューション開発者及び／又はソリューション利用者にサービス利用に関するアンケートを実施して、当該サービスの使い勝手や性能等を評価してもらう。そして、その評価結果に基づいて、当該サービスの妥当な価格を決定する。他にも、ソリューションが提供する環境への便益等によって、サービスの価格を決定してもよい。この方式を採用する場合、利用者のアンケート結果を、評価データとしてモニタリングするとよい。

上述した実施例は、本発明の説明のための例示であり、本発明の範囲を実施例にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１：管理システム １００：情報処理システム １０１：登録端末 １０２：利用端末 １０３：開発端末

Claims (9)

1. サービスプログラムを管理するサービス管理システムであって、プロセッサとメモリと有し、
   前記メモリは、
   複数のサービスプログラムの所在と、
   前記複数のサービスプログラムの組み合わせで構成されるソリューションプログラムと、を保持し、
   前記プロセッサは、
   前記ソリューションプログラムを構成する各サービスプログラムの、当該ソリューションプログラムの開発又は運用に対する貢献度を算出し、
   その算出した貢献度に基づいて、各サービスプログラムの価値を算出する
   サービス管理システム。
2. 前記プロセッサは、各サービスプログラムの貢献度を、前記ソリューションプログラムの運用において各サービスプログラムに入出力されたデータ量に基づいて算出する
   請求項１に記載のサービス管理システム。
3. 前記プロセッサは、各サービスプログラムの貢献度を、前記ソリューションプログラムの運用において各サービスプログラムに発生した障害数に基づいて算出する
   請求項１に記載のサービス管理システム。
4. 前記プロセッサは、各サービスプログラムの貢献度を、前記ソリューションプログラムの開発における、サービスプログラム同士を連結させるためのインタフェースプログラムの開発量に基づいて算出する
   請求項１に記載のサービス管理システム。
5. 前記プロセッサは、
   前記ソリューションプログラムの利用頻度又は利用期間に基づいて、当該ソリューションプログラムの価値を算出し、
   その算出されたソリューションプログラムの価値に基づいて、当該ソリューションプログラムの利用料を算出し、
   その算出されたソリューションプログラムの利用料と、前記貢献度に基づいて決定された各サービスプログラムの価値と、に基づいて、各サービスプログラムに対する報酬を算出する
   請求項１に記載のサービス管理システム。
6. サービスプログラムに対する報酬は、当該サービスプログラムを含むソリューションプログラムの利用者から徴収した利用料の少なくとも一部である
   請求項５に記載のサービス管理システム。
7. 前記プロセッサは、
   前記ソリューションプログラムの開発に関する要件を受領し、
   その受領した要件に適合する可能性のあるサービスプログラムと、そのサービスプログラムが別のソリューションプログラムで利用された際に発生した問題に関する情報と、を合わせて出力する
   請求項１に記載のサービス管理システム。
8. サービスプログラムを管理する方法であって、
   メモリが、
   複数のサービスプログラムの所在と、
   前記複数のサービスプログラムの組み合わせで構成されるソリューションプログラムと、を保持し、
   プロセッサが、
   前記ソリューションプログラムを構成する各サービスプログラムの、当該ソリューションプログラムの開発又は運用に対する貢献度を算出し、
   その算出した貢献度に基づいて、各サービスプログラムの価値を算出する
   サービス管理方法。
9. サービスプログラムを管理するサービス管理システムに、
   メモリに、
   複数のサービスプログラムの所在と、
   前記複数のサービスプログラムの組み合わせで構成されるソリューションプログラムと、を保持させ、
   プロセッサに、
   前記ソリューションプログラムを構成する各サービスプログラムの、当該ソリューションプログラムの開発又は運用に対する貢献度を算出し、
   その算出した貢献度に基づいて、各サービスプログラムの価値を算出する
   ことを実行させるためのコンピュータプログラム。

Images