JP7293485B1 - 配送管理を行うためのプログラム、装置、及び、方法 - Google Patents

Abstract

【課題】当日の追加の配送依頼に対応する配送管理を行うためのプログラム、装置及び方法を提供する。【解決手段】プログラムは、所定の日の第１の配送計画のデータを作成する工程Ｓ０１と、当該所定の日に、第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する工程Ｓ０２と、当該所定の日に、且つ、配送の実施の開始後に、追加の配送依頼のデータを取得する工程Ｓ０３と、追加の配送依頼のデータを、配送計画取り込み待ちデータとして記憶する工程Ｓ０４と、実施状況のデータと、配送計画取り込み待ちデータとに少なくとも基づいて、追加の配送を割り当てる対象となる候補ドライバー及び候補車両のうちいずれかを抽出する工程Ｓ０５と、抽出された候補ドライバー及び候補車両のうちいずれかから、少なくとも１人の特定のドライバー及び少なくとも１台の特定車両のうちいずれかを指定する工程Ｓ０６と、をプロセッサに実行させる。【選択図】図３

Description

本開示は、配送管理を行うためのプログラム、装置、及び、方法に関する。

物流業界において、配送管理は重要である。荷物の集荷及び配送を行う日の前日までに、配送依頼を受け取り、これに基づいて、当日の配送計画を作成する。配送に関わる条件は多種多様であり、その条件は、荷物自体の条件（例えば、集荷先到着予定時刻、配送先到着予定時刻、荷物の重量等）、ドライバー側の条件（連続勤務時間、積載量等）も含む。

荷物側の条件と、ドライバー側の条件とを、システムを用いてマッチングさせる種々の仕組みが公開されている。例えば、特許文献１では、荷主から依頼され、現時点から少なくとも明日以降の将来の日を集配送日とする配送依頼情報を、配送車両の将来の運行予定に組み込むための配車マッチング処理を行う配車マッチング部を有する運送管理システムが開示されている。

特開２０１７－１６５５１０号公報

前日までに配送依頼が到着していれば、配送計画を立て、それに基づいて、配送計画を遂行していくことはさほど困難ではない。しかし、現実には、様々なアクシデントがあり、配送計画が狂うことが多々ある。要因の一例としては、配送当日に、緊急の配送依頼が発生することが挙げられる。この場合、既に配送計画ができ上がっており、これに基づいて、各ドライバーは業務遂行を開始しているので、システムに組み込まれた配送計画を変更することは困難となる。

仮に、手動で変更できるようにシステム側で対応していたとしても、こうした緊急の依頼が、複数件あった場合には、ユーザの手動による変更作業では、対応しきれない。

こうした状況に鑑み、本開示は、当日の追加の配送依頼に対応できる仕組みを提供することを目的とする。

上記目的を達成するため、本開示は、一側面において、以下の発明を提供する。

（発明１）
配送管理を行うためのプログラムであって、前記プログラムは、情報処理装置のプロセッサに命じて、以下を含む工程を実行させることが可能である、プログラム。
・所定の日の第１の配送計画のデータを作成する工程、
・当該所定の日に、前記第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する工程、
・当該所定の日に、且つ、前記配送の実施の開始後に、追加の配送依頼のデータを取得する工程、ここで、当該追加の配送依頼のデータは、当該所定の日に配送することが必要な配送依頼のデータである、
・前記追加の配送依頼のデータを、配送計画取り込み待ちデータとして記憶する工程、
・前記実施状況のデータと、前記配送計画取り込み待ちデータとに少なくとも基づいて、追加の配送を割り当てる対象となる候補ドライバー及び候補車両のうちいずれかを抽出する工程、
・前記抽出された候補ドライバー及び候補車両のうちいずれかから、少なくとも１人の特定のドライバー及び少なくとも１台の特定車両のうちいずれかを指定する工程、
・前記指定されたドライバー又は車両の配送状況と、前記配送計画取り込み待ちデータとに少なくとも基づいて第２の配送計画のデータを作成する工程、
ここで、配送対象の荷物のデータを、配送可能な単位に分割して、前記指定されたドライバーに割り当てることができる。

（発明２）
発明１のプログラムであって、
前記抽出する工程が、以下の条件のいずれか１つに少なくとも当てはまる場合には、ドライバー及び車両のうちいずれかを候補として抽出しないことを含む、プログラム。
・すでに当該所定の日の業務が終了している
・追加の配送を割り当ててしまうと、当該配送及び別の配送依頼のうち少なくともいずれかの条件をみたすことが不可能になる
・追加の配送を割り当ててしまうと、積載量がオーバーしてしまう

（発明３）
発明２のプログラムであって、
前記抽出する工程が、以下の条件に少なくとも当てはまる場合には、ドライバーを候補として抽出することを含む、プログラム。
・追加の配送に係る集荷先に到達した時点での空き容量が、前記配送可能な単位よりも大きい

