JP2015164034A - 運行管理方法および運行管理システム - Google Patents

Abstract

【課題】労働省告示第３７号および関連法令に基づく請負業務の要件を満たした上で、ユーザの依頼に迅速かつ柔軟に対応できる運行管理方法を提供する。
【解決手段】ユーザ３は、ＰＣ３１を用いて、業務請負会社２が運営するサーバ２１にアクセスし、車両の運行計画のデータを送信する。業務請負会社２の車両管理責任者２Ｐは、サーバ２１で受信した運行計画の内容を確認すると共に、車両４の運転手４Ｄの確定と運行計画の承認を行い、その後、サーバ２１を用いて、確定した運転手４Ｄが使用するスマートフォン４１に運行計画承認の通知を行う。運行計画承認の通知を受けた運転手４Ｄは、スマートフォン４１を用いてサーバ２１にアクセスし、承認された運行計画の内容を確認する。
【選択図】図１

Description

本発明は、車両運行管理業務における運行管理方法およびその方法を採用した運行管理システムに関する。

労働省告示第３７号および関連法令に基づく請負業務の一形態として、選任された運転手でユーザの所有する車両（社用車等）の運行管理、運転、日常点検等の車両管理にかかる一切の業務を請け負う車両運行管理業務がある。

この形態の請負業務では、運転者の労務管理の一切は業務請負会社の車両管理責任者が行い、ユーザから直接業務の指示命令を受けることは禁じられている。従って、運行時間や行き先等の運行計画を変更したい場合、車両の運行中であっても、ユーザが直接運転者に行き先等の変更を指示することは禁じられている。

従来、業務請負会社に車両の運行を依頼する場合、運行計画が記載された運行管理依頼書を、郵便またはＦＡＸを用いてユーザから業務請負会社に送付していた。そして依頼書を受け取った業務請負会社は、運転者に運行指図書を郵便またはＦＡＸを用いて送付していた。

しかし、このような手続きは極めて非効率であり、ユーザの依頼に迅速に対応することが難しかった。特に、運転中に行き先等の変更が生じた場合、一旦自動車を止め、携帯電話等を用いてユーザが車両管理責任者に連絡し、責任者の承認を得た後でなければ運行を再開することができないため、ユーザから強く改善が求められていた。

本発明は上述の状況に鑑みてなされたもので、ユーザの依頼に迅速に対応でき、更には、運行計画の変更にも柔軟に対応でき、しかも労働者派遣に関する法令の要件をも満足できる運行管理方法および運行管理システムを提供することを目的とする。

上記目的を達成するため本発明にかかる運行管理方法は、
自己の所有する車両の運行管理を業務請負会社に依頼したいユーザが、第１のコンピュータを用い、ネットワークを介して前記業務請負会社が運営するサーバにアクセスし、車両の運行計画のデータを送信する第１のステップと、
前記業務請負会社の車両管理責任者が、前記サーバで受信した前記運行計画の内容を確認すると共に、前記車両の運転手の確定と運行計画の承認を行う第２のステップと、
前記車両管理責任者が、前記サーバを用い、ネットワークを介して前記確定した運転手が使用する第１のスマートフォンに、運行計画が承認されたことを通知する第３のステップと、
前記運行計画承認の通知を受けた運転手が、前記第１のスマートフォンを用い、ネットワークを介して前記サーバにアクセスし、前記承認された運行計画の内容を確認する第４のステップと、を含むことを特徴とする。

ここで、前記サーバには、少なくとも２つのデータベースが接続され、そのうち第１のデータベースには前記運行計画の情報が格納され、第２のデータベースには前記運転手に関する情報が格納されていることが好ましい。

また前記第２のステップにおいて、前記サーバは、前記車両管理責任者が使用する第２のコンピュータに、前記ユーザから運行計画の依頼があったことを通知し、前記車両管理責任者は、前記第２のコンピュータを用いて前記サーバにアクセスし、前記運行計画の確認、運転手の確定および運行計画の承認の各手続きを行うことが好ましい。

