00:00:03 ITとサプライチェーンにおけるモジュール化の紹介。
00:00:26 物理的なサプライチェーンのモジュール性。
00:02:31 初期のITシステムのモノリシックな構造。
00:04:08 モノリシックシステムのITコンテキスト。
00:05:31 モジュラーソフトウェア設計へのインターネットの影響。
00:08:02 モノリシックソフトウェアシステムの問題点。
00:08:48 モノリシックシステムの非効率性。
00:11:16 モジュラーシステムへの移行：具体例。
00:13:34 モジュラーアプリケーションのシステム障害。
00:14:34 モジュラーシステムにおける冗長性と稼働時間。
00:16:00 大規模システムの信頼性とソフトウェアプロジェクトの障害。
00:16:50 Lidlの失敗したソフトウェア移行の例。
00:18:09 ソフトウェアプロジェクトにおける「早期失敗」の概念。
00:19:30 オーバーラップの管理、および「グルーソフトウェア」の重要性。
00:22:46 ソフトウェアの災害を回避する方法。
要約
Lokad TVのエピソードでは、Lokadの創設者であるJoannes Vermorelが、ビジネスのITインフラストラクチャにおけるモジュール化の重要性について議論しています。彼は、テクノロジーの制約による柔軟性の欠如から、1970年代と1980年代のモノリシックなITシステムに言及し、ネットワーク化システムへの移行にもかかわらず、ビジネスがITシステムをモジュール化するための継続的な課題を強調しています。Vermorelは、サービス指向アーキテクチャ（SOA）を潜在的な解決策として提案し、より小さな、明確に定義されたサービスの必要性を強調しています。彼は大規模なプロジェクトを行うことに慎重であり、「早期失敗」のアプローチを提唱しており、障害発生時のリスク管理と迅速な回復の重要性を強調しています。
詳細な要約
Lokad TVの現在のエピソードでは、ホストのKieran ChandlerがLokadの創設者であるJoannes VermorelとビジネスのITインフラストラクチャにおけるモジュール化についての議論を行っています。Vermorelは、主に物理的な世界のサプライチェーンとの類似点を引きながら、モジュール化の概念を説明しています。彼は、トラック、パレット、コンテナの例を使用して、モジュール化に関するポイントを明確にしています。Vermorelは、バーコードの普遍的な適用性を指摘することで、物理的なサプライチェーンの固有のモジュール性を強調しています。バーコードはほとんど何にでも取り付けることができるという点です。
物理的なサプライチェーンは明確なモジュール性を示しているものの、Vermorelは企業のITインフラストラクチャがしばしば同様の柔軟性を欠いていると指摘しています。彼は、これは1970年代と1980年代の企業内での初期のIT開発段階にさかのぼることを指摘し、当時の技術的な制約により初期のIT実装やERPシステムがスタンドアロンのモノリシックな構造として設計されたことに起因すると述べています。
Vermorelは、IT用語での「モノリス」とは、より小さな部分に分解できない統合されたアプリケーションを指すと述べています。彼は、さまざまなコンポーネントを必要に応じて組み合わせたり分離したりできる物理的なサプライチェーンで見られるモジュラリティとは対照的なモノリシックなアプローチの説明をしています。
複雑さにもかかわらず、Vermorelは初期のメインフレームが本質的に一貫性があり、すべての操作が集中して行われる単一のユニットとして機能していたことを説明しています。彼は、この形式のシステム設計が現在の世代にとっては時代遅れに思えると指摘し、分散システムやネットワークベースのアプリケーションに慣れた現在の世代におけるITインフラストラクチャの開発における重要な変化を示しています。
Vermorelは、90年代後半のインターネットの登場により、ネットワークで接続された分離された部分から構成されるソフトウェアの設計が始まり、景品が接続されたソフトウェアの設計が始まりました。しかし、彼は、多くの企業がモジュール化に苦労していると述べていますが、モジュール化されたITシステムの価値は理論的には十分に理解されていると述べています。
彼は、多くのベンダーがこれらの古いモノリシックなアーキテクチャをクラウドやSoftware as a Service（SaaS）モデルに適応させたことにより、メンテナンスが向上したシステムが提供されているが、モジュラリティは向上していないと説明しています。彼は、このモジュラリティの欠如が企業が特定の機能を分離して変更することを妨げていると述べています。
この問題を克服するために、Vermorelはサービス指向アーキテクチャ（SOA）を提案しています。これは、機能をより小さな、明確に定義された「チャンク」に分解するアプローチです。彼は、Amazonがこのモジュラーなアプローチを早期に成功裏に取り入れた企業の例として言及しています。
彼は、企業内のさまざまな部門でデータをエクスポートして利用できるAPIを備えたサービス指向アーキテクチャを提唱しています。モノリシックなシステムと比較して、分散型アプローチは故障の可能性がより高いと認識しているものの、冗長性と高品質のエンジニアリングによってこれらの課題を軽減できるとVermorelは主張しています。
Vermorelは、サプライチェーンのITプロジェクトのうち、3分の1から半分が失敗すると推定しています。彼は、ドイツのLidlの失敗したSAP移行で50億ユーロを失った事例を引用しています。彼は、小規模なベンダーから大規模なベンダーへの移行は失敗率をわずかに減らすだけであり、完全に排除するわけではないと主張しています。
複数のアプリケーションの管理に関して、Vermorelは、重複を最小限に抑えるためにスコープの狭いアプリケーションを選択し、ベンダーから大規模なフレームワークを購入することを避けることを提案しています。複数のアプリケーションを効果的に管理するために、彼は、サービス指向アーキテクチャによってこれらのアプリケーションを結びつけるための内部の「接着剤」を開発することが企業にとって重要であると述べています。
最後に、Vermorelは、Lidlの失敗したSAP移行のような「災害」を防ぐためのアドバイスを共有しています。彼は、リスク管理の観点で考え、失敗を早期に受け入れるアプローチを取ることを強調しています。彼は、プロジェクト管理において願望的な考え方を避け、潜在的な失敗に備えることと、迅速に回復する方法を見つけることの重要性を強調しています。
フルトランスクリプト
Kieran Chandler: こんにちは、Lokad TVの別のエピソードへようこそ。今週は、モジュール化について話し合います。モジュール化とは、会社のコンピュータプロセスを単独のシステムから他のサブプログラムやアプリに分割するプロセスです。いつものように、Joannes Vermorelが参加しています。では、Joannes、今日はどのようなビジネスプロセスの一部をよりモジュール化することについて話していますか？
Joannes Vermorel: 今日は、特に会社のITインフラストラクチャとアプリケーションの景品に焦点を当てています。モジュール化は興味深いです。物理的な世界を考えると、サプライチェーンは非常にモジュラーであることが明らかです。おそらく人類が発明した中で最もモジュラーなものです。モジュラーとは、例えば道路を通じて商品を輸送する場合、トラックを使用できるということです。トラックは非常にモジュラーであり、トラックの容量を超えないものであれば、ほとんど何でもトラックに積むことができます。トラックはどの道路でも走行でき、どこからでもどこへでも移動できます。必要な場合は、追加のトラックをほぼどの種類のトラックでも使用でき、サプライチェーンの輸送能力を追加できます。
同じことがパレットやコンテナにも当てはまります。容量を超えない限り、ほとんど何でもパレットやコンテナに入れることができます。コンテナは非常にモジュラーです。貨物船からトラックに移動することができます。これらのすべての部品は非常にモジュラーです。小さすぎない限り、ほとんど何にでもバーコードを貼ることができます。これは非常に現代的な発明です。ダイヤモンドのようなものがある場合、おそらく箱に入れてから箱の上にバーコードを貼ります。これらの単純な要素を自由に組み合わせることができ、ほぼ無限に組み合わせることができます。それは非常にレゴのようです。さまざまな方法で組み合わせることができる単純なパーツです。それが非常にモジュラーな物理的なサプライチェーンです。
しかし、興味深いことは、ITの世界に移ると、完全に異なる視点に入ることであり、頻繁にモジュール化が失われることです。私はそれが70年代または80年代初頭に遡ることを思い出します。企業が最初のコンピュータシステムと最初のERPの導入を始めた時期です。
Kieran Chandler: つまり、最初の導入、最初のITシステムは、非常に単一のアプローチだったため、今でもそれを使用しているということですか？それが言いたいことですか？
Joannes Vermorel: はい、その通りです。70年代、80年代、90年代初頭のITまたはソフトウェアを思い出してみると、ネットワークを介して何かを行うことはロケットサイエンスのようなものでした。可能ではありましたが、エンジニアリングの悪夢でした。複雑なソフトウェアシステムを多くのパーツで構築する方法がわからない場合、ネットワークを介して行うことはエンジニアリングの悪夢でした。このノウハウや文化、ツールは、一般の人々によるインターネットの普及の副産物として主に登場しました。
Kieran Chandler: では、モノリスとはどういう意味ですか？
Joannes Vermorel: モノリスとは、一つのアプリのようなものです。それを分解することはできません。一緒になければ何もありません。
Kieran Chandler: 私は少しミレニアル世代ですので、このような考え方は少し私よりも前のものかもしれません。しかし、基本的には、すべてが一つのマシンに接続されているということですね？そして、私たちはみんな接続して、そこから作業しているということですか？
Joannes Vermorel: まさにその通りです。メインフレームは比較的複雑なハードウェアのものでしたので、それが一つのマシンであっても。
Kieran Chandler: 私たちは主にERPについて話しています。つまり、企業資源管理システムです。これらのシステムは通常、拡張可能であり、追加の機能や機能を追加できるように設計されています。ただし、モジュラーではなく、それらの機能を完全に分離して保持することはできません。
Joannes Vermorel: 興味深いことは、本当に変わったのはおそらくインターネットです。インターネットの発明を指しているわけではありませんが、90年代後半にインターネットが非常に人気になり、ネットワークを介してパーツを分離して設計する方法について考え始めた人々がいました。これにより、ワークフローはエンジニアリングの悪夢ではありませんでした。これ以前は、多くのパーツで構成される複雑なソフトウェアシステムを構築する方法がわからない場合、ネットワークを介して行うことはエンジニアリングの悪夢でした。このノウハウや文化、ツールは、一般の人々によるインターネットの普及の副産物として主に登場しました。
Kieran Chandler: インターネットは長い間存在していますが、なぜ私たちはまだモジュール化について話しているのですか？なぜこれらのソフトウェアはまだこのような単一の方法で動作しているのですか？
Joannes Vermorel: 現在、私の診断結果は、複雑なサプライチェーンや多国籍企業を運営している平均的な企業が、物理的には非常にモジュール化されている一方で、ITを見ると完全にモノリシックであるということです。私は、企業や市場全体が、ITの観点で非常にモジュール化されたものの価値を十分に理解するのにまだ苦労していると考えています。物理的には、それはかなり明白であり、サプライチェーンはまだモジュール化を改善しています。しかし、アプリケーションの景色では、それはより抽象的であり、モジュール性をそのように知覚することはより困難です。
多くのベンダーは、古いモノリシックなアーキテクチャを取り、それをSaaSとクラウドに向けてわずかにアップグレードし、ただコピーして貼り付けました。それは基本的には、90年代のIBMメインフレームで持っていたものと同じようなアーキテクチャです。つまり、会社の本部にマシンを持っていてそれを実行する代わりに、SaaSとして動作するソフトウェアベンダに委任することを決めたのです。しかし、SaaSベンダが本部から遠く離れたマシンで実行されるモノリスしか持っていない場合、モダン化の観点からは何も追加されません。それは単にメンテナンスを容易にするだけです。しかし、機能を分解したい場合、このような機能は発生しません。
Kieran Chandler: このモノリシックなアプローチの問題は何ですか？それが実際の世界の企業にどのような影響を与えていますか？
Joannes Vermorel: モジュール化の欠如の物理的な相当物を想像してみてください。例えば、1つのトラックを変更するたびに、すべてのトラックを変更する必要があるとします。たとえば、1つのトラックから別のトラックに変更する場合、異なる種類のガソリンが必要です。したがって、すべてのガソリンスタンドを変更する必要があります。つまり、ガソリンが必要な場所にガソリンを含む貯蔵タンクがある必要があります。それは膨大な作業です。
このように、ソフトウェアの状況と同様に、モダン化の欠如は痛みを伴います。モダン化が不足していると、1つの部分を変更するとすべてを変更する必要があります。1つのトラックを変更する場合、すべてのフリートを変更する必要があります。1つの倉庫の棚を変更する場合、他のすべての倉庫の棚を変更する必要があります。さもないと、互換性がありません。そして、あなたは気付きます、良いですね、おそらく私は電気トラックに向けて私のトラックのフリートをアップグレードすることを決めることができますが、それは大規模な戦略的な動きになり、非常に複雑です。長い期間にわたって電気トラックと燃焼トラックが優雅に共存できる比較的モジュール化されたものを持っている方が良いと思います。モダン化が不足していると、このような共存をすることはできません。すべてを変更せずにサプライチェーンの一部を変更することはできません。
このモダン化の欠如の最も頻繁な証拠は、企業が物理的に1つの倉庫から別の倉庫に移動するために1日で行うことができるということです。倉庫Aの棚にあるものを倉庫Bの棚に移動するだけです。しかし、倉庫Aに接続されていたソフトウェアを倉庫Bに移行して、すべてのものが倉庫Bを駆動するシステムに存在することを知るようにするには、6ヶ月かかるでしょう。
Kieran Chandler: それは興味深いですね。もし大企業がこのモノリシックなシステムで存在している場合、どのようにしてよりモジュール化されたシステムに移行するのでしょうか？
Joannes Vermorel: 私たちはほぼすべてのエピソードで言及した企業の1つに戻ることになると思います、例えばAmazonのような。彼らは非常にモジュール化されたアプローチを採用した唯一の企業ではありません。ドイツのZalandoでは、ブログで追跡できるように、非常にモジュール化されたアプローチを完全に採用しました。そして、このモジュール化を実現するためのITのキーワードは、おそらくService Oriented Architecture（SOA）です。
L6 Service Oriented Architecture（SOA）とは、基本的には、自体が小さなモノリスのようなチャンクに機能を分離し、それらが一つのことをうまく行うように非常によくスコープされていることを意味します。そして、それらのすべての要素をService Oriented Architectureを介して組み合わせることができます。つまり、一つのことをうまく行うアプリであるという意味で、すべてのサービスはAPIを公開しており、任意のアプリケーション環境に簡単にプログラム的に組み込むことができます。それは、アプリケーション環境の他の部分が何であるかについてほとんどの仮定を行わずに、任意のアプリケーション環境にプログラム的に簡単に組み込むことができるように設計されています。
AmazonのJeff Bezosは、おそらく2002年に非常に有名なメモを公開しました。彼はすべてのチームに対して、データを他の部門で利用できるようにするために、サービス指向アーキテクチャ（SOA）とAPIを持つ必要があると述べました。そして、あなたが構築しているものとプログラム的に対話することができます。
Kieran Chandler: 問題は、より多くの小さなアプリ、小さなプログラム、小さな企業に依存するようになることです。それによって、単一障害点が多く導入されるのではないでしょうか？一方、モノリシックなアプローチを取る場合、常に稼働している堅牢な大企業、大規模なERPシステムがあるため、それに対する信頼性が高まります。
Joannes Vermorel: それは確かですし、ある程度は分散システムの課題の一つです。もしハードウェアが1%の確率で故障する場合、それはメインフレームを持っている場合です。
Kieran Chandler: ソフトウェアが1年に3回壊れると言いましたね。もし10個のアプリがそれぞれ1%の確率でダウンする場合、ネットワークのどこかで約10日ごとに何かがダウンしていることになります。確かに課題ですね。この状況に対してどのような解決策を提案しますか？
Joannes Vermorel: 冗長性がまず思い浮かびますが、分散コンピューティングの観点からの意味を議論したいと思います。そして、小規模企業と大規模企業、ベンダー内の格差について話しましょう。分散コンピューティングの観点からは、すべてのブロックが非常に冗長であることを確保することが目標です。これがクラウドコンピューティングの本質です。アップタイムを非常に高くするために、非常に冗長なソフトウェアを持つことを望みます。
良いニュースは、アプリが小さくシンプルであるため、非常に高いアップタイムを実現するのは非常に簡単です。インターネット上には常にオンになっているコンポーネントサービスがたくさんあります。例えば、Googleメールは常にオンです。Yahooのウェブサイトも基本的に常にオンです。Facebookも常にオンです。したがって、アプリにこれらの「常にオン」の特性をエンジニアリングすることは可能であり、システム全体の信頼性に対応します。
Kieran Chandler: 一つの大規模ベンダーから多くの小規模ベンダーへの移行はどうですか？
Joannes Vermorel: 現実的には、ソフトウェアの故障率は高いです。多くの人々は気づいていないかもしれませんが、ソフトウェアの取り組みのうち、おそらく半分は失敗します。私の推定では、ほぼどのような規模の企業でも、サプライチェーンのITプロジェクトの3分の1から半分が失敗します。数週間前、ドイツのLidlは、失敗したSAPの移行に約5億ユーロを投じました。7年間のプロジェクトは失敗に終わり、最終的には諦めました。しかし、これは唯一の例ではありません。これはかなり頻繁に起こります。
大規模ベンダーの方がおそらく成功率が高いですが、おおよその数字で話している場合、50%の失敗率を持つ小規模ベンダーから30%の失敗率を持つ大規模ベンダーに移行することになります。したがって、小規模企業から大規模企業に移行すると、リスクはわずかに減少しますが、ほんのわずかです。
高度にモジュール化されたアプローチを選択する場合、はい、多くのものが失敗する可能性がありますが、成功するまで何度も試す機会があります。各コンポーネントは失敗する可能性がありますが、スコープが簡単なため、アプリ自体が小さくなり、素早く失敗して再試行することができます。
Lidlのアプローチの問題は、おそらく最初は7年間の移行を計画していなかったことです。おそらく2年間の移行が3年間になり、さらに4年間になり、失敗し、再試行し、再び失敗したためです。7年後、プロジェクトが成功する見込みがなくなったため、彼らはついに諦めることを決めました。
Kieran Chandler: したがって、適切なものを見つけ、少し改良することで、これらのアプリは信頼性があるということに同意する場合…それらは動作し、大規模なシステムと同じ仕事をしているように思われます。それらのアプリのクロスオーバーについてはどうですか？多くの場合、アプリは他のこともうまく行い、そのシステム内でクロスオーバーや競合が生じる場合があります。それをどのように管理しますか？
Joannes Vermorel: まず、アプリケーションの構成を選択する際には、スコープが狭いアプリを選ぶことが重要です。このアプローチは、ほとんどの提案依頼（RFP）が行うこととはまったく逆です。企業がソフトウェアの一部を取得しようとするとき、彼らはしばしばRFPを行い、すべての機能、すべてのベルとホイッスルを求めます。しかし、それは求めるべきものとは正反対です。設計上、スコープが非常に狭いものを求めることで、重複を最小限に抑えることができます。
大規模なフレームワークを購入すると、重複が発生する可能性があります。エンタープライズベンダーは、多くの機能を追加できるように大規模なフレームワークを販売することに興味があります。彼らは何かを販売し、それに追加の機能を販売します。したがって、大規模なサプライチェーンを運営している人々には、プラットフォームが販売される際に非常に注意することをお勧めします。
プラットフォームは良いものですが、2つのプラットフォームは悪夢になることがあります。複数のベンダーからプラットフォームを販売されると、重複の海になります。解決策は、成分の構成を注意深く選ぶことです。
「接着剤」に関しては、通常、内部で開発する必要があるものです。これは、なぜ自社でソフトウェアを開発したいのかという直感に反するかもしれません。その答えは、一定の規模の会社であれば、アプリケーションのランドスケープは完全に独自のものであるということです。
標準のアプリをすべて使用しても、複数のアプリが必要です。ERPでメールやビデオ会議などを行うことはできません。必要なすべてのソフトウェア機能を1つのアプリに詰め込むことはできません。おそらく他の人と同様にMicrosoft Excelを使用するでしょうので、ファイルを保存する場所が必要になります。
1つのソフトウェアを持っているとは現実的ではありません。重要な規模の会社は、いずれにせよソフトウェアの集合体になります。具体的なレシピ、つまり文字通り会社を運営するために必要なソフトウェアのリストは、あなたに完全に固有のものになるでしょう。他の会社はあなたとまったく同じように組織されていません。
Kieran Chandler: それは完全に固有のものであり、それがあなたのDNAです。自社内で実装するこの接着剤を持つことができます。それがサービス指向アーキテクチャの全体のポイントであり、この接着剤を非常にシンプルで効率的に実装することで、最小限の努力で非常にシンプルなITチームを持つことができます。すべてをつなぎ合わせるためのカスタムソフトウェアを作成します。では、まとめると、もし私がCEOなら、どのようにして別のLidlのような災害を避けることができるでしょうか？
Joannes Vermorel: まず、リスクを最小化するのではなく、リスクを考えることが重要だと思います。Lidlのような災害は、「絶対にリスクを取りたくない」という人々が言った結果であり、そこで最も大きなベンダーを選び、すべてを行う製品を持ちたいと考えました。基本的には、設計上正しいものを求め、一度に会社全体をアップグレードするものを展開したいというアプローチです。これは、リスク管理の観点から最悪のアプローチです。
完全に逆の考え方をする必要があります。つまり、「もし失敗する必要があるなら、どのようにすれば速やかに失敗できるか」ということです。リスクの問題は、この大規模なプロジェクトでは長い期間、失敗したかどうかわからないということです。あなたが望むのは、より「速やかに失敗する」ものであり、もし失敗した場合には、その失敗が小規模な範囲で起こることを知ることです。そして、もし置き換えが必要な場合には、管理可能な範囲で行うことです。そして、それを多くの小さなチャンクで行います。
ですから、リスクを防ぐのではなく、リスクを考えるということです。大手ベンダーから小規模なベンダーに移行することで、リスクを50％の失敗の可能性から50％に増やすかもしれません。最終的には、30％の失敗の可能性が、会社が破産するか、供給チェーンが停止するリスクである場合、それはあなたが取ることのできないリスクです。ですから、どのような場合でも失敗に備える必要があります。
私の考えは、高度なリスクを避けられないため、失敗に備える計画に直接取り組むことです。小さな、速い、そしてスコープの管理可能な失敗を持つようにし、反復できるようにすることです。最初からすべてを正しく行うという考え方ではなく、願望的な考え方です。そして、最終的には7年間続く可能性がある旅に乗り出し、その過程で5億ユーロを失うような願望的なプロジェクト管理についての考え方です。
Kieran Chandler: 素晴らしい、気に入りました。Lokadの今日のヒント：もし失敗するなら、速やかに失敗してください。素晴らしいですね。それでは、今週はこれで全てです。来週もまた別のエピソードで戻ってきます。それまで、ご視聴ありがとうございました。
