00:00:07 現代のサプライチェーンにおけるソフトウェアデザインの重要性。
00:01:22 サプライチェーンマネジメントにおける一般的なソフトウェアデザインの問題。
00:02:37 サプライチェーンにおけるリアルタイムソフトウェアシステムの課題。
00:04:55 複雑な操作がリアルタイムシステムに与える影響。
00:07:13 リアルタイムシステムが非リアルタイム操作で詰まること。
00:09:13 サプライチェーンソフトウェアにおけるデザインの選択と時間スケールの重要性。
00:12:31 シングルテナントとマルチテナントソフトウェアの違い。
00:14:11 シングルテナントアプリケーションにおける複数バージョンのソフトウェアの課題。
00:15:33 マルチテナントソフトウェアの利点とSaaSモデルへの移行。
00:17:56 サプライチェーンのソフトウェアデザインにおけるコアの仮定の理解の重要性。
00:19:18 Lokadのコアデザインの仮定、バッチ処理モードとマルチテナンシーの重要性。
00:21:35 ソフトウェアの選択と将来の運用への影響を理解する上でのまとめの考え。
00:23:36 結びの思い。
概要
Lokadの創設者であるJoannes Vermorelとのインタビューで、サプライチェーンの最適化におけるソフトウェアデザインの影響について話し合われています。課題は、ソフトウェアの遅さ、直感的でない操作性、設定の難しさなど、バグやクラッシュではなく、デザインの問題から生じることが多いです。リアルタイムデータ処理は、操作に影響を与える重要な機能です。ただし、迅速でシンプルな操作に焦点を当てることは、予測やネットワーク全体の分析などの複雑なプロセスを妨げることがあります。ソフトウェアのデザインの仮定を理解することは重要であり、ソフトウェアのデザインと企業の意図した使用方法との不一致による問題を防ぐために必要です。
詳細な概要
このインタビューでは、ホストのKieran ChandlerがLokadの創設者であるJoannes Vermorelと共に、ソフトウェアデザインが企業の運用に与える影響について、特にサプライチェーンの最適化の文脈で議論しています。Vermorelは、現代のサプライチェーンが効率的に機能するために、ERP、MRP、WMS、OMS、EDIなど、複数のソフトウェアレイヤーに依存していることを強調しています。
Lokadのクライアントが直面する課題は、明らかなバグやクラッシュではなく、ソフトウェアのデザインに関する問題から生じることが多いです。これらのデザインの問題により、ソフトウェアは遅く、直感的でなく、設定が難しくなることがあります。Vermorelによれば、これらの問題は、ソフトウェアのコアデザインの決定と、それが対象とするサプライチェーンの実際の現実との不一致から生じることがよくあります。
サプライチェーンの運用に影響を与えるソフトウェアアーキテクチャの主要な特徴の1つは、リアルタイムデータの処理能力です。Vermorelは、光の有限な速度のために真のリアルタイムデータ処理は不可能ですが、多くのサプライチェーンソフトウェアシステムはリアルタイムデータ処理を近似するように設計されていると指摘しています。たとえば、商品が棚から取り出されると、ソフトウェアは在庫レベルをすぐに減らします。しかし、このリアルタイムなアプローチは、予期しない結果をもたらすことがあります。
ソフトウェアが迅速でシンプルな操作に設計されている場合、予測やネットワーク全体の分析などのより複雑な操作を実行することは困難になります。これらの複雑な操作には、リアルタイムで小規模な更新に最適化されたシステムでは実現が難しい、より洗練されたデータ処理レベルが必要です。
Joannes Vermorelは、サプライチェーンの最適化におけるソフトウェア設計の重要性を強調しています。Lokadのクライアントが直面する課題は、しばしばソフトウェアの設計上の問題に起因しており、ソフトウェアのコア設計の決定とサプライチェーンの実際の現実との不一致によって、ソフトウェアが遅く、直感的でなく、設定が困難になることがあります。リアルタイムデータの処理能力は、サプライチェーンの運用に影響を与えるソフトウェアアーキテクチャの主要な特徴の1つです。しかし、ソフトウェアが迅速でシンプルな操作に設計されている場合、予測やネットワーク全体の分析などのより複雑な操作を実行することは困難になります。これらの操作には、より洗練されたデータ処理レベルが必要です。
Vermorelは、このようなソフトウェアを使用するサプライチェーンの実践者が直面する問題は常に明白ではなく、彼が「千切りによる死」と呼ぶ問題の遅れた蓄積として現れることが多いと説明しています。
特定のシナリオ（例えば、高速コンベアベルト上のアイテムのスキャン）では、リアルタイムの機能が必要です。非リアルタイムの操作がシステムに導入されると、全体的なパフォーマンスに悪影響を及ぼし、遅延が発生する可能性があります。これにより、ユーザーの不満が増し、効率が低下する可能性があります。
Vermorelは、ソフトウェアが解決しようとしている問題と深く一致する正しいコア設計の選択の重要性を強調しています。サプライチェーンソフトウェアの文脈では、さまざまなコアの仮定が行われ、これらが満たされない場合、問題が発生する可能性があります。
ソフトウェアが動作するタイムスケールは重要な考慮事項です。Vermorelは、駆動コンベアベルトの応答時間がサブミリ秒であるようなタイムスケールから、数年または数十年にわたる工場配置の計画に関わる長期的な計画まで、さまざまなタイムスケールに必要な異なるタイプのソフトウェアについて説明しています。タイムスケールが1桁増えるごとに、ユニークな機能を持つ異なるタイプのソフトウェアが必要となります。
Lokadでは、通常、1日から1年までのタイムスケールに焦点を当てており、これにはソフトウェア設計に異なるアプローチが必要です。Vermorelはまた、マルチテナントソフトウェアとシングルテナントソフトウェアの違いに触れていますが、これはソフトウェア開発者にとって重要な考慮事項ですが、ほとんどの企業には馴染みがありません。
マルチテナントソフトウェアとシングルテナントソフトウェアの違い、SaaSモデルの利点、およびLokadのソフトウェア設計に影響を与えたコアの仮定について議論しています。
Vermorelは、マルチテナントソフトウェアは同じソフトウェアを複数のクライアントが使用する一方、シングルテナントソフトウェアは各クライアントに独自のカスタマイズバージョンを提供することを説明しています。Lokadはマルチテナントであり、週次で更新される1つのコードベースを使用しています。このアプローチには、バージョン管理の簡素化やセキュリティの問題の軽減など、いくつかの利点があります。これに対して、シングルテナントソフトウェアはクライアントごとのカスタマイズを可能にしますが、複数のバージョンを管理する必要があり、運用上の課題が生じます。
彼は、過去10年間で多くの重要なソフトウェア会社がマルチテナンシーに移行してきたと指摘しています。LokadのようなWebアプリケーションでは、マルチテナントであることは比較的簡単ですが、クライアントのマシン上で動作するソフトウェアの場合、より複雑になる場合があります。この問題への1つの解決策は、「常緑」戦略です。これは、Google ChromeやMicrosoft Office 365のようなアプリケーションが自動的に更新されるため、ユーザーの介入なしで同じソフトウェアの複数のバージョンの問題を軽減します。
Lokadのソフトウェア設計について話し合う際、Vermorelはベンダーのコアの仮定を理解することの重要性を強調しています。彼は、ソフトウェアがすべてを行えると主張するベンダーや、デザインがトレードオフ（trade-offs）であることを強調し、曖昧で肯定的な回答しか提供しないベンダーには注意するようクライアントに促しています。
Lokadのコアデザインの仮定には、Vermorelが最適化とリソース管理のために選択されるバッチ処理モードが含まれています。
1つの重要な原則は、速度よりもスマートな計算を優先することです。Lokadは、正確で詳細な計算を行うことを好みます。それによって時間がかかる場合でも、より速くて不正確な計算よりも優れた結果を得ることができます。このソフトウェアはリアルタイムではなくバッチ処理に設計されており、分析においてより表現力とパワーを持つことができます。
もう1つのコアの仮定は、マルチテナンシーの重要性とクラウドコンピューティングが提供する機能を受け入れることです。Lokadは、単一の強力なスーパーコンピュータに頼るのではなく、大量のデータを処理するために複数の小さなマシンを利用するスケールアウトの能力を活用することを目指しています。
Vermorelは、サプライチェーンの実践者がソフトウェアのコアデザインの仮定を理解することの重要性を強調しています。この理解によって、ソフトウェアのデザインと企業の意図した使用との不一致から生じる問題を防ぐことができます。ベンダーは自分たちのソフトウェアが多様な状況に対応できると主張するかもしれませんが、実際には特定のデザイン上の制約がいくつかのアプリケーションで効果を妨げる可能性があります。
フルトランスクリプト
Kieran Chandler: 今日は、これらの決定が会社を制約することについて理解し、それらの背後にあるいくつかのコアの仮定を理解することになります。では、ジョアネスさん、ソフトウェアの設計が会社にどのように影響を与えるかについて少し話しましょう。どのような課題が見られますか？
Joannes Vermorel: 最初の課題は、ソフトウェア設計がサプライチェーンにとって非常に重要であることです。現代のサプライチェーンはソフトウェアで動いています。トラック、機械、コンベアベルトだけでなく、ERP、MRP、WMS、OMS、EDIなどの大量のソフトウェアも含まれています。現代のサプライチェーンは、ソフトウェアなしでは動作しません。Lokadのクライアントと話をすると、彼らはサプライチェーンのアプリケーションの風景に苦労していることがよくあります。ソフトウェアに関連する問題はたくさんありますが、それは必ずしもバグやクラッシュではありません。デザインの問題はより普遍的であり、ものを遅くしたり直感的でなくしたり、システムの設定に永遠に時間がかかる原因となります。原因の分析を行おうとすると、実際にはソフトウェアのデザインに関する問題であり、ソフトウェアのデザインの中で基本的な決定が特定のサプライチェーンの実際の現実と完全に一致しなかったことがよくわかります。
Kieran Chandler: では、ソフトウェアのアーキテクチャのいくつかの特徴はなぜ重要なのでしょうか？クライアントとの取り組みでどのような課題が見られますか？
Joannes Vermorel: たとえば、リアルタイムです。現在の多くのサプライチェーンソフトウェアはリアルタイムの操作に向けて設計されています。リアルタイムとは、棚から1つのユニットを選ぶと在庫レベルがすぐに減少することを意味します。非常に合理的なことのように思えます。しかし、リアルタイムのために設計されたこの種のソフトウェアがあると、複雑な計算を行うことは非常に困難になります。その理由は、ソフトウェアが非常に迅速で単純な操作に最適化されているためであり、予測やネットワーク全体の分析などの複雑な操作を行う場合には苦労することになります。
Kieran Chandler: そして、もし大規模な詳細なバージョンがある場合、バーコードをスキャンしてビープ音を鳴らすなど、非常に高速な操作も遅くなってしまいます。これらの課題のいくつかはどれくらい明白ですか？サプライチェーンの実務者には同情せざるを得ません。多くのことが行われており、このソフトウェアには非常に多くのことが行われています。これらの課題のいくつかはどれくらい明白ですか？
Joannes Vermorel: 明白ではありません。通常、システムがクラッシュする明白なバグではありません。むしろ、千切りのようなものです。例を挙げましょう。リアルタイムで動作するシステムがあります。高速なコンベアベルトで何かがスキャンされた場合、1秒に3つのアイテムをビープ音で通知できるはずです。非常に高速でミリ秒単位の応答時間が必要です。
では、たまに数秒かかる計算がある場合はどうなるでしょうか？たまに数秒かかる1つの操作があるだけで、リアルタイムシステムがうまく設計されていれば、他のほとんどの操作は非常に高速のままであり、それほど問題ありません。ただし、運が悪い場合、同じ時点で複数の操作が数秒かかるような状況が発生すると、その時点ですべての計算リソースが吸収されます。
したがって、スキャンしてフィードバックを得ることができるはずだったシステムが突然1秒かかるようになります。理想的ではありませんが、それでも使えます。ただし、たまに、何かを超高速で期待していたのに、突然2〜3秒の遅延が発生することがあります。ちなみに、地元のスーパーマーケットでもそれが見られることがあります。ポイントオブセールでアイテムのビープ音が非常にスムーズに行われているのに、ある時点で何かをビープ音で通知し、3秒待つことがあります。
ここでは、リアルタイムシステムが非リアルタイムの操作に詰まってしまっています。何が原因かはわかりませんが、おそらくWindowsのアップデートや何らかの奇妙なことが原因でマシンが遅くなっています。ただし、リアルタイムシステムでは、スーパーファストな操作を実行するためには、スマートで複雑な操作は許可されません。
「千切りで死ぬ」と言うのは、最初にリアルタイムシステムで非リアルタイムの操作を行うと、実際には何も悪いことは起こらないでしょう。それはまれなことなので、まあまあ大丈夫です。しかし、問題は、非リアルタイムの操作をますます積み重ねていくことで、それらの問題が非常に頻繁になり、ますます頻繁になることです。そして、人々は「なぜこのコンベアベルトがもっと速く動かないのか？」と言って狂ってしまいます。
答えは、バーコードをスキャンするためのマシンがあり、システムの応答を待たなければならないからです。私はバーコードをスキャンした後にシステムが応答するまでに30秒かかる状況を見たことがあります。それは箱に印刷するためのものでしたが、コンベアはシステムがプリンタに注文を送信して箱に印刷する速度に制限されていました。プリンタの印刷を待っている人々がいました。
解決しようとしている問題と深く関連する方法で、コアの選択を正しく行うためには、多くの設計上の選択肢が必要です。
Kieran Chandler: サプライチェーンソフトウェアで行われている主な前提条件は何であり、どれが実際には機能していないと観察されていますか？
Joannes Vermorel: これには多くのアプローチ方法があります。まず、操作する時間スケールを考慮してください。コンベアベルトを直接制御するために必要なサブミリ秒の応答時間から、工場の配置のように10年先を考える必要がある決定まで、さまざまな時間スケールで動作するものがあります。桁を追加するたびに、ソフトウェアは根本的に変わります。
Kieran Chandler: 異なる時間スケールと対応するソフトウェアの例をいくつか教えていただけますか？
Joannes Vermorel: もちろんです。サブミリ秒は1つのタイプのソフトウェアです。1から10ミリ秒までは別のタイプのソフトウェアになります。10から100ミリ秒までは、通常ERPソフトウェアで、応答時間は10から100ミリ秒です。100ミリ秒から1秒までは、ウェブアプリで見つけることができるものです。そして、1分から10分先を考え始めると、リアルタイムではなくなりますが、高度な計算を行うことができます。例えば、Wazeのようなナビゲーションアプリは、30秒以内にルートを提供する必要がありますが、リアルタイムである必要はありません。
トラックの配送ルートを最適化する場合、結果を得るまでに通常数分かかることができます。リアルタイムである必要はありません。Lokadでは、通常、1日から1年の時間枠に焦点を当てています。これが私たちのスイートスポットであり、それ以前のすべてをほぼ無視できることを意味します。1年以上先に進むと、問題が変わり、より地図中心のサプライチェーン設計の領域に入ります。
Kieran Chandler: ソフトウェアの実装についてもっと話しましょう。シングルテナントとマルチテナントのソフトウェアの主な違いは何ですか？
Joannes Vermorel: シングルテナントとマルチテナントの違いは、同じソフトウェアでいくつのクライアントにサービスを提供するかです。Lokadのようなマルチテナントの場合、同じソフトウェアがすべてのクライアントにサービスを提供します。常に1つのバージョンがオンラインで展開されており、このソフトウェアは週次で更新されます。もう1つの方法は、SaaSの登場前により一般的だったシングルテナントです。このアプローチでは、各クライアントに独自のソフトウェアのコピーを提供し、大規模なクライアントに対してカスタマイズを行うことがしばしばあります。
ソフトウェアを作成すると、同時に実行される多くのバリアントのソフトウェアが発生するため、大きな運用上の問題となります。つまり、1つのバージョンでバグが発生した場合、このバージョンを修正する必要がありますが、他のすべてのバージョンでもバグが修正されていることを確認する必要があります。ところで、これはソフトウェア企業にとって、逆スケールの問題です。規模が大きくなるほど、バージョン管理に問題が発生します。ちなみに、これはOracleに非常に深刻な影響を与えています。例えば、Oracleデータベースでは、パフォーマンスを最適化した多くのカスタマイズバージョンがあります。内部情報は持っていませんが、公開情報だけでも、Oracleのいくつかのエンジニアリング部門では、ソフトウェアの多くのバリアントに苦労していることがわかります。もちろん、Oracleには多くのエンジニアリング能力がありますが、それでも大きな課題です。したがって、シングルテナントはクライアントごとのカスタマイズオプションを提供しますが、クライアントごとのオーバーヘッドに対処する必要があります。マルチテナントは、すべての人に対して1つのコードベースを提供し、カスタマイズはありませんが、それに対してはより速く進化することができ、セキュリティの問題も少なくなります。
Kieran Chandler: 市場がこのようなSaaSモデルに向かっていると言われている理由は何ですか？このモデルは企業により大きな柔軟性を提供するのでしょうか？
Joannes Vermorel: はい、過去10年間で、ほとんどの真剣なソフトウェアベンダーは、クラシックなデスクトップアプリケーションを含め、マルチテナンシーに移行してきました。明らかに、LokadのようなWebアプリケーションであれば、マルチテナントは非常に簡単です。自分自身のシステム上でスタッフを再配置すれば済むからです。もちろん、ブラウザのようなクライアントマシン上で動作するソフトウェア（例えば、Internet ExplorerやGoogle Chrome）の場合は、もう少し複雑です。なぜなら、クライアントマシンを制御することができないからです。しかし、ソフトウェアベンダーはどうしたかと言いますと、彼らは常緑戦略に切り替えました。例えば、Google Chromeはもはやブラウザの更新について尋ねません。GoogleがChromeのバージョンが古くなり、置き換える必要があると判断した場合、Googleはリモートでブラウザを更新します。もちろん、次回インターネットに接続し、その他の操作を行った場合にのみ、インターネット接続がない場合はソフトウェアを自動的に更新することはできません。ただし、インターネット接続が可能であり、マシンでアップグレードを防止するための特別な操作を行っていない場合、アップグレードは基本的にはあなたの介入なしで行われます。そして、MicrosoftがOffice 365で行っていることも同じです。過去には、Excelのバージョンを移行する際に、一連のMicrosoft Officeのバージョンがありました。現在では、オンデマンドであり、Microsoftがアップグレードを管理します。サブスクリプションを持っており、ソフトウェアがマシンにインストールされていますが、次のバージョンに自動的にアップグレードされることができます。そして、アップグレードオプションを無効にしない限り、Microsoftはデスクトップアプリケーションをすべてアップグレードします。これにより、同じソフトウェアの多くのバージョンが存在するという問題を軽減しています。
Kieran Chandler: それでは、Lokadについて少し話しましょう。ソフトウェア設計において将来の運用に本当に影響を与える可能性のある特定の基本的な仮定があると言いましたね。では、Lokadでどのような基本的な仮定を行いましたか？
Joannes Vermorel: それはたくさんありますが、基本的な仮定に入る前に、ひとつ注意点があります。もしソフトウェアベンダーに出会ったら、
Kieran Chandler: すべてのソフトウェアができると言われると、私たちは何も作っていない。ソフトウェアの仮定です。もし彼らがあなたに提供するのが、例えば「セキュリティのために設計されています」といった曖昧なものであれば、それは素晴らしいことです。「スピードのために設計されています」といったものも同様です。これらは非常に曖昧で、絶対的にポジティブなものです。しかし、設計について議論するとき、設計の観点はトレードオフです。それはポジティブな側面とネガティブな側面を持つものです。ですので、もしソフトウェアベンダーと議論できるのであれば、彼らが提供できるのがポジティブな側面だけである場合、おそらく彼らはまずソフトウェア設計の本質さえ理解していないのかもしれません。では、Joannes、Lokadに組み込まれた基本的な設計の仮定は何ですか？
Joannes Vermorel: 最初の仮定はバッチ処理モードでした。それはどういう意味でしょうか？私たちが望んでいるのは、大量のビッグデータを処理し、非常にスマートな計算を行うことです。明らかに、私たちは非常にスマートであることを好みます。非常に非常に速いことよりも、つまり、私たちにとっては、通常数分で実行される計算ができれば、数秒で実行されることはボーナスのようなものです。しかし、できない場合もそれほど大きな問題ではありません。少し時間がかかっても、より良い数値を持ちたいと思っています。ちなみに、私たちのパーツがあるからといって、私たちのホイールタイムがあるわけではありません。それは結果のプレゼンテーションです。ですので、大規模な計算には30分程度かかるかもしれませんが、その結果にアクセスしたい場合はリアルタイムである必要がありますが、事前計算されています。ですので、これは基本的な設計の仮定でした。リアルタイムではなく、バッチです。その理由は、非常に表現力豊かで非常にパワフルであり、ネットワールドワイドな分析に対してできるだけスマートであることを望んでいるからです。これが一つ目の基本的な仮定です。もう一つは、マルチテナンシーを持ちたいということでした。現在では、ほとんどの人々がそれを行っていますが、特にエンタープライズの領域ではまだ遅れている企業もあります。そして、私たちはすべてでマルチテナンシーを行いたいと思っていました。
Kieran Chandler: スケーラブルとスケールアウトの違いを説明してもらえますか？
Joannes Vermorel: クラウドが提供する機能のおかげで、私たちはスケールアップではなくスケールアウトの機能を持ちたいと考えています。問題は、テラバイト単位のデータを処理する場合、小さなマシンを山積みにすることでそれができるのか、それともスーパーコンピュータが必要なのかということです。
Kieran Chandler: では、今日の主な結論は何ですか？
Joannes Vermorel: 私たちの主な結論は、将来のソフトウェアの選択に関して、既に存在するデータやソフトウェアによって、将来の活動が制約される可能性があるということです。したがって、自分が行っている選択肢を完全に理解する必要があります。
Kieran Chandler: それについて詳しく説明してもらえますか？
Joannes Vermorel: サプライチェーンの専門家に対して、自分たちのアプリケーションの設計前提条件についてもっと意識してもらいたいと思います。彼らは多くのアプリを持っていますが、その製品の内外を説明する数個の重要なコード前提条件を教えてもらえますか。これは非常に技術的なことのように聞こえるかもしれませんが、これらの設計前提条件を理解していないと、設計上の問題が発生し、その製品がその用途に適していないことに気付いたときに非常に苦労することになります。私は多くの企業で、ソフトウェアの設計とそれを使用しようとしていることとの不一致から問題が発生しているのを見てきました。
Kieran Chandler: 例を挙げてもらえますか？
Joannes Vermorel: ベンダーは非常に自信を持とうとします。ベンダーとして、ソフトウェアを販売しようとしています。クライアントに対して自信を持って、あなたのサプライチェーンソフトウェアはあらゆる状況で素晴らしいものになるし、問題はないと伝えたいのです。しかし、現実は、クライアントがあなたのソフトウェアを設計の能力を超える用途に使用する場合、単にダクトテープで修正することはできません。機能を追加するだけでは済まないのです。バックエンドのソフトウェアエンジニアは、「ボス、ごめんなさい、それはできません。それは地獄になります」と言うでしょう。
Kieran Chandler: では、まとめましょう。ありがとうございました、Joannes。今週は以上です。ご視聴いただきありがとうございました。また次回お会いしましょう。それでは、さようなら。
