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

Joannes Vermorel

Lokadのsupply chain practiceは、月次または四半期の計算を行っていても、すべてのdata pipelines（予測を含む）を少なくとも1日1回更新することです。多くの実務者にとって、この実践は直感に反しているように見えるかもしれません。なぜ四半期ごとの予測を四半期に1回以上更新する必要があるのでしょうか？数値の不安定性はどうなのでしょうか？関連する摩擦はどうでしょうか？これは、特にS&OPプロセスを導入している企業の、確立されたサプライチェーンの慣行に反します。しかし、10年以上の経験から、「すべてをリフレッシュする」という実践に従わないことが、絶え間ない生産問題の原因になると分かりました。根本的には、この問題は、サプライチェーンのpredictive optimizationを担うソフトウェアの_バージョン管理されたステートレスな設計_によって、徹底的に対処されるべきです。この点は以下でさらに詳しく再検討されますが、まずは問題そのものを詳しく見てみましょう。

enterprise softwareの世界では、問題やグリッチ、バグ、イシューが絶えず発生します。これは特に、applicative landscapeが、ERP、EDI、MRP、WMS、OMS、ecommerceなど、数十年にわたる活動の中で組み合わされた雑多なソフトウェアの集合体であるサプライチェーンにおいて顕著です。すべてのアプリは、他の多くのアプリと相互作用するため、潜在的な問題の原因となり得ます¹。これらのアプリに加えられる変更は、アプリ自体だけでなく他の部分を壊してしまう可能性があります。企業によってアプリケーションの管理体制はさまざまですが、従業員が1000人を超える企業では、どんなに運営が優れていても、1日あたり1回以上のソフトウェア起因のサプライチェーンの「グリッチ」が発生するのです。

このように、大企業では解決すべきソフトウェアの問題が絶え間なく発生します。これらの問題の解決責任は、IT部門、サードパーティのベンダー、運用チーム、サプライヤーなど、さまざまな主体に委ねられる場合があります。しかし、いずれかの問題が「一応」修正されたとしても、実際に問題が解決されたことを確認するには5～10ラウンド²が必要です。実際、ほとんどの問題は_エッジケース_であり、必ずしも常に現れるわけではありません。そのため、ある問題が何らかの修正によって一時的に解決されたように見えても、必ずしも完全には解決されていないのです。サプライチェーンは、多くの相互依存する部品からなる_複雑なシステム_であり、その中には企業の完全な管理下にないもの（例：サプライヤーとのEDI）も含まれます。人々が_決定的な修正_をうまく提供できないのは、怠慢や無能のせいではなく、取り除くことのできない周囲の複雑性が原因なのです。

その結果、生産事故後にデータパイプラインが毎日実行される場合、安定状態に戻るまでに5～10日かかります。もしデータパイプラインが月次で実行されると、同じ解決プロセスには_5～10ヶ月_が必要となります。重要なのは実行回数であり、経過時間ではありません。エッジケースが確実に対処されたことを確認するには、複数回の実行が必要です。逸話的な例として、Lokadでは、タイムチェンジに関連するジョブスケジューリングのバグが、問題を引き起こす条件が非常に稀であった（タイムゾーンごとに年2回）ため、修正に2年を要しました。しかし、タイムチェンジのような一部の事象は本質的に発生頻度が低い一方で、ほとんどの問題は「ラウンド」の頻度を上げるだけで意図的に再現可能となるのです。

エンドツーエンドのデータパイプラインを常に再実行することだけが、問題が適切な期間内に解決されることを保証する唯一の方法です。実行頻度が低いと、システムの既定状態が必然的に_壊れている_状態になってしまいます。例えば四半期ごとのデータパイプラインを運用する企業は、四半期に1度だけパイプラインを再稼働させるための大規模な官僚組織に頼ることになりがちです。さらに悪いことに、その官僚組織は次の四半期の「リフレッシュ」を確保するために、四半期の大部分を費やすことになります。逆に、企業ウェブサイトのページサービスのようなリアルタイムパイプラインは、ほとんど人手を必要としません。

Lokadでは、10年以上前に単なる必要性から_毎日のリフレッシュ_（またはそれ以上）を採用しました。それ以来、サプライチェーンの観点から適切なサービス品質を実現する他の方法は見つかっていません。おそらく他に方法はありません。予測分析は複雑であり、そのため、あらゆる種類の「バグ」に悩まされがちです。毎日のリフレッシュは、問題が永遠に宙ぶらりんになるのではなく、迅速に対処されることを保証します³。この点において、私たちの知見は決して独創的なものではありません。Netflixは、同様の考え方に基づいてカオスエンジニアリング全体の分野を切り開きました。堅牢なシステムを構築するには、ストレスを与える必要があり、ストレスがなければ堅牢性はエンジニアリングの考え方に根付かないのです。GAFAMをはじめとする多くの大手ソフトウェア企業は、さらに厳格な形のこのアプローチを採用しています。

