最適化の維持

Joannes Vermorel

Lokadがエンタープライズクライアントに請求する料金体系は単純です¹。ソフトウェアと専門家サービスを組み合わせた、定額の月額料金です²。この月額料金が、導入フェーズの終わりに大きく下がるのではなく、時間が経ってもほぼ一定であることに驚く人もいます。もっとも、多くの人は驚きません。エンタープライズソフトウェアの世界では、ベンダーの強欲じみた振る舞いなど珍しくもないからです。しかし、これは教科書的な暴利の例ではありません。むしろ、この料金こそが、持続的なサプライチェーン性能を実現するために必要な水準なのです。

エンタープライズソフトウェアベンダーにとって最も収益性が高い道は、昔も今も、金を受け取って逃げること です。前払いのライセンス料は、紙幣を刷るのに等しいものです。ライセンス販売に比べれば、統合作業ははるかに骨が折れます。リスクは高く、利幅は薄くなります。そのため大手ベンダーはたいてい、この部分を丸ごと下請けに出し、火の粉をかぶる役をインテグレーターのネットワークに押しつけます。しかし、ベンダーの立場から見て最も儲からない部分は、圧倒的に保守です。高額な保守費を請求していても、なおクライアントにアップグレードを強制するのは、そのためだと考えれば筋が通ります。保守費は十分に高く見えても、ベンダー自身のレガシーを支えるのに必要な水準には到底達していません。

ただし、サプライチェーン最適化は少し特殊です。ベンダーたち（Lokadではありません）は、保守を 消し去ること に「成功」してきたからです。もちろん、この「成功」はクライアントが望んでいた種類の成功ではありません。

1980年代以来、ベンダーたちはサプライチェーンの意思決定を自動化するためのソフトウェアを提供してきました³。Lokadも同じ系譜に属しますが、登場はずっと後です。それ以来、ほとんどすべての大企業が、その種のソリューションを1つどころか複数導入してきました。ERPという名称、すなわち Enterprise Resource Planning という呼び名自体も、1990年代に「計画」の部分を自動化したいという野心に由来しています。そうでなければ、Enterprise Resource Management を意味する ERM と呼ばれていたはずです。

それでも、サプライチェーンの意思決定の自動化は実現しませんでした。システムは導入されたものの、埃をかぶっているか、本来の使命を回避しているかのどちらかです⁴。その結果、サプライチェーンの大半はいまだにスプレッドシートで運営されています。つまり、これらの最適化ソリューションが当初は成功と見なされていたとしても、保守のどこかで何かが壊れたのです。

こうした失敗は、ソフトウェアベンダーにとっては利益になります。ベンダーはライセンス料、SaaSであれば複数年契約の収益を確保して立ち去れます。ソリューションが機能していない、少なくとも最適化部分が機能していないのであれば、保守はほとんど、あるいはまったく不要です。クライアントも、どうせ使っていない機能については気にしないため、ベンダーに強い圧力をかけません。元のソリューションのうち残るのは、ごく一部だけです。通常は、企業システムに組み込まれた基本的な自動化ルール、たとえばSKUごとの min/max 設定などを管理するための、薄いデータ入力ゲートウェイにすぎません。

一方でLokadは、本番運用に耐える自動化されたサプライチェーン意思決定を実際に提供しています。ただし、それを成立させるには、クライアント専任のタスクフォース、つまり Lokad の用語でいう サプライチェーンサイエンティスト の継続的な努力が必要です。このサイエンティストは、対象となるサプライチェーン意思決定を生成する数値レシピを設計し、その後も保守する責任を担います。

完成した数値レシピは、しばらく放置しても動き続けます。サプライチェーン最適化において「本番グレードの」自動化とは、おおむねそういう意味です。したがって、サプライチェーンサイエンティストは、ある時点で現場から外れても、直ちに企業へ損害を与えるわけではありません。

とはいえ、サプライチェーンは絶えず姿を変える厄介な対象であり、その変化は当然ながら連鎖的な影響をもたらします。私たちのアルゴリズムはフローの規模変化には対応できますが、本番グレードの数値レシピを維持するために必要となる、その他の微妙な変化すべてに対処できるアルゴリズムは、まだ存在しません。

その結果、Lokad が本番稼働に入った後も、サプライチェーンサイエンティストには対応すべき一連の仕事が残ります。

• 新しいデータが利用可能になれば⁵、その価値を取り込むために数値レシピを更新しなければなりません。逆に、廃止されるデータソースもあり、それに応じて数値的な依存関係を切り離す必要があります。規模の大きい企業では、ERP の更新時に限らず、アプリケーション環境そのものが常に変化しています。

• 企業戦略は変化します。数値レシピはクライアントの戦略的意図を反映したものであり、その反映は単に数個のパラメータ値を選ぶだけでは済みません。戦略の方向転換に合わせてサプライチェーンサイエンティストがレシピの一部を丸ごと書き換えることは頻繁ではありませんが、実際に起こります。

• 信頼は維持されなければなりません。サプライチェーン部門のリーダーは、数値レシピが健全に機能していることを示す継続的な証拠を、サプライチェーンサイエンティストに求めます。サイエンティストには、新しい、あるいは改訂された業績指標を反映する計測手段を整えることだけでなく、経営陣や責任者から出てくる疑問に答えることも期待されます。

• 透明性も維持されなければなりません。サイエンティストは、数値レシピを「ホワイトボックス化」する責任を負います。そのためには、チームが十分な理解を持てるよう教育する必要があり、その理解があって初めて、数値レシピが提供する自動化を最大限に活用できます。人の入れ替わりがあれば、新しく入った人たちを再教育しなければなりません。

これらの仕事のどれか一つでも失敗すれば、現場の実務担当者はスプレッドシートへ戻る以外に選択肢がなくなります。

したがって、数値レシピは数週間であれば放置しても動きますが⁶、その妥当性は時間とともに必ず劣化します。数値レシピを意味のある状態に保つには、継続的なエンジニアリング資源が必要です。人工知能が近年進歩したとはいえ、自己保守できるソフトウェアを設計することは、いまだ技術水準をはるかに超えています。異論を招く表現かもしれませんが、この課題は人工汎用知能の実現と同じくらい難しいように見えます。

サプライチェーンサイエンティストの継続的な関与が 必要である としても、数値レシピが本番に入れば、その負荷は減っていくと考えたくなるのも無理はありません。しかし、私たちの経験はその逆を示しています。数値レシピの複雑性は、利用可能なエンジニアリング資源の水準に合わせて、ほぼ必ず膨張していきます⁷。

この10年、私たちは資源配分に関して何度も同じ転換点を見てきました。もしレシピの立ち上げ⁸に投じた初期資源が、その後の年間保守に会社が投じるつもりの資源を上回るなら、そのレシピは本番グレードの状態を維持するために必要な水準のケアを受けられません。この見落としの最も典型的な症状は、重要ではあるが直ちに致命的ではない項目、たとえばドキュメント、コードレビュー、コード整理、計測整備などが、延々とバックログに積み上がることです。

どの技術やプロセスも事業成功を保証するわけではありません⁹。しかし、不適切な保守は、企業を出発点へ引き戻し、そのままスプレッドシートの海に沈めるための、昔から実証済みの処方箋です。あなたの会社を、完全に回避できたはずのサプライチェーン失敗事例の新たな1件にしてはいけません。