JP6347873B2

JP6347873B2 - サイト提供システムおよびその構築支援システム、並びにプログラム

Info

Publication number: JP6347873B2
Application number: JP2017130403A
Authority: JP
Inventors: 京介志賀; 高史鑑; 由里子大堀
Original assignee: 株式会社大和総研
Priority date: 2017-07-03
Filing date: 2017-07-03
Publication date: 2018-06-27
Anticipated expiration: 2036-03-22
Also published as: JP2017174469A

Description

本発明は、ネットワークを介して接続される顧客端末に向けて複数種類のサービスを行うためのウェブサイトを提供するコンピュータにより構成されたサイト提供システムおよびその構築支援システム、並びにプログラムに係り、例えば、パーソナル・コンピュータ、携帯電話機、スマートフォン、タブレット、または今後開発される新しいタイプのデバイス等の異なる機種の顧客端末からのアクセスを受け付け、それぞれの機種の顧客端末に対して複数種類のサービスを提供する場合に利用できる。

一般に、顧客に対し、インターネットを介してオンラインによるサービスを行うためのウェブサイトを提供するシステムは多数あり、このようなサイト提供システムの中には、顧客端末からのアクセスに対し、複数種類のサービスを選択的に提供するシステムも存在する。例えば、証券会社等の金融機関が運営・管理するサイト提供システムでは、顧客は、オンラインにより、自分の保有する株式・債券・投資信託等の各種の有価証券や預金の残高を表示するサービス、金融商品の売買注文を受け付けるサービス、入出金を受け付けるサービス等、様々なサービスの提供を受けることができるようになっている。これらのサービスは、通常、データベースに格納されているデータ（例えば株価や残高等の変動するデータ）を用いて提供されるので、顧客端末に表示されるウェブページには、変動するデータを用いて表示される動的部分が含まれている。そして、このようなデータを取り扱う処理は、サーバアプリケーション（以下、サーバアプリと略して記載することがある。）により実行される。

一方、近年では、パーソナル・コンピュータ（以下、ＰＣと略して記載することがある。）、携帯電話機（本願明細書では、スマートフォンのような多機能携帯電話機を除く従来型の携帯電話機を、単に携帯電話機と記載する。）からのアクセスに加え、スマートフォンやタブレットからのアクセスも増加し、これに伴って、ＰＣ向けのサイト、携帯電話機向けのサイト、スマートフォン／タブレット向けのサイトを用意する等、提供するサイトの数も多くなり、サイトの運営・管理は、複雑化してきた。

また、上記のように、様々な機種（デバイス）の顧客端末からのアクセスがあることから、ＰＣからのアクセスにも、スマートフォンやタブレットからのアクセスにも対応できるように、顧客端末の画面サイズに応じて画面表示の態様を変化させることができるレスポンシブ・ウェブ・デザイン（以下、ＲＷＤと略して記載することがある。）による画面作成も行われている。しかし、複数の機種の顧客端末に対応できるＲＷＤ画面によるサイトを用意したとしても、既存のＰＣ画面によるサイトをすぐに閉鎖することができるわけではない。例えば、顧客端末に搭載されたＷｅｂブラウザのバージョンの新旧に左右され、すなわち、顧客端末側でのブラウザの未更新により、ＲＷＤ画面に対応できないといった事態が生じることがある。従って、ＰＣ画面によるサイトと、ＲＷＤ画面によるサイトとを併存させ、並行稼働させる期間を設ける場合がある。また、ＰＣ画面は、ＰＣ特有の機能を発揮できるように設計し、スマートフォン向けの画面は、スマートフォン特有の機能を発揮できるように設計することもある。従って、このような場合にも、複数の種別の画面によるサイト（複数のデバイス向けのサイト）を併存させ、並行稼働させる場合がある。

そして、前述したように、顧客に対し、複数種類のサービスを提供する場合には、ＰＣ画面、携帯画面、ＲＷＤ画面等による各々のサイトにおいて、複数種類のサービスを提供することになるので、サイトの構築作業は、ますます複雑化してくる。

なお、ＰＣ向けのサイトと、スマートフォン向けのサイトとを、ウェブサーバ「Ａｐａｃｈｅ」の設定ファイルである「．ｈｔａｃｃｅｓｓファイル」を使って振り分ける方法が知られているが（非特許文献１参照）、これは、主として固定的なウェブページを用意し、振り分けて使用する方法であり、サーバアプリケーションにより、顧客の要求に係るサービスに関するデータを用いて動的部分を含む画面を作成する場合の技術ではない。

株式会社オールアバウト、"ＰＣ版とスマートフォン版サイトを自動振り分けする方法"、［online］、オールアバウトホームページ、［平成２８年２月２２日検索］、インターネット＜ＵＲＬ：http://allabout.co.jp/gm/gc/386483/＞

前述したように、複数の種別の画面によるサイト（複数のデバイス向けのサイト）を並行稼働させる際には、時間の経過に伴って新しいタイプのデバイスが開発され、世の中に登場し、普及していくので、最初にＰＣ画面によるサイトを提供していて、その後、ＲＷＤ画面によるサイトの提供を追加する場合のように、既存の利用環境に向けてのサービス提供を継続しながら、新たな利用環境に向けてＷｅｂアプリケーションのサービス提供を行う場合が多い。また、後発の事業参入者等では、複数のサイトを同時期に構築する場合もある。従来、これらの場合のいずれについても、複数のサイトを並行稼働させる際には、以下の２通りの方法により、新規サイト（既設サイトがある状態で追加する新規サイト、または、複数のサイトを同時期に構築する場合の複数の新規サイト）を開発することが考えられた。

第１の方法（複数のサイトを並行稼働させる第１の従来方式）としては、新規サイトについて、サーバアプリとともに、画面をゼロから開発する方法がある。この方法により複数のサイトの並行稼働を実現した状態では、サーバアプリも、画面も、デバイスの種類の数（サイトの数）の分だけ存在することになる。なお、複数種類のサービスに関する業務処理があれば、その業務の多様性の分だけ重畳的に開発が複雑化する。

第２の方法（複数のサイトを並行稼働させる第２の従来方式）としては、サイトの追加の場合で言えば、サーバアプリの各画面表示に関する処理を変更し、そのサーバアプリを既存画面と新画面とで共有する方法があり、この方法では、新画面はゼロから開発し、サーバアプリが、条件によって新画面と既存画面とを選択して表示することになる。また、この方法は、複数のサイトを同時期に構築する場合で言えば、複数の種別の画面を選択して使用するための画面表示に関する処理を含むサーバアプリを開発するとともに、複数種類のデバイス向けのそれぞれの画面をゼロから開発する方法ということになる。この方法により複数のサイトの並行稼働を実現した状態では、サーバアプリは共有されるが、画面は、デバイスの種類の数（サイトの数）の分だけ存在することになる。なお、サーバアプリが共有されるといっても、複数種類のサービスに関する業務処理があれば、その業務の多様性の分だけ開発が複雑化する。

しかしながら、第１の方法では、サイトの追加の場合で言えば、ゼロからの開発になるものが多いので、開発期間が長期化し、開発コストが膨大になるうえ、長期化によりビジネスチャンスを逃すことに繋がる。さらに、既存サイトで提供しているサービスと同じサービスを新規サイトで提供するにあたり、業務要件に変更がなくても、サーバアプリを再度開発することになり、バグが埋め込まれてしまうリスクが増加する。また、複数のサイトを同時期に構築する場合で言えば、提供するサービスが同じであり、業務要件が同じなのに、複数種類のデバイス向けのそれぞれの画面用のサーバアプリを開発しなければならない。

また、第２の方法では、開発期間が長期化し、開発コストが膨大になるうえ、長期化によりビジネスチャンスを逃すことに繋がるのは、第１の方法の場合と同様である。また、サイトの追加を１回行い、後日、新デバイス向けにさらに別のサイトを提供することになったときには、やはりサーバアプリの各画面表示に関する処理を変更し、新デバイス向けの新画面をゼロから開発することになるので、２回目のサイト追加時も、１回目のサイト追加時と同規模の対応が必要になり、追加するサイトの構築作業が容易であるとはいえない。また、複数のサイトを同時期に構築する場合で言えば、複数のサイトを同時期に構築した後に、後日、新デバイス向けにさらに別のサイトを提供することになったときには、やはり同規模の対応が必要になる。

従って、サイトの追加を容易に行うことができる仕組みを構築することが望まれる。また、複数のサイトを同時期に構築する場合にも、その構築作業を容易に行うことができる仕組みであることが望ましい。

本発明の目的は、並行稼働させるサイトの追加や複数のサイトの同時期の構築を容易に行うことができるサイト提供システムおよびその構築支援システム、並びにプログラムを提供するところにある。

＜サイト提供システムの発明：例えば、後述する第１実施形態の図１〜図３の場合＞

本発明は、ネットワークを介して接続される顧客端末に向けて複数種類のサービスを行うためのウェブサイトを提供するコンピュータにより構成されたサイト提供システムであって、
顧客端末からネットワークを介して送信されてくる顧客のログイン情報を受信し、受信したログイン情報を用いて顧客端末の画面の種別を判定し、判定した画面の種別を示す画面判定区分を、セッションＩＤと関連付けて画面判定区分記憶手段に記憶させる処理を実行するログイン処理手段と、
画面判定区分に対応して作成された、各サービスに関する個別の業務処理を行う業務処理アプリケーションについてのアプリケーションＩＤと各サービスで使用する画面についての画面ファイルのパスとの関連付けを定める画面定義ファイルを記憶する画面定義ファイル記憶手段と、
各サービスで使用する画面についての画面ファイルを記憶する画面ファイル記憶手段と、
顧客端末からネットワークを介して送信されてくるセッションＩＤおよびアプリケーションＩＤを含む画面表示要求信号を受信し、受信した画面表示要求信号に含まれるセッションＩＤに関連付けられて画面判定区分記憶手段に記憶された画面判定区分を取得し、取得した画面判定区分に対応する画面定義ファイルを画面定義ファイル記憶手段から読み込むことにより、受信した画面表示要求信号に含まれるアプリケーションＩＤに関連付けられたパスを取得する処理を、複数種類のサービスの全ての業務処理に共通するフレームワークの処理として実行する業務共通処理手段と、
この業務共通処理手段により受信した画面表示要求信号に含まれるアプリケーションＩＤの業務処理アプリケーションにより、要求に係るサービスの業務処理を実行する業務処理手段と、
業務共通処理手段により取得したパスを用いて、要求に係るサービスで使用する画面ファイルを画面ファイル記憶手段から読み込み、読み込んだ画面ファイルを用いて、要求に係るサービスの画面を作成する処理を、複数種類のサービスの全ての画面表示処理に共通するフレームワークの処理として実行する画面表示共通処理手段と、
業務処理手段による業務処理で得られたデータを用いて、画面表示共通処理手段により読み込んだ画面ファイルで作成される画面のうちの動的部分を作成する処理を実行する画面表示処理手段とを備え、
業務処理手段を構成するサービス毎のプログラムは、業務共通処理手段による業務共通処理を継承するサービス毎の業務処理を実行するプログラムであり、業務共通処理手段を構成するプログラムは、継承元の親クラスのプログラムであり、
画面表示処理手段を構成するサービス毎のプログラムは、画面表示共通処理手段による画面表示共通処理を継承するサービス毎の画面表示処理を実行するプログラムであり、画面表示共通処理手段を構成するプログラムは、継承元の親クラスのプログラムである
ことを特徴とするものである。

このような本発明のサイト提供システムにおいては、各サービスの提供に必要な画面についての画面ファイルのパスが画面定義ファイルに記述され、この画面定義ファイルからの画面ファイルのパスの取得が、業務共通処理手段によるフレームワークの処理として行われる。従って、既存サイトを継続して提供することを前提として、別のデバイス向けに新サイトを提供する際には、別のデバイス用の画面定義ファイルおよび画面ファイルを新たに作成して用意する必要があるが、処理の内容としては、業務処理手段により実行される各サービスの個々の業務処理については変更する必要がなく、業務共通処理手段によるフレームワークの処理に、増やす画面判定区分（追加する別のデバイス用の画面の種別を示す画面判定区分）に対応する別のデバイス用の画面定義ファイルを読み込む分岐を増やす変更を行えばよい。

このため、開発範囲の狭小化が図られ、開発作業が容易になるので、開発期間の短縮、開発コストの低減を実現することが可能となる。

また、サイトを追加する際に、フレームワークの処理以外の個々の処理を実行するアプリケーション、すなわち業務処理手段を構成する業務処理アプリを修正せずに対応することができるので、サーバアプリの開発において、新たなバグが埋め込まれてしまう可能性を少なくすることが可能となり、ビジネスリスクが減少する。

さらに、サイトの追加が容易になるので、既存の画面によるサイトと、別の画面によるサイトとの並行稼働を容易に実現することができるため、別のデバイス向けの画面によるサイトの設置が必要になり、あるいは別のデバイスが主流になった場合でも、サービス提供の場を新設のサイトに完全に置き換えてしまうのではなく、既存サイトの利用者へのサービス提供を継続することが可能となる。また、複数のサイトの並行稼働を容易に実現することができるため、システム障害発生時の代替手段を確保することも可能となる。

そして、今後、未だ世の中に存在しないか、普及していない新しいタイプのデバイスが開発され、その新しいタイプのデバイス向けの画面によるサイトを提供する必要性が生じた場合でも、現存しているか、現在普及している別のデバイス向けの画面によるサイトを追加する場合と同様に、開発の対応範囲が限定的なものとなるので、その新しいタイプのデバイス向けの画面によるサイトを容易に追加することが可能となる。

また、追加するサイトで使用される画面の開発は、既存の画面の情報を利用して行うことができるので、画面開発においてバグが埋め込まれてしまう可能性も極力排除されるようになる。

さらに、異なるデバイス向けの複数のサイトを同時期に新設する場合にも、各デバイス用の画面定義ファイルおよび画面ファイルをそれぞれ新たに作成して用意する必要はあるが、処理の内容としては、業務処理手段により実行される各サービスの個々の業務処理において各サイトへの分岐処理を設ける必要はなく、業務共通処理手段によるフレームワークの処理に、各デバイス用の画面の種別を示す画面判定区分に対応する各デバイス用の画面定義ファイルを読み込む分岐処理を設ければよい。このため、複数のサイトを同時期に構築することも容易になり、これらにより前記目的が達成される。

＜サイト提供システムの構築支援システムの発明：例えば、後述する第１実施形態の図１、図４の場合＞

