JP7259432B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理装置及びプログラムに関する。

特許文献１では、ソフトウェアの機能の変更の便宜を図るために、機能設計書、要件定義書等の成果物テキストから文字列を抽出し、閾値以上存在する文字列をシステムやソフトウェアの仕様である要件を構成する機能として抽出して、ソフトウェアが有する機能と要件とを対応付けたトレーサビリティマトリクスを自動作成する技術が提案されている。そして、ソフトウェア開発者は、トレーサビリティマトリクスを参照することによって変更対象とする機能を特定する。

特開２０１２－１６４２３２号公報

機能設計書、要件定義書等の成果物テキストに含まれる文字列からトレーサビリティマトリクスを作成し、トレーサビリティマトリクスを参照して、要件を構成する機能を抽出しようとしても、成果物テキストに機能を特定する文字列が含まれていない場合、サービスを構成する全ての機能を正確に抽出できない場合がある。

本発明は、トレーサビリティマトリクスを参照することによって変更対象とする機能を特定する場合と比較して、ユーザに提供しているサービス機能に含まれていない機能モジュールを、当該サービス機能に追加できるようにすることを目的とする。

本発明に係る情報処理装置は、ユーザのサービス機能に対する利用頻度を示す利用実績情報を生成する生成手段と、前記利用頻度に応じてユーザに提供しているサービス機能に機能モジュールを追加するサービス機能追加手段と、を有し、前記サービス機能追加手段は、ユーザのサービス機能の利用頻度が所定の閾値以上の場合、ユーザに提供しているサービス機能に機能モジュールを追加し、前記サービス機能が複数のユーザにより利用される場合において、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも複数のユーザのサービス機能の利用頻度が所定の追加条件に合致しない場合、当該一のユーザに提供しているサービス機能に機能モジュールを追加しない、ことを特徴とする。

サービス機能提供者により設定された判定条件情報であって、機能モジュールをサービス機能に追加するかどうかの判定条件を含む判定条件情報を取得する判定条件情報取得手段を有し、前記サービス機能追加手段は、前記判定条件情報及び前記利用実績情報が前記判定条件を満たす場合にユーザに提供しているサービス機能に機能モジュールを追加することを特徴とする。

また、前記判定条件情報には、機能モジュールをサービス機能に追加する際にかかる費用に関する判定条件が設定されていることを特徴とする。

本発明に係るプログラムは、コンピュータを、ユーザのサービス機能に対する利用頻度を示す利用実績情報を生成する生成手段、前記利用頻度に応じてユーザに提供しているサービス機能に機能モジュールを追加するサービス機能追加手段、として機能させ、前記サービス機能追加手段は、ユーザのサービス機能の利用頻度が所定の閾値以上の場合、ユーザに提供しているサービス機能に機能モジュールを追加し、前記サービス機能が複数のユーザにより利用される場合において、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも複数のユーザのサービス機能の利用頻度が所定の追加条件に合致しない場合、当該一のユーザに提供しているサービス機能に機能モジュールを追加しない。

請求項１に記載の発明によれば、ユーザに提供しているサービス機能に含まれていない機能モジュールを、当該サービス機能に追加することができる。また、サービス機能の利用頻度の高いユーザに対しては、当該サービス機能に機能モジュールを追加することができる。また、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも、複数のユーザにおける当該サービス機能の利用状況によっては一のユーザに提供しているサービス機能に機能モジュールを追加しないようにすることができる。

請求項２に記載の発明によれば、サービス機能提供者が設定した判定条件に従う場合にユーザに提供しているサービス機能に機能モジュールを追加することができる。

請求項３に記載の発明によれば、機能モジュールをサービス機能に追加する際にかかる費用を考慮した上でユーザに提供しているサービス機能に機能モジュールを追加することができる。

請求項４に記載の発明によれば、ユーザに提供しているサービス機能に含まれていない機能モジュールを、当該サービス機能に追加することができる。また、サービス機能の利用頻度の高いユーザに対しては、当該サービス機能に機能モジュールを追加することができる。また、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも、複数のユーザにおける当該サービス機能の利用状況によっては一のユーザに提供しているサービス機能に機能モジュールを追加しないようにすることができる。

