全文書き起こし

Conor Doherty: これはサプライチェーン・ブレイクダウンです。今日は、なぜあなたのサプライチェーンが運用費ではなく資本的支出であるのか、その理由を詳しく解説していきます.

私の名前はConorです。私はLokadのコミュニケーションディレクターであり、いつものように左隣のスタジオから、非常に身なりの整ったJoannes Vermorelが参加しています.

さて、始める前に、下のコメント欄にぜひご記入ください。まず第一に、どこからご覧になっているのか、そして第二に、あなたはどう考えますか――あなたのサプライチェーンは資本的支出でしょうか、それとも運用費でしょうか?

とてもシンプルな質問ですが――果たしてそうでしょうか?さっそく本題に入りましょう.

さて、Joannes、私は休暇から戻ってきました。良い従業員として、休暇中にあなたの講義をすべて再視聴しました.

Lokadの古参のファンならご存じの通り、Joannesは長期にわたるシリーズを持っています。休暇の過ごし方としては非常にひどい方法ですが、余談はここまでにします.

しかし、私自身の時間を有効活用するために、冗談抜きに実際にいくつか再視聴したのです.

その中の一つが「サプライチェーンのための製品指向デリバリー」で、かなり昔のものです.

多分2017年頃のもので、その中には非常に素晴らしい洞察が含まれていました.

いろいろありますが、その中でも特に心に残ったのは、あなたが提案した、サプライチェーンを再考すべきだという点です――つまり、運用費や単なる支出、負債ではなく、機械や車のように再び価値を生み出す生産的資産として捉えるべきだという点です.

さて、最初の質問ですが、私の説明は大まかにあなたの主張を正しくまとめていますか?

Joannes Vermorel: はい。そして、ここでいうサプライチェーンとは、実際には意思決定の部分、つまりプロセスの中の判断部分を指しており、サプライチェーンのインフラそのものではありません。もちろん、warehouseは明らかに資産ですが、ここで議論しているのは、日々必要とされるありふれたsupply chain decisionsを生み出す機械、組織、プロセス、またはその他何かという点です。何を購入するか?どこで生産するか?在庫はどこに置くか?価格を上げるべきか下げるべきか?

その機械、つまりこれらの決定を生み出す組織は、資産と見なされているでしょうか?そして、私の主張は、現状の主流実務では全くそうではないということです。サプライチェーン、すなわち管理部分・意思決定部分は純粋な運用費です。コストセンターに過ぎず、業務を完遂するために必要なだけ多くのプランナーが投入されている、という現状なのです.

Conor Doherty: では、これを明確かつ具体的にしましょう。現在あなたが提唱しているものと現状の技術水準を分ける、具体的な行動は何でしょうか?つまり、具体的には?

Joannes Vermorel: 具体的に言えば、CapExと見なされるのは、あるenterprise softwareベンダーが提供する、意思決定プロセスをサポートするためのソフトウェアライセンスのみです。しかし、サプライチェーンの分野においてこれらの企業向けソフトウェアは、資本的支出としても生産的資産としても非常に弱いと私は考えています。なぜなら、これらのソフトウェアは膨大な人手を必要とするからです。文字通り、これらのソフトウェアは人間の補助プロセッサーを必要とするものと考えてもよいのです。つまり、あなたのシステムは、日々現場に関わる決定を下すために膨大な人手を必要としているのです.

そして、それがCapExではないと私が言う理由は、付加価値が生み出されないからです。あなたは日々、業務の流れを維持するために必要な指示に投資しますが、これは資本主義的な価値蓄積とは言えません。支出を何度も何度も繰り返し、20年後に見ても同じことをしなければならないのです。ご覧のとおり、これらは途切れることなく人手を消費し続けます。本当に資本主義的に付加価値を生むものではありません。まるでトラックに燃料を入れるように、これらの企業向けソフトウェアには人手が必要なのです。だからこそ、概して企業は自社のサプライチェーンを純粋な運用費として扱っているのです――仮に会計上資産と見なされる可能性のある小さなソフトウェアライセンスを除けば――しかし、それでも非常に弱い資産に過ぎません.

Conor Doherty: この見方は全社的なものなのでしょうか?それともサプライチェーン担当者だけの話で、COOやCFO、会計担当も同様にそう見ているということですか?