なお、前記第１のステップにおいて、前記ユーザは、前記第１のコンピュータに代え、前記車両に備え付けの携帯型コンピュータを用いて前記サーバに前記運行計画の情報を送信してもよい。

また前記第２のステップにおいて、前記車両管理責任者は、前記第２のコンピュータに代え、第２のスマートフォンを用いて前記運行計画の確認、運転手の確定および運行計画の承認の各手続きを行ってもよい。

また前記第１のステップにおいて、ユーザは既に承認された運行計画の変更を依頼する場合、当該運行計画が終了する前であれば、前記サーバに運行計画のデータを送信して運行計画の変更を依頼できることが好ましい。

また前記第１のステップにおいて、前記車両の運転手が前記サーバにアクセスして運行計画の内容を確認する場合、運行計画の依頼があった事実が、時間と共に前記第１のスマートフォンの画面に表示されることが好ましい。

また前記サーバから前記第２のスマートフォンへの通知は、緊急度に応じて制限されることが好ましい。

また本発明にかかる運行管理システムは、
車両の運行管理を業務請負会社に依頼したいユーザが所有する第１のコンピュータと、
ネットワークを介して前記第１のコンピュータに接続された、前記業務請負会社が運営するサーバと、
ネットワークを介して前記サーバに接続された、前記車両の運転手が使用する第１のスマートフォンと、を備え、
前記ユーザは前記第１のコンピュータを用いて、前記サーバに前記運行計画のデータを送信し、
前記業務請負会社の車両管理責任者は、前記サーバで受信した前記運行計画の内容を確認すると共に、前記車両の運転手の確定と運行計画の承認を行い、
前記車両管理責任者は、前記サーバを用いて、前記第１のスマートフォンに、運行計画が承認されたことを通知し、
前記運行計画承認の通知を受けた運転手は、前記第１のスマートフォンを用いて前記サーバにアクセスし、前記承認された運行計画の内容を確認することを特徴とする。

本発明にかかる運行管理方法およびシステムによれば、労働者派遣に関する法令の要件を満たした上で、ユーザの依頼に迅速に対応でき、しかも運行計画の急な変更にも柔軟に対応できる運行管理システムを実現できる。

本発明の実施の形態にかかる運行管理システムの全体構成を示すブロック図である。 本発明の運行管理方法における処理の流れを示すフローチャートである。 図２のステップＳ２１の処理の流れを示すフローチャートである。 運行計画が表示されたパーソナルコンピュータの画面を示す図である（その１）。 運行計画が表示されたパーソナルコンピュータの画面を示す図である（その２）。 運行計画の承認が通知されたスマートフォンの画面を示す図である（その１）。 運行計画が表示されたスマートフォンの画面を示す図である（その１）。 運行計画が表示されたパーソナルコンピュータの画面を示す図である（その３）。 運行計画が表示されたパーソナルコンピュータの画面を示す図である（その４）。 運行計画の承認が通知されたスマートフォンの画面を示す図である（その２）。 運行計画が表示されたスマートフォンの画面を示す図である（その２）。 スマートフォンの画面に表示された運行計画の予告例を示す図である（その１）。 スマートフォンの画面に表示された運行計画の予告例を示す図である（その２）。 夜間または休日においてユーザから運行計画の依頼があった場合の車両管理責任者への通知の形態を示す図である。

以下、本発明の実施の形態にかかる運行管理方法および運行管理システムについて、図面を参照しながら説明する。

＜運行管理システムの構成＞
図１に、本実施の形態にかかる運行管理システムの全体構成を示す。運行管理システム１は、業務請負会社２が運営するサーバ２１およびパーソナルコンピュータ（以降、単に「ＰＣ」という）２２、夜間や休日に車両管理責任者２Ｐが運行管理サーバ２１にアクセスする際に用いるスマートフォン２３、社用車等の車両の運行管理を依頼するユーザ３が所有するＰＣ３１およびタブレットＰＣ３２、車両４を運転する運転手４Ｄが使用するスマートフォン４１、車両４に備え付けられ、行き先等の変更が生じたとき、乗車中のユーザの社員４Ｐがサーバ２１にアクセスするために用いるタブレットＰＣ４２、ならびに通信ネットワークであるインターネット５および携帯通信網６で構成されている。