本発明は、前述したサイト提供システムの構築を支援するコンピュータにより構成されたサイト提供システムの構築支援システムであって、
完成している既存の種別の画面についての画面定義ファイルおよび開発中の種別の画面についての画面定義ファイルを読み込む処理を実行する画面定義ファイル読込手段と、
この画面定義ファイル読込手段により読み込んだ画面定義ファイルから、同一のアプリケーションＩＤに関連付けられている既存の種別および開発中の種別の画面についての画面ファイルのパスを取得し、取得したパスを用いて、画面ファイル記憶手段から、既存の種別および開発中の種別の画面についての画面ファイルを読み込む処理を実行する画面ファイル読込手段と、
この画面ファイル読込手段により読み込んだ画面ファイルから、画面の動的部分を記述したコードを抽出する処理を実行する抽出手段と、
この抽出手段により抽出した既存の種別および開発中の種別の画面の動的部分を記述したコードを対比して画面表示および／または印刷する処理、動的部分を記述したコードの差異若しくは過不足を画面表示および／または印刷する処理、動的部分を記述したコードの抽出数を対比して画面表示および／または印刷する処理のうちの少なくとも１つの処理を実行する対比結果出力手段と
を備えたことを特徴とするものである。

ここで、「開発中の種別の画面」における「開発中」とは、確認対象、すなわち対比チェックの対象であることを意味するので、必ずしも開発環境に置かれている状態に限定されるものではなく、例えば、システムの不具合が発生した場合に、本番環境に置かれている状態のものを確認する場合も含まれる。また、開発完了後の最終確認や再確認の場合も含まれる。これらの場合は、ここでいう「開発中」とみなされる状態だからである。従って、「画面ファイル記憶手段」については、主として開発環境下の画面ファイル記憶手段を指すことになるが、本番環境下の画面ファイル記憶手段も含まれる。以下の発明においても同様である。

このような本発明のサイト提供システムの構築支援システムにおいては、既存の種別および開発中の種別の画面の動的部分を記述したコードを対比して確認することができるので、画面開発においてバグが埋め込まれてしまう可能性を低減することが可能となる。すなわち、サーバアプリケーションを共通利用して新規画面のサイトを提供する場合には、バグが生じる可能性が高いのは、画面の動的項目の部分であるので、デザイン上の制約がない状態で新規画面を開発し、その後、既存の種別の画面についての画面ファイルと、開発中の種別の画面についての画面ファイルとを読み込み、それらから抽出した動的部分を記述したコードを対比して出力し、あるいは差異や過不足、抽出数を出力することで、バグの埋め込みを回避することが可能となる。

また、既存の種別および開発中の種別の画面についての画面ファイルを読み込む際には、画面定義ファイルに記述されている画面ファイルのパスを取得し、取得したパスを用いて読込処理を行うので、対応する多くの画面ファイルの対比チェックを容易に、かつ短時間で行うことが可能となるため、画面開発の開発効率の向上が図られる。そして、画面開発の進捗管理も容易に行うことが可能となる。

さらに、対応する画面ファイルを１対ずつ順番に読み込んで対比して確認する作業を繰り返す場合には、確認作業者が、確認対象の各画面ファイルのパスを把握していて、それを読込対象として毎回入力することになるので、手間がかかるうえ、対応する画面ファイルのパスが、確認作業者にとって記憶しやすく、把握しやすいものになっている必要がある。これに対し、本発明では、画面定義ファイルに記述されている画面ファイルのパスを利用して読込処理を行うので、画面ファイルのパスが確認作業者にとって記憶しにくく、把握しにくいものになっていたとしても、容易に画面ファイルの読込処理を行うことが可能となる。

＜プログラムの発明＞

本発明のプログラムは、以上に述べたサイト提供システムとして、コンピュータを機能させるためのものである。

また、本発明のプログラムは、以上に述べたサイト提供システムの構築支援システムとして、コンピュータを機能させるためのものである。

なお、以上に述べたプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）を利用した読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）、デジタル・バーサタイル・ディスク（ＤＶＤ）を利用した読出し専用メモリ（ＤＶＤ−ＲＯＭ）、ＤＶＤを利用したランダム・アクセス・メモリ（ＤＶＤ−ＲＡＭ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ＬＡＮ、ＭＡＮ、ＷＡＮ、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、以上に述べたプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。

以上に述べたように本発明によれば、顧客端末の画面の種別を示す画面判定区分を記憶する画面判定区分記憶手段を設けるとともに、画面ファイルのパスを記述した画面定義ファイルを用意し、フレームワークの処理で、画面判定区分に対応する画面定義ファイルを読み込むようにしたので、開発範囲の狭小化を図ることができ、並行稼働させるサイトの追加や複数のサイトの同時期の構築を容易に行うことができるという効果がある。

本発明の第１実施形態のサイト提供システムおよびその構築支援システムの全体構成図。第１実施形態のサイト提供システムによるサービス提供に関する処理の流れを示すフローチャートの図。第１実施形態のサイト提供システムによるサービス提供に関する処理の流れを示すフローチャートの続きの図。第１実施形態の構築支援システムによるサイト構築支援に関する処理の流れを示すフローチャートの図。本発明の第２実施形態のサイト提供システムおよびその構築支援システムの全体構成図。第２実施形態のサイト提供システムによるサービス提供に関する処理の流れを示すフローチャートの図。第２実施形態のサイト提供システムによるサービス提供に関する処理の流れを示すフローチャートの続きの図。第２実施形態の構築支援システムによるサイト構築支援に関する処理の流れを示すフローチャートの図。

以下に本発明の各実施形態について図面を参照して説明する。

［第１実施形態］

図１には、本発明の第１実施形態のサイト提供システム１０およびその構築支援システム６０の全体構成が示されている。図２および図３には、サイト提供システム１０によるサービス提供に関する処理の流れがフローチャートで示されている。図４には、構築支援システム６０によるサイト構築支援に関する処理の流れがフローチャートで示されている。

図１において、サイト提供システム１０は、ネットワーク１を介して接続される様々なデバイスの顧客端末７０，８０，９０等に対し、各種のサービス業務を行うウェブサイトを提供するシステムである。例えば、証券会社等の金融機関が運営・管理するサイト提供システム１０の場合には、顧客の保有する株式・債券・投資信託等の各種の有価証券や預金の残高を表示するサービス、買付余力を表示するサービス、取引残高報告書を表示するサービス、金融商品の売買注文を受け付けるサービス、入出金を受け付けるサービス等である。なお、本願明細書でサービスというときは、サイト全体で提供される包括的な概念のサービスではなく、ウェブ画面上での顧客の操作（クリックやタッチによる選択操作、入力操作等）により実行される各々の業務処理を指すものとする。

ネットワーク１は、主としてインターネットにより構成され、このインターネットに、例えばイントラネットやローカル・エリア・ネットワーク（ＬＡＮ）等の各種の通信網が接続されて構成されている。

サイト提供システム１０は、１台または複数台のコンピュータにより構成され、本実施形態では、一例として、ウェブサーバおよびアプリケーションサーバの機能を有するＷＥＢ／ＡＰサーバ２０と、セッション管理サーバ４０と、データベースサーバ５０とを備えて構成されている。なお、サイト提供システム１０を構成するサーバ（コンピュータ）の台数は任意であり、例えば、ウェブサーバとアプリケーションサーバとを異なるコンピュータで構成してもよく、逆に、セッション管理サーバ４０やデータベースサーバ５０を、ＷＥＢ／ＡＰサーバ２０と同じコンピュータにより構成してもよい。

ＷＥＢ／ＡＰサーバ２０は、１台または複数台のコンピュータにより構成され、ログイン処理手段２１と、業務共通処理手段２２と、業務処理手段２３と、画面表示共通処理手段２４と、画面表示処理手段２５と、顧客情報記憶手段３０と、画面定義ファイル記憶手段３１と、画面ファイル記憶手段３２とを含んで構成されている。

ログイン処理手段２１は、顧客端末７０等からの要求に応じてログイン画面を送信し、顧客端末７０等からネットワーク１を介して送信されてくる顧客のログイン情報（画面の種別を示す情報を含む。）を受信し、受信したログイン情報を用いて顧客端末７０等の画面の種別を判定し、判定した画面の種別を示す画面判定区分を、セッションＩＤと関連付けてセッション管理サーバ４０のセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶させる処理を実行するものである。

具体的には、ログイン処理手段２１は、顧客端末７０等からネットワーク１を介して送信されてくるログイン画面の表示要求信号を受信し、受信した表示要求信号に対応するログイン画面（ＰＣログイン画面、ＲＷＤログイン画面、またはその他のデバイス用のログイン画面）のファイルを画面ファイル記憶手段３２から取得し、そのログイン画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する処理を実行する。

また、ログイン処理手段２１は、ログイン画面が表示されている顧客端末７０等からネットワーク１を介して送信されてくるログイン情報（顧客識別情報、ログインパスワードに加え、画面の種別を示す情報を含む。）を受信し、受信した顧客識別情報およびログインパスワードと、顧客情報記憶手段３０に記憶された顧客識別情報およびログインパスワードとを比較して顧客のログイン認証処理を実行し、認証された場合には、受信したログイン情報に含まれる画面の種別（ＰＣ画面、ＲＷＤ画面、またはその他のデバイス用の画面の別）を示す情報を用いて要求元の顧客端末７０等の画面の種別を判定し、判定結果として得られた画面判定区分を、認証された顧客についての顧客名や口座情報等（顧客情報記憶手段３０に記憶されているデータ）とともに、セッション管理サーバ４０へ渡す処理を実行する。

さらに、ログイン処理手段２１は、ログイン認証後に、要求元の顧客端末７０等の画面の種別に応じたトップ画面（ＰＣトップ画面、ＲＷＤトップ画面、またはその他のデバイス用のトップ画面）のファイルを、画面ファイル記憶手段３２から取得し、そのトップ画面の表示用データ（顧客情報記憶手段３０から取得した顧客名等が含まれていてもよい。）を、ネットワーク１を介して要求元の顧客端末７０等へ送信する処理を実行する。

業務共通処理手段２２は、顧客端末７０等からネットワーク１を介して送信されてくる画面表示要求信号（次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤを含む。）を受信し、受信した画面表示要求信号に含まれるセッションＩＤに関連付けられてセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶された画面判定区分を、セッション管理サーバ４０から取得し、取得した画面判定区分に対応する画面定義ファイルを、画面定義ファイル記憶手段３１から読み込むことにより、受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）に関連付けられた画面ファイル（ＪＳＰ）のパス、画面表示アプリの識別情報（ｃｌａｓｓ）、および状態（ｃｏｄｅ）を取得する処理を、複数種類のサービスの全ての業務処理に共通するフレームワークの処理として実行するものである。

また、業務共通処理手段２２は、下記の業務処理手段２３でデータベースサーバ５０のデータベース５２から取得したデータ、並びに、画面定義ファイルから取得した正常時または異常時についての画面ファイル（ＪＳＰ）のパスおよび画面表示アプリの識別情報（ｃｌａｓｓ）を、セッションＩＤとともに、画面表示共通処理手段２４に渡す処理を実行する。

業務処理手段２３は、業務共通処理手段２２により受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）の業務処理アプリケーションにより、要求に係るサービスの業務処理を実行するものである。この業務処理手段２３は、要求に係るサービスの業務処理として、そのサービスの提供に必要なデータを、データベースサーバ５０のデータベース５２から取得する処理を実行する。従って、業務共通処理手段２２が複数種類のサービスの全てに共通する処理を実行するのに対し、この業務処理手段２３は、個々のサービスの処理を実行するものであり、サービス毎に設けられている。

具体的には、サービスに係る業務処理を実行するプログラムを、一例としてｊａｖａ（登録商標）で記述する場合には、業務処理手段２３は、業務共通処理手段２２による業務共通処理を継承する業務処理を実行するプログラム（ｃｌａｓｓ）により実現される。従って、業務共通処理手段２２を実現するプログラム（ｃｌａｓｓ）は、継承元の親クラス（スーパークラス、基底クラス等とも称される。）となる。

画面表示共通処理手段２４は、業務共通処理手段２２から受け取った画面ファイル（ＪＳＰ）のパスを用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段３２から読み込み、読み込んだ画面ファイル（ＪＳＰ）を用いて、要求に係るサービスの画面の表示用データ（Ｗｅｂページ）を作成し、作成した画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する処理を、複数種類のサービスの全ての画面表示処理に共通するフレームワークの処理として実行するものである。なお、ここで作成されて顧客端末７０等へ送信される画面の表示用データ（Ｗｅｂページ）には、その次の画面に遷移するためのボタン（例えば「次へ」ボタン等）が設けられ、このボタンの付帯情報として、その次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤ（ａｉｄ）が含まれているので、顧客端末７０等で、そのボタン（例えば「次へ」ボタン等）が選択操作（クリック操作等）されると、それらの付帯情報がＷＥＢ／ＡＰサーバ２０へ送信されてくることになる。

画面表示処理手段２５は、画面表示共通処理手段２４で業務共通処理手段２２から受け取った名称（ｃｌａｓｓ：画面表示アプリの識別情報）の画面表示アプリケーションにより、業務共通処理手段２２から受け取ったデータ（業務処理手段２３による業務処理でデータベースサーバ５０のデータベース５２から取得したデータ）を用いて、画面表示共通処理手段２４により読み込んだ画面ファイル（ＪＳＰ）で作成される画面のうち、要求に係るサービスのデータを用いて表示される動的部分を作成する処理を実行するものである。従って、画面表示共通処理手段２４が複数種類のサービスの全てに共通する処理を実行するのに対し、この画面表示処理手段２５は、個々のサービスの処理を実行するものであり、サービス毎に設けられている。

具体的には、サービスに係る画面表示処理を実行するプログラムを、一例としてｊａｖａ（登録商標）で記述する場合には、画面表示処理手段２５は、画面表示共通処理手段２４による画面表示共通処理を継承する画面表示処理を実行するプログラム（ｃｌａｓｓ）により実現される。従って、画面表示共通処理手段２４を実現するプログラム（ｃｌａｓｓ）は、継承元の親クラスとなる。

顧客情報記憶手段３０は、顧客名、顧客識別情報である口座情報（部店コード、口座番号等）、ログインパスワード等を対応付けて記憶するものである。

画面定義ファイル記憶手段３１は、画面判定区分に対応して用意されている画面定義ファイルを記憶するものである。この画面定義ファイルは、例えば、ＸＭＬで記述されている。画面判定区分＝０（ＰＣ画面）の場合には、例えば、「ｚａｎｄａｋａＳｙｏｋａｉ＿０．ｘｍｌ」というファイル名の画面定義ファイルを用意し、画面判定区分＝１（ＲＷＤ画面）の場合には、例えば、「ｚａｎｄａｋａＳｙｏｋａｉ＿１．ｘｍｌ」というファイル名の画面定義ファイルを用意すること等により、画面判定区分に対応させることができる。その他のデバイスに対応する場合も、別のファイル名の画面定義ファイルを用意することで対応することができる。また、用意する画面定義ファイルの数は、画面判定区分の数と同数としてもよいが、必ずしも同数とする必要はなく、例えば、上記の例のように残高照会という種類のサービスについて、画面判定区分の数と同数の画面定義ファイルを用意する等、サービスの種類毎に用意してもよく、要するに、同じサービスについて画面判定区分に対応させて画面判定区分の数と同数の画面定義ファイルを用意すればよい。

