JP6318019B2 - 計画業務支援方法およびシステム - Google Patents

Description

本発明は、計画作成業務支援方法およびシステムに関する。

計画作成や計画変更などの計画業務の複雑化、業務知識の属人化を背景に、計画自動作成技術のニーズが近年高まっている。計画自動作成技術には、当初の計画に対して問題が生じた場合に計画変更を提案して問題解消を図る技術を含む。計画自動作成技術を用いた計画作成業務支援システムは、当初の計画と生じた問題を入力とし、計画変更の可能性を探索することにより変更提案という形で解を出力することができる。ただし、解の探索に先立って、計画が満たすべき制約条件をあらかじめ定式化しておく必要がある。しかし、知識エンジニアが業務専門家にヒアリングして計算機処理向けに定式化した制約条件は、業務用語で慣用する制約条件と異なる。このため、計画自動作成処理の計算ログを見てもなぜその解が出力されるに至ったかがユーザに理解しにくく、知識工学の手法をスケジューリング問題の意思決定支援に用いる上での障壁となっている。

提案理由を示すことによって計算過程を可視化して、ユーザが承認しやすい計画を自動作成するシステム技術を提供することが課題であった。

エキスパート（業務専門家）の知識を運行整理に適用するための技術として、たとえば特許文献１に記載の技術がある。特許文献１に記載の技術では、エキスパートの知識のうち具体的な表現が容易なものについては録音に、表現が困難な推論は変更履歴に記憶して、運行整理に用いることが開示されている。

特公平８−２２６７２号公報

しかしながら特許文献１に記載の技術には、計画を自動に作成する技術について開示されていない。更に、業務専門家の発話録音した変更理由と知識エンジニアが定式化した計算処理過程との関係付けをすることも困難であり、計画自動作成処理の計算過程を十分に可視化できないという課題がある。

本発明の目的は、計画に生じた問題を解決するよう計画変更を計算機が計算する際において、計算結果である計画変更内容を出力するに至った理由を示すことによって計算過程を可視化して、ユーザが承認しやすい計画を自動作成する計画業務支援システムを提供することである。本発明の別の目的は、計画業務支援システムにおいて理由を示すことによって計算過程を可視化する方法を提供することである。

開示する計画作成業務支援システムは、計画に関する初期計画と提案計画を取得する取得部と、初期計画と提案計画から変更内容を抽出する変更内容抽出部と、変更内容に対応する変更理由を予め記憶する対処情報記憶部と、対処情報記憶部に記憶された変更内容に対する変更理由を取得する変更理由取得部と、変更内容と変更理由を表示する表示部と、を備える。

本発明により、計画変更内容の視認性、ユーザの了解性が高い計画業務支援システムを提供できる。

計画業務支援システムの全体システム構成を示す説明図である。 計画業務支援システムにおける計算過程可視化方法をデータフローの観点からまとめた図である。 計算機のハードウェア構成を示す図である。 計画変更内容を規定する変更内容テーブルを示す図である。 データサーバ上の各種データのデータ構造を説明する図である。 業務モデルのルールを定めたパターンテーブルを説明する図である。 解釈・説明情報生成処理の処理手順を示す図である。 変更内容判定処理の処理手順を示す図である。 計算過程可視化処理の処理手順を示す図である。 計算過程可視化処理の出力する画面例を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１は計画業務支援システムの全体システム構成を示す説明図である。

計画業務支援システム１０１は、複数の計算機をネットワーク接続したシステムであって、計算過程可視化サブシステム１０２、自動提案サブシステム１０５、データサーバ１０６、状況変化連絡機１０４、ユーザ端末１０３から構成する。これらの機器はメモリ上にプログラムとして処理方法を実装した計算機である。

データサーバ１０６は入出力処理部を備え、入出力処理部を介して出入りするデータを保管管理する。データには、計算ログ１１２、状況情報１１３、業務モデル１１４、初期計画１１５、提案計画１１６、承認計画１１７、属性情報１１８等があり、あらかじめユーザが作成して保存しておくか、あるいはネットワーク接続された別の機器によって作成されたデータを入出力処理部を介して受け取り保存する。

状況変化連絡機１０４は計算機であり、あらかじめ状況変化連絡についての処理方法を定めたプログラムをメモリに搭載してＣＰＵを用いてこれを実行する。状況変化連絡の処理方法は、初期計画に従って人が業務遂行する際にどの人の何のタスクにどのような問題が生じているかについての情報をセンサ、ネットワークを介して受信し、状況情報１１３を逐次更新する方法である。あるいは、ユーザ端末１０３を介してユーザが状況変化の更新情報を逐次入力してもよい。