車両４の運行管理を請け負う業務請負会社２は、車両４に配属した運転手４Ｄに運行指示を出す。業務請負会社２には、車両４の運行管理を行う運行管理室２Ｒが設けられ、その部署には、運行計画の承認等を行う車両管理責任者２Ｐが常駐している。

車両の運行管理に用いられるサーバ２１にはＷｅｂサーバソフトがインストールされており、インターネット５を介して、ユーザ３のＰＣ３１との間で通信を行うことができる。サーバ２１として、通常、業務請負会社２が所有するサーバを用いる。

サーバ２１にはデータベースマネジメントシステムがインストールされており、３つのデータベース（以降、「ＤＢ」と略す）２４〜２６へのデータの書き込みおよび読み出しを管理している。３つのＤＢのうち運行計画ＤＢ２４には車両の運行計画に関する情報が格納されている。顧客情報ＤＢ２５にはユーザに関する情報が格納されている。また運転手情報ＤＢ２６には、運転手に関する情報が格納されている。

運行管理室２６には、ＷｅｂブラウザソフトがインストールされたＰＣ２２が設置されている。車両管理責任者２Ｐは、このＰＣ２２を用いてサーバ２１にアクセスし、運行計画ＤＢ２４に格納された運行計画の内容を読み出して確認し、車両を運転する運転手を確定した後、運行計画を承認する。

ユーザ３の所有するＰＣ３１にはＷｅｂブラウザソフトがインストールされており、インターネット５を介してサーバ２１との間で通信を行うことができる。車両の運行管理を依頼したいユーザ３は、サーバ２１にアクセスし、運行計画の入力ページを開いて必要なデータを入力する。

ユーザ３はタブレットＰＣ３２を用いてサーバ２１にアクセスすることもできる。タブレットＰＣ３２は平板状の外形を有し、タッチパネル式の表示／入力部を備えた携帯可能なＰＣであり、ＰＣ３１と同様にＷｅｂブラウザソフトがインストールされている。

ユーザ３がタブレットＰＣ３２を用いてサーバ２１にアクセスする場合、通常は、契約済みの携帯電話会社の携帯通信網６とインターネット５を介してアクセスする。なお、図では、ユーザ３として３社が表示されているが、実際には、多数のユーザ３がＰＣ３１またはタブレットＰＣ３２を用いてサーバ２１にアクセスできる。

ユーザ３の車両４には、業務請負会社２の従業員であり、車両管理責任者２７から運行の指示を受けた運転手４Ｄと、ユーザ３の社員４Ｐが乗車している。運転手４Ｄは、常時、スマートフォン４１を携帯している。スマートフォンは、ユーザインタフェースにＬＣＤ画面とタッチパネルを用いた多機能型の携帯電話機である。

また車両４には、ユーザ社員４Ｐが使用するタブレットＰＣ４２が備え付けられている。マートフォン４１およびタブレットＰＣ４２は、携帯通信網６およびインターネット５を介してサーバ２１との間で通信を行うことができる。

運転手４１は、車両４の運行前および運行中にスマートフォン４１を用いてサーバ２１にアクセスし、車両管理責任者２Ｐに承認された運行計画の内容を確認し、その内容に基づいて車両４の運転を行う。

車両４に備え付けのタブレットＰＣ４２は業務請負会社２が所有するもので、乗車中のユーザ社員４Ｐに貸与される。ユーザ社員４Ｐは、事前に計画した行く先等を変更したい場合、タブレットＰＣ４２を用いてサーバ２１にアクセスし、運行計画の変更について、車両管理責任者２Ｐの承認を得る。