画面定義ファイルには、各サービスに関する個別の業務処理を実行する業務処理アプリケーションソフトを識別するためのアプリケーションＩＤ（例えば、主要口座お預り資産を表示する業務処理では、ａｉｄ＝“ｚａｎ０１２”等）と関連付けられた状態で、正常時および異常時（タイムエラー、システムエラー等）のそれぞれについての画面ファイル（ＪＳＰ）のパス（例えば、ｊｓｐ＝“／…／…．ｊｓｐ”）、画面表示アプリの識別情報（ｃｌａｓｓ＝“…”）、状態（ｃｏｄｅ＝“…”）が記述されている。

このうち、画面ファイル（ＪＳＰ）のパスについては、ＰＣ画面用の画面定義ファイルでは、例えば、ｊｓｐ＝“／ＪＳＰ／ｉｎｔｅｒ／ｚａｎｄａｋａＳｙｏｋａｉ／ＡｚｕｋａｒｉＳｈｉｓａｎＳｕｍｍａｒｙ．ｊｓｐ”となり、ＲＷＤ画面用の画面定義ファイルでは、例えば、ｊｓｐ＝“／ＪＳＰ／ｒｗｄ／ｚａｎｄａｋａＳｙｏｋａｉ／ＡｚｕｋａｒｉＳｈｉｓａｎＳｕｍｍａｒｙ．ｊｓｐ”となる等、異なるパスが定義されている。この例では、ファイル名は同じだが、画面ファイルを格納するフォルダ名を別の名称にしている。なお、画面表示アプリの識別情報（ｃｌａｓｓ）は、ＰＣ画面用の画面定義ファイルとＲＷＤ画面用の画面定義ファイルとで原則同じ名称とする。

また、状態については、正常時であれば、例えば、ｃｏｄｅ＝“ＡＺＵＫＡＲＩ＿ＳＨＩＳＡＮ＿ＳＵＭＭＡＲＹ”等となり、異常時であれば、例えば、ｃｏｄｅ＝“ＴＩＭＥ＿ＥＲＲＯＲ”、ｃｏｄｅ＝“ＳＹＳＴＥＭ＿ＥＲＲＯＲ”等となる。

画面ファイル記憶手段３２は、ＰＣ画面、ＲＷＤ画面、その他のデバイス向けの画面のそれぞれについての画面ファイル（ＪＳＰ）を記憶するものである。この画面ファイルは、各サービスで使用する画面を作成するためのファイルであり、データベース５２から取得したデータを用いて表示される動的部分を含む画面を作成するためのコードが記述されている。本実施形態では、一例として、画面ファイルは、ＷＥＢページ内にＪａｖａコード（Ｊａｖａは登録商標）を埋め込んだＪＳＰ（ＪａｖａＳｅｒｖｅｒＰａｇｅｓ）とするので、このＪａｖａコードをＷＥＢ／ＡＰサーバ２０上で実行して得られた結果を反映したページを動的に生成することができる。なお、ＰＣ画面用の画面ファイル（ＪＳＰ）と、ＲＷＤ画面用の画面ファイル（ＪＳＰ）と、その他のデバイス向けの画面用の画面ファイル（ＪＳＰ）とは、別のフォルダに格納され、異なるパスを指定して取得できるようになっている。

また、画面ファイル記憶手段３２には、ＰＣ画面、ＲＷＤ画面、その他のデバイス向けの画面のそれぞれについてのログイン画面およびトップ画面のファイルも記憶されている。なお、トップ画面もＪＳＰで作成してもよいが、本実施形態では、説明の便宜上、その場合の処理の流れの記載は省略している（図２参照）。

セッション管理サーバ４０は、１台または複数台のコンピュータにより構成され、セッション管理手段４１と、セッション情報記憶手段４２とを含んで構成されている。

セッション管理手段４１は、顧客のログイン時に、ログイン認証された顧客についての顧客名や口座情報等、および画面判定区分を、ＷＥＢ／ＡＰサーバ２０のログイン処理手段２１から受け取り、この顧客からのアクセスに対し、セッションＩＤを自動付与し、セッション情報記憶手段４２に、そのセッションＩＤを含むセッション情報および画面判定区分を格納する領域を生成して確保し、確保した領域に、顧客名や口座情報等、および画面判定区分を、セッションＩＤと関連付けて記憶させる処理を実行するものである。

また、セッション管理手段４１は、ＷＥＢ／ＡＰサーバ２０の業務共通処理手段２２からの画面判定区分の問い合わせ信号（セッションＩＤを伴う。）を受け付け、受け付けたセッションＩＤに関連付けられた画面判定区分をセッション情報記憶手段４２から取得し、取得した画面判定区分を、ＷＥＢ／ＡＰサーバ２０の業務共通処理手段２２に渡す処理も実行する。

セッション情報記憶手段４２は、セッション情報（セッションＩＤ、顧客名、口座情報等を含む。）および画面判定区分を対応付けて記憶するものである。従って、このセッション情報記憶手段４２には、本発明における画面判定区分記憶手段（請求項に記載された画面判定区分記憶手段）が含まれる。なお、セッション情報（セッションＩＤ、顧客名、口座情報等を含む。）とは別に、画面判定区分をセッションＩＤと関連付けて記憶する画面判定区分記憶手段を設けてもよい。

データベースサーバ５０は、１台または複数台のコンピュータにより構成され、データベース管理手段５１と、データベース５２とを含んで構成されている。

データベース管理手段５１は、データベース５２を管理し、外部のソフトウェア（ここでは、ＷＥＢ／ＡＰサーバ２０の業務処理手段２３を構成する業務処理アプリケーション）からの要求に応えてデータベース５２の操作処理を実行するものであり、いわゆるデータベース・マネジメント・システム（ＤＢＭＳ）である。

データベース５２は、業務処理手段２３による各サービスに関する個別の業務処理で使用される各種のデータを記憶するものである。例えば、証券会社等の金融機関のサイトの場合には、データベース５２に記憶されるデータは、顧客の保有する株式・債券・投資信託等の各種の有価証券の保有数量データ、顧客の預金残高データ、顧客の買付余力のデータ、取引残高報告書のデータ、売買履歴データ、各種の金融商品の時価データ等である。このうち、各顧客のデータについては、顧客識別情報（例えば、顧客の口座情報等）に関連付けられて記憶され、各種の金融商品に関するデータについては、金融商品の銘柄識別情報（銘柄コード）に関連付けられて記憶されている。

構築支援システム６０は、１台または複数台のコンピュータにより構成され、画面定義ファイル読込手段６１と、画面ファイル読込手段６２と、抽出手段６３と、対比結果出力手段６４とを含んで構成されている。

画面定義ファイル読込手段６１は、完成している既存の種別の画面についての画面定義ファイル（例えばＰＣ画面用の画面定義ファイル）および開発中の種別の画面についての画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む処理を実行するものである。通常は、開発環境下の画面定義ファイル記憶手段３１から読み込むが、本番環境下の画面定義ファイル記憶手段３１から読み込んでもよく、あるいは画面定義ファイル記憶手段３１とは別の格納場所や、サイト提供システム１０を構成するコンピュータとは別のコンピュータのハードディスクやＵＳＢメモリ等の記録媒体から読み込んでもよい。

画面ファイル読込手段６２は、画面定義ファイル読込手段６１により読み込んだ画面定義ファイルから、同一のアプリケーションＩＤ（ａｉｄ）に関連付けられ、かつ、同一の状態（ｃｏｄｅ）で使用される既存の種別の画面（例えば、ＰＣ画面）および開発中の種別の画面（例えば、ＲＷＤ画面）についての画面ファイル（ＪＳＰ）のパスを取得し、取得したパスを用いて、画面ファイル記憶手段３２から、既存の種別および開発中の種別の画面についての各画面ファイル（ＪＳＰ）を読み込む処理を実行するものである。通常は、開発環境下の画面ファイル記憶手段３２から読み込むが、本番環境下の画面ファイル記憶手段３２から読み込んでもよい。

抽出手段６３は、画面ファイル読込手段６２により読み込んだ各画面ファイル（ＪＳＰ）から、画面の動的部分を記述したコードを抽出する処理を実行するものである。動的部分とは、固定されたコードの部分ではなく、変数（パラメータ）になっている部分であり、例えば、データベース５２から取得されたデータの表示部分等である。抽出するのは、動的部分の中心となる変数（パラメータ）だけでもよいが、その周囲のコードも含めて抽出してもよい。

対比結果出力手段６４は、抽出手段６３により抽出した既存の種別の画面（例えば、ＰＣ画面）および開発中の種別の画面（例えば、ＲＷＤ画面）の動的部分を記述したコードを対比して画面表示および／または印刷する処理、動的部分を記述したコードの差異若しくは過不足を画面表示および／または印刷する処理、動的部分を記述したコードの抽出数を対比して画面表示および／または印刷する処理のうちの少なくとも１つの処理を実行するものである。

顧客端末７０は、パーソナル・コンピュータにより構成され、顧客端末８０は、スマートフォンやタブレットにより構成され、顧客端末９０は、その他のデバイス（例えばウェアラブル端末、音声認識端末、立体画像端末等の新しいデバイスを含む。）により構成されている。いずれのデバイスによる顧客端末７０，８０，９０も、マウスやキーボードや音声認識器等の入力手段と、サイトの構成画面を表示する液晶ディスプレイ等の表示手段とを備えている。また、適宜、印刷装置を備えていてもよい。

以上において、サイト提供システム１０のＷＥＢ／ＡＰサーバ２０に設けられた業務共通処理手段２２、業務処理手段２３、画面表示共通処理手段２４、および画面表示処理手段２５、セッション管理サーバ４０に設けられたセッション管理手段４１、データベースサーバ５０に設けられたデータベース管理手段５１、並びに、構築支援システム６０の画面定義ファイル読込手段６１、画面ファイル読込手段６２、抽出手段６３、および対比結果出力手段６４は、サイト提供システム１０の各サーバ２０，４０，５０や構築支援システム６０を構成する各コンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。

また、サイト提供システム１０のＷＥＢ／ＡＰサーバ２０に設けられた顧客情報記憶手段３０、画面定義ファイル記憶手段３１、および画面ファイル記憶手段３２、セッション管理サーバ４０に設けられたセッション情報記憶手段４２、並びに、データベースサーバ５０に設けられたデータベース５２は、例えばハードディスク等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えばフラッシュ・メモリ等の他の記録媒体を採用してもよい。

このような第１実施形態においては、以下のようにしてサイト提供システム１０により、顧客へのサービス提供に関する各種処理が実行される。

図２において、先ず、ＷＥＢ／ＡＰサーバ２０で、ログイン処理手段２１により、顧客端末７０等からネットワーク１を介して送信されてくる顧客のログイン画面の表示要求信号を受信すると、その表示要求信号が、パーソナル・コンピュータ用のＰＣログイン画面（例えば、ｈｔｔｐ：／／…／ｌｏｇｉｎ．ｈｔｍｌというＵＲＬ）の表示要求信号である場合には、画面ファイル記憶手段３２に記憶されているＰＣログイン画面のファイルを取得し、ＰＣログイン画面の表示用データを、ネットワーク１を介して要求元の顧客端末（通常は、ＰＣがデバイスである顧客端末７０となる。）へ送信する（ステップＳ１）。また、受信した表示要求信号が、スマートフォンやタブレットにも対応可能なＲＷＤログイン画面（例えば、ｈｔｔｐ：／／…／ｌｏｇｉｎ＿ｒ．ｈｔｍｌというＵＲＬ）の表示要求信号である場合には、画面ファイル記憶手段３２に記憶されているＲＷＤログイン画面のファイルを取得し、ＲＷＤログイン画面の表示用データを、ネットワーク１を介して要求元の顧客端末（通常は、スマートフォンやタブレットがデバイスである顧客端末８０となる。）へ送信する（ステップＳ１）。

なお、ＰＣの顧客端末７０で検索を行った場合には、通常は、ＰＣログイン画面（例えば、ｈｔｔｐ：／／…／ｌｏｇｉｎ．ｈｔｍｌというＵＲＬ）がヒットし、スマートフォンやタブレットの顧客端末８０で検索を行った場合には、通常は、ＲＷＤログイン画面（例えば、ｈｔｔｐ：／／…／ｌｏｇｉｎ＿ｒ．ｈｔｍｌというＵＲＬ）がヒットするようになっている。従って、例えば、ＲＷＤログイン画面のＵＲＬを記憶しておき、それをＰＣで打ち込んで表示させるといった特殊な操作を行わない限り、アクセス元のデバイスに対応したログイン画面が表示される。

また、ここでは、主としてＰＣの顧客端末７０、およびスマートフォン／タブレットの顧客端末８０からのアクセスがあるものとして説明を行うが、本実施形態のサイト提供システム１０へのアクセスを行うデバイスの種別は、これらに限定されるものではない。従って、例えばウェアラブル端末や音声認識端末等、新しいデバイスが世の中に登場し、それに対して、新しいデバイス向けのログイン画面が用意され、新しいサイトが用意された場合には、その新しいデバイス向けのログイン画面の表示用データを、ネットワーク１を介して要求元の新しいデバイスの顧客端末９０へ送信することになる。

続いて、ログイン処理手段２１により、ログイン画面が表示されている顧客端末７０等からネットワーク１を介して送信されてくるログイン情報（顧客識別情報、ログインパスワードに加え、画面の種別を示す情報を含む。）を受信し、受信した顧客識別情報およびログインパスワードと、顧客情報記憶手段３０に記憶された顧客識別情報およびログインパスワードとを比較して顧客のログイン認証処理を実行する（ステップＳ１）。なお、顧客識別情報は、証券会社等の金融機関のサイトである場合には、例えば、顧客の口座情報（部店コード、口座番号等）である。

さらに、アクセスした顧客が認証された場合には、ログイン処理手段２１により、受信したログイン情報に含まれる画面の種別を示す情報を用いて要求元の顧客端末７０等の画面の種別を判定し、画面判定区分を決定する（ステップＳ１）。例えば、画面の種別を示す情報が、ＰＣ画面を示す情報（例えばｒｏｏｔ＝ｐｃ）である場合（ＰＣログイン画面からのログインである場合）には、画面判定区分＝０とし、ＲＷＤ画面を示す情報（例えばｒｏｏｔ＝ｒｗｄ）である場合（ＲＷＤログイン画面からのログインである場合）には、画面判定区分＝１とする。なお、本実施形態では、画面判定区分は、０，１のような数値情報であるが、提供するサイトの数（画面の種別の数）が２つの場合には、フラグのように、ＯＮ、ＯＦＦとしてもよく、本願明細書でいう画面判定区分は、画面判定フラグを含む概念である。

