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 終了の考察。
概要
Joannes Vermorel（Lokadの創設者）とのインタビューでは、供給チェーンの最適化に対するソフトウェア設計の影響について語られています。問題はバグやクラッシュではなく、設計上の欠陥から生じ、ソフトウェアが遅く、直感的でなく、設定が難しくなる原因となります。リアルタイムなデータ処理はオペレーションに大きな影響を与える重要な特徴ですが、迅速かつシンプルなオペレーションに偏ると、予測やネットワーク全体の解析などの複雑なプロセスが妨げられる可能性があります。ソフトウェアの設計前提を正しく理解することは、企業が意図する利用方法と実際の設計との間のずれによる問題を防ぐために極めて重要です。
拡張概要
このインタビューでは、司会のKieran ChandlerがLokadの創設者Joannes Vermorelと共に、特に供給チェーン最適化の文脈におけるソフトウェア設計が企業オペレーションに与える影響について議論しています。Vermorelは、現代の供給チェーンが、ERP、MRP、WMS、OMS、EDIなどの多層的なソフトウェアに依存して効率的に機能していることを強調します。
Lokadのクライアントが直面する課題は、明らかなバグやクラッシュではなく、ソフトウェア設計上の問題に起因することが多いです。これらの設計上の問題は、ソフトウェアを鈍く、直感的でなく、遅延を引き起こし、システムの設定に非常に時間がかかる原因となります。Vermorelによれば、これらの問題は、ソフトウェアの基本設計の決定と、実際に対応すべき供給チェーンの現実との間の不一致から生じることが多いといいます。
ソフトウェアアーキテクチャの主要な特徴の一つは、リアルタイムデータを処理する能力です。Vermorelは、光の速度という物理的限界のために真のリアルタイム処理は不可能であるものの、多くの供給チェーンソフトウェアは、リアルタイム処理の近似を目指して設計されていると指摘します。例えば、棚から商品が取り出されると、ソフトウェアは直ちに在庫レベルを減算します。しかし、このリアルタイム方式には、意図しない結果が伴うことがあります。
ソフトウェアが迅速でシンプルな操作用に設計されている場合、予測やネットワーク全体の解析といった複雑な操作を実行するのは困難になります。これらの複雑な操作は、より高度なデータ処理能力を要求し、リアルタイムかつ小規模な更新に最適化されたシステムでは対応が難しい場合があります。
Joannes Vermorelは、供給チェーン最適化におけるソフトウェア設計の重要性を強調します。Lokadのクライアントが直面する課題は、ソフトウェアの基本設計の決定と現実世界の供給チェーンとのミスマッチが原因で、ソフトウェアが遅く、直感的でなく、設定が複雑になる点にあります。リアルタイムデータ処理の能力は、供給チェーンの運用に影響を及ぼすソフトウェアアーキテクチャの主要な側面ですが、迅速でシンプルな操作のために設計されたシステムでは、予測やネットワーク全体の解析など、より複雑な処理の実行が困難になります。
Vermorelは、この種のソフトウェアを用いる供給チェーン実務者が直面する問題は、システムクラッシュのような明白な障害ではなく、いわゆる「千のカットによる死」とも呼ばれる、徐々に蓄積される問題として現れると説明します。
一つの重要な問題は、例えば高速コンベヤーベルト上での商品のスキャンなど、特定のシナリオでリアルタイム機能が必要とされる点です。非リアルタイムの処理がシステムに導入されると、全体のパフォーマンスが低下し、遅延が発生しやすくなります。これにより、ユーザーのフラストレーションが増し、効率が損なわれる可能性があります。
Vermorelは、ソフトウェアが解決しようとする問題に深く合致した正しい基本設計の選択を行うことの重要性を強調します。供給チェーンソフトウェアでは、様々な基本前提が採用されており、これらが満たされなければ、後に問題が発生する可能性があります。
ソフトウェアが動作する時間軸は重要な考慮事項です。Vermorelは、コンベヤーベルトの駆動に必要なサブミリ秒の応答時間から、工場配置の意思決定など数年から数十年に及ぶ長期計画まで、様々な時間軸に対応するための異なるソフトウェアのタイプについて述べています。時間スケールが大きくなるごとに、各段階で必要とされるソフトウェアの特性は変わります。
Lokadでは、通常1日から1年という時間軸に焦点を当てたソフトウェア設計が行われており、これには独自のアプローチが求められます。Vermorelはまた、ソフトウェア開発者にとって重要なシングルテナントとマルチテナントの違いにも触れていますが、多くの企業にはあまり馴染みがありません。
彼らは、マルチテナントとシングルテナントのソフトウェアの違い、SaaSモデルの利点、そしてLokadのソフトウェア設計を支える基本前提について議論します。
Vermorelは、マルチテナントソフトウェアは同一のソフトウェアを用いて複数のクライアントにサービスを提供する一方、シングルテナントソフトウェアは各クライアントにカスタマイズされたバージョンを提供するものであると説明します。Lokadはマルチテナントであり、単一のコードベースが週単位で更新されます。このアプローチには、バージョン管理の簡素化やセキュリティ問題の低減といった利点があります。Vermorelは、クライアントごとのカスタマイズが可能なシングルテナントソフトウェアと比較して、複数バージョンの管理が必要になるために運用上の課題が発生すると述べています。
彼は、過去10年間で多くの大手ソフトウェア企業がマルチテナント方式に移行していると観察しています。Lokadのようなウェブアプリケーションではマルチテナントであることは比較的簡単ですが、クライアントのマシン上で動作するソフトウェアでは、より複雑な問題となることがあります。この問題に対する一つの解決策として、Google ChromeやMicrosoft Office 365に代表される「エバーグリーン」戦略が挙げられます。これらのアプリケーションはユーザーの介入なしに自動更新され、同一ソフトウェアの複数バージョン運用の問題を緩和しています。
Lokadのソフトウェア設計について議論する際、Vermorelはベンダーの基本前提を理解することの重要性を強調します。彼は、ソフトウェアが何でもできると主張するベンダーに警告し、設計はトレードオフに関するものであり、肯定的な側面と否定的な側面の両方を伴うと述べています。彼は、潜在的なクライアントに対してソフトウェアベンダーの基本前提について質問し、あいまいで肯定的な回答しか得られないベンダーには注意するよう促しています。
Lokadの基本設計前提には、より良い最適化とリソース管理を可能にするために選ばれたバッチ処理モードが含まれています。
もう一つの重要な原則は、スピードよりもスマートな計算を優先することです。Lokadは、迅速だが不正確な計算よりも、時間がかかっても正確で詳細な計算を行うことを重視しています。ソフトウェアはリアルタイム処理ではなくバッチ処理向けに設計されており、これにより分析の表現力とパワーが向上します。
もう一つの基本前提は、マルチテナンシーの重要性と、クラウドコンピューティングが提供する機能の活用です。Lokadは、スケールアップではなくスケールアウトの手法、つまり大量のデータ処理において単一の高性能マシンに頼るのではなく、複数の小型マシンを利用する戦略を採用しています。
Vermorelは、供給チェーンの実務者がソフトウェアの基本設計前提を理解することの重要性を強調します。この理解により、ソフトウェアの設計と企業の意図する利用との間に生じるミスマッチによる問題の発生を防ぐことができます。ベンダーは自社のソフトウェアが多用途であらゆる状況に対応できると主張するかもしれませんが、実際には特定の設計上の制約がその有効性を損なう可能性があります。
完全な文字起こし
Kieran Chandler: 今日は、これらの決定がどのようにして企業を型にはめ、またそれらの背後にある基本前提を理解する助けとなるのかを見ていきます。さて、Joannes、ソフトウェアの設計不良が企業にどのような影響を与えるかについて少し話していただけますか？どのような課題が見受けられますか？
Joannes Vermorel: 最初の課題は、ソフトウェア設計が供給チェーンにおいて極めて重要であるということです。現代の供給チェーンはソフトウェアによって稼働しています。トラックや機械、コンベヤーベルトが存在する一方で、ERP、MRP、WMS、OMS、EDIなどの大規模なソフトウェア層も必要です。現代の供給チェーンは、大量のソフトウェアなしには機能しません。Lokadのクライアントと話すと、彼らは供給チェーンのアプリケーション環境に対してしばしば苦労していることがわかります。多くのソフトウェア関連の問題はありますが、それらは必ずしもバグやクラッシュによるものではありません。設計上の問題はより広範囲に及び、システムを鈍化させ、直感的でなく、設定に非常に時間がかかる原因となります。原因分析を進めると、問題は基本設計の決定と対象となる供給チェーンの実態との不一致に起因していることが多いのです。
Kieran Chandler: では、ソフトウェアアーキテクチャのどのような特徴が非常に重要だと考えられますか？クライアントで見受けられる課題にはどのようなものがあるのでしょうか？
Joannes Vermorel: 例えば、リアルタイム処理の場合を考えてみましょう。現代の多くの供給チェーンソフトウェアはリアルタイムオペレーションを前提としています。リアルタイムとは、棚から一つの商品を取り出すと、その瞬時に在庫レベルが減少するということです。一見合理的に思えます。しかし、このようなリアルタイム用に設計されたソフトウェアでは、洗練された計算処理が実施されると大きな負担となります。なぜなら、ソフトウェアが非常に迅速でシンプルな操作向けに設計されているため、予測やネットワーク全体の解析といった複雑な計算処理が困難になるからです。
Kieran Chandler: そして、もし非常に詳細なバージョンが存在すると、バーコードのスキャンなど、本来極めて迅速であるべき操作も全体的に遅延してしまいます。供給チェーンの実務者の立場からすると、裏で非常に多くのことが同時に進行しているため、その影響を感じざるを得ないでしょう。
Joannes Vermorel: 明らかではありません。というのも、通常はシステムクラッシュのように明瞭なバグとして現れるのではなく、「千のカットによる死」とも言えるように、徐々に問題が蓄積されるからです。例を挙げると、高速コンベヤーベルト上で何かがスキャンされると、通常は1秒間に3アイテム程度処理され、本来はミリ秒単位の応答があるはずです。
さて、もしたまにミリ秒ではなく数秒かかる計算処理が発生した場合、1回だけであれば大抵の他の操作は非常に高速なままで問題にはならないかもしれません。しかし、運が悪く、同時に10種類もの操作が数秒を要するなら、その瞬間、全ての計算資源が消費されてしまいます。
その結果、本来ミリ秒単位でフィードバックを提供すべきシステムが、突然1秒の遅延を引き起こすことになります。これは理想的ではありませんが、ある程度は許容されるでしょう。しかし、まれに、非常に高速な応答が期待される場面で突然2～3秒の遅延が発生することがあります。ちなみに、地元のスーパーマーケットでも、レジのビープ音は非常にスムーズに流れているものの、ある瞬間にビープ音が鳴り、3秒の遅延が発生し、再びビープ音が鳴ることがあるのです。
Joannes Vermorel: ここでは、本来リアルタイムであるべきシステムが、非リアルタイムの操作によって詰まれてしまった例を示しています。何が原因であったのかは分かりませんが、もしかするとWindows Updateやその他の予期せぬ事象により、マシンが遅延してしまったのかもしれません。しかし、リアルタイムシステムでは、複雑またはスマートな操作は、求められる超高速な処理を劣化させるため、許容されないのです。
私が「千の小刃による死」と言うのは、リアルタイムシステムで非リアルタイムの処理を初めて行うときは、たいてい大きな問題が起こらないからです。稀なケースなので、ある意味大丈夫なんです。しかし問題は、非リアルタイムの処理をどんどん積み重ねると、もともと非常に稀だった問題が次第に頻繁になり、最終的には超頻繁に発生するようになる点です。すると人々は「なぜこのコンベアベルトはもっと速く動かないんだ？もっと速くできるはずだ」と大騒ぎし始めます。
答えは、バーコードをスキャンするための機械があり、システムからの応答を待たなければならないからです。バーコードをスキャンした後、システムが応答するまでに30秒もかかった事例を見たことがあります。箱に貼る印刷物を出力するためでしたが、コンベアはシステムがプリンターに注文を伝える速度によって制限されていました。そのため、人々はただプリンターの印刷完了を待っていたのです。
解決すべき問題に深く連動した形で、根本的な選択肢を非常に正確に決める必要がある多くの設計上の選択肢があります。
Kieran Chandler: サプライチェーンソフトウェアで採用されている主要な前提は何ですか？また、うまく機能していないと観察されたものはどれですか？
Joannes Vermorel: これに取り組む方法はたくさんあります。まず、運用したい時間スケールを考えてみてください。コンベアベルトを実際に駆動するために必要なサブミリ秒単位の応答時間から、工場の配置のように10年先を見据える決定まで、様々なものがあります。桁が一つ増えるたびに、ソフトウェアは根本的に変わってしまうのです。
Kieran Chandler: 異なる時間スケールと、それに対応するソフトウェアの種類の例をいくつか挙げてもらえますか？
Joannes Vermorel: もちろんです。サブミリ秒が一つのタイプのソフトウェアで、1～10ミリ秒のものはまた別のタイプ、10～100ミリ秒のものはさらなるタイプで、これは通常、ERPソフトウェアとして応答時間が10～100ミリ秒です。100ミリ秒から1秒の場合は、ウェブアプリで見られるようなものになります。そして、1分から10分先を見据えると、もはやリアルタイムではなくなりますが、複雑な計算が可能になります。例えば、Wazeのようなナビゲーションアプリは30秒以内にルートを提示する必要がありますが、必ずしもリアルタイムである必要はありません。
トラックの配送ルートを最適化する場合、リアルタイムでなくても良いので、結果を得るのに通常数分かかることがあります。Lokadでは、主に1日から1年の時間枠に焦点を当てています。これが私たちにとっての理想的な範囲であり、その前の部分はほとんど無視できるということです。1年を超えると、サプライチェーン設計という領域に入り、より地図中心となり、問題自体が変わってしまいます。
Kieran Chandler: ソフトウェアの実装についてもう少し話しましょう。シングルテナントとマルチテナントソフトウェアの主な違いは何ですか？
Joannes Vermorel: シングルテナントとマルチテナントの違いは、同じソフトウェアで何社のクライアントにサービスを提供するかという点にあります。Lokadのようなマルチテナントの場合、すべてのクライアントに同一のソフトウェアを提供します。オンラインに展開しているのは常に1つのバージョンで、毎週アップデートを行っています。一方、SaaSが普及する前によく見られたのがシングルテナントです。この方式では各クライアントに独自のソフトウェアのコピーを提供するため、大口クライアント向けのカスタマイズが多くなります。
ソフトウェアを製造すると、結果的に同時に稼働している多くのバージョンができあがってしまい、運用上大きな問題となります。というのも、あるバージョンにバグが発生した場合、そのバージョンを修正しなければならず、同時に他の全てのバージョンにも修正を反映させなければならないからです。ちなみに、これはソフトウェア企業にとって、規模が大きくなるほど逆効果になる、「スケールの逆経済性」と言える問題です。たとえば、Oracleデータベースではこの問題が非常に深刻で、パフォーマンス最適化のために大幅にカスタマイズされたバージョンが多数存在しています。内部情報ではありませんが公開情報からも、Oracleの複数のエンジニアリング部門が多数のバリアントに苦しんでいるのが分かります。もちろん、Oracleには膨大なエンジニアリング能力がありますが、それでも依然として大きな課題となっているのです。つまり、シングルテナントはクライアントごとのカスタマイズが可能という選択肢を与えますが、その分クライアントごとのオーバーヘッドに直面します。マルチテナントは全員が共通のコードベースを使うためカスタマイズはなく、その代わり進化が速く、セキュリティの問題も大幅に減少します。
Kieran Chandler: 市場がそのようなSaaSモデルに大きく移行していると言うとき、なぜそのモデルがそれほど優れているのですか？企業にとってより柔軟性が高いということなのでしょうか？
Joannes Vermorel: はい、過去10年間でほぼすべての本格的なソフトウェアベンダーは、古典的な従来のデスクトップアプリケーションでさえ、マルチテナントに移行してきました。もちろん、Lokadのようなウェブアプリであれば、マルチテナントは非常にシンプルです。自社のシステム上で再展開すれば済むのです。しかし、クライアントのマシン上で動作するソフトウェア、たとえばブラウザ（Internet ExplorerやGoogle Chromeなど）の場合は、クライアントマシンの管理ができないため、より複雑になります。しかし、ソフトウェアベンダーはどうしたと思いますか？彼らは常に最新の状態を保つ「エバーグリーン戦略」に切り替えたのです。例えば、Google Chromeはもはやブラウザの更新をユーザーに尋ねません。GoogleがあなたのChromeのバージョンが古くなって交換が必要だと判断すると、遠隔でブラウザを更新します。もちろん、次回インターネットに接続するときに、接続がなければ更新は起こりませんが、インターネット接続があり、特別な対策をしていなければ、基本的にユーザーの介入なしにアップグレードされるのです。そして、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。今週の内容はこれで以上です。ご視聴ありがとうございました。また次回お会いしましょう。さようなら。
