JP6496849B1 - 検証システムおよびプログラム - Google Patents

Abstract

【課題】新旧システムの挙動の同一性を確保しつつ検証処理の時間短縮を図ることができる検証システムを提供する。【解決手段】システム更改の際に新旧システムの処理結果を比較検証する検証システム１０を構成するにあたり、システムの挙動が切り替わる複数の時間帯に合わせて、本番環境から取得した投入電文を、記録時刻を用いて複数の時間帯に分類する分類手段４２と、分類された状態の投入電文を記憶する再現電文記憶手段５６と、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態のテスト環境下の新システムに対し、再現電文記憶手段５６に記憶された分類後の投入電文のうちの当該仮想の時刻に対応する時間帯の投入電文を新システムに投入する投入手段４３とを設けた。【選択図】図３

Description

本発明は、システム更改の際に新システムの動作をテストするために新システムと旧システムとの処理結果を比較検証する処理を実行する検証システムおよびプログラムに係り、例えば、顧客の注文を受け付けて市場システムへの発注を行う注文処理システムの更改を行う場合等に利用できる。

一般に、システムには、様々な業務を取り扱うシステムが存在するが、その多くは、単独のシステムではなく、複数のシステム（複数のコンピュータ）の連携により業務を遂行している。例えば、株式等の金融商品の売買といった証券・金融業務を取り扱うシステムでは、クライアント端末で入力された顧客の注文をインターネット等のネットワークを介して受け付ける注文受付サーバ、メインフレームである注文処理システム、証券取引所システム等の市場システムなどが連携している。

このように連携している複数のシステムのうちの一部のシステムについて更改を行う場合、その更改部分を構成するシステムは、周辺システムとの間で電文の送受信を行っているので、すなわち、周辺システムからの電文の入力や、周辺システムへの電文の出力があるので、そのような周辺システムとの連携を含めた状態で、更新後の新システムの動作を検証することになる。そして、幾つかの周辺システムがあれば、それぞれの周辺システムとの連携を考慮して検証を行うことになる。

この際、システムの更改においては、新システムは、同じ条件下であれば基本的に旧システムと同一の挙動を行うべきであり、当該条件を保証するためには、個別に結合テストを行い、挙動を確認する必要があるが、テストケースに漏れがあった場合、予期せぬシステム障害が発生する可能性がある。

これを解決するために、実際に旧システムの本番環境で発生した電文をログ情報等から取得し、それを基にしてテスト環境下で再現した電文を新システムにも投入し、結果として出力される電文およびデータベースを新旧システムで比較し、それらに差分がないことを確認することで同一の挙動となっていることを確認する手法を用いた検証処理が頻繁に行われている。

なお、このように本番環境下の旧システムから取得した実際のデータをテスト環境下で再現し、新システムに投入して検証を行う場合において、テスト時間に膨大な時間を費やさなければならないという課題の解決を目的としたシステムとして、データの投入時間の調整を行うテスト装置が知られている（特許文献１参照）。このテスト装置では、本番用システム（本願発明の説明における旧システムに相当）へのリクエスト入力履歴情報（投入電文のログ情報に相当）とアクセス履歴情報とによりテストデータ情報（再現電文に相当）を作成し、更新アクセスである第１のテストデータと更新アクセスである第２のテストデータとのアクセス時間が重複する場合、第２のテストデータのリクエスト入力時間（投入電文の投入タイミングに相当）を所定の時間遅らせるようにテストデータ情報を更新し、テスト用システム（新システムに相当）に対して更新後のテストデータ情報に含まれるテストデータを入力する。この際、テスト用システムに対して更新後のテストデータ情報に含まれる複数のテストデータを入力し、アクセス障害が発生する場合には、アクセス障害が発生するテストデータのリクエスト入力時間を遅らせる。

特開２０１１−８６０８３号公報

前述したように、本番環境下の旧システムから取得した実際のデータをテスト環境下で再現し、新システムに投入して検証を行う手法は、頻繁に利用されているが、次のような課題が生じる。

第１の課題として、１日の再現を１日かけて実施した場合、再現したい日が大量にあった場合、日数がその分発生してしまう。この場合、１日の電文を単純に時間的に圧縮して新システムに投入しても正しい再現にはならない。なぜなら、夜間の時間帯に発生した電文を昼間に投入した場合、システムが異なる振る舞いを行う可能性がある。例えば、株式の注文処理システムの場合に、１５：３０〜１８：００が注文受付停止の時間帯であったとすると、その時間帯に注文電文を投入した場合、注文受付停止の時間帯のエラーが返るが、その時間帯以外に電文を投入した場合、注文電文は正常に受け付けられてしまう。

なお、上記の例のような株式の注文処理システムの場合における各時間帯のシステムの振る舞いの相違は、主として市場システムとの関係でもたらされるが、より一般には、各時間帯のシステムの振る舞いの相違は、市場システムのような周辺システムとの関係で生じる場合だけではなく、法律や規則または各種規制や指導に基づく場合、会社や団体等の取り決めに基づく場合、電力供給の関係で生じる場合等、様々な事情で生じ得る。従って、上述した第１の課題と同様な課題は、周辺システムとのデータ連携を行う構成とされているシステムの更改の場合だけではなく、単独で業務処理を行うシステムの更改の場合にも生じ得る。このため、本発明は、主としてデータ連携を行う一連のシステムのうちの一部のシステムを更改する場合の検証処理を実行するものであるが、これに限定されず、単独で業務処理を行うシステムを更改する場合の検証処理を実行するものとしてもよい。

第２の課題として、再現テストは、１回だけではなく、同じ日の再現を何回も実施する必要があるが、投入電文の準備やシステム内データの整備等の前準備作業が大量にあるため、１回の作業を行うまでの手順が煩雑となる。

第３の課題として、投入電文の入力経路が複数ある場合には、その全てを本番で発生した順序を保ったうえで再現しないと出力電文が一致しない場合がある。例えば、株式の注文処理システムの場合には、注文の入力操作が行われるクライアント端末とネットワークで接続された注文受付サーバからの注文電文の入力経路と、市場システムからの通知電文の入力経路とがあり、さらに、逆指値注文・デュアル指値注文・連続注文等のような条件付注文を受け付ける注文処理システムの場合には、条件の成否を監視する条件成否監視サーバからの条件付注文発注電文の入力経路もある。

第４の課題として、システム更改に係る部分について新旧システム間で仕様を変更している箇所がある場合には、本番環境から取得した実際の投入電文を単純にテスト環境下の新システムに投入することはできず、また、新旧システムの応答電文を単純に比較することもできない。なお、ここでいう仕様の変更とは、システムの性能向上に寄与するハードウェア仕様の変更という意味ではなく（経年によるシステム更改であれば、システム技術の進歩に伴うハードウェア仕様の変更は当然にあるが、ここではその意味ではない。）、データベースや電文の構成（形式や定義）の変更という意味である。例えば、市場について、旧システムで「１＝東京」、「２＝大阪」となっていたのに対し、新システムでは「１＝大阪」、「２＝東京」となる場合や、注文状況について、旧システムで「１＝注文中」、「２＝約定済」となっていたのに対し、新システムでは「１＝約定済」、「２＝注文中」となる場合のように、定義が逆転したり、ずれたりする場合等である

従って、テストに要する処理時間の短縮を図るという意味で、第１の課題を解決することができる検証システムの開発が望まれる。また、併せて、第２〜第４の課題を解決することができれば、より便利である。

なお、前述した特許文献１に記載されたテスト装置は、リクエスト入力時間を遅らせる処理を行っているので、データの投入時間の調整を行っているとは言えるものの、以上に述べたような第１〜第４の課題を解決するものではない。

本発明の目的は、新旧システムの挙動の同一性を確保しつつ検証処理の時間短縮を図ることができる検証システムおよびプログラムを提供するところにある。

本発明は、システム更改の際に新システムの動作をテストするために新システムと旧システムとの処理結果を比較検証する処理を実行する検証システムであって、
本番環境下の旧システムから取得した投入電文を、本番環境下の記録時刻とともに記憶する本番投入電文記憶手段と、
新システムおよび旧システムの双方に共通してシステムの挙動が切り替わる複数の時間帯に合わせて、本番投入電文記憶手段に記憶された投入電文を、記録時刻を用いて複数の時間帯に分類する処理を実行する分類手段と、
この分類手段により分類された投入電文を、分類された状態で記憶する再現電文記憶手段と、
複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態のテスト環境下の新システムに対し、再現電文記憶手段に記憶された分類後の投入電文のうち、新システムに設定した仮想の時刻に対応する時間帯の投入電文を通信回線を介して投入する処理を、複数の時間帯のそれぞれについて実行する投入手段と
を備えたことを特徴とするものである。

ここで、「投入手段」において、「複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態」のように「時間帯に従って…」とし、また、「仮想の時刻に対応する時間帯の投入電文」のように「…に対応する時間帯」としているのは、次の理由からである。すなわち、通常は、システム時刻を各時間帯の開始時刻に設定すればよく、それが最も簡単な処理であるが、投入電文の投入が所望の時間帯（新システムにおいて進行する仮想の時間帯）に行われるようになればよいので、システム時刻として、各時間帯の開始時刻以外の時刻を設定してもよい。例えば、６：００〜８：００という時間帯の場合には、当該時間帯の開始時刻６：００を設定するのが通常であるが、８：００までに当該時間帯に投入すべき投入電文の処理が終了することを前提に（新システムへの投入電文の投入タイミングは、時間的にかなり圧縮されるので、２時間よりもかなり短い時間長で当該時間帯の処理は終了する。）、例えば６：０５や７：００等の仮想の時刻（６：００よりも後の時刻）を設定してもよい。逆に、例えば、５：５９等の仮想の時刻（６：００よりも前の時刻）を設定することも可能であり、この場合、仮想の時刻を設定した後、時間を置いてから投入電文の投入を行うようにすればよく、例えば、５：５９の仮想の時刻を設定し、１分間置いてから、投入電文の投入を開始すれば、投入電文の投入は、６：００以降に行われることになるので、当該時間帯６：００〜８：００内の処理となり、適正なシステムの挙動が得られる。但し、あえてずらす必要性や利点がない場合は、システム時刻として、各時間帯の開始時刻を設定するのが、処理としては簡単でよい。

また、仮想の時刻が設定される「システム時刻」は、通常は、コンピュータが保有する時刻を意味するが、別途に時間を管理する制御プログラムを稼働させ、新システムの各種業務用のプログラムが、その制御プログラムにより管理される時刻を参照して業務処理を行う構成とされている場合には、その制御プログラムで管理される時刻としてもよく、要するに、各種業務用のプログラムが取得する時刻を、仮想の時刻に設定することができればよい。