Joannes Vermorel: 企業内の多くのコストセンターは全く同じアプローチを取っています。例えば会計部門も同様です。純粋に運用費、すなわち事業を継続するための単なるコストと捉えられています。会計部門には一定のリソースが必要ですが、たとえ会計ソフトウェアが小さな資産であっても、それは決して生産的な資産ではありません。それ自体で追加の利益や収益を生み出すものではなく、金銭を生み出す機械でもないのです.

ご存知のように、これが資産と負債の違いです。購入したものが自らお金を生み出すかどうか――会計を例に取れば、明らかにお金を生み出しません。必要はあるものの、お金を生み出すわけではなく、純粋なコストセンターなのです。これが問題なのです。私が伝えたいのは、サプライチェーン、つまり意思決定の部分を、従来は毎日必要な指示に伴う支出という観点から純粋なコストセンターとして扱ってきたということです。これほど大きな企業であれば、業務の流れを維持するために必要な指示が多く求められるのです.

Conor Doherty: 今後、その影響や、サプライチェーンを資産として扱う具体的な方法についても掘り下げていきます。しかし冒頭で、意思決定が金銭を生み出すとおっしゃいました。これは、現在の考え方とは正反対の概念だと言われましたね。一日の中で、サプライチェーンをCapExとして見るか運用費として見るかで変わる意思決定の具体例はありますか?

Joannes Vermorel: つまり、CapExとして考え始めると、一歩引いて全体を見渡す必要があるのです。「人々に決定させるために支払っている」のではなく、「自動的に決定を生み出すシステムを設計するために支払っている」と考えるのです。これは非常に大きな違いで、支払いを停止してもシステム自体は利益を生む決定を継続して下すということを意味しています.

そして、それは在庫の補充のような、非常に日常的な作業にも当てはまります。正しく運用されれば、これは明らかに利益を生むオペレーションです。あなたはドルを物理的な在庫に変換し、その在庫が再びドルに変わるのです。もしこれらの決定が自動化されれば、それはまるでお金を印刷する機械のようになります。たとえ人々がより多くの時間を投資しなくても、企業のために利益を生む決定が自動的に行われるのです。実際には、ソフトウェアの稼働を維持するために電気代などがかかりますが、原理的には、全体を機械化できれば、同じ作業を人間が行う場合に比べ運用コストはごくわずかになるのです.

ベルトコンベアを例にとれば、物を移動させるには電気代、メンテナンス代などのコストがかかりますが、人が手作業で運ぶ場合に比べれば、その割合は非常に小さいのです.

Conor Doherty: では、再びサプライチェーンを資産として扱う議論に入りましょう。多くの人は「資産」と聞くと物理的資産を連想します。しかし、何度も話してきたように、サプライチェーンは地理的に分散したアクターのネットワークであり、行動や価格といった抽象的な要素も含んでいます。つまり、サプライチェーンは物理的な要素と抽象的な要素の両方で構成されているのです。では、物理的でありながら抽象的なサプライチェーンが、いかにして資産としての性質を持つのかを説明していただけますか?

Joannes Vermorel: これを意思決定機械と考えてください。コンピューターと人々を用いた大規模な機械が存在し、それが決定を生み出しているのです。つまり、これを資産と捉えるならば、「機械をより良くするために時間を投資する」と考えるべきです。そして、機械である以上、人々の投資を止めたとしても、その機械はそのままの状態を維持すべきなのです.

両者の見解を比べてみてください。CapExの視点から見ると、これらはまったく異なるものです。サプライチェーンの意思決定を機械化し――すなわちサプライチェーンをCapExとして扱えば――実際、supply chain scientistsが休暇に入っても問題は起こりません。決定は引き続き生み出され、監督する人々や緊急時の補助があっても、もし1週間投資を止めたとしても、すべての決定は継続して生み出され、復帰して投資を再開すればさらに改善されるのです。まさに、費やされた時間は継続的な改善のためのものであり、その改善は持続的な価値を生み出します。だからこそ、私はこれをCapExと言うのです――付加的(accretive)だからです。機械をより良くするために一定の日数を投資し、その後に機械を稼働させれば、自動的に運転し続けるのです。これは、ベルトコンベアと似ています。確かにメンテナンスは必要ですし、完全な自律性はありませんが、その効果には桁違いの差があるのです.

