配送ルート最適化プロジェクトの現場実装

こんにちは。データサイエンティストの町田と申します。

私は主にデータ分析プロジェクトのマネジメントを担当し、日々お客様たちのビジネス課題の抽出・解決をデータ分析を用いてご支援をさせていただいております。

今回は、数理最適化を用いたプロジェクトを進める中で実際に直面したことのあるプロジェクト上の障壁について、エピソードを交えてお話ししたいと思います。

分析の課題ではなく、プロジェクトチームやより幅広く組織が一致団結して超えなければならない課題といった、メディアではあまり語られていないような泥臭い部分をお伝えできたらと思います。

せっかく取り組んできたプロジェクトが、現場適用まで進められず頓挫してしまったとならないように意識していきたい事項となります。

今回は具体的なエピソードの題材として、物流分野における配送効率化プロジェクトをあげてお話しさせていただきます。

なお数理最適化の技術的な部分については以下の記事をご参照ください。

【関連】

なぜその荷物を運ばなければならないのか

配送業務において、荷物を誤配することなく配送先に届けることは、当たり前の業務だと思います。

しかしながら、配送分野で数理最適化を用いてプロジェクトを進める際には、この当たり前の”前段階”まで考慮することが望ましいと考えています。

“前段階”とは、なぜ、その荷物が配送されなければならないのかという点です。

配送事業では、貨物スペースに荷物があまり載せられておらず、積載率が低い状態で配送を行っていることを「空気を運んでいる」と揶揄されているそうですが、配送ビジネスを行っている企業様はこれを喜ばしい状態とは思われていないことは自明です。

(もちろん、貴重な材や重量が非常にあるものなどを配送する場合はこの限りではないと思います。)

どちらかと言えば、空気を運ばざるを得ない状態、つまり収益性の低い状態を強いられているのかと思います。

私見ですが、この状況は配送への需要が少ないために起きているのではなく、むしろ配送への需要が多いために起きているのかと思います。

もし、配送担当者に配送する荷物量と配送する日時を自由に決定する権限があったとすれば、最も効率の良い積載と配送経路で配送を行うことを選択され、「空気を運ぶ」ようなことは避けられるのではないでしょうか。

しかし、現実では配送元・配送先からどのような形状・重量であっても、指定の時間までに届けてほしいという需要が強く、その要望に配送を担っている方たちが応え続けているのかと思います。

上記は極端な例ではありますが、配送を効率化するためには、その荷物は本当にある日のある時刻までに運ばなければならないのかを考えることも重要であることがご理解いただけるかと思います。

この問題は、配送の担当者たちだけで解決することは難しく、組織一体となって解決されるべき重要な問題になるかと思います。

配送を専業とされている企業では、荷物量の事前通知を受け取れるようにすることや、配送時刻の指定の緩和などを検討することが最も効果のある施策となることもあるでしょう。

自社で生産と配送を行っている企業では、生産部門がすべて生産量を決定するのではなく、配送部門と連携を取ることで企業全体で効率化を推し進めることができるかもしれません。

数理最適化を用いて「もし今の業務の制約が変更されたら」というシミュレーションを実施することは可能ですが、コストが課題が自明になっている場合は、数理最適化を用いるということに囚われず、データの可視化や丁寧な現場へのヒアリングを通じて施策を実施することが望ましい場合もあるかと思います。


分析のためのデータがあるか

数理最適化を用いたプロジェクトでも他の機械学習プロジェクトと同様に、分析に利用できるデータがないという課題が生じることが往々にしてあります。

配送計画を数理最適化で効率化する場合に必要となるデータは、以下のようなものが考えられます。

  • 各トラックの車格
  • 各トラックの配送先
  • 各トラックの移動時間や移動距離の実測値
  • 各配送先の届ける必要のある荷物量
  • 配送先の荷物の受け取り可能時間
  • 荷積み可能なスペースの数 (バース)
  • 時間ごとに使用可能なトラック数

これらの他にも課題に応じて、実際の業務で考えられている情報をデータとして準備する必要があります。

例えば、倉庫での荷物管理の都合上、配送先ごとにトラックに荷積みが可能になる時刻に制限がある場合は、配送先ごとに荷積みが可能になる時刻のデータが必要になります。

上記で上げたような情報は、現場では日々当たり前に利用されているものです。

現場の配送計画の担当者にお話を伺えば、当日の配送計画を立てる際に考慮されていることをご教授いただけると思います。

しかしながら、電話、FAX、紙といったツールを用いて業務を遂行されていることがあるため、後から振り返って調査を行うとなると既に情報が失われていることがあります。

例えば、会計上必要になるのはその日に使用されたトラック台数であるため、どのトラックにどの程度の荷物が積まれていたかという情報は蓄積されていないといったことが起こります。

実際に私が体験したところでは、各トラックがどの順で配送を行ったのかといった情報が紙でしか蓄積されていないことがありました。

対応するにあたっては、紙で蓄積されている情報をOCR(Optical Character Reader:光学文字認識機能)や手作業による打ち込みによってデータ化を行うことから作業が始まったこともあります。