車両管理責任者２Ｐは、夜間または休日に、ユーザ３から運行計画の承認を求められる場合に対応するため、常時、スマートフォン２３を携帯している。車両管理責任者２Ｐは、スマートフォン２３を用い、携帯通信網６およびインターネット５を介してサーバ２１との間で通信を行うことができる。

＜運行管理における処理の流れ＞
次に、図２および図３のフローチャートを参照して、ユーザから運行管理の依頼があったときの処理の流れを説明する。図２は、運行管理における処理の流れを示すフローチャート、図３は、図２のステップＳ２１「運行計画の確認・承認」の流れを示すフローチャートである。

自社の車両の運行管理を業務請負会社２に依頼したいユーザ３は、予め業務請負会社２との間で請負契約を締結すると共に、サーバ２１にユーザ（顧客）として登録しておく必要がある。ユーザ登録の方法は周知であるため、ここでは説明を省略する。ユーザ登録により、ユーザ３はユーザＩＤを取得し、またパスワードを設定する。

最初に、自社の車両の運行を依頼するユーザ３は、ＰＣ３１を用いて業務請負会社２のサーバ２１にアクセスしてログインの処理を行う（ステップＳ１１）。ログインの処理は、上述のユーザＩＤおよびパスワードを用いて行うが、一般に広く知られているため説明を省略する。

ユーザ３の担当者が運行計画入力用のページを開くと、そのページのハイパーテキストデータがサーバ２１からＰＣ３１に送信され、ＰＣの画面に運行計画入力用の画面が表示される。ユーザ３の担当者は、キーボード等を用いて依頼したい運行計画を入力する（ステップＳ１２）。

図４に、運行計画が入力された画面の例を示す。画面には、顧客名、車両ナンバー、運行日、運行計画（開始時間、目的地、終了時間）およびステータスが表示されている。

画面に表示された運行計画の内容を簡単に説明すると、２０１４年１月２４日に株式会社ＡＢＣの社用車（車両Ｎｏ．や○○○○）を用いて、以下のスケジュールで社長の送迎を行うものである。
（１）９時に本社を出発し、新大阪駅に寄った後、９時４０分に本社に戻る。
（２）１０時３０分に本社を出発し、銀行協会と京町堀クラブに寄った後、１１時３ ０分に本社に戻る。
（３）１６時３０分に本社を出発し、１７時３０分に社長を自宅まで送る。
（４）１７時３０分に社長の自宅を出発し、１８時３０分に本社に戻る。

運行計画を入力したい場合には、マウスを用いて画面の「行追加」のボタンをクリックすると、新たな行が表示される。１行毎に計画を入力した後、「依頼」のボタンをクリックすると、そのデータがサーバ２１に送信される。入力した計画を削除したいときは「キャンセル」のボタンをクリックする。また入力したデータをサーバ２１に一括して送信したいときは「一括依頼」のボタンをクリックする。

運行計画を入力した後、ユーザ３の担当者が「依頼」もしくは「一括依頼」のボタンをクリックすると、入力された運行計画のデータがサーバ２１に送信されると共に（ステップＳ１２）、画面のステータスが「入力中」から「依頼中」（図示せず）に変わる。サーバ２１に送信された運行計画のデータは、運行計画ＤＢ２４に格納される。

ユーザ３から車両の運行管理の依頼を受け、サーバ２１で運行計画のデータを受信した後、業務請負会社２は運行計画の確認と承認の手続きを行う（ステップＳ２１）。

具体的には、図３に示すように、ユーザ３のＰＣ３１から送信された運用計画のデータを受信すると、サーバ２は運行管理室２ＲのＰＣ２１に電子メールを送信して、車両管理責任者２Ｐに運行の依頼があったことを通知する（ステップＳ４１）。

依頼の通知を受け取った車両管理責任者２Ｐは、ＰＣ２２を用いてサーバ２１にアクセスし、運行計画ＤＢ２３に格納された運行計画を読み出し、その内容を画面上で確認する（ステップＳ５１）。図５に運行計画を表示した画面を示す。