このような本発明の検証システムにおいては、テスト環境下での再現に使用する投入電文を複数の時間帯に分類しておき、複数の時間帯のそれぞれについて、テスト環境下の新システムについてのシステム時刻を仮想の時刻に設定した状態で、その仮想の時刻に対応する時間帯の投入電文を新システムに投入する処理を実行するので、投入電文の投入タイミング（投入間隔）を圧縮しても、新システムで進行している仮想の時刻で見た場合には、投入電文は、投入すべき時間帯に新システムに投入されていることになるため、新システムにおいて、投入電文に対する適正な挙動（本番環境で実行された処理を再現する挙動）が得られるようになる。

このため、１日の再現を１日かけて実施する必要はなく、新システムへの投入電文の投入タイミング（投入間隔）を圧縮することにより、１日の再現を短時間で実行可能となり、検証処理の時間短縮を図ることが可能となる。

また、再現したい日が大量にある場合でも、新システムへの投入電文の投入タイミング（投入間隔）の圧縮を、日を超えて行うことにより、テストに要する日数が本番環境と同じ日数分だけ発生してしまうことを回避することができ、検証処理の時間短縮を図ることが可能となり、これらにより前記目的が達成される。

＜仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを連動させる構成＞

また、前述した検証システムでは、新システムに対し、ある時間帯の投入電文を投入する前に、その時間帯に対応する仮想の時刻の設定が行われていればよいので、仮想の時刻の設定は、人手による判断で決められたタイミングで実行してもよく、また、人手による操作を介して実行してもよい。しかし、省力化を図りつつ検証処理の時間短縮を効果的に図るには、次のような構成とすることが望ましい。

すなわち、前述した検証システムにおいて、
投入手段は、
テスト環境下の新システムに対し、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定するための仮想の時刻の設定指令を、通信回線を介して送信した後、当該仮想の時刻に対応する時間帯の投入電文を、通信回線を介して新システムに投入する処理を実行し、この際、仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを、複数の時間帯について交互に繰り返す構成とされていることが望ましい。

このように仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを連動させ、自動化する構成とした場合には、仮想の時刻の設定指令の送信タイミングや、当該仮想の時刻に対応する時間帯の投入電文の投入開始タイミングの管理を、人手により行う必要がなくなるので、省力化（再現テストの担当者の負荷軽減や、再現テストにかかる要員の削減）を図ることができるとともに、投入電文の投入タイミング（投入間隔）の圧縮を、より一層確実に行うことが可能となる。すなわち、同一の時間帯内における各投入電文の投入タイミング（投入間隔）の圧縮は、投入開始タイミングの管理を手動で行っても実現できるので、圧縮投入の効果を得ることができるが、上記のような仮想の時刻（システム時刻）の設定と投入開始とを連動させる自動化により、ある時間帯の投入開始タイミングと、その次の時間帯の投入開始タイミングとの時間間隔を、より一層確実に詰めていくことができるので、複数の時間帯に跨っての圧縮投入を、より一層確実に実現可能となる。さらに、再現の自動化により、夜間の再現テストも可能になる。そして、この効果は、同じ日の再現を何回も実施する場合や、複数の日（本番環境下における複数の日）の再現を実施する場合には、より顕著となる。

＜顧客の注文を受け付けて市場システムへの発注を行う注文処理システムを更改する場合の構成＞

以上に述べた検証システムにおいて、
システム更改の対象となる新システムおよび旧システムは、顧客の注文を受け付けて市場システムへの発注を行う注文処理システムであり、
時間帯は、市場システムとの電文の送受信を行うために定められた時間帯であり、
投入電文には、顧客またはその入力代行者により入力された新規注文、注文の訂正、および注文の取消のケースを含む注文電文と、市場システムからの通知電文とが含まれ、
分類手段は、
複数の時間帯に分類された投入電文を、さらに顧客毎にグルーピングし、時間帯に分類され、かつ、顧客毎にグルーピングされた状態で投入電文を再現電文記憶手段に記憶させる処理を実行する構成とされ、
投入手段は、
複数の時間帯のそれぞれについて、顧客毎にグルーピングされた投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していく処理を実行する構成とすることができる。

ここで、「市場システムからの通知電文」には、システム更改の対象となる新旧のシステムと市場システムとの間に、他のシステム（例えば、市場接続システム）が介在する場合には、当該他のシステムからの通知電文が含まれる。

このように注文処理システムを更改する構成とした場合には、複数の時間帯のそれぞれについて、顧客毎にグルーピングされた投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していくので、本番環境を適正に再現することが可能となる。すなわち、注文処理システムでは、投入電文として、新規注文、注文の訂正、および注文の取消のケースを含む注文電文と、市場システムからの通知電文とがあるので、投入電文を時間帯で分類し、かつ、システム時刻への仮想の時刻の設定を行ったとしても、同一顧客内の投入電文の順序が本番環境の通りに保たれないと、新システムで所望の挙動（本番環境での処理を再現する挙動）を得られないことがあるが、このような問題の発生を回避することが可能となる。例えば、本番環境で、新規注文の注文電文、訂正の注文電文、約定の通知電文の順序で投入されていた場合に、テスト環境で、訂正の注文電文と約定の通知電文との投入順序が入れ替われば、処理結果は異なってしまうが、このような事態を回避することが可能となる。

＜投入電文の入力経路が複数あり、複数の入力経路についての記録時刻が同時刻になったときに優先する入力経路を予め定めておく構成＞

前述した注文処理システムを更改する構成とした場合において、
投入電文には、注文電文および通知電文に加え、市場システムへの発注のタイミングを監視する必要のある条件付注文について条件が満たされた場合に投入される条件付注文発注電文が含まれ、
分類手段は、
複数の時間帯のそれぞれについて顧客毎に投入電文をグルーピングする際に、本番環境下の記録時刻が同時刻になっている投入電文については、注文電文、条件付注文発注電文、通知電文の順で予め定められた優先順位に従って、この優先順位の高い投入電文から順番にテスト環境下の新システムに対して投入されるように投入電文を並べる構成とされていることが望ましい。

このように複数の入力経路についての記録時刻が同時刻になったときに優先する入力経路を予め定めておく構成とした場合には、本番環境で生じた状況を正しく再現することができ、新システムで所望の挙動（本番環境での処理を正しく再現する挙動）を得ることが可能となる。すなわち、複数の入力経路についての本番環境下の記録時刻が同じ時刻になっていたとしても、本番環境における実際の処理には、記録時刻の最小単位の刻み幅に満たない長さの時間差があり、順番がある場合があるので、それらの処理の順序が逆転してしまうと、エラーが発生する等、新システムで所望の挙動（本番環境での処理を再現する挙動）を得られないことがあるが、このような問題の発生を回避することが可能となる。例えば、訂正の注文電文の投入についてのログの記録時刻と、訂正完了の通知電文の投入についてのログの記録時刻とが同じ時刻であったとしても、実際には前者の処理のほうが早いが、これらが逆転すると、注文の訂正が出ていないのに、訂正完了の通知を受けることになってしまうので、このような事態を回避することが可能となる。なお、複数の入力経路の記録時刻が、異なるコンピュータでの記録時刻である場合には、記録時刻の最小単位の刻み幅がコンピュータ間で異なることもあり得るが、そのような場合にも、同様な問題が生じ得る。

＜システム更改に伴う新システムと旧システムとの投入電文の形式または定義に差分がある場合の構成＞

以上に述べた検証システムにおいて、
システム更改に伴う新システムと旧システムとの投入電文の形式または定義の差分を記憶する投入用差分記憶手段を備え、
投入手段は、
投入用差分記憶手段に記憶された投入電文の形式または定義の差分を用いて、再現電文記憶手段に記憶された分類後の投入電文を、新システム用の形式または定義に変換してから新システムに投入する処理を実行する構成としてもよい。

このように投入用差分記憶手段に記憶された投入電文の形式または定義の差分を用いて、投入手段により投入電文を新システム用の形式または定義に変換してから新システムに投入する構成とした場合には、新旧システムの投入電文の形式または定義に差分があるときであっても、本番環境から取得した投入電文を用いて、テスト環境下の新システムに投入する投入電文を自動的に作成することができるので、検証処理の準備作業が容易になり、省力化を図ることが可能となる。

＜プログラムの発明＞

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

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

以上に述べたように本発明によれば、テスト環境下での再現に使用する投入電文を複数の時間帯に分類しておき、複数の時間帯のそれぞれについて、テスト環境下の新システムについてのシステム時刻を仮想の時刻に設定した状態で、その仮想の時刻に対応する時間帯の投入電文を新システムに投入する処理を実行するので、新旧システムの挙動の同一性を確保しつつ検証処理の時間短縮を図ることができるという効果がある。

本発明の一実施形態の検証システムの全体構成図。 前記実施形態におけるシステム更改の対象となる本番環境下の旧システムの構成図。 前記実施形態におけるシステム更改の対象となるテスト環境下の新システムの構成図。 前記実施形態のテスト環境下の新システムに投入する投入電文の作成方法の説明図。 前記実施形態のテスト環境下の新システムへの投入電文の投入方法の説明図。 前記実施形態の検証システムによる検証処理の流れを示すフローチャートの図。

以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態の検証システム１０の全体構成が示されている。図２、図３には、システム更改の対象となる本番環境下の旧システム、テスト環境下の新システムの構成がそれぞれ示されている。また、図４および図５は、テスト環境下の新システムに投入する投入電文の作成方法および投入方法の説明図である。さらに、図６には、検証システム１０による検証処理の流れがフローチャートで示されている。

＜検証システム１０の構成の概略：図１＞

図１において、検証システム１０は、システム更改の際に新システムの動作をテストするために新システムと旧システムとの処理結果を比較検証する処理を実行するシステムであり、１台または複数台のコンピュータにより構成されている。この検証システム１０は、本番環境下の旧システムから実際のデータを取得し、そのデータを利用してテスト環境下の新システムにおいて、本番環境で実行された処理内容（システムの動作）を再現し、新旧システムの処理結果を比較検証することにより、新システムの動作をチェックするものである。

なお、検証システム１０は、例えば、１台または複数台のサーバと、検証処理の担当者が操作する担当者端末（クライアント）とを通信回線（社内ＬＡＮやイントラネット等の内部ネットワークでもよく、インターネット等の広範な外部ネットワークでもよく、専用線でもよい。）で接続することにより構成してもよく、検証処理の担当者が操作するマウスやキーボード等の入力手段および液晶ディスプレイ等の表示手段を備えた１台のコンピュータにより構成してもよい。

この検証システム１０は、本番環境情報収集手段２０と、テスト環境情報収集手段３０と、本番データ反映手段４０と、マスキング手段４１と、分類手段４２と、投入手段４３と、条件成否監視サーバ用スタブ４４と、市場用スタブ４５と、注文データ検証手段４６と、応答電文検証手段４７とを備えている。