ちょうど、ベルトコンベアのメンテナンスを1日止めても、通常は問題なく稼働し続けるはずです。常に誰かがその機械を微調整する必要はありません。もし、ベルトコンベアの運用に常時人員を配置しなければならないのであれば、その機械は悪いものです。生産的資産としての役割を果たしておらず、基本的には無人で運転されるべきなのです.

Conor Doherty: あなたは、機械を良くすることや悪くすること、すなわち改善の可能性について触れました。例に出されたベルトコンベアは機能的なもので、非常に日常的な存在です。そして、その資産価値の向上には限界があるのではないかと考えます。その点についてもう少し深掘りしていただきたいのですが、サプライチェーン資産の価値が上昇(または減少)する限界、つまり資産としての価値はどこまで上がる(または下がる)のかを教えてください。資産であるならば、価値の上昇や下落の影響を受けるはずですから.

Joannes Vermorel: はい。そして基本的には上限はありません。なぜなら、意思決定の領域に入ると通常、明確な天井は存在しないからです。もしも既に販売済みの商品の狭義の在庫補充だけを問題として定義するのであれば、確かに上限は存在します。最適な補充、何であれ、それが企業の収益性を高めるには限界があるのです。たとえ大きな効果が見込めたとしても、その範囲には限度があるのです.

しかし、もしこの意思決定の概念を、例えばいつ新製品を導入するかや、特定の製品のプロモーションにどれだけ投資するかといった形で拡大すれば、状況は非常に曖昧になり、明確な上限は存在しないと言えるでしょう。確かに制約はあるかもしれませんが、意思決定プロセスの領域では、実質的に上限がないと言っても過言ではありません.

再度例えるなら、会計を見てみるとわかります。優秀な会計士がいれば十分な成果が得られますが、世界最高の会計士を起用しても、意思決定の領域では規制遵守が中心となるため、大きな差は生まれません。もし、これらの意思決定の範囲を恣意的に狭め、サプライチェーンがこの限定された決定しか行えないと仮定すれば、確かに上限は存在します。しかし、その範囲を拡大すれば、明確な上限はなくなります。そして、市場に参入し続け、かつての支配的企業を凌駕する企業が現れる事実が、より優れた意思決定が可能であることを証明しています。最近巨人へと成長したすべての企業は、何らかの形でより良い方法が存在していたことを示しているのです.

Conor Doherty: もっとシンプルに言えば――もし私が間違っていたら訂正してください――意思決定を生み出すのは、利用可能なデータ、すなわちその情報そのものです。市場に参入する人が増え、供給者が増え、競合他社の価格変動など、これらすべてが限界を変化させます。つまり、昨日可能だったことと比べ、今日や明日可能なことが変わるのです。その観点から、もしこれらの情報をサプライチェーン、つまり資産に組み込むツールがあれば、意思決定の質、ここでいう「良さ」=経済的リターンにおいて、上限は存在しません。今日1ドルの利益を上げたとして、明日はグローバルなサプライチェーンの状況の微妙な変化により、それが1.10ドル相当になるかもしれず、さらに良い結果を生み出す可能性があるのです.

Joannes Vermorel: 他の分野、例えばマーケティングを見れば、その差は非常に明白です。マーケティングのキャッチフレーズに上限はなく、Nikeの「Just Do It」は非常に有名で、このフレーズで何十億ドルもの成果を上げています。マーケティングにおいて、どれほど優れた結果を出せるかについては事実上の上限はありません。もちろん、実際に抜きんでた成果を出すのは非常に難しく、絶対的に優れた人材は極めて稀ですが、本質的には、私が言っているのは、明確な上限が存在しないということです。さらに、アウトライヤー、すなわち意思決定、創造性、発明の領域においては、意思決定の枠組み自体を再考することが可能です。これにより計り知れない自由が得られ、だからこそ明確な上限はないと言えるのです。しかし、これは実際的な限界が存在しないという意味ではありません。確かに、あなた自身がこのシステムを考え、設計できる能力という現実的な限界は存在するのです.

Conor Doherty: システムのエンジニアリングに関しては、システムの設計を考える方法は二通りあります。一方では、いわゆるデータサイエンティストやサプライチェーンの科学者、意思決定の専門家が実際にコーディングを行います。しかし、もう一方では、そのような活動が可能になる企業内の環境―つまりCOOやCFOといった役員が整える環境―のエンジニアリングがあります。後者に焦点を当てると、彼らがどのような行動をとることで、この種の思考が促進され、より協調的かつ生産的な環境が作られるのでしょうか?

