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 サプライチェーンはIT部門の一部ではない
01:03:19 結論として、克服すべき2つの課題がある
01:07:04 次回の講義と聴衆からの質問
説明
量的供給チェーンの取り組みの目的は、定型的な意思決定（例：在庫補充や価格更新）を自動化するソフトウェアアプリケーションを提供するか、またはその改善を図ることにあります。このアプリケーションは、エンジニアリングされるべき製品と見なされます。供給チェーン理論は、企業をサプライチェーンパフォーマンスへ導くアプリケーションを提供するのに役立ち、その生産に伴うあらゆる制約に適合するようにします.
全文書き起こし
皆さん、こんにちは。このサプライチェーン講義シリーズにご参加いただき、誠にありがとうございます。私はジョアンネス・ヴェルモレルで、今回「サプライチェーン最適化のための製品指向デリバリー」についてご紹介します.
まず、ここでいう「製品」とはソフトウェア製品のことです。現代のエンタープライズソフトウェアの内部構造を調査する機会に恵まれた方なら、その体験はなかなかのものだったでしょう.
H.P.ラヴクラフトの作品に親しんでいる方なら、いくつかの不穏な類似点に気づくでしょう。ラヴクラフトは一連の小説を執筆しており、その繰り返されるテーマの一つは禁断の知識という概念です。宇宙は理解できないのではなく、理解可能であるにもかかわらず、人類を守る唯一のものは無知であるということです。無知は問題ではなく、むしろ私たちの心が耐えられないほど恐ろしい宇宙から守ってくれるのです。この考えは多くの現代ゲーム、特にロールプレイングゲームに取り入れられており、従来のヒットポイントに加えてキャラクターが精神力ポイントを持ちます。もし精神を損なう行動をとれば、そのポイントは失われます。エンタープライズソフトウェアにおける挑戦は、精神を保ちながらそれを構築することであり、これは企業に付加価値をもたらすための要件の一つです。では、進めましょう.
なぜ製品、特にソフトウェア製品なのでしょうか？ 従来のサプライチェーンの運営方法を詳しく見てみましょう。昔は多くの人々が現場で物を動かし、荷物を仕分け、車両を運転し、あらゆる手作業をこなしていました。生産現場や店舗にも多くの人が関与していました。しかし、過去数十年でブルーカラーの労働者数は着実に減少しており、現在では生産工程が大幅に自動化されています。なお、繊維産業など、すべてを自動化することが困難な産業は、人件費の低い地域へと移行しています。実際、原始的な人力の需要は大幅に低下しています.
自律走行車の導入を見据えると、現場で肉体労働を担うブルーカラーの従業員よりも、エクセルのスプレッドシートでサプライチェーンを管理するホワイトカラーの従業員が多くなるという、非常に奇妙な状況に陥るでしょう。これが私が「事務作業」と呼ぶものです.
もう一つ特筆すべき点は、サプライチェーンが少なくとも過去20年にわたり多くの企業でデジタル化されていることです。サプライチェーンにソフトウェアを新たに導入するのではなく、既にソフトウェアによって駆動・運営されているのです。しかし、これらのシステムにおける人間の役割を考えると、人間は平均的なサプライチェーンシステムにおいて、事実上「人間の共同プロセッサ」として活用されています。通常のCPU（機械のプロセッサ）が対応できない特定の作業が存在するため、その全体のタスクが人間に委ねられているのです。単純な数値レシピ、例えばABC分析やmin-max在庫管理といった手法と連携する中で、人間は結局、一日中火消し作業に追われ、標準の枠組みに収まらない例外や条件に常に対処しなければなりません.
コストの観点から見ると、これはすべて運用費用（OpEx）です。企業が日々行うあらゆる日常的意思決定を処理するために、膨大な数の事務職員に毎日賃金を支払わなければなりません。例えば、何を購入するか、在庫をどこに配置するか、ある倉庫から店舗へ1単位を移動するかどうかなど、多くのルーチンな決断が含まれます。システムが自動的に生成した素朴な判断の不備に対処するため、人間はその都度、意思決定と火消し作業を行っているのです.
本日の提案は、運用費用（OpEx）から資本支出（CapEx）へ移行するというものです。これが製品指向デリバリーの核心であり、私たちは資産を構築したいのです。なぜなら、それが資本主義的だからです。今日、世界の最も利益率の高い100社を見渡せば、その半数が利益面でソフトウェア企業であり、彼らは前払いの投資によって、僅かな追加投資で付加価値を生み出す装置や成果物を持つ、超資本主義的企業の本質を体現しているからです.
前回の講義に戻りますが、経営陣が再びコントロールを取り戻すためにはロボット化が必要です。自動化と人間は協働すべきであり、人間が単純なmin-maxのような在庫ポリシーの不備に対応するためにいるのではありません。むしろ、価値を付加し、数値レシピを改善し、戦略的判断を下す役割が求められます。昔のIBMのモットーに「機械は働き、人は考えよ」というものがありました—これが今回のプレゼンテーションに込めた考えです。私たちはサプライチェーンを資本主義的な資産へと変革したいと考えており、そのためにはサプライチェーンをソフトウェア製品を提供する機械へと転換する必要があります.
この製品は実際に何をするのでしょうか？ 実は、非常にシンプルなこと、すなわち意思決定を行います。恣意的で無限に広がる決断ではなく、生産品目、仕入先から購入する単位数、そしてある場所から別の場所へ移動する単位数といった、ありふれた日常的な判断です。一見すると、サプライチェーン管理には多くの意思決定が必要と見えますが、実際に業務を精査すると、どんなに複雑なサプライチェーンでも、毎日必要となる意思決定の種類はせいぜい数十種類に過ぎません。これは圧倒されるほどの数ではなく、機能数としても合理的です。興味深いことに、これらの決定はほぼ排他的なため、分割統治的なアプローチには限界があります。一度、仕入先から100単位を購入することを決定すると、別のシステムが200単位を購入すると決める余地はありません。最終的には、購入および移動する単位数について明確な判断を下す必要があるのです。これらの決定は離散的で範囲が限定され、かつ排他的です。私たちが求めるのは、毎日完全自動で発注判断を生成するソフトウェアです.
ソフトウェアに関してしばしば十分に理解されていない概念の一つに、規模の不経済というものがあります。多くの人が規模の経済性に馴染みがある一方で、ソフトウェアでは、機能をわずか25%追加するだけでコストが倍増する場合があるのです。この概念は、小規模なスタートアップが大企業に対抗できる理由を説明しています。すなわち、スタートアップはごく一部の機能に集中することで、製品を市場に投入するコストを大企業よりも大幅に低減できるのです.
規模の不経済という考えを念頭に、私たちはサプライチェーン最適化製品を自社開発するか、購入するか、または別のアプローチを取るかを決定しなければなりません。もしベンダーから製品を購入することを選ぶなら、市場に対応するためにそのソフトウェアベンダーが提供すべき機能を慎重に検討する必要があります.
では、既製のサプライチェーン最適化製品の購入について検討してみましょう。これらのスライドでは、取り組むべき課題のごく一部についてレビューを行っています。私自身、2008年にLokadを立ち上げた際、サプライチェーン最適化よりも予測に重きを置いた小規模なソフトウェア製品から始めた経験があり、クライアントと仕事をする中で、欠如している機能や能力の多さを痛感し、次々と新たな要件が浮かび上がるという終わりなきプロセスに直面しました.
次に、主要な機能を見ていきましょう。まず、B2C企業とB2B企業は、サプライチェーン管理において全く異なるパターンを示します。例えば、B2B企業は通常、顧客数が少ない一方で、その顧客は非常に大きな数量を発注するため、企業の売上の大部分を占める単一顧客を失うリスクといった、異なる種類のリスクが生じます。さらに、B2B2CやB2B2Bのような、より複雑なビジネスモデルも存在します.
店舗、倉庫、生産施設など、カバーすべきさまざまな種類の拠点を考えてみてください。拠点ごとに固有の課題があり、例えば店舗はRFID技術があっても在庫の不正確さが発生しやすいのは、顧客が製品を自由に移動させるためです。一方、倉庫や農場、鉱山などの生産現場は、それぞれ特有の問題や生産収率の不確実性を抱えています.
サプライチェーンネットワークは、シングルエシェロンからマルチエシェロンシステムまで、さまざまなレベルを持ちます。エシェロンの数が増えるにつれて、管理の複雑さは飛躍的に増加します。また、ネットワークトポロジーも重要な要素です。ツリートポロジーは、いくつかの生産拠点から複数の倉庫へ、そして多数の店舗へと配送される古典的な前方サプライチェーンのパスを示します。しかし、ひとつの店舗が複数の倉庫からサービスを受けるような、有向非巡回グラフ（DAG）などの他のトポロジーも存在します.
つまり、グラフ理論上の単なる木構造に留まらず、再接続が起こり得るものの、それでも基本的には前方への流れです。しかし、複数のサプライヤーが存在する場合、DAGでも同様の現象が発生し、修理が絡む場合にはサプライチェーンのグラフにループが生じることもあります。例えば、鉱業や航空宇宙産業では、修理可能な設備により無数の修理ループが存在します.
さて、在庫そのものは単一の性質を持つわけではなく、多様性に富んでいます。たとえば、「私にはSKUsがあって、それだけだ」とは言えません。なぜなら、まず原材料はグラム、キログラム、または体積といった数量で計測されるものです。次に、ほとんどの場合、綺麗に区分された単位があります。しかし、製薬業界や食品業界のように、ロットごとに特定の有効期限が設定される在庫も非常に多く存在します。さらに、各単位に固有のシリアル番号が付与された、完全にシリアライズされた在庫も存在し、サプライチェーン最適化の観点からは、これらは全く別の問題となるのです.
そして当然ながら、マーケットプレイスに関するあらゆる問題も存在します。Lokadでは、ありとあらゆる状況下のクライアントがおり、第三者のマーケットプレイスで販売する場合、自社のマーケットプレイスを運営する場合、あるいはその両方を行う場合など、販売できなかった在庫を処分するために二次的に利用する場合など、さまざまなシナリオが見受けられます.
例えば、注文とは何かを一度考えてみてください。即時に購入してその場で所有権が移るスポットオーダーがある一方、「購入するが、すぐには納品せず、1か月後に納品してほしい」という注文も存在します。もちろん、サプライチェーン最適化の観点では、特定の日に特定数量を納品する必要があらかじめ分かっている場合、その予測は不要であり、全く異なる問題となります.
そして、構成可能な注文も存在します。例えばオンラインでコンピューターを購入する際、メモリ容量、ハードドライブサイズ、オペレーティングシステムの種類、設定する言語、キーボードの種類などを選択できる場合です。このような巨大なコンフィギュレーターは、状況を大きく変え、選択肢やサプライチェーン最適化問題へのアプローチ方法を全く異なるものにします.
たとえ価格についてであっても、単位あたりの価格が一律で、非常にシンプルかつ直線的である場合もありますが、それだけではありません。たとえば、10単位購入すると割引が適用される「プライスブレイク」があったり、ある種の製品や特定の条件にのみ適用される割引を、loyaltyプログラムで提供したりすることができます。また、B2Bの世界では、非常に頻繁に交渉される要素も存在し、膨大な商品が取引される中で、通常のカタログ価格が設定されています。しかし、重要な顧客に対しては、販売業者がリベートを提供する場合もあり、これが一般的なやり方となっています。要するに、まだほんの数分しか話しておらず、核となる部分だけしか触れていません。必須の機能にさえまだ手を出していないのです。だから、ちょっと立ち止まって、サプライチェーン最適化を実現するための既製のエンタープライズソフトウェア製品がどのようなものになるのかを想像してみてください。カバーすべき機能の数は文字通り常軌を逸しており、それらをひとつのモノリスにまとめようとする過程で、正気を失いかねません。結局のところ、宇宙が理解不可能というのではなく、むしろ宇宙の裸の真実に触れると正気を失ってしまう、ということなのです。
さて、ここで大きな問題があります。サプライチェーン管理とサプライチェーン最適化を区別しなければならないのです。これは以前の講義のどこかで既に触れた違いですが、管理面と最適化面との間には大きな混乱が存在しています。管理は簿記やワークフローのサポート、そして主にデータ入力プロセスに関するものです。ここまで説明した全ての要素を表現しようとすると非常に広範囲になりますが、不可能ではありません。「肥大化した」ERPならそれが可能です。はい、最終的には1万個のテーブルができあがり、見た目はかなり醜くなりますが、実現可能なのです。しかし、誤解しないでほしいのは、ERP（正確には、エンタープライズ・リソース・マネジメント、ERMと呼ぶべきもの）は、実際に大したことはしないということです。ただ単にそれらの事象を記録しておくだけなのです。つまり、MOQやプライスブレイク、店舗、倉庫といった膨大なエンティティを保有しますが、特に知的な動作は要求されないのです。単にデータを反映する地味なデジタルの対応物として、システムにデータを入力できるようにするだけです。
これは、「機能が4分の1増えるとコストが倍になる」という法則に少しだけ例外を認めることで可能になるのです。ここで一つ、あまり言及していなかったことがあります。それは、機能が完全に分離されている場合にはこの法則が適用されないということです。機能同士が相互作用しなければ問題はなく、規模の不経済という呪いに縛られることはありません。データ入力の観点からは全く問題ありません。MOQを操作するユーザーインターフェイスと、ネットワークに新しい店舗を追加するための仕組みが連動している必要はなく、これら二つは完全に分離してもかまわないのです。
しかし、サプライチェーン最適化となると話は別です。MOQが存在すれば、それは発注の頻度、倉庫から店舗への配送頻度などに深刻な影響を及ぼします。影響は計り知れず、最適化を実現するためには全ての要素を一つのシステムに組み込む必要があり、そこで物事は崩壊してしまうのです。
管理側では、ひょっとすると製品として成立する可能性があります。しかし、サプライチェーン最適化に関しては、実際にはそうはいかないのです。見かけ上はできるふりをすることは可能でも、実際には不可能です。例えば、Lokadは、もともと予測型サプライチェーン最適化に特化した供給予測企業ではなく、むしろ「サービスとしての予測」を提供する会社としてスタートしました。2008年のLokadブログに戻ると、最初は時系列予測から始めたのですが、これはまったくの的外れなものでした。それでも、そこからスタートしたのです。たとえ全体の問題のほんの一部に過ぎない時系列予測でさえ、手に負えないのです。これが、私が12年以上この業界に身を置いてきた結論です。
もしソフトウェア製品の製造という特定の世界に立ち戻ると、そこには非常にユニークな側面があります。自らソフトウェアエンジニアとして訓練を受け、成功している大手ソフトウェア企業がどのようにソフトウェアを生み出しているかに精通していない限り、その仕組みについてはほとんど知識がないのではないでしょう。実際、これは非常に特殊な世界であり、多くの直感に反する側面が存在します。特に、古典的な機械工学やマーケティングのマインドセットを持つ伝統的な企業は、ソフトウェアがどのように動作するのかを理解するのに非常に苦労します。
これらの側面については今後の講義でより詳しく扱いますが、私が特に好きな一冊の本があります。元Microsoft社員で、初期のMicrosoft Excelのチームに所属していたJoel Spolskyによるもので、彼はStack OverflowやTrelloの共同創設者でもあります。2004年、私がまだ学生だった頃に、彼の本とブログを読みました。その本のタイトルは「Joel on Software」で、成功するソフトウェアビジネスの運営がどのようなものかをユーモラスに理解させてくれます。この業界外の多くの人々が期待するものとは全く異なる内容です。動画の説明欄にこの本の詳細も追加する予定です。
しかし、念頭に置いておくべきは、サプライチェーン最適化は平均的なソフトウェア製品ではないということです。通常、平均的なソフトウェア製品に対処する場合、たとえばソーシャルネットワークでは、投稿される憎悪のこもったコンテンツといった敵対的な行動が多数発生する、といった状況があります。しかし、Microsoft WordやExcelのような伝統的なエンタープライズソフトウェアの場合、適切なデザインさえ整えば、緊急事態は皆無なのです。伝統的なソフトウェア製品では、何年もかけてデザインや製品を洗練させることができるのです。これは長期的な投資であり、数十年先を見据える必要があります。開発ペースを急ぐ理由はありません。しかし、サプライチェーン最適化はそうはいきません。常に何かしらの事態が発生し、環境も非常に厳しいため、選択の余地はありません。
パンデミックやランサムウェアのような極端な事態が発生し、ネットワークの半分が停止してしまうこともあり得ます。その状況下では、まだ利用可能なキャパシティを最大限に活用するための賢明な判断が必要です。悲劇的な事故による艦隊の地上待機、関税のような政治的動きによる戦略の混乱、またはカリフォルニアやオーストラリアで発生した火災や熱波のような自然災害も起こり得ます。こうした事象が発生した際、あなたは数時間以内に対応できなければならないのです。
ソフトウェア製品があっても、変化を起こす必要があり、それをプログラム的に実現したいのです。ソフトウェア資産を提供するという考えでは、少人数のチームがそのソフトウェアを動かし、それがサプライチェーンを加速させます。全日体制で火消し作業を行う事務員の大軍がいるわけではありません。たとえ多くの事務員がいても、彼らを訓練しなければならず、全く予想外の事態が発生した際には、その状況に対応できる訓練を受けた軍勢がいないという事態に陥ります。私の経験では、管理しなければならない人が増えれば増えるほど、何かを成し遂げるまでに長い時間を要するのです。
ほんの数日前のことですが、悪天候により1,800個以上のコンテナを失った貨物船がありました。こうした事象は避けられるものではなく、製造業のように生産現場がすべて厳密に管理されているわけではないサプライチェーンでは、自然現象などの制御不可能な要素に常に晒されているのです。制御できない数多くの力が働いている以上、驚くような事態に対処できる体制を整えておく必要があります。驚きは必ず起こるという前提で、数時間以内に対応できるシステムを持つことこそが、現実的に問題に取り組むための本質であると言えます。
さて、サプライチェーン最適化のためのソフトウェアの要素として、まず第一に必要なのは、多種多様なデータソースを表現できる柔軟なデータストレージです。表現したい事象が非常に多岐にわたるため、構造と多様性に富んだ非常に柔軟なものが求められます。
第二に必要なのは、プログラム可能なロジックです。ここに戻ってきますが、もしプログラム可能なロジックがなければ、これらすべての問題にどう対処するのでしょうか？すべてをどうやって結びつけるのかという問題です。既製品としてすべてがあらかじめプログラムされている製品を買うわけにはいきません。
次に、柔軟なユーザーインターフェイスが必要です。というのも、状況に応じて問題の見方が大きく異なるからです。KPIは企業ごとに全く異なるため、どのような形でも数値を提示できる柔軟なユーザーインターフェイスが必要となります。そうでなければ、大きな制約となってしまいます。
また、コラボレーション機能も必要です。サプライチェーンは本質的にチームワークで成り立っており、多くの人々が関与し、分散しているため、コラボレーション機能は不可欠です。
最後に、そしておそらく議論を呼ぶ点ですが、訓練を受けたソフトウェアエンジニアでなくても利用できるプログラム可能な機能が欲しいのです。これはいくつかの理由で重要です。まず第一に、熟練したソフトウェアエンジニアは就職市場で非常に少なく、採用競争が激しいという点です。第二に、有能なソフトウェアエンジニアになるには莫大な努力と献身が必要であり、同時にサプライチェーン専門家であることは極めて困難だからです。
両分野に精通した人材は非常に稀であり、プログラマーと弁護士、またはプログラマーと医師という組み合わせでも同様の状況です。もちろん、こうしたスキルセットを持つ人が全くいないというわけではありませんが、大企業として毎年大量に、しかも確実に採用できるかというと疑問です。Lokadを10年にわたって運営してきた私の経験上、これはうまくいかないのです。
プログラム可能なものが求められる一方で、プログラミングに関してはプロのソフトウェアエンジニアである必要はありません。覚えておいてほしいのは、サプライチェーンの知識を持った担当者が必要だということです。そうすることで、ITにチケットを切って提出するのではなく、数時間以内にシステムにプログラミングの修正を加えることができるのです。もしその方法でなければ、問題解決に数週間もかかってしまいます。では、一体どのようなソフトウェアがこの問題を解決できるのでしょうか？
答えは、Excelです。見た目は美しくなく、最新のソフトウェアの頂点とは感じられないかもしれませんが、Excelは十分に役割を果たします。すべての要件を満たしているのです。
柔軟なデータストレージ？はい、ある程度は、Excelにはあらゆる種類のデータを大量に格納することができます。プログラム可能なロジック？もちろん、Excelは完全にプログラム可能です。柔軟なユーザーインターフェイス？バーチャートやライングラフなど、データを表現するさまざまな方法が用意されており、非常に柔軟です。洗練されているとは言えないかもしれませんが、その柔軟性は大いに役立ちます。
コラボレーション機能に関しては、多少粗削りです。オンライン版のExcelも存在し、多少は改善されているものの、本質的にはスプレッドシートを共有するにとどまります。コラボレーション機能が不足している問題は、単にデスクトップアプリであるということではなく、複雑なシートを同僚が作成してしまった場合に、その内容を理解するよりも最初から作り直す方が容易であるという、スプレッドシートに内在するマインドセットの問題なのです。そのため、強力な協力作業には限界があるのです。
しかし、Excelは非開発者でも完全に扱える上、複雑なタスクにはVisual Basic for Applicationsが利用可能です。こうした必要要件をすべて満たしているため、Excelが多くのサプライチェーンで運用上成功している理由が大いに説明できると私は考えています。
私の経験では、世界中のサプライチェーンの大部分は、最小規模の企業から大企業まで、エンタープライズソフトウェアに一銭も投資していない企業から、サプライチェーン最適化のために何百万ドルも投資している企業まで、Excelによって駆動されています。ごくわずかな例外はあるものの、ほとんどの場合、Excelが利用されているのです。場合によっては、他のソフトウェアでmin-maxの設定を見直すためにExcelが使われることもありますが、そうした設定の保守はExcelを扱う担当者に委ねられています。
今日のサプライチェーンの世界はExcelが主導しており、これは決して偶然の結果ではありません。スプレッドシートはその根幹において、正しい多くの問題に取り組んでいるのです。他の多くの選択肢は、プログラムができない場合にデフォルトで失敗してしまうという弱点を抱えているため、いくら優れていると謳われても、実際の緊急事態に直面した時には頼りにならないのです。多くの場合、唯一結果を出せるのはITチームかもしれません。最初はチケットを切って辛抱強く待つかもしれませんが、三ヶ月も経てば、誰もが迅速さを求めてExcelのスプレッドシートに戻るでしょう。Excelは最終的な解決策ではありませんが、いかなる優れた代替手段を導入するにしても、必要条件をすべて満たさなければならないのです。
何かをより良くするにはどうすればいいか？ 多機能なデータストレージという観点では、Excelは優れているが非常にスケーラブルとは言えない。現代のExcelバージョンでも100万行を扱えるとはいえ、何百万行もの処理は問題となる。スケールに応じた操作ではすぐにパフォーマンスの問題が発生する。Excelでプログラム可能なロジックを実現することは可能だが、それは非常に繊細で壊れやすい。誤ってスプレッドシートにミスやバグを混入させると、デバッグして問題の原因を突き止めるのは悪夢と化す。同じロジックが無限に複製され、何千ものコピーができるため、エラーの特定と修正が困難になる。
ユーザーインターフェースは理想的とは言えない。なぜなら、完全にウェブベースではなく、データが常にインターフェースに絡みついているからだ。協働機能は存在するが、乱雑である。協働はプログラム可能なロジックのレベルで行われるべきである。多くのサプライチェーン最適化ベンダーは、予測を手動で調整し、複数の人が参加できるといったアウトプットでの協働を提供している。しかしこれは誤ったアプローチだ。協働は必要だが、それは論理レベル、すなわちプログラム可能なロジックのレベルで行われなければならない。Excelは非開発者にも非常に使いやすいが、やや複雑なことを行おうとすると困難になる。サプライチェーンマネジメントでは、あらゆる可能な未来に対応したい、つまり確率的予測、乱数変数、そして不確実性に取り組む必要がある。Excelでこれを行うことは可能だが、かなり複雑になる。Excelは単純な作業では容易だが、より複雑な状況ではExcelの魔法使いになる必要がある。
保守性は非常に重要だ。なぜなら、時間の経過と共に価値が増大する資産を構築したいからだ。スプレッドシートではこれを達成するのは困難であり、少なくともソフトウェア製品としての意味で真に正確なものを作るのが難しい。
今日のバズワードはAIとPythonであり、データサイエンスを取り巻くあらゆるトレンドとハイプがある。しかし、サプライチェーンマネジメントにおいては、私はPythonはExcelに劣ると考えている。
誤解してほしくはない。私はPythonが大好きで、素晴らしい言語だと思っているし、10歳の娘にも教えている。しかし、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はセキュリティ、バックアップ、コアインフラ、ネットワーク、企業レベルでのデータ管理と同期、そしてあらゆる指導やコーチングといった基本的なプラクティスに責任を持つ。
しかし、基本的な考えは、サプライチェーンがサプライチェーンに関する意思決定を自ら所有すべきだということである。彼らは、その意思決定を生み出すすべての仕組みを所有するべきであり、これが彼らの核心的な所有権となる。前回の講義で述べたように、サプライチェーンサイエンティストとは、コードによって生み出された数値的な決定を所有する人のことである。これは、決定を生み出すシステムではなく、1人または複数のサプライチェーンサイエンティストによって記述された数値レシピであり、彼らはそれらの数値的決定を共同で所有する。もしプロモーションが行われている場合や大規模なマーケティングプッシュがある場合、物事はタイムリーに生み出され、提供可能な状態にしなければならない。既に在庫切れに近いストックアウトの状況で何かを推し進め、在庫や製造能力、さらにはサービスの提供が間に合わずにマーケティングプッシュに資金を投じるという、壊滅的な状況に陥ることは避けねばならない。
つまり、焦点が大きく異なる2つの部門が存在する。私の理想とするIT部門のビジョンでは、IT部門はチケット処理を行う部門ではない。それはその本質ではない。IT部門はコアインフラを担当し、常にシームレスに動作する仕組みを提供する。まるでWi-Fiが正常に動作しているときは気にならないように、ユーザーは存在に気づかない。Wi-Fiは動作しているときは意識されず、故障時にだけ注目される。良いIT部門は、インフラ全体を提供し、利用者がその存在に気づかないほど自然に機能させる。つまり、メールが完璧に動作しているのと同じである。それが優れたコアITのあり方だ。そして、ITは手助けとなるプラクティスを確立するために支援に来る存在である。プログラム可能なロジックは多少難解であるため、プログラミング力向上のための指導をどこで受けるかというと、その答えはITにある。彼らは「あなたのためにコードを書く」のではなく、「あなた自身が実装できるようにコーチングするため」に来るべきだ。いくつかの概念や、本来よりも技術的な部分についての助言を与える。時には偶発的な複雑さも生じるため、ITはそのサポートをする。しかし基本的には、彼らはあなたに代わって作業を行うために存在するのではなく、致命的なミスを犯し、会社全体がランサムウェア等のリスクに晒される事態を防ぐためのメンターやコーチとして機能すべきである。
判断基準として、もしITとサプライチェーンのやり取りが仕様や要件を羅列した文書を通して行われるのであれば、それは両部門間の良好な関係を築く適切な方法とは言えない。ここで言う良好な関係とは、実際に会社に価値をもたらすものであることを意味する。
結論として、伝統的なサプライチェーンマネジメント側からは、Excelスプレッドシートを使ったプログラミングが行われていたものの、その実態にすら気づいていなかったという2つの課題がある。恐怖を克服しなければならない。明日の世界では、あなたの部門がソフトウェア製品のように動作する製品を提供する責任を担うという、途方もない変化に直面する。確かにそれは大きな変化だが、適切なツールがあれば対処可能である。なぜなら、プログラミングが絡むとしても、根本的かつ劇的にExcelより難しいわけではないからだ。再度言うが、課題はツールの技術的な難易度ではなく、本質的にサプライチェーン自体の複雑さにある。ツールが扱いにくいためではなく、そもそもサプライチェーンが複雑であるために問題が生じるのだ。
聴衆の中で、データサイエンティストやIT担当に近い方々は、過信という壁を乗り越えなければなりません。何度も見てきたのですが、私自身も含め、プロトタイプを実際の生産に持ち込む能力に過信しているデータサイエンティストがいます。これは困難であり、サプライチェーンは時に予想もしない形であなたの顔の前で崩壊するものです。何年も前に、ヨーロッパ有数の自動車部品のeコマース企業と共に始めた際の逸話が思い出されます。私たちは、その企業の部品補充を私たちの予測技術で扱い、部品補充の提案を行いながら自動車部品を提供していました。しかし翌週、私たちの予測はすべて2倍の誤差を出していることが判明しました。需要が倍増していたのです。何が起こったかと言うと、彼らのナンバーワンの競合が同時に複数の国へ進出することを決定し、文字通り私たちが予測を開始したタイミングで、その競合の一社が全国のテレビに登場し、オンラインで自社のサービスを放送し始めたのです。興味深いのは、私のクライアントがその事実に気付いていなかったこと、そして彼らの検索エンジン最適化の結果がより優れていたことです。基本的に、人々は競合のテレビ広告を目にしても、自然と競合の名前を覚えず、Googleで「car parts」と検索し、最終的にクライアントのウェブサイトにたどり着いたのです。Lokadの素晴らしさを証明するために、私たちが始めた初週は予測が2倍のズレを出し、「一体全体何が起こっているんだ？」と考えざるを得ませんでした。需要が倍増するからといって、すべてが倍になるわけではなく、あるものは10倍になり、多くのものは全く変わらないからです。
このような状況だからこそ、迅速に対応する能力が求められるのです。つまり、恐れと過信の問題です。ご清聴、誠にありがとうございました。
さて、チャットでいただいた質問を確認していきたいと思います。
質問: 明日分として追加注文が必要な場合、どのサプライヤーに追加注文を出すかの判断をソフトウェアが下すことはできますか？例えば、オーストラリアのオフィス向け200グラムのイチゴパネットの場合、同日に同じ商品を配送する10社ものサプライヤーが存在するかもしれません。
もちろんです。ここでは、サプライチェーン管理とサプライチェーン最適化の二つの側面を明確に区別しなければなりません。サプライチェーン管理側は、EDIを含むすべてのデータパイプラインが整備され、人的介入なしにサプライヤーへ電子的に注文をプッシュできる状態にあります。つまり、エンドツーエンドで電子的な橋渡しが可能です。しかし、それとは別に、最適化側には、1日中継続的に稼働し、ある時点で管理側に「この注文を実行してください」と通知できるソフトウェアが必要となります。そして、ITが管理する管理側は、その通知に基づき注文が完全に実行されるように確認するだけです。これは純粋に取引処理の問題であり、もはや「知性」は存在しません。つまり、「この数量」という注文を受け取った後、最適化側が、特定の数量を生成する際に、該当商品を提供可能なサプライヤーの正確なリスト、在庫の有無、さらには競合するサプライヤー間での適切な選択など、あらゆる制約に適合しているかを保証するのです。その他にも多くの要素が絡むかもしれません。はい、もちろんですが、サプライチェーン管理側の凡庸な取引処理と、追加発注の判断に必要な最適化要素は、明確に切り離す必要があります。
質問: 今、あなたはeSportsワールドチャンピオンシップと競合しているのをご存知ですか？
いいえ、現時点でeSportsのチャンピオンシップと競合しているわけではありませんが、それは非常にクールなことです。ちなみに、Lokadでは頻繁にDota 2をプレイしており、経営陣も参加しています。一部の従業員はLeague of Legendsをプレイしたいと言いますが、CEOとしては固く反対しています。
質問: 多くの企業がそもそもERPやWMSを持っておらず、その経営陣がサプライチェーン最適化に取り組んでいるのを見かけますが。
ええ、もちろんです。サプライチェーン最適化は、企業が最初から避けることのできない課題であり、その決断を下さなければなりません。サプライチェーン最適化は、いかなるサプライチェーン管理ソフトウェアが存在する前から存在しており、60年前、ソフトウェアがなかった時代でも、人々は決断を下していました。つまり、サプライチェーン最適化は、ペンと紙を使って行われていたのです。最古のサプライチェーンの理論であるWilsonの式、別名EOQ式を見れば、一世紀以上前のものであり、明らかにソフトウェアに先んじるものです。ですから、組織にソフトウェアがあるか否かに関わらず、サプライチェーン最適化は最初の日から行われるものなのです。
もちろん、適切なITシステムを持つ必要はありますが、その考え方は全く異なります。サプライチェーン管理とは、例えばデータ入力やバーコード対応など、非常に凡庸な作業を確実にこなすことに関するものであり、単にデータを表現するに過ぎません。しかし問題は、人々がサプライチェーン管理とサプライチェーン最適化の両方を一つのシステムに求めるため、結果的に過剰に複雑で、通常はバグが多く、回避すべき警告や例外などの悪い機能を持つ製品になってしまうことです。この点については、後の講義で詳しく触れる予定です。
基本的に、今日ではWMSやERPの導入は、すでにシステムを持っていない場合は数週間で済むものです。既にシステムが存在している場合でも、それを意思決定から切り離すことができれば、数ヶ月で済むこともあります。
質問: 経営陣はいつになって、情報の追跡からサプライチェーンの意思決定の最適化へと移行し、最終的にサプライチェーン最適化に注力する時が来たと認識できるのでしょうか？
まず第一に、最初から二つの問題が存在し、同じソフトウェアがその双方を解決することは決してないと認識する必要があります。これこそが大きな幻想であり、ソフトウェアベンダーはこの点で非常に混乱を招いています。最大手のERPベンダーを見ると、「このシステムはサプライチェーン最適化を実現する」と謳っていますが、実際に彼らが提供するのは、AIなどの知能的要素を欠いた、より魅力に欠けるサプライチェーン管理側の機能に過ぎません。ソフトウェアの世界ではこれをCRUDアプリ（Create, Read, Update, Delete）と呼びます。ERPは、リレーショナル・データベースからレコードを作成、読み取り、更新、削除するための膨大なCRUD画面の集合体にすぎません。要するに、ERPは様々なエンティティのための何千ものテーブルの集合体であり、論理的にグループ化できる各エンティティごとに1画面か2画面が存在するだけなのです。ですから、経営者の皆さんがERPベンダーのパンフレットを読んで「これがサプライチェーンを最適化する」と信じたとしても、答えは決して「はい」ではありません。本当に行われるのは、生産性の向上とサプライチェーンの正確な簿記の維持であり、これだけでも盗難、在庫の縮小、商品の紛失を劇的に減少させ、倉庫におけるバーコードの活用で生産性を向上させるなど、多大な付加価値をもたらします。ERPやWMSが提供する価値を否定しているわけではありません。それは莫大ですが、サプライチェーン最適化そのものを実現するものではありません。例えばWMSは、設計上、倉庫に特化しており、顧客やサプライヤーを含む全体のサプライチェーンには対応していません。あくまで特定の場所に焦点を当てるものなのです。
質問: PythonからEnvisionへの移行、もしくは両者を併用する場合、どのように円滑に連携させることができますか？
歴史的に、いくつかの状況でPythonとEnvisionを併用してきました。ここで皆さんにお伝えしたいのは、EnvisionはLokadによって設計された、サプライチェーンの予測最適化専用のドメイン固有プログラミング言語であるということです。次回の講義では、実際のコードを交えながらEnvisionのデモンストレーションを行い、私の話している内容をより深く理解していただけるようにします。
当初、Envisionの機能が非常に限定されていたため、歴史的にはPythonとEnvisionを併用していました。多くの状況で不足している機能をPythonで補っていたのです。しかし、年月とともにEnvisionの機能は徐々に拡充され、Pythonコンポーネントの必要性は段階的に解消されていきました。これは単にPythonコンポーネントの話だけでなく、Airflowのように連携させる必要がある一連のツールの話でもあります。
ちなみに、Envisionの構文は意図的にPythonと多くの面で調和するように設計されています。Pythonプログラマーを排除しないために、Envisionの構文をあえてPythonに似せることに決めたので、Pythonに慣れていれば一週間でEnvisionを習得できるでしょう。細部では微妙かつ大きな違いはありますが、構文の多くの部分は共通しています。Pythonにはシンプルさや設計の純粋さといった多くのメリットがあります。たとえ私が、Pythonがすべての要件を満たさず、生産現場で深刻な問題を引き起こすと指摘したとしても、Pythonにメリットがないというわけではありません。私が言いたいのは、Pythonには非常に多くのメリットがあるということです。ここで再度申し上げますが、今回の議論は生産環境におけるサプライチェーン運用という、非常に特定の問題についてのものです。
質問: クライアントに、彼らのERPが何も最適化していないとどのように理解させますか？
これは非常に困難です。実際、最悪の状況は、見込み客が「我々のレガシーERPは何の価値も提供していない。だから、今度はサプライチェーン最適化を実現する新たなERPに移行したい」と言ってくる場合です。そうなると、クライアントに説明しなければならないのは、彼らが求めているのは一つの製品ではなく、二つの製品であるということです。一つは、既存のERPを置き換え管理側の業務をより適切に処理するもの、もう一つは最適化を実現するものなのです。
レガシーERPと言えば、特にオールドスクールなIBMメインフレーム上のコマンドライン端末を持つAS/400製品には大いに敬意を表します。管理側の観点からは、通常、非常に適切に機能しています。クライアントが本当に求めているのはコマンドラインではなくウェブインターフェイスかもしれませんが、それが現場のチームの生産性を向上させるのでしょうか？私はそうは思いません。テキスト端末を用いたコマンドラインは、非常に迅速で生産性が高く、全くの気晴らしがありません。
したがって、競合他社が押し付ける無意味な主張を解体しなければならないため、状況は非常に厳しいものとなります。さらに、ERPはサプライチェーンを最適化するものではなく、AIやブロックチェーンといったものは存在せず、ただ統計モデルの一群にすぎないことを説明しなければなりません。残念ながら、この段階でほとんどの見込み客を失ってしまいます。これこそが、私がこれらの講義を行っている主な理由のひとつであり、なぜ私が問題をこのように捉える必要があるのかを説明するのに何時間もかかるのです。
質問: 確率的需要分布を持つ複数製品の計画の複雑性に対処するためのプラットフォームとして、どのようなものを推奨しますか？
ええ、もちろんLokadです。ただし、私がLokadのCEOであり、かつ同社の大株主であるため、利益相反が存在することはご承知おきください。私はLokadが必要なプラットフォームであると固く信じていますが、同時にそれが私自身が所有・運営している会社であることもご理解ください。あらゆる点でできる限り客観性を保つよう努めます。
ちなみに、Lokadは確率的需要分布に対処するために文字通り設計されているだけでなく、確率的なリードタイム分布、確率的な返品分布などにも対応しています。あらゆる種類の不確実性を考慮し、あらゆる可能な未来を確率とともに見積もる必要があるのです。需要は非常に重要な要素であり、通常は最も重要ですが、唯一のものではありません。
すべての質問に目を通したと思います。何か見落としていないか確認しましたが、追加の質問はありません。それでは、本講義をご視聴いただきありがとうございました。また来週、同じ曜日、同じ時間にお会いしましょう。では、また。さようなら。
参考文献
- Joel on Software: ソフトウェア開発者、デザイナー、マネージャー、および幸運であれ不運であれ何らかの形で彼らと関わるすべての人々にとって興味深いであろう、多岐にわたるそして時には関連する事項について - Joel Spolsky著, 2004