これらの各手段２０，３０，４０〜４３，４６，４７および各スタブ４４，４５は、検証システム１０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。なお、これらの各手段２０，３０，４０〜４３，４６，４７および各スタブ４４，４５の詳細は、後述する。

また、検証システム１０は、本番投入電文記憶手段５０と、本番応答電文記憶手段５１と、業務開始時点本番データ記憶手段５２と、業務終了時点本番データ記憶手段５３と、テスト応答電文記憶手段５４と、業務終了時点テストデータ記憶手段５５と、再現電文記憶手段５６と、投入用差分記憶手段５７と、注文データ検証用差分記憶手段５８と、応答電文検証用差分記憶手段５９とを備えている。

これらの各記憶手段５０〜５９は、例えばハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、例えば、ＤＶＤ、ＣＤ、ＭＯ、磁気テープ等の他の記録媒体を採用してもよい。また、各記憶手段５０〜５９のデータ保存形式は、データベースでもよく、フラットファイル等のファイル形式でもよい。なお、これらの各記憶手段５０〜５９の詳細は、後述する。

＜本番環境下の旧システムおよびその周辺システムの構成、およびこれらのシステムによる一連の業務処理の流れの概要：図２＞

本実施形態では、システム更改の対象（すなわち、検証処理の対象）は、図２に示すように、一例として、株式の注文処理システムとする。従って、本実施形態の検証システム１０は、顧客による株式の売買注文を受け付けて株式市場への発注を行う注文処理システムについて、更改に係る新旧のシステムの処理結果の比較検証を行うことにより、新システムが正常に動作するかを確認するためのテストを行う。

なお、本発明の検証システムによる検証処理の対象システム（システム更改の対象システム）は、株式の注文処理システムに限定されるものではなく、株式以外の金融商品の売買注文を取り扱う注文処理システムであってもよく、さらには、証券・金融システムに限定されるものでもなく、従って、市場への発注を行う注文処理システムに限定されるものでもない。但し、市場への発注を行う注文処理システムの場合には、その注文処理システムへの投入電文の入力経路について、少なくとも、顧客サイドからの入力経路と、市場サイドからの入力経路とが存在する状態となるので、本発明の効果が、より顕著に得られる。

図２において、検証システム１０による検証処理の対象となる株式の注文処理システムは、図２中の一点鎖線で囲まれた部分であり、注文受付システム６０と、注文管理システム７０とにより構成されている。これらのシステム６０，７０は、いずれも大型汎用コンピュータにより構成された、いわゆるメインフレーム（ホストコンピュータ）である。なお、これらのシステム６０，７０は、１台のメインフレームにより構成してもよい。本実施形態では、一例として、これらのシステム６０，７０のうち、注文受付システム６０についてシステム更改が行われ、注文管理システム７０については、更改部分は無いものとする。但し、本実施形態では、注文管理システム７０も含めて注文処理システムの全体（すなわち、注文受付システム６０および注文管理システム７０の結合状態）を、比較検証対象の新旧システムとして捉えるものとする。従って、本実施形態では、検証システム１０は、注文処理システム（システム６０，７０の結合状態）への入力データを「投入電文」とし、注文処理システム（システム６０，７０の結合状態）からの出力データを「応答電文」として捉えるものとする。なお、更改部分である注文受付システム６０に対する入出力データを収集することができる場合には、注文管理システム７０を除いて注文受付システム６０だけを、比較検証対象の新旧システムとして捉えてもよく、その場合には、注文受付システム６０への入力データを「投入電文」とし、注文受付システム６０からの出力データを「応答電文」として捉えることになるので、更改部分のない注文管理システム７０は、比較検証対象の新旧システムの外部に配置される周辺システムという扱いになる。より一般的に言えば、ある業務を行う一連のシステムのうち、どこからどこまでの範囲を本発明の検証システムによる比較検証対象とするかは、データの収集容易性等から、ケース・バイ・ケースで選択することができ、要するに、更改部分が含まれるように比較検証対象を選択決定すればよい。

注文受付システム６０の上流側には、注文受付サーバ９０が設けられている。この注文受付サーバ９０は、顧客が操作する顧客端末（不図示）とインターネットを介して接続されたウェブ・アプリケーションサーバであり、顧客端末からインターネットを介して送信されてくる顧客の注文データ（顧客識別情報、銘柄、売買区分、数量、単価、市場等を含む。）を受け付ける処理を実行するものである。また、注文受付サーバ９０は、入力代行者（営業員やオペレータ）が操作する代行者端末（不図示）からネットワーク（社内ＬＡＮやイントラネット等の内部ネットワークでもよく、インターネットでもよい。）を介して送信されてくる顧客の注文データを受け付ける処理を実行するものでもよい。

注文受付サーバ９０は、注文受付手段９１により、顧客端末または代行者端末からネットワークを介して送信されてくる顧客の注文データを受信すると、その注文に注文番号を自動付与し、注文電文（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。）を、通信回線を介して注文受付システム６０へ送信する。この注文電文（注文受付サーバ９０から注文受付システム６０へ送信される電文）は、比較検証対象の注文処理システムに投入される投入電文である。なお、最終的に市場に送信する注文番号は、注文管理システム７０により自動付与される番号であり、注文管理システム７０よりも上流のシステムで付与される番号ではないが、各システムで付与される番号は関連付けられているので、本実施形態では、説明の便宜上、各システムで付与される番号を、市場に送信する注文番号で統一して説明を行う。

注文受付システム６０では、投入電文である注文電文の受信があると、そのログ情報が注文ログ記憶手段６５に記憶される。このログ情報には、注文電文の記録時刻（年月日、時分秒）が含まれる。

そして、注文受付手段６１は、受信した注文電文の内容を、注文データ記憶手段６４に記憶させるとともに、注文を受け付けた旨の注文応答電文（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。）を、通信回線を介して注文受付サーバ９０へ送信する。この注文応答電文（注文受付システム６０から注文受付サーバ９０へ送信される電文）は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文受付システム６０では、注文応答電文の送信があると、そのログ情報が注文応答ログ記憶手段６６に記憶される。このログ情報には、注文応答電文の記録時刻（年月日、時分秒）が含まれる。

また、注文受付手段６１は、受信した注文電文の注文が、逆指値注文・デュアル指値注文・連続注文等のような条件付注文の場合には、条件の成否を監視する処理が必要となり、市場への発注をすぐに行うことはできないので、条件付注文電文（顧客識別情報、注文番号、銘柄、売買区分、数量、条件となる単価、市場等を含む。）を、通信回線を介して条件成否監視サーバ１００へ送信する。この条件付注文電文（注文受付システム６０から条件成否監視サーバ１００へ送信される電文）は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文受付システム６０では、条件付注文電文の送信があると、そのログ情報が条件付注文ログ記憶手段６７に記憶される。このログ情報には、条件付注文電文の記録時刻（年月日、時分秒）が含まれる。

条件成否監視サーバ１００では、条件付注文受付手段１０１により、条件付注文電文を受信し、受信した条件付注文電文の内容を、条件付注文データ記憶手段１０３に記憶させる。そして、条件付注文発注手段１０２は、時価情報提供システム１１０（情報ベンダーのシステム、自社内の別のシステム、または市場システム１３０）から取得した金融商品の時価情報（本実施形態では、株価情報）を用いて、条件付注文データ記憶手段１０３に記憶されている各条件付注文についての条件の成否を監視し、条件が成立した条件付注文について、条件付注文データ記憶手段１０３に記憶された条件付注文のデータを用いて、条件付注文発注電文（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。）を作成し、通信回線を介して注文受付システム６０へ送信する。この条件付注文発注電文（条件成否監視サーバ１００から注文受付システム６０へ送信される電文）は、比較検証対象の注文処理システムに投入される投入電文である。

注文受付システム６０では、投入電文である条件付注文発注電文の受信があると、そのログ情報が条件付注文発注ログ記憶手段６８に記憶される。このログ情報には、条件付注文発注電文の記録時刻（年月日、時分秒）が含まれる。そして、条件付注文受付手段６２は、受信した条件付注文発注電文の内容を、注文データ記憶手段６４に記憶させる。

なお、各種マスタ記憶手段６３には、例えば、顧客情報（顧客の口座番号、パスワード、住所、氏名、電話番号等）や銘柄情報などが記憶され、注文受付手段６１や条件付注文受付手段６２の処理で必要な場合に参照される。

注文管理システム７０では、発注手段７１が、注文データ記憶手段６４に記憶された注文データを用いて、市場への発注を行うための発注電文（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場等を含む。）を作成し、通信回線を介して市場接続システム１２０へ送信するとともに、発注電文の内容を発注データ記憶手段７３に記憶させる。この発注電文（注文管理システム７０から市場接続システム１２０へ送信される電文）は、比較検証対象の注文処理システムから外部へ出ていく応答電文である。注文管理システム７０では、発注電文の送信があると、そのログ情報が発注ログ記憶手段７４に記憶される。このログ情報には、発注電文の記録時刻（年月日、時分秒）が含まれる。

市場接続システム１２０は、市場システム１３０との接続の異常検知を含め、市場システム１３０との間の電文の送受信の管理処理を実行するものである。この市場接続システム１２０は、注文管理システム７０から受信した順番で発注キューに置かれた発注電文を、その順番で通信回線を介して市場システム１３０へ送出する。なお、市場接続システム１２０は、証券会社等の金融機関が設置するシステムであるが、本発明を説明するうえでは（検証システム１０の機能を把握するうえでは）、市場サイドのシステムとして捉えてもよい。

市場システム１３０は、応答電文である発注電文を受信すると、その発注電文に応じた内容の通知電文（顧客識別情報、注文番号等を含む。）を、通信回線を介して市場接続システム１２０へ送信する。例えば、上流から見ると、注文受付サーバ９０からの投入電文が、新規注文の注文電文、訂正の注文電文、取消の注文電文である場合には、注文管理システム７０からは、それらの投入電文に対する応答電文として、新規注文の発注電文、訂正の発注電文、取消の発注電文が、市場接続システム１２０を介して市場システム１３０に送信されてくるので、市場システム１３０は、注文受付の通知電文、訂正完了の通知電文、取消完了の通知電文を、それぞれ通信回線を介して市場接続システム１２０へ送信する。

また、市場システム１３０は、市場において顧客の注文が約定した場合には、約定の通知電文（顧客識別情報、注文番号、銘柄、売買区分、約定数量、約定単価、市場等を含む。）を、通信回線を介して市場接続システム１２０へ送信する。

市場接続システム１２０は、市場システム１３０から送信されてくる通知電文を受信し、受信した通知電文を、通信回線を介して注文管理システム７０へ送信する。この通知電文（市場接続システム１２０から注文管理システム７０へ送信される電文）は、比較検証対象の注文処理システムに投入される投入電文である。

注文管理システム７０では、投入電文である通知電文の受信があると、そのログ情報が通知ログ記憶手段７５に記憶される。このログ情報には、通知電文の記録時刻（年月日、時分秒）が含まれる。