（発明４）
発明１～３いずれか１つに記載のプログラムであって、
前記抽出する工程が、割り込み配送を許容したうえで抽出することを含む、プログラム。

（発明５）
発明１～４いずれか１つに記載のプログラムを備える装置。

（発明６）
発明１～４いずれか１つに記載のプログラム、又は、発明５の装置を用いて、配送管理を行う方法。

一側面において、上記発明は、第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する。これにより、当日の追加の配送依頼を、どのドライバーに割りあてればよいかの判断が可能となる。

一実施形態における本開示のシステムの構成を示す。 一実施形態における本開示の情報処理装置の構成を示す。 一実施形態における本開示の方法のフローを示す。 一実施形態における本開示の配送計画データのコンテンツを示す。 一実施形態における本開示の配送の実施状況のデータのコンテンツを示す。 一実施形態における本開示の追加の配送依頼のデータのコンテンツを示す。 一実施形態における本開示の配送計画取り込み待ちデータのコンテンツを示す。 一実施形態における本開示のインターフェースを示す。当該インターフェースでは、追加の配送依頼の情報、配送状況の情報、及び、候補ドライバーの情報が表示される。また、追加の配送依頼の情報を取り込む処理を開始するためのボタン（「依頼取込」ボタン）、配送状況の情報を表示する処理を開始するためのボタン（「現状確認」ボタン）、ドライバーに荷物を割り当てる処理を開始するためのボタン（「割り当て」）も表示される。 一実施形態における本開示のインターフェースを示す。当該インターフェースでは、店舗情報、集荷先、配送先の位置関係などが視覚的に表現される。 一実施形態における本開示の第１の配送計画データのコンテンツを示す。 一実施形態における本開示の第２の配送計画データのコンテンツを示す。 一実施形態における本開示のインターフェースを示す。当該インターフェースでは、追加の配送依頼の情報、配送状況の情報、及び、候補ドライバーの情報が表示される。また、追加の配送依頼の情報を取り込む処理を開始するためのボタン（「依頼取込」ボタン）、配送状況の情報を表示する処理を開始するためのボタン（「現状確認」ボタン）、ドライバーに荷物を割り当てる処理を開始するためのボタン（「割り当て」）も表示される。 一実施形態における本開示のインターフェースを示す。当該インターフェースは、追加の配送依頼の一部を、特定のドライバーに割り当てるためのものである。 一実施形態における本開示の配送割り当て済みデータのコンテンツを示す。

以下、発明を実施するための具体的な実施形態について説明する。以下の説明は、発明の理解を促進するためのものである。即ち、本発明の範囲を限定することを意図するものではない。

１．システム
一実施形態において、本開示は、配送管理システムに関する。別の一実施形態において、本開示は、配送管理システムを構成するサーバに関する。また、更に別の一実施形態において、本開示は、配送管理システムを構成する端末に関する。また、更に別の一実施形態において、本開示は、配送管理システムを構成するサーバ及び端末のうちいずれかにインストールされるプログラムに関する。また、更に別の一実施形態において、本開示は、当該プログラムが記憶された非一時的記憶媒体（例えば、ハードディスク、光学ディスク、フラッシュメモリ等）に関する。また、更に別の一実施形態において、本開示は、配送管理を行う方法に関する。

一実施形態におけるシステム構成を図１に示す。システムは、少なくとも１つのサーバと、少なくとも１つの第１端末と、複数の第２端末とを備える。これらは、ネットワークを通して相互に接続される。ネットワークは、有線ネットワークでもよく、無線ネットワークでもよく、或いは、両者の組み合わせでもよい。

サーバ、第１端末、及び、第２端末は、典型的な情報処理装置で構成されてもよい。典型的な情報処理装置の構成を、図２に示す。情報処理装置は、少なくともプロセッサ、メモリ、非一時的記憶媒体、通信モジュールを備える。プロセッサは、プログラムを読み込んで実行することができる。メモリは、一時的に情報を格納する媒体であり、典型的にはＲＡＭ等が挙げられる。非一時的記憶媒体は、典型的には、ＨＤＤ、ＳＳＤ、フラッシュメモリドライブ（例えば、ＵＳＢメモリ）などによって実装されてもよい。非一時的記憶媒体は、メモリとは異なり、電源の供給が途絶えても、記憶を保持することができる。通信モジュールは、ネットワークに接続して、外部との信号の送受信を行うためのモジュールである。

サーバには、配送管理のプログラムがインストールされる。当該プログラムを実行することにより、サーバは、配送管理に関する一連の処理を実行することができる。処理内容の例としては、配送依頼の受領、配送計画の作成、配送計画の修正、配送計画のマッチング、配送計画の進捗管理、請求書の発行等が挙げられるがこれらに限定されない。