また、データの蓄積状況や蓄積期間によっては、すぐには有益な分析を行うことが期待できないと判断することもあり、プロジェクトに本格的に取り組む前にデータを収集・蓄積する期間を設けることもあります。

データの収集を進める中で、どうして蓄積がなされていないのかであったり、どのようにすれば蓄積ができるのかを整理していくことは、数理最適化に限らず組織としてのビジネスフローやガバナンス体制を見直す機会ともなります。

データがない場合であってもすぐに諦めるのでなく、将来的に質の高いデータの収集を計画するプロジェクトを立ち上げることは、将来のための投資と考えることができるかと思います。

標準業務を組織全体で共有できるか

数理最適化を用いた業務の効率化・自動化を考えている場合は、まずは現在の業務フローや各業務で現在考慮されている業務制約を可能な限り言語化・可視化する必要があります。

例えば、配送先に荷物を届けるという業務であっても、まずは荷物は何時に準備されるのか、トラックは何時に準備が整うのか、何時までに配送経路を決定するのかといったことを言語化する必要があります。

そして各点について「なぜ荷物はその時間でしか準備できないのか」「荷物を準備するため必要な情報はなにか」など、それぞれの業務上の制約を書き下していく必要があります。

日々行われている業務でも改めて詳細に言語化を試みると、想像以上に難易度が高く、想定スケジュール通りにまとめることができなかったということも起こります。

特に、日々実際に業務を遂行されている方と分析プロジェクトを推進される方が異なっていると、双方の業務への認識が異なっており意見がまとまらないということが見受けられます。

私見となりますが、業務に対する認識の齟齬が起きる理由は、どちらかが業務への認識を大きく誤っていることが原因でなく、どのような点に重きをおいて日々の業務や職業人としてのミッションを果たそうとされているのかが異なることに起因しているのかと思います。

おそらくですが、日々配送を行われている方たちは、配送先の方が不満を持たないように荷物の受け渡しを行うことが最大のミッションとなっているかと思います。

そして、分析プロジェクトを推進するような管理部門は、現状のビジネスを維持しつつ組織として健全に成長し続けるために半年後、一年後、そしてより長期に渡っての戦略を立案し遂行することが最大のミッションとなっているかと思います。

このような関係性の違いによって、一方は、現場で起きうる人間的な課題を避ける工夫や、日々変わりゆく現場の状況によって少しずつ変化していった業務フローの変化を、業務上必要なこととして捉えているでしょう。

他方は、属人化してしまうような業務はなるべく避けて、より汎用的な業務フローを描きたいと考えるでしょう。

このように、どちらの意見も誤っているということではないでしょう。

しかしながら数理最適化プロジェクトでは、現実の業務をプログラムで表現し、幾度もシミュレーションを行うため、どのような業務を標準のものと定義するかは最も重要な仕事となります。

定義が曖昧なままですと、シミュレーションを実施すること自体ができないこともあれば、シミュレーションの結果が非現実的な結果となってしまうこともあります。

そのため、「標準業務」の定義には、十分な時間と多様な人員をもって意見の一致をさせる必要があります。

数理最適化プロジェクトを遂行するにあたって、業務フローや業務制約を書き出すという仕事は、組織全体を俯瞰し、改めて業務を定義しなおすという行為とも言えるかと思います。

このような仕事は、組織間の関係によっては会議の時間を取れなかったり、目指すべき組織像の意見がまとまらないといったこともあり、分析プロジェクトの枠を越えた努力が必要になることもあります。

数理最適化の結果が現場に受け入れられるか

データが揃い、業務制約が揃ったのであれば、数理最適化のシミュレーションを行っていくことになります。

数理最適化のシミュレーションを行っていく過程は、こちらの記事をご参照ください。

【関連】

試行錯誤を繰り返し、シミュレーションの結果が現実的だと思われる場合は、実務に導入していくことを考えていくことになります。

このとき、現場の担当者の方がシミュレーション結果を利用することに躊躇されることが想定されます。

現場の担当者としては、既存の業務を変更することによって日々の業務に支障が出るのではないかと思われるのは想像に難くありません。

こちらについては、当たり前のことではありますが、プロジェクトの意図と数理最適化の結果を用いた業務でも支障がないことを丁寧に説明をし、現場の担当者の方が不安に思われることに対して十分に補足を行うことが重要だと考えています。

現場の担当者との対話が不十分であった場合、プロジェクトの担当者が数理最適化の結果を現実に適用可能だということを分かっていても、現場の担当者にとっては訳のわからないことを言っていると思われても仕方ありません。

このようなことを避けるためには、定期的に会話をする時間を設けたり、実際に倉庫などに赴いて現在の業務をしっかりと理解することが必要かと思います。

私としては、倉庫に1 度だけ訪問するだけでは現場から学ぶ時間が足りないかと思いますので、時間や都合の許す限り何度も訪問して理解を深めていくことをおすすめいたします。

数理最適化の結果が現実に適用できるということを現場の方にもご理解いただく過程では、通常の業務のうち一部だけを数理最適化の結果を用いて配送するという実験も行いました。