Joannes Vermorel: 私の考えでは、まず意思決定、すなわち広くはサプライチェーン全体にかかる費用の中で、計画、予測、S&OP、製造管理、在庫管理、流通管理など、日常的な管理業務を担う人々がどれだけの費用を使っているかをコアとして評価することが出発点です。

あなた自身に問いかけなければなりません。これは実際に必要で、なければ流れが止まってしまい、翌日も同じ状況―つまり根本的に何も変わっていない状況―になるために、いわゆるCapExのようにお金を使っているのでしょうか?それとも、さらなる自動化や自動化の改善、あるいは自動化の開始のためにお金を使っているのでしょうか?エンジニアリングの細かい実施方法などを考慮する前に、まずは「このお金は意思決定マシンをより良くするために使われているのか?それとも、単に燃料を補給するためだけに使われ、燃料が尽きれば何も変わらないのか?」と考えることが重要です。

私の基本的な見解は、もしこの基礎的な評価を実施すれば、ほとんどの企業において資金のほぼ全てがOpEx、つまり運用費用として使われていることに気づくはずだということです。実際、99%ほどがエンジン(=業務プロセス)を動かし続けるためだけに使われ、エンジンそのものの改善に充てられる部分は非常に少ないのです。エンジンの改善は、例えば5年に一度、突如として大手エンタープライズソフトウェアベンダーにアップグレードのための大金を支払うときだけに起こるでしょう。しかし、それは非常に弱いアプローチです。つまり、毎日自社のサプライチェーンをほぼ純粋にOpExとして扱い、ごく稀にだけ反対のことをしているような状態になってしまいます。私が提唱するのは、CapExとしての投資は毎日行われるべきだということです。つまり、どんな支出も、年に一度や十年に二度ベンダー選定のために行うのではなく、常にこの資産を改善するためのものであるべきです。

Conor Doherty: その点はまさに切れ目となる話ですね。「毎日」、つまりCapExのマインドセットを取り入れ、毎日の支出をCapExとして扱うということです。では、資産の一例として、もし私が家を買った場合、家の正確な価値を完全に把握することはできないものの、「1年前に50万ドルで購入した。同じエネルギー効率を持つ似たサイズの家が近隣でいくらで売れたかから、私の資産は10%上昇、あるいは5%下落した」といった評価方法はあります。サプライチェーンをCapExまたは資産として見る観点から、この資産クラスの価値の上昇または下落をどのように測定することを提案しますか?

Joannes Vermorel: 根本的には反事実的状況に対処することになるため、非常に難しい問題です。つまり、「もし私のサプライチェーンが別のマシンによって運営されていたら、その収益性はどうなっていただろうか?」という問いに直面するわけです。しかし、実務上はさほど困難ではなく、基本的なパフォーマンス指標、例えばインベントリーターンオーバー、収益性、在庫の償却、全体的なサービス品質などを見ることで、もしマシンがしっかりと稼働し改善されているなら、それらの指標も改善されるはずです。

また、反事実的なシナリオを考慮しなければなりません。例えば、改善が進んでいても、突然サプライヤーに多大な問題が発生し、リードタイムが急激に延びた場合、その改善効果が打ち消される可能性があるのです。すべての要素を考慮する必要があり、明確な指標を設けるのは難しいですが、この問題は本質的には全てのソフトウェアベンダーが直面する問題と同じです。ちなみに、この類似性には理由があり、もしサプライチェーンを意思決定を生み出すマシンとして扱うのであれば、実質的にはソフトウェア資産と同じ問題に取り組んでいることになるのです。

たとえば、MicrosoftがMicrosoft Wordの改善に投資した際、彼らは実際にMicrosoft Wordが改善されたと判断します。これは非常に広範で把握しにくい問題であり、なぜ資源を投入してエンジニアリングを改善しているのか、その具体的な改善内容を掴むのは難しいのです。しかし、困難であっても進歩そのものは非常に実感できるものです。20年前にリリースされたバージョンのソフトウェアと比較して、「あのバージョンはひどかったが、今のはずっと良い」と即座に実感できるでしょう。ソフトウェアベンダーが進捗を止めなければ、これは典型的なパターンです。

