供給チェーンのためのプログラミングパラダイム（講義1.4の要約）

供給チェーンの問題は悪質であり、適切なプログラミングツールを使わずにこれらの問題に取り組むことは、大規模な企業の文脈で常に高額な学習経験となります。効果的な供給チェーンの最適化は、物理的および抽象的な複雑さの散在するネットワークであり、現代的でアジャイルかつ革新的なプログラミングパラダイムのスイートが必要です。これらのパラダイムは、供給チェーンに固有のさまざまな問題の正確な特定、考慮、および解決に不可欠です。

講義を見る

静的解析

プログラマでなくてもプログラマのように考えることができ、適切な供給チェーンの問題の分析は、単にプログラミングツールではなく、プログラミングのマインドセットで取り組むことが最善です。従来のソフトウェアソリューション（ERPなど）は、問題を実行時ではなくコンパイル時¹に対処するように設計されています。

これは反応型の解決策と予防型の解決策の違いです。この違いは重要であり、反応型の解決策は財務面および帯域幅の両面で予防型の解決策よりもはるかに高価になる傾向があります。これらの回避可能なコストは、プログラミングのマインドセットが回避しようとするものであり、静的解析はこのフレームワークの表現です。

静的解析は、実行せずにプログラム（この場合は最適化）を検査し、製造に影響を与える前に潜在的な問題を特定する手段として行われます。Lokadは、ドメイン固有言語（DSL）であるEnvisionを介して静的解析に取り組んでいます。これにより、設計レベル（プログラミング言語内）でのミスの特定と修正ができるようになります。

倉庫を建設する企業を考えてみましょう。倉庫を建ててからそのレイアウトを考えるわけではありません。代わりに、通路、ラック、積み込みドックの戦略的な配置は事前に考慮され、建設前に潜在的なボトルネックを特定します。これにより、将来の倉庫内での最適な設計とした流れが可能になります。この注意深い設計は、LokadがEnvisionを通じて実現する静的解析の一種です。

ここで説明した静的解析は、最適化の基礎となるプログラムをモデル化し、インストールする前にレシピ内の潜在的な敵対的な動作を特定します。これらの敵対的な傾向には、必要以上の在庫の誤った注文が発生するバグが含まれる可能性があります。その結果、そのようなバグは混乱を引き起こす前にコードから削除されます。

配列プログラミング

サプライチェーンの最適化では、厳密なタイミングが重要です。たとえば、小売チェーンでは、データを60分以内に統合し、最適化して倉庫管理システムに渡す必要があります。計算に時間がかかりすぎると、サプライチェーン全体の実行が危険にさらされる可能性があります。配列プログラミングは、特定のプログラミングエラーのクラスを排除し、計算時間を保証することで、サプライチェーンの実践者にデータ処理の予測可能な時間枠を提供します。

データフレームプログラミングとも呼ばれるこのアプローチでは、操作を単一のデータ要素ではなく、データ配列全体に直接適用することができます。Lokadは、そのDSLであるEnvisionを活用してこれを実現しています。配列プログラミングにより、データの個々のエントリではなく、データの列全体に対して操作を行うことができるため、分析の効率が大幅に向上し、プログラミングのバグの可能性も低くなります。

倉庫管理者が2つのリストを持っていると考えてみましょう。リストAは現在の在庫レベルであり、リストBはリストAの製品の入荷です。リストAの現在の在庫レベルに入荷（リストB）を手動で1つずつ追加する代わりに、より効率的な方法は両方のリストを同時に処理し、一度にすべての製品の在庫レベルを更新することです。これにより、時間と労力の両方を節約することができ、基本的には配列プログラミングが行うことです²。

実際には、配列プログラミングにより、サプライチェーンの最適化に関与する膨大な量のデータの計算を並列化および分散化することが容易になります。計算を複数のマシンに分散することで、コストを削減し、実行時間を短縮することができます。

ハードウェアの互換性

サプライチェーンの最適化における主なボトルネックの1つは、サプライチェーンサイエンティストの数が限られていることです。これらのサイエンティストは、クライアントの戦略や競合他社の敵対的な操縦を考慮して、実行可能な洞察を生み出すための数値レシピを作成する責任があります。

これらの専門家を見つけること自体が難しいだけでなく、見つけた後もタスクの迅速な実行から彼らを分離するいくつかのハードウェアの障壁をクリアする必要があります。さまざまなシステム内のさまざまなコンポーネントが混ざり合い、協力して動作することができるハードウェアの互換性は、これらの障壁を取り除くために重要です。ここでは、次の3つの基本的なコンピューティングリソースが考慮されます：

• コンピュート： CPUまたはGPUによって提供されるコンピュータの処理能力。
• メモリ： RAMまたはROMを介してホストされるコンピュータのデータストレージ容量。
• 帯域幅： コンピュータの異なる部分間、またはコンピュータネットワーク全体で情報（データ）を転送できる最大速度。

大量のデータセットを処理することは一般に時間がかかるプロセスであり、エンジニアがジョブの実行を待つことにより生産性が低下します。サプライチェーンの最適化では、コードの断片（中間計算ステップを表す）を固体状のドライブ（SSD）に保存することができます。この単純な手順により、似たようなスクリプトをわずかな変更で実行することができ、生産性が大幅に向上します。