第１端末は、配送管理を担当する第１ユーザが操作するための端末である。第１端末は、配送管理システムへのアクセスモジュールを備える。当該モジュールは、配送管理のためのインターフェースを提供することができる。当該インターフェースを通して、第１ユーザは、サーバの配送管理のプログラムと通信し、配送管理を行うことができる。例えば、第１ユーザは、上述した、配送依頼の受領、配送計画の作成、配送計画の修正、配送計画のマッチング、配送計画の進捗管理、請求書の発行等の処理を行うことができる。

第２端末は、配送を行うドライバーが使用する端末である。ドライバーは、常に場所の移動をともなう。したがって、第２端末は、図２の構成に加えて、ＧＰＳモジュールを備える。ＧＰＳモジュールは、ＧＰＳと通信して現在位置の情報を取得することができる。また、第２端末は、サーバ等へ、当該情報を送信することができる。

また、第２端末は、配送の状況をリアルタイムでサーバに送ることができる。具体的には、集荷作業、及び／又は、配送作業が完了するたびに、第２端末を操作して、当該作業が完了した旨を知らせることができる。そして、当該操作に応答して、第２端末は、本日の配送計画のうち、どこまで終了したのかに関する情報を、サーバ等に送信することができる。

サーバ及び第１端末は、上述した情報処理装置によって実装することができる。例えば、サーバ及び第１端末は、サーバ、パソコン、ノートパソコン、スマートフォン、タブレット端末等を用いて、実装することができる。

第２端末は、ＧＰＳモジュールを備える情報処理装置によって実装することができる。ただし、第２端末は、サーバ及び第１端末とは異なり、ある程度の携行性も要求される。したがって、例えば、第２端末は、ノートパソコン、スマートフォン、タブレット端末等を用いて、実装することができる。

あるいは、第２端末は、自動車などに組み込まれてもよい。例えば、カーナビシステムの拡張モジュールとして実装されてもよい。

２．配送管理の流れ
一実施形態において、配送管理に関する方法は、少なくとも以下のステップを含む。そして、各ステップは、サーバにインストールされたプログラムがプロセッサに命じることによって実行されてもよい（図３）。

・所定の日の第１の配送計画のデータを作成する工程（Ｓ０１）、
・当該所定の日に、第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する工程（Ｓ０２）、
・当該所定の日に、且つ、配送の実施の開始後に、追加の配送依頼のデータを取得する工程、ここで、当該追加の配送依頼のデータは、当該所定の日に配送することが必要な配送依頼のデータである（Ｓ０３）、
・追加の配送依頼のデータを、配送計画取り込み待ちデータとして記憶する工程（Ｓ０４）、
・実施状況のデータと、配送計画取り込み待ちデータとに少なくとも基づいて、追加の配送を割り当てる対象となる候補ドライバー及び候補車両のうちいずれかを抽出する工程（Ｓ０５）
・抽出された候補ドライバー及び候補車両のうちいずれかから、少なくとも１人の特定のドライバー及び少なくとも１台の特定車両のうちいずれかを指定する工程（Ｓ０６）、
・指定されたドライバー又は車両の配送状況と、配送計画取り込み待ちデータとに少なくとも基づいて第２の配送計画のデータを作成する工程（Ｓ０７）、
ここで、配送対象の荷物のデータを、配送可能な単位に分割して、指定されたドライバーに割り当てることができる。

以下では、各工程について詳述する。

２－１．第１の配送計画のデータを作成する工程（Ｓ０１）
第１の配送計画は、その計画の実施が開始される前に作成される計画である。本明細書において、第２又はそれ以降の配送計画は、その計画の実施が開始された後に作成される計画である。

例えば、第１の配送計画は、対象となる日付の前日までに作成されてもよい。あるいは、第１の配送計画は、対象となる日付の日の朝（ただし、その計画の実施が開始される前）までに作成されてもよい。

一方で、第２又はそれ以降の配送計画は、第１の配送計画の修正版に対応する。

配送計画のデータの形式は特に限定されないが、例えば、２次元の表形式であってもよい。配送計画のデータは、以下の項目に関する情報を含んでもよい：配送担当のドライバーの識別情報（例えば、氏名、ＩＤ等）、区分情報（例えば、出発、帰着、配送、集荷等）、集荷先位置情報（例えば、緯度経度の組み合わせ、住所等）、集荷先到着予定時刻、配送先位置情報（例えば、緯度経度の組み合わせ、住所等）、配送先到着予定時刻、荷物情報（例えば、荷物識別情報、数量、重さ、大きさ等）、経路情報、積載量（又は、積載率、空き率、空き容量）等。

第１の配送計画の一例を図４に示す。図４では特定のドライバーの配送計画が表現されている。担当ドライバー識別情報、移動ポイントへの到着時刻（集荷先到着予定時刻、配送先到着予定時刻等を含む）、区分情報、移動先の位置情報としての緯度経度の組み合わせ（集荷先位置情報、配送先位置情報等を含む）、荷物の識別情報、移動先までの経路の情報等が表現されている。図４に示す配送計画は、ドライバーごとに作成される。