同じようなことがサプライチェーンにも起こるべきで、そのマシンは、人間の補助作業が必要な領域が次第に減少していく状態へと導くはずです。この点は非常に直感的に測定可能です。また、意思決定の深度、例えばマルチソーシングに対応できるのか、あるいは依然として非常に粗いソーシングのヒューリスティックに頼っているのか、といった評価もできます。再発注が、完全なトラック積載、完全なコンテナ積載といった形で本当にスマートに行われているのか、サプライヤーが提供する価格割引を十分に活用できているのか、といった点も考慮すべきです。

たとえ実際に「もしも」の状況を正確に再現できなくても、概算で評価できるケースは多々あります。たとえば、「前四半期には完全コンテナ出荷に関するヒューリスティックを大幅に改善できた。以前はそうではなかったが、今は慎重に運用しており、その追加の効果はおおよそこの程度だ」というように。これは概算に過ぎませんが、改善が現実のものであれば、具体的な成果が自ずと見えてくるはずです。もし、ほとんど具体的な成果が確認できないのであれば、その改善は実質的なものではなく、単なるアイデアに留まっている可能性が高いでしょう。

Conor Doherty: ヒューリスティックについて話す際、人々があらゆるデジタルトランスフォーメーションで求めるのは、レジリエンス、すなわち回復力の向上であり、資産は市場の衝撃に対して強いものとみなされがちです。たとえば、市場が暴落すれば金の価値が急上昇します。あなたのサプライチェーンをCapExとして捉える視点が、COVIDやスエズ運河のような事象に直面した際に、OpExと比較して具体的なレジリエンス向上をもたらすと考えますか?

Joannes Vermorel: そうです。OpExモードの場合、基本的にはリソース、つまり人材を最大限に活用しようとします。人々が100%働いているということは、もし70%しか活用されていないのであれば、30%は無駄になっているということです。これがOpExアプローチの問題点であり、常に100%の活用を追求してしまいます。

では、もし混乱が起きた場合はどうでしょうか。混乱が発生すると、通常とは異なる対処が必要になり、なおかつ一般的な人工知能はまだ存在しないため、基本的には人間に頼るしかありません。マシンを作ってもそのマシンは自意識を持たず、常時通常業務をこなすだけであり、非常時に自ら異常事態に対処することはできません。問題は、その時に必要な人材が確保できるかどうかという点です。

私の答えはこうです。もしOpExモードにあるなら、現状では全員が100%稼働しているはずです。具体的には、社内の全員が火急の対応に追われ、サプライチェーンのディレクターが1日に5件もの緊急事態を抱えているといった状況です。これは、高い稼働率―つまり、常に火消し作業が行われ、人々が多忙を極め、結果として問題が上層部にまで波及している証拠です。

対照的に、CapExモードの場合、人々はマシンの改善に時間を費やしています。もし混乱が発生した場合、彼らは通常の改善作業を中断し、早急にダメージコントロールに移行することができます。なぜなら、単に日常業務を動かすためだけに100%働かされているわけではないからです。この点で、私が提唱するCapExの考え方は、例外的な状況に対応するための大きな余裕を提供します。文字通り、もしCapExモードであれば、全員が一週間休暇をとることさえ可能であり、混乱の発生しない通常時には問題が起こらず、混乱時には日常業務に追われることなく即座にダメージコントロールに取り組むことができるのです。

Conor Doherty: これを踏まえて、決定エンジンの敏捷性と責任についての講義(たとえば1.4の講義)にも繋がると思います。非常時に、百人を同じ部屋やTeamsコールに集める必要がなく、そのエンジン、つまり資産が迅速に衝撃に対応できることが重要です。

Joannes Vermorel: これが答えの第二の部分でもあります。もしマシンを持っていれば、大規模な混乱が発生した場合、調整すべき項目は膨大になります。もし数十人を再訓練し、ポリシーを変更する必要があれば、それには時間がかかります。どれほど勤勉に取り組んでも、数週間は必要です。しかし、もし意思決定が基本的にソフトウェアによって制御されているなら、数時間、せいぜい1日か2日で、粗雑ながらも大規模なダメージコントロールのための対策を打ち出すことができるのです。

過去10年間にわたって、こうした方法が何度も実証されてきました。ダメージコントロールに対応する余力がある人々は、非常時に行動を起こす際、通常の業務フローに頼らず、直接コードに手を加えて問題解決のヒューリスティックを注入することができます。そして、エンジンを再起動すれば、新たな現実に則った改訂済みの意思決定が生成されるのです。

