備忘録⑤ 物流×数理最適化案件にどう取り組んだか

※ヘッダー画像の出典：esri

今回で物流×数理最適化案件編はラストになります。ぺーぺーの自分の場合はどう案件に取り組んだかを書いてみます。

アジャイルに進める

良いモデルができるまでに、
関係者へのヒアリング→要件定義→定式化→Python実装→結果の可視化のサイクルをテンポ良く回そうとしました。

モデルが出来てから実際に使うためのソフト開発も勿論アジャイルです。ここでは前半の良いモデルができるまでの話にフォーカスします。

MIPソルバーを使う

私の場合はPuLPでCBCを使っていました。最近SCIPが商用利用可能になったみたいですね。

要件を適切に盛り込んで定式化するのを一発で完璧にやるのはほぼ無理だと思います。
問題規模が大きく厳密解を出すには時間がかかりすぎる場合でも、ヒューリスティクス解法の開発は最後まで我慢して、MIPソルバーを途中で打ち切った解を使う方がサイクルを速く回せます。

私の案件の場合ですが、結局最後までヒューリスティクス解法の開発は必要ありませんでした。

Umeponさんの数理最適化による問題解決の実践的なアプローチをだいぶ参考にしていました。

インプットに終わりなし

「良い考えが出ないときの多くはインプット不足である」みたいなニュアンスの格言をどこかで見かけて、個人的に気に入っています。

数理最適化でいうと、どんな典型問題や定式化のテクニックがあるかなどを知っておくことが役立ちました。
一度学んだものでも、読み返していると「そういえば条件分岐をどう式にするか悩んでたな。ここに書いてあるじゃん」みたいな瞬間が結構ありました。

数理最適化の技術のほうだけではなく、もちろんドメインの知識も必要です。物流業界でこれまでどんな思想でどんな改善が行われてきて、何がスタンダードなのかみたいなところから解決のヒントが得られる瞬間も多々ありました。

結果を見せて関係者にツッコミを貰う

上手く問題解決するためにも、目的や制約条件を明確にするためのヒアリングは不可欠かと思います。

事前のヒアリングでどんなに頑張って、相手も協力的であったとしても、その場で必要な情報が全て揃うことはまずないと思っています。

ある程度必要な情報が得られたらモデルを作って結果を相手に見せてみると、
相手「結果のここがおかしい」
自分「どうおかしいでしょうか？」
相手「○○という条件を満たせてない」
といった調子で新たに必要な情報が得やすいと感じました。

こちらも先ほどのUmeponさんの記事に同じ話がありましたね。ほとんどUmeponさんの受け売りです笑

それっぽく動くデモを作る

Streamlitでデモを作ることで関係者に動いてもらいやすくしようとしていました。

業務システムからダウンロードしてきたファイルをアップロードして、ボタンを押すと最適化が実行されて、地図とグラフで結果が表示されて、……
というデモアプリをStreamlitで手軽に作ることができます。

大きな組織になると、油断してると進みが遅くなります。
デモアプリは関係各者が最終アウトプットをイメージしやすくなったり、なんかカッコいいアプリが動いているぞと前のめりになって貰う効果がありました。
結果として進みやすくなった気がしています。

と言いつつ、初めてStreamlitで遊んで自己満足してた部分もあるかもです。

コミュニケーションを頑張る

結局これです。
適切な問題設定と解決策を見極めるのにも、実際にプロジェクトを前に進めるのにも、泥臭いコミュニケーションは不可欠かと思います。
(私もまだまだ未熟ですが…)

• プロジェクトの予算承認を得るために資料の準備を頑張るだけでなく、事前に決裁権を持つ方や反対すると思われる方の小耳に挟んでおく

• 「意思決定が完全に自動化されるのではなく、そこそこ良いたたき台が素早く作れると考えてください」「なのであなたの仕事を奪うのではなく、楽になるんです」といった認識合わせを常に行う

など、コミュニケーションに気を遣うべきところが多々ありました。
この辺は学生の時には全くイメージが湧いていませんでしたね、実践経験を積むしかないのでしょうね。
多くは会社の先輩方から学んでいるので、とても感謝しています。

最後に

物流×数理最適化の案件に限らず、仕事をするうえで当たり前とされてることしか言っていない気もします。

新卒最初の仕事の話は以上になりますが、改めて面白い仕事をさせていただいたうえに多くのことを学ばせていただきました。
このような機会に恵まれたことに強く感謝します。