そして、当該配送計画のデータは、サーバが備える非一時的記憶媒体（例えば、データベース）、又は、サーバ外の記憶場所（例えば、ストレージサーバ、クラウド等）に記憶されてもよい。以降で説明する他のデータについても同様である。

２－２．配送の実施状況のデータをリアルタイムで取得する工程（Ｓ０２）
配送の実施状況のデータは、第２端末から送信される所定の情報を集計することによって作成されてもよい。当該情報は、リアルタイムで、第２端末から取得することができる。ここでいうリアルタイムの意味するところは、時間の観点から具体的に限定されるものではなく、例えば、３０秒以内であってもよく、１分以内であってもよく、３分以内であってもよく、５分以内であってもよく、１０分以内であってもよく、１５分以内であってもよい。ただし、実情をデータに反映させる時間が長くなると、第２又はそれ以降の配送計画を作成する際に支障が出る可能性があるので、典型的には、最大で３０分以内である。

例えば、第２端末は、集荷先の引き渡し者、配送先の受け取り者などの署名をタブレット端末経由で受領することに応答して、作業完了の情報をサーバに送信してもよい。例えば、第２端末は、ドライバーの操作に応答して、作業完了の情報をサーバに送信してもよい。例えば、第２端末は、ＧＰＳモジュールを通して、運転中の車両の現在位置を、サーバに送信してもよい。例えば、第２端末は、通信モジュールを通して、走行中の道路情報を取得し、サーバに送信してもよい。

これらの第２端末からの情報を含む配送の実施状況のデータをサーバがリアルタイムで習得することで（そして、データを集計することで）、第２又はそれ以降の配送計画を作成する際に、適切に荷物を割り当てることが可能となる。

配送の実施状況のデータは、以下の項目を含んでもよい：担当のドライバーの識別情報（例えば、氏名、ＩＤ等）、車両の識別情報（例えば、管理番号、ナンバープレートの内容）、現在位置（例えば、緯度経度の組み合わせ、住所等）、業務進行状況（例えば、完了率、未遂率、残り荷物の量等）、帰社予定時間、連続勤務時間等、車両に搭載できる荷物の空き容量等。

配送の実施状況のデータの一例を図５に示す。図５では、現在業務遂行中のドライバーの状況として、以下の情報が表現されている：担当のドライバーの識別情報、現在どの位置にいるかについての現在位置情報（例えば、第２端末から送信される情報に基づく位置情報であって、経度緯度の組み合わせ）、帰着時間、勤務時間（例えば、第２端末から送信される情報（例：勤務開始を示す操作等）に基づいて計算される情報）、残りの訪問数等。

２－３．追加の配送依頼のデータを取得する工程（Ｓ０３）
次に、追加の配送依頼のデータをサーバが取得する。ここで、当該ステップＳ０３は、上記ステップＳ０２と並行して行われてもよく、或いは、上記ステップＳ０２の前で行われてもよく、上記ステップＳ０２の後で行われてもよい。

配送依頼のデータは、様々なルートで取得される。例えば、配送依頼主が、表計算ソフトで作成した配送依頼のデータをメール等に添付して送付し、第１端末の第１ユーザがそれを受け取って、第１端末経由で、サーバに配送依頼のデータをアップロードしてもよい。あるいは、当該サーバが、配送依頼のデータを受信するためのＡＰＩを設けており、所定の端末から、当該ＡＰＩを経由して、配送依頼のデータを受信してもよい。

配送依頼のデータの形式は、特に限定されず、例えば、ＣＳＶファイル形式、ＴＸＴファイル形式、ＸＭＬファイル形式、ＪＳＯＮファイル形式、表計算ソフト（例えば、ＥＸＣＥＬ（登録商標））の形式等であってもよい。

配送依頼のデータの内容は、特に限定されず、例えば、以下の情報を含んでもよい：依頼を特定する情報（例えば、依頼ＩＤ）、集荷先位置情報（例えば、緯度経度の組み合わせ、住所等）、集荷先到着予定時刻、配送先位置情報（例えば、緯度経度の組み合わせ、住所等）、配送先到着予定時刻、荷物情報（例えば、数量、重さ、大きさ等）。

配送依頼のデータの一例を図６に示す。図６では、各依頼された荷物に関しての、以下の情報が表示されている：依頼ＩＤ、集荷場所（例えば、緯度経度の組み合わせに基づく位置情報）、配送場所（例えば、緯度経度の組み合わせに基づく位置情報）、集荷時刻、配送時刻、荷物の数量等。

２－４．配送計画取り込み待ちデータとして記憶する工程（Ｓ０４）
上述した配送依頼のデータは、サーバが備える非一時的記憶媒体に記憶されてもよく、或いは、サーバ外の記憶場所（例えば、ストレージサーバ、クラウド等）に記憶されてもよい。