例えば、ある状況を想定してみてください。もし、会社にサービスを提供していた大手銀行が、突然大口の信用枠をキャンセルしてしまい、会社の利用可能な流動資金が一夜にして半減してしまったとします。

その場合の課題は、すなわち、エンドツーエンドで、すべての購買ポリシーをこの新たな現実に合わせてどのように改訂するかということです。少なくとも、誰かが財務部で新たな流動性の供給源を見つけるまでの一時的な対策として。もし人手で行うなら、非常に複雑で数週間を要するでしょう。しかし、もしマシンと、経済的ドライバーに基づく数値的なレシピがあれば、「現金のコストを考慮して―ばちっ―このファクターを流動性危機のために10倍に上げる」といった簡単な調整を自動的に実施し、流動性不足という問題に対処するため、即座に現金プラスの意思決定のみを選ぶことができるのです。

Conor Doherty: ありがとうございます。パブリックコメントやいくつかのDMに進む前に最後の一言です。資産について、CapExの視点についてお話ししましたが、ここで技術的な面、つまりどのようなツールやテクニック、手法がこの視点―資産の価値向上―を実現しているのかについて、具体的なコメントはいただいていません。

Joannes Vermorel: 私たちが話しているのは、文字通りソフトウェアの改善の話です。実際、私が「マシン」と述べたとき、コンピュータと人間が組み合わさったシステムは、本質的には大規模なソフトウェアプロジェクトであると言えます。現代の手法でサプライチェーンを意思決定のゲームとして捉えるなら、根本的にはそれはソフトウェアのゲームなのです。

次に考えるべきは、いかにしてこの自社固有のソフトウェアを作り上げるかという点です。ここが非常に難所です。それは、汎用のソフトウェアではなく、自社固有のデータソースや戦略を完全に取り込む必要があるからです。特に、企業規模が1億ドル以上であれば、全く同じ企業は二つと存在せず、常に独自性が求められるのです。すべての大企業は、それぞれ固有の経済的ニッチを占めています。

したがって、このマシンはあなた専用のものとなるのです。類似点や再利用可能なコンポーネントが存在する可能性はあっても、基本的には、すべてのデータソースと企業の戦略を統合しているため、このソフトウェアは極めて独自のものとなります。Lokadでは、何十社もの企業にサービスを提供していますが、各社は完全に異なる数値レシピを持っており、似た企業でも本質的な違いがあることが分かっています。

Conor Doherty: 「数値レシピ」という用語を使うとき、基本的には資産そのもの、つまり意思決定を生成するアルゴリズムを指しているということですね。

Joannes Vermorel: まさにその通りです。「数値レシピ」というのは、非常に広い意味で使われる用語であり、そこには多数のアルゴリズムやヒューリスティック、非常に賢いものもあればそうでないものも含まれます。これは、すべての入力から必要な意思決定までのプロセス全体、いわば配管作業全体を表しており、資産を視覚化する一つの方法です.

Conor Doherty: よし、ジョアンネス、35分ほど話し合ってきたので、続きを進めよう。これは—コメントとして読むから、疑問符がないのでそのまま読み上げるよ。君の意見を聞かせてくれ。これは—発音をお許しください—ガヴからのものだ。上手く言えていればいいんだけど:「私の理解では、サプライチェーン投資をキャペックスとして位置付けることは、回復力のあるネットワーク、自動化、そしてデジタルプラットフォームの構築が、日常のコストだけでなく、競争力を強化する長期的な資産であることを際立たせる」という意味だ。君も同意していると思う。

Joannes Vermorel: 絶対にそうです。そして、目的にかなう手段として本当に考えなければなりません。「何らかのデータプラットフォームに投資している」とは考えずに、より利益を生む意思決定を行うマシンに投資しているのです。念頭に置くべきは、この投資がより利益を生み出す意思決定というビジョンと一致しているかどうかです。

なぜなら、ここにはもう一つの落とし穴があるからです。多くの企業向けソフトウェアは、資本的に利益を積み上げるものではありません。例えば、サプライチェーンのデジタルツイン―派手に見える―を持っていたとしても、もしそれが日々意思決定を導き出さなければ、結果としてそれは単なるガジェットに過ぎず、しかも高価なものでしかありません。有効な資産とみなす唯一の方法は、それが大規模に毎日意思決定を生み出し、その意思決定が資産を生産的かつ利益に結びつけることです。