そして、注文管理システム７０では、約定処理手段７２により、受信した通知電文の内容に応じ、発注データ記憶手段７３に記憶された発注データの更新処理を実行する。例えば、約定の通知電文を受信した場合には、約定数量や約定単価等を記憶させ、注文状況を示すステータスを「注文中」から「約定済」に変更する処理等を実行する。また、約定の情報を用いて、注文受付システム６０の注文データ記憶手段６４に記憶された注文データの更新処理も行われる。

＜テスト環境下の新システムの構成および検証システム１０との配置関係：図３＞

図３において、テスト環境下の新システムである注文処理システムは、図３中の一点鎖線で示すように、注文受付システム８０と注文管理システム７０とにより構成されている。このうち、更改部分は、注文受付システム８０だけであり、注文管理システム７０については、更改はなく、図２の本番環境下と同じものである。従って、図２の本番環境下の旧システムを構成する注文受付システム６０が、図３のテスト環境下の新システムを構成する注文受付システム８０に変わっただけである。新システムの注文受付システム８０を構成する各手段８１，８２および各記憶手段８３〜８８は、旧システムの注文受付システム６０を構成する各手段６１，６２および各記憶手段６３〜６８に対応している。

そして、図３のテスト環境において、新システムである注文処理システム（注文受付システム８０と注文管理システム７０との結合状態）の上流側には、図２の注文受付サーバ９０や条件成否監視サーバ１００の代わりに、検証システム１０の投入手段４３や条件成否監視サーバ用スタブ４４が配置され、下流側には、図２の市場接続システム１２０や市場システム１３０の代わりに、検証システム１０の投入手段４３や市場用スタブ４５が配置されている。

＜検証システム１０の構成の詳細：図１、図３＞

図１において、本番環境情報収集手段２０は、本番環境から検証処理に必要なデータを収集する処理を行うものであり、本番投入電文取得手段２１と、本番応答電文取得手段２２と、業務開始時点本番データ取得手段２３と、業務終了時点本番データ取得手段２４とを含んで構成されている。

本番投入電文取得手段２１は、本番環境下の旧システム（図２参照）の注文ログ記憶手段６５に記憶された注文電文（投入電文）のログ情報、条件付注文発注ログ記憶手段６８に記憶された条件付注文発注電文（投入電文）のログ情報、および通知ログ記憶手段７５に記憶された通知電文（投入電文）のログ情報を取得し、取得した各ログ情報（電文データの記録時刻を含む。）を、本番投入電文記憶手段５０に記憶させる処理を実行するものである。

本番応答電文取得手段２２は、本番環境下の旧システム（図２参照）の注文応答ログ記憶手段６６に記憶された注文応答電文（応答電文）のログ情報、条件付注文ログ記憶手段６７に記憶された条件付注文電文（応答電文）のログ情報、および発注ログ記憶手段７４に記憶された発注電文（応答電文）のログ情報を取得し、取得した各ログ情報（電文データの記録時刻を含む。）を、本番応答電文記憶手段５１に記憶させる処理を実行するものである。

業務開始時点本番データ取得手段２３は、本番環境下の旧システム（図２参照）の業務開始時点における各種マスタ記憶手段６３に記憶された各種マスタ情報（顧客情報等）、注文データ記憶手段６４に記憶された注文データ（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。）、および発注データ記憶手段７３に記憶された発注データ（注文データと同様な内容）を取得し、取得したデータを、業務開始時点本番データ記憶手段５２に記憶させる処理を実行するものである。なお、業務開始時点における注文データや発注データを取得するのは、例えば、業務開始時点で、前日の夜間に発生したデータが残っている場合等があり、そのような状態をテスト環境に反映させてから検証処理を開始する必要があるからである。

業務終了時点本番データ取得手段２４は、本番環境下の旧システム（図２参照）の業務終了時点における注文データ記憶手段６４に記憶された注文データ、および発注データ記憶手段７３に記憶された発注データを取得し、取得したデータを、業務終了時点本番データ記憶手段５３に記憶させる処理を実行するものである。

テスト環境情報収集手段３０は、テスト環境から検証処理に必要なデータを収集する処理を行うものであり、テスト応答電文取得手段３１と、業務終了時点テストデータ取得手段３２とを含んで構成されている。

テスト応答電文取得手段３１は、テスト環境下の新システム（図３参照）の注文応答ログ記憶手段８６に記憶された注文応答電文（応答電文）のログ情報、および条件付注文ログ記憶手段８７に記憶された条件付注文電文（応答電文）のログ情報を取得し、取得した各ログ情報を、テスト応答電文記憶手段５４に記憶させる処理を実行するものである。また、図１および図３には、市場用スタブ４５が、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文（本番環境下の番号に変換後の注文番号を含む。）を、テスト応答電文記憶手段５４に記憶させるように図示されているが、テスト応答電文取得手段３１が、発注ログ記憶手段７４に記憶された発注電文（応答電文）のログ情報を取得し、再現電文記憶手段５６に記憶された二つの環境下の番号の関連付け情報を用いて、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文（本番環境下の番号に変換後の注文番号を含む。）を、テスト応答電文記憶手段５４に記憶させる構成としてもよい。

業務終了時点テストデータ取得手段３２は、テスト環境下の新システム（図３参照）の業務終了時点における注文データ記憶手段８４に記憶された注文データ、および発注データ記憶手段７３に記憶された発注データを取得し、取得したデータを、業務終了時点テストデータ記憶手段５５に記憶させる処理を実行するものである。

本番データ反映手段４０は、テスト環境下の新システム（図３参照）に対し、業務開始時点における本番環境のデータを反映させることにより、テスト環境下の新システムにおいて本番環境の業務開始時点の状況を再現する処理を実行するものであり、業務開始時点本番データ記憶手段５２に記憶された各種マスタ情報（顧客情報等）、注文データ、および発注データを、テスト環境における各種マスタ記憶手段８３、注文データ記憶手段８４、および発注データ記憶手段７３にそれぞれ格納する処理を実行する。

マスキング手段４１は、本番投入電文記憶手段５０に記憶された投入電文（注文電文、条件付注文発注電文、および通知電文）のログ情報の中に、暗証番号等の個人情報が含まれている場合には、その個人情報を代替情報に置き換える処理を実行するものである。なお、本実施形態では、顧客識別情報は、個人情報とはみなさないので、そのまま再現電文の構成データとして使用する。

分類手段４２は、図４に示すように、本番投入電文記憶手段５０に記憶された複数の入力経路の投入電文（注文電文、条件付注文発注電文、および通知電文）を、マスキング手段４１による処理後に、記録時刻を用いて各投入電文の投入順序の通りに並べて統合し、統合した複数の入力経路の投入電文を、比較検証対象のシステム（本実施形態では、注文処理システム）の挙動が切り替わる複数の時間帯に合わせて、記録時刻を用いて複数の時間帯に分類し、分類後の投入電文を、再現電文記憶手段５６に記憶させる処理を実行するものである。

ここで、複数の時間帯は、本実施形態では、一例として、注文処理システムを比較検証対象としているので、市場システム１３０（図２参照）との関係で予め設定されている時間帯であり、これらの複数の時間帯は、新システムである注文処理システム（図３の注文受付システム８０および注文管理システム７０）と、旧システムである注文処理システム（図２の注文受付システム６０および注文管理システム７０）との双方に共通するものである。このように時間帯による分類処理を行うのは、各時間帯でシステムの挙動が異なるので、テスト環境において本番環境と同じ挙動を再現し、両者を比較検証するためである。

より具体的には、複数の時間帯は、例えば、「市場開局前」の時間帯（１）＝６：００〜８：００と、「市場開局後」の時間帯（２）＝８：００〜９：００と、「前場」の時間帯（３）＝９：００〜１１：３０と、「場間」の時間帯（４）＝１１：３０〜１２：０５と、「後場受付」の時間帯（５）＝１２：０５〜１２：３０と、「後場」の時間帯（６）＝１２：３０〜１５：３０と、「受付停止」の時間帯（７）＝１５：３０〜１８：００と、「翌日注文」の時間帯（８）＝１８：００〜２７：００とに分割された時間帯である。

なお、１日だけの投入電文の再現ではなく、連続する複数の日の投入電文を再現する場合には、ある日の時間帯（１），（２）…（８）、翌日の時間帯（１），（２）…（８）、さらにその次の日の時間帯（１），（２）…（８）のように、投入電文の分類処理が行われる。従って、例えば、同じ時間帯（１）であっても、日にちが異なっていれば、別々に分類される。

また、分類手段４２は、本実施形態では、図４に示すように、複数の時間帯に分類された投入電文（注文電文、条件付注文発注電文、および通知電文）を、さらに顧客識別情報（口座番号等）を用いて顧客毎にグルーピングし、時間帯に分類され、かつ、顧客毎にグルーピングされた状態で、投入電文を再現電文記憶手段５６に記憶させる処理を実行する。従って、再現電文記憶手段５６には、時間帯（１）については、時間帯（１）の顧客Ａの投入電文のグループ、時間帯（１）の顧客Ｂの投入電文のグループ、時間帯（１）の顧客Ｃの投入電文のグループ、…が記憶されている状態となる。他の時間帯（２）〜（８）についても同様であり、それぞれの時間帯に、顧客Ａ，Ｂ，Ｃ，…のグループがある。そして、時間帯毎で、かつ、顧客毎の各々のグループ内では、同一の時間帯についての同一の顧客の投入電文だけが、記録時刻の順番に従って並べられている状態となる。

このように時間帯に分類し、さらに顧客毎にグルーピングする処理を行うのは、同一の時間帯の投入電文であっても、同一の顧客については、新規注文、訂正、取消の注文電文があり、それらの投入順序が保たれないと、処理結果が異なってしまうので、そのような事態を回避するためである。換言すれば、同一の顧客内での投入電文の投入順序（前後関係）を保ちさえすれば、同一の時間帯内で、異なる顧客間の投入電文の投入順序を崩しても、検証処理には影響は出ないので、顧客単位でのグルーピングを行う。

なお、一般には、先に市場への発注を行った顧客の注文が優先されて約定するので、異なる顧客間の投入電文の投入順序を変えれば、市場での処理は異なるものとなり、異なった処理結果が得られることになる。しかし、本実施形態の検証システム１０は、市場システム１３０の処理を含めて検証を行うわけではなく（そのような検証は、市場の板の状態を再現することになるので、実質的に困難である。）、市場システム１３０の処理は、比較検証対象の注文処理システムの外部で行われる処理に相当する。従って、市場システム１３０の処理結果は、市場システム１３０からの通知電文（投入電文）という形で、検証処理に関わることになり、この通知電文は、本番環境から実際のデータを取得しているので、異なる顧客間の投入電文の投入順序を変えても、検証処理には影響は出ないことになる。

