JP7402290B1 - マルチテナントシステム、サービス提供方法、及びプログラム - Google Patents

Abstract

【課題】ベンダー及び契約先の少なくとも一方の手間を軽減する。【解決手段】マルチテナントシステム（１）は、マルチテナントでサービスを提供する。取得部（１０５）は、サービスのベンダーと契約した契約先の契約先システム（２）から、契約先に特有のカスタマイズに関するカスタマイズ情報を取得する。実行部（１０６）は、カスタマイズ情報に基づいて、カスタマイズを実行する。提供部（１０７）は、所定の利用申請を行ったユーザに対し、カスタマイズが実行された前記サービスであるカスタマイズドサービスを提供する。【選択図】図６

Description

本開示は、マルチテナントシステム、サービス提供方法、及びプログラムに関する。

従来、複数のユーザに共通の環境でサービスを提供するマルチテナントと呼ばれる技術が知られている。例えば、非特許文献１には、ベンダーから直接的に利用許諾を受けたユーザと、ベンダーと契約した複数の契約先の各々から利用許諾を受けたユーザと、に共通の環境でサービスを提供するマルチテナントが記載されている。非特許文献１の技術では、ベンダー側のシステムは、契約先ごとに用意された設定差分を管理し、自身にアクセスしてきたユーザに応じて、設定差分を動的に切り替える。

「SaaSサービスのマルチテナントとOEM（ホワイトラベル）を考える」，インターネット，２０２２年９月１６日検索，ｏｎｌｉｎｅ， https://tech-blog.optim.co.jp/entry/2022/06/23/100000

しかしながら、非特許文献１の技術では、ベンダー側のシステムで設定差分を管理するために、ベンダーが、契約先からの依頼を受けて、設定差分を人手で登録する必要がある。契約先側で設定差分の登録作業をする場合にも、契約先側の人間がベンダー側のシステムにアクセスし、設定差分を登録する必要がある。このため、従来の技術では、ベンダー及び契約先の少なくとも一方の手間がかかっていた。

本開示の目的の１つは、ベンダー及び契約先の少なくとも一方の手間を軽減することである。

本開示の一側面に係るマルチテナントシステムは、マルチテナントでサービスを提供するマルチテナントシステムであって、前記サービスのベンダーと契約した契約先の契約先システムから、前記契約先に特有のカスタマイズに関するカスタマイズ情報を取得する取得部と、前記カスタマイズ情報に基づいて、前記カスタマイズを実行する実行部と、所定の利用申請を行ったユーザに対し、前記カスタマイズが実行された前記サービスであるカスタマイズドサービスを提供する提供部と、を含む。

本開示によれば、ベンダー及び契約先の少なくとも一方の手間を軽減できる。

マルチテナントシステムのハードウェア構成の一例を示す図である。 オリジナルサービスの利用申請を受け付けるための利用申請画面の一例を示す図である。 オリジナルサービスのポータル画面の一例を示す図である。 カスタマイズドサービスの利用申請を受け付けるための利用申請画面の一例を示す図である。 カスタマイズドサービスのポータル画面の一例を示す図である。 マルチテナントシステムで実現される機能を示す機能ブロック図である。 サービスデータベースの一例を示す図である。 マルチテナントシステムで実行される処理の一例を示すフロー図である。

［１．マルチテナントシステムのハードウェア構成］
本開示に係るマルチテナントシステムの実施形態の一例を説明する。図１は、マルチテナントシステムのハードウェア構成の一例を示す図である。例えば、マルチテナントシステム１は、マルチテナントサーバ１０を含む。マルチテナントシステム１は、インターネット又はＬＡＮ等のネットワークＮに接続される。例えば、ネットワークＮには、契約先システム２及びユーザ端末３０が接続される。

マルチテナントサーバ１０は、サーバコンピュータである。例えば、マルチテナントサーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

例えば、契約先システム２は、契約先サーバ２０を含む。契約先サーバ２０は、サーバコンピュータである。例えば、契約先サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。例えば、ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、タッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。

なお、記憶部１２，２２，３２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、マルチテナントサーバ１０、契約先サーバ２０、及びユーザ端末３０の各々のハードウェア構成は、図１の例に限られない。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器と直接的に接続するための入出力部（例えば、ＵＳＢ端子）が含まれてもよい。この場合、情報記憶媒体に記憶されたプログラムが読取部又は入出力部を介して供給されてもよい。

また、マルチテナントシステム１は、少なくとも１つのコンピュータを含めばよい。マルチテナントシステム１に含まれるコンピュータは、図１の例に限られない。例えば、マルチテナントシステム１は、マルチテナントサーバ１０と、他のサーバコンピュータと、を含んでもよい。マルチテナントシステム１は、サーバコンピュータ以外の他のコンピュータ（例えば、ベンダーの担当者が操作するコンピュータ）を含んでもよい。

また、契約先システム２も、少なくとも１つのコンピュータを含めばよい。契約先システム２に含まれるコンピュータは、図１の例に限られない。例えば、契約先システム２は、契約先サーバ２０と、他のサーバコンピュータと、を含んでもよい。契約先システム２は、サーバコンピュータ以外の他のコンピュータ（例えば、契約先の担当者が操作するコンピュータ）を含んでもよい。図１では、ユーザ端末３０が１つだけ示されているが、複数のユーザ端末３０が存在してもよい。

［２．マルチテナントシステムの概要］
本実施形態では、マルチテナントシステム１は、マルチテナントでサービスを提供する。マルチテナントは、複数のユーザに共通の環境でサービスを提供する仕組みである。複数のユーザは、原則として互いに関係のない者である。互いに関係のない者とは、互いに同じ又は関連する組織に属さない者である。複数のユーザは、そもそも組織に属さない個人であってもよい。例えば、マルチテナントシステム１では、第１組織に属する第１ユーザＡと、第１組織とは関係のない第２組織に属する第２ユーザＢと、に共通の環境下で、第１ユーザＡ及び第２ユーザＢの各々に対し、サービスが提供される。

環境とは、サービスを提供するために利用されるハードウェア、ソフトウェア、及びＡＰＩの少なくとも１つである。本実施形態では、互いに関係のない複数のユーザ（例えば、互いに同じ組織に属さない複数のユーザ）の各々に対し、同じハードウェア、ソフトウェア、及びデータの少なくとも１つに基づいて、サービスが提供される。個々のユーザ用に、サービスの一部の機能に関するカスタマイズが実行される可能性があるが、サービスを提供するための大まかな仕組み自体は、複数のユーザで共通である。

例えば、マルチテナントサーバ１０といった同じハードウェアに基づいて、複数のユーザの各々に対し、サービスが提供される。ただし、複数のユーザにサービスを提供するための複数のハードウェアは、互いに異なってもよい。この場合、複数のハードウェアは、互いに同じベンダーにより管理されるものとする。例えば、第１ユーザＡに対し、第１のハードウェアに基づいて、サービスが提供される。第２ユーザＢに対し、第１のハードウェアを管理するベンダーが管理する第２ハードウェアに基づいて、サービスが提供されてもよい。

例えば、マルチテナントサーバ１０に記憶された同じソフトウェアに基づいて、複数のユーザの各々に対し、サービスが提供される。ただし、複数のユーザにサービスを提供するための複数のソフトウェアは、多少であれば互いに異なってもよい。この場合、あるソフトウェアは、他のソフトウェアを流用して開発されるものとする。例えば、第１ユーザＡにサービスを提供するための第１ソフトウェアの一部の機能がカスタマイズされた第２ソフトウェアに基づいて、第２ユーザＢに対するサービスが提供されてもよい。

例えば、マルチテナントサーバ１０が有する同じＡＰＩに基づいて、複数のユーザの各々に対し、サービスが提供される。ただし、複数のユーザにサービスを提供するための複数のＡＰＩは、互いに全く同じではなく、互いに異なってもよい。この場合には、あるＡＰＩは、他のＡＰＩを流用して開発されているものとする。例えば、第１ユーザＡにサービスを提供するための第１ＡＰＩの一部がカスタマイズされた第２ＡＰＩに基づいて、第２ユーザＢに対するサービスが提供されてもよい。

