ホリミゼーション：なぜ最適化だけでは十分ではないのか
私のキャリアのほとんどにおいて、「最適化」が答えだと言われてきました。もしも正しいモデルを定式化し、十分なデータを供給し、強力なソルバーに委ねることができれば、機械は落ち着いて最善の判断を導き出すだろうと信じられていました。
しかし実際のサプライチェーンでは、この約束はめったに実現しません。企業は高度なソフトウェアを展開し、無数のパラメータを調整しても、品切れ、過剰在庫、そしてシステムを信頼しなくなったプランナーたちによる火消しに追われるのです。ブラックボックス内部の数学は美しいかもしれませんが、倉庫現場での判断は必ずしもそうではありません。
Introduction to Supply Chain、特に意思決定や数値レシピに関する章において、私は本当のボトルネックはソルバーの不足ではなく、最適化そのものを取り巻く適切な枠組みの欠如にあると主張してきました。このエッセイでは、その考えをさらに一歩進め、名前を与えたいと思います：ホリミゼーション、そして動詞としてのホリミゼート、これは「ホリスティックな最適化」を縮めたものです.
最適化が誤った問いに基づいている場合
古典的最適化は、その最も単純な形態において、非常に魅力的な姿勢から始まります:
「最大化または最小化したいものを教えてください。制約を列挙すれば、最善の判断を見つけます。」
ホワイトボード上ではこれは全く合理的に聞こえます。しかし、サプライチェーンにおいては、実際に重要なほとんどすべての要素を隠してしまうのです。
一体何を「最大化」しているのでしょうか？今月の利益？一年間の利益？数年にわたる成長？測定が難しい顧客満足度？混乱に対する耐性？あるいはそれらすべての混合でしょうか？
制約とは一体何でしょうか？容量やリードタイムといった形式的なものだけでしょうか、それとも「この倉庫チームは現実的に1日に5,000個以上の入荷カートンを処理できない」や「この機械は同じ週に二度リセットできない」といった文書化されていないものも含むのでしょうか？
そして、どのように損害を評価すべきでしょうか？品切れはクリアランスセールよりも悪いのでしょうか？金銭的にはどれほど悪く、どの商品に対してでしょうか？
私たちがサプライチェーン内に古典的な最適化エンジンを導入すると、これらの問いに答えるために、明示的にも暗黙的にもそれらを目的関数と一連の制約としてエンコードせざるを得ません。そして、そのエンコードに対してソルバーは「最適な」判断を見つけ出します。しかし、もしそのエンコードが現実と少しでもずれていれば、間違った判断がより早く導かれるだけなのです。
私は同じ話のさまざまなバリエーションを何度も見てきました。ある小売業者は、「サービスレベル」を在庫や物流コストを制約としながら誇らしげに最大化する新たな補充システムを展開します。書面上では品切れが減少しているものの、店舗には顧客が望まない遅い回転のサイズや色が過剰に存在するのです。あるメーカーは、単純化された設備容量モデルに基づいて生産スケジュールを最適化する高度な計画システムを導入します。その結果、画面上では計画が洗練されて見えるものの、実際の工場では重要なボトルネックを捉えられなかったために即席の対策に追われることになります。
これらの各ケースにおいて、最適化自体は機能しています。コンピューターは私たちが求めた通りのことを実施しているのです。しかし、問題は私たちが誤った問いを投げかけたという点にあります。
欠如している学問分野に名前を付ける
ここで提案したい概念は次のとおりです:
ホリミゼーション (名詞) – 複雑で進化するシステムに対するホリスティック最適化の学問分野。ここで主要な設計対象は最適化の枠組みそのものであり、目的、制約、データの意味論、意思決定の文法が含まれます。ホリミゼーションは、目的関数、モデル、そして計測手法が実世界からのフィードバックの下で共進化する反復的、実験的プロセスとして最適化を扱います。
ホリミゼート (動詞) – そのようなプロセスを実行すること。すなわち、意思決定システムを経済現実や組織の意図に沿うように、枠組みの設定、計測、最適化、リファクタリングを繰り返すことです。
狭義の最適化は内側のループに焦点を合わせ、固定された目的と世界の表現のもとで、その目的を極大または極小化する判断を見つけることに専念します。一方、ホリミゼーションは外側のループに焦点を当て、どのように目的を設計し、世界を表現し、システムを計測し、そしてこれらすべてが時間と共にどのように変化していくかを問います。
言い換えれば、最適化は「もし世界がこうであれば、何が最善か？」に答えますが、ホリミゼーションは「私たちは『最善』が意味を成すような世界の見方をしているだろうか？」と問いかけるのです。
これは抽象的な哲学の問題ではありません。混沌と進化する環境―サプライチェーンのような―において、私たちが最適化している問いは常に変化しています。市場は変動し、品揃えは変わり、チャネルは現れたり消えたりし、規制は進化し、内部の優先順位も移り変わります。もし最適化の枠組みが固定されたままであれば、スクリーン上の「最適」と現実的に意味のあるものとの乖離は、時間と共に確実に広がっていくのです。
ホリミゼーションとは、枠組み自体を一級の作業対象として扱う学問分野の名称として提案するものです。
サプライチェーンをホリミゼートするとはどういう意味か
ここで、私が多くの時間を費やしてきたサプライチェーンの具体例をもって説明しましょう。
例えば、店舗で「サービス向上」を目指すファッション小売業者を想像してください。狭義の最適化では、サービスを顧客の来店時に品切れにならない確率として定義し、「95%のサービスレベル」という目標を設定するかもしれません。その後、品切れをあるコスト、在庫過剰をまた別のコストとしてエンコードし、最適化エンジンにそのバランスを取らせるのです。
このアプローチは数値上は整然とした判断を導き出しますが、見た目には奇妙な結果となります。店舗は技術的には十分な数量のユニットを持つものの、ほとんどが不適切なサイズや、すべて安全な色だけで揃えられてしまい、実際の顧客には魅力的に映りません。
一方、ホリミゼーションの場合、「サービス」がまだ適切に定義されていないことを受け入れ、意思決定システムの展開自体を自己の仮定に対する実験とするのです。
実際のデータと最適化によって動かされる決定レシピを導入しつつ、その周囲に、人間のバイヤーなら即座に有害だと判断するであろう「非常識な」判断を浮かび上がらせるための計測手法を配置します。モデルが信じがたいほど不合理なサイズと、在庫処分品の組み合わせを店舗へ送ろうとするケースを監視し、システムが特定の店舗に多様性を与えないと不満を口にするプランナーの声に耳を傾けるのです。
そのような非常識な結果に直面するたびに、その原因を追求します。もしかすると、目的関数にはアソートメントの多様性を評価する仕組みがなく、単にユニットの利用可能性だけを評価していたのかもしれません。もしくは、店舗のリセット頻度の現実的な上限が捉えられていなかったのかもしれません。あるいは、過去データが、特定の品切れの影響を過小評価している代替効果を隠している可能性もあります。
そこで、我々は枠組みを変更します。目的に、金銭的価値を伴った多様性の定量的概念を導入し、厳格な制約をコストとして置き換える、またはその逆を行います。また、展示の更新時期や壊れやすい店舗への配送スケジュールの調整といった、新たな意思決定のカテゴリをレシピに加えます。さらに、次の非常識な結果が発生した際に診断が容易となるよう、計測手法を拡張してこれら新たな側面を可視化します。
こうして、私たちは状況をホリミゼートしたのです。ソルバーを非難したり、システムを無視したりするのではなく、意思決定の失敗そのものを、枠組みが不完全で進化する必要があるというシグナルとして活用したのです。
同様の話は、メンテナンスや修理の運用においても見られます。例えば、航空機エンジンの予備部品を管理しているとしましょう。素朴な最適化アプローチでは、各部品を独立したものとし、必要頻度を推定し、品切れと在庫保有にそれぞれコストを割り当て、最適な再発注点を求めるというものです。
しかし実際には、エンジンの修理はそう簡単にはいきません。真の損害は、他の多数の部品が在庫過多であっても、ある一つの重要な部品が欠如しているために修理が遅れるときに発生します。そのコストは、スプレッドシート上の単なる品切れではなく、航空機の数日間に及ぶ稼働停止として現れるのです。
ホリミゼーションは、目的をより現実に即したもの―例えば、エンジンあたりの予想遅延日数を予算単位で削減する―に再定義させるのです。同時に、どの部品が修理の遅延に繰り返し影響を与えているかを明確にする視点でプロセスの計測を強化します。もしシステムが、実際には修理のボトルネックになっていない部品を大量に在庫すべきと示唆すれば、それは非常識なシグナルです。逆に、エンジンの遅延を引き起こす部品を不足させる場合もまた、シグナルとなります。
こうした失敗を恥ずかしいバグとして隠すのではなく、我々の枠組みが誤っている箇所についての最良の情報源として活用し、その後、損害の測定方法、事象とコストとの関連性、そして意思決定の構造を調整して、将来の最適化がより現実に忠実な空間で行われるようにします。
つまり、ホリミゼーションとは最適化を排除することではなく、その失敗から学ぶために最適化を取り巻く実践を体系化することなのです。
最適化エンジンの背後に隠された作業
「最適化」を実践している大企業に足を踏み入れると、そこではアルゴリズムの設計よりも、データの意味を解明し、例外に対処し、システムの示す結果と現実を調和させる作業に多くの労力が費やされていることに気づくでしょう。
ホリミゼーションは、その隠れた作業を明示的かつ体系的にします。
多くの困難はデータの意味論に起因します。運用システムは、途方もない数のフィールド、コード、そして歴史的な癖を持っています。意思決定エンジンがこれらのデータを額面通りに解釈すると、必然的にいくつかは誤って理解されるのです。かつて意味を持っていた制限が、今では時代遅れになっていることもあれば、「リードタイム」と見なされるフィールドが、実際には輸送と管理上の遅延の混合である場合もあります。また、「販促中」といったフラグが、地域によって一貫して使われていないこともあるのです。
ホリミゼーションの心構えがなければ、これらの問題は偶然に、そしてしばしば被害が出た後に発見されるだけです。しかしホリミゼーションでは、最初からデータの解釈は仮説に過ぎないと考え、テスト、比較、健全性チェックを構築してその仮説を検証しようとします。もしシステムが、ドックの過負荷を引き起こす判断を提案したならば、それを「不運」と片付けるのではなく、我々の世界観に欠落している制約の証拠と捉えるのです。
また、重要な要素として計測手法があります。最適化エンジンそのものは盲目です。データを取り込み、意思決定を出力するのみで、その判断が妥当かどうかについて判断しません。ホリミゼーションは、主要な業績指標を追跡するだけでなく、システムが人間には非常識に映る動作をする箇所を明示するための可視性層を必要とするのです。
これは、過去のデータに対して意思決定を再現するタイムトラベルビュー、単一の製品やサイトに焦点を当てた、時間とともに進化する判断の様子を示す顕微鏡、そして平均値ではなく外れ値を強調するダッシュボードなど、さまざまな形態をとり得ます。目的は常に同じで、「非常識」と見なされる変数を、構造化されたフィードバックチャンネルに変換し、不満の原因ではなくすることにあります。
最後に、反復の迅速性と安全性が求められます。ホリミゼーションは本質的に実験的なものです。新たな枠組みや改訂された目的を、ビジネス全体を危険にさらすことなく試す必要があります。それは、意思決定レシピのバージョン管理、制御されたロールアウト、シャドウモードといった技術的能力だけでなく、明確な責任分担、実験を必要とする文化、そして安定した運用ルールと試験的なテストの違いを理解する経営陣など、組織的な能力も要求するのです。
これらすべては作業です。しかし、これは「システムが理解していない」と文句を言うたびに、我々がすでに非公式に行っている作業なのです。ホリミゼーションは、その作業に正当な名称と方法論を与えようとする試みです。
なぜ新しい言葉が重要なのか
「そもそもなぜ新しい用語を作る必要があるのか？」と合理的に疑問を呈するかもしれません。単に「良い最適化の実践」や「実験的モデリング」と呼べばよいのではないでしょうか?
私の経験では、明確な名前がなければ、外側のループが内側のループに飲み込まれてしまいます。「最適化」という言葉が議論に上ると、注意はアルゴリズム、ソルバー、パフォーマンスの指標に向かい、果たして本当に最適化すべきものは何かという、より根本的な問いから逸れてしまうのです。
対照的に、「ホリミゼーション」という言葉は、その構造自体に、最適化がより広い学問分野の一要素に過ぎないということを思い出させる効果を持っています。
それは、我々が重視すべき主要な成果物がソルバーではなく、ソルバーが動作する進化する枠組みそのものであることを示唆しています。
私自身の会社であるLokadにとって、この命名は、我々が構築しようとしているものを明確にします。 私たちは本質的には、単なる最適化エンジンの提供者ではありません。データが再構築され、目的が金銭的に表現され、意思決定が自動化されながらも理解可能であり、システムのあらゆる失敗が、枠組みの進化についての貴重な学習機会として扱われるプラットフォームを提供しようとしているのです。 数学としての最適化はなくなることはなく、ますます改善され続けるでしょう。ホリミゼーションは、我々のモデル、目的、制約を神聖なものとしてではなく、実世界と照らし合わせて検証すべき仮説として扱う、新たな視点への招待状なのです。