さらに、分類手段４２は、複数の時間帯のそれぞれについて顧客毎に投入電文（注文電文、条件付注文発注電文、および通知電文）をグルーピングする際に、本番環境下の記録時刻が同時刻になっている投入電文については、注文電文、条件付注文発注電文、通知電文の順で予め定められた優先順位に従って、この優先順位の高い投入電文から順番にテスト環境下の新システムに対して投入されるように投入電文を並べる処理を実行する。

このように投入電文の入力経路に優先順位を付けるのは、記録時刻が同時刻になっていたとしても、本番環境における実際の処理では投入に時間差がある場合があり、この場合に、実際の投入順序が保たれないと、処理結果が異なってしまうことがあるので、そのような事態を回避するためである。例えば、市場接続システム１２０の発注キューでの滞留もなく、市場システム１３０からの返信も円滑に行われると、記録時刻の最小刻みに満たない時間差で、複数の入力経路からの投入が行われることがあり得る。

具体的には、注文電文と条件付注文発注電文との順序関係では、例えば、実際には、条件付注文である新規注文の注文電文の投入の後に、条件付注文発注電文の投入が行われるところ、それらの順序が逆転し、顧客から条件付注文の新規注文が出ていないのに、条件成否監視サーバ１００から条件付注文の条件成立に伴う市場への発注指令が出るという事態があり得るので、そのような事態を回避するためである。

また、注文電文と通知電文との順序関係では、例えば、実際には、新規注文の注文電文の投入の後に、注文受付の通知電文の投入や、約定の通知電文の投入が行われるところ、それらの順序が逆転し、顧客から新規注文が出ていないのに、市場から注文受付の通知や、約定の通知があるという事態があり得るので、そのような事態を回避するためである。

さらに、条件付注文発注電文と通知電文との順序関係では、例えば、実際には、条件付注文発注電文の投入の後に、注文受付の通知電文の投入や、約定の通知電文の投入が行われるところ、それらの順序が逆転し、条件成否監視サーバ１００から条件付注文の条件成立に伴う市場への発注指令が出ていないのに、市場から注文受付の通知や、約定の通知があるという事態があり得るので、そのような事態を回避するためである。

投入手段４３は、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態のテスト環境下の新システム（図３参照）に対し、再現電文記憶手段５６に記憶された分類後の投入電文のうち、新システムに設定した仮想の時刻に対応する時間帯の投入電文を、通信回線を介して投入する処理を、複数の時間帯のそれぞれについて実行するものである。なお、新システムのシステム時刻を、仮想の時刻に設定する処理は、手動で行ってもよいが、本実施形態では、投入手段４３により自動設定する。

より詳細には、投入手段４３は、図５に示すように、テスト環境下の新システム（図３参照）に対し、複数の時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定するための仮想の時刻の設定指令を、通信回線を介して送信した後、当該仮想の時刻に対応する時間帯の投入電文を、通信回線を介して新システムに投入する処理を実行する。この際、各時間帯の投入電文は、顧客毎にグルーピングされているので、投入手段４３は、顧客毎にグルーピングされた投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していく処理を実行する。そして、投入手段４３は、このような仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを、複数の時間帯について交互に繰り返す。

具体的には、投入手段４３は、図５に示すように、親ドライバと、顧客毎のドライバ（顧客Ａ用のドライバ、顧客Ｂ用のドライバ、顧客Ｃ用のドライバ、…）とにより構成されている。

親ドライバは、新システムである注文処理システムを構成する注文受付システム８０および注文管理システム７０（図３参照）のそれぞれに対し、時間帯（１）に対応する仮想の時刻６：００（時間帯（１）の開始時刻）の設定指令を、通信回線を介して送信した後に、顧客毎のドライバに対し、当該仮想の時刻６：００に対応する時間帯（１）の各顧客の投入電文のグループの投入指令を出す処理を実行する。そして、他の時間帯（２）〜（８）についても、このような新システムに対する仮想の時刻の設定指令の送信処理と、顧客毎のドライバに対する投入指令の処理とを繰り返すようになっている。

顧客毎のドライバは、親ドライバから時間帯（１）の投入電文の投入指令を受けたときに、各顧客の時間帯（１）の投入電文のグループを、通信回線を介して新システムに投入する処理を実行する。そして、他の時間帯（２）〜（８）についても同様に、親ドライバからの投入指令を受けたときに、指令に係る時間帯についての各顧客の投入電文のグループを、通信回線を介して新システムに投入する処理を実行する。

また、投入手段４３は、再現電文記憶手段５６に記憶された投入電文を投入する処理を実行するが、そのうちの通知電文の投入については、再現電文記憶手段５６において注文番号についての本番環境の番号とテスト環境の番号との関連付けの更新処理が行われた後でないと、投入処理を実行しない。すなわち、投入手段４３は、通知電文を新システム（図３参照）に投入する際には、本番環境で自動付与された注文番号を含む通知電文のままではなく、テスト環境で自動付与された注文番号を含む通知電文を投入する。なお、再現電文記憶手段５６に記憶された通知電文に関する情報の更新処理（注文番号についての本番環境の番号とテスト環境の番号との関連付け情報の追加処理）は、後述するように、市場用スタブ４５により実行される。

さらに、投入手段４３は、新旧システムで投入電文の構成（形式または定義）に相違がある場合には、投入用差分記憶手段５７に記憶された投入電文の形式または定義の差分情報を用いて、再現電文記憶手段５６に記憶された分類後の投入電文を、新システム用の形式または定義に変換してから、新システムに投入する処理を実行する。

条件成否監視サーバ用スタブ４４は、条件成否監視サーバ１００（図２参照）の代用の処理を行うものであり、注文受付システム８０から通信回線を介して送信されてくる条件付注文電文を受信する処理を実行する。

市場用スタブ４５は、市場システム１３０（図２参照）の代用の処理を行うものであるが、注文番号について本番環境の番号とテスト環境の番号とを関連付ける処理も実行する。すなわち、注文管理システム７０は、市場へ発注電文を送信する際に、注文番号を自動付与して送信するが、テスト環境下の注文管理システム７０は、再現する発注電文（応答電文）に対し、本番環境下の注文管理システム７０と同じ注文番号を付与しないので、市場用スタブ４５は、注文管理システム７０から、テスト環境で付与された注文番号を含む発注電文を受信することになる。この際、市場用スタブ４５は、受信した発注電文について、注文番号以外の情報（顧客識別情報、銘柄、数量、単価等）から、いずれの注文の発注電文であるかを特定する処理を実行し、特定した注文についての本番環境の注文番号と、受信した発注電文に含まれるテスト環境の注文番号との関連付け情報を、再現電文記憶手段５６に記憶させる。これにより、再現電文記憶手段５６に記憶された通知電文は、本番環境から取得しているので、本番環境で付与された注文番号を含む通知電文であるが、テスト環境で付与された注文番号との関連付け情報を追加されることで、投入手段４３がテスト環境の注文番号を含む通知電文を作成し、新システムに投入することが可能となる。

また、市場用スタブ４５は、上記の関連付けを行った後に、受信した発注電文（テスト環境の注文番号を含む）を、発注電文（本番環境の注文番号を含む）に変換し、テスト応答電文記憶手段５４に記憶させる処理も実行する。なお、テスト応答電文記憶手段５４への発注電文（本番環境の注文番号を含む）の格納処理は、テスト応答電文取得手段３１により、発注ログ記憶手段７４に記憶された発注電文（テスト環境の注文番号を含む）のログ情報を変換することにより行ってもよい。

注文データ検証手段４６は、業務終了時点本番データ記憶手段５３に記憶された旧システム（図２参照）の注文データおよび発注データと、業務終了時点テストデータ記憶手段５５に記憶された新システム（図３参照）の注文データおよび発注データとを比較することにより、新旧システムの動作が同じか否かを確認する検証処理を実行するものである。この際、注文データ検証手段４６は、注文データおよび発注データの構成（形式または定義）が新旧システムで相違する場合には、注文データ検証用差分記憶手段５８に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。

応答電文検証手段４７は、本番応答電文記憶手段５１に記憶された旧システム（図２参照）の応答電文（注文応答電文、条件付注文電文、発注電文）と、テスト応答電文記憶手段５４に記憶された新システム（図３参照）の応答電文（注文応答電文、条件付注文電文、発注電文）とを比較することにより、新旧システムの動作が同じか否かを確認する検証処理を実行するものである。この際、応答電文検証手段４７は、応答電文の構成（形式または定義）が新旧システムで相違する場合には、応答電文検証用差分記憶手段５９に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。

本番投入電文記憶手段５０は、本番環境下の旧システム（図２参照）から取得した投入電文（注文電文、条件付注文発注電文、通知電文）のログ情報（本番環境下での各電文の記録時刻を含む。）を記憶するものである。通知電文は、本番環境から取得しているので、本番環境で付与された注文番号を含んでいる。

本番応答電文記憶手段５１は、本番環境下の旧システム（図２参照）から取得した応答電文（注文応答電文、条件付注文電文、発注電文）のログ情報（本番環境下での各電文の記録時刻を含む。）を記憶するものである。発注電文は、本番環境から取得しているので、本番環境で付与された注文番号を含んでいる。

業務開始時点本番データ記憶手段５２は、本番環境下の旧システム（図２参照）の業務開始時点における各種マスタ情報（顧客情報等）、注文データ記憶手段６４に記憶された注文データ（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。）、および発注データ記憶手段７３に記憶された発注データ（注文データと同様な内容）を記憶するものである。

業務終了時点本番データ記憶手段５３は、本番環境下の旧システム（図２参照）の業務終了時点における注文データ記憶手段６４に記憶された注文データ（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。）、および発注データ記憶手段７３に記憶された発注データ（注文データと同様な内容）を記憶するものである。

テスト応答電文記憶手段５４は、テスト環境下の新システム（図３参照）から取得した応答電文（注文応答電文、条件付注文電文、発注電文）のログ情報を記憶するものである。但し、テスト環境下で作成された発注電文には、注文管理システム７０により自動付与されたテスト環境の注文番号が含まれているが、本実施形態では、応答電文検証手段４７による新旧システムの応答電文の比較検証処理を行うための準備として、市場用スタブ４５によりテスト環境の番号から本番環境の番号への変換を行った後の注文番号を含む発注電文が、テスト応答電文記憶手段５４に記憶されている。