本実施の形態におけるサービスシステムの全体構成図である。 本実施の形態におけるサービスサーバが提供するサービスの構造を示す図である。 本実施の形態における顧客情報に含まれる契約情報のデータ構成の一例を示す図である。 本実施の形態における顧客情報に含まれるバージョン管理情報のデータ構成の一例を示す図である。 本実施の形態における顧客情報に含まれるオンプレミス商品情報のデータ構成の一例を示す図である。 本実施の形態においてサブ機能の追加対象とする機能を決定する処理を示すフローチャートである。 本実施の形態における履歴情報記憶部に蓄積される履歴情報のデータ構成の一例を示す図である。 本実施の形態における利用状況情報のデータ構成の一例を示す図である。 本実施の形態における提供側設定情報記憶部に記憶される提供側設定情報のデータ構成の一例を示す図である。 本実施の形態における追加機能選定情報記憶部に記憶される追加機能選定情報のデータ構成の一例を示す図である。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

図１は、本実施の形態におけるサービスシステムの全体構成図である。図１には、顧客にサービスを提供するサービス提供事業者が有するサービスサーバ１と、サービス提供事業者の顧客となり、サービス提供事業者が提供するサービスを利用する会社が有する顧客システム３とがインターネット等のネットワーク２で接続された構成が示されている。なお、サービス提供事業者の顧客となる会社は複数存在することから、複数の顧客システム３がネットワーク２に接続されることになるが、各顧客システム３はそれぞれ、以下に説明する処理機能を同様に有するので、図１には、１つの顧客システム３のみを図示する。本実施の形態における会社は、サービス提供事業者の顧客であることを前提としているため、本実施の形態において「会社」と「顧客」は同義である。

また、サービス提供事業者からしてみれば、各顧客がユーザという位置付けになり、各会社においては、サービスを利用する従業員等の各個人がサービスのユーザという位置付けになるが、本実施の形態では、サービス提供事業者からみてサービスの利用者となるユーザを「顧客」と称し、各顧客（つまり、会社）においてサービスの利用者となる従業員等の各個人を「ユーザ」と称することにする。

サービスサーバ１は、汎用的なハードウェア構成のサーバコンピュータで形成される。すなわち、サービスサーバ１は、ＣＰＵ、ＲＯＭ、ＲＡＭ、またハードディスクドライブ（ＨＤＤ）等の記憶手段、通信手段としてのネットワークインタフェースを有する。また、後述するマスタデータの更新等のために、入力手段としてのマウスやキーボード、表示手段としてのディスプレイを持たせてもよい。なお、サービス提供事業者は、サービスサーバ１を用いて提供するサービスを、複数のサーバコンピュータにより形成されるクラウドコンピューティングによるクラウドサービスとして提供してもよい。

サービスサーバ１は、履歴情報収集部１１、利用状況解析部１２、追加機能決定部１３、機能追加処理部１４、顧客情報管理部１５、顧客サポート処理部１６、サービス処理制御部１７、サービスマスタ２１、顧客情報記憶部２２、提供側設定情報記憶部２３、追加機能選定情報記憶部２４、履歴情報記憶部２５、利用状況情報記憶部２６及び顧客データ記憶部２７を有している。サービスサーバ１において、本実施の形態の説明に用いない構成要素は図から省略している。

まず、最初に、本実施の形態におけるサービスサーバ１が提供するサービスの構造について図２を用いて説明する。

図２は、本実施の形態におけるサービスマスタ２１を用いて管理されているサービスの構造を示す図である。本実施の形態で取り扱う各サービスは、図２に示すように１又は複数の機能を組み込むことで構成される。なお、１つの機能が異なるサービスに組み込まれる場合もある。また、機能は、１又は複数のサブ機能を組み込むことで構成される。例えば、文書作成サービスには、文書の編集、保存、バックアップ等の各種機能が含まれる。そして、例えばバックアップ機能には、文書の保存時に更新前の文書を上書きせずに残しておく保存時バックアップ、編集中の文書を一時的の保存する自動バックアップ等の各種サブ機能が含まれる。

