00:22 はじめに
02:40 なぜ製品か？それは資本主義だから
08:18 製品は何をすべきか？
10:05 ソフトウェアの規模の不経済
12:50 市販のSCO製品を購入しよう
21:58 SCM対SCO
25:58 幕間
28:21 SCOは一般的なソフトウェア製品ではない
33:26 SCOのためのソフトウェア要素
42:49 しかしスプレッドシートが最終形態ではない
46:51 Pythonも最終形態ではない
58:52 SCはIT部門ではない
01:03:19 結論として、克服すべき2つの課題
01:07:04 次回講義と聴衆からの質問
説明
定量的サプライチェーンイニシアティブの目的は、ルーチンな意思決定の範囲（例：在庫 補充 や価格更新）をロボット化するソフトウェアアプリケーションを提供または改善することにあります。このアプリケーションはエンジニアリングされる製品として見なされます。供給チェーン理論は、製造に伴うすべての制約に適合しながら企業を サプライチェーンパフォーマンス へ導くアプリケーションを提供するために存在します。
全文書起こし
皆さん、こんにちは。このサプライチェーン講義シリーズにご参加いただきありがとうございます。私はJoannes Vermorelと申します。本日は「サプライチェーン最適化のための製品指向デリバリー」についてご説明いたします。
まず、製品と言う場合、私はソフトウェア製品を意味しています。現代の企業向けビジネスアプリの内部構造を調査する機会に恵まれた方なら、その体験は非常に印象深いことでしょう。
H.P.ラヴクラフトの作品に精通している方なら、不穏な類似点に気づくかもしれません。ラヴクラフトは一連の小説を発表しており、反復するテーマの一つは禁断の知識という考えです。宇宙は知ることができるのに、唯一人類を守っているのは無知であるということです。無知は問題ではなく、むしろ精神が耐えうるにはあまりに恐ろしい宇宙から私たちを守るものです。この考えは、多くの現代ゲーム、特にロールプレイングゲームに取り入れられ、従来の体力ポイントに加えてキャラクターには正気ポイントが設けられています。もし正気を損なう行動をとれば、正気ポイントが減少します。エンタープライズソフトウェアの課題は、正気を保ちながらこれを作成することであり、これが企業に付加価値をもたらすための要件の一つとなっています。それでは進めましょう。
なぜ製品、特にソフトウェア製品なのでしょうか？伝統的なサプライチェーンの運用方法を詳しく見てみましょう。従来、現場では多くの人々が物を運び、荷物を仕分け、車両を運転し、手作業で労働していました。製造現場や店舗にも多くの人が関わっていました。しかし、ここ数十年でブルーカラーの労働者数は着実に減少してきました。今日では、生産現場は大幅に自動化され、例えば繊維業界のようにすべてを自動化するのが難しい産業は、人件費が最も安い地域へ移転する傾向にあります。現実として、単純労働の需要は大幅に低下しています。
自律走行車が目前に迫る中、非常に奇妙な状況が生じます。多くの企業では、現場でのブルーカラー労働者よりも、Excel スプレッドシートを扱うホワイトカラー労働者の方がサプライチェーン運営に従事するケースが増えています。これが私が事務作業と呼ぶ状況です。
もう一つの特異な点は、少なくとも20年以上にわたり多くの企業でサプライチェーンがデジタル化されていることです。サプライチェーンにソフトウェアを導入するのではなく、すでにソフトウェアで運営されているのです。しかし、これらのシステムにおける人間の役割を見ると、一般的なサプライチェーンシステムでは、人間が文字通りコプロセッサとして使われています。通常のCPU（機械内のプロセッサ）では実行できない特定の操作が存在するため、全てが人間に委ねられるのです。単純な数値レシピ、例えばABC分析やミンマックスによる在庫管理といった手法と連携することで、人間は日々、例外や標準枠組みに当てはまらない条件に対処するという火消し作業に追われることになるのです。
コストの観点から見ると、これらはすべて営業経費（OpEx）に該当します。企業が日々下す必要のある平凡な意思決定―何を買うか、在庫をどこに配置するか、ある倉庫から店舗へ単位を移動するか、その他多くの日常的な決定―を処理するために、大勢の事務員に毎日報酬を支払わなければなりません。システムが生成する自動的な判断の不備に対処するため、人間がこれらの決定を下し、火消し作業を行っているのです。
本日の提案は、OpExから設備投資（CapEx）へと移行することです。これが製品指向デリバリーの要点です。私たちは資産を構築したいのです。なぜなら、それが資本主義的であるからです。現代の世界で最も収益性の高い上位100社を見ると、そのうち半数は利益面でソフトウェア企業であり、先行投資により、最小限の追加投資で付加価値を生み出す装置や成果物を手にしています。
前回の講義に戻ると、経営を再び掌握するためにはロボット化が必要です。自動化と人間は協力すべきであり、人間はミンマックスのような単純な在庫方針の不備に対処するために存在すべきではありません。むしろ、人間は付加価値を提供し、数値レシピを改善し、戦略家として機能すべきです。かつてのIBMのモットーに「機械は働き、人間は考える」という言葉がありました。これが本プレゼンテーションに込められた考え方です。私たちはサプライチェーンを資本主義的な資産へ転換したいのです。そのためには、サプライチェーンをソフトウェア製品を提供する機械へと変える必要があります。
この製品は実際に何をするのでしょうか？実は、非常にシンプルなこと、すなわち意思決定を行います。恣意的で無限の選択ではなく、何を生産するか、サプライヤーから何単位購入するか、一箇所から別の箇所へ何単位移動するかといった、平凡で日常的な決定です。一見するとサプライチェーン管理には数多くの意思決定が関与しているように思えますが、実際には複雑なサプライチェーンでさえ、1日に数十種類の意思決定で済むのです。これは圧倒されるほどのものではなく、機能数の観点からも十分合理的です。興味深いことに、これらの意思決定は大部分が相互に排他的であるため、分割統治の手法でできることには限界があります。一度、サプライヤーから100単位を購入する決定を下すと、別のサブシステムが200単位を購入する決定を下すことはできません。最終的には、どれだけの単位を購入し、どこへ移動させるかを確定しなければならないのです。これらの意思決定は離散的で、範囲が限定され、ほぼ排他的です。私たちが求めているのは、毎日完全に自動化された方法で注文の意思決定を生成するソフトウェアです。
ソフトウェアについて十分に理解されていない点の一つに、規模の不経済という概念があります。規模の経済は多くの人々にとって馴染み深いですが、ソフトウェアでは、機能を4分の1追加するだけでコストが倍増する場合があるのです。この概念は、小規模なスタートアップが大企業に匹敵できる理由を説明しています。つまり、スタートアップはごく一部の機能に注力することで、製品を市場に投入するコストを大企業よりも大幅に低く抑えられるのです。
規模の不経済の考えを念頭に置くと、サプライチェーン最適化製品を自社開発すべきか、購入すべきか、または別のアプローチを取るべきかを決定する必要があります。もしベンダーから製品を購入する場合、ソフトウェアベンダーが市場に提供すべき機能を考慮しなければなりません。
それでは、棚からサプライチェーン最適化製品を購入することを検討してみましょう。これらのスライドでは、対処すべき多数の課題のごく一部を概観しています。私自身、2008年にLokadを始めた際、サプライチェーン最適化よりも予測に重点を置いた小規模なソフトウェア製品からスタートした経験があります。クライアントと仕事を進めるうちに、自分にない多数の機能や能力があることに気づき、さらに他のクライアントではより多くの不足を実感しました。新たな要件を発見する終わりのないプロセスのように感じられたのです。
核心的な機能のみを見てみましょう。まず、企業はB2CまたはB2Bに分類され、サプライチェーン管理において全く異なるパターンを示します。例えば、B2B企業は通常、顧客数が少ないものの、その顧客ははるかに大量の注文を行います。これにより、企業収益の大部分を占める単一の顧客を失うリスクなど、異なる種類のリスクが生じます。さらに、B2B2CやB2B2Bといった、より複雑なビジネスモデルも存在します。
店舗、倉庫、生産施設など、カバーすべき多種多様な拠点を考えてみてください。それぞれの拠点は固有の課題を伴います。例えば、店舗はRFID技術があっても、顧客が商品を動かすため在庫誤差が発生しがちです。倉庫や農場、鉱山などの生産拠点は、生産収率における独自の問題や不確実性を抱えています。
サプライチェーンネットワークは、単一エシェロンから多エシェロンシステムまで、さまざまな階層構造を持ち得ます。エシェロンの数が増えるにつれて、サプライチェーン管理の複雑性は大幅に増加します。ネットワークのトポロジーも重要な要素です。ツリートポロジーは、少数の生産拠点から複数の倉庫へ出荷し、そこから多くの店舗へ配送する古典的な前方サプライチェーンパスを示します。しかし、複数の倉庫が1つの店舗に供給するなど、DAG（有向非巡回グラフ）といった他のトポロジーも存在し得ます。
つまり、グラフとしては単なるツリーではなく再接続が可能な場合もありますが、それでも前方のみの構造です。しかし、複数のサプライヤーが存在する場合、DAGでも同様の現象が起こり得ます。修理が関与する場合には、サプライチェーンのグラフにループが生じることもあります。例えば、鉱業や航空宇宙業界では、修理可能な設備に起因する多数の修理ループが存在します。
さて、在庫そのものは一種類の性質だけではなく非常に多様です。「これが私の持つSKUだ、それだけだ」とは言えません。まず、原材料はグラム、キログラム、体積といった単位で測定されます。次に、ほとんどの場合、整然とした単位で表される製品があります。しかし、医薬品や食品業界のように、特定の賞味期限が付いたロットが非常に頻繁に存在する在庫もあります。さらに、各単位に固有のシリアル番号が付与される完全なシリアライズ在庫も存在します。サプライチェーン最適化の観点からは、これらは状況を一変させ、各ケースごとにまったく異なる問題となります。
そして当然ながら、マーケットプレイスに関する問題もすべて存在します。Lokadでは、ありとあらゆる状況のクライアントを抱えており、第三者のマーケットプレイスで販売するクライアント、自社のマーケットプレイスを保有するクライアント、またその両方を持つクライアントが存在します。売れ残りの品を処分するための二次的な仕組みとして利用される場合もあるのです。状況は様々です。
さて、例えば「注文」とは何かについて少し考えてみましょう。スポット注文とは、カウンターで即購入し、自分のものとする注文です。しかし、例えば「購入するがすぐには納品せず、1か月後に納品してほしい」という注文もあり得ます。明らかに、サプライチェーン最適化の視点からは、特定の日に一定量を納品しなければならないと前もって分かっている場合、その部分の予測は不要となり、全く異なる状況となります。
さらに、構成注文というものもあります。たとえば、オンラインでコンピュータを購入する際に、メモリ容量、ハードドライブ容量、オペレーティングシステム、設定する言語、キーボードの種類などを選択できる場合です。つまり、大規模なコンフィギュレータが存在し、状況が再び一変します。これは自転車や自動車などでも見られ、サプライチェーン最適化の課題に対し、全く異なる選択肢やアプローチを提供することになります。
価格についても、単位あたりの価格が固定で、とてもシンプルで直線的な設定であっても、それだけではありません。例えば、10ユニット購入すると割引が適用されるような段階的な料金設定があったり、また特定の製品や条件に応じて、loyaltyプログラムによりロイヤルティカードを持つクライアントに割引が適用されたりすることもあります。そしてB2Bの場合は、交渉が非常に頻繁に行われ、実際には多数の取引が成立しながらも通常のカタログ価格が存在する一方、ベンダーが重要なクライアントにリベートを与えるという運用が行われます。結局のところ、ここ数分で核心部分だけに触れたに過ぎず、必要不可欠な要素にはまだ手をつけていません。ですから、一度立ち止まって、サプライチェーン最適化を実現するための既製エンタープライズソフトウェアがどのようなものになるかを考えてみてください。取り扱うべき機能の数は文字通り途方もなく、それらすべてを一つのモノリスにまとめようとすると、正気を失いかねません。私たちは、宇宙そのものが理解不能なのではなく、むしろその裸の真実に触れると正気を失ってしまうのだという考えに立ち返る必要があります。
そこで、サプライチェーン管理とサプライチェーン最適化を区別するという大きな問題に直面しています。これは、以前の講義でも取り上げた区別です。管理側と最適化側との間には大きな混乱が存在します。管理とは帳簿整理、ワークフローの支援、そして主にデータ入力プロセスに関するもので、これまで述べたすべてを表現しようとすれば非常に広範囲をカバーする必要がありますが、不可能ではありません。「肥大化した」ERPならそれが可能です。はい、最終的には1万ものテーブルに及び、見た目はかなり醜くなりますが、実現は可能です。しかし、決して誤解してはなりません。ERP（むしろERM、Enterprise Resource Managementと呼ぶべきもの）は、多くの処理を行うわけではなく、単にそれらの情報を記録するだけにすぎません。つまり、MOQsや価格の段階的設定、店舗、倉庫など、膨大な数のエンティティが存在することになりますが、そこに高度な知性は求められていないのです。単にデータを反映する凡庸なデジタルの対応物として、システムへのデータ入力を可能にするだけなのです。
これは、「機能を4分の1増やすだけでコストが倍になる」というルールを少し回避できるからこそ可能なのです。実は十分に触れてこなかったのですが、機能を完全に分離して運用すれば、それでうまくいくのです。各機能が互いに相互作用しなければ、規模の経済の呪縛から逃れることができるのです。データ入力の面から見ると問題はなく、MOQsを操作するユーザーインターフェースと、ネットワークに追加店舗を加えるための操作は完全に分離して扱うことができるのです。
しかし、サプライチェーン最適化に関しては同じことは言えません。もしMOQsが存在すれば、それは注文の頻度や倉庫から店舗への配送頻度に深刻な影響を及ぼします。影響は途方もなく広範囲にわたり、すべての要素を分離することはできません。結局、サプライチェーンとは全てが互いに影響し合う一つのシステムに過ぎないからです。つまり、サプライチェーン最適化の観点からは、最適化を実現するためにこれらすべての要素を組み込む必要があり、その点で物事がうまくいかなくなるのです。
管理側では最終的に製品として形にすることが可能ですが、サプライチェーン最適化に関しては、本質的に実現できないのです。できるふりはできても、実際には不可能です。Lokadも、予測型サプライチェーン最適化を専門とする供給予測会社としてではなく、「Forecasting as a Service」としてスタートしました。2008年のLokadブログに戻ると、当初はtime series予測から始めたのですが、これは大きな誤りでした。それでも、これが私の始まりでした。全体のごく一部に過ぎない時系列予測でさえ、管理しきれないのです。これが、12年以上この業界で経験してきた結論です。
ソフトウェア開発の特異な世界に立ち返ると、それは非常に独特なものです。もしあなた自身がソフトウェアエンジニアとして訓練を受け、大手成功企業のソフトウェア開発方法に精通していなければ、その仕組みについてはほとんど理解が及ばないでしょう。実際、そこは直感に反する側面が数多く存在する非常に特定の世界です。特に、古典的な機械工学的またはマーケティング的思考を持つ伝統企業は、ソフトウェアがどのように動くのかを理解するのにも非常に苦労します。
これらの側面については今後の講義でさらに詳しく取り上げますが、私が特に好きな一冊の本があります。これは、初期のMicrosoft Excelチームに所属していた元Microsoft社員であり、またStack OverflowやTrelloの共同創設者でもあるJoel Spolsky氏によるものです。2004年、私がまだ学生だった頃、彼の著書とブログを読みました。その本のタイトルは “Joel on Software” で、成功するソフトウェアビジネスの運営がいかにあるべきかをユーモラスに示しています。これは、この業界外の大多数の人々が期待するものとは全く異なります。その本の詳細はビデオの説明欄に追記する予定です。
しかし、サプライチェーン最適化は、一般的なソフトウェア製品とは一線を画しています。普通のソフトウェア製品の場合—確かに、製品の種類によっては対立する動作が見られることもあります。例えば、ソーシャルネットワークでは、憎悪に満ちたコンテンツを投稿する人々が数多く存在し、全く別の状況となります。しかし、Microsoft WordやExcelのような伝統的なエンタープライズソフトウェアの場合は、正しいデザインが求められるものの、緊急性は全くなく、何年もかけてデザインや製品を洗練させることができる—長期投資として数十年先を見据える必要があるのです。開発に急ぐ必要はありません。しかし、サプライチェーン最適化はそのようには機能せず、物事は常に起こり、状況は非常に厳しいため、選択の余地がないのです.
パンデミックのような極端な状況や、ランサムウェアなどによってネットワークの半分が停止してしまう問題が発生する可能性があります。現有するキャパシティを最大限に活用するために、賢明な判断を下す必要があるのです。悲劇的な事故による運行停止、あるいは戦略を混乱させる関税などの政治的動き、またはカリフォルニアやオーストラリアで発生する津波、火災、猛暑といった自然disastersに直面するかもしれません。こうした出来事は必ず起こるため、実際に数時間以内に対応できなければならないのです.
ソフトウェア製品は既に存在しているものの、変革をもたらす必要があり、その変革はプログラムによって実現されなければなりません。ソフトウェア資産を提供するという考えにいるなら、そのソフトウェアを動かす少数のチームがサプライチェーンを支えているのです。全日程で消防対応にあたる事務員の大軍がいるわけではありません。仮に大軍の事務員を抱えていたとしても、彼らを訓練する必要があり、予期せぬ事態が発生した時には、その状況に適切な訓練を受けた集団が存在しないことになってしまいます。私の経験から言えば、管理しなければならない人数が多ければ多いほど、何かを成し遂げるのに要する時間は長くなるのです.
数日前、貨物船が悪天候のために1,800以上のコンテナを失ったという事件がありました。こうした事態は避けられず、排除することは不可能です。サプライチェーンは、全てが厳格に管理された生産現場がある製造業とは異なり、定義上、広大な世界で発生するため、ほとんどの状況で環境要因のコントロールが利きません。自分の制御を超えた数多くの力が働いている中で、思いがけない出来事に対応できる体制が求められるのです。驚きは避けられないと分かっている以上、常に準備を整えておかなければなりません。準備が整っているというのは、全てを綿密に計画しているわけではなく、必要な際に数時間以内で対応できるシステムを持っていることを意味します。これが、現実的に問題に取り組むための本質なのです.
さて、サプライチェーン最適化のためのソフトウェア要素として何が必要でしょうか？まず第一に、あらゆる多様なデータソースを表現できる柔軟なデータストレージが必要です。表現すべき内容が非常に多岐にわたるため、高度な構造と多様性を備えたものが求められます.
第二に、プログラム可能なロジックが必要です。改めて言いますが、プログラム可能なロジックがなければ、これらの問題すべてにどう対処するのでしょうか？どうやって全ての要素を繋ぎ合わせるのでしょうか？あらかじめ全てがプログラムされた既製品を購入することはできないのです—それでは機能しません.
次に、柔軟なユーザーインターフェースが必要です。なぜなら、問題の見方は状況により大きく異なり、各社ごとにKPIも全く異なるため、あなたが望む方法で数値を提示できる柔軟なユーザーインターフェースが不可欠だからです。そうでなければ、大きな制限となってしまいます.
また、サプライチェーンは本質的にチームワークであるため、協働機能も必要です。多くの人が関与し、分散しているため、協働機能は中核をなす要素となるのです.
最後に、そしておそらく意見が分かれる点ですが、プログラム可能な機能が、専門に訓練されたソフトウェアエンジニアでなくても利用できる形で提供されるべきです。これはいくつかの理由で重要です。第一に、労働市場には熟練したソフトウェアエンジニアが非常に少なく、彼らを採用する競争は激しいのです。第二に、優秀なソフトウェアエンジニアになるには莫大な努力と献身が必要であり、同時にsupply chain specialistであるのは非常に困難だからです.
両分野において二刀流の能力を持つ人材は非常に稀です。もし、プログラマーでありながら弁護士や、プログラマーでありながら医師という人材を求めたとしたら、同様のことが言えます。確かにそのようなスキルセットを持つ人は存在しますが、大企業として毎年安定して大量に採用できるでしょうか？10年にわたりLokadを運営してきた私の経験からすると、うまくいかないのです.
プログラム可能なものが求められる一方で、プログラミングの対応にプロのソフトウェアエンジニアである必要はありません。覚えておいてほしいのは、サプライチェーンに精通した人材が必要だということです。なぜなら、IT部門にチケットを発行して転送するのではなく、数時間以内にシステムに対してプログラム修正を適用できなければならないからです。そのような方法では、問題解決に数週間を要してしまいます。では、実際にこの問題を解決できるソフトウェアとは何でしょうか?
さて、Excelなら可能です。見た目は洗練されていないかもしれませんし、最新のソフトウェアの頂点とは言えないかもしれませんが、必要な役割は果たします。あらゆる要件を満たしているのです.
柔軟なデータストレージ？ はい、ある程度までならExcelにはあらゆる種類のデータを大量に格納できます。プログラム可能なロジック？ もちろん、Excelは完全にプログラム可能です。柔軟なユーザーインターフェース？ はい、棒グラフや折れ線グラフ、その他多様な方法でデータを提示できます。ユーザーインターフェースの面では非常に柔軟であり、最も洗練されているわけではありませんが、柔軟性という点では多くのことが可能です.
協働機能の面では、やや粗削りです。オンライン版のExcelも存在し、多少改善は見られるものの、本質的にはスプレッドシートの共有にとどまっています。協働機能が欠如している問題は、デスクトップアプリであるがゆえではなく、スプレッドシートに伴う考え方自体が、集中的な協働作業には適さないという点にあります。通常、非常に複雑なシートを作成した同僚がいる場合、そのシートの内容を理解するよりも、一から再作成したほうが簡単なのです。つまり、協働機能の欠如は、そもそもスプレッドシートが持つ協働に対する限界的な思考から来ているのです.
しかし、Excelは非開発者にも完全に利用可能であり、より複雑なタスクにはVisual Basic for Applicationsも用意されています。必要な要素という点では、Excelは全ての条件を満たしており、それが多くのサプライチェーンで運用上成功している大きな理由だと私は考えています.
私の経験では、世界中のサプライチェーンの大部分は、最小の企業から最大の企業まで、エンタープライズソフトウェアに一銭も投資しない企業から、サプライチェーン最適化のために何百万ドルも投資している企業に至るまで、Excelによって駆動されています。例外はごくわずかで、時には他のソフトウェアのmin-max設定の修正にExcelが用いられることもありますが、これらの設定の維持管理はExcelを扱う担当者に委ねられているのです.
今日のサプライチェーンの現場はExcelによって動かされており、それは偶然ではないと私は考えています。その根底には、スプレッドシートが本質的に多くの重要な問題を解決しているという事実があります。多くの他の選択肢が優れていると謳われても、プログラミングができなければ結果は出ません。プログラミングができなければ、大きな問題や緊急事態に直面した際に対処できないのです。柔軟なユーザーインターフェースが不足している場合や、非開発者が利用できないソリューションに直面した場合、人々は結局Excelのスプレッドシートに頼るようになります。もし、結果を出せるのがITチームだけであれば、最初はチケットを発行して辛抱強く待つかもしれませんが、三ヶ月以内には皆がより迅速な対応が可能なExcelに戻るでしょう。Excelは最終的な解決策ではありませんが、いかなる優れた代替品を生み出すにしても、必要な要件を満たさなければならないのです.
ものをより良くするにはどうすればよいのか？多用途なデータ保存という観点では、Excelは良いが非常にスケーラブルではない。最新のExcelバージョンで100万行を扱えるとしても、数百万行の処理は問題となる。大規模に操作するとパフォーマンスの問題がすぐに発生する。Excelでプログラム可能なロジックを実現することは可能だが、非常に脆弱で壊れやすい。もしスプレッドシートにうっかりミスやバグを導入してしまうと、デバッグして問題の原因を特定するのは悪夢となる。論理が無限に複製され、同じロジックが何千も作られるため、エラーを見つけて修正するのが困難になる。
ユーザーインターフェースは理想的ではなく、完全にウェブベースというわけではなく、データが常にインターフェースと絡み合っている。共同作業機能は存在するものの、混沌としている。協働はプログラム可能なロジックのレベルで行われるべきだ。多くのサプライチェーン最適化ベンダーは、予測を手動で微調整したり複数人が参加したりする形で出力に対する協働を提供している。しかし、これは誤ったアプローチである。協働は必要だが、それはロジックのレベル、すなわちプログラム可能なロジックのレベルで行われるべきだ。Excelは非開発者にとって非常に利用しやすいが、少し複雑なことをしようとすると難しくなる。サプライチェーン管理では、確率的予測や乱数変数、不確実性に対応するため、あらゆる可能な未来に対処しなければならない。これをExcelで実現することは可能だが、非常に複雑である。Excelは単純なタスクには容易だが、より複雑な状況ではExcelの達人になる必要がある。
メンテナンス性は重要だ。なぜなら、時間と共に価値が増大する資産を構築したいからである。スプレッドシートではこれを実現するのは難しく、少なくともソフトウェア製品としての意味で、本当に正確なものを作るのは困難である。
今日の流行語はAIとPythonであり、データサイエンスを取り巻くあらゆるトレンドとハイプがある。しかし、サプライチェーン管理においては、PythonはExcelに劣ると考えている。
誤解してほしくはない。私はPythonが大好きで、素晴らしい言語だと思っているし、10歳の娘にさえ教えている。しかし、サプライチェーン管理においてPythonが最適な選択肢ではない理由がいくつかある。まず、Pythonはソフトウェアエンジニアを必要とする。たとえPythonが最もアクセスしやすいプログラミング言語の一つだとしても、より複雑なことをしようとすると、サプライチェーンの専門知識とソフトウェアエンジニアの両方を持つ人材が必要になり、これが大きな課題となる。
Pythonには優れた機能があるが、依存関係の扱い方が非常に複雑で、パッケージ管理も不十分である。パッケージは追加機能を提供するビルディングブロックであり、Pythonを使うというのは言語だけでなく、NumPy、Pandas、TensorFlow、SciPyなどのサードパーティライブラリを含む全体のエコシステムに関心があるということになる。パッケージ管理は10年以上にわたって不十分で、改善はされているものの進捗は遅い。システムの設計上の多くの側面が、改善を困難にしている。
パフォーマンスもまた、設計上の理由から非常に低い。計算性能とは、あなたのコンピュータに備わる生の演算能力を活用するために、Pythonが行う作業の質を指す。驚くべきことに、Microsoft Excelはこの点でるかに優れている。Excelは高度に最適化されており、マルチCPU、マルチコアシステムを活用し、ネイティブにコンパイルされたロジックを実行する。MicrosoftはExcelを非常に高速にするために多大な投資をしている。
対照的に、Pythonには本質的な問題があり、そのためパフォーマンスは理論上あなたのマシンが発揮できる速度に比べてしばしば100倍遅くなる。現代のコンピュータの能力を考えれば許容範囲に思えるかもしれないが、取引量が5000万ドルを超える企業にとっては理想的ではない。初めから優れたパフォーマンスを提供するものが必要なのだ。
Pythonのパフォーマンス不足を補うためにNumPyのようなサードパーティライブラリを使うという発想は、複雑さを増すだけである。パフォーマンスの問題を解決しているように見えても、同時にNumPyの複雑さという新たな問題を引き起こし、そのメンテナンスを長期にわたって行わなければならなくなる。これはソフトウェアエンジニアリング側のハードルも引き上げる。
実際のサプライチェーン管理のためにPythonソリューションを実装しようとすると、ヌル参照例外、メモリ不足例外、長時間の計算など様々な問題が発生する。計算が完了するまで20分も待たされ、果たして完了するのか、それともプロセスを強制終了して再起動すべきか迷うこともある。完了までにどれだけ時間がかかるか正確に予測できる状態が望まれる。ちなみにExcelに話を戻すと、現在では多少時間のかかる操作がある場合、Excelはかなり信頼できるインジケーター、つまり進捗バーで完了までの時間を示してくれる。これもまた、生産現場で求められる「プロダクション・レディネス」の一部である。あなたが作るソフトウェアは、ほとんどの場合、夜間や一括処理の間に無人で動作するものになるため、データサイエンティストが常に監視する必要のないものが必要なのだ。
そして再び、もしデータサイエンティストが問題であるならば、第三の能力が必要となる：サプライチェーンの専門家、ソフトウェアエンジニアリングの専門家、そしてデータサイエンティストの専門家である。一人でこれら三つの資質を兼ね備えることは可能だが、それら全てを持つ人を年に一人以上採用するのは、たとえ大企業であっても容易ではない。本当に極めて稀な存在なのだ。
つまり、改善される何かが必要なのだ。ちなみに、最初に改善すべきは深層防御である。ランサムウェアが増加する中で、組織にプログラム可能な何かを導入すると、同時にランサムウェアのリスクにも晒されることになる。なぜなら、プログラムが存在すると、そのプログラムは稼働しているマシンを乗っ取るなど、数多くのことを行えるからだ。問題を緩和する方法は山ほどある。サンドボックス化したり、制限をかけたり、権限を限定したりと様々な手段がある。しかし、汎用のプログラミング言語のようなものを使えば、技術用語では「アタックサーフェス」と呼ばれる攻撃対象面積が、実に莫大になってしまう。
要するに、そのようなコードを組み込むたびに、セキュリティ上の問題に大きく晒されることになる。そして、通常のソフトウェアエンジニアリング企業では、コードはピアレビューされる。すなわち、コードをレビューし、コードレビュープロセスを経て、誰かが作成したコードを同僚がチェックして、不正行為がないか確認する。しかし、ソフトウェアは堅牢でなければならず、数時間以内に対応できる必要があるという現実に照らすと、サプライチェーン最適化の観点からコードレビュープロセスを導入することは不可能なのだ。遅延や緊急事態と両立しないからである。
したがって、設計段階から深層防御を提供する何かが必要だ。そして次に、透明性のあるパフォーマンスを持つものが求められる。すなわち、物事に時間がかかるとしても、それを自分でコントロールでき、あらかじめ完了までの時間が把握できるものでなければならない。もしそれがなければ、結果を出すための2時間のウィンドウがあるにもかかわらず遅れてしまい、結局トラックはすでに出発しているという、非常に馬鹿げた問題に直面することになる。つまり、すべてが確実に対処されている仕組みが必要なのだ。
同様に、透明性のあるアップグレードも求められる。これがExcelの素晴らしさだ。Excelのメンテナンスについて考える必要はない。Microsoftは数十年前に血の契約を交わした。つまり、もしあなたがExcelスプレッドシートを作成したならば、市場に登場する次世代のExcelは必ずあなたのスプレッドシートをサポートするという約束だ。最も驚くべきは、現代のExcelを見ると、既に存在しなくなった競合他社のExcelフォーマットさえも多くサポートしていることである。Lotus Notesで作成されたスプレッドシートであっても、今なお読み取ることができる。すなわち、透明なアップグレードに関するMicrosoftの価値提案は、あなたが作り上げたロジックが永遠に機能するという点にある。確かに、今後数十年にわたってExcelは改善され続けるが、心配する必要はない。これはPython 2からPython 3への移行で見られた悪夢とは全く異なり、あのときは10年もの時間を要した。つまり、Pythonは多くの点で優れているが、最悪のパンデミック、最悪の関税、最悪の緊急事態の際にアップグレードが行われることを想像してみてほしい。アップグレードのために6か月ものダウンタイムを余儀なくされる余裕は、サプライチェーン最適化には到底許されない。
では、サプライチェーン向けにエンジニアリングされた何かを実際に検討するとしたら、どうなるだろうか？それこそが次回の講義のテーマである。
そして、サプライチェーンはIT部門の一部ではない。プロダクト指向の提供と言ったとき、ソフトウェアは目的ではなく手段に過ぎないという意味であり、たとえばMicrosoftのようにライセンスや料金でソフトウェアを販売することはない。この講義で私が描いているビジョンでは、ITはセキュリティ、バックアップ、コアインフラ、ネットワーク、企業レベルでのデータ管理と同期、そしてあらゆるガイダンスやコーチングといった、コアなITプラクティスに責任を持つ。
しかし、本質はサプライチェーンが自らサプライチェーンに関する意思決定を所有すべきだということだ。彼らは、サプライチェーンの意思決定を生み出す全ての仕組みをも所有するべきであり、これが彼らの本来の役割となる。前回の講義で述べた通り、サプライチェーンサイエンティストとは、コードが生み出す数値的な意思決定を所有する者のことである。これは、意思決定を自動生成するシステムではなく、1人または複数のサプライチェーンサイエンティストによって記述された数値レシピであり、彼らが共同でその数値的意思決定を所有するのだ。彼らはそれを自らのものとし、サプライチェーンの責任は、会社全体の意思決定が一貫していることを保証することである。たとえば、プロモーションが行われている場合や大規模なマーケティングプッシュがある場合、サービス提供に間に合うように物事が生み出される必要がある。既にストックアウト寸前の状況で何かをプッシュし、在庫も製造能力もサービス提供のキャパシティもないままマーケティング費用を費やすような壊滅的な事態に陥りたくはない。
つまり、焦点が全く異なる二つの部門が存在する。私の理想とするIT部門のビジョンでは、IT部門はチケット処理を行う部門ではない。それはそのようなものではなく、むしろコアインフラの管理を担う。常にシームレスに機能し、Wi-Fiが正常に動作しているときのように、意識する必要すらない。Wi-Fiに気を配るのは、動作していないときだけだ。優れたIT部門は、インフラをすべて提供し、その存在に気付かせないほどシームレスに動作する。メールが完璧に届くのと同じように。それが優れたコアITの本質である。そして、ITはあなたの元に来て、実践を確立する手助けをする存在である。プログラム可能なロジックは少し難しいので、プログラミングを少しでも向上させるためのコーチングはどこで受けるのか？答えは、IT部門である。彼らは「あなたのためにコードを書く」のではなく、「あなた自身が実装できるようにコーチングする」ために来るべきだ。いくつかの概念の説明や、通常よりも技術的な部分のサポートを行う。時には、偶発的な複雑性が生じるが、その際にITがサポートする。しかし、根本的には彼らはあなたの代わりに作業を行うのではなく、メンターやコーチとして、誰も会社全体をランサムウェアのリスクやシステム全体のITリスクに晒すような致命的なミスを犯さないようにする役割を担う。
一つの試金石として、もしITとサプライチェーンのやり取りが、仕様や要件を列挙した文書を介して行われるならば、これは両部門間に良好な関係を築く適切な方法ではない。良好な関係とは、実際に会社に価値をもたらすものであるという意味だ。
結論として、伝統的なサプライチェーン管理側には二つの課題がある。彼らはExcelスプレッドシートでかろうじてプログラミングを行っており、それがすでに一種のプログラミングであると最初は気付いていなかったかもしれない。恐怖を克服しなければならない。明日の世界、つまりあなたの部門がソフトウェア製品のように動作する製品を提供する責任を担うという大きな変革に備える必要がある。そうだが、正しいツールさえあれば対処可能である。確かにプログラミングは伴うが、根本的にExcelよりも劇的に難しいというわけではない。再び言うが、課題はツールの技術的な側面ではなく、本質的にはサプライチェーン自体の複雑さにある。問題が難しいのは、ツールが扱いにくいからではなく、もともと複雑なサプライチェーンが存在するからである。
データサイエンティスト寄り、またはIT寄りの方々にとって克服すべきは、過信という問題です。私自身を含め、何度も何度も、プロトタイプを実運用に移す能力に過信しているデータサイエンティストを目にしてきました。これは厳しい問題であり、サプライチェーンは最も驚くべき形であなたの前で崩壊する可能性があります。数年前、ヨーロッパ有数の自動車部品Eコマース企業と取引を始めた際の逸話を思い出します。当社は需要予測技術を使い、部品の補充を扱い、補充の提案を行い、車の部品を供給していました。しかし翌週、我々の予測はすべて2倍の誤差であったのです。需要が倍増していたのです。原因は、競合するナンバーワンの企業が同時に複数国へ進出する決断をしたためでした。まさに我々が予測を開始した瞬間、競合の一社が全国のテレビに出演し、オンラインでサービスを放送し始めたのです。興味深いのは、私のクライアントはそのことに全く気づいておらず、彼らのSEO（検索エンジン最適化）の結果の方が優れていたという点です。基本的に、人々は競合のテレビCMを見るものの、競合の名前を自然に覚えず、「car parts」とGoogleで検索し、結果的にクライアントのウェブサイトにたどり着いたのです。我々は、Lokadの優秀さを示すため、開始初週に2倍の誤差を出し、「一体全体何が起こっているのか？」と頭を抱えることになりました。需要が倍になっても、すべてが倍になるわけではなく、あるものは10倍になり、多くのものは全く影響を受けないのです。
つまりそのようなものであり、迅速に反応できることが重要です。要は、恐れと過信の問題なのです。お時間いただき、誠にありがとうございました。
では、チャットを通して質問を拝見しましょう。
Question: 明日もっと必要な場合、どのサプライヤーに追加発注を行うかをソフトウェアが判断できますか？たとえば、オーストラリアのオフィスで使われる200グラムのイチゴパックでは、同日に10社のサプライヤーが同じ製品を配送センターに届けるかもしれません。
絶対に可能です。そしてここでは、サプライチェーン管理とサプライチェーン最適化という二つの側面を区別する必要があります。サプライチェーン管理側は、EDIを含む全ての data pipelines が整備され、人の介在なくサプライヤーに電子発注を送ることができる状態を指します。すなわち、端から端まで電子的な橋が架けられているのです。しかしながら、最適化側では、日中連続して動作し、ある時点で管理側に「この注文を実行してください」と通知できるソフトウェアが必要になります。そして、ITが管理する管理側は、その注文が完全に実行されるよう確認するのみです。これは純粋なトランザクションの問題であり、もはや知能は介在しません。「この数量」という注文を受け取った時、その数量を生成する際に、対象となるサプライヤーの正確なリスト、在庫の有無、そして競合するサプライヤー間での適切な選択など、全ての制約に準拠しているかどうかを確認するのは最適化側の責任となるのです。多くの要素が絡むかもしれません。絶対にその通りですが、我々はサプライチェーン管理側の単純な実行部分（トランザクション処理）と、追加発注を判断する際の最適化要素を文字通り明確に分けなければなりません。
Question: あなたは今、eスポーツ・ワールドチャンピオンシップと競合していることをご存知ですか？
いいえ、現時点でそれらのeスポーツ大会と競合しているわけではありませんが、とてもクールな存在です。ちなみに、LokadではDota 2を頻繁にプレイしており、経営陣も参加しています。一部の従業員はLeague of Legendsをプレイしたがりますが、CEOとしては断固反対しています。
Question: 多くの企業がそもそもERPやWMSを持たず、管理部門がサプライチェーン最適化に取り組んでいるのを見かけますが。
もちろんです。初日からサプライチェーン最適化は避けられず、その決断を下さなければなりません。サプライチェーン最適化は、あらゆる種類のサプライチェーン管理ソフトウェアが存在する以前からありました。60年前、ソフトウェアがなかった時代でも、人々は意思決定を行っていたのです。すなわち、サプライチェーン最適化はすでに存在しており、人々は紙とペンでその作業を行っていました。最も初期のサプライチェーン理論、ウィルソン・フォーミュラ（別名 EOQ 式）を見ると、それは一世紀以上前のものであり、明らかにソフトウェアよりも以前のものなのです。ですから、組織内にソフトウェアがあるか否かにかかわらず、サプライチェーン最適化は初日から行われるべきものなのです。
確かに適切なITシステムは必要ですが、それは全く異なる考え方です。サプライチェーン管理とは、データ入力などの単調な作業を非常によくこなすことであり、バーコードなどのサポートがあっても良いのです。しかし、それは単にデータを表現するための非常に平凡な作業に過ぎません。問題は、人々がサプライチェーン管理とサプライチェーン最適化の両方を同時に行うシステムを求めるため、結果として過剰に複雑で、通常は非常に不具合が多く、アラートや例外処理といった望ましくない機能を持つ製品になってしまうことです。この件については後の講義で詳しく触れます。
基本的に、今日ではWMSやERPの導入が未実施であれば、わずか数週間で導入可能です。既に導入済みであれば、そのシステムと意思決定を切り離すことができれば数ヶ月で済む場合もあります。
Question: 経営陣はいつになれば、単に情報を追跡する段階からサプライチェーンの意思決定の最適化へ移行し、最終的にサプライチェーン最適化に注力すべき時期だと気付くのでしょうか？
まず最初に、そもそも二つの問題が存在し、同一のソフトウェアが両方の側面に対応できないことに気付く必要があります。これが大きな誤解であり、ソフトウェアベンダーたちはこの点で非常に混乱を招いています。大手ERPベンダーを見ると、彼らのメッセージはサプライチェーン最適化に関するものですが、実際に提供しているのはサプライチェーン管理側の機能だけです。管理側はAIや実際の知能を持たず、あまり魅力的ではありません。ソフトウェア界隈ではこれをCRUDアプリ（作成、読み込み、更新、削除）と呼んでいます。ERPは単にリレーショナルデータベースから行を作成、読み込み、更新、削除するための巨大なCRUD画面の集合体に過ぎません。簡単に言えば、ERPは様々なエンティティのための数千のテーブルの集まりであり、論理的にグループ化できる各エンティティごとに1、2枚の画面しか存在しません。ですから、経営陣に関する質問に戻ると、もしあなたがマネージャーであれば、ERPベンダーのパンフレットを読み、「このシステムはサプライチェーンを最適化する」と言われるでしょう。しかし、答えは違います。実際に行われるのは、生産性の向上とサプライチェーンの正確な経理管理です。これは、盗難の大幅な減少、ロス、品物の紛失、及び倉庫でバーコードを用いることでの生産性向上など、既に多くの付加価値をもたらしています。ERPやWMSが提供する価値を否定しているわけではありません。それは非常に大きいものですが、サプライチェーン最適化の面においては対応していないのです。例えばWMSはその設計上、倉庫に焦点を当てており、クライアントやサプライヤーを含む全体のサプライチェーンには対応していません。特定のロケーションにフォーカスする設計となっているのです。
Question: PythonからEnvisionへスムーズに移行する、あるいはそれらを連携させる方法はどのようなものですか？
歴史的に、いくつかの状況下でこれらを連携させた経験があります。ご参考までに、EnvisionはLokadが設計したドメイン固有のプログラミング言語であり、サプライチェーンの predictive optimization のために特化して開発されています。次の講義では、実際のコードを用いてEnvisionのデモを行い、私の話の内容をよりよく理解していただけるようにします。
歴史的には、創業当初、Envisionの機能が非常に限定されていたため、PythonとEnvisionを併用していました。多くの機能が不足していたため、多くの場合Pythonに頼らざるをえなかったのです。しかし年々、Envisionの機能は徐々に拡張され、Pythonコンポーネントの必要性は次第に解消されていきました。これはPythonコンポーネントだけでなく、Airflowのように連携させるべき一連のツールも含みます。
ちなみに、Envisionの構文はあえてPythonに合わせて設計されています。Pythonプログラマーに反感を買わないよう、もしPythonに精通していれば一週間でEnvisionを習得できるように、という意識的な選択をしたのです。微妙かつ深遠な違いはありますが、構文面では多くの点で共通しています。Pythonにはシンプルさや純粋な設計など多くのメリットがあります。たとえ、Pythonがすべての要求を満たさず、生産環境で回復不能な重大な問題を引き起こすと主張しても、Pythonに長所がないという意味ではありません。そう言っているのではなく、私自身、Pythonには多くのメリットがあると信じています。改めて申し上げますが、ここで議論しているのは、生産環境におけるサプライチェーン運用という非常に特化した問題についてです。
Question: どのようにしてクライアントに自社のERPが何も最適化していないと理解させますか？
これは非常に難しい問題です。率直に言えば、最悪のケースは見込み客から「我々のレガシーERPは何の価値も提供しておらず、今後はサプライチェーン最適化を実現する次世代ERPに移行したい」と言われる状況です。これは私にとって非常に厄介な状況で、クライアントには、求めているのはひとつの製品ではなく二つの製品だと説明しなければならないからです。すなわち、ERPを置き換えて管理側をより良く処理するものと、最適化を実現するものの二つです。
これらのレガシーERPについて考えると、特に旧式のIBMメインフレーム上のコマンドライン端末を備えたAS/400製品には、大いに敬意を表します。管理面では、通常非常に適切な役割を果たしています。クライアントが本当に求めているのは、コマンドラインではなくウェブインターフェースかもしれませんが、それが現場のチームの生産性を向上させるのでしょうか？私はそれに疑問を呈します。テキスト端末を用いたコマンドラインは、非常に迅速かつ生産的で、集中力をそがれることがない場合もあるのです。
このように、競合他社が押し付けるナンセンスを解消しなければならないため、非常に困難です。さらに、ERPがサプライチェーンを最適化しないこと、そしてAIやブロックチェーンなどは存在せず、あくまで統計モデルの分類に過ぎないことを説明しなければなりません。残念ながら、この段階でほとんどの見込み客を失ってしまうのです。これが、私がこの講義を行っている主な理由の一つであり、なぜ問題を私の見方で捉える必要があるのかを説明するのに何時間もかかるのです。
Question: 確率的需要分布を持つ複数製品の計画の複雑さに対処するためのプラットフォームの推奨は何ですか？
ええ、もちろんLokadです。ただし、私自身がLokadのCEOであり、多くの株式を保有しているため、意見に利益相反があることはご理解ください。私は深く、Lokadがあなたにとって必要なプラットフォームであると確信していますが、同時にそれが私自身が所有し運営している会社であることもご理解いただければと思います。その点に関しては、できる限り客観性を保つよう努めます。
ちなみに、Lokadは文字通り、確率的需要分布に対処するために設計されており、それだけに留まらず、確率的なリードタイム分布、確率的な返品分布など、さらなる要素にも対応しています。あらゆる不確実性を考慮に入れ、あらゆる可能な未来を確率とともに捉える必要があるのです。需要は非常に重要な要素であり、通常は最も重要ですが、それだけが全てではありません。
すべての質問にお答えしたと思います。何か見落としていないか確認しますが…追加の質問はありません。それでは、この講義をご覧いただきありがとうございました。来週も同じ曜日、同じ時間にお会いしましょう。またお会いできるのを楽しみにしています。さようなら。
参考文献
- Joel on Software: ソフトウェア開発者、デザイナー、マネージャー、そして幸運にもまたは不運にも何らかの形で彼らと関わるすべての人々に興味を持たれるであろう、多岐にわたる時に関連する事項について - Joel Spolsky著, 2004