なお、テスト応答電文記憶手段５４にテスト環境の注文番号を含む発注電文を記憶しておき、新旧システムの応答電文の比較検証を行う際に、応答電文検証手段４７により、再現電文記憶手段５６に記憶された関連付け情報を用いてテスト環境の番号から本番環境の番号への注文番号の変換を行うようにしてもよい。また、テスト環境下の新システムの発注ログ記憶手段７４（図３参照）には、テスト環境の注文番号を含む発注電文のログ情報が記憶されているので、これをテスト応答電文取得手段３１により取得し、再現電文記憶手段５６に記憶された関連付け情報を用いてテスト環境の番号から本番環境の番号への注文番号の変換を行ってからテスト応答電文記憶手段５４に記憶させてもよく、あるいは、応答電文検証手段４７により比較検証の際に注文番号の変換処理を行うことを前提として、テスト応答電文取得手段３１により、発注ログ記憶手段７４（図３参照）に記憶された発注電文（テスト環境の注文番号を含む）のログ情報を取得し、注文番号の変換処理を行うことなくテスト応答電文記憶手段５４に記憶させてもよい。

業務終了時点テストデータ記憶手段５５は、テスト環境下の新システム（図３参照）の業務終了時点における注文データ記憶手段８４に記憶された注文データ（顧客識別情報、注文番号、銘柄、売買区分、数量、単価、市場、注文状況を示すステータス等を含む。）、および発注データ記憶手段７３に記憶された発注データ（注文データと同様な内容）を記憶するものである。

再現電文記憶手段５６は、図４に示すように、分類手段４２により時間帯毎に分類され、かつ、顧客毎にグルーピングされた状態の投入電文（注文電文、条件付注文発注電文、通知電文）を記憶するものである。具体的には、再現電文記憶手段５６には、時間帯（１）の投入電文として、時間帯（１）の顧客Ａの投入電文のグループ、時間帯（１）の顧客Ｂの投入電文のグループ、時間帯（１）の顧客Ｃの投入電文のグループ、…が記憶され、時間帯（２）の投入電文として、時間帯（２）の顧客Ａの投入電文のグループ、時間帯（２）の顧客Ｂの投入電文のグループ、時間帯（２）の顧客Ｃの投入電文のグループ、…が記憶され、時間帯（３）〜（７）も同様であり、そして、時間帯（８）の投入電文として、時間帯（８）の顧客Ａの投入電文のグループ、時間帯（８）の顧客Ｂの投入電文のグループ、時間帯（８）の顧客Ｃの投入電文のグループ、…が記憶されている。

投入用差分記憶手段５７は、システム更改に伴う新システムと旧システムとの投入電文の構成（形式または定義）の差分情報を記憶するものである。投入電文の構成（形式または定義）の差分情報とは、例えば、市場について、旧システムで「１＝東京」、「２＝大阪」となっていたのに対し、新システムでは「１＝大阪」、「２＝東京」となる場合等である。

注文データ検証用差分記憶手段５８は、システム更改に伴う新システムと旧システムとの注文データや発注データのデータ保有管理構成（形式または定義）の差分情報を記憶するものである。ここでの差分情報は、システム内で保有管理されるデータベースやファイルの構成の差分情報であり、例えば、注文状況について、旧システムで「１＝注文中」、「２＝約定済」となっていたのに対し、新システムでは「１＝約定済」、「２＝注文中」となる場合等である。

応答電文検証用差分記憶手段５９は、システム更改に伴う新システムと旧システムとの応答電文の構成（形式または定義）の差分情報を記憶するものである。応答電文の構成（形式または定義）の差分情報は、投入電文の場合の差分情報と同様である。

＜検証システム１０による検証処理の流れ：図６＞

このような本実施形態においては、以下のようにして検証システム１０により、検証処理が行われる。

図６において、先ず、本番環境情報収集手段２０により、本番環境下の旧システムである注文処理システム（図２の注文受付システム６０および注文管理システム７０）から、検証処理に必要な各種の情報を収集する（ステップＳ１）。

具体的には、本番投入電文取得手段２１により、本番環境下の旧システム（図２参照）の注文ログ記憶手段６５に記憶された注文電文（投入電文）のログ情報、条件付注文発注ログ記憶手段６８に記憶された条件付注文発注電文（投入電文）のログ情報、および通知ログ記憶手段７５に記憶された通知電文（投入電文）のログ情報を取得し、取得した各ログ情報（電文データの記録時刻を含む。）を、本番投入電文記憶手段５０に記憶させる。

また、本番応答電文取得手段２２により、本番環境下の旧システム（図２参照）の注文応答ログ記憶手段６６に記憶された注文応答電文（応答電文）のログ情報、条件付注文ログ記憶手段６７に記憶された条件付注文電文（応答電文）のログ情報、および発注ログ記憶手段７４に記憶された発注電文（応答電文）のログ情報を取得し、取得した各ログ情報（電文データの記録時刻を含む。）を、本番応答電文記憶手段５１に記憶させる。

さらに、業務開始時点本番データ取得手段２３により、本番環境下の旧システム（図２参照）の業務開始時点における各種マスタ記憶手段６３に記憶された各種マスタ情報（顧客情報等）、注文データ記憶手段６４に記憶された注文データ、および発注データ記憶手段７３に記憶された発注データを取得し、取得したデータを、業務開始時点本番データ記憶手段５２に記憶させる。

また、業務終了時点本番データ取得手段２４により、本番環境下の旧システム（図２参照）の業務終了時点における注文データ記憶手段６４に記憶された注文データ、および発注データ記憶手段７３に記憶された発注データを取得し、取得したデータを、業務終了時点本番データ記憶手段５３に記憶させる。

次に、本番データ反映手段４０により、テスト環境下の新システム（図３参照）に対し、業務開始時点における本番環境のデータを反映させることにより、テスト環境下の新システムにおいて本番環境の業務開始時点の状況を再現する処理を実行する（図６のステップＳ２）。

具体的には、本番データ反映手段４０により、業務開始時点本番データ記憶手段５２に記憶された各種マスタ情報（顧客情報等）、注文データ、および発注データを、テスト環境下の新システムである注文処理システム（図３の注文受付システム８０および注文管理システム７０）における各種マスタ記憶手段８３、注文データ記憶手段８４、および発注データ記憶手段７３にそれぞれ格納する。

続いて、テスト環境下の新システム（図３参照）で再現する投入電文（注文電文、条件付注文発注電文、および通知電文）の準備処理を実行する（図６のステップＳ３）。

具体的には、先ず、マスキング手段４１により、本番投入電文記憶手段５０に記憶された投入電文（注文電文、条件付注文発注電文、および通知電文）のログ情報の中に、暗証番号等の個人情報が含まれている場合には、その個人情報を代替情報に置き換える処理を実行する。

それから、分類手段４２により、図４に示すように、マスキング手段４１による処理を行った後の複数の入力経路の投入電文（注文電文、条件付注文発注電文、および通知電文）を、記録時刻を用いて各投入電文の投入順序の通りに並べて統合し、統合した複数の入力経路の投入電文を、比較検証対象のシステム（本実施形態では、注文処理システム）の挙動が切り替わる複数の時間帯に合わせて、記録時刻を用いて複数の時間帯に分類し（本実施形態では、一例として、市場システム１３０との送受信を行うために予め定められた８つの時間帯（１）〜（８）に分類し）、さらに顧客識別情報（口座番号等）を用いて顧客毎にグルーピングする。そして、時間帯に分類され、かつ、顧客毎にグルーピングされた状態で、投入電文を再現電文記憶手段５６に記憶させる。

これにより、再現電文記憶手段５６には、時間帯（１）の顧客Ａの投入電文のグループ、時間帯（１）の顧客Ｂの投入電文のグループ、時間帯（１）の顧客Ｃの投入電文のグループ、…、時間帯（８）の顧客Ａの投入電文のグループ、時間帯（８）の顧客Ｂの投入電文のグループ、時間帯（８）の顧客Ｃの投入電文のグループ、…が記憶されている状態となる。

そして、各時間帯の各顧客の投入電文のグループ内（１つ１つのグループ内）では、同一の時間帯についての同一の顧客の投入電文だけが、記録時刻の順番に従って並べられている状態となる。この際、各々のグループ内において、記録時刻について同時刻の投入電文が存在する場合には、分類手段４２により、注文電文、条件付注文発注電文、通知電文の順で予め定められた優先順位に従って、この優先順位の高い投入電文から順番にテスト環境下の新システムに対して投入されるように投入電文を並べる。

図４の例では、時間帯（３）の顧客Ａの投入電文のグループについては、新規注文の注文電文、注文受付の通知電文、訂正の注文電文、訂正完了の通知電文、約定の通知電文という順番で並べられ、この順に新システムに投入されるように再現電文記憶手段５６に記憶されている。ここで、新規注文の注文電文と、注文受付の通知電文とは、記録時刻が同時刻であるが、入力経路の優先順位に従って、新規注文の注文電文が先となっている。また、訂正の注文電文と、訂正完了の通知電文とは、記録時刻が同時刻であるが、入力経路の優先順位に従って、訂正の注文電文が先となっている。

また、時間帯（３）の顧客Ｂの投入電文のグループについては、新規注文の注文電文、注文受付の通知電文、取消の注文電文、取消完了の通知電文という順番で並べられ、この順に新システムに投入されるように再現電文記憶手段５６に記憶されている。

なお、顧客Ｂの新規注文の注文電文は、顧客Ａの訂正の注文電文よりも、記録時刻が先であるが、顧客Ａの投入電文のグループを投入した後に、顧客Ｂの投入電文のグループを投入した場合には、それらの投入順序は逆転することになる。しかし、同一顧客内での投入電文の投入順序が崩れなければ、新システムでの処理内容は変わらないので、検証処理に影響は出ない。

その後、投入手段４３により、図５に示すように、複数の時間帯（１）〜（８）に従ってテスト環境下の新システム（図３参照）のシステム時刻を現実の時刻とは異なる仮想の時刻に設定し、システム時刻を仮想の時刻に設定する処理を行った後に、各時間帯に分類され、かつ、顧客毎にグルーピングされた状態で再現電文記憶手段５６に記憶されている投入電文のうち、新システムに設定した仮想の時刻に対応する時間帯の投入電文を、通信回線を介して新システムに投入する。そして、このような処理を、複数の時間帯（１）〜（８）のそれぞれについて実行する（図６のステップＳ４）。

この際、新旧システムで投入電文の構成（形式または定義）に相違がある場合には、投入用差分記憶手段５７に記憶された投入電文の形式または定義の差分情報を用いて、投入電文を新システム用の形式または定義に変換してから、新システムに投入する。