本実施の形態では、顧客は、サービス提供事業者との契約により、サービス提供事業者が提供する１又は複数のサービスを利用することになる。契約により顧客に提供されるサービスに含まれる機能の構成は、全ての顧客が同じとは限らず、契約内容によって決まる。つまり、各顧客は、サービス提供事業者から同じサービスを受けるとしても、そのサービスの機能構成は、顧客によって異なってくる場合がある。なお、機能に含まれるサブ機能の構成は、各顧客とも同じとする。

本実施の形態では、機能に追加可能なサブ機能が開発されたりすることで用意された場合、そのサブ機能を無条件に機能に追加するのではなく、各顧客のユーザによるサービスの利用頻度及び種々の条件の下、サブ機能の追加対象とする機能を選択的に決定し、サブ機能の追加の是非を顧客に問い合わせることなく当該顧客に提供している機能にサブ機能を追加するようにしたことを特徴としている。

図１に戻り、サービスサーバ１に含まれる各構成要素について説明する。履歴情報収集部１１は、各顧客システム３から履歴情報を収集して履歴情報記憶部２５に保存する。利用状況解析部１２は、生成手段として機能し、履歴情報記憶部２５に保存されている履歴情報を解析することで利用状況情報を生成して利用状況情報記憶部２６に登録する。利用状況情報は、サービスを利用する各顧客の機能に対する利用頻度を示す利用実績情報である。追加機能決定部１３は、利用状況情報に含まれる各顧客の各機能に対する利用頻度に応じて、顧客に提供している機能にサブ機能を追加するかどうかを決定する。機能追加処理部１４は、サービス機能追加手段として機能し、追加機能決定部１３がサブ機能を追加すると決定した機能に対して当該サブ機能を追加する。そして、当該機能のデータ構造に関してサービスマスタ２１を更新する。

顧客情報管理部１５は、顧客情報記憶部２２に保存されている各種情報のメンテナンス等情報管理を行う。顧客サポート処理部１６は、サービスサーバ１に存在する各顧客の情報のセキュリティ管理や顧客に提供しているサービスのバージョン管理など顧客をサポートする処理を実行する。サービス処理制御部１７は、サービス提供事業者が提供するサービスの実行制御などサービスに関する処理を制御する。

サービスマスタ２１には、前述したサービスの構造に加えて、各サービスを実現するためのソフトウェアが保存されている。本実施の形態では、１又は複数のサブ機能の組合せにより機能が形成され、１又は複数の機能の組合せによりサービスが形成される。従って、機能やサービスは、基本的にはサブ機能のソフトウェアを組み込むことで実現される。以降の説明では、サブ機能又はサブ機能のソフトウェアのことを「機能モジュール」とも称することにする。

顧客情報記憶部２２には、顧客に関連する情報として、契約情報、バージョン管理情報及びオンプレミス商品情報が含まれている。

図３は、本実施の形態における顧客情報に含まれる契約情報のデータ構成の一例を示す図である。契約情報には、顧客との契約に関する情報が含まれる。図３には、顧客を識別する情報としての会社名、当該顧客の住所、管理者名等を含む会社情報、契約期限、当該顧客に対する課金に関する課金情報、当該顧客の認証情報及び当該顧客においてサービスサーバ１が提供するサービスを利用するユーザのユーザＩＤ、連絡先等を含むユーザ情報を含む契約情報の例が示されている。

図４は、本実施の形態における顧客情報に含まれるバージョン管理情報のデータ構成の一例を示す図である。バージョン管理情報には、顧客を識別する情報としての会社名に、当該顧客に提供しているサービスを示すオンプレミス商品、当該顧客に提供している各オンプレミス商品のバージョン、契約期限、サポートの有無を示すサポート対象及びアラート通知を含むバージョン管理情報の例が示されている。

ここで、「オンプレミス」とは、サーバやソフトウェアなどの情報システムを、利用者が管理している施設の構内に機器を設置して運用することを指すなどと定義されている。本実施の形態では、サービス提供事業者が提供するサービス、すなわちサービスマスタ２１にて管理されているサービスのうち顧客が契約により購入したサービスのことを「オンプレミス商品」と称している。

