JP6744446B1 - シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム - Google Patents

シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム Download PDF

Info

Publication number
JP6744446B1
JP6744446B1 JP2019063251A JP2019063251A JP6744446B1 JP 6744446 B1 JP6744446 B1 JP 6744446B1 JP 2019063251 A JP2019063251 A JP 2019063251A JP 2019063251 A JP2019063251 A JP 2019063251A JP 6744446 B1 JP6744446 B1 JP 6744446B1
Authority
JP
Japan
Prior art keywords
scenario
control unit
order
storage unit
management system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019063251A
Other languages
English (en)
Other versions
JP2020166313A (ja
Inventor
正志 岩田
正志 岩田
工 森脇
工 森脇
清貴 田内
清貴 田内
雄太 菊池
雄太 菊池
薫 中里
薫 中里
寛志 佐藤
寛志 佐藤
藤野 直樹
直樹 藤野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mizuho DL Financial Technology Co Ltd
Mizuho Information and Research Institute Inc
Mizuho Bank Ltd
Original Assignee
Mizuho DL Financial Technology Co Ltd
Mizuho Information and Research Institute Inc
Mizuho Bank Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mizuho DL Financial Technology Co Ltd, Mizuho Information and Research Institute Inc, Mizuho Bank Ltd filed Critical Mizuho DL Financial Technology Co Ltd
Priority to JP2019063251A priority Critical patent/JP6744446B1/ja
Application granted granted Critical
Publication of JP6744446B1 publication Critical patent/JP6744446B1/ja
Publication of JP2020166313A publication Critical patent/JP2020166313A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】階層化された指示からなるシナリオを効率的に管理するためのシナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラムを提供する。【解決手段】リーブオーダー管理システム20は、各指示の処理内容を記憶するシナリオ情報記憶部22と、前記各指示の関連性に関するリンク情報を格納するリンク情報記憶部23と、ユーザ端末25に接続された制御部21を備える。制御部21は、シナリオ情報記憶部22に記録された上位指示の処理内容を監視エリアに登録し、監視エリアの上位指示の処理内容を実行した場合、リンク情報記憶部23のリンク情報を用いて、関連性がある下位指示の処理内容を特定し、監視エリアに追加する。【選択図】図1

Description

本発明は、階層化された指示からなるシナリオを管理するシナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラムに関する。
オプション取引業務等においては、状況に応じた処理を実行するための指示を含めたシナリオを、予め準備しておくことがある。この場合、シナリオを用いて、状況に応じた指示による処理が実行されて、所定の目的を達成することができる。例えば、ダイナミックヘッジ商品は、想定シナリオにより組成された為替予約取引(リーブオーダー形式)の反復売買を繰り返すことにより、オプション取引と同等の効果を実現する。このダイナミックヘッジ商品においては、例えば、現在の為替レートに対して、所定金額を上下させた金額を設定したオーダーからなる複数階層のシナリオを想定し、それぞれのオーダーについて売るべき(或いは買うべき)金額を指定しておく。このように、取引すべき金額や価格を事前に指定した上で金融機関に対して依頼するオーダー(為替オーダー)を「リーブオーダー」という。
このような階層構造からなるリーブオーダーを的確に実行するための技術が検討されている(例えば、特許文献1参照)。この文献に記載されたリーブオーダー管理システムは、二つの選択的なオーダーの内、一方のオーダーを実行した場合に他方のオーダーを取り消し、実行したオーダーについて更に二つの選択的な配下のオーダーを定めるシナリオ情報に基づいてリーブオーダーを実行する。
特開2007−272560号公報
上述したように、多様な状況に応じた処理を行なうための指示を準備することにより、状況に応じて的確に対応することができる。しかしながら、予め準備する指示が多くなると管理負担が大きくなる。例えば、市場の変動に応じて、予め多くの階層からなるリーブオーダーを準備すると、記憶容量が大きくなり、リソース負荷が大きくなる。
上記課題を解決するためのシナリオ管理システムは、各指示の処理内容を記憶する処理情報記憶部と、前記各指示の関連性に関するリンク情報を格納するリンク情報記憶部と、上位指示に対して、想定条件に応じて選択的な下位指示を定めた階層化された監視シナリオを管理する制御部を備える。前記制御部が、前記処理情報記憶部に記録された前記上位指示の処理内容を監視エリアに登録し、前記監視エリアの上位指示の処理内容を実行した場合、前記リンク情報記憶部のリンク情報を用いて、関連性がある下位指示の処理内容を特定し、前記監視エリアに追加する。
本発明によれば、階層化された指示からなるシナリオを効率的に管理することができる。
本実施形態のシステム概略図。 本実施形態のハードウェア構成の説明図。 本実施形態の階層構成の説明図。 本実施形態のリンク情報の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図であって、(a)は初期状態、(b)は第6階層を実行した状態、(c)は第7階層を実行した状態の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。 他の実施形態の処理手順の説明図。
以下、図1〜図7を用いて、シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラムを具体化した一実施形態を説明する。
図1に示すように、本実施形態では、ダイナミックヘッジシステム10、リーブオーダー管理システム20を用いる。このリーブオーダー管理システム20には、ユーザ端末25が接続される。
(ハードウェア構成)
図2を用いて、ダイナミックヘッジシステム10、リーブオーダー管理システム20、ユーザ端末25を構成する情報処理装置H10のハードウェア構成を説明する。情報処理装置H10は、通信装置H11、入力装置H12、表示装置H13、記憶部H14、プロセッサH15を備える。なお、このハードウェア構成は一例であり、他のハードウェアにより実現することも可能である。
通信装置H11は、他の装置との間で通信経路を確立して、データの送受信を実行するインターフェースであり、例えばネットワークインターフェースカードや無線インターフェース等である。
入力装置H12は、操作者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。
表示装置H13は、各種情報を表示するディスプレイ等である。
記憶部H14は、ダイナミックヘッジシステム10、リーブオーダー管理システム20の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部H14の一例としては、ROM、RAM、ハードディスク等がある。
プロセッサH15は、記憶部H14に記憶されるプログラムやデータを用いて、ダイナミックヘッジシステム10、リーブオーダー管理システム20における各処理を制御する。
プロセッサH15の一例としては、例えばCPUやMPU等がある。このプロセッサH15は、ROM等に記憶されるプログラムをRAMに展開して、各サービスのための各種プロセスを実行する。
(リーブオーダーの管理)
次に、ヘッジ取引に用いるリーブオーダーの管理を説明する。
図3に示すように、特許文献1に記載されている技術と同様に、各リーブオーダーLO1は、2つの選択的なオーダーのそれぞれに対して、選択的な2つのオーダーが関連付けられることにより階層化されている。本実施形態では、リーブオーダーLO1を、監視階層(3階層)、プール階層(6階層)、圧縮階層(6階層)からなる上位階層〜下位階層に至る15階層で管理する。監視階層は、ユーザ端末25の出力部に出力され、担当者により選択される階層である。一方、プール階層、圧縮階層は、ユーザ端末25の出力部に出力されることなく、監視階層のリーブオーダーが利用された場合に準備される階層である。
各リーブオーダーLO1の識別番号は、階層構造において、以下のルールにより割り当てられている。
(A)最上段の左側を1とし、最上段の右側を2とする。
(B)下段の最も左側が小さくなるようにして連続して右に番号付けされており、同じ階層のすべてについて番号付けした場合には、その下の階層に移り、同様にして最下層まで番号付けを行なう。
このような15階層のリーブオーダーLO1の各オーダー明細は、オーダー情報テーブル、プール情報テーブル、圧縮テーブルによって管理される。
オーダー情報テーブルは、ヘッジ取引に用いることができる形式で記述され、監視階層(第1階層〜第3階層の3階層)を構成するテーブル(CSVファイル)である。
プール情報テーブルは、プール階層(第4階層〜第9階層の6階層)を構成し、形式的にはオーダー情報テーブルと同じテーブル(CSVファイル)である。
圧縮テーブルは、圧縮階層(第10階層〜第15階層)を構成し、ダイナミックヘッジシステム10によって作成されるファイルであって、オーダー情報テーブルを作成するための元となるデータが書き込まれた圧縮形式で記述されたテーブル(CSVファイル)である。この圧縮テーブルを展開することにより、オーダー情報テーブルを作成することができる。
更に、図4に示すように、各リーブオーダーLO1は、「oco」、「ido」により、相互に関連付けられる。
「oco」は、「one cancel the other」の略であり、一方のオーダーが約定(実行)された場合には、他方のオーダーを取り消した上で、約定されたオーダーと関連付けられた下段の二つのオーダーを選択できるように有効化(発効)する処理を示す。例えば、「1oco2」は、識別番号1の1が約定になった場合には、他方の識別番号2のオーダーを取り消し、識別番号2のオーダーが約定になった場合には、他方の識別番号1のオーダーを取り消すことを示す。
また、「ido」は、「if done」の略であり、オーダーが約定になった場合には、関連付けられたオーダーを発効する処理を示す。例えば、「1ido3,4」は、識別番号1のオーダーが約定になった場合には、識別番号3、4のオーダーを最上階層において、ヘッジ取引に利用できるように発効することを示す。
上記のように、各オーダーは、並列に2つの選択肢と関連付けられており、そして、一方のオーダーが約定(選択)された場合には他方が取り消され、次に約定されたオーダーに対して下段(配下)において関連付けられた2つの選択肢を発効する。
(システム構成)
次に、図1を用いて、ヘッジ取引に用いるシステム構成を説明する。
ダイナミックヘッジシステム10は、現在の各種マーケットレートといった変数を入力値として想定シナリオ(ヘッジ計画)を作成するコンピュータシステムである。ダイナミックヘッジシステム10に、各種マーケットレートといった変数を入力すると、予め定められたアルゴリズムに従って、想定シナリオを計算し作成する。ダイナミックヘッジシステム10では、例えば顧客別にそれぞれ15階層(65534パターン)のリーブオーダーからなるシナリオを作成する。そして、シナリオに含まれるリーブオーダーのそれぞれに1,2,3…,Nの連続する数字からなる識別番号を付与する。
リーブオーダー管理システム20は、ヘッジ取引を実行するコンピュータシステムである。このリーブオーダー管理システム20は、制御部21、シナリオ情報記憶部22、リンク情報記憶部23を備える。このリーブオーダー管理システム20は、現在の為替レートを提供する為替情報システム(外部システム)に接続されている。
制御部21は、ダイナミックヘッジシステム10により生成されたリーブオーダーを管理するとともに、リーブオーダーを用いてヘッジ取引処理を実行する。そして、制御部21は、後述する処理(オーダー管理段階、ヘッジ処理段階等を含む処理)を行なう。このためのシナリオ管理プログラムを実行することにより、制御部21は、オーダー管理部211、ヘッジ処理部212として機能する。
オーダー管理部211は、階層化されたリーブオーダーを管理する処理を実行する。このオーダー管理部211は、リーブオーダーを追加するための残り階層数の確認時期(例えば、営業日毎)に関するデータを保持する。
ヘッジ処理部212は、市場状況に基づいてリーブオーダーを実行する処理を実行する。
リーブオーダー管理システム20に接続されたユーザ端末25は、ヘッジ取引の担当者が用いるコンピュータ端末であり、入力部、出力部を備える。この出力部には、監視階層のリーブオーダーのオーダー明細が出力される。
シナリオ情報記憶部22には、ダイナミックヘッジシステム10により作成されたシナリオ情報が記録される。このシナリオ情報には、ヘッジ取引に用いるリーブオーダーに関するデータが記録される。リーブオーダーの各オーダー明細は、上述したように、階層に応じて、オーダー情報テーブル、プール情報テーブル、圧縮テーブルによって管理される。
オーダー明細には、識別番号、売買フラグ、取引金額、通貨種類、為替レート、指値フラグ、取引先等の各明細項目に関する情報が記録される。
識別番号データ領域には、各リーブオーダーを特定するための識別子に関するデータが記録される。
売買フラグデータ領域には、「売り」又は「買い」を識別するためのフラグが記録される。
取引金額データ領域には、リーブオーダーを実行する場合の取引金額に関するデータが記録される。
通貨種類データ領域には、取引に用いる通貨に関するデータが記録される。
為替レートデータ領域には、リーブオーダーを実行する場合の為替レートに関するデータが記録される。
指値フラグデータ領域には、通貨指値又は逆指値を識別するためのフラグが記録される。
取引先データ領域には、取引先を特定するための識別子に関するデータが記録される。
図3に示すように、シナリオ情報記憶部22は、ワークエリアとプールエリアとを備える。ワークエリアには、上述した監視階層のリーブオーダーLO1のオーダー明細が格納される。一方、プールエリアには、プール階層、圧縮階層のリーブオーダーLO1のオーダー明細が格納される。なお、上位階層のリーブオーダーLO1のオーダー明細の項目情報と、この上位階層に関連付けられた下位階層のオーダー明細の項目情報とが同じ場合には、下位階層のオーダー明細の項目情報を省略しておく。これにより、下位階層のオーダー明細のデータ容量の削減を図ることができる。
リンク情報記憶部23には、シナリオ情報記憶部22に格納されたリーブオーダーの監視シナリオに基づいて作成されたリンク情報が記録される。ここで、リンク情報は、図4に示すように、個々のオーダー明細を相互の関連性を示す情報である。
(定期追加処理)
次に、図5を用いて、定期追加処理を説明する。この処理は、予め定められた確認時期に定期的に実行される。
まず、リーブオーダー管理システム20の制御部21は、残り階層数の確認時期かどうかについての判定処理を実行する(ステップS1−1)。具体的には、制御部21のオーダー管理部211は、システムタイマから現在日時を取得し、残り階層数の確認時期と比較する。
現在日時において残り階層数の確認時期が到来していない場合(ステップS1−1において「NO」の場合)、リーブオーダー管理システム20の制御部21は、定期追加処理を終了する。
一方、現在日時において残り階層数の確認時期が到来している場合(ステップS1−1において「YES」の場合)、リーブオーダー管理システム20の制御部21は、基準数未満かどうかについての判定処理を実行する(ステップS1−2)。具体的には、制御部21のオーダー管理部211は、シナリオ情報記憶部22に記録されているシナリオ情報において、未実行のリーブオーダーの階層数(残り階層数)を算出する。そして、オーダー管理部211は、残り階層数と基準数(本実施形態では15階層)とを比較する。
残り階層数が基準数以上であり、基準数未満でないと判定した場合(ステップS1−2において「NO」の場合)、リーブオーダー管理システム20の制御部21は、定期追加処理を終了する。
一方、残り階層数が基準数未満と判定した場合(ステップS1−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、追加指示処理を実行する(ステップS1−3)。具体的には、制御部21のオーダー管理部211は、残り階層数と基準数との差分を算出する。そして、オーダー管理部211は、ユーザ端末25の出力部に追加指示メッセージを出力する。この追加指示メッセージには、追加すべき階層数(基準数との差分)に関する情報を含める。
追加指示メッセージを確認した担当者は、ダイナミックヘッジシステム10により、追加すべき階層数の圧縮テーブルを生成する。この場合、上位階層のリーブオーダーのオーダー明細の項目情報と同じ下位階層の項目については、オーダー明細の項目情報を省略する。そして、圧縮階層が不足している場合には、生成した圧縮テーブルをシナリオ情報記憶部22のプールエリアに記録する。一方、プール階層で不足している場合には、圧縮テーブルをプール情報テーブルに展開して、シナリオ情報記憶部22のプールエリアに記録する。更に、監視階層においてオーダー明細が不足している場合には、圧縮テーブルからオーダー情報テーブルを生成し、シナリオ情報記憶部22のワークエリアに記録する。そして、各リーブオーダーについてのリンク情報を生成し、リンク情報記憶部23に記録する。
図7(a)に示すように、ワークエリアに監視階層のオーダー情報テーブル(3階層)が記録され、プールエリアにプール階層のプール情報テーブル(6階層)、圧縮階層の圧縮テーブル(6階層)が記録される。
(ヘッジ処理)
次に、図6を用いて、ヘッジ処理を説明する。この処理は、予め定められたヘッジ期間において継続して行なわれる。
まず、リーブオーダー管理システム20の制御部21は、為替レート取得処理を実行する(ステップS2−1)。具体的には、制御部21のヘッジ処理部212は、為替情報システムから直近の為替レートを取得する。
次に、リーブオーダー管理システム20の制御部21は、ヘッジが必要かどうかについての判定処理を実行する(ステップS2−2)。具体的には、制御部21のヘッジ処理部212は、取得した為替レートと、シナリオ情報記憶部22に記録された監視階層のオーダー明細をユーザ端末25の出力部に表示する。担当者は、直近の為替レートとオーダー明細の内容とを比較して、ヘッジが必要と判断した場合には、ユーザ端末25の入力部を用いて、ヘッジ取引のためのリーブオーダーを指定して取引実行を入力する。
取引実行が入力されず、ヘッジが必要でない場合(ステップS2−2において「NO」の場合)、リーブオーダー管理システム20の制御部21は、為替レート取得処理(ステップS2−1)に戻る。
一方、取引実行が入力されてヘッジが必要な場合(ステップS2−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、上位階層を用いてヘッジ取引の実行処理を実行する(ステップS2−3)。具体的には、制御部21のヘッジ処理部212は、選択されたリーブオーダーを用いて、ヘッジ取引を実行する。
次に、リーブオーダー管理システム20の制御部21は、追加下位階層のリーブオーダーの特定処理を実行する(ステップS2−4)。具体的には、制御部21のオーダー管理部211は、リンク情報記憶部23に記録されたリンク情報「ido」を用いて、実行したリーブオーダーに関連付けられた下層のリーブオーダーを特定する。
次に、リーブオーダー管理システム20の制御部21は、7階層目の実行かどうかについての判定処理を実行する(ステップS2−5)。具体的には、制御部21のオーダー管理部211は、実行したリーブオーダーが7階層目かどうかを判定する。
7階層目の実行でないと判定した場合(ステップS2−5において「NO」の場合)、リーブオーダー管理システム20の制御部21は、上位階層エリアに下位階層の追加処理を実行する(ステップS2−6)。具体的には、制御部21のオーダー管理部211は、特定したリーブオーダーを上位階層に引き上げる。例えば、第1階層のリーブオーダーを実行した場合、プール階層の第4階層が監視階層に引き上げられる。この結果、ワークエリアの監視階層には、第2階層〜第4階層が格納される。この場合、オーダー管理部211は、引き上げられるリーブオーダーのオーダー明細において不足する項目情報がある場合には、実行された上位階層のリーブオーダーのオーダー明細に記録された項目情報により補完する(明細化登録処理)。例えば、下位階層のリーブオーダーのオーダー明細に「取引先」に関する項目情報が記録されていない場合には、実行された上位階層のリーブオーダーのオーダー明細に記録された「取引先」情報を、下位階層のリーブオーダーのオーダー明細に「取引先」情報として記録する。
図7(b)に示すように、第1階層〜第6階層のリーブオーダーを、順次、実行した場合、プール階層に記録されていた第7階層〜第9階層が、ワークエリアに監視階層として格納される。
一方、7階層目の実行と判定した場合(ステップS2−5において「YES」の場合)、リーブオーダー管理システム20の制御部21は、圧縮テーブルからの読み込み処理を実行する(ステップS2−7)。具体的には、制御部21のオーダー管理部211は、シナリオ情報記憶部22のプールエリアに格納され、残っている階層の圧縮テーブルを読み込む。
この場合、図7(c)に示すように、プールエリアに格納されていた圧縮階層の中で上位階層である第10階層の圧縮テーブルをオーダー情報テーブルに展開して、ワークエリアに監視階層として格納する。
次に、リーブオーダー管理システム20の制御部21は、不要になった上位階層の削除処理を実行する(ステップS2−8)。具体的には、制御部21のオーダー管理部211は、リンク情報記憶部23に記録されたリンク情報「oco」を用いて、実行したリーブオーダーと同じ階層の他方のオーダー情報テーブル、このオーダー情報テーブルに関連付けられたプール情報テーブル、圧縮テーブルを削除する。
そして、リーブオーダー管理システム20の制御部21は、為替レート取得処理(ステップS2−1)に戻る。
本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態においては、シナリオ情報記憶部22には、ダイナミックヘッジシステム10により作成されたシナリオ情報が記録される。リーブオーダーLO1を、監視階層(3階層)、プール階層(6階層)、圧縮階層(6階層)からなる15階層で管理する。これにより、リーブオーダーを複数階層で準備して、市場状況に応じたヘッジ取引を行なうことができる。更に、下位の圧縮階層では、圧縮テーブルが記録されるので、リソース負荷を軽減することができる。
(2)本実施形態においては、リンク情報記憶部23には、シナリオ情報記憶部22に格納されたシナリオ情報に基づいて作成されたリンク情報が記録される。これにより、リング情報を用いて、リーブオーダーが実行された場合の次のリーブオーダーの発効や不要なリーブオーダーの削除を行なうことができる。
(3)本実施形態においては、残り階層数が基準数未満と判定した場合(ステップS1−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、追加指示処理を実行する(ステップS1−3)。これにより、リーブオーダーの実行により、不足したリーブオーダーの作成を指示することができる。
(4)本実施形態においては、ヘッジが必要と判定された場合(ステップS2−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、上位階層を用いてヘッジ取引の実行処理(ステップS2−3)、追加下位階層のリーブオーダーの特定処理(ステップS2−4)を実行する。これにより、状況に応じたシナリオで、リーブオーダーを特定することができる。
(5)本実施形態においては、7階層目の実行でないと判定した場合(ステップS2−5において「NO」の場合)、リーブオーダー管理システム20の制御部21は、上位階層エリアに下位階層の追加処理を実行する(ステップS2−6)。これにより、新たなリーブオーダーが監視階層に格納され、ヘッジ取引に必要な取引明細を、ユーザ端末25において確認することができる。
(6)本実施形態においては、7階層目の実行と判定した場合(ステップS2−5において「YES」の場合)、リーブオーダー管理システム20の制御部21は、圧縮テーブルから読み込み処理を実行する(ステップS2−7)。これにより、圧縮テーブルを、オーダー情報テーブルに展開することができる。
(7)本実施形態においては、上位階層のリーブオーダーのオーダー明細の項目情報と、下位階層のオーダー明細の項目情報とが同じ場合には、下位階層のオーダー明細の項目情報を省略しておく。そして、下位階層のリーブオーダーのオーダー明細において不足する項目情報がある場合には、上位階層のリーブオーダーのオーダー明細に記録された項目情報により補完する明細化登録処理を実行する。これにより、下位階層において、データ容量の削減を図り、実行可能なオーダー明細を生成することができる。
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、定期追加処理において、残り階層数が基準数未満と判定した場合(ステップS1−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、追加指示処理を実行する(ステップS1−3)。ここで、ダイナミックヘッジシステム10の担当者の出勤予定や市場状況を考慮して、階層数を準備するようにしてもよい。この場合には、リーブオーダー管理システム20は、ダイナミックヘッジシステム10の担当者の出勤予定情報を記録した勤怠管理サーバにアクセスできるようにしておく。更に、オーダー管理部211に、階層数決定テーブル、調整関数を保持させておく。階層数決定テーブルにおいては、出勤日までの期間の長さに応じて、必要階層数を決定するための情報が記録される。例えば、期間日数が長い程、必要階層数を多くする。調整関数においては、市場状況の変動傾向に基づいて、必要階層数を調整するための情報が記録される。例えば、大きな変動が予測される場合には、必要階層数を増やす。
図8を用いて、定期追加処理を説明する。
まず、リーブオーダー管理システム20の制御部21は、休日カレンダに基づいて必要階層数の決定処理を実行する(ステップS3−1)。具体的には、制御部21のオーダー管理部211は、勤怠管理サーバにアクセスし、担当者の出勤予定を取得する。この場合、定期追加処理の実行時期が、担当者の休日に該当する場合には、次の出勤日までの期間を算出する。そして、オーダー管理部211は、階層数決定テーブルを用いて、この期間の長さに応じて必要階層数を決定する。
次に、リーブオーダー管理システム20の制御部21は、直近の市況情報の取得処理を実行する(ステップS3−2)。具体的には、制御部21のオーダー管理部211は、為替情報システムにアクセスし、為替レートの変動状況に関する情報を取得する。
次に、リーブオーダー管理システム20の制御部21は、市況情報に応じて必要階層数の決定処理を実行する(ステップS3−3)。具体的には、制御部21のオーダー管理部211は、変動状況に基づいて、次の定期追加処理までの期間における変動傾向を予測する。そして、オーダー管理部211は、調整関数を用いて、予測した変動傾向に基づいて、必要階層数を調整する。
次に、リーブオーダー管理システム20の制御部21は、現在の階層数は必要階層数未満かどうかについての判定処理を実行する(ステップS3−4)。具体的には、制御部21のオーダー管理部211は、シナリオ情報記憶部22に記録された階層数と、調整した必要階層数とを比較する。
ここで、現在の階層数は必要階層数未満と判定した場合(ステップS3−4において「YES」の場合)、リーブオーダー管理システム20の制御部21は、ステップS1−3と同様に、追加指示処理を実行する(ステップS3−5)。
一方、現在の階層数は必要階層数以上と判定した場合(ステップS3−4において「NO」の場合)、リーブオーダー管理システム20の制御部21は、追加指示処理(ステップS3−5)をスキップして定期追加処理を終了する。これにより、出勤状況や市場状況に応じて、適切な階層数を準備しておくことができる。
更に、図9に示すように、機械学習により、必要階層数を算出するようにしてもよい。この場合には、市況情報、担当者の休日を示すカレンダ、ヘッジ取引において使用された階層数を学習用教師データ501として用いて学習を行なう。この場合、市況情報、カレンダを入力層、ヘッジ取引において使用された階層数を出力層として機械学習を行ない、市況情報、カレンダから必要階層数を予測するモデル(階層数予測モデル)を生成する。そして、定期追加処理において、リーブオーダー管理システム20の制御部21は、予測用データ502として、現在の市況情報、カレンダを用いて、階層数予測モデルに適用して、必要階層数を予測する。そして、この必要階層数を補う追加指示を行なう。
・上記実施形態では、定期追加処理を実行する。これに加えて、状況に応じて、リーブオーダーを追加するようにしてもよい。この場合には、オーダー管理部211に、追加要否を判定するための通知判定数に関するデータを記憶させておく。
次に、図10を用いて、緊急追加処理を説明する。この処理は、取引が行なわれている期間中に実行される。
まず、リーブオーダー管理システム20の制御部21は、プールエリアの残り階層数の特定処理を実行する(ステップS4−1)。具体的には、制御部21のオーダー管理部211は、シナリオ情報記憶部22に記録されているシナリオ情報において、プールエリアのリーブオーダーの階層数(残り階層数)を算出する。
次に、リーブオーダー管理システム20の制御部21は、通知判定数未満かどうかについての判定処理を実行する(ステップS4−2)。具体的には、制御部21のオーダー管理部211は、残り階層数と通知判定数とを比較する。
残り階層数が通知判定数未満でないと判定した場合(ステップS4−2において「NO」の場合)、リーブオーダー管理システム20の制御部21は、所定期間を待機して、プールエリアの残り階層数の特定処理(ステップS4−1)を繰り返す。
一方、残り階層数が通知判定数未満と判定した場合(ステップS4−2において「YES」の場合)、リーブオーダー管理システム20の制御部21は、追加指示処理を実行する(ステップS4−3)。具体的には、制御部21のオーダー管理部211は、残り階層数と基準数との差分を算出する。次に、オーダー管理部211は、ユーザ端末25の出力部に追加指示メッセージを出力する。この追加指示メッセージには、追加すべき階層数(基準数との差分)に関する情報を含める。この場合も、圧縮階層が不足している場合には、この追加指示メッセージを確認した担当者は、ダイナミックヘッジシステム10により、追加すべき階層数の圧縮テーブルを生成し、生成した圧縮テーブルをシナリオ情報記憶部22のプールエリアに記録する。一方、プール階層で不足している場合には、圧縮テーブルをプール情報テーブルに展開して、シナリオ情報記憶部22のプールエリアに記録する。更に、監視階層においてオーダー明細が不足している場合には、圧縮テーブルからオーダー情報テーブルを生成し、シナリオ情報記憶部22のワークエリアに記録する。そして、各リーブオーダーについてのリンク情報を生成し、リンク情報記憶部23に記録する。
・上記実施形態では、リーブオーダー管理システム20の制御部21は、ヘッジが必要かどうかについての判定処理を実行する(ステップS2−2)。ここでは、制御部21のヘッジ処理部212は、取得した為替レートと、シナリオ情報記憶部22に記録された監視階層のオーダー明細をユーザ端末25の出力部に表示する。ここで、市況に応じて、表示する監視階層数を決定するようにしてもよい。この場合には、オーダー管理部211に、変動傾向に対して監視階層数(必要階層数)を関連付けた階層数決定テーブルを保持させておく。この階層数決定テーブルでは、例えば、変動傾向が大きい場合や激しい場合には、監視階層数が多くなるように設定されている。
図11を用いて、表示階層決定処理を説明する。
まず、リーブオーダー管理システム20の制御部21は、市況情報の取得処理を実行する(ステップS5−1)。具体的には、制御部21のオーダー管理部211は、為替情報システムにアクセスし、為替レートの変動状況に関する情報を取得する。
次に、リーブオーダー管理システム20の制御部21は、市況情報に応じて必要階層数の決定処理を実行する(ステップS5−2)。具体的には、制御部21のオーダー管理部211は、取得した変動状況に基づいて、変動傾向を予測する。そして、オーダー管理部211は、階層数決定テーブルを用いて、変動傾向に応じた必要階層数を決定する。
次に、リーブオーダー管理システム20の制御部21は、現在の表示階層数が必要階層数かどうかについての判定処理を実行する(ステップS5−3)。具体的には、制御部21のオーダー管理部211は、決定した必要階層数と、現在の表示階層数とを比較する。
現在の表示階層数と必要階層数とが一致する場合(ステップS5−3において「YES」の場合)、リーブオーダー管理システム20の制御部21は、表示階層決定処理を終了する。
一方、現在の表示階層数と必要階層数とが一致しない場合(ステップS5−3において「NO」の場合)、リーブオーダー管理システム20の制御部21は、現在の表示階層数が必要階層数よりも少ないかどうかについての判定処理を実行する(ステップS5−4)。
現在の表示階層数が必要階層数よりも少ない場合(ステップS5−4において「YES」の場合)、リーブオーダー管理システム20の制御部21は、不足階層の追加処理を実行する(ステップS5−5)。具体的には、制御部21のオーダー管理部211は、プール階層のリーブオーダーを、不足階層分だけ、監視階層に追加する。この場合、ユーザ端末25の出力部に表示されるオーダー明細が増加する。
一方、現在の表示階層数が必要階層数よりも多い場合(ステップS5−4において「NO」の場合)、リーブオーダー管理システム20の制御部21は、過剰階層の削減処理を実行する(ステップS5−6)。具体的には、制御部21のオーダー管理部211は、監視階層のリーブオーダーを、過剰階層分だけ、プール階層に戻す。この場合、ユーザ端末25の出力部に表示されるオーダー明細が減少する。
これにより、ヘッジ取引の担当者は、ユーザ端末25の出力部に表示されたオーダー明細を、効率的に確認することができる。
・上記実施形態では、リーブオーダー管理システム20の制御部21は、ヘッジが必要かどうかについての判定処理を実行する(ステップS2−2)。ここでは、ユーザ端末25を用いて、ヘッジ取引のためのオーダー明細を指定して取引実行を入力された場合に、ヘッジが必要と判定する。ここで、制御部21は、ヘッジの要否の判断を支援するようにしてもよい。この場合には、オーダー明細に、ヘッジ取引を行なう条件(ヘッジトリガー)を記録しておく。そして、制御部21のヘッジ処理部212は、直近の為替レートと、最上階層のリーブオーダーのオーダー明細とを比較する。そして、オーダー明細の為替レート(ヘッジトリガー)に該当する場合にヘッジが必要であることを示すメッセージを、ユーザ端末25の出力部に出力する。
・上記実施形態では、ダイナミックヘッジシステム10、リーブオーダー管理システム20を用いるハードウェア構成はこれらに限定されるものではない。例えば、ダイナミックヘッジシステム10、リーブオーダー管理システム20を一体として用いてもよい。また、定期追加処理や緊急追加処理を、ダイナミックヘッジシステム10において実行するようにしてもよい。
・上記実施形態では、為替レートのリーブオーダーの管理に適用したが、適用対象は、これに限定されるものではない。複数の指示からなるシナリオに基づいて情報処理が実行されるシステムに適用することができる。
10…ダイナミックヘッジシステム、20…リーブオーダー管理システム、21…制御部、211…オーダー管理部、212…ヘッジ処理部、22…シナリオ情報記憶部、23…リンク情報記憶部、25…ユーザ端末、H10…情報処理装置、H11…通信装置、H12…入力装置、H13…表示装置、H14…記憶部、H15…プロセッサ。

Claims (9)

  1. 各指示の処理内容を記憶する処理情報記憶部と、
    前記各指示の関連性に関するリンク情報を格納するリンク情報記憶部と、
    上位指示に対して、想定条件に応じて選択的な下位指示を定めた階層化された監視シナリオを管理する制御部を備えたシナリオ管理システムであって、
    前記制御部が、
    前記処理情報記憶部に記録された前記上位指示の処理内容を監視エリアに登録し、
    前記監視エリアの上位指示の処理内容を実行した場合、前記リンク情報記憶部のリンク情報を用いて、関連性がある下位指示の処理内容を特定し、前記監視エリアに追加することを特徴とするシナリオ管理システム。
  2. 前記制御部が、前記下位指示の処理内容に不足がある項目について、前記上位指示の処理内容の項目情報を用いて補完することを特徴とする請求項1に記載のシナリオ管理システム。
  3. 前記制御部が、前記監視エリアにおいて、前記監視シナリオの進行により、不要となった上位指示を削除することを特徴とする請求項1又は2に記載のシナリオ管理システム。
  4. 前記制御部は、状況情報を提供する外部システムに接続され、
    前記制御部が、
    前記外部システムから状況情報を取得し、
    前記状況情報に基づいて、前記監視シナリオを進行させることを特徴とする請求項1〜3の何れか一項に記載のシナリオ管理システム。
  5. 前記制御部が、前記状況情報に基づいて、前記監視エリアに格納する階層数を決定することを特徴とする請求項4に記載のシナリオ管理システム。
  6. 前記処理情報記憶部において、前記監視エリアに含まれない下位指示の処理内容を圧縮形式で保存し、
    前記制御部が、前記監視シナリオの進行に応じて、下位指示の処理内容を実行できる形式に、前記圧縮形式を展開することを特徴とする請求項1〜5の何れか一項に記載のシナリオ管理システム。
  7. 前記処理内容は、ヘッジ取引のためのリーブオーダーのオーダー明細であることを特徴とする請求項1〜6の何れか一項に記載のシナリオ管理システム。
  8. 各指示の処理内容を記憶する処理情報記憶部と、
    前記各指示の関連性に関するリンク情報を格納するリンク情報記憶部と、
    上位指示に対して、想定条件に応じて選択的な下位指示を定めた階層化された監視シナリオを管理する制御部を備えたシナリオ管理システムを用いて、シナリオを管理する方法であって、
    前記制御部が、
    前記処理情報記憶部に記録された前記上位指示の処理内容を監視エリアに登録し、
    前記監視エリアの上位指示の処理内容を実行した場合、前記リンク情報記憶部のリンク情報を用いて、関連性がある下位指示の処理内容を特定し、前記監視エリアに追加することを特徴とするシナリオ管理方法。
  9. 各指示の処理内容を記憶する処理情報記憶部と、
    前記各指示の関連性に関するリンク情報を格納するリンク情報記憶部と、
    上位指示に対して、想定条件に応じて選択的な下位指示を定めた階層化された監視シナリオを管理する制御部を備えたシナリオ管理システムを用いて、シナリオを管理するためのプログラムであって、
    前記制御部を、
    前記処理情報記憶部に記録された前記上位指示の処理内容を監視エリアに登録し、
    前記監視エリアの上位指示の処理内容を実行した場合、前記リンク情報記憶部のリンク情報を用いて、関連性がある下位指示の処理内容を特定し、前記監視エリアに追加する手段として機能させることを特徴とするシナリオ管理プログラム。
JP2019063251A 2019-03-28 2019-03-28 シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム Active JP6744446B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019063251A JP6744446B1 (ja) 2019-03-28 2019-03-28 シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019063251A JP6744446B1 (ja) 2019-03-28 2019-03-28 シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム

Publications (2)

Publication Number Publication Date
JP6744446B1 true JP6744446B1 (ja) 2020-08-19
JP2020166313A JP2020166313A (ja) 2020-10-08

Family

ID=72048014

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019063251A Active JP6744446B1 (ja) 2019-03-28 2019-03-28 シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム

Country Status (1)

Country Link
JP (1) JP6744446B1 (ja)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000113072A (ja) * 1998-09-30 2000-04-21 Bank Of Tokyo-Mitsubishi Ltd グループ内金融取引支援システム
US7882008B2 (en) * 2001-04-02 2011-02-01 Goldman Sachs & Co. Apparatus, methods and articles of manufacture for computerized transaction execution and processing
US7966249B1 (en) * 2006-02-10 2011-06-21 Icap Services North America Llc Block trading system and method
JP4362490B2 (ja) * 2006-03-31 2009-11-11 株式会社みずほコーポレート銀行 リーブオーダー管理システム
JP2013210851A (ja) * 2012-03-30 2013-10-10 Fujisoft Kcs Co Ltd シミュレーション装置、取引自動化システムおよびプログラム
JP5960483B2 (ja) * 2012-04-16 2016-08-02 ヴイアールアイ株式会社 行動支援システム及びプログラム

Also Published As

Publication number Publication date
JP2020166313A (ja) 2020-10-08

Similar Documents

Publication Publication Date Title
JP7097675B2 (ja) サプライチェーンにおけるリスク識別
US9898522B2 (en) Distributed storage of aggregated data
US8732118B1 (en) Distributed performance of data aggregation operations
JP6781602B2 (ja) 業務支援システム、および、業務支援方法
CN110383268A (zh) 对用于处理带键网络数据流的参数化应用的动态执行
Putman Urban land use and transportation models: A state-of-the-art summary
CN110826902A (zh) 目标对象考核评价方法、装置、计算机设备及存储介质
CN107844936A (zh) 物料清单的变更方法、装置、终端和计算机可读存储介质
Chiaramonte et al. An agent-based nurse rostering system under minimal staffing conditions
CN110532041A (zh) 规则引擎参数配置方法、装置、计算机设备及存储介质
CN115170048B (zh) 基于模型和规则的工作流实现方法、系统和介质
Nucamendi-Guillén et al. A methodology for increasing revenue in fashion retail industry: A case study of a Mexican company
Moselhi et al. Project schedule compression: a multi-objective methodology
Aboolian et al. Responsive make‐to‐order supply chain network design
JP6744446B1 (ja) シナリオ管理システム、シナリオ管理方法及びシナリオ管理プログラム
Roy et al. Multi‐agent architecture for supply chain management
JP6062836B2 (ja) 経費按分システム及びその方法
Palma et al. A robust model for protecting road-building and harvest-scheduling decisions from timber estimate errors
JP5784450B2 (ja) 緊急時事案行動計画策定支援装置、緊急時事案行動計画策定支援方法、及び緊急時事案行動計画策定支援プログラム
CN112487721B (zh) 一种工单排产实现方法、设备及介质
JP6626327B2 (ja) ガントチャート生成プログラム、ガントチャート生成装置、および、ガントチャート生成方法
JP6506089B2 (ja) 経営管理システム、経営管理方法、および、経営管理プログラム
Kiss et al. Supply Chain Simulation As A Service To Increase Adaptation Capability In Manufacturing
JP6016657B2 (ja) データ処理装置及びプログラム
JP4790085B1 (ja) 販売価格管理装置、販売価格管理システム、販売価格管理方法及び販売価格管理プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190328

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190415

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200701

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200730

R150 Certificate of patent or registration of utility model

Ref document number: 6744446

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250