より詳細には、図５に示すように、投入手段４３の親ドライバにより、新システムである注文処理システムを構成する注文受付システム８０および注文管理システム７０（図３参照）のそれぞれに対し、時間帯（１）に対応する仮想の時刻６：００（本実施形態では、一例として、時間帯（１）の開始時刻としている。）の設定指令を、通信回線を介して送信した後に、投入手段４３の顧客毎のドライバ（顧客Ａ用のドライバ、顧客Ｂ用のドライバ、顧客Ｃ用のドライバ、…）のそれぞれに対し、当該仮想の時刻６：００に対応する時間帯（１）の各顧客の投入電文のグループの投入指令を出す。そして、顧客毎のドライバは、親ドライバから時間帯（１）の投入電文の投入指令を受けたときに、自分の担当する顧客の時間帯（１）の投入電文のグループを、通信回線を介して新システムに投入する。なお、図５では、顧客Ａ，Ｂ，Ｃの順に投入されているが、これらの顧客間の投入順序は任意であり、例えば、逆順で顧客Ｃ，Ｂ，Ａの順に投入してもよく、同一顧客内での投入順序が保たれていれば、異なる顧客間の投入順序については制約はない。

続いて、投入手段４３の親ドライバにより、新システムである注文処理システムを構成する注文受付システム８０および注文管理システム７０（図３参照）のそれぞれに対し、時間帯（２）に対応する仮想の時刻８：００（本実施形態では、一例として、時間帯（２）の開始時刻としている。）の設定指令を、通信回線を介して送信した後に、投入手段４３の顧客毎のドライバ（顧客Ａ用のドライバ、顧客Ｂ用のドライバ、顧客Ｃ用のドライバ、…）のそれぞれに対し、当該仮想の時刻８：００に対応する時間帯（２）の各顧客の投入電文のグループの投入指令を出す。そして、顧客毎のドライバは、親ドライバから時間帯（２）の投入電文の投入指令を受けたときに、自分の担当する顧客の時間帯（２）の投入電文のグループを、通信回線を介して新システムに投入する。

時間帯（３）〜（８）についても同様に、投入手段４３の親ドライバにより、注文受付システム８０および注文管理システム７０（図３参照）のそれぞれに対する仮想の時刻の設定指令の送信処理と、投入手段４３の顧客毎のドライバに対する投入指令の処理とを繰り返す。そして、顧客毎のドライバは、親ドライバから各時間帯の投入電文の投入指令を受けたときに、自分の担当する顧客の当該時間帯（親ドライバからの投入指令に係る時間帯）の投入電文のグループを、通信回線を介して新システムに投入する。

また、投入手段４３は、通知電文の投入については、本番環境から取得した本番環境の注文番号を含む通知電文のままではなく、テスト環境の注文番号を含む通知電文を作成し、新システムに投入するので、その通知電文に係る注文番号について市場用スタブ４５により本番環境の番号とテスト環境の番号との関連付け処理が行われ、再現電文記憶手段５６においてその関連付け情報を追加する更新処理が行われた後に、投入処理を実行する。すなわち、注文電文や条件付注文発注電文（いずれも投入電文）を新システムに投入すると、それらの投入電文に対する応答電文として発注電文（テスト環境下で注文管理システム７０により付与された注文番号を含む。）が作成され、新システムから出力されたその発注電文（テスト環境の注文番号を含む。）を市場用スタブ４５が受信し、市場用スタブ４５により、注文番号についてのテスト環境の番号と本番環境の番号との関連付け処理が行われ、再現電文記憶手段５６にその関連付け情報を追加する更新処理が行われるので、そのタイミングで、投入手段４３により、通知電文（テスト環境の注文番号を含む。）を新システムに投入する。

なお、新システムのシステム時刻として設定される仮想の時刻と、その仮想の時刻を新システムのシステム時刻に設定するタイミングである現実の時刻とは、全く無関係である。例えば、時間帯（３）＝９：００〜１１：３０の開始時刻である９：００を仮想の時刻として新システムのシステム時刻に設定するタイミングは、現実の時刻では何時でもよく、例えば、午後の１３：００等とすることができる。そして、現実の時刻が１３：００のタイミングで、仮想の時刻９：００を設定したとすると、現実の時刻が１３：０５を進行中であれば、新システムのシステム時刻は、９：０５を進行中ということになる。但し、現実の時刻が１３：０５になる前に、時間帯（３）の投入電文の投入処理が終了し、次の時間帯（４）の投入電文の投入処理を開始することができる場合には、新システムのシステム時刻は、大きくずれることになる。例えば、現実の時刻が１３：０４のタイミングで、次の時間帯（４）＝１１：３０〜１２：０５の開始時刻である１１：３０を仮想の時刻として新システムのシステム時刻に設定したとすると、現実の時刻が１３：０５を進行中であれば、新システムのシステム時刻は、１１：３１を進行中ということになる。すなわち、新システムでは、時間帯の切替が行われたので、新システムのシステム時刻は、もはや時間帯（３）の９：０５を進行中ということではなく、次の時間帯（４）の１１：３１を進行中ということになる。このように現実の時刻の進行に対し、新システムのシステム時刻は、時間帯の切替により急速に進行していくので、検証に要する処理時間の短縮を図ることができる。それぞれの時間帯内においては、現実の時刻の進行速度と、新システムのシステム時刻の進行速度とは、当然に同じであるが、新システムは、時間帯の切替が行われることにより、全体的に見れば、みかけ上、進行速度が速くなるという意味である。そして、以上は、時間帯の切替により、新システムのシステム時刻の進行速度を、みかけ上、速くすることができるという観点での説明であるが、これを実現するには、そもそも時間帯の切替を短い時間間隔で繰り返し行うことができることが前提となるので、下記の投入タイミングの圧縮が必須となる。

すなわち、投入手段４３によるテスト環境下での各投入電文の投入処理は、本番環境下でのログへの各投入電文の記録時刻よりも圧縮したタイミングで実行する。例えば、時間帯（３）＝９：００〜１１：３０における本番環境での各投入電文の投入処理は、現実の時刻で記録しているので、当然、２時間半かかっているが、テスト環境では、これを圧縮し、かなり短い時間で各投入電文の投入処理を終了させることができる。例えば、４分以内で時間帯（３）の全ての投入電文の投入処理を終了させることができるとすれば、時間帯（３）＝９：００〜１１：３０の開始時刻である９：００を仮想の時刻として新システムのシステム時刻に設定し、その直後に投入処理を開始したとすると、新システムのシステム時刻が９：０４になったときには、投入処理が終了していることになる。従って、投入タイミングの圧縮により、本番環境下で２時間半かけて投入されていた各投入電文について、テスト環境では、２時間半よりも、かなり短時間で投入処理を終了させることができるので、次の時間帯（４）への早期の切替が可能となり、このような投入タイミングの圧縮および時間帯の切替の繰り返しにより、検証に要する処理時間の短縮を図ることができる。

また、上記のように、投入タイミングの圧縮により、それぞれの時間帯の各投入電文について、かなり短時間で投入処理を終了させることができるので、新システムのシステム時刻として設定する仮想の時刻は、それぞれの時間帯の開始時刻である必要はない。例えば、４分以内で時間帯（３）の全ての投入電文の投入処理を終了させることができるとすれば、時間帯（３）＝９：００〜１１：３０の開始時刻である９：００ではなく、例えば１０：００を仮想の時刻として新システムのシステム時刻に設定してもよく、その場合でも、新システムのシステム時刻が１０：０４になったときには、時間帯（３）の全ての投入電文の投入処理が終了していることになり、すべて時間帯（３）の範囲内での投入処理となるので、システムの振る舞いは、開始時刻である９：００を仮想の時刻として設定した場合と同じである。

さらに、上記のように、投入タイミングの圧縮が行われるので、たとえそれぞれの時間帯の開始時刻を新システムのシステム時刻に設定して投入を開始したとしても、本番環境での各投入電文の投入の記録時刻（現実の時刻）と、テスト環境での各投入電文の投入時刻（新システムのシステム時刻、すなわち新システムで進行している仮想の時刻）とは一致しない。例えば、時間帯（３）の場合には、本番環境で丁度９：００（現実の時刻）に投入された投入電文については、テスト環境でも、丁度９：００（新システムのシステム時刻）に投入されることになるかもしれないが、それ以外の時刻に投入された投入電文については、一致しない。なお、ここでは、本番環境での記録時刻（現実の時刻）が、テスト環境での新システムのシステム時刻（仮想の時刻）による投入時刻と一致しないという説明をしており、テスト環境における現実の時刻が、これらとは全く無関係である（何時でもよい）ことは、前述した通りである。

そして、投入処理が完了した後に、テスト環境情報収集手段３０により、テスト環境下の新システムである注文処理システム（図３の注文受付システム８０および注文管理システム７０）から、検証処理に必要な各種の情報を収集する（図６のステップＳ５）。

具体的には、テスト応答電文取得手段３１により、テスト環境下の新システム（図３参照）の注文応答ログ記憶手段８６に記憶された注文応答電文（応答電文）のログ情報、および条件付注文ログ記憶手段８７に記憶された条件付注文電文（応答電文）のログ情報を取得し、取得した各ログ情報を、テスト応答電文記憶手段５４に記憶させる。また、図１および図３には、市場用スタブ４５により、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文（本番環境下の番号に変換後の注文番号を含む。）を、テスト応答電文記憶手段５４に記憶させるように図示されているが、テスト応答電文取得手段３１により、発注ログ記憶手段７４に記憶された発注電文（応答電文）のログ情報を取得し、再現電文記憶手段５６に記憶された二つの環境下の番号の関連付け情報を用いて、注文番号をテスト環境下の番号から本番環境下の番号に変換し、発注電文（本番環境下の番号に変換後の注文番号を含む。）を、テスト応答電文記憶手段５４に記憶させてもよい。

また、業務終了時点テストデータ取得手段３２により、テスト環境下の新システム（図３参照）の業務終了時点における注文データ記憶手段８４に記憶された注文データ、および発注データ記憶手段７３に記憶された発注データを取得し、取得したデータを、業務終了時点テストデータ記憶手段５５に記憶させる。

続いて、注文データ検証手段４６および応答電文検証手段４７により、新旧システムの処理結果を比較し、新旧システムの動作が同じか否かを確認する検証処理を実行する（図６のステップＳ６）。

具体的には、注文データ検証手段４６により、業務終了時点本番データ記憶手段５３に記憶された旧システム（図２参照）の注文データおよび発注データと、業務終了時点テストデータ記憶手段５５に記憶された新システム（図３参照）の注文データおよび発注データとを比較することにより、新旧システムの動作が同じか否かを確認する。この際、注文データおよび発注データの構成（形式または定義）が新旧システムで相違する場合には、注文データ検証手段４６により、注文データ検証用差分記憶手段５８に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。

また、応答電文検証手段４７により、本番応答電文記憶手段５１に記憶された旧システム（図２参照）の応答電文（注文応答電文、条件付注文電文、発注電文）と、テスト応答電文記憶手段５４に記憶された新システム（図３参照）の応答電文（注文応答電文、条件付注文電文、発注電文）とを比較することにより、新旧システムの動作が同じか否かを確認する。この際、応答電文の構成（形式または定義）が新旧システムで相違する場合には、応答電文検証手段４７により、応答電文検証用差分記憶手段５９に記憶された差分情報を用いて変換処理を行うことにより形式または定義を統一してから、比較検証処理を実行する。