自動提案サブシステム１０５は、自動提案処理部１１０、入出力処理部１１１を備える。データサーバ１０６上の初期計画１１５、状況情報１１３等のデータを、入出力処理部１１０を介して取得し、状況情報１１３の中に記述されたデータの示す問題を解決するよう提案計画１１６を作成、入出力処理部１１１を介してデータサーバ１０６上に保存する。計画変更方法をあらかじめルールの形で定型化しておいて状況に応じたルール（あるいはパターン）を選択することにより、計画変更内容を含む提案計画１１６を作成する。あるいは、制約条件を定めておき制約を充足する計画変更内容を算出する従来技術を用いてもよい。ルールと制約条件は対応する理由情報、優先順位情報と共に業務モデル１１４としてあらかじめ定める。入出力処理部１１１を介して提案計画１１６をユーザが参照し、それを承認するユーザ入力を入出力処理部１１１が受け取ると自動提案処理部１１０は承認計画１１７を作成、保存する。自動提案処理部１１０の計算過程で適用した業務モデル１１４のルール等は計算ログ１１２としてデータサーバ１０６上に逐次保存する。

ユーザ端末１０３はユーザが使う計算機である。ユーザ端末１０３は計算過程可視化サブシステム１０２、自動提案サブシステム１０５、データサーバ１０６、状況変化連絡機１０４の入出力処理部にアクセスして、これらの機器の動作をユーザが操作する。これらの機器は計算機であり、計算機の入出力手段を用いてユーザが機器を直接操作してもよい。

計算過程可視化サブシステム１０２は入出力処理部１０７、計算過程可視化処理部１０８、解釈・説明情報生成処理部１０９を備える。入出力処理部１０７は、提案計画１１６などのデータをデータサーバ１０６から読み込む。解釈・説明情報生成処理部１０９は、自動提案サブシステム１０５が提案計画１１６を作成するに至った提案理由について提案計画１１６、計算ログ１１２および他のデータを用いて解釈し、提案理由情報を作成する。計算過程可視化処理部は提案計画１１６に含まれた変更内容を出力する際に、対応する提案理由情報と共に、入出力処理部１０７を介して出力する。その出力先はデータサーバ１０６あるいはユーザ端末１０３である。

すなわち、計画作成業務支援システム１０１において、取得部（入出力処理部１０７）が、計画に関する初期計画と提案計画を取得し、変更内容抽出部（計算過程可視化処理部１０８）が、初期計画と提案計画から変更内容を抽出し、対処情報記憶部（パターンテーブル６０１）に、変更内容に対応する変更理由を予め記憶し、変更理由取得部（解釈・説明情報生成処理部１０９）が、対処情報記憶部に記憶された変更内容に対する前記変更理由を取得し、表示部が、変更内容と変更理由を表示する。

図２は、計画業務支援システムにおける計算過程可視化方法をデータフローの観点からまとめた図である。

スケジューリング機能２０５は自動提案処理部１１０に含まれる機能モジュールであり、初期計画２０１に生じた問題を解決して提案計画２０６を作成する。ブラックボックス評価機能２０３およびホワイトボックス評価機能２０９は解釈・説明情報生成処理部１０９に含まれる機能モジュールである。出力機能２０７は計算過程可視化サブシステム１０２の入出力処理部１０７に含まれる機能モジュールである。

初期計画２０１、提案計画２０６、業務モデル２０２、計算ログ２０８、提案理由情報２０４、提案理由情報２１０はデータサーバ１０６上のデータである。業務モデル２０２には、どのような条件の場合にどのような理由の元でどのような計画変更を行うかというルール情報（ＩＦ、ＴＨＥＮ、ＢＥＣＡＵＳＥ、ＰＲＩＯＲＩＴＹ）を記述する。さらに、計画変更についてどのような理由の元でどのような制約条件があるかについての制約情報（ａ＞ｂ、ｂｅｃａｕｓｅ〜）を優先順位情報付きで記述する。スケジューリング機能２０５が提案計画２０６を作成するには業務モデル２０２を利用する。すなわち、対処情報記憶部（パターンテーブル６０１）は、変更内容に対して複数の変更理由と、優先順位を記憶し、変更理由取得部（解釈・説明情報生成処理部１０９）は、複数の変更理由のうち優先順位の高いものを変更理由として取得し、表示部は、変更理由を表示する。

計算過程可視化という計画業務支援の目的に対してブラックボックス評価とホワイトボックス評価という２種類のアプローチがある。