本実施形態では、マルチテナントで提供されるサービスの一例として、業務を支援するための業務支援サービスを説明する。業務支援サービスは、グループウェアと呼ばれることもある。マルチテナントシステム１は、業務支援サービス以外の他のサービスにも適用可能である。マルチテナントシステム１を適用するサービスは、業務支援サービスに限られない。例えば、マルチテナントシステム１は、オンラインストレージサービス、ウェブメールサービス、ウェブ会議サービス、又はオンラインセミナーサービスといった他のサービスにも適用可能である。

例えば、業務支援サービスのベンダーは、マルチテナントシステム１を管理する。ベンダーは、業務支援サービスを開発した企業である。ベンダーと契約した契約先は、契約先システム２を管理する。本実施形態では、契約先が、ベンダーとＯＥＭ（Original Equipment Manufacturing）契約を交わしたＯＥＭ先である場合を例に挙げるが、契約先は、ベンダーと何らかの契約をした者であればよい。例えば、ベンダーと契約先の間で、パートナー契約、販売代理店契約、仲介業者契約、又は請負契約といったＯＥＭ契約以外の他の契約が交わされてもよい。

本実施形態では、ベンダーがクラウド型の業務支援サービス（いわゆるＳａａＳ）を提供する場合を例に挙げるが、業務支援サービスは、オンプレミス型であってもよく、クラウド型に限られない。例えば、ベンダーである「ＡＡＡ株式会社」は、自身の名の元で提供する「ＡＡＡワーク」といった業務支援サービスを提供する。ベンダーとＯＥＭ契約を交わした契約先である「ＢＢＢ株式会社」は、「ＡＡＡワーク」をベースにした「ＢＢＢワーク ｐｏｗｅｒｅｄ ｂｙ ＡＡＡワーク」といった業務支援サービスを提供する。

以降、ベンダーが提供するオリジナルの業務支援サービス「ＡＡＡワーク」を、オリジナルサービスという。契約先が提供する業務支援サービス「ＢＢＢワーク ｐｏｗｅｒｅｄ ｂｙ ＡＡＡワーク」を、カスタマイズドサービスという。オリジナルサービス及びカスタマイズドサービスは、マルチテナントで提供されるので、オリジナルサービス及びカスタマイズドサービスは、原則として、同じ環境下で提供される。なお、オリジナルサービス及びカスタマイズドサービスを区別しない時は、単にサービスという。ベンダーが契約先のために業務支援サービス「ＡＡＡワーク」をカスタマイズすることもサービスの一種である。このサービスは、カスタマイズ（「ド」ではない）サービスということができる。

例えば、ユーザは、オリジナルサービス及びカスタマイズドサービスの少なくとも一方を利用可能である。ユーザは、オリジナルサービス及びカスタマイズドサービスの両方を利用してもよいし、オリジナルサービス又はカスタマイズドサービスの何れか一方だけを利用してもよい。ユーザは、オリジナルサービス及びカスタマイズドサービスの少なくとも一方を利用する場合に、利用申請をする必要がある。例えば、ユーザは、オリジナルサービスを利用する場合に、マルチテナントサーバ１０にアクセスして利用申請を行う。

図２は、オリジナルサービスの利用申請を受け付けるための利用申請画面の一例を示す図である。本実施形態では、オリジナルサービスに無料の試用期間が設けられている場合を説明するが、オリジナルサービスには、特に試用期間が設けられていなくてもよい。例えば、ユーザが、オリジナルサービスの利用登録を済ませていない状態でユーザ端末３０を操作してマルチテナントサーバ１０にアクセスすると、オリジナルサービスの利用申請画面ＳＣ１が表示部３５に表示される。

図２の例では、オリジナルサービスの利用申請画面ＳＣ１は、「aaawork.com」といったベンダーのドメイン上で表示される。例えば、ユーザは、入力フォームＦ１０に対し、会社名、氏名、及びメールアドレスといった利用申請に必要な項目を入力する。ユーザがボタンＢ１１を選択すると、オリジナルサービスの利用申請が完了する。マルチテナントサーバ１０は、利用申請を受け付けると、ユーザがオリジナルサービスを試用するための環境を作成する。例えば、マルチテナントサーバ１０は、ユーザ専用のサブドメインと、大まかな画面レイアウトと、の少なくとも一方を、オリジナルサービスの環境として作成する。

例えば、オリジナルサービスの環境が作成されると、ユーザは、自身に割り当てられたサブドメインにアクセスし、オリジナルサービスを利用できるようになる。ユーザは、利用申請時に登録したユーザＩＤ及びパスワードに基づいて、オリジナルサービスにログインする。ユーザは、必要に応じて、オリジナルサービスのカスタマイズを実行してもよい。例えば、ユーザがオリジナルサービスにログインすると、オリジナルサービスのポータル画面が表示部３５に表示される。

図３は、オリジナルサービスのポータル画面の一例を示す図である。図３の例では、「ＣＣＣ株式会社」に属するユーザ「山田太郎」が、オリジナルサービスにログインしている。オリジナルサービスのポータル画面ＳＣ２に相当するＵＲＬは、「aaawork.com」といったドメインの前に、「ccc.」といった文字列が付加されて「ccc.aaawork.com」といったサブドメインを含む。サブドメインは、ユーザの組織を識別可能な文字列でなくてもよく、任意の文字列であってよい。例えば、サブドメインは、ランダムに生成された文字列を含んでもよい。

例えば、ユーザ「山田太郎」は、サブドメイン「ccc.aaawork.com」で提供されるオリジナルサービスの管理者権限を有する。ユーザ「山田太郎」は、スペースと呼ばれるユーザグループに、「ＣＣＣ株式会社」に属する他のユーザを招待する。他のユーザは、ユーザ「山田太郎」からの招待を受けて、スペースに加入するための手続を進める。例えば、他のユーザは、自身の氏名及びメールアドレスといったように、スペースへの加入に必要な情報を入力する。他のユーザは、スペースに加入すると、オリジナルサービスを利用できるようになる。

例えば、スペースに属するユーザ同士で、スレッドと呼ばれる掲示板の一種にコメントを投稿し、コミュニケーションを取る。例えば、スペースに属するユーザ同士で、アプリと呼ばれるデータベースの一種にデータを登録し、業務に必要な情報を共有する。例えば、スペースに属するユーザ同士で、自身のスケジュールを共有する。これらの機能は、スペースに属するユーザ同士ではなく、スペースに関係のない場所で行われてもよい。オリジナルサービスで提供される機能自体は、公知に種々の機能であってよい。

本実施形態では、このようなオリジナルサービスがカスタマイズされて、契約先の名前の元で、カスタマイズドサービスとして提供される。カスタマイズドサービスは、あくまで契約先により提供されるので、ユーザは、ベンダーではなく契約先に利用登録を行う。ただし、カスタマイズドサービス自体は、契約先が独自に開発したものではなく、ベンダーが開発した機能が流用される。例えば、ユーザは、カスタマイズドサービスを利用する場合に、契約先サーバ２０にアクセスして所定の利用申請を行う。

図４は、カスタマイズドサービスの利用申請を受け付けるための利用申請画面の一例を示す図である。本実施形態では、カスタマイズドサービスに無料の試用期間が設けられている場合を説明するが、カスタマイズドサービスは、特に試用期間が設けられていなくてもよい。カスタマイズドサービスは、契約先の名前の元で提供されるので、ユーザは、カスタマイズドサービスの利用申請をするために、契約先サーバ２０にアクセスする必要がある。図４の例では、カスタマイズドサービスの利用申請画面ＳＣ３は、「bbbcompany.com」といった契約先のドメイン上で表示される。