そして、ログイン処理手段２１により、得られた画面判定区分を、認証された顧客についての顧客名や口座情報等（顧客情報記憶手段３０に記憶されているデータ）とともに、セッション管理サーバ４０へ渡す（ステップＳ１）。

セッション管理サーバ４０では、セッション管理手段４１により、認証された顧客についての顧客名や口座情報等、および画面判定区分を、ＷＥＢ／ＡＰサーバ２０のログイン処理手段２１から受け取り、この顧客からのアクセスに対し、セッションＩＤを自動付与し、セッション情報記憶手段４２に、そのセッションＩＤを含むセッション情報および画面判定区分を格納する領域を生成して確保し、確保した領域に、顧客名や口座情報等、および画面判定区分を、セッションＩＤと関連付けて記憶させる（ステップＳ１）。

次に、ログイン処理手段２１により、要求元の顧客端末７０等の画面の種別に応じたトップ画面のファイルを、画面ファイル記憶手段３２から取得し、そのファイルを用いてトップ画面の表示用データを作成し、作成したトップ画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する（ステップＳ２）。例えば、ＰＣログイン画面からのログインがあった場合には、ＰＣトップ画面を送信し、ＲＷＤログイン画面からのログインがあった場合には、ＲＷＤトップ画面を送信し、その他のデバイス向けのログイン画面からのログインがあった場合には、その他のデバイス向けのトップ画面を送信する。この際、要求元の顧客端末７０等に送信するトップ画面の表示用データには、次画面のＵＲＬ、業務処理アプリケーションを識別するアプリケーションＩＤ、およびセッションＩＤが含まれている。また、トップ画面の表示用データには、顧客情報記憶手段３０から取得した顧客名等が含まれていてもよい。なお、トップ画面についても、以下に述べるように、その次の画面以降の画面と同様に、動的部分を含む画面を作成するための画面ファイル（ＪＳＰ）を用いて作成してもよいが、ここでは、説明の便宜上、その場合の処理の流れの記載は省略している。

図３において、業務共通処理手段２２により、顧客端末７０等からネットワーク１を介して送信されてくる画面表示要求信号（次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤを含む。）を受信する（ステップＳ３）。

続いて、業務共通処理手段２２により、顧客端末７０等から受信した画面表示要求信号に含まれるセッションＩＤをセッション管理サーバ４０に渡す（ステップＳ３）。セッション管理サーバ４０では、セッション管理手段４１により、ＷＥＢ／ＡＰサーバ２０の業務共通処理手段２２からの画面判定区分の問い合わせ信号（セッションＩＤを伴う。）を受け付け、受け付けたセッションＩＤに関連付けられた画面判定区分をセッション情報記憶手段４２から取得し、取得した画面判定区分を、ＷＥＢ／ＡＰサーバ２０の業務共通処理手段２２に渡す（ステップＳ３）。

ＷＥＢ／ＡＰサーバ２０では、業務共通処理手段２２により、画面判定区分を受け取ると、その画面判定区分に対応する画面定義ファイルを、画面定義ファイル記憶手段３１から読み込む。例えば、画面判定区分＝０の場合には、ＰＣ画面用の画面定義ファイルを読み込み、画面判定区分＝１の場合には、ＲＷＤ画面用の画面定義ファイルを読み込む。なお、この読込は、画面判定区分＝０の場合に読み込むべきＰＣ画面用の画面定義ファイルの識別情報（名称）、および画面判定区分＝１の場合に読み込むべきＲＷＤ画面用の画面定義ファイルの識別情報（名称）が、業務共通処理手段２２を構成するフレームワーク（ｊａｖａ（登録商標）の場合には親クラス）に記述されていることにより実現される。そして、読み込んだ画面定義ファイルの中から、受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）に関連付けられた画面ファイル（ＪＳＰ）のパス、画面表示アプリの識別情報（ｃｌａｓｓ）、および状態（ｃｏｄｅ）を取得する（ステップＳ３）。従って、ここで取得する画面ファイル（ＪＳＰ）のパスは、画面判定区分＝０の場合には、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスであり、画面判定区分＝１の場合には、ＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスである。

それから、業務処理手段２３により、業務共通処理手段２２で受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）の業務処理アプリケーションにより、要求に係るサービスの業務処理を実行する。すなわち、業務処理手段２３により、要求に係るサービスの提供に必要なデータを、データベースサーバ５０のデータベース５２から取得する（ステップＳ４）。なお、このステップＳ４のデータ取得処理は、前述したステップＳ３の画面定義ファイルの読み込み処理の前に実行してもよい。

その後、業務処理手段２３でデータベースサーバ５０のデータベース５２から取得したデータ、並びに、画面定義ファイルから取得した正常時または異常時についての画面ファイル（ＪＳＰ）のパスおよび画面表示アプリの識別情報（ｃｌａｓｓ）を、セッションＩＤとともに、業務共通処理手段２２から画面表示共通処理手段２４へ渡す（ステップＳ５）。具体的には、データベース５２から取得したデータとして、例えば、顧客の残高データであれば「ＺＡＮＤＡＫＡ，１００００００」、法人フラグであれば「ＨＯＪＩＮ＿ＦＬＧ，１」等のデータを渡す。また、画面定義ファイルから取得した画面情報として、例えば、正常時について定義された情報であれば「ＮＯＲＭＡＬ，ｃｌａｓｓ＝“…”，ｊｓｐ＝“／…／…．ｊｓｐ”」、異常時について定義された情報であれば「ＴＩＭＥ＿ＥＲＲＯＲ，ｃｌａｓｓ＝“…”，ｊｓｐ＝“／…／…．ｊｓｐ”」、「ＳＹＳＴＥＭ＿ＥＲＲＯＲ，ｃｌａｓｓ＝“…”，ｊｓｐ＝“／…／…．ｊｓｐ”」等の画面情報を渡す。

続いて、画面表示共通処理手段２４により、業務共通処理手段２２から受け取った画面ファイル（ＪＳＰ）のパスを用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段３２から読み込む（ステップＳ５）。

さらに、画面表示処理手段２５により、画面表示共通処理手段２４で業務共通処理手段２２から受け取った名称（ｃｌａｓｓ：画面表示アプリの識別情報）の画面表示アプリにより、業務共通処理手段２２から受け取ったデータ（業務処理手段２３による業務処理で得られたデータ）を用いて、画面表示共通処理手段２４により読み込んだ画面ファイル（ＪＳＰ）で作成される画面のうち、要求に係るサービスのデータを用いて表示される動的部分を作成する（ステップＳ６）。例えば、業務共通処理手段２２から、「ＺＡＮＤＡＫＡ，１００００００」という残高データを受け取ったとすれば「１，０００，０００円」という動的部分を作成し、「ＨＯＪＩＮ＿ＦＬＧ，１」という法人フラグのデータを受け取ったとすれば「“法人”」という動的部分を作成する。

そして、画面表示共通処理手段２４により、読み込んだ画面ファイル（ＪＳＰ）を用いて、画面表示処理手段２５で作成された画面の動的部分も含め、要求に係るサービスの画面の表示用データ（Ｗｅｂページ）を作成し、作成した画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する（ステップＳ７）。この際、顧客端末７０等へ送信される画面の表示用データ（Ｗｅｂページ）には、その次の画面に遷移するための情報として、その次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤ（ａｉｄ）が含まれている。

なお、以上のステップＳ３〜Ｓ７の処理は、各サービスの提供を受けるための顧客端末７０等からの画面表示要求がある都度に繰り返される。

また、第１実施形態においては、以下のようにして構築支援システム６０により、サイト提供システム１０の構築支援に関する各種処理が実行される。

図４において、先ず、画面定義ファイル読込手段６１により、完成している既存の種別の画面についての画面定義ファイル（例えばＰＣ画面用の画面定義ファイル）および開発中の種別の画面についての画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む（ステップＳ１１）。この際、通常は、開発環境下の画面定義ファイル記憶手段３１から読み込むが、本番環境下の画面定義ファイル記憶手段３１から読み込んでもよく、あるいは画面定義ファイル記憶手段３１以外の保存場所（例えば、開発者のコンピュータ等）から読み込んでもよい。

次に、画面ファイル読込手段６２により、読み込んだ各画面定義ファイルから、同一のアプリケーションＩＤ（ａｉｄ）に関連付けられ、かつ、同一の状態（ｃｏｄｅ）で使用される既存の種別の画面（例えば、ＰＣ画面）および開発中の種別の画面（例えば、ＲＷＤ画面）についての画面ファイル（ＪＳＰ）のパスを取得する（ステップＳ１２）。通常、各画面定義ファイルには、多くのパスが定義されているので、対になるパスを全て取得する。なお、開発漏れ等があれば、対になるべきパスの一方が存在しない場合もあるが、その場合も、以下では、説明の便宜上、対になるパスと呼ぶものとする。

続いて、画面ファイル読込手段６２により、取得したパスを用いて、画面ファイル記憶手段３２から、既存の種別の画面（例えば、ＰＣ画面）および開発中の種別の画面（例えば、ＲＷＤ画面）についての各画面ファイル（ＪＳＰ）を読み込む（ステップＳ１３）。この際、通常は、開発環境下の画面ファイル記憶手段３２から読み込むが、本番環境下の画面ファイル記憶手段３２から読み込んでもよい。

なお、サイトの規模（画面ファイルの個数）にもよるが、通常は、ステップＳ１２において、各画面定義ファイルから、多くの対になるパスが取得されることになる。この際、ステップＳ１３以降の処理（画面ファイルの読込、動的部分の抽出、結果の出力）を行うにあたり、対になるパスを１対ずつ処理していってもよく（対の数だけ画面ファイルの読込、動的部分の抽出、結果の出力という順序の処理を繰り返す。）、幾つかの対になるパス（複数対のパス）をまとめて処理してもよく（まとめられた集合の数だけ画面ファイルの読込、動的部分の抽出、結果の出力という順序の処理を繰り返す。）、対になるパスの全てをまとめて処理してもよい。

それから、抽出手段６３により、読み込んだ各画面ファイル（ＪＳＰ）から、画面の動的部分を記述したコードを抽出する（ステップＳ１４）。より具体的には、データベース５２から取得されたデータ（例えば残高等）の表示部分等のように、変数（パラメータ）になっている部分のコード（例えば“ＺＡＮＤＡＫＡ”等）を抽出する。

そして、対比結果出力手段６４により、抽出した既存の種別の画面（例えば、ＰＣ画面）および開発中の種別の画面（例えば、ＲＷＤ画面）の動的部分を記述したコードを対比した結果を出力（画面表示や印刷）する（ステップＳ１５）。

対比結果の出力の態様は任意であり、例えば、次のような出力の態様がある。なお、出力の態様を使用者（システム開発者）が選択できるようにしてもよい。

第１の出力の態様では、抽出した動的部分を記述したコードを、そのままコードの状態で、図４に示すように、左右に並べる等して対比して出力する。同一のアプリケーションＩＤ（ａｉｄ）および同一の状態（ｃｏｄｅ）に関連付けられたパスを用いて、対応する各画面ファイル（ＪＳＰ）を読み込んでいるので、図４の例では、アプリケーションＩＤ（ａｉｄ）および状態（ｃｏｄｅ）を表示した後に、対応する各画面ファイル（ＪＳＰ）からそれぞれ抽出した画面の動的部分を記述したコードを、左右に並べて配置し、出力（画面表示や印刷）している。従って、開発中の種別の画面（例えば、ＲＷＤ画面）について、開発漏れがあれば、開発中の種別の画面側が空欄になるか、対応するコードが存在しない旨を示す文字や記号等が出力される。一方、開発中の種別の画面（例えば、ＲＷＤ画面）について、余分な動的部分が含まれていれば、既存の種別の画面（例えば、ＰＣ画面）側が空欄になるか、対応するコードが存在しない旨を示す文字や記号等が出力される。

第２の出力の態様では、双方の画面の動的部分を記述したコードについて、差異若しくは過不足がある場合に、その差異若しくは過不足があるところだけを、左右に並べる等して対比して出力する。従って、第１の出力の態様では、差異や過不足がなくても、対応する動的部分のコードを出力するが、第２の出力の態様では、差異若しくは過不足がある場合にのみ、対応する動的部分のコードを出力する。この際、対応するコードが無い場合は、空欄にするか、対応するコードが存在しない旨を示す文字や記号等を出力するのは、第１の出力の態様と同様である。

第３の出力の態様では、抽出した動的部分を記述したコードそのものを出力するのではなく、抽出数を対比して出力する。例えば、既存の種別の画面（例えば、ＰＣ画面）には、動的部分が１００箇所あり、開発中の種別の画面（例えば、ＲＷＤ画面）には、動的部分が９８箇所ある等の数値情報を出力する。この際、細かい単位（例えばサービスの細目）で区切って抽出数の対比出力を行ってもよく、全サービスをトータルして抽出数の対比出力を行ってもよい。なお、抽出数の対比出力だけでは、前者のように細かい単位で区切って抽出数の対比出力を行わないと、どこに過不足があるのかを直ぐに特定することは困難であるが、画面開発の全体的な進捗を確認することは容易になる。例えば、画面開発をほぼ終えた段階では、双方の抽出数は、ほぼ同数になるが、既存の種別の画面（例えば、ＰＣ画面）には、動的部分が１００箇所あり、開発中の種別の画面（例えば、ＲＷＤ画面）には、動的部分が６０箇所ある等と出力されれば、６割程度の進捗であることがわかる。

このような第１実施形態によれば、次のような効果がある。すなわち、サイト提供システム１０では、各サービスの提供に必要な画面についての画面ファイルのパスが画面定義ファイルに記述され、この画面定義ファイルからの画面ファイルのパスの取得が、業務共通処理手段２２によるフレームワークの処理として行われる。従って、既存サイトを継続して提供することを前提として、別のデバイス向けに新サイトを提供する際には、別のデバイス用の画面定義ファイルおよび画面ファイルを新たに作成して用意する必要があるが、処理の内容としては、業務処理手段２３により実行される各サービスの個々の業務処理については変更する必要がなく、業務共通処理手段２２によるフレームワークの処理に、増やす画面判定区分（追加する別のデバイス用の画面の種別を示す画面判定区分）に対応する別のデバイス用の画面定義ファイルを読み込む分岐を増やす変更を行えばよい。