また車両管理責任者２Ｐは、運転手情報ＤＢ２６から運転手の情報を読み出し、運行日（１月２４日）に対象となる運転手を確定する。ユーザには、請負業務締結時に決めた運転手が常時駐在しているため、指定車輌が決まれば自動的に運転手が確定する。なお、複数の運転手が配属されているユーザもあるが、担当車輌を決めているため、運行依頼において車両が指定された時点で、自動的に運転手が確定する。

運転手の確定によって運行計画の承認が可能になった段階で（ステップＳ５２でｙｅｓ）、車両管理責任者２Ｐは、図５に示す画面の「承認」または「一括承認」のボタンをクリックして運行計画を承認する（ステップＳ５３）。

運行計画が承認されると、画面のステータスが「承認済」に変わる。併せて、図４に示す入力画面のステータスも、「入力中」から「承認済」（図示せず）に変わり、ユーザ３の担当者は、ステータスの変更によって運行計画が承認されたことを確認できる。

なお、運行計画の入力ミスがあったり、運行計画そのものに無理がある場合は運行計画を承認できないが（ステップＳ５２でＮｏ）、このような場合は、車両管理責任者２Ｐが電話等を用いてユーザ３の担当者に連絡し、データの修正や日程の変更等を依頼する（ステップＳ５４）。

運行計画が承認されると、サーバ２１は、運行日まで何日残されているか算出し、運行日まで○日（例えば４日）以内である場合は（ステップＳ２２でＹｅｓ）、運転手４Ｄのスマートフォン４１に電子メールを送信して、運行計画が承認されたことを通知する（ステップＳ２３）。

図６に、運転手４Ｄのスマートフォンに送信された運行計画承認の画面を示す。運行計画承認の通知は、個別の計画ごとに行われ、図５に示したように１日に４件の運行計画がある場合は、運転手４Ｄには、計画毎に４件の電子メールが送信される。

なお、運行日まで（○＋１）日（例えば５日）以上あり、時間的に余裕がある場合は、運転手４Ｄへの運行計画承認の通知は行われない（ステップＳ２２でＮｏ）。これは、運転手４Ｄへのメールによる通知を必要最小限に留めるためであり、５日以上先のスケジュールについては、サーバ２１にアクセスして確認することが運転手４Ｄに義務付けられているため、日程を限定しても特に問題は生じない。

なお、運行計画承認の電子メールを送信する期間○日については、休日と祝日が続くときは長く設定する等、カレンダーに合わせて変更することができる。

電子メールで運行計画承認の通知を受けた運転手４Ｄは、承認された運行計画を確認したことを電子メールで運行管理室２ＲのＰＣ２２に報告する（ステップＳ３１）。更に、運転手４Ｄは、スマートフォン４１を用いてサーバ２１にアクセスし、指示された運行計画の内容を確認する（ステップＳ３２）。

図７に、スマートフォン４１の画面に表示された運行計画を示す。上述したように、運行計画承認の通知は個々の計画毎に行われるが、サーバにアクセスすれば、同じ運行日に承認された全ての運行計画を確認できる。なお、図７において、「前日」および「翌日」のボタンは、画面に前日または翌日の運行計画を表示するときに用いる。

スマートフォン４１の画面で運行計画を確認した後、運転手４Ｄはその計画に従って車両４を運転する（ステップＳ３３）。

上述したように、本発明にかかる運行管理方法によれば、運行計画の送信、同計画の承認、運転手への通知等を、円滑にかつ短時間で処理できる。例えば、運行計画のデータ受信後、数分で運行計画の承認を行い、運行計画承認の通知を運転手に送信できる。

＜運行計画に変更があったときの運行管理の処理の流れ＞
次に、運行計画に変更があった場合の運行管理の処理の流れについて説明する。基本的に運行管理の処理の流れは、図２および図３のフローチャートにより説明した流れと変わりがない。

運行計画が変更される例として、以下のような場合がある。
・天候の関係で搭乗便や列車の到着が遅くなった。
・取引先での会議が延び、終了時間が大幅に遅れた。
・取引先訪問の予定がキャンセルになった。