例えば、ユーザは、入力フォームＦ３０に対し、会社名、氏名、及びメールアドレスといった利用申請に必要な項目を入力する。本実施形態では、カスタマイズドサービスの利用申請に必要な項目と、オリジナルサービスの利用申請に必要な項目と、が互いに同じである場合を説明するが、これらは互いに異なってもよい。例えば、カスタマイズドサービスの利用申請では、カスタマイズドサービス用にカスタマイズするために必要な項目が存在してもよい。この点は、後述の変形例で説明する。

例えば、ユーザが利用申請に必要な項目を入力してボタンＢ３１を選択すると、カスタマイズドサービスの利用申請が完了する。カスタマイズドサービスの利用申請は、契約先サーバ２０に対して行われるが、カスタマイズドサービス自体は、契約先サーバ２０ではなく、マルチテナントサーバ１０により提供される。このため、契約先サーバ２０は、マルチテナントサーバ１０に対し、ユーザがカスタマイズドサービスを試用するための環境の作成を依頼する。

例えば、マルチテナントサーバ１０は、契約先サーバ２０からの依頼を受信すると、ユーザ専用のサブドメインと、大まかな画面レイアウトと、の少なくとも一方を、カスタマイズドサービスの環境として作成する。環境作成の流れは、原則として、オリジナルサービスの利用申請が行われた場合の流れと同様である。ただし、カスタマイズドサービスは、契約先に応じた機能を有するので、大まかな環境が作成された後に、契約先に応じたカスタマイズが実行される。

例えば、マルチテナントサーバ１０は、カスタマイズドサービスの環境を作成すると、マルチテナントサーバ１０と契約先サーバ２０の間で、カスタマイズドサービスに特有のカスタマイズが実行される。本実施形態では、契約先に応じた詳細な画面レイアウトがカスタマイズとして実行される場合を説明するが、画面レイアウト以外の他のカスタマイズが実行されてもよい。他のカスタマイズの一例は、後述の変形例で説明する。

例えば、カスタマイズドサービスのカスタマイズが完了すると、ユーザは、自身に割り当てられたサブドメインにアクセスし、カスタマイズドサービスを利用できるようになる。カスタマイズドサービスでも、ユーザは、利用申請時にユーザＩＤ及びパスワードの登録を行うものとする。ユーザは、利用申請時に登録したユーザＩＤ及びパスワードに基づいて、カスタマイズドサービスにログインする。例えば、ユーザがカスタマイズドサービスにログインすると、カスタマイズドサービスのポータル画面が表示部３５に表示される。

図５は、カスタマイズドサービスのポータル画面の一例を示す図である。図５の例では、「ＤＤＤ株式会社」に属するユーザ「木村花子」が、カスタマイズドサービスにログインしている。カスタマイズドサービスのポータル画面ＳＣ４に相当するＵＲＬは、「aaawork.com」といったドメインの前に、「dddbbbwork.」といった文字列が付加されて「dddbbbwork.aaawork.com」といったサブドメインを含む。サブドメインは、ユーザの組織及び契約先を識別可能な文字列でなくてもよく、任意の文字列であってよい。例えば、サブドメインは、ランダムに生成された文字列を含んでもよい。

図５のように、カスタマイズドサービスのポータル画面ＳＣ４は、オリジナルサービスのポータル画面ＳＣ２とレイアウトが異なる。例えば、カスタマイズドサービスのポータル画面ＳＣ４は、カスタマイズドサービスであることが分かるように、「ＢＢＢワーク」といったロゴが表示される。カスタマイズドサービスのポータル画面ＳＣ４は、契約先の企業カラーの背景を有してもよいし、契約先の社名を示す画像が背景として試用されてもよい。例えば、カスタマイズドサービスのポータル画面ＳＣ４のお知らせ欄には、契約先の製品に関する情報が表示される。

例えば、カスタマイズドサービスのポータル画面ＳＣ４から何らかの問い合わせが行われる場合には、ベンダーではなく、契約先が問い合わせ先として設定される。一方で、オリジナルサービスのポータル画面ＳＣ２における問い合わせ先は、ベンダーとなる。カスタマイズドサービスで表示されるポータル画面ＳＣ４以外の他の画面についても、契約先に特有のレイアウトを有する。ユーザ「木村花子」は、「ＤＤＤ株式会社」に属する他のユーザをスペースに招待する。この点は、オリジナルサービスの利用を開始する手順と同様である。

例えば、カスタマイズドサービスでは、契約先の製品に特有の業務支援を提供できるようになっている。契約先がスキャナ又は複合機といった機器を販売する企業だった場合には、文書管理の業務支援に特化したカスタマイズドサービスが提供される。本実施形態では、画面レイアウトのカスタマイズを例に挙げるが、アプリと呼ばれるデータベース、又は、プラグイン等の機能がカスタマイズされてもよい。文書管理の業務支援に特化した業務支援サービスを利用したいユーザは、カスタマイズドサービスの利用申請を行う。

以上のように、本実施形態のマルチテナントサーバ１０は、カスタマイズドサービスの利用申請が受け付けられると、契約先サーバ２０との間で、カスタマイズドサービスの環境の作成と、カスタマイズドサービスに特有のカスタマイズと、を自動的に実行する。これにより、ベンダー及び契約先の間で手動による作業が発生せず、ベンダー及び契約先の少なくとも一方の手間を軽減できるようになっている。以降、マルチテナントシステム１の詳細について説明する。

［３．マルチテナントシステムで実現される機能］
図６は、マルチテナントシステム１で実現される機能を示す機能ブロック図である。図６では、マルチテナントシステム１だけではなく、契約先システム２及びユーザ端末３０の各々で実現される機能も示されている。

［３－１．マルチテナントシステムで実現される機能］
例えば、マルチテナントサーバ１０は、データ記憶部１００、受付部１０１、環境作成部１０２、発行部１０３、認証部１０４、取得部１０５、実行部１０６、及び提供部１０７を含む。データ記憶部１００は、記憶部１２により実現される。受付部１０１、環境作成部１０２、発行部１０３、認証部１０４、取得部１０５、実行部１０６、及び提供部１０７の各々は、制御部１１により実現される。

［データ記憶部］
データ記憶部１００は、マルチテナントでサービスを提供するために必要なデータを記憶する。例えば、データ記憶部１００は、サービスデータベースＤＢを記憶する。

図７は、サービスデータベースＤＢの一例を示す図である。サービスデータベースＤＢは、カスタマイズドサービスに関する各種情報が格納されたデータベースである。例えば、サービスデータベースＤＢには、契約先を識別可能な契約先情報と、カスタマイズドサービスの環境に関する環境情報と、が格納される。例えば、契約先情報は、契約先の名前、契約先に割り当てられたＩＤ、又は契約先のメールアドレスである。

環境情報は、カスタマイズドサービスの環境に関する何らかの情報であればよい。例えば、環境情報は、サブドメイン、レイアウト情報、スペース情報、アプリ情報、及びスレッド情報を含む。例えば、サブドメインは、カスタマイズドサービスの利用単位を識別する情報である。利用申請が行われるたびに、サブドメインが生成される。サブドメインは、事後的に変更可能であってもよい。

レイアウト情報は、ポータル画面ＳＣ２，ＳＣ４等の各種画面のレイアウトに関する情報である。例えば、レイアウト情報は、ポータル画面ＳＣ２，ＳＣ４等の各種画面の背景、アイコン、及びヘッダといった情報を含む。スペース情報は、スペースに関する情報である。例えば、スペース情報は、スペースの名前、スペースに属するユーザのユーザＩＤ、及びユーザの権限を含む。スペース情報は、スペースでやり取りされているメッセージ等の情報を含んでもよい。

アプリ情報は、スペースに関連付けられたアプリに関する情報である。本実施形態では、アプリは、ソフトウェアというよりもデータベースの意味である。例えば、スペースに属するユーザ同士で共有する情報がアプリに登録される。スペースに属するユーザは、自身が認められた権限の範囲内で、アプリに登録された情報を閲覧、更新、又は削除することができる。アプリは、スペースに関係のない場所に登録されてもよい。スレッド情報は、掲示板の一種であるスレッドに関する情報である。例えば、スレッド情報には、スレッドのタイトル、スレッドに投稿されたコメント、及び添付ファイルが含まれる。