Conor Doherty: そう思います―そして、もし私に誤りがあればいつでも訂正してください―しかし、ここでの重要な点は「大規模に」ということで、それが極めて重要だからです。

どんな個人でも、ひとつの意思決定においてはアルゴリズムを上回る、あるいは同等のパフォーマンスを発揮できるかもしれません。しかし、もし毎日50,000もの意思決定を行う必要があるなら、それは個人の能力の範疇をはるかに超えています―

Joannes Vermorel: そして、もう一つの問題として、それは再び運用費(OpEx)の問題にもなります。確かに、この人は非常に優秀ですが、本質的に時間が経ってもそれほどの向上は期待できません。優れたサプライチェーンの実践は1970年代から知られており、米国のAPICS(サプライチェーン管理協会)は何十年にもわたってその原則を教えてきました。我々は、どれほどの改善が現実的かを見極めなければなりません。これは、明日誰かがもっと生産的になる分野ではなく、本質的には同じ数値レシピ、同じ実践なのです。

手作業で行う場合、それほど大きな改善が見込めるとは期待すべきではありません。つまり、大規模というのは、ソフトウェアを使えばデフォルトで得られるものなのです。ソフトウェアが正しく設計されていれば、どんな規模においても意思決定を生み出すことができます。

Conor Doherty: 分かりました。ありがとう。続けます。もし数値レシピ――つまり意思決定の根幹――が資産であるなら、バージョン管理、ロールバック、そして安全弁は誰の所有で、また市場の動向が変わったときにモデルの減価償却をどのように扱うのですか?

Joannes Vermorel: はい、数値レシピが唯一の資産というわけではありません。Lokadでは、同じく重要なもう一つのものがあります。それが、私たちが「共同プロセスマニュアル」と呼ぶ、イニシアチブの総合マニュアルです。数値レシピは、何をするか―つまり、毎日どのように意思決定を生成するか―を示し、各段階で何が起こっているかを教えてくれます。これがコードです。コードはどの計算がなされているかを示します。一方、共同プロセスマニュアル――これは人間向けに意図されたもの――は、なぜそれをするのか、という理由を示します。なぜそのようにDRを準備することを選んだのか?なぜこのモデリングを採用し、別のものではなくこれを選んだのか?なぜ経済的な推進要因をこのように、またはあのように表現することを決定したのかを説明するものです。

この「何をするか」と「なぜするか」という二つの組み合わせこそが、真に資産となるのです。数値レシピは非常に重要ですが、全体の半分に過ぎません。「なぜ」を記述する文書もまた極めて重要です。なぜなら、それがあなたが何を改善すべきかを知るための出発点になるからです。「なぜあれをしたのか?ああ、単に時間がなかったための粗い近似だったのでそのままにした」という考えがあるなら、それは「なぜ」の部分に含まれる―つまり、サプライチェーンの科学者にとって「もしこうならば」という指針となる文書なのです。

確かに、コードのバージョン管理や監査は必要です。リリースのためのプロセスも必ず整えるべきです。理想的には、入力が正しいのか、出力が正しいのかなどを確認する多数のプロセスが必要です。これを誰が管理すべきか?答えはサプライチェーンです。サプライチェーン管理の枠内に置かれるべきです。最終的には、サプライチェーンのディレクターあるいは責任者がその責任を負うのです。IT部門ではなく、根本的にあなたはサプライチェーンの意思決定を生み出しているのです。最終的な責任は、まるでマーケティングがGoogle AdWordsの予算を賢く使う責任を負うのと同じように、その担当者の手にあるのです。

確かに、Google AdWordsに資金を投入するには多くのツールが必要かもしれませんが、最終的には、どのキーワードにどれだけ賭けるかを決めるのはマーケティングの判断です。彼ら自身がその責任を負う必要があります。ここでも同じことが言えます。

Conor Doherty: これは少し技術的な話になります。CFOの観点から、継続的な運用費として計上するのではなく、なぜ決定エンジンを資産計上するのか、その正当性を監査人に示すための具体的な証拠は何でしょうか?それとも、これは主に哲学的な立場であり、厳密な会計論ではないのですか?