図５は、本実施の形態における顧客情報に含まれるオンプレミス商品情報のデータ構成の一例を示す図である。契約により各顧客に提供するサービスの構成は異なり、また各顧客に提供するサービスを構成する機能は必ずしも同じでないことは上述した通りであるが、図５には、各サービスを構成する機能のうち各顧客が契約した各サービスに含まれる機能が示されている。図５には、例えばサービスαにおける機能αＦＢは、Ｂ社のオンプレミス商品には含まれているが、Ａ社及びＣ社の各オンプレミス商品には含まれていないことが示されている。なお、各社において、サービスαに１つの機能も含まれていない場合、例えば図５においては全ての欄が“×”となる会社においては、サービスαは当該会社においてオンプレミス商品に該当しないサービスとなる。

その他の各記憶部２３～２７に記憶される情報については、動作の説明と合わせて説明する。

サービスサーバ１における各構成要素１１～１７は、サービスサーバ１を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、各記憶手段２１～２７は、サービスサーバ１に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

顧客システム３は、サーバ３１と、サービスの利用者となる従業員等（つまり、「ユーザ」）が利用する複数のユーザ端末３２とがＬＡＮ３３にて接続されて構築された社内システムである。ユーザ端末３２は、例えばパーソナルコンピュータ（ＰＣ）等の従前から存在する汎用的なハードウェア構成で実現できる。ユーザ端末３２は、サービスを利用する際に動作するサービス実行部３２１と、サービスを利用することで生成されたデータ（例えば、文書データ）を記憶するデータ記憶部３２２を有する。各ユーザ端末３２はそれぞれ同等の構成要素を有しているので、図１では１台のユーザ端末３２のみ構成要素を図示した。サービス実行部３２１は、ユーザ端末３２を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、データ記憶部３２２は、ユーザ端末３２に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

サーバ３１は、顧客システム３にオンプレミスを実現するために用意された情報処理装置であり、汎用的なハードウェア構成のサーバコンピュータで形成され、サービス提供事業者が提供するサービスを利用するのに必要な構成要素を有している。すなわち、サーバ３１は、サービス処理部３１１、履歴情報送信部３１２、オンプレミス商品マスタ３１３、履歴情報記憶部３１４及びデータ記憶部３１５を有している。サービス処理部３１１は、ユーザからのサービス利用の要求に応じてサービス実行部３２１と連携動作し、オンプレミス商品であるサービスの処理を実行する。また、サービス処理部３１１は、サービスの処理を実行すると、その履歴情報を生成して履歴情報記憶部３１４に登録する。履歴情報送信部３１２は、履歴情報記憶部３１４に保存されている履歴情報をサービスサーバ１へ送信する。

サービス提供事業者は、顧客に対して契約に基づくサービスを提供するが、オンプレミス商品マスタ３１３には、当該顧客がサービス提供事業者から利用許諾を受けたサービス、すなわちオンプレミス商品に関する情報が登録される。具体的には、オンプレミス商品に該当するサービス及び当該サービスを構成する機能モジュールが登録される。

履歴情報記憶部３１４には、ユーザによるサービスの利用実績を示す履歴情報が蓄積される。データ記憶部３１５には、ユーザがオンプレミス商品を利用した際に生成されたデータ（例えば、文書データ）が保存される。

サーバ３１における各構成要素３１１～３１２は、サーバ３１を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、各記憶手段３１３～３１５は、サーバ３１に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ－ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。

次に、本実施の形態におけるサービスシステムの動作について説明する。