なお、サービスデータベースＤＢは、カスタマイズドサービスに関する何らかの情報が格納されるようにすればよく、図７の例に限られない。例えば、利用申請をしたユーザが所属する会社名、ユーザの名前、ユーザのメールアドレス、ユーザが属する組織の事業規模、又はカスタマイズドサービスの利用目的の他の情報がサービスデータベースＤＢに格納されてもよい。例えば、カスタマイズドサービスを利用するユーザ（利用申請をしたユーザに招待された他のユーザ）のユーザＩＤ及びパスワードがサービスデータベースＤＢに格納されてもよい。

例えば、契約先のユーザＩＤ及びパスワードがサービスデータベースＤＢに格納されてもよい。本実施形態では、契約先は、管理権限を有するユーザの１人であるものとする。オリジナルサービスの利用申請をしたユーザも管理権限を有するが、オリジナルサービスの利用申請をしたユーザも、管理権限を有する１人ではあるが、本実施形態では、契約先が招待した他のユーザの１人といった位置付けになるものとする。例えば、契約先は、自身に対して発行されたユーザＩＤ及びパスワードでログインし、カスタマイズに関する各種処理が実行される。

また、データ記憶部１００は、カスタマイズドサービスでやりとりされているデータを記憶してもよい。例えば、データ記憶部１００は、カスタマイズドサービスのアプリに登録されたレコードのデータと、カスタマイズドサービスのスレッドに投稿されたコメントのデータと、を記憶してもよい。データ記憶部１００は、オリジナルサービスに関するデータを記憶してもよい。データ記憶部１００は、マルチテナントでサービスを提供するために必要なデータを記憶すればよい。データ記憶部１００が記憶するデータは、上記の例に限られない。例えば、データ記憶部１００は、各種ＡＰＩに関するデータを記憶してもよい。

［受付部］
受付部１０１は、カスタマイズドサービスの利用を申請するための所定の利用申請を受け付ける。本実施形態では、契約先システム２で利用申請が行われるので、受付部１０１は、契約先システム２で利用申請が行われた場合に、契約先システム２から、所定の利用申請を受け付ける。利用申請は、所定形式のデータが送信されることによって行われる。例えば、利用申請には、利用申請をしたユーザに関する情報が含まれてもよい。マルチテナントシステム１でカスタマイズドサービスの利用申請も行われる場合には、受付部１０１は、ユーザ端末３０から直接的に利用申請を受け付ける。マルチテナントシステム１及び契約先システム２以外の他のシステムでカスタマイズドサービスの利用申請も行われる場合には、受付部１０１は、他のシステムを介して利用申請を受け付ける。

本実施形態では、受付部１０１は、環境を作成するための環境作成ＡＰＩに基づいて、契約先システム２から、利用申請を受け付ける。ユーザがカスタマイズドサービスの利用申請画面ＳＣ３から利用申請をした場合、契約先サーバ２０は、マルチテナントサーバ１０の環境作成ＡＰＩに対し、利用申請を送信する。利用申請は、環境作成ＡＰＩで定められた形式のデータとなる。なお、利用申請は、環境作成ＡＰＩとは異なるＡＰＩで受け付けてもよいし、ユーザ端末３０からマルチテナントサーバ１０に直接的に送信されてもよい。

［環境作成部］
環境作成部１０２は、利用申請が受け付けられた場合に、カスタマイズドサービスにおける環境を作成する。環境を作成するとは、カスタマイズドサービスに関するデータを生成し、サービスデータベースＤＢに格納することである。環境作成部１０２が作成する環境は、後述の実行部１０６によるカスタマイズとは異なる。環境作成部１０２は、カスタマイズドサービスの大まかな設定を行い、後述の実行部１０６により、カスタマイズドサービスの細かな設定が行われる。環境作成部１０２により設定される項目は、予め定められているものとする。環境作成部１０２が環境を作成すると、サービスデータベースＤＢに新たなレコードが作成され、当該作成された環境に関する各種情報が格納される。

例えば、環境作成部１０２は、カスタマイズドサービスのサブドメインを作成する。サブドメインは、契約先を識別可能な文字列を含んでもよい。この場合、環境作成部１０２は、カスタマイズドサービスの利用申請である場合に、当該文字列を含むサブドメインを作成する。環境作成部１０２は、カスタマイズドサービスのポータル画面ＳＣ４の大まかなレイアウトを決定する。例えば、大まかなレイアウトは、カスタマイズドサービスのポータル画面ＳＣ４のヘッダ部分及び背景である。環境作成部１０２は、カスタマイズドサービスのポータル画面ＳＣ４のヘッダ部分に、契約先の社名又はロゴが含まれるように、カスタマイズドサービスにおける環境を作成する。

［発行部］
発行部１０３は、ユーザが利用申請を行った場合に、所定の認証情報を発行する。認証情報は、契約先の認証で利用される情報である。本実施形態では、パスワードが認証情報に相当する場合を説明するが、認証情報は、他の情報であってもよく、パスワードに限られない。例えば、認証情報は、暗証番号、合言葉、又は電子証明書であってもよい。発行部１０３は、予め定められた発行方法に基づいて、認証情報を発行する。発行された認証情報は、サービスデータベースＤＢ又は他のデータベースに格納される。認証情報は、発行済みの他の認証情報と重複しないように発行されるものとする。

本実施形態では、パスワード設定用のＵＲＬに基づいて、パスワードが発行される場合を例に挙げる。例えば、発行部１０３は、パスワード発行用のＵＲＬに対するアクセスを受け付けて、当該ＵＲＬのページで入力されたパスワードを新たに発行する。発行部１０３は、パスワード発行用のＵＲＬではなく、ランダムにパスワードを発行してもよい。発行部１０３は、発行したパスワードをサービスデータベースＤＢに格納する。カスタマイズドサービスの場合には、契約先サーバ２０の処理により、パスワードを発行する処理が自動化されているものとする。

［認証部］
認証部１０４は、認証情報に基づいて、契約先システム２に関する認証を実行する。認証部１０４は、契約先システム２から受信した認証情報と、発行部１０３により発行されてマルチテナントサーバ１０側で保持されている認証情報（例えば、サービスデータベースＤＢに格納された認証情報）と、に基づいて、認証を実行する。認証は、これらの認証情報が一致した場合に成功となる。認証自体は、任意の認証方法を利用可能であり、パスワード認証に限られない。例えば、暗証番号認証、合言葉認証、又は電子証明書認証が実行されてもよい。契約先ではなくユーザについて認証する場合には、認証部１０４は、ユーザ端末３０から受信した認証情報と、発行部１０３により発行されてマルチテナントサーバ１０側で保持されている認証情報と、に基づいて、認証を実行する。

［取得部］
取得部１０５は、サービスのベンダーと契約した契約先の契約先システム２から、契約先に特有のカスタマイズに関するカスタマイズ情報を取得する。本実施形態では、カスタマイズ情報を取得するための専用のＡＰＩが用意されているものとする。例えば、取得部１０５は、環境作成ＡＰＩとは異なるカスタマイズＡＰＩに基づいて、契約先システム２から、カスタマイズ情報を取得する。契約先サーバ２０は、カスタマイズＡＰＩを利用して、マルチテナントサーバ１０にカスタマイズ情報を送信する。

本実施形態では、契約先システム２では、環境の作成結果に基づいて、カスタマイズ情報が生成される。取得部１０５は、環境の作成結果に基づいて生成されたカスタマイズ情報を取得する。例えば、環境の作成が成功すると認証情報が発行されるので、取得部１０５は、認証が成功した場合に、契約先システム２から、カスタマイズ情報を取得する。取得部１０５は、認証が成功しなかった場合には、契約先システム２から、カスタマイズ情報を取得しない。