ホワイトボックス評価は、スケジューリングの中で業務モデルがどのように利用されるかをよく知った状態でスケジューリングの処理内容を評価するアプローチである。具体的には、スケジューリング２０５の処理において業務モデル２０２のどの情報を利用したかを計算過程での計算ログ２０８として出力するステップを備え、計算結果に対応する提案理由情報を得る。提案理由情報はスケジューリング機能２０５の処理内容に忠実となる。その反面、制約情報の利用において全部の要素が作用する場合に全部の理由情報が該当するなど、ユーザには提案理由が多すぎて結果的に分かりにくくなることがある。知識工学に基づくスケジューリング機能の計算過程は複雑なものが多く、計算過程に忠実な提案理由情報が必ずしもユーザに理解されやすいものとは限らない。

ブラックボックス評価は、スケジューリングの処理方法を知らない状態で（すなわち計算ログや処理方法に関する人の知識を利用せずに）、スケジューリング機能の処理内容を推測しようとするアプローチである。具体的には、初期計画２０１と提案計画２０６を比較することによって変更内容を抽出し、さらに状況情報１１３等を分析することによって、業務モデル２０２のどの要素が作用した結果その変更内容が出力されたのかを、後から業務モデル２０２を当てはめることによって提案理由情報を推定する。制約情報はすべて満たされると想定するため全件をユーザに提示しなくてもよいし、制約情報の一部をルール情報に含めて提示しても良い。推測結果が実際のスケジューリング処理内容と異なっても、提案理由情報が業務モデルの観点に投影されて出力されるため、ユーザに提案計画が理解しやすい効果がある。

ホワイトボックス評価機能２０９および／あるいはブラックボックス評価機能２０３によって得た提案理由情報を優先順位情報に基づいて抜粋したり並べ替えたりして提示することによって両方式の長所を組み合せ利用できる。

図３は、計算機のハードウェア構成を示す図である。

計算機３０１はＣＰＵ３０２、メモリ３０３、ディスク３０５、入出力手段３０６、タイマ３０４、センサ３０７を備える。入出力手段３０６には、マウスやディスプレイなどを含む。

以降、鉄道乗務員の運用についての計画変更業務を実施例として取り上げる。

鉄道会社では、どの列車に誰が乗務するか、および誰がどの列車に乗務するかについてあらかじめ計画されている。例えば、乗務員Ｘは列車Ａ乗務の後に終着駅Ｓで列車Ｂに乗務する計画について考える。もし列車Ａが大幅に遅れた場合、乗務員Ｘは列車Ｂの発車時刻に間に合わなくなる。このとき、列車Ｂに誰を乗務させるか、また、乗務員Ｘは次にどの列車に乗務するかを計画変更しなければならない。列車Ｂの発車時刻に駅Ｓに存在可能という空間的、時間的な制約条件を満たしつつ、連続労働時間や宿泊場所などのヒトに関わる制約も踏まえて列車Ｂに乗務員を割り当てる必要がある。当初の計画は多くの列車、多くの乗務員に関わる多種多様な制約を整合させたものであり、１つの問題が連鎖的に多数の計画変更を呼び起こすことも少なくない。このため計画変更の作業には多くのチェックが必要であり、計算機による業務支援が役立つ。

図４は、計画変更内容を規定する変更内容テーブルを示す図である。

変更内容テーブルは属性情報１１８の一部でありデータサーバ１０５上に保存する。

ある乗務員は初期計画１１５では、ある時刻にある列車Ａに乗務しているか待機所に待機しているかどちらかであり、変更内容テーブル４０１では初期計画４０２における業務内容として、それぞれ列車４０５、待機所４０４の軸で表す。ここでは２状態での状態遷移を考えるが、多種の状態でもよい。計画変更が生じて提案計画１１６が作成されたとき、その乗務員にとっての業務の可能性は、当該時刻において同じ列車Ａに乗務しているか、別列車Ｂに乗務しているか待機所に待機しているかである。同様に、変更内容テーブル４０１では、それぞれ、業務内容として別列車４０７、待機所４０６の軸で表す。

すなわち、初期計画情報と前記提案計画情報から変更内容を特定する変更内容特定記憶部（変更内容テーブル４０１）を更に備え、変更内容抽出部（計算過程可視化処理部１０８）は、初期計画情報と提案計画情報から変更内容を抽出する。