また、配送依頼のデータを記憶する際に配送計画取り込み待ちデータとして記憶することができる。或いは、配送依頼のデータを記憶した後で別途、配送計画取り込み待ちデータとして記憶することができる。

配送計画取り込み待ちデータとして記憶する際には、データの変換作業等が行われてもよい。特に、集荷及び配送の対象となる荷物の情報については、配送対象の荷物のデータを、配送可能な単位に分割して記憶することができる。

なお、上述した配送依頼のデータを取得する段階で、既に、配送対象の荷物のデータが、配送可能な単位になっている場合には、こうした変換作業は不要である。

こうした変換作業は、例えば、プログラム（配送単位分割モジュール）を実行することによって行われてもよい。あるいは、第１端末の第１ユーザがデータを加工する操作を行って、変換作業を実施してもよい。この目的で、変換作業を実施するためのインターフェース及び変換作業を実施するためのプログラムを設けてもよい。

配送計画取り込み待ちデータの内容の例を、図７に示す。内容は、図６に示す内容と類似している。しかし、枝番が存在する点で異なっており、更には、荷物量の内容が異なっている。これは、例えば、図６の１番目の依頼である依頼ＩＤ「ｅ８ｆｇｖｃｚｍ」について、３つに分割し、各々の配送する荷物の量を１０に設定している。２番目の依頼である依頼ＩＤ「ｎ８ｕｆｙｗｘｐ」についても、４つに分割し、各々の配送する荷物の量を１０に設定している。

これは、両者の依頼における荷物が分割可能な状態の荷物であり、そのような場合には、配送可能な単位（好ましくは、配送可能な最小単位）の荷物量になるように、依頼のレコードを分割することができる。

一方で、荷物によっては、１まとまりで配送することが、依頼主の要望などにより、必要となっているケースもある。そのような場合には、３番目の依頼である依頼ＩＤ「ｕ５ｃｘｖ９ｙｍ」に示すように、分割することなく、そのままの状態で、配送計画取り込み待ちデータに記憶してもよい。

また、分割する単位は、図７では１０にしているが、荷物の種類、顧客からの要望などに応じて、荷物ごとに適宜設定することができる。

このように分割することのメリットは、以下のように説明される。即ち、追加の配送依頼を受けた時点では、既に配送計画が作成済みの状態となっており、大幅な変更は難しい。また、最初に配送計画を立てる時点で、各ドライバーが運転する車両の空き容量はなるべく少なくなるように設定することが多い。

このような状況下で追加の配送依頼が発生すると、既に配送計画実施中のドライバーにとっては、時間的な余裕が仮にあったとしても（例えば、当日自分が担当する配送ルートの近くに集荷場所及び配送場所があるので、立ち寄ること自体は十分に可能であったとしても）、車両の空き容量の関係で、追加の積み込みができない可能性がでてくる。

しかし、一度に配送する荷物の量を分割したうえで、配送計画取り込み待ちデータに記憶することにより、上述した可能性を低減させることができる。

なお、分割する処理を行う際には、最小単位にまで分割してもよく、或いは、それ以上の単位に分割してもよい。即ち、ドライバーが配送する荷物の最小単位が仮に１０とした場合、分割する際には、必ずしも１０単位にする必要はなく、例えば、２０単位に分割してもよい。その場合には、例えば、２番目の依頼である依頼ＩＤ「ｎ８ｕｆｙｗｘｐ」は、２つの枝番に分割されることとなる。そして、このような分割であっても、空き容量の観点からマッチングできない可能性を低減させることはできる。

また、別の実施形態においては、配送計画取り込み待ちデータとして記憶する際に、上述した分割処理を行うことなく、記憶してもよい。その場合には、図６に示すように、１件の追加配送依頼ごとに対応する一行のレコードが存在する形で記憶されてもよい。その場合に、どのようにして、ドライバーに荷物を割り当てるのかについては後述する。

２－５．候補ドライバー及び候補車両のうちいずれかを抽出する工程（Ｓ０５）
候補ドライバー及び候補車両のうちいずれかを抽出する工程は、プログラム側で自動的に実行される。その前処理として、配送計画取り込み待ちデータと、配送の実施状況のデータとを、インターフェース上に表示してもよい。

図８にインターフェースの一例を示す。当該インターフェースでは３つの一覧表が表示されている。１つめは、追加の配送依頼の一覧である。２つめは、現状で業務遂行中のドライバーの最新情報である。３つめは、追加の配送依頼の割り当て候補となるドライバーの一覧である。

また、当該インターフェースでは、「依頼取込」のボタンをクリックすると、追加の配送依頼のデータが画面上に表示される。また、「現状確認」のボタンをクリックすると、最新の各ドライバーの状況が表示される。更には、「割り当て」のボタンをクリックすると、指定された依頼を指定されたドライバーに割り当てる処理を実行することができる。そして、１つめの追加の配送依頼の一覧のうち、１番目の依頼の行をクリックすると、内部で、配送マッチング処理が行われ、３つめの一覧表内に、追加の配送依頼の割り当て候補となるドライバーの一覧が抽出される。

