毎日すべてをリフレッシュする

Joannes Vermorel

Lokadのサプライチェーンの実践は、月次または四半期の計算を行う場合でも、少なくとも1日に1回はすべてのデータパイプライン（予測を含む）をリフレッシュすることです。多くの実践者にとって、この実践は直感に反するかもしれません。四半期ごとに予測を何度も更新する理由は何でしょうか？数値の不安定性はどうでしょうか？関連する摩擦はどうでしょうか？これは、特にS&OPプロセスを導入している企業の場合、ほとんどの確立されたサプライチェーンの実践に反するものです。しかし、10年の経験から、この「すべてのものをリフレッシュする」実践に従わないことは、生産上の問題の絶え間ない流れのレシピになることがわかりました。根本的には、この問題は、サプライチェーンの予測最適化を担当するソフトウェアの_versioned stateless design_を通じて、詳細に取り組む必要があります。このポイントは後で詳しく再検討されますが、まずは問題自体をより詳しく見てみましょう。

企業ソフトウェアの世界では、問題/グリッチ/バグ/課題が頻繁に発生します。これは特にサプライチェーンの場合に当てはまります。サプライチェーンのアプリケーションの風景は、活動の数十年にわたって組み合わされたソフトウェアの断片の集まりです（ERP、EDI、MRP、WMS、OMS、eコマースなど）。すべてのアプリは、他の多くのアプリと相互作用することになるため、問題の可能性があります¹。これらのアプリのいずれかに変更が加えられると、アプリ自体だけでなく他の場所でも何かが壊れる可能性があります。すべての企業がアプリケーションの風景を管理する際に平等ではありませんが、1000人以上の従業員を超えると、最も運営が良く管理されている企業でも、1日に1つ以上のソフトウェアによるサプライチェーンの「グリッチ」が発生します。

したがって、大規模な企業は解決すべきソフトウェアの問題の絶え間ない流れに直面しています。問題の解決の責任は異なります。責任はIT部門、サードパーティのベンダー、運用チーム、サプライヤーなどにあるかもしれません。しかし、これらの問題のいずれかが「おそらく」修正されると、問題が本当に修正されたことを確認するには5〜10ラウンド²が必要です。実際、ほとんどの問題はエッジケースであり、各時点で発生するかどうかはわかりません。したがって、問題が修正されたように見えるかもしれませんが、ある種の修正を適用した後に問題が解消したため、まだそのような状況ではないかもしれません。サプライチェーンは、会社自体の完全な制御下にない要素を含む_複雑なシステム_です。人々は、不可避な環境の複雑さのために、_決定的な修正_を提供することに失敗することがよくあります。

データパイプラインがプロダクションインシデントの後に毎日実行される場合、安定性を回復するまでに5〜10日かかります。データパイプラインが月に1回実行される場合、同じ解決プロセスには「5〜10ヶ月」かかります。壁時計の時間ではなく、ラウンドの数が重要です。エッジケースが対処されたことを確認するには、複数のラウンドが必要です。例えば、Lokadでは、タイムゾーンごとに年に2回しか発生しない時間変更に関連するジョブスケジューリングのバグがあり、修正に2年かかりました。しかし、時間変更のような特定の問題は本質的には頻繁に発生しないものの、ほとんどの問題は「ラウンド」の頻度を上げるだけで「自由に」再現できます。

エンドツーエンドのデータパイプラインを常に再試行することは、問題が合理的な時間枠内で修正される唯一の方法です。頻繁な実行は、システムのデフォルト状態が「壊れた」状態になることを必然的にもたらします。四半期ごとのデータパイプラインを運用する企業は、四半期ごとにパイプラインを復活させるためだけに存在する大規模な官僚組織になることが避けられません。さらに悪いことに、その全体は通常非機能的であり、官僚組織は次の四半期の「リフレッシュ」を確保するために四半期の大部分を費やすことになります。一方、企業のウェブサイトのページを提供するようなリアルタイムのパイプラインは、ほとんど誰もが動作させる必要がありません。

Lokadでは、10年以上前に単なる必要性から「毎日のリフレッシュ」（またはそれ以上）を選択しました。その時以来、サプライチェーンの観点からまともなサービス品質を実現する他の方法はまだ見つかっていません。おそらくありません。予測分析は複雑であり、そのためあらゆる種類の「バグ」に対して脆弱です。毎日のリフレッシュは、問題が永遠にリンボスに残るのではなく、迅速に対処されることを保証します³。この点で、私たちの調査結果は決してオリジナルではありません。Netflixは、同様の考え方に基づいてカオスエンジニアリングの分野全体を先駆けました。堅牢なシステムを設計するためには、ストレスを加える必要があります。ストレスがなければ、堅牢性はエンジニアリングのマインドセットに組み込まれることはありません。真剣なソフトウェア企業（特にGAFAMなど）のほとんどは、さらに厳格なアプローチを採用しています。

さらに、頻繁でないデータパイプラインのリフレッシュは、特定のサプライチェーンの観点からだけでなく、一連の悪いプラクティスと悪いテクノロジーを強調します。