現場の担当者の方にとって、数理最適化の結果でも実際に業務を遂行できることを確認するためにはこれ以上ないものではないでしょうか。

余談ですが、その際には、私も分析の責任者としてトラックの後ろを追いかけさせていただき、シミュレーション結果と現実の間に乖離がないかを確認させていただきました。

実際に配送するトラックを追いかけることによって、プロジェクトチームは、データからでは分からない知見を得ることができたり、現場の方にとっては当たり前過ぎて言語化されていないことについても学ぶことができました。

数理最適化の結果を机上の空論としないためには、実際に現場に赴くというのが一番良いのかもしれません。

日々の業務に組み込めるか

上記までの課題が解決され、数理最適化でのシミュレーションも期待通りの結果を得ることができたのならば、いよいよ本格的に業務への適用を目指すことになるかと思います。

しかし、数理最適化に限ったことではないのですが、新たな業務フローやシステムを実務適用するには様々な困難が付きまといます。

私が経験した中では以下のようなことがありました。

  • 数理最適化の結果通りに業務が進められない場合のバックアッププランを決定することが困難
  • 現場で数理最適化の結果を利用するためには、新規のシステム開発が必要

このような課題は、既存の業務に変更を加えることになるすべてのプロジェクトで起きうるかと思います。

数理最適化の結果通りに業務が進められない場合のバックアッププランを決定することが困難

数理最適化は基本的に標準的な業務を想定して開発するものですから、人災、天災や特殊なイベントが起きた際など、100%正常に作動することを保証することはできません。

極端な例としては、路面に異常が起きていてそもそもトラックによる配送が行うことができないこともあるでしょう。

ありそうなところでは、利用できると思っていたトラックが急に利用できなくなってしまうなどで、荷物を運び切るのに必要なトラックの台数が不足してしまうこともあるかと思います。

上記のような想定外のことが起きた際には数理最適化のシステム導入を推進した部門がリスクを負うことになることが多いかと思いますが、どの程度のリスクなら許容できるのか、また補填としてどのような対応を取ることができるのかをまとめることは、非常に難しい問題になるかと思います。

配送に関わる契約の問題になることもありますし、通常よりも割高であるが外部の傭車を利用することで解決できるのかを見定めることは、一部門だけではできないことかもしれません。

現場の方との合意を得ることはもちろんですが、より上位の意思決定層を巻き込んで判断を行うことも視野にいれたプロジェクトの推進が必要になるでしょう。

この作業には多くの関係者を巻き込む必要があるため、日々の関係性の構築は言わずもがなですが、何度も議論が必要になりスケジュールの調整も難しくなることが想定されますので、余裕を持って議論を始めることが必要になります。

現場で数理最適化の結果を利用するためには、新規のシステム開発が必要

今まで数理最適化のためのデータ収集や業務の整理を行ってきましたが、新しいシステムを利用することになると、それらとは別にシステム開発のための要求定義、要件定義、設計、実際の開発のための時間が必要になります。

追加で開発したい機能の数や種類によっては、相応の開発期間が必要になってしまいます。

業務適用の開始時期を先に定めている場合は、まずは最低限の機能に絞ったシステムの開発を目指し、現場に導入された後に徐々に機能を拡張していく方針を取ることも視野に入れるとよいかと思います。

システム開発についてはこちらの記事もご参照ください。

【関連】【後編】データ分析を「システム実装」するための重要ポイントとは ~機械学習を活用した業務アプリケーション構築~

まとめ

数理最適化プロジェクトを現場に適用するためには、分析のためのデータを十分に蓄積し、業務フローや業務制約を可能な限り言語化・可視化し、組織全体で解釈を一致させる必要があることを述べました。

また、数理最適化の結果を現場に受け入れてもらい、日々の業務に適用するためには、現場の方々のご理解をいただく必要があります。

数理最適化という人間らしさのない機械的な道具を用いていても、私たちが解決したい課題は人間同士のやりとりの中にあるため、お互いへの理解と尊敬を忘れてはいけません。

私の経験が、数理最適化をはじめとしたデータ分析プロジェクトを進められる方にとって少しでも参考になれば幸いです。

RANKING人気ランキング

NEW ARTICLES新着記事

WRITER執筆者プロフィール

株式会社ブレインパッド

アナリティクスコンサルティングユニット
町田 義将

コンサルティング企業、他社データ分析企業の経験後、2019年にブレインパッドに入社。データに基づく意思決定を支援するために、注力すべきプロジェクトの見極めや、機械学習・数理最適化を用いての現場適用など幅広い領域に従事。

MAIL MAGAZINEメールマガジン

データ活用の厳選記事や、
会員限定のDXのお得情報などをお届けいたします。

TREND人気ワード・タグ

BEST PRACTICEベストプラクティス

ベストなDXへの入り口が見つかるメディア

DOORS

BrainPad

MAIL MAGAZINEメールマガジン

登録が完了しました。

メールマガジンのご登録ありがとうございます。
最新特集記事の情報をお届けしますので、
お楽しみにお待ちください。

MAIL MAGAZINEメールマガジン

登録エラーです。