上記の例では、安価なメモリハックを利用してコンピュートのオーバーヘッドを低減しています。システムは処理中のスクリプトがほぼ前回のものと同じであることに気づき、コンピュートを数秒で実行できるようにします。これにより、数十分ではなく数秒で処理が完了します。

このようなハードウェアの互換性により、企業は投資額から最大の価値を引き出すことができます。

確率的プログラミング

可能な未来の結果は無限に存在しますが、すべてが等しく確率的ではありません。この不可避な不確実性を考慮して、プログラミングツールは確率的予測のパラダイムを採用する必要があります。Excelは長い間多くのサプライチェーンの基盤となってきましたが、確率的予測を使用してスケールで展開することはできません。なぜなら、このタイプの予測には確率変数の代数を処理する能力が必要だからです³。

簡潔に言えば、Excelは主に確定的なデータ（つまり、固定値、静的な整数など）に対して設計されています。確率関数を実行するためには一部の機能を変更することもできますが、確率的需要予測で遭遇する複雑な確率変数の操作に対応するために必要な高度な機能、柔軟性、表現力は備えていません。むしろ、Envisionなどの確率的プログラミング言語がサプライチェーンで遭遇する不確実性を表現し処理するのに適しています。

自動車のアフターマーケット店舗がブレーキパッドを販売しているとします。この仮想的なシナリオでは、顧客は2個または4個単位でブレーキパッドを購入する必要があり、店舗は需要予測時にこの不確実性を考慮する必要があります。

もし店舗が確率的プログラミング言語（スプレッドシートの群れではなく）にアクセスできる場合、確率変数の代数を使用して総消費量をより正確に推定することができます。一般的なプログラミング言語ではこのような機能はほとんど備わっていません。

微分可能プログラミング

サプライチェーンの最適化の文脈において、微分可能プログラミングは提供されたデータに基づいて数値的なレシピを学習し適応させることができます。微分可能プログラミングは、確率的勾配降下法と組み合わせることで、サプライチェーンの中で複雑なパターンや関係性を発見することができます。パラメータは新しいプログラミングの反復ごとに学習され、このプロセスは何千回も繰り返されます。これにより、現在の予測モデルと過去のデータとの間の不一致を最小限に抑えることができます⁴。

キャニバリゼーションと代替 - 同じカタログ内で - は、この文脈で解明する価値のある2つのモデルの問題です。両方のシナリオでは、複数の製品が同じ顧客を対象に競合し、予測の複雑さが増します。これらの力の下流効果は、通常の時系列予測ではほとんど捉えられません。時系列予測は主にトレンド、季節性、ノイズを「単一の製品」に対して考慮し、相互作用の可能性を考慮しません。

微分可能プログラミングと確率的勾配降下法を利用することで、顧客と製品をリンクするトランザクションの過去のデータを分析するなど、これらの問題に対処することができます。Envisionは、トランザクション、日付、製品、顧客、購入数量などの十分な履歴の深さを含むシンプルなフラットファイルを読み取ることで、このような調査 - アフィニティ分析と呼ばれるもの - を実行することができます⁵。

Envisionはわずか数行のコードを使用して、顧客と製品の関連性を特定することができます。これにより、サプライチェーンの科学者は関心のある推奨事項を提供する数値レシピをさらに最適化することができます⁶。

コードとデータのバージョニング

長期的な最適化の持続可能性を確保するためには、数値レシピ（コードのすべての構成要素とデータの断片を含む）をソース化、トラッキング、再現できることが重要です⁷。このバージョニング機能がないと、狂気じみた例外が必ず発生するときに、レシピを逆算する能力が大幅に低下します（コンピュータの世界では「ハイゼンバグ」と呼ばれます）。

ハイゼンバグは最適化計算に問題を引き起こす厄介な例外ですが、プロセスを再実行すると消えてしまいます。これにより、修正が非常に困難になり、一部の取り組みが失敗し、サプライチェーンがExcelスプレッドシートに戻ることがあります。ハイゼンバグを回避するためには、最適化のロジックとデータの完全な再現性が必要です。これには、プロセスで使用されるすべてのコードとデータのバージョニングが必要であり、環境を過去の任意の時点の正確な条件に再現できるようにする必要があります。

セキュアプログラミング

デジタル化が進むサプライチェーンは、サイバー攻撃やランサムウェアなどのデジタル脅威に対する脆弱性を伴います。この点で、混乱の主な原因は2つあります。1つは使用するプログラム可能なシステム、もう1つはそれを使用する人々です。後者に関しては、偶発的な無能さを考慮するのは非常に困難です（意図的な悪意の事例については言及しません）；前者に関しては、意図的な設計レベルの選択肢は、これらの地雷を回避するために重要です。

貴重なリソースをサイバーセキュリティチームの増強に投資する代わりに（消火活動などの反応的な行動を予想して）、プログラムシステムの設計フェーズでの慎重な決定により、下流のさまざまな問題を解決することができます。Lokadの場合、SQLデータベースなどの冗長な機能を削除することで、SQLインジェクション攻撃などの予測可能な災害を防ぐことができます。同様に、Lokadでは追加専用の永続化レイヤーを選択することで、データの削除（友人または敵による）をより困難にすることができます⁸。

ExcelとPythonにはそれぞれ利点がありますが、これらの講義で議論されているスケーラブルなサプライチェーン最適化に必要なプログラミングセキュリティは欠けています。

ノート