初期計画４０２で列車Ａ（すなわち列車４０５）に乗務していた乗務員が提案計画４０３で待機所４０６となる状況を、待機４１０と呼ぶ。初期計画で列車Ａ（すなわち列車４０５）に乗務していた乗務員が提案計画で別列車Ｂ（すなわち別列車４０７）への乗務となる状況を、乗換４１１と呼ぶ。初期計画で待機所４０４にいた乗務員が提案計画で別列車Ｂ（すなわち別列車４０７）への乗務となる状況を、割当４０９と呼ぶ。同じ列車Ａに乗務し続ける場合および待機し続ける場合は計画変更がない意味だが図では表現を簡単化している。

ある乗務員の計画変更の前後の業務内容を取得し、変更内容テーブル４０１を参照することによって、その乗務員に命じられた計画変更内容が仕分けできる。

図５は、データサーバ上のデータのデータ構造を説明する図である。

データサーバ１０６上には、状況情報１１３、属性情報１１８を含むデータが保存されている。属性情報１１８は、（ａ）属性情報テーブル（駅）５０１、（ｂ）属性情報テーブル（乗務員）５０２、（ｃ）属性情報テーブル（列車）５０３を含むデータを備える。初期計画１１５は、（ｄ）初期計画テーブル５０４を含むデータを備える。提案計画１１６は（ｅ）提案計画テーブル５０５を含むデータを備える。属性情報１１８には、駅、乗務員、列車の属性について初期値をあらかじめ記述しておき、状況が変われば一部を更新する。属性情報のマスターデータをバックアップしておいて必要時には更新内容を元に戻しても良い。

状況情報１１３には、乗務員状況、駅状況、ノード状況、列車状況、時刻状況、状態状況、管理状況の情報を含み、状況変化連絡機１０４あるいはユーザ端末１０３からの入力によって逐次更新される。これらは業務モデル１１４のＩＦ情報と対応して状況一致不一致を判定する属性情報を含む。

属性情報テーブル（駅）５０１は、駅番号５０６と属性５０７を含む。属性位置関係情報５０７には、駅名、隣駅の駅番号、駅順、管理、待機場所指定、所属乗務員番号、線名、種別などを備え、グラフ構造を構成する。種別は始発駅、終着駅、基地などを示す。

属性情報テーブル（乗務員）５０２は、乗務員番号５０８、属性５０９を含む。属性５０９には、所属、氏名、出退勤時刻、資格、勤務種別、宿泊地、労働時間の情報を含む。

属性情報テーブル（列車）５０３は、列車番号５１０、属性５１１を含む。

属性５１１には、車種、車名、番線、出発駅番号、到着時刻、出発時刻、到着駅番号、関係する列車番号など含み、グラフ構造を構成する。

初期計画テーブル５０４は、乗務員番号５１２、ノード番号５１３、次ノードのノード番号５１４、列車番号５１５、状態５１６、管理５１７、フラグ５１８のフィールドを含む。管理５１７フィールドには駅属性情報、時刻情報を含み、さらに、どの駅でどの列車番号の列車にどの乗務員番号の乗務員が乗務するか、どの駅でどの乗務員が待機するかの業務内容を定める。

提案計画テーブル５０５は、初期計画テーブル５０４と似た構造を備え、乗務員番号５１９、ノード番号５２０、次ノードのノード番号５２１、列車番号５２２、状態５２３、管理５２４、フラグ５２５のフィールドを含む。管理５２４フィールドには提案理由情報、優先順位情報を含む。

初期計画テーブル５０４で例示した第１レコードでは、乗務員番号５１２が１番となる乗務員が、列車番号５１５が１００番となる列車を、状態５１６が運転と示す業務を行った後、次ノード番号５１４が２番となる業務にあたる計画を示す。初期計画テーブル５０４で例示した第２レコードでは、管理５１７フィールドの定める場所で、状態５１６が待機と示す業務を行い、次ノード番号５１４がＥｎｄ（業務終了を示す）となる業務にあたる計画を示す。なお、フラグ５１８フィールドには初期値であることを示すフラグ情報をあらかじめ設定しておく。自動提案処理部１１０あるいは解釈・説明情報生成処理部１０９によって当該レコードに対して変更提案がなされたと判定した後に、当該レコードのフラグフィールドに「変更」と後からレコードを更新する。

提案計画テーブル５０５で例示する第１レコードは、初期計画テーブル５０４の第１レコードと同等であり、乗務員番号１番の乗務員が列車番号１００番の列車を運転する業務に対して変更提案がない状態を示す。提案計画テーブル５０５で例示する第２レコードは、（第１レコードの業務の後に）乗務員番号１番の乗務員が列車番号１０５番の列車を運転する計画を示す。

初期計画テーブル５０４で状態５１６が待機であった乗務員を乗務させる変更なので、解釈・説明情報生成処理部１０９は、初期計画テーブル５０４および提案計画テーブル５０５の比較を行い、さらに変更内容テーブル４０１を参照することによってフラグ５２５フィールドに「割当」４０９を示す情報を設定する。