カスタマイズ情報は、カスタマイズドサービスでどのようなカスタマイズを実行するかを識別可能な情報を含む。カスタマイズ自体は、契約先に応じた任意の処理を実行可能である。本実施形態では、ポータル画面ＳＣ４のレイアウトに関するカスタマイズが実行されるので、カスタマイズ情報は、ポータル画面ＳＣ４のレイアウトに関する情報を含む。例えば、取得部１０５は、ポータル画面ＳＣ４におけるロゴ及び背景といったレイアウトに関するカスタマイズ情報を取得する。

［実行部］
実行部１０６は、カスタマイズ情報に基づいて、カスタマイズを実行する。本実施形態では、カスタマイズの一例として、レイアウト情報のカスタマイズを説明する。このため、カスタマイズ情報には、レイアウト情報が含まれる。例えば、実行部１０６は、契約先システム２から受信したカスタマイズ情報に含まれるレイアウト情報を、サービスデータベースＤＢに格納する。ポータル画面ＳＣ４等の各画面には、このレイアウト情報が反映される。

本実施形態では、サービスの一例として、業務を支援するための業務支援サービスを説明するので、カスタマイズは、契約先が独自に提供するカスタマイズドサービスに関する業務に特有のカスタマイズである。例えば、カスタマイズによって、契約先の製品に関する情報をポータル画面ＳＣ４のお知らせ欄に表示させる処理、契約先の企業カラーを背景に設定する処理、及び契約先のロゴをポータル画面ＳＣ４等の画面に表示させる処理の少なくとも１つが実行される。

本実施形態では、カスタマイズＡＰＩを利用してレイアウト情報がやりとりされる。このカスタマイズＡＰＩは、オリジナルサービスで何らかのカスタマイズが実行される場合にも利用される。このため、実行部１０６は、ベンダーが提供するオリジナルのサービスであるオリジナルサービスと同じカスタマイズＡＰＩを流用して、カスタマイズを実行する。例えば、オリジナルサービスのカスタマイズＡＰＩと、カスタマイズドサービスのカスタマイズＡＰＩと、は互いに同じである。このため、これらのＡＰＩが受け付けるデータ形式も同じである。

［提供部］
提供部１０７は、所定の利用申請を行ったユーザに対し、カスタマイズが実行されたサービスであるカスタマイズドサービスを提供する。本実施形態では、契約先システム２で利用申請が行われる場合を説明するが、利用申請は、マルチテナントシステム１で行われてもよい。例えば、オリジナルサービスの利用申請と同じ利用申請画面ＳＣ１でカスタマイズドサービスの利用申請を選択できるようにしてもよい。カスタマイズドサービスの利用申請は、マルチテナントシステム１及び契約先システム２以外の他のシステム（例えば、代理店のシステム）で行われてもよい。この場合、マルチテナントシステム１は、他のシステムから、カスタマイズドサービスの利用申請が行われたことを示す通知を受信するものとする。

例えば、提供部１０７は、利用申請をしたユーザ又は当該ユーザから招待を受けた他のユーザが、自身のユーザＩＤ及びパスワードを入力してログインした場合に、カスタマイズドサービスのポータル画面ＳＣ４をユーザ端末３０に表示させる。このポータル画面ＳＣ４は、契約先に特有のカスタマイズが実行されたものである。このため、提供部１０７は、ユーザに対し、カスタマイズが反映されたカスタマイズドサービスを提供することになる。本実施形態では、マルチテナントが実現されるので、提供部１０７は、ユーザに対し、オリジナルサービスも提供することになる。カスタマイズドサービスの提供は、サービスデータベースＤＢ又は他のデータベースに格納されたデータに基づいて実行される。

［３－２．契約先システムで実現される機能］
例えば、契約先システム２は、データ記憶部２００、受付部２０１、第１依頼部２０２、取得部２０３、第２依頼部２０４、及び通知部２０５を含む。データ記憶部２００は、記憶部２２により実現される。受付部２０１、第１依頼部２０２、取得部２０３、第２依頼部２０４、及び通知部２０５は、制御部２１により実現される。

［データ記憶部］
データ記憶部２００は、カスタマイズドサービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、カスタマイズドサービスの利用申請画面ＳＣ３をユーザ端末３０に表示させるためのデータを記憶する。本実施形態では、データ記憶部２００は、カスタマイズ情報を記憶する。カスタマイズ情報は、契約先の担当者の操作により適宜更新可能である。例えば、データ記憶部２００は、ポータル画面ＳＣ４のレイアウトに関するレイアウト情報を、カスタマイズ情報として記憶する。カスタマイズ情報には、レイアウト情報以外の他の情報が含まれてもよい。データ記憶部２００は、カスタマイズ情報そのものを記憶しなくてもよく、カスタマイズ情報を生成するためのデータを記憶してもよい。

［受付部］
受付部２０１は、カスタマイズドサービスの利用申請を受け付ける。本実施形態では、利用申請がユーザ端末３０から送信される場合を説明するが、利用申請は、ユーザ端末３０以外の他の端末から送信されてもよい。例えば、契約先の担当者がユーザの代わりに利用申請を行う場合には、担当者の端末から利用申請が送信されてもよい。利用申請は、所定形式のデータが送信されることによって行われる。利用申請は、カスタマイズドサービスの利用を開始するために必要な情報を含む。例えば、利用申請は、カスタマイズドサービスの利用申請画面ＳＣ３の入力フォームＦ３０に入力された各種情報を含む。

［第１依頼部］
第１依頼部２０２は、マルチテナントサーバ１０に対し、カスタマイズドサービスの環境を作成するための環境作成依頼を送信する。環境作成依頼は、所定形式のデータが送信されることによって行われる。環境作成依頼は、カスタマイズドサービスの環境を作成するために必要な情報を含む。例えば、環境作成依頼は、カスタマイズドサービスであることを識別可能なサービス識別情報を含む。サービス識別情報は、オリジナルサービスと区別できる情報であればよく、例えば、所定の文字、記号、数字、又はこれらの組み合わせによって表現される。

本実施形態では、環境作成ＡＰＩとカスタマイズＡＰＩが別々のＡＰＩとして用意されているので、第１依頼部２０２は、マルチテナントサーバ１０の環境作成ＡＰＩに対し、カスタマイズドサービスの環境作成依頼を送信する。環境作成依頼は、環境作成ＡＰＩに沿ったデータフォーマットとなる。このデータフォーマットは、原則として、オリジナルサービスの環境作成依頼と同様である。このため、環境作成ＡＰＩは、カスタマイズドサービスの環境作成依頼と、オリジナルサービスの環境作成依頼と、の両方に対応できる。

［取得部］
取得部２０３は、予め定められた取得方法に基づいて、カスタマイズ情報を取得する。本実施形態では、カスタマイズ情報そのものがデータ記憶部２００に記憶されているので、取得部２０３は、データ記憶部２００に記憶されたカスタマイズ情報を取得する。データ記憶部２００に記憶されたカスタマイズ情報は、契約先の担当者によって適宜変更可能である。カスタマイズ情報をマルチテナントサーバ１０に記録する必要がないので、カスタマイズドサービスのポータル画面ＳＣ４のレイアウトを変更する場合には、契約先の担当者は、ベンダーに依頼してカスタマイズ情報を変更してもらう必要がなくなる。これにより、ベンダー及び契約先の両者の手間を軽減できる。カスタマイズ情報は、カスタマイズドサービスの環境結果に基づいて取得されてもよいし、カスタマイズドサービスの環境に関係なく取得されてもよい。

［第２依頼部］
第２依頼部２０４は、マルチテナントサーバ１０に対し、カスタマイズドサービスに特有のカスタマイズを実行するためのカスタマイズ依頼を送信する。カスタマイズ依頼は、所定形式のデータが送信されることによって行われる。カスタマイズ依頼は、カスタマイズを実行するために必要な情報を含む。例えば、カスタマイズ依頼は、契約先のユーザＩＤと、カスタマイズ情報と、を含む。