顧客システム３を利用するユーザは、ユーザ端末３２を操作してオンプレミス商品マスタ３１３に登録されているサービスを利用する。ユーザは、オンプレミス商品以外のサービスを利用可能としてもよいが、本実施の形態では、オンプレミス商品に限定して利用することとする。サービス処理部３１１は、サービス実行部３２１と連携してユーザ操作により指定されたサービスを実行する。例えば、文書作成サービスの場合、サービス処理部３１１は、文書作成サービス処理を実行することで文書を作成する。作成された文書は、データ記憶部３２２又はデータ記憶部３１５に保存される。あるいは、サービスサーバ１の顧客データ記憶部２７に保存させてもよい。顧客データ記憶部２７に保存する際には、暗号化してから保存する。この文書の保存及び暗号化は、顧客サポート処理部１６が実施する。

サービス処理部３１１は、サービス処理を実行すると、その履歴情報を生成して履歴情報記憶部３１４に登録する。履歴情報送信部３１２は、履歴情報記憶部３１４に履歴情報が登録されると、その履歴情報をサービスサーバ１へ送信する。履歴情報の送信は、履歴情報が履歴情報記憶部３１４に登録される度に行ってもよいし、所定の時間間隔で未送信分の履歴情報をまとめて送信するようにしてもよい。

サービスサーバ１では、顧客システム３から収集した履歴情報に基づいてサブ機能（つまり、機能モジュール）を追加する機能を決定するが、この処理について図６に示すフローチャートを用いて説明する。

まず、ステップ１１０において、サービスサーバ１における履歴情報収集部１１は、各顧客システム３から送信されてくる履歴情報を収集して、履歴情報記憶部２５に保存する。

図７は、本実施の形態における履歴情報記憶部２５に蓄積される履歴情報のデータ構成の一例を示す図である。履歴情報には、日時、顧客、サービス名、機能名、サブ機能名、ユーザＩＤ、開始日時、終了日時、総時間が含まれている。日時は、履歴情報の履歴情報記憶部２５への登録日時である。顧客は、履歴情報の送信元の顧客の会社名である。サービス名は、実行されたサービスの名称、機能名は実行された機能の名称、サブ機能名は、実行されたサブ機能の名称である。ユーザＩＤはサービスを利用したユーザのユーザＩＤである。開始日時は、サービスの利用開始日時、終了日時は、サービスの利用終了日時、総時間は、サービスの利用時間であり、終了日時と開始日時との差分から得られる。

履歴情報収集部１１は、顧客システム３から収集した履歴情報に、収集元となる顧客の識別情報（つまり、会社名）を付加して履歴情報記憶部２５に保存する。履歴情報収集部１１は、各顧客システム３が自ら動作して送信してきた履歴情報を受信して履歴情報記憶部２５に保存するようにしてもよいし、履歴情報収集部１１が履歴情報の送信を顧客システム３に指示することで収集してもよい。

ステップ１２０において、利用状況解析部１２は、履歴情報記憶部２５に保存されている所定期間内の履歴情報を参照して、所定期間内において機能の利用時間を顧客毎に集計し、その集計結果に基づき利用状況情報を顧客毎に生成して利用状況情報記憶部２６に保存する。

なお、本実施の形態では、履歴情報収集部１１が顧客システム３から収集した履歴情報に顧客の識別情報を付加したが、付加せずに受信した履歴情報をそのまま保存するようにしてもよい。この場合、各ユーザによる機能の利用時間を集計し、顧客情報の契約情報を参照してユーザによる機能の利用時間を顧客毎に集計することで利用状況情報を生成してもよい。

図８は、利用状況解析部１２が生成する利用状況情報のデータ構成の一例を示す図である。図８に示すように、顧客毎の各機能の利用状況が示されている。図８では、予め決められた２つの閾値と比較することで、各顧客の機能の利用状況を、機能の利用時間が多い、中くらい、少ないの３段階に分類する。図８では、それぞれ“○”、“△”、“×”で表している。なお、“－”は当該顧客において利用していない機能であることを示している。

利用状況解析部１２は、更に、各顧客の利用状況を機能毎に集計して各機能の利用状況を求める。この機能毎の集計結果を図８に示す利用状況情報において最右欄の「集計」に設定する。

なお、本実施の形態では、各顧客の機能の利用状況のレベルを３段階に分類したが、２レベル以上に分類すればよい。