例えば、ＰＣ画面による既存サイトが稼働しているときに、これと並行稼働するＲＷＤ画面による新サイトを提供する場合には、ログイン手段２１による画面の種別の判定処理において、ＲＷＤ画面を示す画面判定区分についての分岐を増やし、ＲＷＤログイン画面、ＲＷＤトップ画面、およびその他のＲＷＤ画面についての画面ファイルを新たに作成するとともに、ＲＷＤ画面用の画面定義ファイルを新たに作成する。そして、業務共通処理手段２２を構成するフレームワーク（ｊａｖａ（登録商標）の場合には、親クラス）に、セッション情報記憶手段４２に記憶された画面判定区分がＲＷＤ画面を示す画面判定区分（例えば、画面判定区分＝１）だった場合に読み込むべきＲＷＤ画面用の画面定義ファイルの識別情報（名称）についての記述を追加する。一方、業務処理手段２３を構成する各サービスの個々の業務処理アプリケーション（ｊａｖａ（登録商標）の場合には、子クラス）には変更を加える必要はない。また、画面表示共通処理手段２４を構成するフレームワーク（ｊａｖａ（登録商標）の場合には、親クラス）および画面表示処理手段２５を構成する画面表示アプリケーション（ｊａｖａ（登録商標）の場合には、子クラス）にも変更を加える必要はない。従って、サイトを追加する際の修正範囲は、複数種類のサービスの全てで共通利用されるフレームワークに限定される。

このため、開発範囲の狭小化を図ることができ、開発作業を容易化することができるので、開発期間の短縮、開発コストの低減を実現することができる。

また、サイトを追加する際に、フレームワークの処理以外の個々の処理を実行するサーバアプリケーション、すなわち業務処理手段２３を構成する業務処理アプリおよび画面表示処理手段２５を構成する画面表示アプリを修正せずに対応することができるので、サーバアプリの開発において、新たなバグが埋め込まれてしまう可能性を少なくすることができ、ビジネスリスクを減少させることができる。

さらに、サイトの追加が容易になるので、既存の画面（例えばＰＣ画面）によるサイトと、別の画面（例えばＲＷＤ画面）によるサイトとの並行稼働を容易に実現することができるため、別のデバイス向けの画面（例えばスマートフォンやタブレットにも対応可能なＲＷＤ画面）によるサイトの設置が必要になり、あるいは別のデバイスが主流になった場合でも、サービス提供の場を新設のサイト（例えばＲＷＤサイト）に完全に置き換えてしまうのではなく、既存サイト（例えばＰＣサイト）の利用者へのサービス提供を継続することができる。このため、例えば、顧客端末７０が、ＲＷＤ画面に対応できない古いバージョンのＷｅｂブラウザを搭載しているＰＣである場合等にも対応することができる。

また、複数のサイトの並行稼働を容易に実現することができるため、システム障害発生時の代替手段を確保することもできる。

そして、今後、未だ世の中に存在しないか、普及していない新しいタイプのデバイス（例えばウェアラブル端末、音声認識端末、立体画像端末等）が開発され、その新しいタイプのデバイス向けの画面によるサイトを提供する必要性が生じた場合でも、現存しているか、現在普及している別のデバイス向けの画面によるサイトを追加する場合と同様に、開発の対応範囲が限定的なものとなるので、その新しいタイプのデバイス向けの画面によるサイトを容易に追加することができる。例えば、ＰＣの顧客端末７０を操作する顧客、およびスマートフォン／タブレットの顧客端末８０を操作する顧客の双方へのサービス提供を実現するために、ＰＣ画面によるサイトと、ＲＷＤ画面によるサイトとを並行稼働させているときに、さらにウェアラブル端末等の新機種の顧客端末９０を操作する顧客へのサービス提供を開始することになった場合でも、その新機種向けの画面によるサイトを容易に追加することができる。

また、追加するサイトで使用される画面（例えばＲＷＤ画面）の開発は、既存の画面（例えばＰＣ画面）の情報を利用して行うことができるので、画面開発においてバグが埋め込まれてしまう可能性も極力排除することができる。

さらに、異なるデバイス向けの複数のサイト（例えば、ＰＣサイトおよびＲＷＤサイト）を同時期に新設する場合にも、各デバイス用の画面定義ファイルおよび画面ファイルをそれぞれ新たに作成して用意する必要はあるが、処理の内容としては、業務処理手段２３により実行される各サービスの個々の業務処理において各サイトへの分岐処理を設ける必要はなく、業務共通処理手段２２によるフレームワークの処理に、各デバイス用の画面の種別を示す画面判定区分に対応する各デバイス用の画面定義ファイル（例えば、ＰＣ画面用の画面定義ファイルおよびＲＷＤ画面用の画面定義ファイル）を読み込む分岐処理を設ければよい。このため、複数のサイト（例えば、ＰＣサイトおよびＲＷＤサイト）を同時期に構築することも容易に行うことができる。

そして、以上のように、サイト提供システム１０は、サイトの追加を容易に行うことができる構成とされているので、並行稼働している複数のサイトのうち、一部のサイトを閉鎖することも容易に行うことができる。すなわち、画面の種別の判定処理における分岐や、画面判定区分に対応する画面定義ファイルの読込処理における分岐を減らすだけでよい。なお、余分な分岐が存在しても処理に悪影響が出ない場合には、その分岐を削除しなくてもよい。

また、構築支援システム６０では、既存の種別の画面（例えばＰＣ画面）および開発中の種別の画面（例えばＲＷＤ画面）の動的部分を記述したコードを対比して確認することができるので、画面開発においてバグが埋め込まれてしまう可能性を低減することができる。すなわち、サーバアプリケーションを共通利用して新規画面のサイトを提供する場合には、バグが生じる可能性が高いのは、画面の動的項目の部分であるので、デザイン上の制約がない状態で新規画面（例えばＲＷＤ画面）を開発し、その後、既存の種別の画面（例えばＰＣ画面）についての画面ファイルと、開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルとを読み込み、それらから抽出した動的部分を記述したコードを対比して出力し、あるいは差異や過不足、抽出数を出力することで、バグの埋め込みを回避することができる。

また、既存の種別の画面（例えばＰＣ画面）および開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルを読み込む際には、画面定義ファイルに記述されている画面ファイルのパスを取得し、取得したパスを用いて読込処理を行うので、対応する多くの画面ファイルの対比チェックを容易に、かつ短時間で行うことができるため、画面開発の開発効率の向上を図ることができる。そして、画面開発の進捗管理も容易に行うことができる。

さらに、対応する画面ファイルを１対ずつ順番に読み込んで対比して確認する作業を繰り返す場合には、確認作業者が、確認対象の各画面ファイルのパスを把握していて、それを読込対象として毎回入力することになるので、手間がかかるうえ、対応する画面ファイルのパスが、確認作業者にとって記憶しやすく、把握しやすいものになっている必要がある。これに対し、構築支援システム６０では、画面定義ファイルに記述されている画面ファイルのパスを利用して自動的に読込処理を行うので、画面ファイルのパスが確認作業者にとって記憶しにくく、把握しにくいものになっていたとしても、容易に画面ファイルの読込処理を行うことができる。

［第２実施形態］

図５には、本発明の第２実施形態のサイト提供システム２００およびその構築支援システム２６０の全体構成が示されている。図６および図７には、サイト提供システム２００によるサービス提供に関する処理の流れがフローチャートで示されている。図８には、構築支援システム２６０によるサイト構築支援に関する処理の流れがフローチャートで示されている。

第２実施形態のサイト提供システム２００は、従来方式（［発明が解決しようとする課題］で述べた第１、第２の従来方式のいずれでもよい。）で複数のサイトの並行稼働を実現している場合において、さらに別のサイトを追加するときに採用される構成を備え、前記第１実施形態のサイト提供システム１０と同様な構成を有する部分も多いので、同様な構成を有する部分については同一の符号を付して詳しい説明を省略し、以下では、異なる構成を有する部分を中心に説明する。

図５において、サイト提供システム２００は、ネットワーク１を介して接続される様々なデバイスの顧客端末７０，７１，８０，９０等に対し、各種のサービス業務を行うウェブサイトを提供するシステムである。

サイト提供システム２００は、１台または複数台のコンピュータにより構成され、本実施形態では、一例として、ウェブサーバおよびアプリケーションサーバの機能を有するＷＥＢ／ＡＰサーバ２２０と、セッション管理サーバ４０と、データベースサーバ５０とを備えて構成されている。なお、サイト提供システム２００を構成するサーバ（コンピュータ）の台数は任意であり、例えば、ウェブサーバとアプリケーションサーバとを異なるコンピュータで構成してもよく、逆に、セッション管理サーバ４０やデータベースサーバ５０を、ＷＥＢ／ＡＰサーバ２２０と同じコンピュータにより構成してもよい。

ＷＥＢ／ＡＰサーバ２２０は、１台または複数台のコンピュータにより構成され、ログイン処理手段２２１と、業務共通処理手段２２２と、業務処理手段２２３と、画面表示共通処理手段２２４と、画面表示処理手段２２５と、顧客情報記憶手段２３０と、画面定義ファイル記憶手段２３１と、画面ファイル記憶手段２３２とを含んで構成されている。

ログイン処理手段２２１は、前記第１実施形態のログイン処理手段２１と略同様な構成を備え、顧客端末７０等からの要求に応じてログイン画面を送信し、顧客端末７０等からネットワーク１を介して送信されてくる顧客のログイン情報（画面の種別を示す情報を含む。）を受信し、受信したログイン情報を用いて顧客端末７０等の画面の種別を判定し、判定した画面の種別を示す画面判定区分を、セッションＩＤと関連付けてセッション管理サーバ４０のセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶させる処理を実行するものである。

前記第１実施形態のログイン処理手段２１では、例えば、ＰＣの顧客端末７０に表示されたＰＣログイン画面からのログインがあった場合には、画面判定区分＝０をセッション管理サーバ４０のセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶させ、スマートフォン／タブレットの顧客端末８０に表示されたＲＷＤログイン画面からのログインがあった場合には、画面判定区分＝１を記憶させ、新デバイスの顧客端末９０に表示された新機種ログイン画面からのログインがあった場合には、画面判定区分＝２を記憶させる等のように、画面の種別が異なれば、それぞれに異なる画面判定区分を割り当てていたのに対し、本第２実施形態のログイン処理手段２２１では、従来方式で並行稼働している複数のサイトの構成画面の種別（本願明細書では、特定種別と呼んでいる。）については、同じ画面判定区分を割り当てる点が異なっている。例えば、本第２実施形態のログイン処理手段２２１は、ＰＣ画面によるサイトと携帯画面によるサイトとが従来方式で並行稼働していたとすると、ＰＣの顧客端末７０に表示されたＰＣログイン画面からのログインがあった場合には、画面判定区分＝０をセッション管理サーバ４０のセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶させ、携帯電話機の顧客端末７１に表示された携帯ログイン画面からのログインがあった場合にも、同じく画面判定区分＝０を記憶させる等、特定種別の画面については、同じ画面判定区分を割り当てる。しかし、スマートフォン／タブレットの顧客端末８０に表示されたＲＷＤログイン画面からのログインがあった場合には、画面判定区分＝１を記憶させ、新デバイスの顧客端末９０に表示された新機種ログイン画面からのログインがあった場合には、画面判定区分＝２を記憶させる等、特定種別以外の種別の画面については、それぞれ異なる画面判定区分を割り当てる。

業務共通処理手段２２２は、前記第１実施形態の業務共通処理手段２２と異なる構成を備え、顧客端末７０等からネットワーク１を介して送信されてくる画面表示要求信号（次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤを含む。）を受信する処理を、複数種類のサービスの全ての業務処理に共通するフレームワークの処理として実行するものである。この業務共通処理手段２２２は、従来方式で複数のサイトの並行稼働を実現している場合の構成と同じである。

前記第１実施形態の業務共通処理手段２２では、顧客端末７０等から受信した画面表示要求信号に含まれるセッションＩＤに関連付けられてセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶された画面判定区分を、セッション管理サーバ４０から取得し、取得した画面判定区分に対応する画面定義ファイルを、画面定義ファイル記憶手段３１から読み込む処理を行っていたのに対し、本第２実施形態の業務共通処理手段２２２では、セッション管理サーバ４０からの画面判定区分の取得処理や、画面定義ファイル記憶手段２３１からの画面定義ファイルの読込処理は行わない点が異なる。なお、本第２実施形態のサイト提供システム２００では、セッション管理サーバ４０からの画面判定区分の取得処理や、画面定義ファイル記憶手段２３１からの画面定義ファイルの読込処理は、画面表示共通処理手段２２４により行われる。

また、業務共通処理手段２２２は、下記の業務処理手段２２３でデータベースサーバ５０のデータベース５２から取得したデータを、セッションＩＤとともに、画面表示共通処理手段２２４に渡す処理を実行する。なお、これらのデータやセッションＩＤを、業務に関する処理から画面表示に関する処理へと伝達するのは、業務共通処理手段２２２によりフレームワークの処理として行うのではなく、業務処理手段２２３により各サービスの個別の処理として行うようにしてもよい。従って、例えば、業務処理手段２２３を構成する業務処理アプリにより、画面表示処理手段２２５を構成する画面表示アプリを呼び出すとともに、これらのデータやセッションＩＤを画面表示アプリに渡すようにしてもよい。

業務処理手段２２３は、業務共通処理手段２２２により顧客端末７０等から受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）の業務処理アプリケーションにより、要求に係るサービスの業務処理を実行するものである。この業務処理手段２２３は、要求に係るサービスの業務処理として、そのサービスの提供に必要なデータを、データベースサーバ５０のデータベース５２から取得する処理を実行する。従って、業務共通処理手段２２２が複数種類のサービスの全てに共通する処理を実行するのに対し、この業務処理手段２２３は、個々のサービスの処理を実行するものであり、サービス毎に設けられている。この点では、業務処理手段２２３は、前記第１実施形態の業務処理手段２３と同様な構成を備えている。

また、業務処理手段２２３は、画面表示処理手段２２５を構成する画面表示アプリの識別情報（名称：ｃｌａｓｓ）を指定する処理も実行する。この点で、業務処理手段２２３は、前記第１実施形態の業務処理手段２３とは異なる構成を有している。従って、業務処理手段２２３を構成する業務処理アプリには、画面表示処理手段２２５を構成する画面表示アプリの識別情報（名称）が記述され、これにより業務処理アプリが、対応する画面表示アプリを呼び出すようになっている。例えば、ｊａｖａ（登録商標）の場合には、業務共通処理を継承した業務処理が、画面表示共通処理を継承した画面表示処理を呼び出すという形になる。そして、業務処理アプリには、正常時および異常時（タイム・エラーやシステム・エラー等）のそれぞれで使用される画面表示アプリの識別情報（名称）が記述され、正常時には、正常時用に指定された画面表示アプリが呼び出され、異常時には、異常時用に指定された画面表示アプリが呼び出されるようになっている。