図６は、業務モデルのルールを定めたパターンテーブルを説明する図である。

業務モデル１１４には、所定の状況になれば所定の計画変更を行うルールを定めたパターンテーブル６０１と変更内容が守るべき制約条件を示す制約テーブルを、それぞれあらかじめユーザが定めて入力しておく。

パターンテーブル６０１にはＩＦ情報（乗務員属性６０２、駅属性６０３、ノード属性６０４、列車属性６０５、時刻属性６０６、状態属性６０７、管理属性６０８）、ＴＨＥＮ情報（変更内容６０９）、ＢＥＣＡＵＳＥ情報（理由６１０）、ＰＲＩＯＲＩＴＹ情報（優先順位６１１）のフィールドを備える。

ＩＦ情報は、それぞれ状況情報１１３の乗務員状況、駅状況、ノード状況、列車状況、時刻状況、状態状況、管理状況に対応し、状況が業務モデル１１４に定めたルールに一致するかどうかを判定可能な属性情報を含む。

例えば、パターンテーブル６０１のあるレコードにおいて、列車属性６０５が「駅Ｍを出る臨時列車」であって、かつ、乗務員属性６０２に「割当が必要」と示すフラグが立ち、かつ、乗務員属性６０２に「初期計画では駅Ｍで待機中」という状況をＩＦ情報として指定する。その状況に対応する変更内容６０９には、「割当」という提案ルールを定める。対応する理由６１０には「臨時列車の運転は待機中の乗務員の本来の任務のため」などと現場ユーザが理解しやすい自由文字列を定めておく。提案理由として業務用語を用いて了解性が高い文章を作成しておき、これを実際の提案内容と関係付けて出力することにより、ユーザに提案内容を了解してもらいやすくなる。

さらに、この提案ルールに対応する優先順位６１１を３番目とする。優先順位６１１の設定は、多数のルールが複数成立する場合に、より優先順位の高いルールを計算機に判定可能とする。さらに、業務現場によっては、より詳細な状況を規定する必要がある場合にも柔軟に対応できる。パターンテーブル６０１はそのような多様な状況、変更内容などを記述するために、各フィールドをインストア関数や構造体を利用して拡張して用いてもよい。

自動提案処理部１１０は、業務モデル１１４に定められたルールや制約条件に基づいて状況情報１１３に応じた提案計画を作成し、計算ログ１１５を出力する。計算ログ１１５は、提案する変更内容と共に、当該変更内容を提案する時に自動提案処理が使用したパターンテーブル６０１および／あるいは制約テーブルの当該レコード内容、状況情報１１３を出力する。

上述の例を習って状況情報１１３に応じる処理内容を補足する。状況情報１１３として、駅状況の出発駅が「駅Ｍ」、列車状況の列車種類が「臨時列車」という情報が入力／送信されてきた場合を考える。パターンテーブル６０１のあるレコードにおいて、列車属性６０５の出発駅が「駅Ｍ」で列車種類が「臨時列車」と指定されていると状況と提案ルールが一致する。状況情報１１３に応じて状況を判定する処理は、自動提案処理部１１０だけでなく、解釈・説明情報生成処理部１０９でも利用する。

自動提案処理部１１０がパターンテーブル６０１に基づいて提案計画１１６を作成する場合には、ホワイトボックス評価によって、ルールを当てはめた時の計算ログを元に提案理由を抽出できる。一方、制約テーブルに基づいて提案計画１１６を作成する場合には、ブラックボックス評価によって、作成後の提案計画に対して業務モデル（パターンテーブル６０１）を当てはめて、対応する提案理由を推定できる。自動提案処理部１１０がパターンテーブル６０１および制約テーブルの両方を併用した場合には、両方の提案理由を組み合せ利用してもよい。

図７は、解釈・説明情報生成処理の処理手順を示す図である。

解釈・説明情報生成処理は解釈・説明情報生成部１０９が備える。図７を用いて説明する解釈・説明情報生成処理はブラックボックス評価機能２０３の実施形態のひとつである。

ステップ７０１において、変更内容判定処理を行う。変更内容判定処理は初期計画１１５と提案計画１１６の比較を行う。具体的には初期計画テーブル５０４の状態５１６フィールドにある業務内容、提案計画テーブル５０５の状態５２３フィールドにある業務内容の比較を行う。変更内容テーブル４０１を参照して変更内容情報(ＴＨＥＮ情報)を取得する。初期計画テーブル５０４のフラグ５１８フィールドに「変更」とフラグを立てる。

