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

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

講義を見る

静的解析

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

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

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

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

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

配列プログラミング

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

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

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

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

ハードウェアの互換性

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

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

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

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

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

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

確率的プログラミング

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

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

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

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

微分可能プログラミング

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

カニバリゼーションと代替 - 同じカタログ内で - は、この文脈で解明する価値のある2つのモデルの問題です。両方のシナリオでは、複数の製品が同じ顧客を競合し、これにより予測の複雑さが増します。これらの力の下流効果は、主に傾向、季節性、ノイズを考慮した単一の製品に対してのみ捉えられることが一般的です。相互作用の可能性を考慮に入れていません。

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

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

コードとデータのバージョン管理

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

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

セキュアプログラミング

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

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

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

ノート