さらに、［発明が解決しようとする課題］で述べた第１の従来方式により複数のサイトを並行稼働させていた場合には、業務処理手段２２３が業務共通処理手段２２２から受け取るアプリケーションＩＤ（ａｉｄ）は、画面の種別毎のアプリケーションＩＤとなっており、例えば、ＰＣ画面用のアプリケーションＩＤにより特定されたＰＣ画面用の業務処理アプリに、ＰＣ画面用の画面表示アプリの識別情報（名称）が記述されていて、これによりＰＣ画面用の業務処理アプリが、ＰＣ画面用の画面表示アプリを呼び出し、また、携帯画面用のアプリケーションＩＤにより特定された携帯画面用の業務処理アプリには、携帯画面用の画面表示アプリの識別情報（名称）が記述されていて、これにより携帯画面用の業務処理アプリが、携帯画面用の画面表示アプリを呼び出すようになっている。但し、特定種別以外の種別の画面（例えばＲＷＤ画面）用の業務処理アプリや画面表示アプリは用意されていないので、特定種別以外の種別の画面（例えばＲＷＤ画面）からのアクセスがあった場合（この場合、例えば、スマートフォン／タブレットの顧客端末８０からの画面表示要求信号に含まれているアプリケーションＩＤは、ＲＷＤ画面用のアプリケーションＩＤではなく、ＰＣ画面用または携帯画面用のアプリケーションＩＤになっている。）には、特定種別のうちのいずれかの種別の画面（例えばＰＣ画面または携帯画面）用の業務処理アプリや画面表示アプリで代用することになる。このような代用が行われた場合には、特定種別以外の種別の画面（例えばＲＷＤ画面）用の画面定義ファイルを用いて、特定種別の画面（例えばＰＣ画面または携帯画面）用の画面ファイルのパスから特定種別以外の種別の画面（例えばＲＷＤ画面）用の画面ファイルのパスへの変換が行われ、特定種別以外の種別の画面（例えばＲＷＤ画面）用の画面ファイルの取得処理が行われることになる。

一方、［発明が解決しようとする課題］で述べた第２の従来方式により複数のサイトを並行稼働させていた場合には、業務処理手段２２３が業務共通処理手段２２２から受け取るアプリケーションＩＤ（ａｉｄ）は、複数の画面の種別に共通のアプリケーションＩＤとなっており、例えば、その共通のアプリケーションＩＤにより特定されたＰＣ画面および携帯画面に共有の業務処理アプリに、ＰＣ画面および携帯画面に共有の画面表示アプリの識別情報（名称）が記述されていて、これによりＰＣ画面および携帯画面に共有の業務処理アプリが、ＰＣ画面および携帯画面に共有の画面表示アプリを呼び出すか、あるいは、その共通のアプリケーションＩＤにより特定されたＰＣ画面および携帯画面に共有の業務処理アプリに、ＰＣ画面用および携帯画面用のそれぞれの画面表示アプリの識別情報（名称）が記述されていて、これによりＰＣ画面および携帯画面に共有の業務処理アプリが、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、ＰＣ画面用の画面表示アプリまたは携帯画面用の画面表示アプリを選択して呼び出すようになっている。なお、特定種別以外の種別の画面（例えばＲＷＤ画面）からのアクセスがあった場合に、特定種別のうちのいずれかの種別の画面（例えばＰＣ画面または携帯画面）用の業務処理アプリや画面表示アプリで代用するのは、上述した第１の従来方式により複数のサイトを並行稼働させていた場合と同様である。

画面表示共通処理手段２２４は、前記第１実施形態の画面表示共通処理手段２４とは異なる構成を有し、業務共通処理手段２２２から受け取ったセッションＩＤ（業務共通処理手段２２２により受信した画面表示要求信号に含まれるセッションＩＤ）に関連付けられてセッション情報記憶手段４２（画面判定区分記憶手段を含む。）に記憶された画面判定区分をセッション管理サーバ４０から取得し、取得した画面判定区分が特定種別（従来方式で並行稼働していた各サイトの構成画面の種別のうちのいずれかの種別）である場合には、下記の画面表示処理手段２２５により指定された特定種別の画面についての画面ファイル（ＪＳＰ）のパスをそのまま用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段２３２から読み込み、一方、取得した画面判定区分が特定種別以外の種別である場合には、取得した画面判定区分に対応する画面定義ファイルを画面定義ファイル記憶手段２３１から読み込むことにより、下記の画面表示処理手段２２５により指定された特定種別の画面についての画面ファイル（ＪＳＰ）のパスを、特定種別以外の種別の画面についての画面ファイル（ＪＳＰ）のパスに変換し、この変換後のパスを用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段２３２から読み込み、読み込んだ画面ファイル（ＪＳＰ）を用いて、要求に係るサービスの画面の表示用データ（Ｗｅｂページ）を作成し、作成した画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する処理を、複数種類のサービスの全ての画面表示処理に共通するフレームワークの処理として実行するものである。

画面表示処理手段２２５は、前記第１実施形態の画面表示処理手段２５とは異なる構成を有し、業務処理手段２２３を構成する業務処理アプリにより呼び出された画面表示アプリにより、特定種別（従来方式で並行稼働していた各サイトの構成画面の種別のうちのいずれかの種別）の画面についての画面ファイル（ＪＳＰ）のパスを指定するとともに、業務共通処理手段２２２から受け取ったデータ（業務処理手段２２３による業務処理でデータベースサーバ５０のデータベース５２から取得したデータ）を用いて、画面表示共通処理手段２２４により読み込んだ画面ファイル（ＪＳＰ）で作成される画面のうち、要求に係るサービスのデータを用いて表示される動的部分を作成する処理を実行するものである。従って、画面表示共通処理手段２２４が複数種類のサービスの全てに共通する処理を実行するのに対し、この画面表示処理手段２２５は、個々のサービスの処理を実行するものであり、サービス毎に設けられている。

また、［発明が解決しようとする課題］で述べた第１の従来方式により複数のサイトを並行稼働させていた場合には、画面の種別毎に業務処理アプリおよび画面表示アプリが存在するので、例えば、ＰＣ画面用の業務処理アプリに呼び出されたＰＣ画面用の画面表示アプリに、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスが記述され、また、携帯画面用の業務処理アプリに呼び出された携帯画面用の画面表示アプリに、携帯画面用の画面ファイル（ＪＳＰ）のパスが記述されている。

一方、［発明が解決しようとする課題］で述べた第２の従来方式により複数のサイトを並行稼働させていた場合には、複数の画面の種別に共有の業務処理アプリとなるので、例えば、ＰＣ画面および携帯画面に共有の業務処理アプリにより呼び出されたＰＣ画面および携帯画面に共有の画面表示アプリに、ＰＣ画面用および携帯画面用の画面ファイル（ＪＳＰ）のパスが記述され、ＰＣ画面および携帯画面に共有の画面表示アプリが、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスまたは携帯画面用の画面ファイル（ＪＳＰ）のパスを選択して指定するようになっているか、あるいは、ＰＣ画面および携帯画面に共有の業務処理アプリにより、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、選択的に呼び出されたＰＣ画面用の画面表示アプリに、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスが記述され、また、選択的に呼び出された携帯画面用の画面表示アプリに、携帯画面用の画面ファイル（ＪＳＰ）のパスが記述されている。

顧客情報記憶手段２３０は、前記第１実施形態の顧客情報記憶手段３０と同じものである。

画面定義ファイル記憶手段２３１は、前記第１実施形態の画面定義ファイル記憶手段３１とは異なり、特定種別（従来方式で並行稼働していた各サイトの構成画面の種別）以外の種別の画面について割り当てられた画面判定区分に対応して用意されている画面定義ファイルを記憶するものである。例えば、ＰＣ画面および携帯画面が特定種別の画面であるとすれば、これらのＰＣ画面用の画面定義ファイルや携帯画面用の画面定義ファイルは存在しない。すなわち、ＰＣ画面や携帯画面を示す画面判定区分＝０に対応する画面定義ファイルは存在しない。従って、スマートフォンやタブレット向けのＲＷＤ画面によるサイトや、その他の新しいタイプのデバイス向けの新機種画面によるサイト等を追加する場合に、それらの画面用の画面定義ファイルが作成され、例えば、ＲＷＤ画面を示す画面判定区分＝１に対応する画面定義ファイル等が用意されることになる。この点で、全ての種別の画面用の画面定義ファイルが記憶されている前記第１実施形態の画面定義ファイル記憶手段３１とは異なる。

また、画面定義ファイル記憶手段２３１に記憶される画面定義ファイルの内容も前記第１実施形態の場合とは異なっている。本第２実施形態では、画面定義ファイルには、特定種別の画面についての画面ファイル（ＪＳＰ）のパスと、特定種別以外の種別の画面についての画面ファイル（ＪＳＰ）のパスとが関連付けられて記憶されている。

例えば、ＰＣ画面および携帯画面が特定種別の画面であり（すなわち、既設サイトは、ＰＣサイトおよび携帯サイトである。）、ＲＷＤ画面によるサイトが追加されたサイトであるとすれば、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスと、ＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスとが関連付けられた画面定義ファイルを用意するか、あるいは、携帯画面用の画面ファイル（ＪＳＰ）のパスと、ＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスとが関連付けられた画面定義ファイルを用意する。また、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスと、ＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスとの関連付け、および、携帯画面用の画面ファイル（ＪＳＰ）のパスと、ＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスとの関連付けの双方が定義された画面定義ファイルを用意してもよい。

画面ファイル記憶手段２３２は、前記第１実施形態の画面ファイル記憶手段３２と同様な構成を備え、ＰＣ画面、携帯画面、ＲＷＤ画面、その他のデバイス向けの画面のそれぞれについての画面ファイル（ＪＳＰ）を記憶するものである。なお、ＰＣ画面用の画面ファイル（ＪＳＰ）と、携帯画面用の画面ファイル（ＪＳＰ）と、ＲＷＤ画面用の画面ファイル（ＪＳＰ）と、その他のデバイス向けの画面用の画面ファイル（ＪＳＰ）とは、別のフォルダに格納され、異なるパスを指定して取得できるようになっている。

また、画面ファイル記憶手段２３２には、ＰＣ画面、携帯画面、ＲＷＤ画面、その他のデバイス向けの画面のそれぞれについてのログイン画面およびトップ画面のファイルも記憶され、この点も、前記第１実施形態の画面ファイル記憶手段３２と同様である。

セッション管理サーバ４０は、前記第１実施形態の場合と同じものである。前記第１実施形態では、セッション管理手段４１は、ＷＥＢ／ＡＰサーバ２０の業務共通処理手段２２からの画面判定区分の問い合わせ信号（セッションＩＤを伴う。）に返答していたのに対し、本第２実施形態では、ＷＥＢ／ＡＰサーバ２２０の画面表示共通処理手段２２４からの画面判定区分の問い合わせ信号（セッションＩＤを伴う。）に返答する点は異なるが、システム構成自体は同じである。

データベースサーバ５０は、前記第１実施形態の場合と同じものである。

構築支援システム２６０は、１台または複数台のコンピュータにより構成され、画面定義ファイル読込手段２６１と、画面ファイル読込手段２６２と、抽出手段２６３と、対比結果出力手段２６４とを含んで構成されている。

画面定義ファイル読込手段２６１は、開発中の種別の画面についての画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む処理を実行するものである。通常は、開発環境下の画面定義ファイル記憶手段２３１から読み込むが、本番環境下の画面定義ファイル記憶手段２３１から読み込んでもよく、あるいは画面定義ファイル記憶手段２３１とは別の格納場所や、サイト提供システム２００を構成するコンピュータとは別のコンピュータのハードディスクやＵＳＢメモリ等の記録媒体から読み込んでもよい。

前記第１実施形態の画面定義ファイル読込手段６１は、対比する画面の双方についての画面定義ファイル、すなわち、完成している既存の種別の画面についての画面定義ファイル（例えばＰＣ画面用の画面定義ファイル）、および開発中の種別の画面についての画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む構成とされていたが、本第２実施形態の画面定義ファイルには、パスの変換情報が定義されているので、その変換情報から、対比する画面の双方についての情報が得られるため、本第２実施形態の画面定義ファイル読込手段２６１は、対応する画面定義ファイルの双方を読み込む構成にはなっていない点が異なっている。

画面ファイル読込手段２６２は、画面定義ファイル読込手段２６１により読み込んだ画面定義ファイルから、対応付けられている特定種別の画面（例えばＰＣ画面または携帯画面）についての画面ファイルのパス、および開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルのパスを取得し、取得したパスを用いて、画面ファイル記憶手段２３２から、特定種別および開発中の種別の画面についての各画面ファイル（ＪＳＰ）を読み込む処理を実行するものである。通常は、開発環境下の画面ファイル記憶手段２３２から読み込むが、本番環境下の画面ファイル記憶手段２３２から読み込んでもよい。

抽出手段２６３は、前記第１実施形態の抽出手段６３と同様な構成を備え、画面ファイル読込手段２６２により読み込んだ各画面ファイル（ＪＳＰ）から、画面の動的部分を記述したコードを抽出する処理を実行するものである。

対比結果出力手段２６４は、抽出手段２６３により抽出した特定種別の画面（例えばＰＣ画面または携帯画面）および開発中の種別の画面（例えばＲＷＤ画面）の動的部分を記述したコードを対比して画面表示および／または印刷する処理、動的部分を記述したコードの差異若しくは過不足を画面表示および／または印刷する処理、動的部分を記述したコードの抽出数を対比して画面表示および／または印刷する処理のうちの少なくとも１つの処理を実行するものである。

顧客端末７０、顧客端末８０、および顧客端末９０は、前記第１実施形態の場合と同じものである。顧客端末７１は、携帯電話機（スマートフォンのような多機能携帯電話機を除く従来型の携帯電話機である。）により構成され、キー入力やボタン操作を行う入力手段と、液晶ディスプレイ等の表示手段とを備えている。

このような第２実施形態においては、以下のようにしてサイト提供システム２００により、顧客へのサービス提供に関する各種処理が実行される。

図６において、先ず、ＷＥＢ／ＡＰサーバ２２０で、ログイン処理手段２２１により、前記第１実施形態の場合と同様にして、顧客端末７０等からの顧客によるログイン画面の表示要求に応じ、画面ファイル記憶手段２３２に記憶されているＰＣログイン画面、携帯ログイン画面、ＲＷＤログイン画面、その他のデバイス向けのログイン画面のうち、表示要求に係るログイン画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する（ステップＳ２０１）。