Joannes Vermorel: 会計の観点から言えば、必ずしもそうしなければならないというわけではありません。実際、いくつかの企業はそうしています。例えば、ソフトウェア企業の中には、ソフトウェアエンジニアがその作業に時間を費やす場合、資金を資産計上するという選択をするところもあれば、そうでないところもあります。これは会計の明確さの問題にすぎません。CFOには、投資したお金を即座に資産計上できるという点にあまり夢中にならないようにと言いたいです。なぜなら、実際ソフトウェア企業が直面している問題でもあるのですが、そのやり方では、この事業への支出が過度に好意的に評価されてしまうからです。

もし、会計上、ソフトウェアに100万ドルを使うたびに「心配するな、資産価値は自動的に100万ドル増加する」と考えてしまうと、現実に基づかない非常に奇妙な問題に直面することになります。私の見解としては、その考えはほどほどにすべきです。会計の観点からは、ソフトウェア企業でどのように会計処理が行われているかを参考にし、国ごとに異なる一般原則に従うべきです。

これは本当に哲学的な原則です。つまり、影響力を持つ何かにお金を投資しているのか、単にその日の生存のためにお金を使っているのか、あるいは明日をより良くするために投資しているのかを問うべきです。私がキャペックスと言うとき、考えるべきは「お金、時間、労力は、明日、明後日、そして先の未来をより良くするためにだけ使う」ということです。

そして実際、その資産は減価償却されます―全くその通りです。Lokadの経験則として、比較的早いペースで減価償却が進みます。Lokadでは、2、3年ごとに数値レシピを完全に書き直すことになります。つまり、極めて長寿命な資産ではありませんが、投資を止めれば翌日には意思決定が行われなくなるようなものと比べ、3年以内に減価償却される資産があるというのは大きな違いとなります。たとえ数十年持続する資産がまだ存在しなくても、いくつかの企業では、多少長持ちする―場合によっては、大きな混乱を受けていない企業では、もう少し長く持続することもあります。もちろん、混乱の度合いが高いほど減価償却は加速します。

Conor Doherty: 質問やコメントはこれ以上ありません。しかし、締めくくる前に、今日ここで多くの話題を扱ったことを改めて伝えておきます。聞いてくださった皆さん、そして後で聴く皆さんへ、60秒間の行動への呼びかけです。

Joannes Vermorel: サプライチェーンに対するあらゆる投資が、この意思決定マシンの改善に貢献していることを必ず確認してください。これがあなたへの重要なメッセージです。自社のサプライチェーン組織を、意思決定マシンと捉えてください。正確な予測、計画、そして官僚的なタスクに固執するのはやめましょう。そういったものは単なる副産物であり、利益を生み出しているわけではありません。利益を生むのは、あなたが下し実行している意思決定だけなのです。

あなたは、自社をそのような意思決定を生み出す機械と捉えるべきであり、問い直すべきは、投資する資金が単に機械を動かし続けるための(電気や燃料のような)ものであるのか、それとも、機械をより良くするためのエンジニアリング、根本的な努力に充てられているのかということです。私の見解では、両方の要素が混在しているのが現実です。しかし、多くの企業では、ほぼ100%が機械を稼働させ続けるための純粋な運用費(OpEx)に頼っており、10年に一度、ベンダーと共に大規模なキャペックス投資を行っています。それは誤りだと考えます。もっと増分的に取り組むべきです。なぜなら、知的な取り組みに関しては、毎日の小さな投資が、10年に一度多額の資金を投入して、その後10年間何も行わない場合に比べ、はるかに大きなリターンをもたらすからです。こうしたオンオフの手法は非常に効果が薄く、それこそが企業向けソフトウェアベンダーを豊かにする一方で、あなたの会社の利益を圧迫する原因となります。

Conor Doherty: では、ジョアンネス、これにて質問は尽きたし、時間も尽きたと思います。いつもながら、貴重なご回答本当にありがとうございました。そして、参加してくださった皆さんにも感謝いたします。

ご質問とプライベートメッセージ、ありがとうございます。このテーマは内部的に敏感な面もあるため、本音を公にするのをためらう方もいらっしゃいます。しかし、私たち双方を代表して申し上げますが、いただいたメッセージには大変感謝しています。そして、プライベートで質問された方々は、私が尋ねた内容の中に、実際にプライベートで送られた質問が含まれていることにお気づきいただけると思います。

つまり、遠慮せずにご連絡ください。そして、その上で、仕事に戻りましょう.