ステップ７０２において、内容変更のあった箇所について、ＩＦ情報（乗務員属性６０２、駅属性６０３、ノード属性６０４、列車属性６０５、時刻属性６０６、状態属性６０７、管理属性６０８）を構成する各属性情報について、状況情報１１３などデータサーバ上のデータを調べる。すなわち、提案前の詳細な状況を判定する。このとき計算ログ２０８を用いてもよい。計算ログ２０８を用いなくてもＩＦ情報、ＴＨＥＮ情報の構成要素となる情報を特定できる点はブラックボックス評価の特徴的な機能構成である。

例えば、属性情報テーブル（列車）５０３に基づき、提案計画テーブルで内容変更があった列車番号５２２の列車についての属性を照会する場合を考える。当該列車の列車属性５１１が「駅Ｍを出る臨時列車」と特定されるとき、ステップ７０３以降の処理において、パターンテーブル６０１であるレコードの列車属性６０５が「駅Ｍを出る臨時列車」であれば、ＩＦ情報の状況が一致していると判定できる。初期計画テーブルの列車番号５１５がゼロとなる場合は待機と等価とする。

ステップ７０３において、パターンテーブル６０１を参照し、ＩＦ情報、ＴＨＥＮ情報に合致するパターンを検索し選択する。

ステップ７０３において、対応する理由情報(ＢＥＣＡＵＳＥ情報)と優先順位情報を取得し、提案計画テーブルの管理フィールドに格納する。

図８は、変更内容判定処理の処理手順を示す図である。

ステップ８０１において、初期計画テーブル５０４、提案計画テーブル５０５を参照する。

ステップ８０２において、提案計画テーブルのリンク開始レコードを検索、注目レコードＡに設定する。次ノード５２１がＥｎｄとなるレコードから、ノード番号５２０を特定し、当該ノード番号を持つレコードを探すというように、逆向きにグラフ構造をたどれば終点となるリンク開始レコードにたどりつく。ある乗務員に注目して業務の連鎖（どの列車に乗って何駅で待機、次にどの列車に乗るかなど）を順次チェックしていく。提案計画テーブル５０５の例では第１レコードがレコードＡである。

ステップ８０３において、初期計画テーブル５０４において、レコードＡの乗務員番号５１９、ノード番号５１３のフィールドの値と同じ値を持つ対応レコードＢを検索する。初期計画テーブル５０４の例では第１レコードがレコードＢである。

ステップ８０４において、レコードＡ，Ｂの属性情報から変更内容テーブル４０１に基づいて、提案前後での変更内容を特定する。

ステップ８０５において、変更があれば、レコードＡのフラグ５２５フィールドに変更内容を設定する。さらに、レコードＢのフラグ５１８フィールドに変更有無を示す情報を設定する。

ステップ８０６において、レコードＡの次ノード番号５２１，レコードＢの次ノード番号５１４を持つレコードを検索し、次の注目レコードＡ，注目レコードＢとして設定する。

ステップ８０７において、業務の連鎖の終端までチェックしたかを判定し、チェック完了していなければ、ステップ８０３に戻って次の業務連鎖についてチェックする。

ステップ８０８において、全乗務員、全列車についてチェックしたかを判定し、チェック完了していなければ、ステップ８０２に戻って、次の乗務員についてチェックする。

図９は、計算過程可視化処理の処理手順を示す図である。

計算過程可視化処理は計算過程可視化処理部が備える。

ステップ９０１において、初期計画テーブル５０４、提案計画テーブル５０５を参照し、ユーザ端末１０３のディスプレイ画面に表示出力する。画面内容を作成するに際しては属性情報テーブル（駅）５０１などのデータサーバ上のデータを利用する。

ステップ９０２において、提案計画テーブルのフラグ５２５を検索、フラグの立っているレコードを注目レコードに設定する。提案レコードを１件づつ処理する。フラグをあらかじめ立てておくことにより、効率的かつ高速に処理対象を絞り込むことができる。

ステップ９０３において、注目レコードの列車番号５２２に基づいて、属性情報テーブル（列車）５０３から列車に関係する属性情報（列車番号、到着駅、出発駅、到着時刻、出発時刻など）５１１を検索する。さらに乗車乗務員番号５１９に基づいて、属性情報テーブル（乗務員）５０２から乗務員に関係する属性情報を検索する。

ステップ９０４において、列車属性、乗務員属性を出力する。

