機械への共感: サプライチェーンソフトウェアにおける欠けていた要素
約20年前にサプライチェーンの問題に取り組み始めたとき、困難な部分は物理学、つまりトラック、船、パレット、コンテナ、生産ラインだと予想していました。しかし、実際には数秒かかる画面の更新、翌朝に引き継がれる夜間バッチ処理、そしてほとんど表計算ソフト以上ではない程度に単純化された「最適化」エンジンに悩まされることになりました。
本当のボトルネックは、鋼鉄やコンクリートではなく、ソフトウェアでした。正確に言えば、そのソフトウェアを動かすマシンに対する私たちの集団的な無関心が原因でした。
私の著書 Introduction to Supply Chain では、現代のサプライチェーンは何よりもまず、不確実性の中で意思決定を行うエンジンであると主張しています。これらの決定の質は、それらを準備するソフトウェアの質に依存しており、そのソフトウェアはまた、CPUキャッシュからメモリ帯域幅に至るまで、基盤となるコンピューティングハードウェアに制約されています。
過去10年間で、いわゆる機械への共感、つまり計算が実際にどのように振る舞うかを本能的に感じ取り、その現実を無視するのではなくその上で方法論を設計する意欲を発展させなければ、サプライチェーンの実践は大きく進歩しないと信じるようになりました。
「機械への共感」とは何か
このフレーズはもともと自動車レースから生まれたものです。優れたドライバーは、単にレースラインを正確に走るだけでなく、車が何をでき、何ができないかを「感じ取る」ことができます。彼らはブレーキが過熱するような激しい操作を避け、エンジンの声に耳を傾け、タイヤが限界に達しようとしている瞬間を察知します。つまり、彼らはマシンに共感しているのです。
コンピューティングにおいては、現代のサーバーが抽象的な「1秒あたりの演算回数」を実行する魔法のような摩擦のない計算機ではなく、特徴を持った物理的なオブジェクトであると理解することに相当します。サーバーには、小さいながら高速なキャッシュ、より遅い主記憶装置、さらに遅いディスク、そして無視できないレイテンシを持つネットワークなどの特性があります。これらの制約を尊重するか、日常的に無視するかの違いは、性能において1桁または2桁の向上をもたらします。
深層学習の歴史には印象的な例があります。初期のニューラルネットワークの文献は、生物学的なインスピレーション、つまりニューロン、シナプス、神経科学に聞こえる学習規則に取り憑かれていました。しかし、研究者たちが脳を模倣するふりを捨て、代わりにGPUと数値安定性のために徹底的に最適化したとき、画期的な進展がもたらされました。修正線形単位（ReLU）、ミニバッチ、密な層、混合精度演算など、これらの多くのアイデアは神経科学よりもハードウェアに適応するためのものです。まさにシリコンに共感を示した瞬間、分野は急速に発展しました。
もちろん、サプライチェーンは画像認識ではありません。しかし、その計算負荷は同等であり、マシンを尊重することによって得られる恩恵も同じくらい大きいのです。
計算問題としてのサプライチェーン
サプライチェーンはしばしば、工場、倉庫、トラック、店舗といった物理的な流れとして描かれます。しかし、一見分かりにくいのは、動くパレットの背後には、何を購入するか、何を生産するか、どれだけ出荷するか、どこに保管するか、いくらで販売するか、いつ値下げするか、どの注文を優先するかといった、数十にも及ぶ小さな決定が存在するということです。
これらの各決定は不確実性の下で行われます。需要が急増したり崩壊したり、リードタイムがずれたり、供給業者が失敗したり、輸送能力が一晩で消失したりします。もし人間の勘よりも体系的に優れた意思決定を行いたいのであれば、単一の予測だけでなく複数のシナリオを考慮し、サービスレベルだけではなく期待利益の観点から選択肢を比較し、各倉庫や店舗を孤立して扱うのではなくネットワーク全体に制約を伝播させるアルゴリズムが必要となるのです。
これらすべては計算的に非常にコストがかかります。数千ものあり得る未来を追跡し、それぞれに対して意思決定を評価する確率論的アプローチは、単純な安全在庫の計算式よりもはるかに多くの演算を必要とします。インベントリ、価格、キャパシティプランニングを連動させたネットワークレベルの視点は、局所的な再発注点の計算よりもはるかに多くのデータをマシンに流し込みます。
ここで機械への共感が決定的な役割を果たします。もし基盤となるソフトウェアとハードウェアのスタックが不十分で、各クエリがトランザクションデータベースへの何十回もの往復を引き起こし、アルゴリズムがキャッシュや並列処理を無効にするように書かれている場合、これらのより高度な手法は利用可能な時間内に収まらなくなります。結果として、本当の問題に対応できるようにマシンを改良するのではなく、問題自体をマシンに合わせるために縮小してしまうのです。
もし再補充の「最適化」が午後6時に開始され、午前6時に終了しなければならない企業を見ると、その組織が代替案の実験を真剣に行わないことが明らかになります。新しいアイデアはすべて数週間に及ぶプロジェクトとなり、1回の実行に半日を要するため、実験の経済性が失われてしまいます。
主流の見解：ハードウェアは後回しにされる
主流のサプライチェーンの教科書を見ると、ネットワーク設計、調達戦略、契約、在庫ポリシー、輸送手段、パフォーマンス指標についての広範な議論が見受けられます。また、ERPシステム、計画ツール、統合について説明する「情報技術」の章もあります。しかし、基盤となるコンピューティングが実際にどのように動作するかについての真剣な議論はほとんど見当たりません。
ITは中立的な促進要因として扱われています。大まかに言えば、ソフトウェアを選定しデータを統合すれば、プロセス設計やマネジメントのレバーに専念できる、というメッセージです。メモリの配置、データの保存方法、計算のスケジューリングといったマシンの内情は、ベンダーや技術者に委ねられているのです。
同じ考え方は、我々の分野のほとんどのエンタープライズソフトウェアに浸透しています。計画システムは、注文予約や在庫レベル更新のために設計されたトランザクションデータベース上に構築されており、夜通しで数十億もの確率シナリオを計算するためのものではありません。アーキテクチャは通常、レコードの作成、読み取り、更新、削除を行う画面やフォームを中心に組み立てられ、さらにここに予測エンジンやルーティングソルバー、在庫のヒューリスティックといった「最適化モジュール」が追加されています。
外見上は、ウェブインターフェース、クラウド展開、API、さらにはマーケティング資料で謳われる「AI」など、十分にモダンに見えます。しかし、内部では計算の中核部分がしばしば飢餓状態にあります。計算は抽象化の層を通じて分割され、データが散らばり、作業が分散されることで、ハードウェアの強みが活かされなくなってしまうのです。その結果、30年前のマシンの何千倍もの速度にもかかわらず、今日のデータ量に追いつくのに苦労するソフトウェアとなっています。
ニクラウス・ウィルトは、有名な皮肉として、ソフトウェアはハードウェアが高速化するよりも速く遅くなっていると述べました。サプライチェーンにおいても、これは明らかです。多くの大規模システムでは、基盤となるハードウェアが同じ時間内に何百万ものレコードをスキャンできるはずであるにもかかわらず、単一の製品とロケーションの組み合わせの「詳細」ページを開くのに数秒を要しています。私たちは、非効率の層によってハードウェアの進歩をほぼすべて消費してしまいました。
一度、非効率がアーキテクチャに組み込まれると、その影響は単なる技術的な問題に留まらず、教義的なものとなります。もしプラットフォームが各SKUごとに何千ものシナリオを追跡する余裕がなければ、単一の予測のみを必要とする手法を好むようになるでしょう。もしエンジンがネットワークレベルでの意思決定の財務的影響を評価できなければ、局所的な規則や、個別に計算可能な主要業績評価指標に頼るようになってしまいます。「理論上」の制約がすぐに「実践上」のドグマへと変わってしまうのです。
マシンを重視すると何が変わるか
話を逆転させてみましょう。もし、マシンが重要であるという前提から始めたらどうなるでしょうか。
まず、局所性を尊重したデータフローの設計を始めます。情報を何十ものテーブルに散らばらせ、各計算ごとにデータベースに再結合させるのではなく、アルゴリズムに必要なすべての情報をメモリの一巡で提供できるようにデータを整理します。これだけで性能が一桁向上する可能性があります。
第二に、逐次的な行ごとの処理ではなく、バッチ処理やベクトル化された操作を採用します。ハードウェアは、大きな配列に対して同じ操作を繰り返すのが非常に得意ですが、一方でメモリやネットワーク上を飛び回る無数の小さな無関係な問い合わせに答えるのは苦手です。サプライチェーンシステムの分析部分が、フォームベースの取引の集まりではなく、一貫したプログラムとして表現されると、その強みを活かすのがずっと容易になります。
第三に、原データから購買発注書やピックリストに現れる数量に至るまでの、全体の意思決定パイプラインを、プロファイリングや最適化、再設計が可能なものとして捉えます。「モデル」をブラックボックスとして扱うのをやめ、そのレシピをソフトウェアとして扱い始めるのです。これこそが、コンピュータグラフィックスや科学計算といった分野が、遅いプロトタイプから産業用ツールへと進化した理由であり、エンジニアたちは各層の非効率を削るために何年も費やしてきました。
直接的な利点は速度です。かつて6時間かかっていた計算が、今では6分あるいは6秒で済むかもしれません。しかし、より深い利点はその数字そのものではなく、その速度がもたらす可能性にあります。もしチームが週に1度のペースではなく、1日に100通りの再補充方針を試行できるなら、これまで考えもしなかったアイデアを探求するでしょう。混乱に応じてモデルを洗練し、代替の仮定を検証し、経済的に実現可能な範囲の最前線を徐々に押し広げていくのです。
これはオタクの虚栄ではなく、経済学である
これらすべてが、エンジニアがただ自身のために美しさに取り憑かれているように聞こえるかもしれません。しかし、棚に商品が並び、トラックが時間通りに出発すれば、アルゴリズムがどれだけキャッシュミスを起こしたかは問題ではないのです。
答えは、非効率には代償が伴うということです。クラウド時代においては、そのコストは二重に発生します。
直接的には、過剰なインフラという形で支払うことになります。もしソフトウェアが同じ意思決定を生み出すために必要以上に10倍の計算能力とストレージを要求するなら、クラウドプロバイダーやハードウェアに10倍の費用を支払うか、あるいは10倍長い実行時間を受け入れることになり、これは単なる別のコストに過ぎません。
さらに、意思決定ロジックの質が低下するという間接的なコストも発生します。非効率なシステムは、大規模に洗練された方針を計算するのに苦労するため、ベンダーはマシンに合わせるために数学を単純化します。確率分布を単一の数値に還元し、現実では密接に連動しているプロセスを切り離して別々に計算できるようにし、荒削りな近似を派手なダッシュボードの背後に隠すのです。その近道を見ることはないかもしれませんが、過剰な安全在庫、売上損失、ショックに対する脆弱な反応という形で必ず実感することになるでしょう。
対照的に、機械への共感は、計算資源を最も重要な部分、すなわち不確実性とトレードオフの探求に投資することを可能にします。効率的なシステムなら、経験則に頼るのではなく、何千もの未来をシミュレーションし、リスクを管理しながら期待利益を最大化する決定を選択する余裕があります。さらに、新しいデータに直面しても意思決定を常に新鮮な状態に保つために頻繁に再計算することができ、各ノードを個別に近視的に最適化するのではなく、ネットワーク全体を見渡すことが可能です。
その意味で、機械への共感は技術的な好みではなく、経済的な立場です。つまり、希少な計算資源を無意味なオーバーヘッドに浪費せず、実際にキャッシュフローを変える計算に投資するということです。
サプライチェーンリーダーに期待すること
これらすべては、すべてのサプライチェーン幹部がシステムプログラマーになる必要があるという意味ではありません。しかし、リーダーシップチームには基本的な規模感と方向性の認識が必要だと考えています。同じルートで走るトラックが、他の車両に比べて3倍の燃料を消費することが問題であると知るためにエンジンを設計する必要はありませんし、数秒で実行可能な計算に何時間もかかるシステムが問題であると判断するためにチップデザイナーである必要もありません。
ソフトウェアやベンダーを選ぶ際には、以下のような質問をすることにためらいを感じるべきではありません：
ネットワーク全体のすべての重要な決定を、現実的にどのくらいの頻度で再計算できるのでしょうか？
SKUや拠点の数を倍にしたら、実行時間は倍になるのか、それとも爆発的に増加するのか？
このプラットフォームが当社のデータを処理するために必要とするハードウェアはどの程度であり、2年後にその要件が急激に増大しないとどれほど確信できるのでしょうか？
もし回答が曖昧であったり、部屋の誰もがおおよその桁数すら見積もることができなければ、何か問題がある証拠です。LokadTVでの計算資源に関する議論では、これは基本的な地理学に例えられました。すべての山の正確な標高を知る必要はありませんが、ある道路がアルプスを横断しているのか、それとも平坦な平野を通っているのかは知っておくべきです。
同様に、社内チームは分析作業を、正しいか間違っているかの静的な「モデル」としてではなく、プロファイリングして改善可能なコードとして捉えるよう奨励されるべきです。パフォーマンスについて論理的に考える能力は、単位経済性を分析する能力が財務の一部であるのと同様に、プロフェッショナルな能力の一部です。
全く異なる種類の共感
機械への共感は、最終的には敬意の一形態です。
それはマシンへの敬意であり、私たちのサーバーが無限ではなく、その特性や限界が現実に存在することを認め、それらを無視することが危険であると理解することです。
また、これらのマシンに依存する人々、すなわち、タイムリーで信頼性のある提案を必要とするプランナー、実験の余地を求めるマネージャー、ソフトウェアの示す情報に基づいて資本を投入しなければならないエグゼクティブに対する敬意でもあります。
そして、それはサプライチェーンという分野そのものへの敬意でもあります。もし我々が、不確実性の中でより良い意思決定を行うことが我々の役割だと主張するなら、その意思決定を生み出す機械の質を軽視してはならないのです。我々は自分たち自身、そして信頼を寄せる企業に対して、計算資源を倉庫や車両と同じように真剣に扱う義務があるのです。
“主流の見解では、ハードウェアおよびソフトウェアの内部は舞台裏の問題、すなわち「IT部門が担当するもの」とみなされてきました。しかし、私はその見解がその有用性を終えたと考えています。サプライチェーンがアルゴリズムとデータに依存すれば依存するほど、機械にスポットライトを当てる必要があります。”
“メカニカル・シンパシーは、すべてのプランナーをプログラマーに変えることを意味するのではありません。それは、あらゆるレベルで、私たちのツールが実際にどのように機能しているのかについての十分な知識に基づいた好奇心を育むこと、そして遅さ、不透明さ、無駄を必然的なものとして受け入れるのを拒否することを意味します。”
