00:28 イントロダクション
00:43 ロバート・A・ハインライン
03:03 これまでのストーリー
06:52 パラダイムの選択
08:20 静的解析
18:26 配列プログラミング
28:08 ハードウェアの互換性
35:38 確率的プログラミング
40:53 差分可能プログラミング
55:12 コード+データのバージョニング
01:00:01 セキュアプログラミング
01:05:37 結論として、ツールの重要性もサプライチェーンにおいて重要です
01:06:40 今後の講義と視聴者の質問
説明
一般的なサプライチェーン理論は企業全体で普及するのに苦労していますが、Microsoft Excelというツールはかなりの運用上の成功を収めています。一般的なサプライチェーン理論の数値レシピをスプレッドシートを介して再実装することは簡単ですが、実際にはそれが実践されていません。スプレッドシートがサプライチェーンの結果を提供するために優れたプログラミングパラダイムを採用したことを示します。
フルトランスクリプト
皆さん、サプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は私の4回目の講義「サプライチェーンのためのプログラミングパラダイム」を紹介します。
「ヴェルモレルさん、サプライチェーンの知識においてあなたにとって最も興味深い分野は何ですか？」と聞かれたとき、私のトップの答えの一つは通常、プログラミングパラダイムです。そして、あまり頻繁ではありませんが、頻繁にはありますが、私が話している相手の反応は、「プログラミングパラダイム、ヴェルモレルさん？ 一体何を言っているのですか？ それはどのようにして現在の課題に関連しているのですか？」というものです。そして、このような反応は頻繁ではありませんが、それが起こるたびに、科学小説作家のドイアン・A・ハインラインが述べたこの信じられないほどの引用を思い出させられます。彼は、能力のある人について素晴らしい引用をしており、特に私たちが手にしている困難な問題があるサプライチェーンにおいては、さまざまな分野での能力の重要性を強調しています。これらの問題は人生自体と同じくらい挑戦的ですし、プログラミングパラダイムの考えを探求することは、サプライチェーンに多くの価値をもたらす可能性があると私は信じています。
ハインラインは、能力のある人についての素晴らしい引用をしており、私たちが手にしている困難な問題、特にサプライチェーンにおいては、その能力の重要性を強調しています。これらの問題は人生自体と同じくらい挑戦的ですし、私はサプライチェーンにとってプログラミングパラダイムの考えを探求することは非常に価値があると考えています。
これまでの講義では、サプライチェーンの問題が困難であることを見てきました。最適な解決策について話す人は、問題の本質を見誤っています。最適性にはほど遠いものがあります。2回目の講義では、サプライチェーン管理における偉大さのための5つの主要な要件を持つ量的サプライチェーンについて説明しました。これらの要件は単独では十分ではありませんが、偉大さを達成したい場合には回避できません。
3回目の講義では、サプライチェーン最適化の文脈でソフトウェア製品の提供について議論しました。サプライチェーン最適化には、資本主義的な方法でソフトウェア製品に対処する必要があると主張しましたが、そのような製品は棚から見つけることはできません。多様性がありすぎて、現在の技術では対応できないほどの課題が待ち受けています。したがって、それは必然的に完全に特注のものになるでしょう。したがって、会社や関心のあるサプライチェーンに特注のソフトウェア製品がある場合、実際にこの製品を提供するための適切なツールは何かという問題があります。それが今日のトピックにつながります：適切なツールは、適切なプログラミングパラダイムから始まります。なぜなら、どのような方法であれ、この製品をプログラムする必要があるからです。
これまで、問題の最適化側に対処するためにプログラムの能力が必要であることがわかりましたが、管理側とは混同しないでください。私の前の講義のテーマであったMicrosoft Excelがこれまでの勝者であることがわかりました。非常に小さな会社から非常に大きな会社まで、どこでも使われています。数百万ドルを投資して超スマートなシステムを持つ企業でも、Excelがまだ主流です。なぜなら、それには適切なプログラミングの特性があるからです。非常に表現力があり、アジャイルでアクセスしやすく、保守性があります。ただし、Excelは最終目標ではありません。私は断固として、私たちはもっと多くのことができると信じていますが、適切なツール、マインドセット、洞察力、およびプログラミングパラダイムを持つ必要があります。
プログラミングパラダイムは、聴衆にとって過度に難解に感じるかもしれませんが、実際には過去50年間で集中的に研究されてきた研究分野です。多くの人々によって行われた高品質な研究成果が、広く知られているわけではありませんが、それらのアイデアを私たちの前に発明した人々から取り入れたライブラリが存在します。今日は、Lokadが採用した7つのパラダイムを紹介します。これらのアイデアは私たちが発明したものではありません。これらのパラダイムは、Lokadのソフトウェア製品に実装されており、Lokadをほぼ10年間運用してきた結果、これらのパラダイムを活用することが私たちの業務の成功に絶対に重要であると信じています。
このリストを静的解析で進めましょう。問題は複雑さです。サプライチェーンで複雑さにどう対処するのでしょうか？数百のテーブルがあり、それぞれに数十のフィールドがあるエンタープライズシステムに直面することになります。在庫の単純な問題を考えると、考慮すべきことがたくさんあります。最小発注量（MOQ）、価格の変動、需要の予測、リードタイムの予測、さまざまな返品などがあります。棚のスペース制限、受け入れ能力の制限、バッチの賞味期限が切れていることもあります。したがって、考慮すべきことがたくさんあります。サプライチェーンでは、「素早く進めて問題を解決する」という考え方は適切ではありません。必要のない商品を100万ドル分誤って注文してしまった場合、非常に高額なミスになります。サプライチェーンを制御するソフトウェアが、日常的な意思決定を行い、バグがあると数百万ドルの損失につながることは避けなければなりません。私たちは、設計段階で非常に高い正確性を持つものが必要です。バグを本番環境で発見したくありません。これは、クラッシュが大した問題ではない通常のソフトウェアとは非常に異なる状況です。
サプライチェーンの最適化に関しては、通常の問題ではありません。間違った大量の注文をサプライヤーに渡した場合、1週間後に電話して「ああ、私の間違いでした。それは忘れてください。私たちはそれを注文していませんでした」と言うことはできません。そのようなミスは多額の費用がかかります。静的解析とは、プログラムを実行せずにプログラムを分析することを指します。つまり、ステートメント、キーワードなどで書かれたプログラムを実行せずに、そのプログラムがほぼ確実に製品、特にサプライチェーンの製品に悪影響を及ぼす問題を既に検出できるかどうかを判断できるのです。その答えは「はい」です。このような技術は存在し、実装されており、非常に価値があります。
例を挙げると、画面にはEnvisionのスクリーンショットが表示されています。Envisionは、サプライチェーンの予測最適化に特化したドメイン固有のプログラミング言語で、Lokadによって10年近くにわたって開発されています。表示されているのは、コードエディターのスクリーンショットです。このウェブアプリはオンラインでコードを編集するために使用できます。構文はPythonの影響を強く受けています。この小さなスクリーンショットでは、在庫の補充に関する大規模なロジックを記述し、価格の変動などの経済変数を導入する場合、プログラムの論理的な分析を通じて、価格の変動が返される結果にまったく影響を与えないことがわかります。ここで、明らかな問題があります。価格の変動という重要な変数を導入しましたが、それらの価格の変動は結果に論理的には何の影響も与えていません。したがって、プログラムの出力に影響を与えないコードを導入した場合、明らかな問題が発生します。この場合、2つのオプションがあります。それらの変数が実際にはデッドコードであり、プログラムをコンパイルすべきではない場合（このデッドコードを削除して複雑さを減らし、偶発的な複雑さを積み重ねないようにする）、または本当のミスであり、計算に組み込むべき重要な経済変数があり、気を散らしていたか、他の理由で見落としてしまった可能性があります。
静的解析は、設計時に正確さを実現するために絶対に基本的です。コードを書くときにコンパイル時に問題を修正することであり、データに触れる前に問題を修正することです。実行時に問題が発生した場合、問題は夜間にのみ発生する可能性があります。夜間のバッチが倉庫の補充を行うときにのみ問題が発生します。プログラムは、誰もプログラムの前にいないときに奇妙な時間に実行される可能性が高いため、プログラムの前に誰もいないときにクラッシュすることは望ましくありません。実際にコードを書いているときにクラッシュするべきです。
静的解析には多くの目的があります。たとえば、Lokadでは、ダッシュボードのWYSIWYG編集に静的解析を使用しています。WYSIWYGは「what you see is what you get」の略です。レポート用のダッシュボードを作成していると想像してください。折れ線グラフ、棒グラフ、テーブル、色、さまざまなスタイル効果があります。これを視覚的に行いたいので、コードを介してダッシュボードのスタイルを微調整する必要はありません。実装したすべての設定はコード自体に再注入され、それは静的解析を通じて行われます。
Lokadでは、サプライチェーン全体にはあまり重要ではないかもしれませんが、プロジェクトにとっては非常に重要なEnvisionというプログラミング言語を扱うことがありました。私たちは、ほぼ10年前から、最初の日から、ミスが発生することを知っていました。最初の日から完璧なビジョンを持つための水晶玉はありませんでした。問題は、プログラミング言語自体で設計上のミスをできるだけ便利に修正できるようにする方法です。ここで、Pythonは私にとって警告の物語でした。
Pythonは、新しい言語ではありませんが、1991年に最初にリリースされ、ほぼ30年前です。Python 2からPython 3への移行には、コミュニティ全体でほぼ10年かかり、この移行に関与した企業にとっては非常に苦痛なプロセスでした。私の認識では、言語自体には十分な構造がありませんでした。プログラミング言語のバージョン間でプログラムを移行することは、完全に自動化された方法で行うことが非常に困難でした。それは、Pythonが静的解析を考慮して設計されていないためです。サプライチェーンのためのプログラミング言語を持つときには、静的解析の品質が優れているものが必要です。サプライチェーンは長期間にわたって存在するため、システムを一時停止することなく修正する必要があります。列車が全速力で走っている間にエンジンを修理したいのと同じです。実際に製造中のサプライチェーンの問題を修正することは、システムを一時停止する余裕がありません。
2番目のパラダイムは配列プログラミングです。サプライチェーンでは、複雑さを制御したいというのが大きなテーマです。プログラマが明示的に書いたループやブランチがある場合、非常に困難な問題のクラスに自分自身をさらすことになります。計算の期間に対する保証を持つために、人々が任意のループを書くことができると、非常に困難になります。それはニッチな問題のように思えるかもしれませんが、サプライチェーンの最適化ではそうではありません。
実際には、小売チェーンがあるとします。深夜には、ネットワーク全体からのすべての販売が完全に統合され、データが統合され、最適化のためのシステムに渡されます。このシステムは、ネットワークのすべての店舗に対して予測、在庫最適化、再割り当ての決定を行うために、正確に60分のウィンドウを持ちます。完了したら、結果は倉庫管理システムに渡され、すべての出荷の準備が開始されます。トラックは、たとえば午前5時に積み込まれ、午前9時までには商品が受け取られ、棚に並べられている状態で店舗がオープンします。
ただし、非常に厳密なタイミングがあり、計算がこの60分のウィンドウを超えると、供給チェーンの実行全体が危険にさらされます。何時間かかるかを本番で発見するだけのものではありません。人々が何回繰り返すかを決めるループがある場合、計算の所要時間を証明するのは非常に難しいです。これは供給チェーンの最適化について話していることを念頭に置いてください。ピアレビューやすべてのものを二重チェックする余裕はありません。パンデミックのため、一部の国は閉鎖され、他の国は通常24時間前の通知で再開されます。迅速に対応する必要があります。
したがって、配列プログラミングとは、配列に直接操作できるという考え方です。ここにあるコードのスニペットを見てみると、これはLokadのDSLであるEnvisionコードです。何が起こっているかを理解するには、「orders.amounts」と書いているときに、変数が来ていることと、「orders」が実際にはテーブルであることを理解する必要があります。たとえば、ここでは、最初の行で「amounts」はテーブルの列になります。1行目では、注文テーブルの各行に対して、「quantity」という列を取り、「price」と掛け算し、動的に生成された3番目の列である「amount」を取得しています。
ちなみに、現代の配列プログラミングの新しい用語は、データフレームプログラミングとも呼ばれています。この研究分野はかなり古く、3〜4十年前にさかのぼることができます。配列プログラミングとして知られていましたが、現在では人々は通常、データフレームのアイデアにより馴染みがあると言えます。2行目では、SQLと同様にフィルタリングを行っています。日付をフィルタリングしており、注文テーブルには日付があります。フィルタリングされ、“date that is greater than today minus 365"と指定しています。つまり、昨年のデータを保持し、“products.soldLastYear = SUM(orders.amount)“と書いています。
さて、興味深いことに、productsとordersの間には自然結合があります。なぜなら、すべての注文行は1つの製品に関連付けられており、1つの製品は0個以上の注文行に関連付けられているからです。この構成では、直接「注文レベルで何が起こっているかの合計」という形で製品レベルで何かを計算することができます。これが9行目で行われていることです。構文は非常にシンプルで、多くの偶然や技術的な要素はありません。私はこのコードはデータフレームプログラミングにおいてほとんど偶然がないと主張します。そして、10行目、11行目、12行目では、テーブルをダッシュボードに表示しています。これは非常に便利に行うことができます。「LIST(PRODUCTS)」、そして「TO(products)」です。
供給チェーンにおける配列プログラミングの多くの利点があります。まず、問題のクラス全体が排除されます。配列のオフバイワンのバグは発生しません。計算を並列化し、さらに分散することがはるかに簡単になります。これは非常に興味深いことです。なぜなら、プログラムを書いて、そのプログラムを1つのローカルマシンではなく、クラウドに存在する複数のマシンのフリートで実行できるからです。ちなみに、これはLokadで行われていることです。この自動並列化は非常に興味深いものです。
供給チェーンの最適化を行う際、通常の計算ハードウェアの消費パターンは非常に断続的です。例えば、店舗の補充中における60分間のウィンドウについての例に戻ると、計算を行うために1日に1時間だけコンピューティングパワーが必要ですが、その他の23時間では必要ありません。したがって、実行する準備が整ったプログラムは、多くのマシンに広がり、完了したらすべてのマシンを解放して他の計算が行われるようにする必要があります。代替案としては、1日中レンタルして使用するが、そのうちの5%しか使用しない多くのマシンを持つことが考えられますが、これは非効率です。
このように、多くのマシンに迅速かつ予測可能に分散し、その処理能力を放棄するアイデアは、Lokadが行っているクラウドのマルチテナント環境とその上にある一連の他の要素を必要とします。しかし、何よりもまず、プログラミング言語自体からの協力が必要です。これは、Pythonのような汎用のプログラミング言語では実現不可能です。なぜなら、言語自体がこのような非常にスマートで関連性のあるアプローチに適していないからです。これは単なるトリック以上のものであり、ITハードウェアのコストを20分の1に削減し、実行を大幅に加速し、供給チェーンにおける潜在的なバグのクラス全体を排除するものです。これはゲームチェンジです。
配列プログラミングは、NumPyやPythonのpandasなど、多くの側面で既に存在しています。これらは、データサイエンティストのセグメントで非常に人気があります。しかし、重要で便利なのであれば、なぜこれらのものが言語自体の第一級の要素ではないのでしょうか？ NumPyを通じてチャネルを流すだけであれば、NumPyは第一級の要素であるべきです。NumPy以上のことができると言えます。NumPyは単に1台のマシン上での配列プログラミングについてですが、なぜクラウドにアクセス可能なハードウェア機能がある場合には、複数のマシンでの配列プログラミングを行わないのでしょうか？それははるかに強力で、適切です。
では、供給チェーンの最適化においてボトルネックとなるのは何でしょうか？ゴルドラットの言葉によれば、「供給チェーンのボトルネック以外の改善は幻想である」ということですが、私はこの言葉に非常に同意します。現実的には、供給チェーンの最適化を行う際、ボトルネックは人々であり、具体的には供給チェーンの科学者です。残念ながら、Lokadや私のクライアントにとっては、供給チェーンの科学者は木から生えてくるものではありません。
ボトルネックは、供給チェーンの科学者であり、会社の戦略、競合他社の敵対的な行動を考慮に入れた数値レシピを作成し、その知識を機械的なものに変換してスケールで実行できる人々です。私が博士課程を始めたときにデータサイエンスを行う方法について考えたとき、私は実際にはみんながデータサイエンスを行っていることがわかりました。ほとんどの人々は、いくつかの高度な機械学習モデルのためのコードを書き、Enterキーを押してから待機していました。データセットが大きい場合、例えば5〜10ギガバイトの場合、リアルタイムではありません。したがって、実験を行いたいときには、数行のコードを書いてEnterキーを押し、コーヒーを飲んだりオンラインで何かを読んだりする人々で溢れている研究室でした。そのため、生産性は非常に低かったのです。
自分自身の会社を立ち上げる際、私は自分の一日の大半をコーヒーを飲みながら待っている非常に頭の良い人々の軍団に給料を払いたくありませんでした。理論的には、彼らは同時に多くのことを並列化し、実験を実行することができますが、実際にはそれを見たことがありません。知的に問題の解決に取り組んでいるときには、仮説をテストしたいと思い、結果が必要です。非常に技術的なことに多重タスクをこなし、同時に複数の知的なトラックを追いかけることは非常に難しいです。
しかし、一筋の光明がありました。Lokadのデータサイエンティスト、そして現在のサプライチェーンサイエンティストは、「実行してください」と言ってから1000行のコードを書くことはありません。通常、彼らは1000行のスクリプトに2行追加し、スクリプトの実行を要求します。このスクリプトは、彼らがちょうど数分前に実行したデータとまったく同じデータに対して実行されています。ほぼ同じロジックですが、2行だけが異なります。では、なぜ数分ではなく数秒でテラバイトのデータを処理できるのでしょうか？その答えは、スクリプトの前回の実行で計算の中間ステップをすべて記録し、それらをストレージ（通常はソリッドステートドライブまたはSSD）に保存しているからです。これらのストレージは非常に安価で高速で便利です。
次回プログラムを実行すると、システムはほぼ同じスクリプトであることに気付きます。差分を取り、計算グラフの観点からほぼ同一であることを確認します。データの観点では、通常は100％同一です。時にはわずかな変更があるかもしれませんが、ほとんどありません。システムは、計算する必要があるのはわずかな要素だけであることを自動的に診断し、数秒で結果を得ることができます。これにより、サプライチェーンサイエンティストの生産性が劇的に向上します。結果を待つために20分間エンターキーを押す人から、エンターキーを押して5秒または10秒後に結果を得て次に進むことができる人になるのです。
これは非常にマイナーなことのように思えるかもしれませんが、実際には生産性に10倍の影響を与えるものです。これは非常に大きなことです。したがって、私たちがここで行っていることは、Lokadが発明したわけではない巧妙なトリックを使用しています。計算という生のコンピューティングリソースを、メモリとストレージという別のリソースに置き換えています。基本的なコンピューティングリソースである計算、メモリ（ボラティルまたは永続的）、および帯域幅を持っています。これらは、クラウドコンピューティングプラットフォームでリソースを購入する際に支払う基本的なリソースです。実際には、1つのリソースを別のリソースに置き換えることができ、目標は最大の効果を得ることです。
メモリ内コンピューティングを使用するべきだと言われると、それはナンセンスだと言います。メモリ内コンピューティングと言うと、他のすべてのリソースに比べて1つのリソースに設計の重点を置いていることを意味します。しかし、いいえ、トレードオフがあります。興味深いことは、トレードオフと視点を実装しやすくするプログラミング言語と環境を持つことができるということです。一般的な汎用プログラミング言語では、それを行うことは可能ですが、手動で行う必要があります。つまり、それを行う人はプロのソフトウェアエンジニアでなければなりません。サプライチェーンサイエンティストは、プラットフォームの基本的なコンピューティングリソースでの低レベルの操作を行うことはありません。これはプログラミング言語自体のレベルで設計されなければなりません。
さて、確率的プログラミングについて話しましょう。量的サプライチェーンのビジョンを紹介した第2回の講義で、私の最初の要件は、すべての可能な未来を考慮する必要があるということでした。この要件への技術的な回答は、確率的予測です。確率を持つ未来に対処する必要があります。すべての未来は可能ですが、すべてが同じ確率ではありません。不確実性を計算できる代数が必要です。Excelに対する私の大きな批判の1つは、不確実性を表現するのが非常に難しいことです。Excelであろうと、より現代的なクラウドベースのバリエーションであろうと、スプレッドシートでは、数値以上のものが必要です。
この小さなスニペットでは、Envisionのネイティブ機能であるランダム変数の代数を示しています。1行目では、平均が2の離散的なポアソン分布を生成し、それを変数Xに入れています。次に、同じように別のポアソン分布Yを生成しています。そして、ZをXとYの乗算として計算しています。ランダム変数の乗算というこの操作は、非常に奇妙に思えるかもしれません。なぜサプライチェーンの観点からこのようなものが必要なのでしょうか？例を挙げましょう。
自動車のアフターマーケットでブレーキパッドを販売しているとしましょう。人々は単位でブレーキパッドを購入するのではなく、2つまたは4つ購入します。したがって、予測を行いたい場合、クライアントが特定のタイプのブレーキパッドを実際に購入する確率を予測したいと思うかもしれません。それがブレーキパッドの需要の0単位、1単位、2単位、3単位、4単位などを観測する確率を与える最初のランダム変数になります。次に、2つまたは4つのブレーキパッドを購入するかどうかを表す別の確率分布があります。おそらく50-50になるかもしれませんし、10％が2つを購入し、90％が4つを購入するかもしれません。問題は、これら2つの観点があることであり、実際のブレーキパッドの総消費量を知りたい場合、このブレーキパッドのクライアントが現れる確率と2つまたは4つを購入する確率分布を乗算する必要があるということです。したがって、これら2つの不確実な量の乗算を行う必要があります。
ここでは、2つのランダム変数が独立していると仮定しています。ちなみに、ランダム変数のこの乗算は数学では離散畳み込みとして知られています。スクリーンショットでは、Envisionによって生成されたダッシュボードが表示されています。最初の3行では、このランダムな代数計算を行い、4行目、5行目、6行目では、それらのものをウェブページやスクリプトによって生成されたダッシュボードに表示しています。たとえば、A1、B2をプロットしています。Lokadのダッシュボードは、Excelのグリッドと同様に配置されており、位置には列B、Cなどがあり、行には1、2、3、4、5があります。
離散畳み込みであるZは、非常に奇妙で、非常に尖ったパターンを持っています。これは、人々がパックやロット、または複数のものを購入できるサプライチェーンで非常に一般的に見られるものです。このような状況では、ロットやパックに関連する乗算イベントのソースを分解する方が通常は良いです。最初級の市民として利用できるこれらの機能を持つプログラミング言語が必要です。それが確率的プログラミングの本質であり、それが私たちがEnvisionで実装した方法です。
さて、微分可能プログラミングについて話しましょう。ここで注意が必要です：聴衆が実際に何が起こっているかを理解することは期待していませんし、そのことをお詫び申し上げます。それはあなたの知性が欠けているわけではなく、このトピックは一連の講義を必要とするものです。実際、今後の講義の計画を見ると、微分可能プログラミングに専念した一連の講義があります。私は超高速で進む予定ですし、かなり難解になるでしょうので、あらかじめお詫び申し上げます。
ここで興味のある供給チェーンの問題、つまりカニバリゼーションと代替に進みましょう。これらの問題は非常に興味深く、普遍的である時系列予測が最も厳しい方法で失敗する場所です。なぜなら、しばしば私たちには、バックパックのような特定のアイテムの13週先の予測を行うことができるかというクライアントや見込み客が訪れるからです。私は「はい、できます」と言うでしょうが、明らかに、1つのバックパックを取り上げてこの製品の需要を予測する場合、他のバックパックをどのように使用するかに大きく依存します。1つのバックパックしか持っていない場合、おそらくすべてのバックパックの需要がこの1つの製品に集中するでしょう。10の異なるバリアントを導入すると、明らかに多くのカニバリゼーションが発生します。参照数を10倍にしたからといって、売上総額が10倍になるわけではありません。したがって、カニバリゼーションと代替が発生します。これらの現象は供給チェーンで一般的です。
カニバリゼーションや代替をどのように分析しますか？私たちがLokadで行っている方法は、唯一の方法ではないかもしれませんが、確実に機能する方法です。それは、クライアントと製品を接続するグラフを見ることです。なぜなら、カニバリゼーションは、製品が同じクライアントに対して自己競争しているときに起こるからです。カニバリゼーションは、クライアントがニーズを持っているが、好みがあり、彼らの親和性に合う製品のセットから1つを選び、1つだけを選ぶということです。それがカニバリゼーションの本質です。
それを分析するためには、売上の時系列を分析するのではなく、クライアントと製品の間の過去の取引を接続するグラフを分析する必要があります。実際、ほとんどのビジネスでは、このデータは簡単に利用できます。eコマースの場合、それは当然のことです。販売するすべてのユニットについて、クライアントを知っています。B2Bの場合も同じです。小売りのB2Cでも、ほとんどの場合、小売チェーンは現在、ロイヤリティプログラムを持っており、カードを持って現れる顧客の二桁パーセンテージを把握しているため、誰が何を買っているかを知っています。すべてのトラフィックに対してではありませんが、それは必要ありません。過去の取引の10％以上で、クライアントと製品のペアを知っている場合、このような分析に十分です。
この比較的小さなスニペットでは、クライアントと製品の間の親和性分析について詳しく説明します。これは、カニバリゼーション分析を行うために取る必要のある基本的なステップです。このコードで何が起こっているかを見てみましょう。
1行から5行までは非常に平凡です。単に、取引の履歴を含むフラットファイルを読み込んでいます。4つの列（日付、製品、クライアント、数量）を持つCSVファイルを読み込んでいるだけです。非常に基本的なことです。すべての列を使用しているわけではありませんが、例を具体的にするためだけです。取引履歴では、すべての取引でクライアントが既知であると仮定しています。非常に平凡です。単にテーブルからデータを読み込んでいます。
次に、7行と8行では、製品のテーブルとクライアントのテーブルを作成しています。実際のプロダクションセットアップでは、通常、これらのテーブルを作成するのではなく、他のフラットファイルからこれらのテーブルを読み込みます。例を非常にシンプルに保つために、トランザクション履歴で観察された製品から製品テーブルを抽出し、クライアントについても同様にします。見ての通り、それは非常にシンプルに保つためのトリックです。
さて、10行目、11行目、12行目では、ラテンスペースに関わることになりますが、これは少し難解になります。まず、10行目では、64行のテーブルを作成しています。このテーブルには何も含まれていません。64行で定義されているだけです。これは、単なるプレースホルダーであり、多くの行と列を持たない単純なテーブルです。それだけではあまり役に立ちません。そして、「P」は基本的にはデカルト積です。これは、製品の各行とテーブル「L」の各行のすべての組み合わせで構成されるテーブルです。したがって、このテーブル「P」は製品テーブルよりも64行多くなります。クライアントについても同じことをしています。この追加の次元でこれらのテーブルを膨らませています。この追加の次元はテーブル「L」です。
これが私のラテンスペースのサポートになります。これが私が学ぶものです。私が学びたいのは、製品ごとに64個の値のベクトルであるラテンスペースであり、クライアントごとにも64個の値のラテンスペースです。クライアントと製品の関連性を知りたい場合、2つのベクトルのドット積を計算するだけで済みます。ドット積は、2つのベクトルの各項を要素ごとに掛け合わせ、その合計を取るだけです。非常に技術的に聞こえるかもしれませんが、それは要素ごとの乗算と合計です。
これらのラテンスペースは、ちょっと作り上げたパラメータを持つスペースを作成するためのファンシーな専門用語です。異なる可能性のあるプログラミングの魔法は、14行目から18行目までのわずか5行で行われます。キーワードの1つは「autodiff」で、「transactions」は興味のあるテーブル、観測のテーブルであることを示しています。このテーブルを行ごとに処理して学習プロセスを行います。このブロックでは、一連のパラメータを宣言しています。パラメータとは、まだ値がわからない数値など、学びたいものです。これらの値はランダムに初期化されます。
「X」、「X*」、「Y」を導入します。具体的には「X*」が何をしているのかには触れませんが、質問で説明します。損失関数としての式を返しており、それが合計です。協調フィルタリングや行列分解のアイデアは、バイパーティットグラフ内のすべてのエッジに適合するラテンスペースを学習したいというものです。少し技術的かもしれませんが、私たちがやっていることは、供給チェーンの観点からは非常にシンプルです。製品とクライアントの関連性を学習しています。
おそらく非常に不透明に思えるかもしれませんが、私と一緒にいてください。もっと考えられた紹介をする講義があります。全体のことは5行で完了しますが、それは完全に注目に値するものです。5行と言っても、「5行しかないけど、実際には巨大な複雑さのサードパーティライブラリを呼び出して、すべての知識を埋め込んでいる」と言っているわけではありません。いいえ、ここでは、この例では、「autodiff」と「params」以外の機械学習の魔法はまったくありません。「autodiff」は、異なる可能性のあるプログラミングが行われるブロックを定義するために使用され、ところで、これはプログラムを注入できるブロックです。次に、「params」を使用して問題を宣言します。以上です。ですから、不透明なマジックは何も起こっていません。背後に100万行のライブラリがあって、すべての作業を代行しているわけではありません。知る必要があるすべてが文字通りこの画面にあります。それがプログラミングパラダイムとライブラリの違いです。プログラミングパラダイムは、わずか数行のコードでカニバリゼーション分析を行うなど、非常に洗練された機能にアクセスできるようにし、複雑さを包む大規模なサードパーティライブラリに頼らない方法を提供します。それは問題を超越し、非常に簡単にするため、数行で解決できる非常に複雑なものを持つことができます。
では、異なる可能性のあるプログラミングがどのように機能するかについて少し説明します。2つの洞察があります。1つは自動微分です。エンジニアリングのトレーニングの恩恵を受けた方々には、2つの方法で導関数を計算する方法があります。1つはシンボリック微分です。たとえば、xの2乗の場合、xで微分すると2xになります。これはシンボリック微分です。次に、数値微分があります。たとえば、微分したい関数f(x)がある場合、f’(x) ≈ (f(x + ε) - f(x))/εとなります。これが数値微分です。どちらもここでやろうとしていることには適していません。シンボリック微分は複雑さの問題があり、微分が元のプログラムよりもはるかに複雑なプログラムになる可能性があります。数値微分は数値的に不安定であり、数値の安定性に関する多くの問題が発生します。
自動微分は、70年代に発表され、最近の10年間で世界中で再発見された素晴らしいアイデアです。それは、任意のコンピュータプログラムの導関数を計算できるというアイデアです。これは驚くべきことです。さらに驚くべきことに、導関数としてのプログラムは、元のプログラムと同じ計算量を持っています。これは驚くべきことです。異なる可能性のあるプログラミングは、自動微分と学習したいパラメータの組み合わせです。
学ぶにはどうすればいいのでしょうか？導関数を持っているということは、勾配を上に伝えることができるということです。そして、確率的勾配降下法を用いて、パラメータの値を少しずつ調整することができます。これらのパラメータを調整することで、確率的勾配降下法の多くの反復を通じて、意味のあるパラメータに収束し、学習または最適化したい目標を達成することができます。
自動微分プログラミングは、私が説明しているような学習問題に使用することができます。私の顧客と製品の関係性を学びたい場合などです。また、制約の下での最適化など、数値最適化問題にも使用することができます。このパラダイムは非常にスケーラブルです。Envisionでは、この側面が一級市民として扱われています。ところで、Envisionの構文にはまだいくつかの進行中のものがありますので、まだそれらを完全に期待しないでください。私たちはまだいくつかの側面を洗練しています。しかし、本質はそこにあります。まだ進化中のいくつかの細かい点については議論しません。
さて、次に、セットアップの本番準備に関連する別の問題に移りましょう。通常、サプライチェーンの最適化では、ハイゼンバグに直面します。ハイゼンバグとは何でしょうか？最適化が行われ、ゴミのような結果が生じるイライラするようなバグのことです。たとえば、夜間に在庫の再補充のためのバッチ計算を行い、翌朝になって、いくつかの結果が無意味であり、高価なミスを引き起こしていることがわかりました。この問題が再発しないようにしたいので、プロセスを再実行します。しかし、プロセスを再実行しても、問題は解消されます。問題を再現することができず、ハイゼンバグは現れません。
これは奇妙なエッジケースのように聞こえるかもしれませんが、Lokadの最初の数年間で、私たちはこれらの問題に何度も直面しました。特にデータサイエンスのようなサプライチェーンの取り組みでは、未解決のハイゼンバグのために失敗することが多かったです。本番でバグが発生し、問題をローカルで再現しようとしましたが、できませんでした。そのため、問題は修正されませんでした。数ヶ月間のパニックモードの後、プロジェクト全体は通常静かに終了し、人々はExcelスプレッドシートを再び使用するように戻りました。
ロジックの完全な再現性を実現するには、コードとデータのバージョン管理が必要です。ソフトウェアエンジニアやデータサイエンティストの多くの方々は、コードのバージョン管理のアイデアについてはお馴染みかもしれません。しかし、プログラムが実行される際に使用されているコードとデータのバージョンも把握する必要があります。翌日に問題を再現できないかもしれません。なぜなら、データが新しいトランザクションやその他の要因によって変更されているため、最初にバグを引き起こす条件が存在しないからです。
プログラミング環境が、ロジックとデータを本番時点で完全に再現できるようにする必要があります。これにはすべてのものの完全なバージョン管理が必要です。プログラミング言語とプログラミングスタックは、これを可能にするために協力する必要があります。プログラミングパラダイムがスタックの一級市民である必要はありませんが、その場合、サプライチェーンの科学者は行うすべてのこととプログラムの方法に非常に注意を払わなければなりません。そうでなければ、自分自身の結果を再現することができません。これにより、サプライチェーンの科学者は既にサプライチェーン自体から大きな圧力を受けているのに、偶発的な複雑さに対処する必要があります。Lokadでは、これを「タイムマシン」と呼んでいます。過去のあらゆる時点ですべてを再現できる場所です。
注意してください。ただ昨夜の出来事を再現するだけではありません。時には、事実が明らかになってから長い時間が経過してからミスを発見することがあります。たとえば、3ヶ月のリードタイムを持つサプライヤーに発注を行い、3ヶ月後にその注文が無意味であることがわかるかもしれません。問題が発生した時点でこの間違った発注を生成した時点に3ヶ月前に戻る必要があります。最後の数時間の作業だけをバージョン管理するのではなく、過去1年間の実行の完全な履歴についてバージョン管理する必要があります。
もう1つの懸念事項は、ランサムウェアとサプライチェーンへのサイバー攻撃の増加です。これらの攻撃は非常に混乱を引き起こし、非常に高額な費用がかかる場合があります。ソフトウェア駆動型のソリューションを実装する際には、企業とサプライチェーンをサイバー攻撃やリスクに対してより脆弱にする可能性があるかどうかを考慮する必要があります。この観点から見ると、ExcelとPythonは理想的ではありません。これらのコンポーネントはプログラム可能であり、多くのセキュリティの脆弱性を抱える可能性があります。
サプライチェーンの問題に取り組むデータサイエンティストやサプライチェーンの科学者のチームがいる場合、ソフトウェア業界で一般的な慎重で反復的なピアレビュープロセスを負担することはできません。関税が一晩で変更されたり、倉庫が浸水したりすると、迅速な対応が必要です。コードの仕様、レビューなどを数週間かけて作成することはできません。問題は、デフォルトで会社に損害をもたらす可能性のある人々にプログラミングの能力を与えていることです。意図的な不正行為を行う悪意のある従業員がいる場合はさらに悪化する可能性がありますが、それを置いておいても、ITシステムの内部の一部を誤って公開する可能性があります。供給チェーンの最適化システムは、会社全体の大量のデータにアクセスできるという点だけでなく、資産だけでなく負債でもあることを忘れないでください。
欲しいのは、安全なプログラミングを促進するプログラミングパラダイムです。供給チェーンの最適化のためにシステムコールを行うことができるプログラミング言語をなぜ持つ必要があるのでしょうか？PythonやExcelはシステムコールを行うことができますが、そもそもそのような機能を持つプログラム可能なシステムが必要なのでしょうか？それは足を撃つために銃を買うようなものです。
供給チェーンの最適化には必要のないクラスや機能が存在しないものが欲しいのです。これらの機能が存在すると、大きな負債になります。安全なプログラミングをデザインに組み込んだツールがないままプログラム可能な機能を導入すると、サイバー攻撃やランサムウェアのリスクが増加し、状況は悪化します。
もちろん、サイバーセキュリティチームの規模を倍増させることで補償することも可能ですが、非常に高額な費用がかかり、緊急のサプライチェーンの状況に直面している場合には理想的ではありません。通常のプロセス、レビュー、承認に時間をかけずに迅速かつ安全に行動する必要があります。また、ヌル参照例外、メモリ不足エラー、オフバイワンループ、副作用などのような日常的な問題を排除する安全なプログラミングも必要です。
結論として、ツールは重要です。ここには「剣を持って銃撃戦に臨むな」という格言があります。サプライチェーンのニーズを満たすために、単に大学で学んだものだけでなく、適切なツールとプログラミングパラダイムが必要です。劣悪なツールで一部の結果を得ることはできるかもしれませんが、素晴らしいミュージシャンはスプーンだけで音楽を作ることができますが、適切な楽器があればもっと素晴らしいことができます。
さて、質問に進みましょう。20秒ほどの遅延があるため、お見せしているビデオと質問を読む私との間にはいくらかの遅延がありますのでご了承ください。
質問: 運用研究の動的計画法についてはどうですか？
動的計画法は、その名前にもかかわらず、プログラミングパラダイムではありません。それはむしろアルゴリズムの技術です。アルゴリズムのタスクを実行したり、特定の問題を解決するためには、同じサブ操作を非常に頻繁に繰り返す必要があります。動的計画法は、先に述べたスペースと時間のトレードオフの特定のケースであり、計算面で時間を節約するために少し多くのメモリを投資するものです。これは60年代と70年代にさかのぼる最初のアルゴリズムの技術の一つです。それは良いものですが、名前は少し不運です。それには本当に動的な要素はなく、プログラミングについてでもありません。それはむしろアルゴリズムの概念についてです。ですので、名前にもかかわらず、私にとってはプログラミングパラダイムとは言えません。それは特定のアルゴリズムの技術です。
質問: ヨハネスさん、優れたサプライチェーンエンジニアが持つべき参考書をいくつか教えていただけますか？残念ながら、私はこの分野に新参者で、現在の焦点はデータサイエンスとシステムエンジニアリングです。
私は既存の文献について非常に混合した意見を持っています。最初の講義で、私はサプライチェーンに関する学術研究の頂点と考える2冊の本を紹介しました。もし2冊の本を読みたいのであれば、それらの本を読んでください。しかし、私はこれまで読んだ本について常に問題を抱えています。基本的には、理想化されたサプライチェーンのためのおもちゃのような数値レシピのコレクションを提供する人々がいるのですが、私はこれらの本がサプライチェーンに正しいアプローチをしておらず、それが困難な問題であることを完全に見逃していると考えています。方程式、アルゴリズム、定理、証明などが含まれる非常に技術的な文献がありますが、それは本質を見失っていると思います。
そして、もう一つのスタイルのサプライチェーン管理の本は、よりコンサルタントスタイルです。これらの本は、2ページごとにスポーツの類似性を使っているため、簡単に認識することができます。これらの本には、SWOT（Strengths, Weaknesses, Opportunities, Threats）ダイアグラムの2x2バリエーションなど、単純化されたダイアグラムがありますが、私はこれらを低品質な論理の方法だと考えています。これらの本の問題は、サプライチェーンが困難な取り組みであることを理解するのには優れているということです。彼らは、さまざまな奇妙なことが起こる人々によって行われるゲームであることをよりよく理解しています。私はそれに対して彼らにクレジットを与えます。ただし、コンサルタントや経営学の教授が書いたこれらの本の問題は、実行可能性があまり高くないということです。メッセージは「より優れたリーダーになる」「より賢くなる」「より多くのエネルギーを持つ」ということになりますが、これは私にとっては実行可能ではありません。ソフトウェアのように非常に価値のあるものに変えることができる要素を提供してくれません。
ですので、最初の講義に戻ります。もし読みたいのであれば、2冊の本を読んでくださいが、それが有意義な時間になるかどうかはわかりません。人々が書いたものを知っていることは良いことです。コンサルタント側の文献では、私のお気に入りはおそらくカタナの仕事ですが、最初の講義ではリストアップしていませんでした。すべてが悪いわけではありません。コンサルタントっぽい人たちでも才能がある人もいます。カタナの仕事をチェックしてみてください。彼は動的なサプライチェーンに関する本を持っています。参考文献にその本をリストアップします。
質問: カニバリゼーションやアソートメントの意思決定において、問題が簡単に並列化できない場合、並列化をどのように使用しますか？
なぜそれが簡単に並列化できないのでしょうか？確率的勾配降下法は非常に簡単に並列化できます。ランダムな順序で確率的勾配ステップを実行し、同時に複数のステップを行うことができます。ですので、確率的勾配降下法によって駆動されるものは、かなり簡単に並列化できると思います。
カニバリゼーションに取り組む際、より困難なのは、どのような順序で行うかということです。この製品を最初に配置し、予測を行い、別の製品を取り入れると、景色が変わります。答えは、全体の景色に対処する方法を持つことです。最初にこの製品を導入して予測を行い、別の製品を導入して予測をやり直し、最初の予測を変更するということはしません。一度に、同時に、すべてのことを行います。より多くのプログラミングパラダイムが必要です。私が今日紹介したプログラミングパラダイムは、そのために非常に役立ちます。
アソートメントの意思決定に関しては、このような問題は並列化には大きな困難を伴いません。同じことが、世界中の小売ネットワークを持ち、すべての店舗のアソートメントを最適化したい場合にも適用されます。すべての店舗に対して並列に計算を行うことができます。順番に行うのではなく、1つの店舗のアソートメントを最適化してから次の店舗に移るという方法は間違っています。それを並列に最適化し、すべての情報を伝播させ、繰り返すことができます。さまざまなテクニックがあり、ツールを使うことでそれをはるかに簡単に行うことができます。
質問: グラフデータベースのアプローチを使用していますか？
いいえ、技術的な意味でのグラフデータベースではありません。市場には非常に興味深いグラフデータベースがたくさんあります。Lokadで内部的に使用しているのは、従来の要素を完全に排除するための統合された、モノリシックなコンパイラスタックを通じた完全な垂直統合です。これにより、計算パフォーマンスに関して非常に優れたパフォーマンスを実現しています。私たちは素晴らしいスマートなコーダーではなく、従来存在するほとんどのレイヤーを完全に排除したためです。Lokadは文字通りデータベースを一切使用していません。すべてを処理するコンパイラがあり、永続性のためのデータ構造の組織までを処理します。少し奇妙ですが、この方法で行う方がはるかに効率的であり、クラウド上の複数のマシンにスクリプトをコンパイルするという事実により、よりうまく動作します。ハードウェアの観点では、ターゲットプラットフォームは1つのマシンではなく、複数のマシンです。
質問: Power BIについて、Pythonコードや勾配降下法、貪欲法などの関連アルゴリズムも実行していますか？
ビジネスインテリジェンスに関連するもの、Power BIもその1つですが、私が供給チェーンには不適切だと考えるパラダイムを持っています。すべての問題をハイパーキューブとして見ることで、次元をスライスして分析するだけです。本質的には、非常に制約のある表現能力の問題があります。Power BIをPythonと組み合わせて使用する場合、ハイパーキューブに関連する表現力が非常に乏しいため、Pythonが必要です。しかし、前の質問で述べたように、レイヤーの呪いというものがあります。現代のエンタープライズソフトウェアの問題は、レイヤーが多すぎることです。追加するレイヤーごとに非効率性とバグが導入されます。Power BIとPythonを使用すると、レイヤーがあまりにも多くなります。すでにPower BIの前に他のシステムが存在しているため、Power BIの上にPower BIがあります。そして、Power BIの上にはPythonがあります。しかし、Pythonは単独で動作しているのでしょうか？いいえ、おそらくPandasやNumPyなどのPythonライブラリを使用することになるでしょう。したがって、Pythonにはレイヤーが積み重なることになり、数十のレイヤーが存在します。これらのレイヤーのいずれかにバグがある可能性がありますので、状況はかなり悪夢のようになるでしょう。
私は、スタックの数が膨大になるような解決策には信じていません。C++では、さらに一段階の間接参照を追加することで、間接参照の数が多すぎるという問題を含め、どんな問題でも解決できるというジョークがあります。明らかに、これは少し無意味な主張ですが、私は、適切なコア設計を持たない製品を持っている人々が、問題に正面から取り組む代わりに、基盤が揺らいでいる間に物事を積み重ねるアプローチには強く反対しています。これは正しい方法ではありませんし、生産性が低下し、解決できないバグとの戦いが続き、保守性に関しては悪夢のレシピになるでしょう。
質問: 協調フィルタリングの分析結果を、バックパックなどの各製品の需要予測アルゴリズムにどのように組み込めばよいですか？
申し訳ありませんが、このトピックについては次の講義で取り上げます。短い答えは、それを既存の予測アルゴリズムに組み込むのではなく、よりネイティブに統合されたものを持つことです。それを行って予測を行う古い方法に戻るのではなく、それを活用するために根本的に異なる方法を取るのです。しかし、それについては後の講義で議論します。今日はそれは多すぎるでしょう。
この講義は以上です。ご参加いただいた皆様、ありがとうございました。次の講義は1月6日（水曜日）に同じ時間、同じ曜日に行われます。私はクリスマス休暇を取る予定ですので、皆様には楽しいクリスマスと幸せな新年をお祈りします。来年も講義シリーズを続けます。どうもありがとうございました。