本実施形態では、環境作成ＡＰＩとカスタマイズＡＰＩが別々のＡＰＩとして用意されているので、第２依頼部２０４は、マルチテナントサーバ１０のカスタマイズＡＰＩに対し、カスタマイズ依頼を送信する。カスタマイズ依頼は、カスタマイズＡＰＩに沿ったデータフォーマットとなる。このデータフォーマットは、原則として、オリジナルサービスで何らかのカスタマイズを実行する場合と同様である。このため、カスタマイズＡＰＩは、カスタマイズドサービスのカスタマイズ依頼と、オリジナルサービスのカスタマイズ依頼と、の両方に対応できる。

［通知部］
通知部２０５は、ユーザ端末３０に対し、利用開始を通知する。利用開始には、カスタマイズドサービスのポータル画面ＳＣ４へのリンクが含まれているものとする。ユーザのパスワードを事後的に登録する場合には、利用開始には、パスワードの登録用のページへのリンクが含まれていてもよい。通知部２０５は、任意の通知手段を利用して利用開始を通知すればよい。通知手段としては、電子メール、メッセージアプリ、ＳＭＳ、又はチャットであってもよい。

［３－３．ユーザ端末で実現される機能］
例えば、ユーザ端末３０は、データ記憶部３００、表示制御部３０１、及び操作受付部３０２を含む。データ記憶部３００は、記憶部３２により実現される。表示制御部３０１及び操作受付部３０２の各々は、制御部３１により実現される。

［データ記憶部］
データ記憶部３００は、ユーザの業務を支援するために必要なデータを記憶する。例えば、データ記憶部３００は、マルチテナントシステム１に関する種々の画面を表示するためのブラウザを記憶する。例えば、データ記憶部３００は、マルチテナントシステム１専用のアプリケーションを記憶する。

［表示制御部］
表示制御部３０１は、マルチテナントシステム１における各種画面を、表示部３５に表示させる。例えば、表示制御部３０１は、マルチテナントサーバ１０から受信した表示データに基づいて、オリジナルサービスの利用申請画面ＳＣ１、オリジナルサービスのポータル画面ＳＣ２、カスタマイズドサービスの利用申請画面ＳＣ３、及びカスタマイズドサービスのポータル画面ＳＣ４を、表示部３５に表示させる。

［操作受付部］
操作受付部３０２は、ユーザによる各種操作を受け付ける。例えば、操作受付部３０２は、オリジナルサービスの利用申請画面ＳＣ１、オリジナルサービスのポータル画面ＳＣ２、カスタマイズドサービスの利用申請画面ＳＣ３、及びカスタマイズドサービスのポータル画面ＳＣ４の各々に対する操作を受け付ける。操作受付部３０２が受け付けた操作内容は、マルチテナントサーバ１０又は契約先サーバ２０に適宜送信される。

［４．マルチテナントシステムで実行される処理］
図８は、マルチテナントシステム１で実行される処理の一例を示すフロー図である。図８では、マルチテナントシステム１で実行される処理のうち、主に、カスタマイズドサービスの利用申請時の処理を説明する。

図８に示すように、ユーザ端末３０は、ユーザがカスタマイズドサービスの利用申請画面ＳＣ３のリンクを指定すると、契約先サーバ２０との間で、カスタマイズドサービスの利用申請画面ＳＣ３を表示させるための処理を実行する（Ｓ１）。ユーザ端末３０は、カスタマイズドサービスの利用申請画面ＳＣ３において、利用申請に必要な項目の入力を受け付けて、契約先サーバ２０に対し、利用申請を送信する（Ｓ２）。利用申請には、ユーザによる各項目の入力内容が含まれる。

契約先サーバ２０は、利用申請を受け付けると（Ｓ３）、マルチテナントサーバ１０に対し、カスタマイズドサービスの環境作成を依頼する（Ｓ４）。Ｓ４では、契約先サーバ２０は、オリジナルサービスにおける環境作成と同じ環境作成ＡＰＩに対し、カスタマイズドサービスの環境作成を依頼する。環境作成ＡＰＩに送信されるデータ形式は、オリジナルサービスにおける環境作成が行われる場合と同様である。ただし、依頼には、カスタマイズドサービスであることを識別可能な識別情報が含まれているものとする。

マルチテナントサーバ１０は、環境作成の依頼を受け付けると（Ｓ５）、カスタマイズドサービスの環境を作成する（Ｓ６）。Ｓ６では、マルチテナントサーバ１０は、カスタマイズドサービスに特有のレイアウトとなるように、レイアウト情報を生成する。マルチテナントサーバ１０は、オリジナルサービスと同様の発行方法に基づいて、サブドメインを発行してもよいが、ここでは、カスタマイズドサービスに特有のサブドメインとなるように、サブドメインを発行するものとする。マルチテナントサーバ１０は、サービスデータベースＤＢを更新する。

マルチテナントサーバ１０は、契約先サーバ２０に対し、環境の作成結果を送信する（Ｓ７）。Ｓ７では、マルチテナントサーバ１０及び契約先サーバ２０の間でポーリングが実行され、ステータスが確認される。マルチテナントサーバ１０は、契約先サーバ２０側で準備完了のステータスになったことを検知すると、契約先のパスワード設定用のＵＲＬを契約先サーバ２０に送信する。契約先のユーザＩＤは、ランダムに生成されるものとする。

契約先サーバ２０は、環境の作成結果を受信すると（Ｓ８）、契約先のパスワードを設定する（Ｓ９）。Ｓ９の処理は、自動的に実行されるものとする。契約先のユーザＩＤ及びパスワードは、契約先サーバ２０に記録される。以降、契約先サーバ２０は、任意のタイミングでユーザＩＤ及びパスワードを利用してマルチテナントサーバ１０にログインできる。

契約先サーバ２０は、予め定められた取得方法に基づいて、カスタマイズ情報を取得する（Ｓ１０）。Ｓ１０では、カスタマイズドサービス用のレイアウト情報が契約先サーバ２０に記録されているものとする。契約先サーバ２０は、カスタマイズドサービス用のレイアウト情報を読み出すことによって、カスタマイズ情報を生成する。契約先サーバ２０は、マルチテナントサーバ１０に対し、Ｓ９で設定されたパスワードでログインしてカスタマイズ情報を送信する（Ｓ１１）。

マルチテナントサーバ１０は、カスタマイズ情報を受信すると（Ｓ１２）、当該受信したカスタマイズ情報に基づいて、カスタマイズドサービスのカスタマイズを実行する（Ｓ１３）。マルチテナントサーバ１０は、契約先サーバ２０に対し、カスタマイズの実行結果を送信する（Ｓ１４）。契約先サーバ２０は、カスタマイズの実行結果を受信すると（Ｓ１５）、ユーザ端末３０に対し、カスタマイズドサービスの利用準備が整ったことを通知し（Ｓ１６）、本処理は終了する。以降、ユーザ端末３０及びマルチテナントサーバ１０の間で、カスタマイズドサービスを利用するための処理が実行される。例えば、ユーザが、自身のユーザＩＤ及びパスワードでカスタマイズドサービスにログインすると、マルチテナントサーバ１０は、カスタマイズドサービスのポータル画面ＳＣ４を表示部３５に表示させる。

本実施形態のマルチテナントシステム１は、契約先システム２から受信したカスタマイズ情報に基づいて、カスタマイズを実行する。マルチテナントシステム１は、契約先システム２で利用申請を行ったユーザに対し、カスタマイズドサービスを提供する。これにより、ユーザによる利用申請を受け付けるたびに、ベンダーが契約先からの依頼を受けて手動でカスタマイズを実行するのではなく、利用申請からカスタマイズの流れを自動化できるので、ベンダーの手間を軽減できる。ベンダーが管理するマルチテナントサーバ１０に契約先の担当者がアクセスしてカスタマイズを実行する必要もなくなるので、契約先の手間も軽減できる。また、カスタマイズの流れを自動化することによって、人為的な設定ミスも防止できる。