このような場合、ユーザ３の担当者は、ＰＣ３１またはタブレットＰＣ３２を用いてサーバ２１にアクセスし、ログインの手続きを終えた後（ステップＳ１１）、承認済みの運行計画を運行計画ＤＢ２３から読み出す。ユーザ３の担当者は、読み出された運行計画に対して、変更したい箇所を上書きする（ステップＳ１２）。

図８に、変更箇所が上書きされた運行計画の画面を示す。画面では、運行計画の「１６時３０分に本社を出発し、１７時３０分に社長を自宅まで送る。」が、「１６時３０分に本社を出発し、ＪＲ京都駅に寄った後、１８時００分に社長を自宅まで送る。」に変更されている。更に、運行計画の「１７時３０分に社長の自宅を出発し、１８時３０分に本社に戻る。」が、「１８時００分に社長の自宅を出発し、１９時００分に本社に戻る。」に変更されている。
図８に示すように、計画を上書きした箇所のステータスが「承認済」から「依頼中」に変わっており、この部分だけ、計画が未承認であることを示している。

なお、計画変更の手続きは、車両４に乗車中のユーザ社員４Ｐが行うこともできる。この場合、車両４に備え付けのタブレットＰＣ４２を用いてサーバ２１にアクセスし、ＰＣ３１を用いた場合と同様の手順で運行計画の変更を入力する。

計画変更の手続きは、各運行計画が終了する前であれば、運行計画の実行中であっても行うことができる。乗車中に行き先や到着時間を変更したい場合が頻繁に発生する。このような場合、従来は、一旦車両を停め、乗車中のユーザ社員４Ｐが携帯電話で運行管理責任者２Ｐに連絡をとり、変更内容を説明して計画変更の承認を得た後、運行管理責任者２Ｐから運転手４Ｄに運行指示をしてもらっていた。

運行管理責任者２Ｐに連絡がとれれば、計画変更の承認を得ることができるが、連絡がとれない場合、連絡が取れるまで停車を続けるか、変更前の計画に従って運行せざるを得ず、実務上、運用に適し難い実態であった。

本発明にかかる運行管理システムによれば、運行計画の実行中であっても計画変更の承認を求めることができるため、このような場合に、状況に応じて柔軟かつ迅速に対応することができる。

図２の説明に戻って、運行管理サーバ２１からの電子メールによって運行計画変更の通知を受けた車両管理責任者２Ｐは（ステップＳ４１）、サーバ２１にアクセスして運行計画の変更内容を確認する（ステップＳ５１）。

運行計画の変更内容を確認した結果、承認が可能であれば（ステップＳ５２でＹｅｓ）、車両管理責任者２Ｐは、ＰＣ２１を用いて計画の承認をサーバ２１に通知する（ステップＳ５３）。

図９に、計画の変更が承認された運行計画の画面を示す。運行計画の「１６時３０分に本社を出発し、ＪＲ京都駅に寄った後、１７時３０分に社長を自宅まで送る。」のステータスが「承認済」に変わっており、代わりに、「１６時３０分に本社を出発し、１７時３０分に社長を自宅まで送る」のステータスから「承認済」の表示が削除されている。同様に、「１８時００分に社長の自宅を出発し、１９時００分に本社に戻る。」のステータスが「承認済」に変わり、「１７時３０分に社長の自宅を出発し、１８時３０分に本社に戻る。」のステータスから「承認済」の表示が削除されている。

運行計画の変更が承認されると、図２で示したように、サーバ２１から運転手４Ｄのスマートフォン４１に電子メールが送信され、運転手４Ｄに運行計画の変更が承認されたことを通知する（図２のステップＳ２３）。

図１０に、運転手のスマートフォンに通知された運行計画変更承認の画面を示す。 今回は、２つの運行計画の変更が承認されたため、もう１つの運行計画の変更についても、図１０に示したものと同様の通知が運転手４Ｄのスマートフォン４１に送られる。電子メールで運行計画承認の通知を受けた運転手４Ｄは、サーバ２１にアクセスし、承認された運行計画の内容を確認する（図２のステップＳ３２）。