＜本実施形態の効果＞

このような本実施形態によれば、次のような効果がある。すなわち、検証システム１０は、分類手段４２により、テスト環境下での再現に使用する投入電文を複数の時間帯に分類しておき、投入手段４３により、複数の時間帯のそれぞれについて、テスト環境下の新システムについてのシステム時刻を仮想の時刻に設定した状態で、その仮想の時刻に対応する時間帯の投入電文を新システムに投入する構成とされているので、投入電文の投入タイミング（投入間隔）を圧縮しても、新システムで進行している仮想の時刻で見た場合には、投入電文は、投入すべき時間帯に新システムに投入されていることになるため、新システムにおいて、投入電文に対する適正な挙動（本番環境で実行された処理を再現する挙動）を得ることができる。

このため、１日の再現を１日かけて実施する必要はなく、新システムへの投入電文の投入タイミング（投入間隔）を圧縮することにより、１日の再現を短時間で実行することができ、検証処理の時間短縮を図ることができる。

また、再現したい日が大量にある場合でも、新システムへの投入電文の投入タイミング（投入間隔）の圧縮を、日を超えて行うことにより、テストに要する日数が本番環境と同じ日数分だけ発生してしまうことを回避することができ、検証処理の時間短縮を図ることができる。

また、投入手段４３は、仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する時間帯の投入電文の投入処理とを連動させ、自動的に繰り返す構成とされているので（図５参照）、仮想の時刻の設定指令の送信タイミングや、当該仮想の時刻に対応する時間帯の投入電文の投入開始タイミングの管理を手動で行う場合に比べ、省力化（再現テストの担当者の負荷軽減や、再現テストにかかる要員の削減）を図ることができるとともに、複数の時間帯に跨っての投入電文の投入タイミング（投入間隔）の圧縮を、より一層確実に行うことができ、検証処理の時間短縮を効果的に図ることができる。さらに、再現の自動化により、夜間の再現テストも可能になる。そして、この効果は、同じ日の再現を何回も実施する場合や、複数の日（本番環境下における複数の日）の再現を実施する場合には、より顕著に得ることができる。

さらに、分類手段４２は、複数の入力経路の各投入電文を、時間帯で分類し、かつ、顧客毎にグルーピングする構成とされ（図４参照）、投入手段４３は、各時間帯に分類され、かつ、顧客毎にグルーピングされた状態の投入電文を、同一顧客内の投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していくので（図５参照）、本番環境を適正に再現することができる。すなわち、注文処理システムでは、投入電文として、新規注文、注文の訂正、および注文の取消のケースを含む注文電文と、市場システム１３０からの通知電文とがあるので、投入電文を時間帯で分類し、かつ、システム時刻への仮想の時刻の設定を行ったとしても、同一顧客内の投入電文の順序が本番環境の通りに保たれないと、新システムで所望の挙動（本番環境での処理を再現する挙動）を得られないことがあるが、このような問題の発生を回避することができる。例えば、本番環境で、注文の訂正があった後に、約定していた場合に、テスト環境で、訂正の注文電文と約定の通知電文との投入順序が入れ替われば、注文の訂正がないのに、訂正された状態での約定通知を受けることになってしまうが、このような事態を回避することができる。

そして、分類手段４２は、複数の入力経路についての記録時刻が同時刻になったときに、予め定められた入力経路の優先順位に従って各投入電文を並べる構成とされているので、本番環境で生じた状況を正しく再現することができ、新システムで所望の挙動（本番環境での処理を正しく再現する挙動）を得ることができる。すなわち、複数の入力経路についての本番環境下の記録時刻が同じ時刻になっていたとしても、本番環境における実際の処理には時間差があり、順番がある場合があるので、それらの処理の順序が逆転してしまうと、エラーが発生する等、新システムで所望の挙動（本番環境での処理を再現する挙動）を得られないことがあるが、このような問題の発生を回避することができる。

また、検証システム１０は、投入用差分記憶手段５７を備えているので、投入手段４３は、この投入用差分記憶手段５７に記憶された投入電文の形式または定義の差分情報を用いて、再現電文記憶手段５６に記憶された投入電文を、新システム用の形式または定義に変換してから新システムに投入することができる。このため、新旧システムの投入電文の形式または定義に差分があるときであっても、本番環境から取得した投入電文を用いて、テスト環境下の新システムに投入する投入電文を自動的に作成することができるので、検証処理の準備作業を容易に行うことができ、省力化を図ることができる。

さらに、検証システム１０は、注文データ検証用差分記憶手段５８および応答電文検証用差分記憶手段５９を備えているので、テスト環境下で、本番環境を再現する投入電文の投入処理を終了した後に、注文データ検証手段４６および応答電文検証手段４７により、注文データや発注データ、および応答電文について、新旧システムの処理結果を比較する検証処理を行う段階でも、これらの注文データや発注データ、および応答電文について、新旧システム間で、形式または定義に差分があれば、その差分を考慮して自動変換を行ってから比較検証処理を実行することができる。このため、比較検証の段階でも、検証作業を容易に行うことができ、省力化を図ることができる。

＜変形の形態＞

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

例えば、前記実施形態では、検証システム１０による比較検証対象が、一例として、株式の注文処理システムとされていたが、本発明の検証システムによる比較検証対象は、株式の注文処理システムに限定されるものではなく、株式以外の金融商品の注文処理システムであってもよく、さらには、市場への発注を行う注文処理システムに限定されるものでもなく、要するに、時間帯によりシステムの挙動が切り替わるシステムであれば、本発明の適用対象となり得る。但し、市場が関与し、それにより複数の入力経路が形成されるシステムであれば、本発明の効果が、より一層顕著に得られる。

また、前記実施形態では、投入手段４３は、新システムのシステム時刻を仮想の時刻に設定するための設定指令の送信処理と、その仮想の時刻に対応する時間帯の各投入電文の投入処理とを連動させ、自動的に繰り返す構成とされていたが（図５参照）、仮想の時刻の設定指令の送信タイミングや、各時間帯の投入電文の投入開始タイミングを、人が管理し、各処理を手動操作で開始させる構成としてもよい。但し、これらの処理を連動させ、自動的に繰り返す構成としておけば、省力化を図ることができるとともに、検証処理の時間短縮を、より一層確実に図ることができる。

以上のように、本発明の検証システムおよびプログラムは、例えば、顧客の注文を受け付けて市場システムへの発注を行う注文処理システムの更改を行う場合等に用いるのに適している。

１０ 検証システム
４２ 分類手段
４３ 投入手段
５０ 本番投入電文記憶手段
５６ 再現電文記憶手段
５７ 投入用差分記憶手段
６０ 旧システムである注文処理システムの一部を構成する注文受付システム
７０ 注文処理システムの一部を構成し、新システムおよび旧システムの双方に共通する部分である注文管理システム
８０ 新システムである注文処理システムの一部を構成する注文受付システム

Claims (6)

1. システム更改の際に新システムの動作をテストするために新システムと旧システムとの処理結果を比較検証する処理を実行する検証システムであって、
   本番環境下の旧システムから取得した投入電文を、本番環境下の記録時刻とともに記憶する本番投入電文記憶手段と、
   新システムおよび旧システムの双方に共通してシステムの挙動が切り替わる複数の時間帯に合わせて、前記本番投入電文記憶手段に記憶された前記投入電文を、前記記録時刻を用いて複数の前記時間帯に分類する処理を実行する分類手段と、
   この分類手段により分類された前記投入電文を、分類された状態で記憶する再現電文記憶手段と、
   複数の前記時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定した状態のテスト環境下の新システムに対し、前記再現電文記憶手段に記憶された分類後の前記投入電文のうち、新システムに設定した前記仮想の時刻に対応する前記時間帯の前記投入電文を通信回線を介して投入する処理を、複数の前記時間帯のそれぞれについて実行する投入手段と
   を備えたことを特徴とする検証システム。
2. 前記投入手段は、
   テスト環境下の新システムに対し、複数の前記時間帯に従ってシステム時刻を現実の時刻とは異なる仮想の時刻に設定するための仮想の時刻の設定指令を、通信回線を介して送信した後、当該仮想の時刻に対応する前記時間帯の前記投入電文を、通信回線を介して新システムに投入する処理を実行し、この際、前記仮想の時刻の設定指令の送信処理と、当該仮想の時刻に対応する前記時間帯の前記投入電文の投入処理とを、複数の前記時間帯について交互に繰り返す構成とされている
   ことを特徴とする請求項１に記載の検証システム。
3. 前記システム更改の対象となる新システムおよび旧システムは、顧客の注文を受け付けて市場システムへの発注を行う注文処理システムであり、
   前記時間帯は、前記市場システムとの電文の送受信を行うために定められた時間帯であり、
   前記投入電文には、顧客またはその入力代行者により入力された新規注文、注文の訂正、および注文の取消のケースを含む注文電文と、前記市場システムからの通知電文とが含まれ、
   前記分類手段は、
   複数の前記時間帯に分類された前記投入電文を、さらに顧客毎にグルーピングし、前記時間帯に分類され、かつ、顧客毎にグルーピングされた状態で前記投入電文を前記再現電文記憶手段に記憶させる処理を実行する構成とされ、
   前記投入手段は、
   複数の前記時間帯のそれぞれについて、顧客毎にグルーピングされた前記投入電文を、同一顧客内の前記投入電文の順序を保ったまま顧客毎のグループ単位で新システムに投入していく処理を実行する構成とされている
   ことを特徴とする請求項１または２に記載の検証システム。
4. 前記投入電文には、前記注文電文および前記通知電文に加え、前記市場システムへの発注のタイミングを監視する必要のある条件付注文について条件が満たされた場合に投入される条件付注文発注電文が含まれ、
   前記分類手段は、
   複数の前記時間帯のそれぞれについて顧客毎に前記投入電文をグルーピングする際に、本番環境下の記録時刻が同時刻になっている前記投入電文については、前記注文電文、前記条件付注文発注電文、前記通知電文の順で予め定められた優先順位に従って、この優先順位の高い前記投入電文から順番にテスト環境下の新システムに対して投入されるように前記投入電文を並べる構成とされている
   ことを特徴とする請求項３に記載の検証システム。
5. システム更改に伴う新システムと旧システムとの前記投入電文の形式または定義の差分を記憶する投入用差分記憶手段を備え、
   前記投入手段は、
   前記投入用差分記憶手段に記憶された前記投入電文の形式または定義の差分を用いて、前記再現電文記憶手段に記憶された分類後の前記投入電文を、新システム用の形式または定義に変換してから新システムに投入する処理を実行する構成とされている
   ことを特徴とする請求項１〜４のいずれかに記載の検証システム。
6. 請求項１〜５のいずれかに記載の検証システムとして、コンピュータを機能させるためのプログラム。

Images