抽出の詳細については、後述する。

２－６．ドライバー及び車両のうちいずれかを指定する工程（Ｓ０６）
図８に示すインターフェースにおいて、候補が抽出された後は、割り当て対象を指定する。この操作は、例えば、第１端末の第１ユーザが、３番目の一覧表から、割り当て対象となるドライバー又は車両を選択してもよい。選択方法は特に限定されないが、例えば、一覧表の中から、該当するドライバー又は車両が表示されている行のどこかをクリックしてもよい。

また、ユーザ補助の観点から、例えば、選択されたドライバー又は車両の配送計画及び追加の配送依頼の詳細情報を別画面で表示してもよい。

図９は、詳細情報を表示するインターフェースの例を示す。

図９に示すインターフェースは、例えば、図８に示すインターフェースからの操作によって表示されてもよい（例えば、候補となるドライバーをダブルクリックするなど）。図９に示すインターフェースでは、地図が表示され、当該地図内には、ドライバーの現在位置（例えば、星のマーク）、走行ルート、追加で発生した集荷場所（例えば、上向きの矢印）、追加で発生した配送場所（例えば、下向きの矢印）などを表示することができる。

また、図９に示すインターフェースでは、地図以外に、配送計画のタイムスケジュールを別途表示してもよい。例えば、走行ルートの各ポイントでの到着予定時間、及び、どこまで進行しているかを示す情報を表示してもよい（例えば、完了した走行ルートは実線で表示し、未完了の走行ルートは点線で表示、追加で発生した走行ルートは鎖線で表示するなど）。

２－７．第２の配送計画のデータを作成する工程（Ｓ０７）
候補となるドライバーの中から、割り当て対象を指定する処理を行った後は、当該ドライバーの配送計画を修正し、第２の配送計画のデータを作成する。例えば、変更前のドライバーの配送計画は、図１０に示す形で表現される。

ここで、追加の配送依頼を踏まえ、プログラムは、図１１に示すような第２の配送計画のデータを作成する。ここでは、２行新たに追加されており、これは、追加の配送依頼の集荷場所及び配送場所に対応している。また、その前後で、経路情報が変更される。

２－８．候補となるドライバーの抽出
以上に示す一連の処理により、第２の配送計画が作成される。ここで、指定されなかったドライバーは、以前の配送計画に従って業務を遂行する。

上記の候補ドライバーを抽出する工程（Ｓ０５）においては、ルールベースでの処理により抽出してもよく、或いは、一定量の学習用データを用いて構築した学習済みモデルを用いて抽出してもよい。

一実施形態において、少なくとも上記抽出する処理は、以下の条件のいずれか１つに少なくとも当てはまる場合には、ドライバーを候補として抽出しない。
（条件１）すでに当該所定の日の業務が終了している
（条件２）追加の配送を割り当ててしまうと、当該配送及び別の配送依頼のうち少なくともいずれかの条件をみたすことが不可能になる
（条件３）追加の配送を割り当ててしまうと、積載量がオーバーしてしまう

条件１では、例えば、既に業務が終了している（あるいは、配送管理システムからログアウトしている）場合には、そもそも追加の業務を割り当てることが不可能である。また、好ましい実施形態においては、そもそも割り当ててしまうと、既定の就業時間に終了させることが不可能である場合には除外してもよい。例えば、１７：００を終了時間として配送計画が作成されているドライバーがいたとする。そして、当該ドライバーは、残業をすることができない旨の制限が課せられている。この場合、配送計画のデータにおいては、帰着予定時刻などのレコードに残業不可などのフラグを別途設けておいてもよい。

あるいは、ドライバーが、そもそも雇用契約上残業できないという場合には、ドライバーのマスターテーブルなどで残業不可のフラグを設けてもよい。

いずれにしても、あるドライバーにおいて、追加の配送依頼を、現在の配送計画（例えば走行ルート）に割り当てる際に、そもそも、既に業務が終了している場合には、候補となるドライバーの一覧には抽出しないようにすることができる。

好ましい実施形態においては、更なる条件として、ドライバーは連続する運転時間がガイドラインなどで定められている場合がある。そして、追加の配送依頼を、現在の配送計画（例えば走行ルート）に割り当てる際に、いかようにして割り当てたとしても、連続勤務時間が、ガイドラインで定める量をオーバーする場合には、候補となるドライバーの一覧には抽出しないようにすることができる。

条件２について、ドライバーは、追加の配送依頼以外にも、既に他の配送依頼を受け持っており、各配送依頼については、集荷時間及び／又は配送時間が厳密に定められている場合もある（例えば、その日の集荷配送であれば何時でもよいといった条件ではなく、集荷は、〇〇時～〇〇時、及び／又は、配送は、〇〇時～〇〇時に行うことが配送依頼の際に条件設定されている）。このような場合において、いかようにして割り当てたとしても、既存の配送依頼の条件を破らないように、設定することが不可能である場合には、候補となるドライバーの一覧には抽出しないようにすることができる。更に言えば、追加の配送依頼にも条件が課せられており、当該条件を破らないように設定することが不可能である場合には、候補となるドライバーの一覧には抽出しないようにすることができる。