図１１に、スマートフォン４１の画面に表示された計画変更後の運行計画を示す。スマートフォン４１の画面で運行計画を確認した後、運転手は、その計画に従って、引き続き車両４を運転する（図２のステップＳ３３）。

本実施の形態にかかる運行管理システムによれば、乗車中のユーザ社員４ＰがタブレットＰＣ４２を用いて運行計画の変更手続きを行ってから、運転手４Ｄがスマートフォン４１で計画変更の内容を確認するまで、早ければ数分で手続きが完了するため、乗車中に運行計画を変更する必要が生じても、柔軟かつ迅速に対応できる。

＜運行計画の予告＞
次に、図１２および図１３を参照して、運行計画の予告について説明する。前述したように、ユーザ３が車両４の運行を依頼する場合、業務請負会社２のサーバ２１にアクセスして運行計画を入力する（図４参照）。この段階では、運転手４Ｄには運行計画の通知は行われないが、運転手から今後のスケジュールについて確認したいという要望がある。

本実施の形態にかかる運行管理システムでは、このような要望に応えるため、運転手４Ｄがサーバ２１にアクセスしたとき、運行計画の依頼があった事実とその日時を運転手に知らせるようにしている。

図１２および図１３に、運転手のスマートフォン４１の画面に表示された運行計画の予告例を示す。図１２に示すように、運行計画の依頼があった場合、画面には、予定日毎に依頼の事実とその時間が表示される。また図１３に示すように、運行計画変更の依頼があった場合も、予定日毎に依頼の事実とその時間が表示される。

運転手４Ｄは、サーバ２１にアクセスして依頼状況を確認することにより、予定日毎に運行計画が入る可能性があること、もしくは運行計画の変更の可能性があることを確認できるため、それに合わせて予定日のスケジュールを調整することができる。

＜運行管理責任者へのメール通知の制限＞
図１４に、夜間または休日において、ユーザ３から運行計画の依頼があった場合に、車両管理責任者２Ｐへの通知の形態を示す。前述したように、車両管理責任者２Ｐは、夜間または休日にユーザ３から運行計画の承認を求められた場合に対応するため、常時、スマートフォン２３を携帯している。以下、図１４を参照して、運行計画の緊急度に応じた対応について説明する。

夜間または休日に、ユーザ３から、図中Ａで示す翌日の朝６時〜７時の運行計画の依頼があった場合、サーバ２１は、依頼があったことを車両管理責任者２Ｐのスマートフォン２３に電子メールで通知する。

通知を受け取った車両管理責任者２Ｐは、サーバ２１にアクセスし、図２のフローに従って運行計画承認の処理を行い、その結果は、直ちに運転手４Ｄのスマートフォン４１に通知される。運転手４Ｄは、承認された運行計画に沿って朝６時から車両を運転する。

一方、図中Ｂで示す翌日の午前１０時〜１２時の運行計画について前日の夜間または休日に依頼があった場合、サーバ２１は、車両管理責任者２Ｐに電子メールを送信しない。これは、翌日の朝、車両管理責任者２Ｐが出社した後、運行管理室２ＲのＰＣ２２を用いて運行計画の承認を行っても、車両４の運行に支障がないためである。

このように、運行計画の緊急度に応じて車両管理責任者２Ｐへの通知を制限することにより、車両管理責任者２Ｐの負担軽減を図ることができる。

１ 運行管理システム
２、業務請負会社
３、ユーザ
４ 車両
５、インターネット
６ 携帯通信網
２１ サーバ
２２、３１ ＰＣ
２３、４１ スマートフォン
３２、４２ タブレットＰＣ
２４、２５、２６ ＤＢ
２Ｐ 車両管理責任者
４Ｄ 運転手
４Ｐ ユーザ社員

Claims (11)