予測が頻繁にリフレッシュされない場合、手動で調整することが非常に誘惑されます。実際、予測は設計上ほとんどの時間停滞していますが、それは頻繁なリフレッシュのためです。したがって、昨日のデータを見るだけで、需要プランナーは3週間前にシステムによって生成された予測を改善することができます。しかし、需要プランナーのこの作業は、会社に持続的な付加価値をもたらしません。それは付加価値を生み出しません。予測を生成する数値レシピが手動のオーバーライドが必要なほど悪い場合、それらの数値レシピを修正する必要があります。ソフトウェアベンダーが修正を提供できない場合、会社はより優れたベンダーが必要です。

予測の頻繁なリフレッシュは、基礎となる統計モデルの数値的な不安定性を悪化させます。つまり、予測を2回実行すると、2つの異なる結果が得られます。これは_良いこと_です⁴。不安定な数値モデルは、ラチェット効果により、サプライチェーンにとって有害です。一度生産オーダーや購買オーダーが通過すると、会社はそのオーダーの結果に取り残されます。オーダーが通過する場合、数値的な不安定性の問題以上の理由であるべきです。会社がサプライチェーンの実践から不安定な数値レシピを排除するほど早く、良いです。予測のリフレッシュ頻度を減らすことで、根本的な問題をごまかすことはナンセンスです。数値的な不安定性は、会社がそれを見るのをやめることによって消えるわけではありません。数値レシピが1日から翌日までの間に強力な一貫性⁵を維持できないほど悪い場合、より良い数値レシピが必要です。同様に、ソフトウェアベンダーが問題の中心にいて深い修正を提供できない場合、会社もより優れたベンダーが必要です。

全てのデータパイプラインを毎日リフレッシュすることは、コンピューティングリソースの観点からは贅沢に思えるかもしれません。しかし、現代のコンピューティングハードウェアと適切に設計されたソフトウェアを考慮すると、このコストは小さいです。例えば、確率的予測⁶などの洗練されたレシピを考慮しても、このコストは小さいです。さらに、サプライチェーンは定期的に即時の大規模な修正が必要な特殊な状況に直面します。もし会社が60分未満で全てのサプライチェーンの数字をリフレッシュできない場合、緊急事態は時折対処されないままであり、現場に混乱をもたらします。以前に議論された5〜10回のルールは依然として適用されます。修正策が見つかったら、この緊急修正が機能していることを確信するために、複数の実行（可能ならば異なる設定で）が必要です。したがって、データパイプラインが「自由に実行できる」ほどコストが高い場合、生産は「テストの場」として使用され、混乱が生じます。

title: “生産性の観点から、毎日のリフレッシュは、ゴミの結果を生成し続ける悪いセットアップに対する許容性を排除します。再度、それは「良いこと」です。ゴミを生成し続ける数値レシピに対して許容的である理由はありません。需要計画は数値分析に逆らうような芸術的な創造物ではありません。機能しない数値レシピは「ソフトウェアのバグ」として扱われ、それに応じて修正されるべきです。ただし、深い修正を頻繁に提供するには、_アドホック_な手動オーバーライドにデフォルトで戻るよりもはるかに多くの考えが必要です。多くの企業は、なぜサプライチェーンチームがスプレッドシートに戻ってくるのか疑問に思っています。実際、スプレッドシートは、数値の修正が既にシステムの一部であるべきであるにもかかわらず、実装される唯一の場所です。なぜなら、スプレッドシート上での繰り返しは問題ではないからです（基礎となるエンタープライズシステム上での繰り返しとは異なります）。

ただし、毎日（またはそれ以上）のリフレッシュは、問題の運用面のみです。ソフトウェア設計の観点では、このアプローチは最初の重要な要素である「状態のなさ」で補完する必要があります。データパイプラインは、事前計算されたデータを使用せず、常に生のトランザクションデータから新たに開始するべきです。実際、すべてのバグやグリッチは、事前計算されたデータを「破損」させる可能性があり、会社を無期限に引き止める可能性があります。ロジックは修正されるかもしれませんが、誤ったデータは残ります。解決策は簡単です。データパイプラインには「状態」がないはずです。つまり、どんな種類の事前計算データもありません。新たに開始することで、修正が可能な限り最大限に活用されることが保証されます。

一方、もう1つのソフトウェア設計の原則である「バージョニング」は、システムの「状態のなさ」を補完するための第2の興味深い要素であり、具体的には「データ」のバージョニングです。実際、データパイプライン自体に状態がない場合、パイプラインのロジック（バージョン管理されたソースコードとして存在する）と入力データの単純な組み合わせだけで、パイプラインの実行中に遭遇した問題を正確に再現するのに十分です。言い換えれば、問題を「再現可能」にします。ただし、これを実現するには、データパイプラインの実行時にデータが存在した状態の正確なコピーを保持する必要があります。言い換えれば、データはコードと一緒にバージョン管理されるべきです。データのバージョニングにより、修正を最初に遭遇した条件とまったく同じ状況でテストできるようになります。

Lokadは、これらの原則を基に設計されています。私たちはすべてのものを毎日のリフレッシュでエンドツーエンドに推進しています。私たちのデータパイプラインは状態を持たず、ロジックとデータの両方がバージョン管理されています。あなたの会社はどうですか？