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 ソフトウェアプロジェクトにおける「Fail fast」概念。
00:19:30 重複管理と「グルー」ソフトウェアの重要性。
00:22:46 ソフトウェア災害の回避。
概要
Lokad TVのエピソードでは、Lokadの創設者ジョアネス・ヴェルモレルが、ビジネスITインフラにおけるモジュラー化の重要性について議論し、サプライチェーンの適応性と比較しています。彼は、70年代や80年代の技術的制約により柔軟性の欠如が目立ったモノリシックなITシステムに触れます。インターネット普及以降も、企業がITシステムをモジュラー化する課題は依然として残っています。ヴェルモレルは、より小さく明確に定義されたサービスの必要性を強調し、サービス指向アーキテクチャ（SOA）を一つの解決策として提案しています。大規模プロジェクトのリスクを回避するため、「Fail fast」アプローチを採用し、リスク管理と迅速な回復の重要性を説いています。
詳細な要約
今回のLokad TVのエピソードでは、司会のキアラン・チャンドラーがLokad創設者のジョアネス・ヴェルモレルと、ビジネスITインフラにおけるモジュラー化について議論します。ヴェルモレルは、主に物理的サプライチェーンと比較しながらモジュラー化の概念を解説し、これを人類が生み出した中で最もモジュラーな仕組みと位置付けています。
彼はトラック、パレット、コンテナの例を用い、モジュラー性について説明します。ヴェルモレルは、ほとんど何にでも付けられるバーコードの普遍性を指摘することで、物理的サプライチェーンの本来的なモジュラー性を強調しています。
物理的サプライチェーンが明確なモジュラー性を示す一方で、企業のITインフラは同様の柔軟性を欠いていると彼は指摘します。このモジュラー性の欠如は、1970年代や1980年代における企業の初期IT導入やERPシステムが技術的制約のためにスタンドアロンのモノリシックな構造として設計されたことに起因しています。
ヴェルモレルは、ITの文脈で「モノリス」とは、分割できない一体のアプリケーションを意味すると述べています。これは、必要に応じて組み合わせたり分離できる物理的サプライチェーンのモジュラー性と対照的です。
複雑でありながら、初期のメインフレームは全ての操作が中央集約され一体となって機能していたため、本質的に一貫していました。彼は、このシステム設計が、分散システムやネットワークベースのアプリケーションに慣れた現代世代には時代遅れに感じられると述べ、ITインフラの発展における大きな変化を示しています。
ヴェルモレルは、1990年代後半にインターネットの普及に伴い、各部を分離してネットワーク経由で連携させるソフトウェア設計が始まったことで状況が変わり始めたと指摘します。しかし、多くの企業が理論上モジュラーITシステムの価値を認識しているにもかかわらず、実際のモジュラー化には苦労していると述べています。
彼は、多くのベンダーが古いモノリシックなアーキテクチャを、SaaSやクラウド向けにわずかにアップグレードしただけで、基本的にはコピー＆ペーストに留まっていると説明します。これは、1990年代のIBMメインフレームでのアーキテクチャと根本的に同じもので、企業本社に設置されたマシンで処理する代わり、SaaSとして提供するベンダーに委ねられているだけです。しかし、もしSaaSベンダーが運用しているのが、ネットワークとウェブユーザーインターフェースがわずかに加わったモノリスであるなら、近代化においては何の価値も追加されず、単に保守が容易になるだけです。機能を分離しようとしても、依然としてモノリシックな構造の障壁に直面することになります。
この問題を解決するために、ヴェルモレルは機能を小さく、明確に定義された「チャンク」に分解するサービス指向アーキテクチャ（SOA）を提案しています。彼は、このモジュラーアプローチを初期に採用した企業としてAmazonを例に挙げています。
彼は、APIを通じて企業内の各部門間でデータをエクスポートし活用できるサービス指向アーキテクチャを推奨します。分散型アプローチはモノリシックシステムに比べて故障点が増える可能性があると認識されがちですが、ヴェルモレルは、冗長性と高い技術力によってこれらの課題は十分に緩和可能だと主張しています。
ヴェルモレルは、サプライチェーンのITプロジェクトの3分の1から半数が失敗に終わると見積もっています。彼は、失敗したSAP移行で5億ユーロを失ったドイツのLidlの事例に触れ、小規模ベンダーから大規模ベンダーへの移行が失敗率をわずかに下げるに過ぎず、根本的な問題の解決には至っていないと論じています。
複数のアプリケーション管理に関して、ヴェルモレルは重複を最小限に抑えるため、狭い範囲に特化したアプリケーションを選ぶべきだと提案し、大規模なフレームワークをベンダーから購入することに反対しています。複数のアプリケーションを効果的に管理するためには、サービス指向アーキテクチャによって促進される、これらのアプリケーションを結合する内部の「グルー」を開発する必要があると述べています。
最後に、ヴェルモレルは、Lidlの失敗したSAP移行のような災害を防ぐためのアドバイスを共有します。彼はリスク管理の観点から物事を考え、「Fail fast」アプローチを取ることの重要性を強調します。プロジェクト管理において希望的観測に頼るべきでなく、潜在的な失敗に備え迅速に回復する方法を計画するべきだと説いています。
完全なトランスクリプト
キアラン・チャンドラー: こんにちは。Lokad TVの新たなエピソードへようこそ。今週は、モジュラー化、つまり企業のコンピュータプロセスを単一システムから複数のサブプログラムやアプリへと分割するプロセスについて議論します。いつものように、ジョアネス・ヴェルモレルが参加しています。では、ジョアネス、今日はビジネスプロセスのどの部分をよりモジュラー化することについて話しているのですか？
ジョアネス・ヴェルモレル: 今日は特にITインフラと、あなたの会社のアプリケーション風景に焦点を当てています。モジュラー化は非常に興味深いものです。物理的な世界を考えると、サプライチェーンが非常にモジュラー化されているのは明らかです。おそらく、それは人類が発明した中で最もモジュラーな仕組みです。ここで言うモジュラーとは、道路輸送の場合、トラックを使用できるという意味です。トラックは非常にモジュラーで、積載可能な容量内であればほぼ何でも運ぶことができ、どんな道路でも移動可能です。追加のトラックが必要であれば、ほぼどんな種類のトラックでも利用でき、サプライチェーンに輸送能力を簡単に追加できます。
同じことがパレットやコンテナにも当てはまります。パレットやコンテナには、容量を超えなければほぼ何でも積み込むことができます。コンテナは非常にモジュラーで、貨物船からトラックへと容易に移動できます。どんな大きさのものでも、バーコードをほぼ何にでも貼ることができるというのは、現代的な発明です。例えばダイヤモンドのようなものなら、箱に入れて、その箱にバーコードを貼るでしょう。これらのシンプルな部品は、ほぼ無限に組み合わせることができ、まるでレゴのようです。これが物理的サプライチェーンの、非常にモジュラーな仕組みです。
しかし、興味深いのは、ITの世界に入ると全く異なる視点となり、しばしばモジュラー化が失われることです。これは、おそらく1970年代や1980年代初頭に企業が初めてコンピュータシステムやERPを導入し始めた頃に起因しています。
キアラン・チャンドラー: つまり、初期のITシステムは、その一体的なアプローチのため、今でもそのまま使われているということですか？
ジョアネス・ヴェルモレル: はい、その通りです。1970年代、1980年代、または初期の1990年代のITやソフトウェアを振り返ると、ネットワーク越しに何かを行うのはロケット科学のようなものでした。可能ではありましたが、工学的には悪夢でした。当時は、一台の大きな機械、理想的には当時のIBMメインフレームに全てのロジックを集約する方がはるかに容易だったのです。そして、すべての人がその機械に接続された端末を使い、全てのロジックがその機械上のモノリスで動作していました。
キアラン・チャンドラー: では、モノリスとはどういう意味ですか？
ジョアネス・ヴェルモレル: モノリスとは、分解が不可能な、一体となったアプリのことを意味します。つまり、分解できず一つのまとまりとして存在しなければならないということです。
キアラン・チャンドラー: 私はミレニアル世代なので、この考え方はやや古いかもしれませんね。しかし基本的には、全てが一台のマシンに接続され、そこから全てが動作しているということですか？
ジョアネス・ヴェルモレル: その通りです。メインフレームは非常に複雑なハードウェアであったため、たとえ一台であってもその影響は大きかったのです。
キアラン・チャンドラー: 主にERP、すなわちエンタープライズ・リソース・マネジメントシステムの話ですね。これらのシステムは、通常、追加機能を取り入れられるよう拡張性が設計されていますが、モジュラーではないため、その機能を完全に分離して保持することはできません。
ジョアネス・ヴェルモレル: 興味深いのは、本当に変化をもたらしたのはおそらくインターネットです。ここで言うインターネットの発明ではなく、1990年代後半にインターネットが普及し、人々が各部を分離してネットワークで接続する設計方法について考え始めた点です。これにより、ワークフローが工学的な悪夢から解放されました。それ以前は、複数の部品からなる複雑なソフトウェアシステムを構築する知識がなければ、ネットワークを介在させること自体が工学的な悪夢でした。このノウハウや文化、ツールは、一般大衆のインターネット採用の副産物としてほぼ生まれたものです。
キアラン・チャンドラー: インターネットは長らく存在しているのに、なぜ今もモジュラー化について語るのでしょうか？ なぜソフトウェアが今も一体型の状態を保っているのですか？
ジョアネス・ヴェルモレル: 現在の私の見解では、複雑なサプライチェーンを運営する多拠点の多国籍企業では、物理的な面は非常にモジュラー化されている一方、ITは完全にモノリシックな状態にあるということです。企業や市場全体が、IT分野における極めてモジュラーな仕組みの価値を十分に評価できていないと考えています。物理的なサプライチェーンではその価値は明らかで、改善が進んでいるのに対し、アプリケーション風景という抽象的な領域ではそのモジュラー性を把握するのが難しくなっています。
多くのベンダーは、古いモノリシックなアーキテクチャを若干SaaSやクラウド向けにアップグレードしただけで、基本的には1990年代のIBMメインフレームのようなアーキテクチャを踏襲しています。企業本社にあるマシンで稼働させる代わり、SaaSベンダーに運用を委ねているだけですが、ネットワークとウェブユーザーインターフェースがわずかに追加されたモノリスでは、近代化の本質的な向上は見られません。保守が容易になるだけで、機能を分割して取り扱う上では依然として分解不可能なモノリスに直面するのです。
キアラン・チャンドラー: このモノリシックなアプローチの問題点は何ですか？ 現実の企業ではどのような影響が出ているのでしょうか？
ジョアネス・ヴェルモレル: モジュラー化が欠けている物理的な例を考えてみてください。例えば、サプライチェーンにおいて、1台のトラックを変更するたびに全てのトラックを変更しなければならなかったとします。例えば、あるトラックを別のものに変えると異なる種類のガソリンが必要になるため、全てのガソリンスタンドを変更し、異なる種類のガソリンを供給するための貯蔵施設を設けなければならなくなります。これは非常に大きな問題です。
その問題は、ソフトウェアの場合にも同様です。近代化が進んでいないと、1部分を変更すれば全てを変更しなければならなくなるのです。たとえば、1台のトラックを変更すると、フリート全体を変更する必要があります。もし、ある倉庫の棚だけを変更する際にも、他の全ての倉庫の棚も同様に変更しなければ互換性が保たれません。そして、電動トラックへの切り替えのような戦略的な変更を行う際も、全体を一括して変更せざるを得ず、柔軟性が失われるのです。
この近代化の欠如の最も典型的な例として、ある企業が物理的に倉庫Aから倉庫Bへ移動する場合、単に棚に置かれた物品を移動するだけなら1日で済むのに、倉庫Aに連動しているソフトウェアを移行し、すべてのシステムが倉庫Bを認識するようにするには6ヶ月かかるという事例が挙げられます。
キアラン・チャンドラー: それは興味深いですね。では、こうしたモノリシックなシステムに依存している大企業は、どのようにしてよりモジュラーなシステムに移行しているのでしょうか？
Joannes Vermorel: 私たちはほぼ全てのエピソードで言及してきた企業、例えばAmazonに戻ると思います。彼らだけが極端にモジュラーなアプローチを採用したわけではありません。ドイツのZalandoも、ブログで確認できるように、既に非常にモジュラーなアプローチを完全に取り入れており、このモジュラリティを実現するためのIT用語はおそらくサービス指向アーキテクチャ（SOA）でしょう。
サービス指向アーキテクチャとは、基本的に機能を、それ自体が小さなモノリスのようなチャンクに分離し（しかしはるかに小さいもの）、一つのことを的確に実行するように範囲が定められていることを意味します。そして、それらすべてをサービス指向アーキテクチャを通じて組み合わせるのです。つまり、各サービスは、一つのことをうまく行うアプリとしてAPIを公開し、あなたのアプリケーション環境に非常に簡単に組み込むことができます。これは、他の部分についてほとんど前提条件を設けることなく、任意のアプリケーション環境にプログラム的に簡単にプラグインできるように設計されています。
AmazonのJeff Bezosは、確か2002年に非常に有名なメモを発表し、全チームに対して、各部門がAPI付きのサービス指向アーキテクチャを持つべきだと述べました。これにより、あなたがsiloに蓄積しているデータを、会社内の他の部門で活用できるようエクスポートし、構築しているものとプログラム的に相互作用できるようにするのです。
Kieran Chandler: ここで問題となるのは、結局、多くの小さなアプリ、小さなプログラム、小さな企業に依存するようになる点です。それでは、単一障害点が増えるのではないでしょうか。一方、モノリシックなアプローチなら、常に稼働する堅実な大企業や大規模ERPシステムがあり、信頼性がより高いと言えます。
Joannes Vermorel: 確かにそうです。そして、これは分散システムの課題の一つでもあります。もしハードウェアが1%の確率で故障するなら、メインフレームを持っている場合にも同様の問題が生じます。
Kieran Chandler: ソフトウェアが年に3回故障する可能性があると述べられましたね。もし10個のアプリがあり、それぞれが任意の日に1%の確率で停止するとすると、おおよそ10日ごとにネットワークのどこかで何かが停止していることになります。これは実際に課題です。この状況に対してどのような解決策を提案しますか？
Joannes Vermorel: まず思い浮かぶのは冗長性ですが、分散コンピューティングの観点からの影響についても議論したいと思います。そして、次に小規模企業と大企業、またはベンダー間の格差についても話せるかもしれません。分散コンピューティングの視点では、各ブロックの冗長性を高く保つことが目標です。これがクラウドコンピューティングの本質であり、極めて冗長なソフトウェアを用いて高いアップタイムを確保するのです。
良いニュースは、アプリが小さくシンプルであるため、非常に複雑なアプリよりもはるかに高いアップタイムを実現しやすいということです。インターネット上には、文字通り常時稼働しているコンポーネントサービスが数多く存在します。たとえば、Google Mailは文字通り常に稼働しており、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を発行してすべて―全機能、あらゆるオプション―を求めることが多いですが、実際にはそれこそが避けるべき方向なのです。重複を最小限に抑えるためには、極めて限定された機能を持つものを選ぶべきです。
大規模なフレームワークを購入すると、重複が必然的に発生します。エンタープライズベンダーは、多機能を追加できる大規模フレームワークの販売に積極的です。彼らはまず製品を販売し、その上でアドオンを追加で売りつけるのです。ですから、大規模なサプライチェーンを運営している方々には、プラットフォームの販売には十分注意するようにお勧めします。
プラットフォーム自体は優れていますが、二つのプラットフォームが共存すると悪夢になりかねません。複数のベンダーがプラットフォームを販売すれば、結果的に重複が氾濫してしまいます。解決策は、構成要素を慎重に選ぶことにあります。
「グルー」（接着剤）的な機能については、通常、社内で開発することが望ましいのです。これは、なぜあらゆるソフトウェアを自社開発するのかという直感に反するかもしれません。しかし、一定規模の企業であれば、あなたのアプリケーション環境は完全にあなた専用のものになるのです。
たとえ標準アプリばかりを使用しても、複数のアプリが必要になります。今日、メールやビデオ会議などあらゆる機能を一つのERPで賄えるはずはありません。必要なすべてのソフトウェア機能を一つのアプリに詰め込むことは不可能なのです。おそらく、皆と同じくMicrosoft Excelを使用するでしょうし、そのためファイル保管場所なども必要になります。
一つのソフトウェアだけで全てをまかなえるというのは現実的ではありません。大企業であれば、結局は様々なソフトウェアの集合体で運営されています。実際、あなたの会社を運営するソフトウェアの一覧、つまり正確なレシピは、あなたにとって完全にユニークなものになるのです。他のどの企業も、あなたほどには組織されていません。
Kieran Chandler: 完全にユニーク、それがあなたのDNAです。社内で実装する接着剤（グルー）を持っていればいいのです。これこそがサービス指向アーキテクチャの根底にある考えであり、接着剤を可能な限りシンプルかつスリムに実装することで、最小限の労力で済む非常にスリムなITチームを実現することができるのです。つまり、物事を結合するためのカスタムソフトウェアを考案する必要がなくなるということです。では、まとめると、もし私がCEOなら、どのようにしてまたLidlのような災害を避けることができるでしょうか？
Joannes Vermorel: まず、リスクを最小限にするのではなく、リスクそのものについて考えることが不可欠だと思います。Lidlの災害は、「全くリスクを取りたくない」という考え方から、最大のベンダーに頼り、全てをこなす製品を求めた結果でした。本質的には、設計上正しいものを求め、企業全体を一度にアップグレードするというアプローチであり、リスク管理の観点からは最悪の方法です。
全く逆の発想、すなわち「失敗するなら迅速に失敗できる仕組みをどう作るか？」と考える必要があります。大規模プロジェクトの場合、長期間にわたり失敗しているかどうかが分からないという問題があります。必要なのは、「迅速に失敗する」仕組みで、失敗がすぐに判明し、その失敗が小規模であること。そして、必要ならば管理可能な範囲で置き換えが可能であり、多くの小さな単位でそれを実現することです。
ですから、リスクを防ぐのではなく、むしろ失敗に対処する方法を考えるべきです。大手ベンダーから小規模ベンダーへ移行すると、失敗率が50%になるかもしれませんが、最終的に30%の失敗率が、会社の破産やサプライチェーンの停止に直結するのであれば、それは引き受けられるリスクではありません。どのみち、失敗に備えた計画が必要なのです。
私の考えでは、高いリスクは避けられないため、直接失敗に対する計画を立てるべきです。全てを最初から完璧にやろうとするのは幻想に過ぎません。むしろ、小規模で迅速かつ適切に範囲が限定された失敗を経験しながら反復することが求められます。さもなければ、7年間もの道のりを経て最終的に5億ユーロを失うという事態に陥ることになってしまいます。これこそがプロジェクトマネジメントにおける幻想的な考え方なのです。
Kieran Chandler: 素晴らしい、気に入りました。今日のLokadのヒント：「失敗するなら、迅速に失敗せよ」。素晴らしいですね。ということで今週はこれで終わりです。来週もまた別のエピソードでお会いしましょう。それでは、ご視聴ありがとうございました。