1. 自己の所有する車両の運行管理を業務請負会社に依頼したいユーザが、第１のコンピュータを用い、ネットワークを介して前記業務請負会社が運営するサーバにアクセスし、車両の運行計画のデータを送信する第１のステップと、
   前記業務請負会社の車両管理責任者が、前記サーバで受信した前記運行計画の内容を確認すると共に、前記車両の運転手の確定と運行計画の承認を行う第２のステップと、
   前記車両管理責任者が、前記サーバを用い、ネットワークを介して前記確定した運転手が使用する第１のスマートフォンに、運行計画が承認されたことを通知する第３のステップと、
   前記運行計画承認の通知を受けた運転手が、前記第１のスマートフォンを用い、ネットワークを介して前記サーバにアクセスし、前記承認された運行計画の内容を確認する第４のステップと、を含むことを特徴とする運行管理方法。
2. 前記サーバには、少なくとも２つのデータベースが接続され、そのうち第１のデータベースには前記運行計画の情報が格納され、第２のデータベースには前記運転手に関する情報が格納されている、請求項１に記載の運行管理方法。
3. 前記第２のステップにおいて、
   前記サーバは、前記車両管理責任者が使用する第２のコンピュータに、前記ユーザから運行計画の依頼があったことを通知し、
   前記車両管理責任者は、前記第２のコンピュータを用いて前記サーバにアクセスし、前記運行計画の確認、運転手の確定および運行計画の承認の各手続きを行う、請求項１または２に記載の運行管理方法。
4. 前記第１のステップにおいて、前記ユーザは、前記第１のコンピュータに代え、前記車両に備え付けの携帯型コンピュータを用いて前記サーバに前記運行計画の情報を送信する、請求項１ないし３のいずれかに記載の運行管理方法。
5. 前記第２のステップにおいて、前記車両管理責任者は、前記第２のコンピュータに代え、第２のスマートフォンを用いて前記運行計画の確認、運転手の確定および運行計画の承認の各手続きを行う、請求項３または４に記載の運行管理方法。
6. 前記第１のステップにおいて、ユーザは既に承認された運行計画の変更を依頼する場合、当該運行計画が終了する前であれば、前記サーバに運行計画のデータを送信して運行計画の変更を依頼できる、請求項１ないし５のいずれかに記載の運行管理方法。
7. 前記第１のステップにおいて、前記車両の運転手が前記サーバにアクセスして運行計画の内容を確認する場合、運行計画の依頼があった事実が、時間と共に前記第１のスマートフォンの画面に表示される、請求項１ないし６のいずれかに記載の運行管理方法。
8. 前記サーバから前記第２のスマートフォンへの通知は、緊急度に応じて制限される、請求項５に記載の運行管理方法。
9. 車両の運行管理を業務請負会社に依頼したいユーザが所有する第１のコンピュータと、
   ネットワークを介して前記第１のコンピュータに接続された、前記業務請負会社が運営するサーバと、
   ネットワークを介して前記サーバに接続された、前記車両の運転手が使用する第１のスマートフォンと、を備え、
   前記ユーザは前記第１のコンピュータを用いて、前記サーバに前記運行計画のデータを送信し、
   前記業務請負会社の車両管理責任者は、前記サーバで受信した前記運行計画の内容を確認すると共に、前記車両の運転手の確定と運行計画の承認を行い、
   前記車両管理責任者は、前記サーバを用いて、前記第１のスマートフォンに、運行計画が承認されたことを通知し、
   前記運行計画承認の通知を受けた運転手は、前記第１のスマートフォンを用いて前記サーバにアクセスし、前記承認された運行計画の内容を確認することを特徴とする運行管理システム。
10. 前記サーバには、少なくとも２つのデータベースが接続され、そのうち第１のデータベースには前記運行計画の情報が格納され、第２のデータベースには前記運転手に関する情報が格納されている、請求項９に記載の運行管理システム。
11. 前記車両には携帯型コンピュータが備え付けられており、前記車両に乗車中のユーザは、前記第１のコンピュータに代え、前記携帯型コンピュータを用いて前記サーバに前記運行計画の情報を送信する、請求項９または１０に記載の運行管理システム。

Images