続いて、追加機能決定部１３は、ステップ１３０においてサブ機能を追加する機能を決定するが、本実施の形態では、いくつかの決定パターンを用意しており、その中から所望のパターンを採用する。

まず、図８に示す利用状況情報を参照すると、各顧客につき利用時間が所定の閾値以上あることから利用時間が多いと判断される機能（図８における“○”の機能）をサブ機能の追加対象として決定する。これにより、当該機能の利用時間が多い顧客に対してサブ機能を提供することができる。本実施の形態では、機能の利用状況を３段階に分類しているが、機能の利用時間が多い顧客に加えて中くらいの顧客（当該機能が“△”の顧客）が利用する機能も利用時間が所定の閾値以上あると判断してサブ機能の追加対象としてもよい。

また、上記パターンでは、追加対象とする機能を、機能毎顧客毎に判定したが、顧客間に差を設けないようにしてもよい。例えば、機能毎に判定してもよい。具体的には、いずれかの顧客に利用時間が多い機能（図８における“○”の機能）が存在すれば、当該機能については全ての顧客に対してサブ機能の追加対象とする。図８に示す例では、利用時間が多い機能（図８における“○”の機能）に該当する機能ＦＡ，ＦＢ，ＦＤ，ＦＥがサブ機能の追加対象となる。あるいは、利用状況情報の最右欄の集計を参照してサブ機能の追加対象とする機能を選定してもよい。

また、上記とは逆に、例えばＣ社は、機能ＦＥの利用頻度が高いため、機能ＦＥをサブ機能の追加対象として選定してもよいが、その他の会社の利用頻度が低く全体として中くらい（つまり、集計が“△”）であることから、機能ＦＥをサブ機能の追加対象として選定しないようにしてもよい。

ところで、上記パターンでは、顧客による機能の利用状況のみに基づいてサブ機能の追加対象とする機能（以下、「追加対象機能」ともいう）を決定した。以下に、追加機能決定部１３がサービス提供事業者側の意向を考慮して追加対象機能を決定するパターンについて説明する。

図９は、本実施の形態における提供側設定情報記憶部２３に記憶される提供側設定情報のデータ構成の一例を示す図である。提供側設定情報及び後述する追加機能選定情報は、サービス提供事業者がサブ機能の追加対象とする機能について自らの意向を設定した判定条件情報であり、機能にサブ機能を追加するかどうかの判定条件が設定される。追加機能決定部１３は、提供側設定情報及び追加機能選定情報を各記憶部２３，２４から取得して追加対象機能を決定する。

提供側設定情報には、「追加対象」、「コスト」及び「費用対効果」という３指標が機能毎に設定される。「追加対象」には、当該機能をサブ機能の追加対象とするかしないかが設定される。“○”の 項目値は追加対象とし、“×” の 項目値は追加対象としないことを示している。“△”の項目値は、追加対象とする方に含めてもよいし、追加対象としない方に含めてもよい。他の指標に基づく判断に依存するようにしてもよい。「コスト」には、当該機能にサブ機能を追加する際に発生するコストのレベルが設定される。本実施の形態では、３段階に分類して設定したが、２つ以上であればよい。「費用対効果」には、サブ機能の追加に要する費用（つまり、コスト）に対してどれだけの効果が見込まれるか、そのレベルが設定される。本実施の形態では、３段階に分類して設定したが、２つ以上であればよい。

図９に示す設定例によると、機能ＦＣ及び機能ＦＥは、サブ機能の追加対象として選定されることはない。なお、「コスト」及び「費用対効果」の各項目は、次に説明する追加機能選定情報を利用する際に参照される。

図１０は、本実施の形態における追加機能選定情報記憶部２４に記憶される追加機能選定情報のデータ構成の一例を示す図である。追加機能選定情報には、「追加対象」、「コスト」、「費用対効果」、「利用頻度（集計）」及び「機能追加最終判断」という項目が設定される。このうち、「追加対象」、「コスト」及び「費用対効果」は、図９に示す提供側設定情報に対応する項目である。「利用頻度（集計）」は、図８に示す利用状況情報の最右欄「集計」の項目に対応する項目である。そして、「機能追加最終判断」には、サービス提供事業者が当該機能（当該機能は、「追加対象」、「コスト」、「費用対効果」及び「利用頻度（集計）」の組合せにより決まる）を、サブ機能を追加対象とするかしないかの最終的な判断が設定される。“対象”は追加対象とし、“対象外”は追加対象としないことを意味している。