続いて、ログイン処理手段２２１により、前記第１実施形態の場合と同様にして、顧客端末７０等からネットワーク１を介して送信されてくるログイン情報（顧客識別情報、ログインパスワードに加え、画面の種別を示す情報を含む。）を受信し、顧客のログイン認証処理を実行する（ステップＳ２０１）。

さらに、アクセスした顧客が認証された場合には、ログイン処理手段２２１により、前記第１実施形態の場合と同様にして、受信したログイン情報に含まれる画面の種別を示す情報を用いて要求元の顧客端末７０等の画面の種別を判定し、画面判定区分を決定する（ステップＳ２０１）。この際、前記第１実施形態の場合と異なるのは、画面の種別を示す情報が、特定種別（従来方式で並行稼働していた各サイトの構成画面の種別）であるＰＣ画面を示す情報（例えばｒｏｏｔ＝ｐｃ）または携帯画面を示す情報（例えばｒｏｏｔ＝ｍｏ）である場合には、これらを区別することなく、いずれも画面判定区分＝０とする点である。そして、画面の種別を示す情報が、ＲＷＤ画面を示す情報（例えばｒｏｏｔ＝ｒｗｄ）である場合には、画面判定区分＝１とする。なお、２つの特定種別に対し、互いに異なる画面判定区分を割り当てても、本発明を適用することは可能であり、要するに、特定種別と特定種別以外の種別とを区別することができ、さらに、特定種別以外の種別が複数種別ある場合には、それらの区別も付くようになっていればよい。また、特定種別である複数の種別（例えば、ＰＣ画面と携帯画面）を区別する必要がないのは、元々、本発明を適用せずに、すなわち本発明における画面判定区分を設けることなく、従来方式で並行稼働を実現していた状態が存在し、その状態を利用する形で本発明のサイト提供システム２００を構築したからである。

そして、ログイン処理手段２２１により、前記第１実施形態の場合と同様にして、得られた画面判定区分を、認証された顧客についての顧客名や口座情報等（顧客情報記憶手段２３０に記憶されているデータ）とともに、セッション管理サーバ４０へ渡し、これらの顧客名や口座情報等、および画面判定区分を、セッションＩＤと関連付けてセッション情報記憶手段４２に記憶させる（ステップＳ２０１）。

次に、ログイン処理手段２２１により、前記第１実施形態の場合と同様にして、要求元の顧客端末７０等の画面の種別に応じたトップ画面のファイルを、画面ファイル記憶手段２３２から取得し、トップ画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する（ステップＳ２０２）。

図７において、業務共通処理手段２２２により、顧客端末７０等からネットワーク１を介して送信されてくる画面表示要求信号（次の画面のＵＲＬ、セッションＩＤおよびアプリケーションＩＤを含む。）を受信する（ステップＳ２０３）。

続いて、業務処理手段２２３により、業務共通処理手段２２２により顧客端末７０等から受信した画面表示要求信号に含まれるアプリケーションＩＤ（ａｉｄ）の業務処理アプリケーションにより、要求に係るサービスの業務処理を実行する。なわち、業務処理手段２２３により、要求に係るサービスの提供に必要なデータを、データベースサーバ５０のデータベース５２から取得する（ステップＳ２０４）。

また、業務処理手段２２３により、画面表示処理手段２２５を構成する画面表示アプリの識別情報（名称：ｃｌａｓｓ）を指定する。すなわち、業務処理手段２２３を構成する業務処理アプリにより、この業務処理アプリに記述された名称（ｃｌａｓｓ：画面表示アプリの識別情報）の画面表示アプリを呼び出す（ステップＳ２０４）。

例えば、［発明が解決しようとする課題］で述べた第１の従来方式により複数のサイトを並行稼働させていた場合には、業務共通処理手段２２２から受け取ったアプリケーションＩＤにより特定されたＰＣ画面用の業務処理アプリにより、ＰＣ画面用の画面表示アプリを呼び出す。また、業務共通処理手段２２２から受け取ったアプリケーションＩＤにより特定された携帯画面用の業務処理アプリにより、携帯画面用の画面表示アプリを呼び出す。

一方、［発明が解決しようとする課題］で述べた第２の従来方式により複数のサイトを並行稼働させていた場合には、業務共通処理手段２２２から受け取ったアプリケーションＩＤにより特定されたＰＣ画面および携帯画面に共有の業務処理アプリにより、ＰＣ画面および携帯画面に共有の画面表示アプリを呼び出すか、あるいは、業務共通処理手段２２２から受け取ったアプリケーションＩＤにより特定されたＰＣ画面および携帯画面に共有の業務処理アプリにより、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、ＰＣ画面用の画面表示アプリまたは携帯画面用の画面表示アプリを選択して呼び出す。

そして、業務共通処理手段２２２により、業務処理手段２２３でデータベースサーバ５０のデータベース５２から取得したデータを、セッションＩＤとともに、画面表示共通処理手段２２４に渡す（ステップＳ２０５）。なお、これらのデータやセッションＩＤを、業務に関する処理から画面表示に関する処理へと伝達するのは、業務共通処理手段２２２によりフレームワークの処理として行うのではなく、業務処理手段２２３により各サービスの個別の処理として行うようにしてもよい。従って、例えば、業務処理手段２２３を構成する業務処理アプリにより、画面表示処理手段２２５を構成する画面表示アプリを呼び出すとともに、これらのデータやセッションＩＤを画面表示アプリに渡すようにしてもよい。

その後、画面表示処理手段２２５により、すなわち業務処理手段２２３を構成する業務処理アプリにより呼び出された画面表示アプリにより、業務共通処理手段２２２から受け取ったデータ（業務処理手段２２３による業務処理でデータベースサーバ５０のデータベース５２から取得したデータ）を用いて、画面表示共通処理手段２２４により読み込む画面ファイル（ＪＳＰ）で作成される画面のうち、要求に係るサービスのデータを用いて表示される動的部分を作成する（ステップＳ２０６）。

また、画面表示処理手段２２５により、すなわち業務処理手段２２３を構成する業務処理アプリにより呼び出された画面表示アプリにより、特定種別（従来方式で並行稼働していた各サイトの構成画面の種別のうちのいずれかの種別）の画面についての画面ファイル（ＪＳＰ）のパスを指定する（ステップＳ２０６）。なお、画面ファイル（ＪＳＰ）のパスは、呼び出された画面表示アプリに記述されている。

例えば、［発明が解決しようとする課題］で述べた第１の従来方式により複数のサイトを並行稼働させていた場合には、ＰＣ画面用の業務処理アプリに呼び出されたＰＣ画面用の画面表示アプリに、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスが記述されている。また、携帯画面用の業務処理アプリに呼び出された携帯画面用の画面表示アプリに、携帯画面用の画面ファイル（ＪＳＰ）のパスが記述されている。

一方、［発明が解決しようとする課題］で述べた第２の従来方式により複数のサイトを並行稼働させていた場合には、ＰＣ画面および携帯画面に共有の業務処理アプリにより呼び出されたＰＣ画面および携帯画面に共有の画面表示アプリに、ＰＣ画面用および携帯画面用の画面ファイル（ＪＳＰ）のパスが記述され、ＰＣ画面および携帯画面に共有の画面表示アプリが、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスまたは携帯画面用の画面ファイル（ＪＳＰ）のパスを選択して指定する。あるいは、ＰＣ画面および携帯画面に共有の業務処理アプリにより、顧客端末７０等からの画面表示要求信号に含まれる情報を用いて判定された画面の種別に応じ、選択的に呼び出されたＰＣ画面用の画面表示アプリに、ＰＣ画面用の画面ファイル（ＪＳＰ）のパスが記述され、また、選択的に呼び出された携帯画面用の画面表示アプリに、携帯画面用の画面ファイル（ＪＳＰ）のパスが記述されている。

続いて、画面表示共通処理手段２２４により、業務共通処理手段２２２から受け取ったセッションＩＤ（業務共通処理手段２２２により受信した画面表示要求信号に含まれるセッションＩＤ）をセッション管理サーバ４０に渡す（ステップＳ２０７）。セッション管理サーバ４０では、セッション管理手段４１により、ＷＥＢ／ＡＰサーバ２２０の画面表示共通処理手段２２４からの画面判定区分の問い合わせ信号（セッションＩＤを伴う。）を受け付け、受け付けたセッションＩＤに関連付けられた画面判定区分をセッション情報記憶手段４２（画面判定区分記憶手段を含む。）から取得し、取得した画面判定区分を、ＷＥＢ／ＡＰサーバ２２０の画面表示共通処理手段２２４に渡す（ステップＳ２０７）。

そして、取得した画面判定区分が特定種別（従来方式で並行稼働していた各サイトの構成画面の種別のうちのいずれかの種別）である場合には、画面表示共通処理手段２２４により、画面表示処理手段２２５により指定された特定種別の画面についての画面ファイル（ＪＳＰ）のパスをそのまま用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段２３２から読み込む（ステップＳ２０７）。例えば、画面判定区分＝０の場合には、業務処理アプリにより呼び出された画面表示アプリに記述されているＰＣ画面用の画面ファイル（ＪＳＰ）のパスを用いて、ＰＣ画面用の画面ファイル（ＪＳＰ）を読み込むか、または、業務処理アプリにより呼び出された画面表示アプリに記述されている携帯画面用の画面ファイル（ＪＳＰ）のパスを用いて、携帯画面用の画面ファイル（ＪＳＰ）を読み込む。

一方、取得した画面判定区分が特定種別以外の種別である場合には、画面表示共通処理手段２２４により、取得した画面判定区分に対応する画面定義ファイルを画面定義ファイル記憶手段２３１から読み込むことにより、その画面定義ファイルに定義された関連付けに従って、画面表示処理手段２２５により指定された特定種別の画面についての画面ファイル（ＪＳＰ）のパスを、特定種別以外の種別の画面についての画面ファイル（ＪＳＰ）のパスに変換し、この変換後のパスを用いて、要求に係るサービスで使用する画面ファイル（ＪＳＰ）を画面ファイル記憶手段２３２から読み込む（ステップＳ２０７）。例えば、画面判定区分＝１の場合には、画面判定区分＝１に対応するＲＷＤ画面用の画面定義ファイルを画面定義ファイル記憶手段２３１から読み込むことにより、そのＲＷＤ画面用の画面定義ファイルに定義された関連付け（ＰＣ画面用の画面ファイルのパスからＲＷＤ画面用の画面ファイルのパスへの変換情報、または、携帯画面用の画面ファイルのパスからＲＷＤ画面用の画面ファイルのパスへの変換情報）に従って、画面表示アプリ（代用）に記述されているＰＣ画面用の画面ファイル（ＪＳＰ）のパスをＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスに変換するか、または、画面表示アプリ（代用）に記述されている携帯画面用の画面ファイル（ＪＳＰ）のパスをＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスに変換し、変換後のＲＷＤ画面用の画面ファイル（ＪＳＰ）のパスを用いて、ＲＷＤ画面用の画面ファイル（ＪＳＰ）を読み込む。

それから、画面表示共通処理手段２２４により、読み込んだ画面ファイル（ＪＳＰ）を用いて、前述したステップＳ２０６で画面表示処理手段２２５により作成した動的部分を含め、要求に係るサービスの画面の表示用データ（Ｗｅｂページ）を作成し、作成した画面の表示用データを、ネットワーク１を介して要求元の顧客端末７０等へ送信する（ステップＳ２０７）。

なお、以上のステップＳ２０３〜Ｓ２０７の処理は、各サービスの提供を受けるための顧客端末７０等からの画面表示要求がある都度に繰り返される。

また、第２実施形態においては、以下のようにして構築支援システム２６０により、サイト提供システム２００の構築支援に関する各種処理が実行される。

図８において、先ず、画面定義ファイル読込手段２６１により、開発中の種別の画面についての画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む（ステップＳ２１１）。この際、通常は、開発環境下の画面定義ファイル記憶手段２３１から読み込むが、本番環境下の画面定義ファイル記憶手段２３１から読み込んでもよく、あるいは画面定義ファイル記憶手段２３１以外の保存場所（例えば、開発者のコンピュータ等）から読み込んでもよい。

次に、画面ファイル読込手段２６２により、画面定義ファイル読込手段２６１により読み込んだ画面定義ファイルから、対応付けられている特定種別の画面（例えばＰＣ画面または携帯画面）についての画面ファイルのパス、および開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルのパスを取得する（ステップＳ２１２）。

続いて、画面ファイル読込手段２６２により、取得したパスを用いて、画面ファイル記憶手段２３２から、特定種別の画面（例えばＰＣ画面または携帯画面）および開発中の種別の画面（例えばＲＷＤ画面）についての各画面ファイル（ＪＳＰ）を読み込む（ステップＳ２１３）。この際、通常は、開発環境下の画面ファイル記憶手段２３２から読み込むが、本番環境下の画面ファイル記憶手段２３２から読み込んでもよい。

なお、サイトの規模（画面ファイルの個数）にもよるが、通常は、ステップＳ２１２において、画面定義ファイルから、多くの対になるパスが取得されることになる。この際、ステップＳ２１３以降の処理（画面ファイルの読込、動的部分の抽出、結果の出力）を行うにあたり、対になるパスを１対ずつ処理していってもよく（対の数だけ画面ファイルの読込、動的部分の抽出、結果の出力という順序の処理を繰り返す。）、幾つかの対になるパス（複数対のパス）をまとめて処理してもよく（まとめられた集合の数だけ画面ファイルの読込、動的部分の抽出、結果の出力という順序の処理を繰り返す。）、対になるパスの全てをまとめて処理してもよい。この点は、前記第１実施形態の場合と同様である。

それから、抽出手段２６３により、読み込んだ各画面ファイル（ＪＳＰ）から、画面の動的部分を記述したコードを抽出する（ステップＳ２１４）。より具体的には、データベース５２から取得されたデータ（例えば残高等）の表示部分等のように、変数（パラメータ）になっている部分のコード（例えば“ＺＡＮＤＡＫＡ”等）を抽出する。

そして、対比結果出力手段２６４により、抽出した特定種別の画面（例えばＰＣ画面または携帯画面）および開発中の種別の画面（例えばＲＷＤ画面）の動的部分を記述したコードを対比した結果を出力（画面表示や印刷）する（ステップＳ２１５）。

対比結果の出力の態様は任意であり、例えば、次のような出力の態様がある。なお、出力の態様を使用者（システム開発者）が選択できるようにしてもよい。この点は、前記第１実施形態の場合と同様である。