また、マルチテナントシステム１は、オリジナルサービスと同じカスタマイズＡＰＩを流用して、カスタマイズを実行する。これにより、カスタマイズドサービス専用のＡＰＩを準備する必要がなくなるので、ベンダーの手間を効果的に軽減できる。例えば、カスタマイズドサービスのために何らかの改修が必要だったとしても、オリジナルサービスで利用していた既存のカスタマイズＡＰＩを流用できるので、改修の手間を軽減できる。

また、マルチテナントシステム１は、利用申請が受け付けられた場合に、カスタマイズドサービスにおける環境を作成する。これにより、ベンダー側で、カスタマイズドサービスにおける環境の作成と、カスタマイズ情報の取得と、を別々の処理として分けることができるので、ベンダー側でカスタマイズ情報を管理する手間がなくなる。例えば、契約先によりカスタマイズの内容が変更されたとしても、ベンダー側のマルチテナントサーバ１０に変更を反映する必要がないので、ベンダー側の管理負担を軽減できる。

また、マルチテナントシステム１は、環境作成ＡＰＩとは異なるカスタマイズＡＰＩに基づいて、契約先システム２から、カスタマイズ情報を取得する。これにより、カスタマイズドサービスの大まかな環境を作成するための環境作成ＡＰＩと、より細かなカスタマイズを実行するためのカスタマイズＡＰＩと、を別々にすることによって、最適なＡＰＩによって環境の作成とカスタマイズを実行できる。

また、マルチテナントシステム１は、ユーザが利用申請を行った場合に発行された認証情報に基づいて、契約先システム２に関する認証を実行する。マルチテナントシステム１は、認証が成功した場合に、契約先システム２から、カスタマイズ情報を取得する。これにより、契約先の正当性を認証したうえでカスタマイズを実行できるので、セキュリティが高まる。

また、本実施形態のサービスは、業務を支援するための業務支援サービスである。カスタマイズは、契約先が独自に提供する契約先サービスに関する業務に特有のカスタマイズである。これにより、業務支援サービスを提供するベンダーの手間を軽減できる。

［５．変形例］
なお、本開示は、以上説明した実施形態の例に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

［５－１．変形例１］
例えば、実施形態では、カスタマイズ情報が予めデータ記憶部２００に記憶されている場合を説明したが、ユーザがカスタマイズドサービスの利用申請をした場合に、カスタマイズ情報が動的に生成されてもよい。変形例１の契約先システム２では、利用申請でユーザが指定した申請内容に基づいて、カスタマイズ情報が生成される。例えば、利用申請時にレイアウトが指定される。契約先サーバ２０は、ユーザが指定したレイアウトに応じたカスタマイズ情報を生成する。

変形例１の取得部１０５は、契約先システム２から、申請内容に基づいて生成されたカスタマイズ情報を取得する。実行部１０６は、申請内容に応じたカスタマイズを実行する。カスタマイズ情報の生成方法が実施形態とは異なるが、カスタマイズ情報に基づいてカスタマイズを実行する処理の流れは、実施形態で説明した通りである。なお、レイアウト以外の他のカスタマイズが実行される場合には、利用申請時に、他のカスタマイズの内容が指定されてもよい。例えば、初期のプラグイン、アプリ、スペース、又はスレッドといった他の機能のカスタマイズが実行される場合には、ユーザは、利用申請時に、これらの内容を指定してもよい。

例えば、カスタマイズ情報は、初期のプラグイン、アプリ、スペース、又はスレッドが示されてもよい。実行部１０６は、ユーザが指定したプラグイン、アプリ、スペース、又はスレッドが最初から利用できるように、カスタマイズを実行する。例えば、実行部１０６は、ユーザが指定したプラグイン、アプリ、スペース、又はスレッドに関する情報を、サービスデータベースＤＢに格納する。提供部１０７は、この情報に基づいて、ユーザが指定したプラグイン、アプリ、スペース又はスレッドを最初から利用できるように、カスタマイズドサービスを提供する。

変形例１のマルチテナントシステム１は、契約先システム２から、申請内容に基づいて生成されたカスタマイズ情報を取得する。マルチテナントシステム１は、申請内容に応じたカスタマイズを実行する。これにより、ユーザの申請内容に応じたカスタマイズを実行することができるので、ユーザの利便性が高まる。

［５－２．変形例２］
例えば、ユーザが、契約先が独自に提供する契約先サービスを利用する場合には、契約先システム２では、契約先サービスにおけるユーザに関するユーザ情報に基づいて、カスタマイズ情報が生成されてもよい。契約先サービスは、契約先が直接的に提供するサービスである。例えば、契約先がスキャナ又は複合機といった機器を販売する会社の場合、契約先は、自社製品と連携した文書管理サービスを、契約先サービスとして提供する。契約先サービスは、オンラインストレージサービス等の他の任意のサービスであってよい。

変形例２では、ユーザが、契約先サービスのポータル画面等の画面のレイアウトをカスタマイズしているものとする。例えば、ユーザは、ユーザ端末３０を操作して契約先サービスにログインし、契約先サービスを利用する。この場合に表示される画面のレイアウトがデータ記憶部２００に記憶されている。データ記憶部２００は、契約先サービスのポータル画面のレイアウトに関する情報を記憶する。例えば、この情報は、契約先サービスの画面の背景又はロゴといった情報を含む。

例えば、契約先サーバ２０は、データ記憶部２００に記憶された契約先サービスに関する情報に基づいて、カスタマイズ情報を生成する。例えば、契約先サーバ２０は、契約先サービスのポータル画面のレイアウトと同じレイアウトになるように、カスタマイズドサービスのカスタマイズ情報を生成する。変形例２の取得部１０５は、契約先システム２から、ユーザ情報に基づいて生成されたカスタマイズ情報を取得する。実行部１０６は、ユーザ情報に応じたカスタマイズを実行する。カスタマイズ情報の生成方法が実施形態とは異なるが、カスタマイズ情報に基づいてカスタマイズを実行する処理の流れは、実施形態で説明した通りである。

なお、変形例２でも、変形例１と同様、レイアウト以外の他のカスタマイズが実行されてもよい。例えば、契約先サーバ２０は、ユーザが契約先サービスで利用中のプラグインや機器に関する情報を記憶してもよい。契約先サーバ２０は、このプラグインや機器をオリジナルサービスでも利用できるように、カスタマイズ情報を生成してもよい。マルチテナントサーバ１０の実行部１０６は、契約先サービスでユーザが利用中のプラグインや機器をオリジナルサービスでも利用できるように、カスタマイズドサービスのカスタマイズを実行すればよい。契約先サービスに関する情報と、カスタマイズ内容と、の関係は、データ記憶部１００に予め定義されているものとする。実行部１０６は、この関係に基づいて、カスタマイズを実行する。

変形例２のマルチテナントシステム１は、契約先システム２から、契約先サービスにおけるユーザ情報に基づいて生成されたカスタマイズ情報を取得する。マルチテナントシステム１は、契約先サービスにおけるユーザ情報に応じたカスタマイズを実行する。これにより、ユーザが利用中の契約先サービスに応じたカスタマイズを実行することができるので、ユーザの利便性が高まる。

［５－３．変形例３］
例えば、ユーザがオリジナルサービスを利用する場合には、実行部１０６は、カスタマイズ情報と、オリジナルサービスにおけるユーザに関するユーザ情報と、に基づいて、カスタマイズを実行してもよい。変形例３では、ユーザがオリジナルサービスを解約してカスタマイズドサービスの利用を開始する場合を説明するが、ユーザは、オリジナルサービスを解約せずに、カスタマイズドサービスの利用を開始してもよい。ユーザが利用中のオリジナルサービスに関する情報は、データ記憶部１００に記憶されているものとする。