サービス提供事業者側の意向を考慮してサブ機能の追加対象機能を選定する場合、このパターンでは、追加機能選定情報を参照して追加対象機能を選定することにする。サービス提供事業者が所望する機能を追加対象機能として予め決定しておけば、ユーザの利用状況を参照する必要はない。一方、ユーザの利用状況を参照して追加対象機能を決定すれば、サービス提供事業者側の意向を、追加対象機能の選定に反映させることができない。そこで、本実施の形態においては、追加機能選定情報を利用してサービス提供事業者側の意向及びユーザの利用状況の双方をすりあわせて追加対象機能を最終的に選定できるようにした。

例えば、図９に示す提供側設定情報の設定例によると、機能ＦＥは、項目値が“×”であることから追加対象外として設定されている。コスト及び費用対効果は、それぞれ“低”、“中”である。図８に示す利用状況情報の「集計」の設定例によると、機能ＦＥの利用頻度は“△”、つまり顧客には中くらい利用されていることがわかる。

ここで、機能ＦＥの「追加対象」、「コスト」、「費用対効果」及び「利用頻度（集計）」の各項目値は、“×”、“低”、“中”、 “△”であり、図１０に示す追加機能選定情報の設定例によると、レコード４１に該当する。レコード４１における機能追加最終判断によると、“対象”となっている。つまり、この機能ＦＥのように、提供側設定情報では追加対象外と設定されていた場合でも、追加機能選定情報における各項目値の組合せから成る判定条件を満たす場合には、最終的に追加対象機能として選定される場合がある。

図９に示す提供側設定情報の設定例によると、サービス提供事業者は、機能ＦＥをサブ機能の追加対象としなくてよいという見解を持っている。しかしながら、機能ＦＥは、中程度に利用されていること、また機能ＦＥにサブ機能を追加するコストは低く、ある程度の費用対効果は認められるので、ユーザの利用状況及びサービス提供事業者側の都合という各観点を総合的に勘案すると、機能ＦＥにサブ機能を追加してもよいという最終判断を下すということを意味している。

また、機能ＦＥの場合とは逆に、追加機能選定情報を参照すると、サブ機能の追加にかかるコストが高く、また費用対効果も見込めないような機能、例えばレコード４２に該当する機能は、利用頻度が高く、かつ提供側設定情報から追加対象機能の候補となる場合でも最終的に追加対象外と判断される場合もある。

以上説明したように、追加機能決定部１３は、ステップ１３０において上記いずれかのパターンを用いてサブ機能を追加する機能を決定する。

以上のようにして、追加機能決定部１３がサブ機能を追加する機能を決定すると、機能追加処理部１４は、追加機能決定部１３がサブ機能を追加すると決定した機能に対して当該サブ機能を追加すると共に、該当する機能のデータ構造に関してサービスマスタ２１を更新する。なお、一追加対象機能に追加する対象となるサブ機能が複数存在する場合、サブ機能毎に追加するかしないかを判断せずに、追加可能なサブ機能の全てを追加対象機能に追加することを想定している。追加対象のサブ機能に関しては、利用状況の情報が取れないため、サブ機能に差異を設ける必要がないからである。

ところで、本実施の形態におけるサービス提供事業者は、顧客に対してセキュリティ及びバージョン管理について付加機能を提供する。

まず、セキュリティに関して、ユーザは、サービスを利用して作成した文書等のデータをサービスサーバ１の顧客データ記憶部２７に保存する場合がある。顧客データ記憶部２７は、複数の顧客のユーザが共用するのでセキュリティ上の問題が発生しうる。そこで、顧客サポート処理部１６は、顧客データ記憶部２７に保存されているデータを、他の顧客がアクセスできないようにするなどの機能を提供する。あるいは、同じ社内のユーザであっても所定の権限を有するユーザのみがデータにアクセスできるようにする。