条件３については、時間的には余裕があって、追加の集荷及び配送が可能であっても、
追加の配送を割り当ててしまうと、積載量がオーバーしてしまう場合がある。留意されたい点として、ここでいう、条件３は、現在の配送状況に基づいて（即ち、現時点でのドライバーの担当する車両の空き容量に基づいて）行われてもよいし、あるいは、あくまで、特定のタイミングで追加の集荷を割り込ませた場合に積載量がオーバーするかどうかに基づいて行われてもよい。

前者の場合には、現時点で空き容量がない車両のドライバーは候補から除外される。一方で後者の場合には、さらに複雑な判断処理が行われる。例えば、図９に示すドライバーにおいては、地点４から地点５への移動中である。そして、地点４で集荷した荷物を運送しており、車両はある程度の荷物で占有されている。しかし、仮にここで、追加の集荷配送依頼の荷物量が、当該ドライバーの今現在の車両の空き状況において積み込むことが不可能だったとしても候補ドライバーから除外されることはない。実際には、追加の集荷配送依頼を任意のポイントで割り込ませたようとしたときに、積載量の余裕があるかどうかで決定することができる。例えば、地点５以降の任意のタイミングで、追加の集荷依頼の荷物が搭載可能かどうかで判断される。図９のケースでは、配送を終えたタイミングであるため、追加の集荷配送依頼の荷物量を受け入れるだけの空き容量があると判断され、候補ドライバーとして抽出される。

このように、今現在の状況に基づいて判断されるというよりは、仮に、今現在以降で特定のタイミングで集荷配送依頼を割り込ませた場合に、当該タイミングにおいて、車両に空き容量があるかどうかという観点で判断される。このように判断することで、候補ドライバーをより多く抽出することができる。

したがって、より好ましい実施形態においては、抽出する工程は、追加の配送に係る集荷先に到達した時点での空き容量が、配送可能な単位よりも大きい場合に、候補として抽出することができる。

また、このような仕組みで判断するため、追加の集荷配送依頼は、図９に示すような、既存の配送計画の一番後ろに追加する場合だけに限られない。即ち、途中の集荷配送の工程の中に、追加の集荷、及び、追加の配送を、独立して割り込ませてもよい。

上述したような条件１～３を充足するかどうかの判定は、ルールベースのプログラム、及び、学習済みモデルのいずれにおいても実現可能である。

また、シフト勤務表の作成などに応用されることが知られる量子コンピューティングの分野（あるいは、量子アニーリング）などを用いて実現してもよい。

２－９．その他変形例について
上記実施形態においては、いくつかの変更が可能である。

例えば、上記の実施形態では、候補ドライバーを抽出し、追加配送依頼の配送を割り当てる際に、候補ドライバーを指定していた。しかし、ドライバーの代わりに、車両を抽出し、そして、車両を指定するように変更してもよい。この理由として、ドライバーと車両は１対１で対応しているケースが多いからである。

また、上記の実施形態では、配送計画取り込み待ちデータとして記憶する際に、配送対象の荷物のデータを、配送可能な単位に分割して記憶する処理を実施していた。しかし、こうした分割して記憶する処理を行わず、ドライバー又は車両に配送依頼を割り当てる段階で、分割する処理を行ってもよい。

以下具体例を示す。図１２は、図８と類似した構成となっているが、相違点として、追加の配送依頼の情報に表示されている配送依頼の内容が分割されることなく表示されている。ここで、第１ユーザは、特定の配送依頼（図１２では、依頼ＩＤ「ｕ５ｃｘｖ９ｙｍ」）を選択している。これに応答して、候補ドライバーの情報が表示されている。更に、第１ユーザは候補ドライバーの１人を選択する（図１２では、候補ドライバー識別情報「ｕａｑｓ２５ｙｊｑ８ｓｒ」を選択）。その後、割り当てボタンをクリックする。

クリックした後は、図１３に示すインターフェースを表示してもよい。当該インターフェースでは、画面左側の枠で地図を表示しており、集荷場所と配送場所を表示している。また、画面右側の枠で、各種項目を表示しており、例えば、依頼内容を特定する情報である依頼ＩＤ、集荷場所の情報（場所名、住所、緯度経度の組み合わせ）、配送場所の情報（場所名、住所、緯度経度の組み合わせ）、集荷及び配送の希望時間、割り当てる荷物の量（例えば、数量、重量等）、割り当て可能な上限などを表示している。