ステップ９０５において、提案計画テーブルの管理５２４フィールドに格納（ステップ７０４で実施）された提案理由情報、優先順位情報を検索する。複数の提案、あるいは複数の提案理由情報が検索された場合、優先順位情報の順に並べ替えて併記あるいはユーザ提示後にユーザが提案を選択した後に出力してもよい。

ステップ９０５において、ユーザ端末からの入力によってユーザが提案を承認すれば、提案計画テーブルの管理フィールドに承認フラグを立てた後に、ステップ９０２に戻って次の提案レコードに処理を移す。

ステップ９０６において、ユーザが提案を却下すれば、提案計画テーブルの当該レコードの管理フィールドに却下フラグを立てる。別の自動提案処理方法や別条件を適用して再提案処理を行ってもよい。

ステップ９０７において、提案全件の処理が済んでいるかを確認し、済んでいなければステップ９０２に戻って提案計画テーブル５０５の次レコードに処理を移す。

すなわち、初期計画情報と提案計画情報に加えて、変更内容抽出部が変更内容を抽出した際に、変更内容があったことをフラグとして更に記憶する計画情報記憶部（初期計画１１５、提案計画１１６）を更に備え、表示部は、計画情報記憶部に記憶された変更内容を表示する。

図１０は、計算過程可視化処理の出力する画面例を示す図である。

ステップ９０４、ステップ９０５の出力処理の詳細について説明する。

初期計画テーブル５０４を出力する。列車ダイヤは縦軸に駅１００１の並び、横軸に時間軸を取った２次元表示する。初期計画テーブル５０４のあるレコードに注目するとき、まず列車番号５１５を検索し取得する。当該列車番号５１５を検索キーとして、属性情報テーブル（列車）５０３から属性情報５１１を検索し、出発駅番号、到着駅番号、出発時刻（Ｘ１）、到着時刻（Ｘ２）を得る。当該出発駅番号をキーとして属性情報テーブル（駅）５０１を検索し、あらかじめ駅属性５０７として定めてあった出発駅のＹ座標描画位置（Ｙ１）、同様に、到着駅のＹ座標描画位置（Ｙ２）をそれぞれ得る。すなわち、スジ１００２と呼ぶ線分（Ｘ１，Ｙ１）−（Ｘ２−Ｙ２）を一つの列車を示す図形として表示できる。同様に全レコードの処理を行い、複数列車に対応する複数のスジを画面に出力する。さらに列車番号、乗務員番号をスジの近くに描画出力する。列車ダイヤと同様に乗務員の動きを示す乗務員ダイヤを描画出力する。

提案計画テーブル５０５について同様に検索して、変更提案のあったレコードの列車については変更のあったことを太線１００３で示して描画する。表示しなくてもよい。あらかじめフラグ５２５を立てておくことにより効率的かつ高速に描画できる。フラグ５１８に基づく初期計画の対応レコードも効率的かつ高速に検索できるため、乗務員番号の変化として運用の変化を直接的に見せてもよい。色を変えたりマークを提案前後の変化として表示出力してもよい。提案ボタン１００５を画面に出しておきユーザが提案ボタン１００５を押すことによって、初期計画と提案計画の両方を切り替え表示してもよい。提案数あるは時間を意味するスライドバー１００４を備えて、ユーザのスライド操作に応じて順番に提案計画を見せてもよい。ユーザの使い勝手を向上する。

詳細情報を出力するようユーザ入力を受けたとき、提案内容の詳細を示すフォーム１００６を出力する。フォーム１００６には、変更提案の内容と提案理由、提案優先順位を出力する。複数の提案、複数の提案理由があれば提案優先順位に基づいて並べ替え取捨選択する。画面構成は軸、レイアウト、出力順序、出力内容などを容易に変更できる。

提案理由が表示されて、機械計算による提案内容に対する了解性を向上する。

１０１：計画業務支援システム，１１１：入出力処理部

Claims (8)

1. 計画に関する初期計画と、前記初期計画と状況を表す状況情報とを入力とし、計画変更のルールおよび制約条件を定めた業務モデルを用いた自動提案処理により前記状況に応じて変更された提案計画と、を取得する取得部と、
   前記取得部で取得された初期計画と前記取得部で取得された提案計画を比較することにより変更内容を抽出する変更内容抽出部と、
   前記業務モデルに、変更内容と、該変更内容に対応する変更理由と、を対応づけたパターン情報を予め記憶する対処情報記憶部と、
   前記状況情報と前記業務モデルを利用し、前記対処情報記憶部に記憶された前記パターン情報から、前記変更内容抽出部で抽出された変更内容に対する変更理由を取得する変更理由取得部と、
   前記変更内容抽出部で抽出された変更内容と、前記変更理由取得部で取得された変更理由と、を表示する表示部と、を備える
   ことを特徴とする計画作成業務支援システム。