例えば、実行部１０６は、データ記憶部１００を参照し、ユーザが利用中のオリジナルサービスのレイアウト情報を取得する。実行部１０６は、当該取得されたレイアウト情報と同じレイアウトとなるように、カスタマイズを実行する。契約先システム２から取得されたカスタマイズ情報にも何らかのレイアウトが示されているが、カスタマイズ情報では足りないものが、データ記憶部１００に格納されたレイアウト情報によって補われてもよい。

なお、変形例３でも、変形例１，２と同様、レイアウト以外の他のカスタマイズが実行されてもよい。例えば、契約先サーバ２０は、ユーザがオリジナルサービスで利用中のプラグイン、アプリ、スペース、又はスレッドに関する情報を記憶してもよい。マルチテナントサーバ１０の実行部１０６は、プラグイン、アプリ、スペース、又はスレッドをオリジナルサービスでも引き続き利用できるように、カスタマイズを実行してもよい。例えば、実行部１０６は、ユーザが利用中のオリジナルサービスのスペース情報等を、カスタマイズドサービスのスペース情報等として流用する。オリジナルサービスに関する情報と、カスタマイズ内容と、の関係は、データ記憶部１００に予め定義されているものとする。実行部１０６は、この関係に基づいて、カスタマイズを実行する。

変形例３のマルチテナントシステム１は、カスタマイズ情報と、オリジナルサービスにおけるユーザに関するユーザ情報と、に基づいて、カスタマイズを実行する。これにより、ユーザが利用中のオリジナルサービスに応じたカスタマイズを実行することができるので、ユーザの利便性が高まる。

［５－４．その他の変形例］
例えば、変形例１～３を組み合わせてもよい。

例えば、環境作成部１０２により作成された環境は、実行部により変更可能であってもよい。この場合、環境作成部１０２によりランダムにサブドメインが生成され、実行部１０６により契約先の名前が入ったサブドメインに変更されてもよい。環境作成部１０２により作成された環境は、ユーザがカスタマイズドサービスの利用を開始した後に、ユーザによって変更されてもよい。逆に、環境作成部１０２により作成された環境は、実行部１０６により変更できないようにしてもよい。更に、実行部１０６によりカスタマイズされた内容が、ユーザによって変更できないようにしてもよい。

例えば、ユーザがカスタマイズドサービスの利用を開始した後も契約先のパスワードを利用するか否かを、ユーザに選択させるようにしてもよい。契約先のパスワードを引き続き利用する場合には、ユーザがカスタマイズドサービスの何らかの設定変更を行うたびに、契約先のパスワードを利用したログインが発生するものとする。契約先のパスワードを利用しない場合には、ユーザの自らのパスワードでカスタマイズドサービスにログインし、管理者権限に基づいて設定変更が行われる。

例えば、上記説明した各機能は、マルチテナントシステム１における任意の装置で実現されるようにすればよい。例えば、マルチテナントサーバ１０で実現されるものとして説明した機能がマルチテナントシステム１内の他のコンピュータによって実現されてもよい。この場合、例えば、各機能が複数のコンピュータによって分担されてもよい。

１ マルチテナントシステム、２ 契約先システム、１０ マルチテナントサーバ、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、２０ 契約先サーバ、３０ ユーザ端末、３４ 操作部、３５ 表示部、Ｎ ネットワーク、ＤＢ サービスデータベース、１００ データ記憶部、１０１ 受付部、１０２ 環境作成部、１０３ 発行部、１０４ 認証部、１０５ 取得部、１０６ 実行部、１０７ 提供部、２００ データ記憶部、２０１ 受付部、２０２ 第１依頼部、２０３ 取得部、２０４ 第２依頼部、２０５ 通知部、３００ データ記憶部、３０１ 表示制御部、３０２ 操作受付部、Ｆ１０，Ｆ３０ 入力フォーム、Ｂ１１，Ｂ３１ ボタン、ＳＣ１，ＳＣ３ 利用申請画面、ＳＣ２，ＳＣ４ ポータル画面。

Claims (11)

1. マルチテナントでサービスを提供するマルチテナントシステムであって、
   前記サービスのベンダーと契約した契約先の契約先システムから、前記契約先に特有のカスタマイズに関するカスタマイズ情報を取得する取得部と、
   前記カスタマイズ情報に基づいて、前記カスタマイズを実行する実行部と、
   所定の利用申請を行ったユーザに対し、前記カスタマイズが実行された前記サービスであるカスタマイズドサービスを提供する提供部と、
   を含むマルチテナントシステム。
2. 前記実行部は、前記ベンダーが提供するオリジナルの前記サービスであるオリジナルサービスと同じカスタマイズＡＰＩを流用して、前記カスタマイズを実行する、
   請求項１に記載のマルチテナントシステム。
3. 前記契約先システムでは、前記利用申請で前記ユーザが指定した申請内容に基づいて、前記カスタマイズ情報が生成され、
   前記取得部は、前記契約先システムから、前記申請内容に基づいて生成された前記カスタマイズ情報を取得し、
   前記実行部は、前記申請内容に応じた前記カスタマイズを実行する、
   請求項１又は２に記載のマルチテナントシステム。
4. 前記ユーザは、前記契約先が独自に提供する契約先サービスを利用し、
   前記契約先システムでは、前記契約先サービスにおける前記ユーザに関するユーザ情報に基づいて、前記カスタマイズ情報が生成され、
   前記取得部は、前記契約先システムから、前記ユーザ情報に基づいて生成された前記カスタマイズ情報を取得し、
   前記実行部は、前記ユーザ情報に応じた前記カスタマイズを実行する、
   請求項１又は２に記載のマルチテナントシステム。
5. 前記ユーザは、前記ベンダーが提供するオリジナルの前記サービスであるオリジナルサービスを利用し、
   前記実行部は、前記カスタマイズ情報と、前記オリジナルサービスにおける前記ユーザに関するユーザ情報と、に基づいて、前記カスタマイズを実行する、
   請求項１又は２に記載のマルチテナントシステム。
6. 前記マルチテナントシステムは、前記利用申請が受け付けられた場合に、前記カスタマイズドサービスにおける環境を作成する環境作成部を更に含む、
   請求項１又は２に記載のマルチテナントシステム。
7. 前記取得部は、前記環境を作成するための環境作成ＡＰＩとは異なるカスタマイズＡＰＩに基づいて、前記契約先システムから、前記カスタマイズ情報を取得する、
   請求項６に記載のマルチテナントシステム。
8. 前記マルチテナントシステムは、
   前記ユーザが前記利用申請を行った場合に、所定の認証情報を発行する発行部と、
   前記認証情報に基づいて、前記契約先システムに関する認証を実行する認証部と、
   を更に含み、
   前記取得部は、前記認証が成功した場合に、前記契約先システムから、前記カスタマイズ情報を取得する、
   請求項１又は２に記載のマルチテナントシステム。
9. 前記サービスは、業務を支援するための業務支援サービスであり、
   前記カスタマイズは、前記契約先が独自に提供する契約先サービスに関する業務に特有のカスタマイズである、
   請求項１又は２に記載のマルチテナントシステム。
10. コンピュータがマルチテナントでサービスを提供するサービス提供方法であって、前記コンピュータが、
    前記サービスのベンダーと契約した契約先の契約先システムから、前記契約先に特有のカスタマイズに関するカスタマイズ情報を取得する取得ステップと、
    前記カスタマイズ情報に基づいて、前記カスタマイズを実行する実行ステップと、
    所定の利用申請を行ったユーザに対し、前記カスタマイズが実行された前記サービスであるカスタマイズドサービスを提供する提供ステップと、
    を実行するサービス提供方法。
11. マルチテナントでサービスを提供するコンピュータを、
    前記サービスのベンダーと契約した契約先の契約先システムから、前記契約先に特有のカスタマイズに関するカスタマイズ情報を取得する取得部、
    前記カスタマイズ情報に基づいて、前記カスタマイズを実行する実行部、
    所定の利用申請を行ったユーザに対し、前記カスタマイズが実行された前記サービスであるカスタマイズドサービスを提供する提供部、
    として機能させるためのプログラム。

Images