また、バージョン管理に関し、顧客サポート処理部１６は、顧客情報に含まれるバージョン管理情報を参照してオンプレミス商品のバージョン管理を行う。

例えば、顧客サポート処理部１６は、図４に示すバージョン管理情報を参照して、サポート対象の顧客には、バージョンアップの際にサポートを行う。また、使用中のバージョンの契約期限が迫ってきた場合（例えば、契約期限の１月前に到達した場合）、アラート通知対象の顧客には、バージョンアップの案内を通知する。

以上説明したように、本実施の形態では、ユーザからの要求に関係なく機能にサブ機能を追加できるようにした。また、追加対象とする機能を特定する際、従来のようにトレーサビリティマトリクスを作成する必要はない。

本実施の形態では、サブ機能を機能モジュールとし、機能をサブ機能の追加対象となるサービス機能として説明した。ただ、この機能モジュールとサービス機能の関係は、サブ機能と機能との関係に限らず、機能とサービスの関係にも適用可能である。つまり、機能を機能モジュールとし、サービスを機能の追加対象となるサービス機能としてもよい。

１ サービスサーバ、２ ネットワーク、３ 顧客システム、１１ 履歴情報収集部、１２ 利用状況解析部、１３ 追加機能決定部、１４ 機能追加処理部、１５ 顧客情報管理部、１６ 顧客サポート処理部、１７ サービス処理制御部、２１ サービスマスタ、２２ 顧客情報記憶部、２３ 提供側設定情報記憶部、２４ 追加機能選定情報記憶部、２５ 履歴情報記憶部、２６ 利用状況情報記憶部、２７ 顧客データ記憶部、３１ サーバ、３２ ユーザ端末、３１１ サービス処理部、３１２ 履歴情報送信部、３１３ オンプレミス商品マスタ、３１４ 履歴情報記憶部、３１５，３２２ データ記憶部、３２１ サービス実行部。

Claims (4)

1. ユーザのサービス機能に対する利用頻度を示す利用実績情報を生成する生成手段と、
   前記利用頻度に応じてユーザに提供しているサービス機能に機能モジュールを追加するサービス機能追加手段と、
   を有し、
   前記サービス機能追加手段は、
   ユーザのサービス機能の利用頻度が所定の閾値以上の場合、ユーザに提供しているサービス機能に機能モジュールを追加し、
   前記サービス機能が複数のユーザにより利用される場合において、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも複数のユーザのサービス機能の利用頻度が所定の追加条件に合致しない場合、当該一のユーザに提供しているサービス機能に機能モジュールを追加しない、
   ことを特徴とする情報処理装置。
2. サービス機能提供者により設定された判定条件情報であって、機能モジュールをサービス機能に追加するかどうかの判定条件を含む判定条件情報を取得する判定条件情報取得手段を有し、
   前記サービス機能追加手段は、前記判定条件情報及び前記利用実績情報が前記判定条件を満たす場合にユーザに提供しているサービス機能に機能モジュールを追加することを特徴とする請求項１に記載の情報処理装置。
3. 前記判定条件情報には、機能モジュールをサービス機能に追加する際にかかる費用に関する判定条件が設定されていることを特徴とする請求項２に記載の情報処理装置。
4. コンピュータを、
   ユーザのサービス機能に対する利用頻度を示す利用実績情報を生成する生成手段、
   前記利用頻度に応じてユーザに提供しているサービス機能に機能モジュールを追加するサービス機能追加手段、
   として機能させ、
   前記サービス機能追加手段は、
   ユーザのサービス機能の利用頻度が所定の閾値以上の場合、ユーザに提供しているサービス機能に機能モジュールを追加し、
   前記サービス機能が複数のユーザにより利用される場合において、複数のユーザのうち一のユーザのサービス機能の利用頻度が所定の閾値以上の場合でも複数のユーザのサービス機能の利用頻度が所定の追加条件に合致しない場合、当該一のユーザに提供しているサービス機能に機能モジュールを追加しない、
   プログラム。

Images