第１の出力の態様では、抽出した動的部分を記述したコードを、そのままコードの状態で、図８に示すように、左右に並べる等して対比して出力する。画面表示アプリにより特定種別の画面用の画面ファイル（ＪＳＰ）のパスが指定されるので、図８の例では、画面表示アプリの識別情報（名称：クラス）を表示した後に、対応する各画面ファイル（ＪＳＰ）からそれぞれ抽出した画面の動的部分を記述したコードを、左右に並べて配置し、出力（画面表示や印刷）している。従って、開発中の種別の画面（例えば、ＲＷＤ画面）について、開発漏れがあれば、開発中の種別の画面側が空欄になるか、対応するコードが存在しない旨を示す文字や記号等が出力される。一方、開発中の種別の画面（例えば、ＲＷＤ画面）について、余分な動的部分が含まれていれば、特定種別の画面（例えば、ＰＣ画面または携帯画面）側が空欄になるか、対応するコードが存在しない旨を示す文字や記号等が出力される。

第３の出力の態様では、抽出した動的部分を記述したコードそのものを出力するのではなく、抽出数を対比して出力する。例えば、特定種別の画面（例えば、ＰＣ画面または携帯画面）には、動的部分が１００箇所あり、開発中の種別の画面（例えば、ＲＷＤ画面）には、動的部分が９８箇所ある等の数値情報を出力する。この際、細かい単位（例えばサービスの細目）で区切って抽出数の対比出力を行ってもよく、全サービスをトータルして抽出数の対比出力を行ってもよい。なお、抽出数の対比出力だけでは、前者のように細かい単位で区切って抽出数の対比出力を行わないと、どこに過不足があるのかを直ぐに特定することは困難であるが、画面開発の全体的な進捗を確認することは容易になる。例えば、画面開発をほぼ終えた段階では、双方の抽出数は、ほぼ同数になるが、特定種別の画面（例えば、ＰＣ画面または携帯画面）には、動的部分が１００箇所あり、開発中の種別の画面（例えば、ＲＷＤ画面）には、動的部分が６０箇所ある等と出力されれば、６割程度の進捗であることがわかる。

このような第２実施形態によれば、次のような効果がある。すなわち、サイト提供システム２００では、各サービスの提供に必要な画面についての画面ファイル（ＪＳＰ）のパスを変換するための情報が画面定義ファイルに記述され、この画面定義ファイルからの画面ファイル（ＪＳＰ）のパスの変換情報の取得が、画面表示共通処理手段２２４によるフレームワークの処理として行われる。従って、従来方式（［発明が解決しようとする課題］で述べた第１、第２の従来方式のいずれでもよい。）で並行稼働している複数のサイト（例えばＰＣサイトおよび携帯サイト）を継続して提供することを前提として、別のデバイス向けに新サイト（例えばＲＷＤサイト）を提供する際には、別のデバイス用の画面定義ファイルおよび画面ファイルを新たに作成して用意する必要があるが、処理の内容としては、画面表示処理手段２２５により実行される各サービスの個々の画面表示処理を変更する必要はなく、また、業務共通処理手段２２２や業務処理手段２２３による処理についても変更する必要がなく、画面表示共通処理手段２２４によるフレームワークの処理に、新設の画面判定区分（追加する別のデバイス用の画面の種別を示す画面判定区分）に対応する別のデバイス用の画面定義ファイル（例えばＲＷＤ画面用の画面定義ファイル）を読み込む分岐を増やす変更を行えばよい。従って、サイトを追加する際の修正範囲は、複数種類のサービスの全てで共通利用されるフレームワークに限定される。

このため、開発範囲の狭小化を図ることができ、開発作業を容易に行うことができるので、開発期間の短縮、開発コストの低減を実現することができる。

また、サイトを追加する際に、フレームワークの処理以外の個々の処理を実行するサーバアプリケーション、すなわち画面表示処理手段２２５を構成する画面表示アプリや、業務処理手段２２３を構成する業務処理アプリを修正せずに対応することができるので、サーバアプリの開発において、新たなバグが埋め込まれてしまう可能性を少なくすることができ、ビジネスリスクを減少させることができる。

さらに、サイトの追加が容易になるので、従来方式で並行稼働している複数の既存サイト（例えばＰＣサイトおよび携帯サイト）と、さらに別の画面によるサイト（例えばＲＷＤサイト）との並行稼働を容易に実現することができるため、別のデバイス向けの画面によるサイトの設置が必要になり、あるいは別のデバイスが主流になった場合でも、サービス提供の場を新設のサイト（例えばＲＷＤサイト）に完全に置き換えてしまうのではなく、従来方式で並行稼働している複数の既存サイト（例えばＰＣサイトおよび携帯サイト）の利用者へのサービス提供を継続することができる。このため、例えば、顧客端末７０が、ＲＷＤ画面に対応できない古いバージョンのＷｅｂブラウザを搭載しているＰＣである場合等にも対応することができる。

また、複数の既存サイトおよび追加の新設サイトの並行稼働を容易に実現することができるため、システム障害発生時の代替手段を確保することもできる。

そして、今後、未だ世の中に存在しないか、普及していない新しいタイプのデバイス（例えばウェアラブル端末、音声認識端末、立体画像端末等）が開発され、その新しいタイプのデバイス向けの画面によるサイトを提供する必要性が生じた場合でも、現存しているか、現在普及している別のデバイス向けの画面によるサイトを追加する場合と同様に、開発の対応範囲が限定的なものとなるので、その新しいタイプのデバイス向けの画面によるサイトを容易に追加することができる。例えば、ＰＣの顧客端末７０、携帯電話機の顧客端末７１、およびスマートフォン／タブレットの顧客端末８０を操作する各顧客へのサービス提供を実現するために、ＰＣ画面によるサイトと、携帯画面によるサイトと、ＲＷＤ画面によるサイトとを並行稼働させているときに、さらにウェアラブル端末等の新機種の顧客端末９０を操作する顧客へのサービス提供を開始することになった場合でも、その新機種向けの画面によるサイトを容易に追加することができる。

また、追加するサイトで使用される画面（例えばＲＷＤ画面）の開発は、既存の画面（例えばＰＣ画面または携帯画面）の情報を利用して行うことができるので、画面開発においてバグが埋め込まれてしまう可能性も極力排除することができる。

さらに、従来方式で並行稼働している複数の既存サイト（例えばＰＣサイトおよび携帯サイト）に対し、別の１つのサイト（例えばＲＷＤサイト）を追加する場合と同様にして、従来方式で並行稼働している複数の既存サイトに対し、複数のサイトを同時期に追加すること、別の１つのサイトを追加した後に、さらに別の１つのサイトを追加すること、別の１つのサイトを追加した後に、さらに別の複数のサイトを同時期に追加すること、複数のサイトを同時期に追加した後に、さらに別の複数のサイトを同時期に追加すること等を容易に行うことができる。

そして、以上のように、サイト提供システム２００は、サイトの追加を容易に行うことができる構成とされているので、並行稼働している複数のサイトのうち、一部のサイトを閉鎖することも容易に行うことができる。すなわち、画面の種別の判定処理における分岐や、画面判定区分に対応する画面定義ファイルの読込処理における分岐を減らすだけでよい。なお、余分な分岐が存在しても処理に悪影響が出ない場合には、その分岐を削除しなくてもよい。

また、構築支援システム２６０では、特定種別（従来方式で並行稼働している複数の既設サイトの構成画面の種別のうちのいずれかの種別）の画面（例えばＰＣ画面または携帯画面）および開発中の種別の画面（例えばＲＷＤ画面）の動的部分を記述したコードを対比して確認することができるので、画面開発においてバグが埋め込まれてしまう可能性を低減することができる。すなわち、サーバアプリケーションを共通利用して新規画面のサイトを提供する場合には、バグが生じる可能性が高いのは、画面の動的項目の部分であるので、デザイン上の制約がない状態で新規画面（例えばＲＷＤ画面）を開発し、その後、特定種別の画面（例えばＰＣ画面または携帯画面）についての画面ファイルと、開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルとを読み込み、それらから抽出した動的部分を記述したコードを対比して出力し、あるいは差異や過不足、抽出数を出力することで、バグの埋め込みを回避することができる。

また、特定種別の画面（例えばＰＣ画面または携帯画面）および開発中の種別の画面（例えばＲＷＤ画面）についての画面ファイルを読み込む際には、画面定義ファイルに記述されている画面ファイルのパスを取得し、取得したパスを用いて読込処理を行うので、対応する多くの画面ファイルの対比チェックを容易に、かつ短時間で行うことができるため、画面開発の開発効率の向上を図ることができる。そして、画面開発の進捗管理も容易に行うことができる。

さらに、対応する画面ファイルを１対ずつ順番に読み込んで対比して確認する作業を繰り返す場合には、確認作業者が、確認対象の各画面ファイルのパスを把握していて、それを読込対象として毎回入力することになるので、手間がかかるうえ、対応する画面ファイルのパスが、確認作業者にとって記憶しやすく、把握しやすいものになっている必要がある。これに対し、構築支援システム２６０では、画面定義ファイルに記述されている画面ファイルのパスを利用して自動的に読込処理を行うので、画面ファイルのパスが確認作業者にとって記憶しにくく、把握しにくいものになっていたとしても、容易に画面ファイルの読込処理を行うことができる。

［変形の形態］

なお、本発明は前記各実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。

例えば、前記各実施形態では、ＷＥＢ／ＡＰサーバ２０上で実行されるプログラムは、一例としてｊａｖａ（登録商標）で記述され、画面ファイルは、一例としてＪＳＰとされていたが、これに限定されるものではなく、ｊａｖａ（登録商標）以外の言語を用いてもよく、要するに、フレームワークを観念できる言語であれば、本発明を適用することができる。

以上のように、本発明のサイト提供システムおよびその構築支援システム、並びにプログラムは、例えば、パーソナル・コンピュータ、携帯電話機、スマートフォン、タブレット、または今後開発される新しいタイプのデバイス等の異なる機種の顧客端末からのアクセスを受け付け、それぞれの機種の顧客端末に対して複数種類のサービスを提供する場合に用いるのに適している。

１ネットワーク
１０，２００サイト提供システム
２１，２２１ログイン処理手段
２２，２２２業務共通処理手段
２３，２２３業務処理手段
２４，２２４画面表示共通処理手段
２５，２２５画面表示処理手段
３１，２３１画面定義ファイル記憶手段
３２，２３２画面ファイル記憶手段
４２画面判定区分記憶手段を含むセッション情報記憶手段
７０，７１，８０，９０顧客端末

Claims

ネットワークを介して接続される顧客端末に向けて複数種類のサービスを行うためのウェブサイトを提供するコンピュータにより構成されたサイト提供システムであって、
前記顧客端末から前記ネットワークを介して送信されてくる顧客のログイン情報を受信し、受信したログイン情報を用いて前記顧客端末の画面の種別を判定し、判定した画面の種別を示す画面判定区分を、セッションＩＤと関連付けて画面判定区分記憶手段に記憶させる処理を実行するログイン処理手段と、
前記画面判定区分に対応して作成された、各サービスに関する個別の業務処理を行う業務処理アプリケーションについてのアプリケーションＩＤと前記各サービスで使用する画面についての画面ファイルのパスとの関連付けを定める画面定義ファイルを記憶する画面定義ファイル記憶手段と、
前記各サービスで使用する画面についての画面ファイルを記憶する画面ファイル記憶手段と、
前記顧客端末から前記ネットワークを介して送信されてくるセッションＩＤおよびアプリケーションＩＤを含む画面表示要求信号を受信し、受信した画面表示要求信号に含まれる前記セッションＩＤに関連付けられて前記画面判定区分記憶手段に記憶された前記画面判定区分を取得し、取得した前記画面判定区分に対応する前記画面定義ファイルを前記画面定義ファイル記憶手段から読み込むことにより、受信した前記画面表示要求信号に含まれる前記アプリケーションＩＤに関連付けられた前記パスを取得する処理を、前記複数種類のサービスの全ての業務処理に共通するフレームワークの処理として実行する業務共通処理手段と、
この業務共通処理手段により受信した前記画面表示要求信号に含まれる前記アプリケーションＩＤの業務処理アプリケーションにより、要求に係るサービスの業務処理を実行する業務処理手段と、
前記業務共通処理手段により取得した前記パスを用いて、要求に係るサービスで使用する前記画面ファイルを前記画面ファイル記憶手段から読み込み、読み込んだ前記画面ファイルを用いて、要求に係るサービスの画面を作成する処理を、前記複数種類のサービスの全ての画面表示処理に共通するフレームワークの処理として実行する画面表示共通処理手段と、
前記業務処理手段による業務処理で得られたデータを用いて、前記画面表示共通処理手段により読み込んだ前記画面ファイルで作成される画面のうちの動的部分を作成する処理を実行する画面表示処理手段とを備え、
前記業務処理手段を構成するサービス毎のプログラムは、前記業務共通処理手段による業務共通処理を継承するサービス毎の業務処理を実行するプログラムであり、前記業務共通処理手段を構成するプログラムは、継承元の親クラスのプログラムであり、
前記画面表示処理手段を構成するサービス毎のプログラムは、前記画面表示共通処理手段による画面表示共通処理を継承するサービス毎の画面表示処理を実行するプログラムであり、前記画面表示共通処理手段を構成するプログラムは、継承元の親クラスのプログラムである
ことを特徴とするサイト提供システム。
請求項１に記載のサイト提供システムの構築を支援するコンピュータにより構成されたサイト提供システムの構築支援システムであって、
完成している既存の種別の画面についての前記画面定義ファイルおよび開発中の種別の画面についての前記画面定義ファイルを読み込む処理を実行する画面定義ファイル読込手段と、
この画面定義ファイル読込手段により読み込んだ前記画面定義ファイルから、同一のアプリケーションＩＤに関連付けられている既存の種別および開発中の種別の画面についての前記画面ファイルのパスを取得し、取得したパスを用いて、前記画面ファイル記憶手段から、既存の種別および開発中の種別の画面についての前記画面ファイルを読み込む処理を実行する画面ファイル読込手段と、
この画面ファイル読込手段により読み込んだ前記画面ファイルから、画面の動的部分を記述したコードを抽出する処理を実行する抽出手段と、
この抽出手段により抽出した既存の種別および開発中の種別の画面の動的部分を記述したコードを対比して画面表示および／または印刷する処理、前記動的部分を記述したコードの差異若しくは過不足を画面表示および／または印刷する処理、前記動的部分を記述したコードの抽出数を対比して画面表示および／または印刷する処理のうちの少なくとも１つの処理を実行する対比結果出力手段と
を備えたことを特徴とするサイト提供システムの構築支援システム。
請求項１に記載のサイト提供システムとして、コンピュータを機能させるためのプログラム。
請求項２に記載のサイト提供システムの構築支援システムとして、コンピュータを機能させるためのプログラム。