さらに、更新頻度が低いデータパイプラインは、サプライチェーンの観点だけでなく、一連の悪しき慣行や劣った技術の問題も浮き彫りにします。

予測が更新される頻度が低いと、手動で調整したくなる誘惑が非常に強くなります。実際、更新頻度が低いために予測は設計上停滞しがちです。つまり、単に昨日のデータを見るだけで、demand plannerは3週間前にシステムが作成した予測を改善できるのです。しかし、この需要計画担当者による作業は、企業に持続的な付加価値をもたらすものではなく、積み上げ的な効果もありません。もし予測を生成するnumerical recipesが不十分で手動上書きが必要なほどであれば、これらの数値レシピは修正されなければなりません。ソフトウェアベンダーが修正を提供できない場合、企業はより優れたベンダーを必要とするのです。

頻繁な予測更新は、基礎となる統計モデルの数値的不安定性を悪化させます。つまり、同じ予測を2回実行すると、異なる結果が出るということです。これは_良いこと_です⁴。不安定な数値モデルは、ラチェット効果によりサプライチェーンに悪影響を及ぼします。一度製造指示や購買注文が出されると、企業はその結果に縛られてしまいます。注文が出される以上、数値的不安定性が理由であってはなりません。企業がサプライチェーンの実践から不安定な数値レシピを早期に排除すればするほど良いのです。更新頻度を下げることで根本的な問題を隠蔽しようとするのは無意味です。なぜなら、企業がその確認をやめたところで、数値的不安定性は消えないからです。もし数値レシピが、日々強固な一貫性⁵を保てないほど不十分であれば、より良い数値レシピが必要となります。再び、ソフトウェアベンダーが問題の真っただ中にあって、根本的な修正ができない場合、企業はより優れたベンダーを必要とするのです。

すべてのデータパイプラインを毎日更新することは、計算資源の面では贅沢に見えるかもしれません。しかし、現代の計算ハードウェアと適切に設計されたソフトウェアを考慮すれば、確率的予測⁶のような洗練されたレシピを使う場合でも、そのコストは小さいものです。さらに、サプライチェーンは、即時の大規模な修正を必要とする例外的な状況に日常的に直面します。もし企業が必要な理由で60分以内にすべてのサプライチェーン数値を更新できないなら、緊急時の対応が度々行われず、現場に混乱をもたらすことは避けられません。前述の5～10ラウンドルールは依然として有効であり、修正が見つかった後も、この緊急修正が本当に機能していると確信するには、複数回の実行（場合によっては設定を変えた実行）が必要となるのです。したがって、データパイプラインの実行が「自由に」行えないほど高額であれば、生産現場が_テスト環境_として利用され、混沌が生じることになります。

生産性の観点から、毎日のリフレッシュは、誤ったセッティングに対する寛容さを排除し、ゴミのような結果を生み出し続ける状況を防ぎます。これは再び_良いこと_なのです。ゴミを生成し続ける数値レシピに対して寛容である理由はありません。需要計画は、数値解析に逆らう芸術的な創作物ではありません。機能不全の数値レシピは_ソフトウェアバグ_として扱い、適切に修正されるべきです。しかし、根本的な修正を行うには、_アドホック_な手動上書きに頼る以上の多くの検討が必要となるのです。多くの企業が、なぜサプライチェーンチームがスプレッドシートに戻り続けるのか不思議に思っています。実際、システムの一部としてすでに実装されるべき数値の修正が、基幹システム上では反復作業が困難なため、迅速に繰り返し作業できるのはスプレッドシートだけなのです。

しかし、毎日（またはそれ以上）のリフレッシュは、問題の運用上の側面に過ぎません。ソフトウェア設計の観点からは、このアプローチは最初の重要な要素である_ステートレス性_によって補完されなければなりません。データパイプラインは、事前に計算されたデータを使用してはならず、毎回、生のトランザクションデータから新たに開始すべきです。実際、あらゆるバグやグリッチは、事前計算されたデータを_破損_させ、企業を無期限に引きずる可能性があります。論理は修正されても、誤ったデータは残るのです。解決策は明快です。データパイプラインは_状態を一切持ってはならない_、すなわち、いかなる種類の事前計算データも保持すべきではありません。ゼロから開始することで、すべての修正が即座に最大限に活用されるのです。

次に、versioning、すなわちもう一つのソフトウェア設計原則であり重要な要素である_データ_のバージョン管理が、システムの_ステートレス性_を補完します。実際、データパイプライン自体に状態がなければ、_バージョン管理_されたソースコードとして存在するパイプラインのロジックと入力データを組み合わせるだけで、パイプライン実行中に発生した問題を正確に再現することができます。言い換えれば、これにより問題が_再現可能_となります。しかし、これを実現するには、データパイプラインの実行時のデータの正確なコピーを保持する必要があります。つまり、データはコードと並んでバージョン管理されるべきです。データのバージョン管理により、修正は当初問題が発生したのと全く同じ条件下でテストすることが保証されます。

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