2. 請求項１に記載の計画作成業務支援システムにおいて、
   前記対処情報記憶部が記憶する前記パターン情報には、前記変更内容に対して、複数の前記変更理由と、前記複数の変更理由の優先順位と、が対応づけられており、
   前記変更理由取得部は、前記パターン情報から、前記変更内容抽出部で抽出された変更内容に対する複数の変更理由のうち優先順位の高いものを取得し、
   前記表示部は、前記変更理由取得部で取得された変更理由を表示する
   ことを特徴とする計画作成業務支援システム。
3. 請求項２に記載の計画作成業務支援システムにおいて、
   更に、初期計画と提案計画の組合せと、前記初期計画から前記提案計画への変更内容と、を対応づけた変更内容情報を記憶する変更内容特定記憶部を更に備え、
   前記変更内容抽出部は、前記取得部で取得された初期計画と前記取得部で取得された提案計画から、前記変更内容情報を参照することによって、変更内容を抽出することを特徴とする計画作成業務支援システム。
4. 請求項３に記載の計画作成業務支援システムにおいて、
   前記変更内容抽出部が前記変更内容を抽出した際に、前記取得部で取得された提案計画の変更内容を含む提案計画情報にフラグを付加する計画情報記憶部を更に備え、
   前記表示部は、前記計画情報記憶部により前記提案計画情報に前記フラグが付加された提案計画に注目し、注目した該提案計画の変更内容により前記パターン情報を検索し、検索で得られた該変更内容に対応する変更理由を表示する
   ことを特徴とする計画作成業務支援システム。
5. 計画作成業務支援システムにおける計画作成業務支援方法であって、
   前記計画作成業務支援システムの取得部が、計画に関する初期計画と、前記初期計画と状況を表す状況情報とを入力とし、計画変更のルールおよび制約条件を定めた業務モデルを用いた自動提案処理により前記状況に応じて変更された提案計画と、を取得し、
   前記計画作成業務支援システムの変更内容抽出部が、前記取得部で取得された初期計画と前記取得部で取得された提案計画を比較することにより変更内容を抽出し、
   前記計画作成業務支援システムの対処情報記憶部が、前記業務モデルに、変更内容と、該変更内容に対応する変更理由と、を対応づけたパターン情報を予め記憶し、
   前記計画作成業務支援システムの変更理由取得部が、前記状況情報と前記業務モデルを利用し、前記対処情報記憶部に記憶された前記パターン情報から、前記変更内容抽出部で抽出された変更内容に対する変更理由を取得し、
   前記計画作成業務支援システムの表示部が、前記変更内容抽出部で抽出された変更内容と、前記変更理由取得部で取得された変更理由と、を表示することを特徴とする計画作成業務支援方法。
6. 請求項５に記載の計画作成業務支援方法において、
   前記計画作成業務支援システムの前記対処情報記憶部が記憶する前記パターン情報には、前記変更内容に対して、複数の前記変更理由と、前記複数の変更理由の優先順位と、が対応づけられており、
   前記計画作成業務支援システムの前記変更理由取得部は、前記パターン情報から、前記変更内容抽出部で抽出された変更内容に対する複数の変更理由のうち優先順位の高いものを取得し、
   前記計画作成業務支援システムの前記表示部は、前記変更理由取得部で取得された変更理由を表示することを特徴とする計画作成業務支援方法。
7. 請求項６に記載の計画作成業務支援方法において、
   前記計画作成業務支援システムの変更内容特定記憶部は、初期計画と提案計画の組合せと、前記初期計画から前記提案計画への変更内容と、を対応づけた変更内容情報を記憶し、
   前記計画作成業務支援システムの前記変更内容抽出部は、前記取得部で取得された初期計画と前記取得部で取得された提案計画から、前記変更内容情報を参照することによって、変更内容を抽出する
   ことを特徴とする計画作成業務支援方法。
8. 請求項７に記載の計画作成業務支援方法において、
   前記計画作成業務支援システムの計画情報記憶部は、前記変更内容抽出部が前記変更内容を抽出した際に、前記取得部で取得された提案計画の変更内容を含む提案計画情報にフラグを付加し、
   前記計画作成業務支援システムの前記表示部は、前記計画情報記憶部により前記提案計画情報に前記フラグが付加された提案計画に注目し、注目した該提案計画の変更内容により前記パターン情報を検索し、検索で得られた該変更内容に対応する変更理由を表示する
   ことを特徴とする計画作成業務支援方法。

Images