なお、割当上限については、図１３においては、図１２の配送依頼に示す荷物量と一致した数値となっている。しかし、例えば、既に別のドライバーに、配送依頼の一部を割り当てている場合には、その分が差し引かれる。例えば、既に別のドライバーに、配送依頼の荷物量として２０を割り当てている場合には、５０－２０＝３０となり、割り当て上限が３０で計算される。

第１ユーザは、ここで、割り当てる荷物量を入力していき、割り当てるべき残りの荷物量がゼロになるまで繰り返してもよい。入力した後は、配送割り当て済みデータを作成してもよい。例えば、図１４のような形式のデータを作成し、記憶することができる。

以上、発明の具体的な実施形態について説明してきた。上記実施形態は、具体例に過ぎず、本発明は上記実施形態に限定されない。例えば、上述の実施形態の１つに開示された技術的特徴は、他の実施形態に適用することができる。また、特記しない限り、特定の方法については、一部の工程を他の工程の順序と入れ替えることも可能であり、特定の２つの工程の間に更なる工程を追加してもよい。本発明の範囲は、特許請求の範囲によって規定される。

Claims (7)

1. 配送管理を行うためのプログラムであって、前記プログラムは、情報処理装置のプロセッサに命じて、以下を含む工程を実行させることが可能である、プログラム。
   ・所定の日の第１の配送計画のデータを作成する工程、
   ・当該所定の日に、前記第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する工程、
   ・当該所定の日に、且つ、前記配送の実施の開始後に、追加の配送依頼のデータを取得する工程、ここで、当該追加の配送依頼のデータは、当該所定の日に配送することが必要な配送依頼のデータである、
   ・前記追加の配送依頼のデータを、配送計画取り込み待ちデータとして記憶する工程、
   ・前記実施状況のデータと、前記配送計画取り込み待ちデータとに少なくとも基づいて、追加の配送を割り当てる対象となる候補ドライバー及び候補車両のうちいずれかを抽出する工程、
   ・前記抽出された候補ドライバー及び候補車両のうちいずれかから、少なくとも１人の特定のドライバー及び少なくとも１台の特定車両のうちいずれかを指定する工程、
   ・前記指定されたドライバー又は車両の配送状況と、前記配送計画取り込み待ちデータとに少なくとも基づいて第２の配送計画のデータを作成する工程、
   ここで、１つの配送依頼識別情報に係る配送対象の荷物のデータを、配送可能な単位に分割して、各々を異なる複数の指定されたドライバーに割り当てることができる。
2. 配送管理を行うためのプログラムであって、前記プログラムは、情報処理装置のプロセッサに命じて、以下を含む工程を実行させることが可能である、プログラム。
   ・所定の日の第１の配送計画のデータを作成する工程、
   ・当該所定の日に、前記第１の配送計画に少なくとも基づく配送の実施状況のデータをリアルタイムで取得する工程、
   ・当該所定の日に、且つ、前記配送の実施の開始後に、追加の配送依頼のデータを取得する工程、ここで、当該追加の配送依頼のデータは、当該所定の日に配送することが必要な配送依頼のデータである、
   ・前記追加の配送依頼のデータを、配送計画取り込み待ちデータとして記憶する工程、
   ・前記実施状況のデータと、前記配送計画取り込み待ちデータとに少なくとも基づいて、追加の配送を割り当てる対象となる候補ドライバー及び候補車両のうちいずれかを抽出する工程、
   ・前記抽出された候補ドライバー及び候補車両のうちいずれかから、少なくとも１人の特定のドライバー及び少なくとも１台の特定車両のうちいずれかを指定する工程、
   ・前記指定されたドライバー又は車両の配送状況と、前記配送計画取り込み待ちデータとに少なくとも基づいて第２の配送計画のデータを作成する工程、
   ここで、抽出する工程は、今現在より後の特定のタイミングで集荷配送依頼を割り込ませた場合に、当該タイミングにおいて、車両に空き容量があるかどうかという観点で判断して抽出される。
3. 請求項１のプログラムであって、
   前記抽出する工程が、以下の条件のいずれか１つに少なくとも当てはまる場合には、ドライバー及び車両のうちいずれかを候補として抽出しないことを含む、プログラム。
   ・すでに当該所定の日の業務が終了している
   ・追加の配送を割り当ててしまうと、当該配送及び別の配送依頼のうち少なくともいずれかの条件をみたすことが不可能になる
   ・追加の配送を割り当ててしまうと、積載量がオーバーしてしまう
4. 請求項３のプログラムであって、
   前記抽出する工程が、以下の条件に少なくとも当てはまる場合には、ドライバーを候補として抽出することを含む、プログラム。
   ・追加の配送に係る集荷先に到達した時点での空き容量が、前記配送可能な単位よりも大きい
5. 請求項１のプログラムであって、
   前記抽出する工程が、割り込み配送を許容したうえで抽出することを含む、プログラム。
6. 請求項１～５いずれか１項に記載のプログラムを備える装置。
7. 請求項１～５いずれか１項に記載のプログラムを用いて、配送管理を行う方法。

Images