00:00:00 Eric KimberlingとThird Stageの紹介
00:04:31 プロジェクトにおいて技術よりも人に注目する
00:06:14 デジタルトランスフォーメーションを正しく位置付ける
00:08:08 変革における漸進主義を克服する
00:10:53 ベンダーのバイアスが努力を誤らせるリスク
00:12:40 強制的なクラウド移行の課題
00:14:46 システムや記録のアップグレードは価値が低い
00:19:26 システムの敏感さと変革の影響
00:21:38 大企業の変革における脆弱性
00:23:39 リーダーシップの問題がリスク回避を増大させる
00:26:22 変革における戦略的視点の欠如
00:29:42 リーダーシップにおける機械的共感の重要性
00:32:42 データの遅延が分散コンピューティングを妨げる
00:35:42 テラバイトデータ処理の高コスト
00:38:38 技術変革のリスク分析
00:41:43 デジタルトランスフォーメーションのためのビジョナリー戦略
00:44:25 プロジェクト予算とリターンのバランスを取る
00:47:42 変革における現実的なコスト期待
00:50:58 ソフトウェア機能の過剰が生産性を妨げる
00:53:29 技術よりもビジネスプロセスに注力する
00:56:39 技術変革の内部管理
00:59:45 戦略的計画実行における官僚主義
01:02:48 ガバナンスがサプライチェーンの混乱を防ぐ
01:06:27 野心的な変革のための包括的な見直し
01:09:34 サプライチェーン価値のための資本支出の最適化
01:12:20 現在の変革における非効率性
01:15:28 競争優位性のためのベンダーデータの活用
01:18:11 財務インセンティブが生産性に影響を与える
01:21:13 有望なソフトウェア技術の開発を追求する
01:23:19 埋没費用を認識することで高コストの失敗を回避する
要約
サプライチェーンのデジタルトランスフォーメーションに関する議論において、Eric KimberlingとJoannes Vermorelは、ベンダー主導の圧力や優先順位の不一致に起因する頻繁な失敗を浮き彫りにする。Third Stage Consulting Groupを率いるKimberlingは、単なるソフトウェアアップグレードを超えた、ビジネスニーズを重視する技術に依存しない戦略を提唱する。彼は、変革的な成果をもたらせない急いだ決定に対して警鐘を鳴らす。Vermorelは、破壊的な置き換えよりも、革新的なアドオンを加えることで既存システムを活用することの重要性を強調する。両リーダーは、変革の取り組みを明確なビジネス目標に合わせ、チェンジマネジメントを成功の要とすることの重要性を訴える。彼らは、目的が明確に定義され、リスクが管理されたうえで、段階的かつ慎重に技術を導入することを提唱する。
拡張要約
サプライチェーンのデジタルトランスフォーメーションがしばしば失敗する理由を検証する際、Conor Dohertyが主催する最近の対話でEric KimberlingやJoannes Vermorelなどの業界リーダーが共有した洞察を考慮することが不可欠である。KimberlingとVermorelの両氏は、技術革新の荒波を乗り越えるために企業を導く豊富な経験を有しており、彼らの見解は、このような試みに乗り出す組織が見落としがちな重要な真実を明らかにしている。
Eric Kimberlingは、技術分野における思想的リーダーとしての光輝ある存在であり、Third Stage Consulting Groupを率いている。この会社は、成功するデジタルトランスフォーメーションを目指す組織に対し、独立した技術に依存しない助言を提供することに専念している。彼の会社は、単なる技術的アップグレードよりもビジネスニーズを前面に出した偏りのない助言を通じてクライアントに力を与えるという明確な使命のもとに運営されている。Ericのアプローチは、変革が単に技術的解決策にとどまらず、プロセスや人々を含む全体的な組織変革に焦点を当てる必要性を浮き彫りにしている。
この対話はすぐに「技術に依存しない」という概念に注目を集める。これは、Kimberlingが成功する変革プロジェクトの中核に据えるべき原則だと主張するものである。彼は、真のビジネスニーズよりもソフトウェアアップグレードを優先するベンダー主導のバイアスに対して警告する。この見解は、Vermorelによっても支持されている。ベンダーはしばしば急速なアップグレードのスケジュールを押し進めるが、これは結果として、変革的ではなく漸進的な改善しかもたらさない急いだ決定に企業を陥れる戦略となり得る。Ericは、このような圧力によるアップグレードが長期的な組織目標にそぐわず、デジタルトランスフォーメーションがもたらすべき価値を損なうと警告する。
Joannes Vermorelは、Lokadの創設者として、エンタープライズソフトウェアの領域を「記録システム」「報告システム」「インテリジェンスシステム」に区分し、変革は最小限の付加価値しか提供しない記録システムに狭く焦点を当てるべきではないと論じる。VermorelとKimberlingの双方は、PalantirやSnowflakeのような企業が見せる、置き換えを必要としない既存システムの拡張を通じた代替戦略を認識しており、革新的なアドオンを用いて現行のインフラを適応させることによる戦略的利点を強調している。
彼らの対話には繰り返し現れるテーマがあり、大企業がデジタルトランスフォーメーションにおいて高コストの失敗に特に脆弱であることを浮き彫りにする。Kimberlingは、これらの失敗はしばしば、複雑なソリューション、高いリスク回避、そして決定的な責任の欠如に起因すると指摘し、組織のデジタル要件を詳細に理解するための内在的な好奇心—すなわち、ビジネスリーダーが企業のデジタル要件に精通する必要性—を強調している。この好奇心がなければ、企業はあまりにも多くをアウトソーシングし、ベンダーを変革の副次的な役割ではなく主要な推進力として扱ってしまい、業績を損なうことになる。
リーダーたちは、デジタルトランスフォーメーション戦略を具体的なビジネス目標に合わせることの重要性を強調する。彼らは、明確なROIがない状態でERPのアップグレードに充てられる膨れ上がった予算、あるいはROIや利益分析を全く無視するプロジェクトという憂慮すべき見通しを示す。この議論は、しばしば見落とされがちな変革成功の要であるチェンジマネジメントの重要性を明示している。文化の同化や包括的なトレーニングを軽視する変革は、技術的な力量にかかわらず困難に直面する運命にある。
成功事例を特定する中で、KimberlingとVermorelは、計画書における明快さと簡潔さの重要性を明らかにする。冗長なパワーポイントではなく、簡潔な文章による計画は、より深い理解を促し、ステークホルダー間の明確なコミュニケーションを助ける。彼らは、技術投資を単なる運用費用ではなく、耐久資産として資本支出に類似して評価することの美徳を讃える。
対話が締めくくられる中で、両者は、技術主導の変革がビジネスの進化のための強力な触媒となり得る一方で、その成功はソフトウェア革新の採用と組織変革の促進との間で慎重なバランスが取られているかどうかにかかっていると改めて強調する。Kimberlingは、実施を加速する前に目的を厳密に定義した上で、段階的かつ慎重に変革に取り組むことを勧める。Vermorelもこれに同意し、リスクを和らげながらも柔軟に適応する余地を残す「早期失敗」のアプローチと段階的な関与を推進する。
彼らの議論を通じて、KimberlingとVermorelは、デジタルトランスフォーメーションを検討する組織に道筋を示し、リーダーたちに流行技術の魅力以上のものを考慮し、むしろこれらのプロジェクトを総合的なビジネス目標や志向に合わせることの重要性を訴える。
完全な書き起こし
Conor Doherty: Lokadへようこそ。本日は、Eric KimberlingとJoannes Vermorelの対話をお届けできることを嬉しく思います。EricはThird Stage Consulting GroupのCEO兼創設者であり、今日、彼はサプライチェーンにおける多くのデジタルトランスフォーメーションがなぜ失敗するのかについて、彼独自の視点を共有するために参加しています。ここにいらっしゃる皆様、もしLokadの活動がお気に召しましたら、ぜひYouTubeのLokad TV登録をご検討ください。お待ちしています。
では、ありがとうございます。そして、LinkedInでもぜひフォローしてください。それでは、今日のEric Kimberlingとの対話をお届けします。まずは、Eric、本日はご参加いただき誠にありがとうございます。Lokadへようこそ。
Eric Kimberling: お招きいただきありがとうございます。こちらにいられて光栄です。
Conor Doherty: では、Eric、話の核心に入る前にお伝えしておきたいのですが、あなたはオンラインで非常に人気のある存在です。実は私があなたを知ったのはLinkedInが初めてでした。フォロワーも多く、YouTubeでも積極的に活動されています。我々の聴衆は主にヨーロッパの方々で、あなたにそれほど馴染みのないかもしれません。そこで、北米にいらっしゃらない皆様のために、Third Stage Consulting Groupがどのような企業で、どのようにここに至ったのか、簡単な紹介をお願いできますか？
Eric Kimberling: ええ、Third Stage Consulting Groupは、米国に拠点を置くデジタルトランスフォーメーションのコンサルティング会社です。我々のビジネスモデルの鍵は、独立性と技術に依存しない点にあります。つまり、デジタル戦略、ソフトウェアの評価および選定から、実装計画、さらには実際の実装プログラム管理やチェンジマネジメントに至るまで、ライフサイクル全体を通してクライアントを支援しています。
私たちは約100名のコンサルタントを有しています。実際、イギリスに欧州担当の小規模なオフィスを構えており、EMEA地域を担当しています。従って、まだ欧州ではそれほど普及していないのは事実ですが、北米と同様にEMEA地域にも十分なプレゼンスを持つことを目指しています。実際、私は2018年にこの会社を始めたのは、本当に技術に依存しない、客観的で、クライアントの利益を真に代表するコンサルタントが不足していると感じたからです。
これが私が会社を立ち上げた根拠そのものであり、従来のコンサルティングモデルに代わる選択肢をクライアントに提供するためでした。
Conor Doherty: 従来のコンサルティングモデルについてお話される際、技術に依存しないという点が大きな要素であると推測しますが、それが具体的にどういう意味なのか詳しく説明していただけますか？素晴らしいフレーズですが、技術に依存しないとはどういう意味でしょうか？
Eric Kimberling: もちろん、「技術的無神論」も好きな表現ですが、さらに良いのは「技術に依存しない」という意味です。つまり、我々はソフトウェアベンダーから委託を受けていないのです。言い換えれば、ベンダーが利益を上げたからといって我々が利益を得ることはありません。我々は直接、クライアントからのみ収益を得ます。これは極めて重要なニュアンスであり、大半のコンサルティング会社は、市場や地域全体でソフトウェアの普及を最大限に拡大するために、ソフトウェアベンダーから直接的にインセンティブを受けています。
彼らは一つの技術に特化したコンサルタントを抱えており、その目的はその特定の技術に焦点を当てたプロジェクトに配置することです。そのバイアスは、変革において技術優先の考え方を生み出しますが、私の意見では、サプライチェーンの変革やERPの導入など、どんな変革であっても、より成功するものは、技術を先導するのではなく、ビジネスニーズに基づいて戦略とロードマップを定義することにより推進されるのです。それは些細なことのように聞こえるかもしれませんが、実際には非常に重要であり、市場における成功または失敗の大きな要因となっています。
Conor Doherty: ありがとうございます。Joannes、そちらにお話を伺います。Ericが問題提起について触れましたが、問題提起をより良く理解することは、達成したいことの基本であると認識しています。では、Ericの発言に関するあなたの考え、そしてそれがあなたのデジタルトランスフォーメーションの理解とどのように結びつくのかを教えてください。
Eric Kimberling: 実際、我々が定義するところでは、デジタルトランスフォーメーションとは、企業全体における技術の活用を意味します。単なる技術ではなく、むしろ運用面や組織面、すなわちプロセスや人に関する側面がさらに重要だと言えるでしょう。
特定の技術を検討する際、多くの場合、人々はまず自社の技術を置き換える必要があるという判断から始めます。これは通常、「何らかの技術を交換する必要がある」という問題提起となります。その技術は、サプライチェーンシステムであったり、ERPシステムであったり、CRM（顧客関係管理システム）であったり、HRシステム、財務システム、さらにはAIが重要視される今日ではAIであったり、ビジネスインテリジェンスであったりします。
このように、多種多様な技術が存在し、その中から選択する必要があります。我々の考えでは、デジタルトランスフォーメーションという言葉は非常に広範かつ曖昧であり、さまざまな要素や異なる技術を内包しています。さらに重要なのは、「デジタルトランスフォーメーション」という言葉自体が誤解を招きやすい点です。なぜなら、それが技術に関するものと捉えさせるからです。実際、これらのプロジェクトは、技術よりもむしろ人々のプロセスに関するものである場合が多いのです。
Conor Doherty: ありがとうございます、Eric。そして、Joannes、そちらにお話を伺います。
Joannes Vermorel: 良い助言を提供するためには、技術に依存しない姿勢の重要性には全く同感です。これは絶対に不可欠です。そうでなければ、問題が文字通り、すでに扉を叩いているベンダーの影響力を拡大する方向に枠組み化されてしまいます。そうなると、プロジェクトは、このベンダーのERPをバージョンNからN+1にアップグレードする方法にまで転落してしまうのです。結果的に、それは大規模な投資に対してほとんど成果が得られない、という結果を招きます。
インセンティブが、最初の問題設定を正しく枠組み化する力を過小評価してはなりません。一見すると些細なことに思えるかもしれませんが、私が観察してきたのは、プロセスのかなり初期段階で下されるごくわずかな決定が、その後何年にもわたって費やされる何百万ドルもの支出の方向性を完全に決定づけてしまうということです。ですから、ビジネスの側に立つことが絶対的に重要だという点には、私も強く同意します。まだ「どのベンダーか」という問いを立てる前に、私たちは何を実現したいのかを考えるべきなのです。そして副次的な問いとして、私もあなたの見解に大いに賛成なのですが、デジタルトランスフォーメーションとは結局のところ、こうしたより洗練されたツールを用いて物事を改善できるなら、私たちはどのような企業になれるのか、という問いに関わっているのです。
線形的な進化、すなわちバージョンNからバージョンN+1へ進むといった考え方とは一線を画すべきです。たとえば、「我々にはこれを行っている人がたくさんいる」と思いがちですが、実際には、もしもっと組織が整っていれば、最初からそれらの作業自体が不要だったかもしれません。だからこそ、彼らのやっていることを最適化しようとしても意味がないのです。最良の組織であれば、そもそもその手順すら必要としないからです。これこそが、ビジネスの本質を真剣に考えるための挑戦だと私は考えています。あなたは実際に何を達成したいのか？
そして、技術が何をでき、何をできないかを十分に理解する感覚も必要です。しかし、私が言うには、ビジネスや達成しようとしていることを非常に明確に理解していることに比べれば、技術の理解は二の次です。この枠組みがとても気に入っており、私にとって、特にヨーロッパでは、あるいはアメリカでもある程度当てはまると思いますが、デジタルトランスフォーメーションにおける多くの企業の最大の課題は、漸進主義の呪いにあるのだと感じています。つまり、わずかに機能を追加するだけで、同じものだと考え、例えばデスクトップインターフェイスの代わりにウェブインターフェイスを持つ同じERPを求める、という発想です。
私にとって、確かにそれは魅力的かもしれませんが、基本的に非常に高額なこれらのプロジェクトに対して、その投資収益率は正当化されません。醜いインターフェイスにうんざりしてERPをアップグレードするということはありません。見た目がよくなくても、動作するならそれで十分です。もしアップグレードに何年も費やすのであれば、それによって企業が単に見た目の良いツールを得るだけでなく、企業自体が大きく向上する必要があります。これが、真に正しく実行されたデジタルトランスフォーメーションが何であるか、私の考えです。
Eric Kimberling: そうですね、非常に良い点です。まず、計画と初期の意思決定について述べられた点は、その後のプロジェクトの軌道を決定づけるという意味で非常に重要です。それは本当にその通りで、多くの組織が、これらの決定を急いで済ませ、プロジェクトに取り掛かってしまい、後で全てを解決しようと考えます。しかし、そうなると物事は混乱し、方向性が不明確になります。
しかし、あなたがほのめかしているもう一つの点は、時には「技術をアップグレードしなくてもよい」という選択肢があるということです。最新の華やかなシステムにアップグレードしなくてもどうでしょう？代わりに、現有の技術を最適化するのはどうでしょう？ビジネスプロセスをより効率化するために改変に注力するのはどうでしょう？ソフトウェアの使い方をより良くするために従業員を訓練するのはどうでしょう？リスクが低く、かつ非常に大きな価値をもたらす、これらの低コストな施策をすべて実施するのはどうでしょう？その選択肢を検討してみては？
さて、ソフトウェアベンダーは私の意見に強く反対するでしょう。もし私がソフトウェアベンダーなら、「それはひどい考えだ。すべての技術をアップグレードし、クラウドに移行し、AIを導入しなければならない」と主張するでしょう。なぜなら、私は技術を販売しようとしているのです。しかし、一歩引いて感情やベンダーバイアスを排除すると、多くの組織は「ベンダーが期限を設けているからといって、急いでクラウドにアップグレードする必要はない」と結論づけることが多いのです。
そして、変革をソフトウェアベンダーではなく、企業自身のビジネスニーズ、優先順位、戦略に基づいて進めることが非常に重要だと私は考えています。
Conor Doherty: Eric、その点についてもう少し詳しくお聞きしてもよろしいでしょうか。決してあなたの意見を曲解するつもりはありませんが、コンサルタントやベンダーによって人々が誤解され、それがデジタルトランスフォーメーションの失敗につながっているという意味でしょうか？もしそうでなければ、デジタルトランスフォーメーションが失敗する一般的な理由として、どのような点があるとお考えですか？
Eric Kimberling: ええ、それは素晴らしい質問です。この一つの問題についてはインタビュー全体を費やすこともできるでしょう。しかし要約すると、偏見は確かに失敗の一因であると言えます。もし私がソフトウェアコンサルタントとして、短絡的な視点で「これが貴社に最適な技術だ」と提案すれば、既にミスマッチが生じています。なぜなら、私は貴社のビジネスを重視するのではなく、自分の技術を前面に出しているからです。
私の技術にはベストプラクティスがあり、組み込みのワークフローが備わっています。貴社は私のソフトウェアに合わせる必要があります。―私のソフトウェアは優れているのです。しかし、それが非常に破壊的なプロセスを引き起こすのです。だから、偏見はその一因であり、大きな要因だと言えます。しかし、私がさらに大きな要因だと考えるのは、多くの人が認識していない点です。多くの大手ソフトウェアベンダー、たとえばSAPやMicrosoftは、「古いシステムの保守やサポートをこの日までに終了する。新しいシステムに移行しなければサポートを打ち切る」という形で、事実上顧客に新技術へのアップグレードを強制しているのです。
そして、それは非常に無謀だと思います。顧客本位の問題定義ではなく、ベンダーの問題を顧客の問題にしてしまっています。ベンダー側の問題は、「我々はクラウドへ移行する必要がある。それが利益につながり、投資家が要求している」というものです。結果として、その問題が顧客の問題になり、「たとえば2年前にオンプレミスソリューションを実装したばかりなのに、同じシステムのサポートを2、3年で打ち切る」という状況になるのです。
その結果、組織内に焦りとパニックが生じ、変革を進める上で最悪の状況を招きます。なぜなら、そのプロセスは、あなたが述べるような、漸進的な改善だけに終始し、膨大な時間、資金、リスクを費やしてもごく僅かな改善しか得られず、投資収益率（ROI）の正当化が困難になるからです。
Conor Doherty: Joannes、あなたはベンダーの大ファンであり、徹底して彼らを擁護していますが、その点について何かコメントをいただけますか？
Joannes Vermorel: ええ、私の見解では、ソフトウェア業界は―ちなみに私の見るエンタープライズソフトウェアの世界は、記録システム、レポートシステム、そしてインテリジェンスシステムという三つの明確な王国に分かれています。記録システムは、実際のところデータ入力とワークフローに関するものです。これには、CRM、ERP（本来ならERM、すなわちエンタープライズリソース管理と呼ぶべきで、計画は二次的な関心事です）、TMS（輸送管理システム）など、管理を伴うすべてのものが含まれます。これらの管理システムはすべて記録システムに該当します。
私の考えでは、ある程度適切に機能し、動作が遅くなりすぎない記録システムが整えば、その層についてはほぼ完了ということになります。デジタルトランスフォーメーションにおいて、多くの人々が手を加えても本当に改善できるものではない部分に手を出してしまうのが現状です。たとえば、あなたが会計士であれば、既に台帳を持っており、それは十分に良いものです。派手ではないかもしれませんが、その台帳は必要な全ての情報を網羅しています。まさにそれが記録システムの役割です。
記録システムはそのようなものであり、デジタルトランスフォーメーションにおける多くの議論は、すでに必要な情報を記録しているシステムのアップグレードについてです。したがって、私にとって、この種のトランスフォーメーション（通常、予算の80%以上を消費するもの）の付加価値はほぼゼロに等しいと感じます。なぜなら、既にワークフローが存在し、正常に機能しているのです。次のインターフェイスがあったとしても、データ入力などの基本部分は変わらないでしょう。
そして、もしそのシステムが存在し、機能的に必要な情報を網羅しているのであれば、もう十分と言えます。そして、エンタープライズベンダー、特にSAPのような企業は、実際に記録システムにおいて、任務が完了した、つまり二十年前にそのシステムで仕事が終わったと認識しているのです。
そして、ちなみに、SAP HANAが「この記録システムを変革して、あらゆる分析層を備えたレポートシステムにしよう」という動きをみせたのもその一例です。しかし、私の分析では、現状を維持するべきだと考えます。あなたのシステムは記録システムです。そして、企業がそのように捉えれば、「次のバージョンではバグや回帰、新たな訓練が必要になるだけで、旧システムが耐え難いほど遅かったり、バグだらけで、必要な記録すら取れなかったのでなければ、投資する意味はない」と言うでしょう。
そして、サプライチェーンにおいてはこれは非常に重要な問題です。私が見ているところ、多くのクライアントは30年前の在庫管理システムを使用しています。白黒のテキストコンソール画面であっても、機能的には企業が必要とする全てを100%こなしているのです。在庫管理は、決してロケット科学ではありません。棚から1つ引く、棚に1つ置くといった単純な作業です。
つまり、これらのソフトウェアは古くても、機能的には必要なことを100%実行しているのです。したがって、これらをただアップグレードするために多額の資金を投じても、期待される成果には結びつかないのです。
Eric Kimberling: 私も同感です。だからこそ、PalantirやSnowflakeのような会社が存在するのだと思います。これらは、いわゆるボルトオンシステム―厳密に言えばボルトオンシステムとは呼びたくはありませんが、他の記録システムと相互運用できるように設計されたシステムです。つまり、「私の記録システムは時代遅れかもしれないが、動作しており、置き換えるためのリスクやコスト、労力をかけたくない。しかし、より優れたレポーティングやインテリジェンス、場合によってはAI機能が必要だ」という場合に対応できるのです。ただし、バックオフィスの記録システムを全面的に取り替える必要はありません。
このようにして、Palantir、Snowflake、その他の企業は生まれたのです。彼らは「古いシステムはそのままで大丈夫。干渉せず、むしろその上に乗せて、より良いワークフロー、より優れたAI、より良いレポーティング、より洗練されたインテリジェンスを提供します」といったソリューションを創出しています。
ですから、あなたの言う通りだと思います。組織やチームは実際、他のベンダーから「いいえ、あなたの記録システムは古い技術に依存しているため、置き換える必要がある。技術的負債があり、遅れを取ることになる」と言われているため、本当は多くの選択肢があるのに気付いていないのです。これは恐怖に基づく販売手法であり、その手法は確かに効果を発揮します。
幸いなことに、ベンダーにとってはこの方法が奏功しますが、不運なことに顧客にとってもその影響は避けられません。だからこそ、重要なのは自らをしっかりと教育し、客観的な視点を持ち、外部の客観的な意見を取り入れて、本当の選択肢が何であるかを理解することです。もしかすると、記録システムをそのまま維持しながら、リスクを伴わずにさらに多くの機能を追加する方法があるかもしれません。
Joannes Vermorel: 遠慮なく言わせてもらえば、これこそがLokadのビジネスモデルそのものです。PalantirやSnowflakeと全く同じ方向性で設計されており、その理由から我々はまさにそれを実践しています。もちろん、あえてそのことをあなたに言わせるつもりはありませんでしたが、これが私の主張です。記録システムに手を加えると、組織に与える混乱の規模が計り知れないのです。
一方、Snowflakeのようなアナリティクスシステムは、日常業務で本当に依存するまで、何度でもオンオフを切り替えることができ、大した問題にはなりません。しかし、記録システムは、万が一手を加えて壊れてしまうと、供給業者への支払いや顧客から回収すべき金銭など、全てが混乱してしまうのです。
つまり、記録システムは非常に敏感で繊細な層であり、仮に既に機能的に満足できるものであれば、アップグレードしても大した改善は見込めません。しかし、一度壊れてしまった場合、そのダメージは絶大になり得るのです。
最近、フランスでは大手企業GiFiが、誤ったデジタルトランスフォーメーションの管理により倒産しました。実際、参考資料を目の前にしているのですが、数十億規模の企業が、失敗したデジタルトランスフォーメーションにより破綻したのです。
Eric Kimberling: フランスでも有名な大手企業だとしましょう、ですよね？
Joannes Vermorel: ええ、全国トップテンの小売ネットワークの一つだったと言えます。
Conor Doherty: それは実に完璧な繋がりですね。実は、Eric、私は皆が知っている大企業の事例についてあなたが頻繁にコメントされる点に触れたかったのです。実際、資料にリストがあり、例えばLidlについても記録されています。画面には、ERPシステムの変革に挑んで6億の損失を出したと書かれているのです。すみません。しかし、これはヨーロッパだけでなく、世界中の話です。
さらに、DHLは何億もの損失、ドイツのLidlは5億の損失、Asda、GE、Sparなどもあります。実際、私はSparに関するあなたの動画も見た記憶があります。再度申し上げますが、これらは巨大企業であり、特定の地域、例えばヨーロッパやフランス、ワシントンなどに限定される問題ではなく、ほぼシステム全体に共通する現象なのです。
さて、あなたの言葉を代弁するつもりはありませんが、もし巨大企業にある程度体系的な問題が存在するとしたら、問題は、巨大企業に固有の何か脆弱な点があるのか、敏捷性に欠けているのか、それとも何か別の理由があるのか、ということになります。なぜこれらの大企業はこれほど多くのお金を失っているのでしょうか？
Eric Kimberling: 素晴らしい質問ですね。まず第一に、私には分かりません。どちらとも言えないのです。確かに大企業では若干失敗率が高いのではないかと思いますが、中小企業にも失敗する企業は多数存在します。ただ、その違いは、誰も気に留めないために、そのことがあまり知られていないという点です。
これらの企業はこれまであまり知られていませんが、Lidl、Spar Group、Asdaなどの大手ブランドは皆さんご存知です。しかし、大企業がなぜ失敗しやすいのかという質問に答えるなら、大企業におけるいくつかのダイナミクス、特に組織行動の側面が失敗を招きやすい要因になっていると言えます。部分的には、大企業は自分たちが大きく複雑であるため、その性質上、より大きく複雑なソリューションを実装しなければならないと感じるからです。
その結果、SAPやOracle、その他の大規模なシステムを購入する可能性が高くなるのです。これ自体がリスク要因となり、実装しようとしているのは大規模で複雑なシステムであるため、リスクが即座に増大します。
大企業で小企業よりも頻繁に発生するもう一つの動向は、いわゆる責任の欠如です。経営層での透明性や説明責任が低いのです。多くの場合、これらの経営者は手一杯で、事業の拡大、新市場への進出、企業買収など戦略的な取り組みに専念しているため、デジタルトランスフォーメーションを非戦略的なものとして扱ってしまうのです。これは大きな誤りです。
そして、その責任を組織内に委譲してしまいます。経営層のオーナーシップ・透明性・可視性・同意（買い）の欠如、つまり経営層の関与不足が失敗につながるのです。これが大きな根本原因の一つです。さらに、大企業は非常にリスク回避的であるため、皮肉なことにリスクを実際に増大させてしまうという三つ目の側面もあります。
つまり、彼らは「SAPを実装すれば、SAPはよく知られた製品だ。Accenture、Deloitte、KPMGを雇えば、これらは非常に有名な企業だ。だからこそ、安心して任せられるブルーチップ企業を採用する」というわけです。
そして、その結果、資金に余裕がある状態となり、システムインテグレーターがプロジェクトを引き継いでしまいます。なぜなら、経営者が十分に関与せず、大手ブランドを信頼しているからです。その結果、大企業はテクノロジーの導入の道を進み、たとえ自社のビジネスに必ずしも合致しなくても、知っている方法で物事を過度に複雑化してしまうのです。
彼らはそうするのです。そして、これは意図的な悪意によるものだとは思いませんが、オーナーシップと透明性の欠如が、人々を自己利益の追求へと導き、その結果、ベンダーやシステムインテグレーターも自己利益を追求し、より多くのソフトウェアを販売し、より多くの作業時間を請求しようとします。ROI（投資収益率）は全く考慮されず、たとえ価値が提供されなくても、彼らは報酬を受け取るのです。
このように、インセンティブがうまく整合していないのです。大企業、特に大規模で複雑な企業では、これらの側面が拡大され、リスクも大きくなるため、この三つの点が中小企業よりも大企業に対してより大きく作用する主な理由だと考えられます。ただし、中小企業も基本的な原則を守らなければ失敗する可能性があるということは言っておきます。
そして良いニュースは、これらを成功させるためにロケット科学や秘密の公式が必要なのではなく、実際には非常にシンプルな解決策が存在するということです。しかし、組織は立ち止まって考え、早期に正しい決断を下す時間を取らないため、これらの問題が発生するのです。
Conor Doherty: ありがとうエリック。ヨアネス、大企業の官僚主義について以前一度か二度コメントしていましたが、その考えをもう一度教えていただけますか？
Joannes Vermorel: ええ、私の見解では、中小企業が失敗するのは、専門家などのリソースが不足しているからです。一方、大企業の場合、失敗が頻発するものの、実際は専門家が揃っています。しかし、その専門家たちはそれぞれ特定のアジェンダ（目的）を持って採用されているという問題があります。
時には、いわば愚かなアジェンダ、例えば新しい技術を試してみたいという、履歴書に良い印象を与えたいという目的のためだったりします。ですから、技術者たちが実験や試行錯誤のために技術的なことを行うという事実を過小評価してはいけません。
しかしまた、あなたが指摘したように、デジタルトランスフォーメーションが戦略的なものと認識されていないのも問題です。その結果、連鎖的に、大企業のトップマネジメントはmechanical sympathyを持たないことが多いのです。
では、mechanical sympathyとは何かというと、彼らはエンジンルームの中身、つまり物事がどのように接続されているのか、何について話しているのかに全く興味を示さないのです。専門的なソフトウェアエンジニアである必要はありませんが、単に多くのテーブルを持つデータベース上で、作成、読み込み、更新、削除を行うような粗末なアプリの話をしているのかどうか、というところです。
あるいはリアルタイムが必要なのか？リアルタイムとは何を意味するのか？マイクロ秒、ミリ秒、秒、あるいは時間単位が必要なのか？などなど、基本的な疑問はたくさんあります。しかし、いわゆるmechanical sympathyが全くない場合、操作するオブジェクトやソフトウェアオブジェクトは全て完全に抽象的なものになってしまいます。
そして、あなたにとっては全く意味を成さないコードネームの羅列に過ぎなくなるのです。「ああ、ウィジェットABC20が必要で、しかしABC20を動作させるためにはContoso12もアップグレードが必要だ」。そしてContoso12には、さらに7番目の何かが必要で、などなど。
つまり、全く意味をなさない長いコードネームのリストということです。もしこのような環境があれば、それは容易にテクノクラートによる支配に陥る状況を助長します。実際、ビジネスの視点が窓から投げ出され、ビジネスパーソンはmechanical sympathyが全くないため、自分たちの主張を完全に放棄してしまうのです。結果、物事がビジネスに沿って進んでいるかどうかについて、意見を述べる力すら失われてしまいます。
すみません、長い回答になってしまいましたが、私の経験上、数多くの企業でこのmechanical sympathyの要素が欠落しているのを見てきました。そして、それにはそれほど高度な専門知識を必要としません。車が好きな人なら、車が前進するためにエンジンルームの中身を少し理解すれば、それが単なる魔法ではなく、主要な構成要素によって動いていることが分かるのと同じです。
Eric Kimberling: ええ、全くその通りです。非常に興味深い用語ですね。私は「mechanical curiosity」という言葉を聞いたことがなかったのですが、これが私がよく述べる点、つまり製品全体に対する一般的なオーナーシップと好奇心と深く関係しているということに繋がっていると思います。
そして、これはまさにあなたが述べているmechanical curiosityを包含していると思います。しかし、もし先ほど述べたようにmechanical curiosityを持たなければ、プロジェクトに関して賢明な判断を下すための所有感や適切な知性を持つことは到底不可能だと考えます。
そして、その実践的な好奇心や経験がなければ、専門家ほどの経験は必要ないにしても、少なくとも彼らを管理できるだけの経験は必要です。なぜなら、管理するのはあなたの仕事だからです。専門家だからといって彼らに管理を委ねるべきではありません。これはあなたの会社です。その結果を受け止めなければならないのはあなたなのですから、それに応じた管理が求められます。
多くの大企業が「私は技術者ではないし、責任もないので、専門家に任せよう」と言うのは驚くべきことです。しかしこれはビジネストランスフォーメーションであり、正しく行っているのであれば、実際にビジネストランスフォーメーションそのものであり、自ら非常に深く関与する必要があるのです。
たとえ技術的なmechanical curiosityに直接関与していなくても、少なくとも運用面での好奇心には関与すべきです。これは、これが私の組織にとって何を意味するのか、業務はどのようになるのか、人々の仕事にどのような影響があるのか、望むべきものなのか、あるいは別のものを求めるべきなのかを判断するためです。
もしそれに関与しなければ、システムインテグレーターは自分たちが正しいと思うものを作り上げるだけで、それはあなたのビジョンや戦略と一致しなくなってしまいます。
Conor Doherty: 私も一言付け加えさせてください。お二人に同意するのですが、mechanical sympathyについて何度かお話しされているのを聞いたことがあります。最近、Supply Chain Connectの別のポッドキャストでも、その正確な概念について触れました。
そこでは二つの非常に良い点がありました。一つはmechanical sympathyの直接的な利点です。ソフトウェアについて少しでも理解すれば、より効果的に活用でき、直接的なROI（投資収益率）が向上するのは明らかです。しかし、それだけでなく、偽のベンダー主張からあなたを守る効果もあります。
そして、以前にもおっしゃっていましたが、何が設計され、ソフトウェアが何を実現できるのかを少しでも理解することで、ベンダーからの誤解を招く主張から守られる可能性があるのです。
Joannes Vermorel: ええ、例えばLLMsを例に挙げましょう。AIは素晴らしい、ということで、大型言語モデルが存在します。では、LLMに1メガバイトのデータを取り込むコストは、ざっくりいくらでしょうか？
大体の目安として、安価なモデルを使ったとしても、1メガバイトあたり基本的に1ドル、しかもそれは下位の安価なモデルの場合です。回答を得るたびに、LLMに1メガバイト分のデータを入力として処理させると、最も安いモデルでも1ドルのコストがかかるのです。
もしこの数字を頭に入れておけば、すぐに実現しても、多くの事柄が初動で見えなくなり、恐らく十年以上はそのままであると分かります。なぜなら、例えばテラバイト単位のデータがある場合、まずそれをLLMで処理するつもりはないでしょうから。
そして、もし誰かがクリックするたびに1ドルを支払わなければならないとすると、極めて基本的な計算で、これは成立し得ず、経済的に実現不可能だと分かるのです。
たとえ価格が100分の1に下がったとしても、依然として実用的な数字からは四桁分も乖離しています。単なる一例ですが、私は見込み客と話している中で、何桁かの基本的な数量級を考慮しようという議論を何度も行ってきました。
例えば、分散コンピューティングも同様です。分散コンピューティングは光速によって大いに制限されます。『なぜ光速を知る必要があるのか？』と言う人もいますが、回答は、あなたのwarehouseが中央システムと情報の往復を行うシステムの場合、200ミリ秒のレイテンシが発生するからです。
つまり、ある処理を行うためには1000回のラウンドトリップが必要で、その結果、ラウンドトリップだけで200秒かかることになるのです。これは超高度な数学ではありませんが、明らかに設計上の問題が存在するということです。
高度なエンジニアである必要はなく、単純な掛け算、基本的な基準の話に過ぎません。私は、多くのプロジェクトが、基本的な概算の計算が行われなかったために失敗しているのをクライアントで見てきました。
その場合、人々は、ビジネス上の目的を考慮すると全く機能しないと認識するでしょう。なぜなら、技術者が「200秒かかる。計算には時間がかかるのだから、200秒で良い」と言うかもしれませんが、
しかし、現場の担当者は「いいえ、これはオペレーターが待っているものなので、そんなことはあり得ない」と言います。また、LLMが「おっと、1メガバイトにつき1ドルだ」と言い、エンジニアは「そうだろう、単なる価格の問題だ。どうでもいい」と言うのです。
「どうでもいい」とは言いながらも、ビジネス側は「しかし、時給20ドル程度の人が1時間に60回もクリックすると考えたことがありますか？」と言います。結果として、LLMのコストは、オペレーターに支払う費用の約4倍になるのです。
再び申し上げますが、これが分かる唯一の方法は、mechanical sympathyを伴ったビジネス、すなわちプロジェクトの枠組みと、その付加価値または意図された付加価値がしっかりと理解されることなのです。これが私の見解です。
Eric Kimberling: ええ、また、表面的にはビジネスを改善しているように見える隠れたコストやその他の要因を理解することが重要です。たとえビジネスが改善されたとしても、もしそれが劇的かつ実質的にコストを増加させるのであれば、望んでいるROIは得られないでしょう。
Joannes Vermorel: はい、それに加え、エンジニアは非常に正確な数字を示せるものの、小数点がわずかにずれるという点を決して過小評価してはならないと、私の経験では言えます。
ですから、だからこそ経営者は本当にmechanical sympathyを持ち、デジタルトランスフォーメーションおよびその背景にあるものに関心を持つ必要があるのです。さもなければ、技術に熱中するテクノロジストたちの手に委ねられることになり、彼らは容易に気を散らし、ROIが正の値になるかどうかを左右する数量級の問題を見失ってしまいます。
Conor Doherty: これを正しく理解するために確認させてください。先ほど述べた影響、つまりテラバイトは100万メガバイトですよね？つまり、1メガバイトあたり1ドルのコストというのは、ただ…
Joannes Vermorel: テラバイトは1000ギガバイトです。つまり、100万メガバイトになります。ですので、ここで述べた価格帯では、1テラバイトの処理に100万ドルかかることになります。
Conor Doherty: 私が理解できているか、確認させてください。
Joannes Vermorel: だから、つまり、もしそれをするつもりなら、そもそもそれをするべきではないでしょうし、どうしてもやらなければならない場合は、年に一度以上は行わないように十分注意すべきです。大企業であっても、非常に莫大なITコストがかかることは明らかです。
Conor Doherty: ええ、そうですね。実は、エリック、その点に戻るのですが、全体の流れは「欠けているもの」についてでした。しかし、別の「欠けているもの」についても改めて触れたいと思います。ご存知の通り、既に機械的共感について議論しましたが、その中であなたはROI、つまり投資収益率の考えも持ち出しました。
そして、エリック、以前あなたが、大企業が自社のソフトウェアを選定する際に、「ああ、有名なブランドのものを選ぼう。そして、有名なコンサルティング会社はどう？ そうすれば、形だけは満たされる」と言ったときのことを覚えています。そして、その文脈では、しばしばROIが重視されないと言いました。Joannesが以前サプライチェーンにおける財務KPIやROIについて語ったのは知っていますが、なぜサプライチェーンでは財務的視点が期待ほど存在しないのか、もう少し詳しく説明していただけますか？
Eric Kimberling: ええ、テクノロジーが非常に速く、しかも指数関数的に変化しているため、まるで核兵器競争のような状況になっており、人々はFOMO、つまり取り残されることへの恐怖を感じています。そして、彼らは技術的負債や、アナリストやソフトウェアベンダーが生み出す派手な用語に苦しむことがないようにしたいと考えているのです。
その結果、彼らは本来の目的を見失ってしまいます。業界全体が、なぜこれらのテクノロジープロジェクトを実施しているのかという根本的な目的を見失っていると思います。つまり、クラウド機能が欲しいから、AIが必要だから、あるいはより優れたインテリジェンスやレポート、記録システムが欲しいから実施しているのではないのです。
私たちはその本質を忘れてしまっているのです。なぜそのテクノロジーが必要なのか、例えばなぜクラウドに移行する必要があるのかという点に真剣に向き合っていないのです。実際、クライアントにその理由を尋ねることがありますが、彼らは「今はオンプレミスだから」といった無表情な返答をするのです。そして私は、「では、あなたはオンプレミスにあるのですから、もしあと5年間そのまま維持した場合、最悪何が起こりますか？」と尋ねます。
ええ、つまり、クラウドに存在できなくなるか、ソフトウェアベンダーがメンテナンスを打ち切るかということです。さて、ちょっと待ってください。それについてさらに考えてみましょう。仮にメンテナンスが打ち切られたとしても、最悪の場合は自社でメンテナンスを行う必要が生じ、ベンダーにサポートを依頼できなくなるだけです。それならば、誰かを新たに雇わなければならなくなるかもしれません。
さあ、考えてみましょう。その選択肢は、たとえばLidlの場合、6億ドルに及ぶ大規模な変革を実施するよりも実際にははるかに低いリスクである可能性があるのです。
そのため、企業は「しなければならない」と感じるあまり、それを十分に行わないのです。アップグレードをしなければならず、クラウドに移行しなければならず、AIを取り入れなければならないと感じるためです。つまり、技術の急激な変化とその速度によって、企業は本来の目的を見失い、混乱してしまい、そもそもなぜこれらのプロジェクトを実施しているのかを忘れてしまうのです。
Joannes Vermorel: 私は、まず第一に、財務的KPIは誤解を招くものであり、正しいアプローチではないと思います。いわばあなたのデジタルジャーニーは10年先を見据えるものです。10年後、あなたはどこにいたいのかを考える必要があるのです。そうした長期的な視点が、まさにあなたがデザインしている未来の企業そのものなのです。
ですから、私の見解では、短期的なKPIに注目することは、正しいかどうかを判断する上で本質的に意味をなさないと思います。なぜなら、もしそのKPIに従えば、2002年のウォルマートが「おっと、ECなんて気にしない」と言ったのと同じようなことになってしまうからです。
それは「ECは重要ではない。小さいから気にしなくていい」と言わせる結果になります。しかし、実際には非常に重要であり、何も手を打たなければ数年後にはあなたよりも大きな巨人が現れるでしょう。これはいわば、デジタルトランスフォーメーションを逃した例です。つまり、大手小売チェーンはECの巨人になり得たのですが、デジタルトランスフォーメーションに乗り遅れたためにそれが実現しなかったのです。 But, so back to say, I would say, I’m not too, I’m more into thinking from a long-term business perspective. Do we have a back-of-the-envelope calculation that tells us this is the right thing to do? Risk-adjusted, saying there’s, you know, do you think it’s 90% risk or 50% risk or 10% risk, and try to have the simple assumption but just to justify that and to get to this direction.
そして、通常欠けているのは、先ほども触れた漸進主義です。多くの人は自社のデジタルトランスフォーメーションを「同じだが少しだけ良くする」ものと考えがちです。改めて言いますが、2002年のウォルマートに戻れば、未来はECであり、単にLCDスクリーン付きのより良いPOSシステムを導入したウォルマートと同じものでは決してありません。
これは、つまり問題の本質です。未来は根本的に全く異なるものであり、企業が10年後の自社のあり方に果敢に挑戦するために十分に踏み込んでいない部分であると思います。どのような役割が必要なのでしょうか。最近、LinkedIn上で拡散されていたShopifyのCEOによる非常に興味深いメモがあったと記憶しています。 彼は実際に皆に向けて、「当面、全ての採用活動を停止し、各部門は採用したいポジションが、既に弊社で導入、実装、接続済みのAI技術やLLMなどで代替できないことを正当化しなければならない」と述べていました。Shopifyは非常にハイテクな企業であり、その分野で既に数年の経験を積んでいます。 そして彼は、「変革に関して、私たちは明らかに問題を抱えています。このメモの本質は、上層部が非常に漸進的な視点に固執し、最終的な目標に向かってもっと野心的になっていないというものでした」と言っていました。そして、そのメッセージは非常に興味深いものだと思いました。彼らは「投資もしない、採用もしない」とは言っておらず、「これらの技術が存在することを認め、存在しないふりをして進むべきではない」という最終目標を持つべきだと言っていたのです。
それがメモの事例で、非常に興味深かった。デジタルトランスフォーメーションを遂げた企業の10年後のビジョンについて、多くの大企業が「つまり、見た目はほとんど変わらず、使い勝手が少し良くなっただけ」という考え方をしているのを見てきた。そして私にとっては、これは非常に物足りなく感じる。
10年先を考えるなら、今存在する職、特にホワイトカラーの仕事の半分は消失している状況を想定しなければならない。これは人を単に解雇するという意味ではなく、再教育や職務の変更が可能であっても、10年後には現状の少なくとも半分の仕事がなくなっているということだ。
Eric Kimberling: ええ、そして皆さんが気づいていると思うのですが、サプライチェーンやその他の職場でテクノロジーや変革のイニシアチブを主導している方々は、自らに問いかける必要があると思います。「私たちはこのイニシアチブで何を達成したいのか？ これは古い技術を置き換えて最新状態を維持するための、段階的で理想的にはコストが低いが、結果としてROIも低い提案なのか？ それとも、本当に我々のビジネスを変革し、新たなビジネスモデルやイノベーションに挑戦するものなのか？」。これは全く異なる二つの道であり、どちらが正しいとか間違っているという話ではなく、自分たちが進もうとしている道に沿って意思決定をすることが重要です。それは万人に当てはまる戦略ではなく、あなた自身の企業に合わせるべきです。Shopifyのデジタル戦略は、あなたや私、他の誰かのそれとは大きく異なるはずです。
Joannes Vermorel: 全く同意します。ただ、私が問題だと感じるのは、第一の道、つまり段階的なアップグレードでROIが低い場合に、大規模な予算が投入される点です。
Eric Kimberling: ええ。
Joannes Vermorel: そうです。そして私にとっては、合理的な概算をすればROIが非常に控えめになるプロジェクトに、なぜこれほどの投資をするのかという疑問が湧いてしまいます。実際、名前は伏せますが、5年以上にわたるプロジェクトで1億ドル以上のERPアップグレードを実施している企業について話を聞いたことがあります。上層部と議論すると、投資収益率だけでなく、実際にアップグレード後にビジネスが改善されるかどうか、そのリターンすらも見極めるのが非常に難しいのです。特に、SAP HANAのようなハードウェア要件に対応しなければならない場合はなおさらです。（SAPにこだわっているわけではなく、彼らだけの問題ではありませんが。）
Conor Doherty: 強めに言っても大丈夫だよ。
Joannes Vermorel: ええ、しかしITを5年間凍結してしまえば、その機会損失だけで莫大なコストが発生します。単なる段階的な改善では済まず、はるかに大きな変革が必要なのです。
Conor Doherty: それでEric、ちょっと補足させてください。実際のところ、Joannes、さっき「第一水準、第二水準の機会費用」という言葉を使ったばかりでした。改めてコンサルタントとしてお聞きしたいのですが、第一水準と第二水準のコストの概念を具体的にどのように説明されますか？ 明らかに、第一水準のコストというのは、例えばこのソフトウェアを買うのに5000万ドル、1億ドル、1億5000万ドルかかり、その監督のためにさらに多額の費用（何百万ドルか）が必要になる、というものです。これが第一水準のコストです。
第二水準のコストは、Joannesが先ほど述べたように、機会費用です。ここに使ったお金は、同時に別のところで使うことはできないのです。
Joannes Vermorel: あなたのITチームも、このプロジェクトにより一定期間、作業が停滞してしまいます。
Conor Doherty: これは、先ほど私が触れた財務的視点にも関わってきます。テクノロジーにこだわらない立場で会議に臨む際、どうすれば人々に理解してもらえるのか―決して見下しているわけではなく、文字通り、「1ドルを使って、1ドルのキャンディバー2本は買えない」というような例えです。つまり、第一水準、第二水準の機会費用について、FOMO（取り残される恐怖）に駆られている人々、つまり波に乗りたいと思っている人々に、どのように伝えるのかということです。
Eric Kimberling: あなたがほのめかしているのは、まだ詳しく触れていない現実的な期待値、すなわち第一水準と第二水準のコストに対する現実的な期待を持つという点です。問題の根本原因、あるいはその一因は、組織が実際のコストを理解しておらず、そのために機会費用を正しく評価できていない点にあると思います。実際には1億ドルかからないのに1億ドルだと思い込んでいる、あるいは最初から1億ドルではなく3億ドルかかるはずなのに、それが理解されていないのです。しかし、誰かに「1億ドルでできる」と説得され、その人物が努力を過小評価し、コストを引き上げる複雑さやリスクを軽視していたのです。考えてみてください。ソフトウェアベンダーやソリューションプロバイダーがソリューションを販売する際、自分たちの利益のためにコストを過大評価しても意味がないのです。むしろ、低リスク・低コストであると過小評価してアピールすることで、自分たちにとって都合が良いのです。これが問題の発端です。
それで、もし私が機会費用、つまり第二水準のコストを評価するとしても、誤った情報に基づいて評価していることになり、正確な情報がなければどんな評価をしても意味がありません。しかし、もし多くの企業が本当のコストを理解していれば、「おっと、ちょっと待って、これは莫大な金額だ。これだけの資金があれば新しい工場を建てられる、もしくは同じ費用で10店舗も開店できる。これが本当に望む結果なのか？」と考えるはずです。ほとんどの組織は、現実的でない過小評価されたコストに基づいて判断しているため、その決断点にたどり着かないのです。
そしてもう一つ、まだ触れていないコストがあります。それが運用上の混乱、つまり新しい技術を採用する際、プロジェクトがどれだけうまく進行しても、何らかの生産性低下が避けられないということです。できれば完全に生産性が崖っぷちまで落ち込むことは避けたいですが、実際にはそうなることが多いのです。それほどうまく管理されたとしても、何らかの混乱は発生するのです。
では、その混乱に伴うコストとは何でしょうか。例えば、2週間、4週間、または3ヶ月製品を出荷できなかった場合、どうなるでしょうか？ 実際に企業では、こうしたプロジェクトを進める中で何かがうまくいかず、稼働を開始した後に製品を出荷できなくなり、顧客が不満を抱いて注文をキャンセルするという事態が発生します。これが実際のコストであり、ROIを算出する際にも考慮に入れるべきコストです。すなわち、実装を最適化し、適切に管理し、本当のリスクを理解するためにも、このコストをしっかりと評価しなければなりません。
Conor Doherty: Eric、非常に鋭い指摘をしてくれましたね。そしてJoannes、今一度Ericが例示した内容に戻りたいのですが、例えば誰か—特定の個人を狙っているわけではありませんが—自動車、航空宇宙、石油・ガス業界などの平均的な水準で「1時間のダウンタイムによる生産性の損失はどれくらいか？」と尋ねれば、大まかな数値は示せるでしょう。しかし、Ericが説明したようなダウンタイムの場合、その具体的なコストを数値で示すのは難しいかもしれません。
Joannes Vermorel: はい、そして運用コストにおいても全くその通りだと思います。人々が気づいていない一つの点は、環境の複雑性が増すと生産性が低下するということです。つまり、古くて必要最低限の機能しか持たないソフトウェアがあって、それが必要なことはこなしている、という状態です。私のIT環境では、ユーザーインターフェースにボタンもオプションも多くなく、装飾的な機能もあまりありません。しかし、私は今、はるかに強力なものへとアップグレードしました。なぜなら、ベンダーに対してAFPでチェックすべき項目があまりにも多く、「これとこれとこれとこれとこれとこれ、はい、100項目目をチェック」と要求されたからです。結果として、追加機能が山ほどあるアップグレードシステムを手に入れたのです。
しかし、それはソフトウェアを操作する側にとっては、はるかに多くのメニューが出現することを意味します。企業向けソフトウェアで何度も見たのですが、ソフトを見せられて「これはひどい」と言わざるを得ません。30個ものメニューがあって、どのメニューをクリックしても、その中に30個ほどのサブメニューがあり、さらにそのサブメニューの中に5個ほどのサブメニューがある。そして、画面には20種類ものオプションが一度に表示されるのです。
そのため、私が頻繁に目にしているのは、特に記録システムのようなソフトウェアを新しく、より良いものへとアップグレードするケースです。はい、UIは洗練されているのですが、機能が多すぎるために実際の生産性は低下してしまいます。なぜなら、人々が数多くの機能の迷路に迷い込んでしまうからです。要するに、エンタープライズソフトウェアにおいては、機能が多いことが必ずしも良いとは限らず、とりわけ使われない機能が多いのは問題なのです。
システム内で使わない機能はすべて、ただの重荷に過ぎません。新しい社員が入って使い始めると、混乱を招くことになります。彼らは「なぜ動作しないのか？」と疑問に思うでしょう。ああ、それは例えば、購買注文用の画面が5種類あって、そのうちの1種類しか使っていないからです。残りの4種類は、いわば行き止まりで、そこに入力しても処理されず、ただ無視されてしまうのです。そんなものが存在するのです。
Eric Kimberling: ええ、全くその通りです。つまり、本当に必要なものを明確に定義するということに行き着くのです。そもそも、あれほどの技術が本当に必要なのでしょうか？多くの場合、企業は実際に扱える以上の技術に手を出し、技術投資に過剰にコミットしてしまいます。その結果、技術面での複雑性が増し、本当に重要なことに投資する時間や資源がなくなってしまうのです。
機会費用の観点に戻りますと、本当に重要なことに投資する時間や資源がなくなってしまいます。そして、本当に重要なこととは、ビジネスプロセスの最適化、従業員の徹底したトレーニング、導入の促進、そして新しい技術や運用モデルに合わせた従業員の役割と責任の再定義などです。
これらのことこそが、システムや変革の成否を分けるものです。しかし、企業は技術に過剰投資しているのです。私は、ほんの少しの技術を導入してそれを非常にうまく実装する企業の方が、成功する可能性が高いと考えています。そうすればリスクが軽減され、おそらくより良いROIが得られるのです。
そしてその小規模な技術投資を非常にうまくやり遂げれば、組織内に信頼、能力、成熟度が生まれ、今や「さて、次はより大きなプロジェクトに取り組もう。もう十分学んだから、もう少し技術に投資できる」と自信を持って言えるようになるのです。
そして、大規模なシステムを一括で購入し、莫大な費用をかけ、そのお金を払ったからには全て実装しなければならないというプレッシャーが生まれ、結果として複雑性だけを増大させ、採用やプロセス改善など本当に重要な部分に投資しなかったために、多くのプロジェクトが制御不能に陥るのです。
Conor Doherty: 実際、そして先ほどのJoannesと同様に、あなたはまさに私が次の質問またはフォローアップとして書き留めたことを予告してくれました。私たちは既に問題点や回避すべき落とし穴について長々と議論しました。しかし、これが実際の実装、そして変更管理、すなわちチェンジマネジメントのプロセスという概念を浮き彫りにするのです。
それでは、Eric、まずあなたにお伺いします。より明るい話題として、成功したデジタルトランスフォーメーション、特に変更管理、企業文化、期待値などの観点で、何か観察されたことはありますか？実際にそれを支援する要素とは何でしょうか？
Eric Kimberling: ええ、ではあなたの使った言葉に戻りましょう――正直さ、というか、機械的な共感？それとも共感、でしょうか。私自身は内心「機械的な好奇心」と考えていました。どちらも有効だと思います。どちらもほぼ同じことです。機械的共感――先ほどは私が混乱してしまいましたが――これは非常に重要な要素なのです。
なぜなら、私たちが見てきた最も成功したプロジェクトは、組織内のビジネスリーダーが自ら手を動かして参加しているものだからです。彼らは技術を理解しており、設定やコーディングの専門家である必要はありませんが、技術がどのように機能しているかを理解しています。そして、自社のビジネスがどのように動いているか、またどのように動いてほしいかを確実に把握しているのです。
その機械的共感は、技術主導ではなくビジネス主導の成果を生み、より一層のオーナーシップをもたらします。これが、私たちが非常によく目にする、つまりプロジェクトへの所有意識と、組織内のビジネスリーダーの実践的な関与につながるのです。
もう一つは、変革をアウトソーシングしないという点です。彼らは単に「大手ベンダーを呼んで全て任せる」というのではなく、「専門家を招くとしても、私たちが彼らを管理する」という考え方です。新しい工場を建設するために下請けやゼネコンを管理するのと同じです。
おそらく彼らは「どうでもいい、ただ工場を建てろ。ベストプラクティスを使え。必要なことをすべて実行すればいい」とは言わないでしょう。むしろ、工場が仕様を満たしているかを厳しく確認するため、深く関与します。しかし、多くの企業は技術プロジェクトにおいてそうしていません。そのため、成功している企業は技術投資や変革を、他の資本投資と同様に扱っているのです。
彼らはそれを特別扱いせず、ROIを期待し、予算を制限し、深く関与し、物事の進捗について多くの発言権を持ちます。こうしたことがすべて最初から行われるため、これが重要な成功要因となるのです。
もう一つは、先ほどどなたかが述べた初期段階の意思決定です。実行が重要でないとは言いませんが、実際の実行に至る前の決定事項、すなわち、下される判断、設定される優先順位、そして整合性の確保こそがさらに重要なのです。
チーム内で整合性を取ることです。例えば、7人の重役と運営委員会がいる部屋に入って、「この変革は組織にとって何を意味するのか？」と尋ねた場合、通常7通りの回答が得られます。それらは必ずしも正しいとか間違っているという問題ではなく、皆異なることを述べるため、成功は難しくなります。
採用する人物や導入する技術にかかわらず、全員が同じ認識を持たなければ、プロジェクトは成功しないのです。プロセスは混沌としており、理論上は「ちょっと待って、技術の導入を一旦停止し、まず整合性を取ろう」と言うため、短期的にはプロジェクトが遅れるかもしれません。
人々は「でも、今日から始めなければならない」と考えます。既にスケジュールが遅れているからと。しかし、私たちは「急いで始めたら崖から転げ落ちるようなものだ。だから、崖から落ちないように、明確な道筋を確保してから全員で同じ認識を持とう」と言うのです。
ですから、その整合性を確保し、戦略目標、パラメータ、優先順位、ビジネスケース、期待、ガバナンス、そして将来的な業務プロセス、つまり今後どのようなプロセスにし、組織をどうしたいのかを、技術導入前にすべて明確に定義することが非常に重要な成功要因となるのです。
そして最後に挙げるのは、変革管理への投資です。ここで言う投資とは必ずしも多額の資金を意味するわけではなく、組織変革、コミュニケーション、採用、そして組織の明確な方向性に対して時間と集中力を投じるということです。これらすべてが成功率を飛躍的に高めるのです。
Joannes Vermorel: あなたの逸話に同意します。実際、私もソフトウェアエンジニアですから、ソフトウェアの世界では「実装したい問題について3時間考えると、その3時間が結局3週間分の余分な実装時間になった」という言葉があります。
しかし、最初のケースに戻ると、多くの大企業は「そうだ、慎重に計画を立てる必要がある」という考えを持っています。彼らはその助言を聞いており、私たちが最初に言ったわけではありません。しかし、私はこの考え方が組織内部で歪められているのを目の当たりにしています。もちろん、非常に明快に考え、極めて重要なこの段階に多少の時間を割くことは正しい方法だと全く同意します。
しかし私が見てきたのは、多くの大企業がこの考え方を、チェック項目を埋める作業や官僚的な手続き、つまり「計画段階だから、このレポートやあのレポート、検証、監査、診断ミッション、などなど」を求める演習に堕してしまうことです。その結果、明快さは得られず、何千ページにも及ぶが全くの不明瞭な文書だけが残るのです。これが、私が言うテクノクラシーです。
この計画段階では、組織から情報を集めるだけで、誰もが要求に過剰に従ってしまいます。例えば、あなたが取締役会だとすると、1か月のうちに各チームが数千ページにもなる評価や診断の資料をまとめ上げたとします。しかし、その内容については誰も全く理解していないのです。これは、アメリカ議会の包括支出法案のようなもので、膨大な文書で何千ページにも及び、何が含まれているのか誰にも分からないのです。
私の見解では、この計画段階において、人々はこれをテクノクラティックな手続きとして取り組むべきではないという認識が必要です。明確に記述された文書は、最大でもたぶん5〜20ページ程度、理想的にはそれ以下でなければなりません。もし20ページ以内で明確に表現できないのであれば、おそらくあなたはテクノクラシーの迷路に迷い込んでいるのです。
その後、あなたの道は大いに誤った方向へ進んでしまうことでしょう。そして、私が言いたいのは、テキストで書かれた文書であってPowerPointではないということです。なぜなら、PowerPointでは箇条書きでごまかすことができ、論理的な連結がなく、非常に曖昧なものになってしまうからです。もし、適切なサインや連結を伴った英語で書かれた文章なら、ごまかしはできず、意味が通じ、音読も可能な文書が必要になるのです。これが私のこの考え方に対する見解です。
Eric Kimberling: 素晴らしい指摘です。そして、プロジェクトを実行するチームもまた、その明確さを持たなければなりません。例えば、サプライチェーントランスフォーメーションを考えてみましょう。完全なサプライチェーン技術の導入を目指す組織の場合、複雑な詳細の中に迷い込むのは容易なことです。
システムに対して皆が平等に発言権や優先順位、要求を主張するような民主主義的な扱いをしてしまうと、プロジェクトは制御不能な状態に陥ります。そこで、「そうだ、私たちはサプライチェーンの変革を行うが、現時点での最優先事項は調達ではなく、サプライヤー管理やベンダー管理である」といった統治が必要なのです。
なぜなら、アメリカ政府が今や各種関税を課していること、また対処すべき地政学的な問題が山積しているため、より良いサプライヤー管理が必要となっており、これが我々の焦点となるのです。優先順位を定め、「サプライヤー管理プロセスを刷新するためにこれを実施する」とし、適切に管理する必要があるのです。
もし、5〜20ページの文書に明確さがなく、全員が同じ認識を持たなければ、誰もが自分の望むものを勝手に要求する無秩序な状態に陥るでしょう。
Joannes Vermorel: ちなみに、実際に多くの企業を見てきましたが、Amazon、Shopify、Appleといったアメリカのテック企業から流出した高品質な文書以外は、一度も見たことがありません。あの流出メモは非常に明確で、5ページに凝縮され、美しく書かれているのです。そこから、経営陣が自社の現状や目指す方向性を非常に鋭く理解していることが窺え、明瞭かつ簡潔に記述されているのがわかります。
非テック企業に目を向けると、そのような文書は極めて稀です。極めて稀で、私が思い浮かぶのはせいぜい十数社だけです。たとえばバークシャー・ハサウェイの場合、そのメモは絶対に素晴らしく、自社の取り組みやその理由が明瞭に記されています。しかし、多くの企業、例えばリドルなどの場合、「我々は一体何を達成しようとしているのか？なぜこのプロジェクトが成功する可能性があると確信しているのか？」というシンプルなメモさえも存在しないと、私は確信しています。
私が目にする大規模プロジェクトのほとんど――Lokadがその一部である場合もありますが――ERPのアップグレードやサプライチェーン分析の刷新を行うのですが、それは非常に稀です。だからこそこの点に触れているのです。デジタルトランスフォーメーションに関して、どれだけの明確さもほとんど見られず、ただテクノクラシーの層が重なっているだけなのです。
再び、あなたはアウトソーシングについて言及しました――つまり、企業外部の全く別の存在のことです。ですから、あの何千ページにもなる文書の半分は、外部のサードパーティベンダーによって提供されるのです。
Eric Kimberling: テック企業についてあなたが述べたことは非常に興味深いですね。正直なところ、それには気づいていなかったか、またはその関連性に今まで気づかなかったのです。もしかすると、テック企業のほうが明確な文書を提供する能力において、より有能で成熟しているのかもしれません。
でも、ふと思うんだ。時々、今の経営者たちは―例えば90年代からテック界隈で育ってきた経営者たちのことを考えると、彼らは私と同じくらいか、少し年上かもしれない。Windows 98が登場したときのことを覚えている。Windows 98が展開されたとき、それは大きな話題だった。
多くの企業にとっては大きなWindowsのアップグレードを余儀なくされたため、ある意味で混乱を招いた。しかし結局のところ、それは単なるWindowsのアップデートであり、変革ではなかった。すなわち「私たちのPC、デスクトップ、ラップトップには新しいオペレーティングシステムが必要だ」ということだった。
あの時代にIT分野で育った経営者たちは、テックプロジェクトを依然としてWindows 98のアップグレードと考えているのかもしれない。そして、これは単なるWindows 98のアップグレードではなく、バックオフィスのシステムやデータベースだけでなく、プロセスや組織の在り方といった全体の大改革であるということに気づいていないのだろう。
それはあくまで仮説に過ぎない。真実かどうかはわからないが、ここで議論している事象の根本原因を探ろうとしているのだ。
Joannes Vermorel: 私の見解では、非テック企業のデジタルトランスフォーメーション計画を見るとき、私自身がテクノロジストとして―Lokadは本質的にサプライチェーンのためのロボット化された意思決定を行うソフトウェア会社だ―それらのデジタルトランスフォーメーションは非常に控えめなものに見えるということだ。
自社のデジタルトランスフォーメーションを考えると、あなたが指摘したようにテクノロジーは進化し、Lokadにおいて多くのことが変わろうとしているため、10年後には、現在の仕事の半分以上がタスクとして消失しているように感じる。人々はそのまま残るが、彼らが従事する業務は異なるものになるだろう。
古典的な非テック企業―例えば航空会社、製造会社、リテール会社、ファッション会社など―テクノロジーが付随的な要素に過ぎない企業のデジタルトランスフォーメーションを見ると、それは非常に非常に控えめなものだ。
既製の形で仕事が削減されたり、タスクがなくなったりすることはほとんどない。例えば、ChatGPTのようなツールができることを考えれば、明らかに自動化が可能なタスクのカテゴリーが存在することがわかる。
ともかく、私の考えでは、デジタルトランスフォーメーションはしばしば野心に欠け、非常に控えめなものだ。ただし、アップグレードを実行するための予算だけは手に負えないほど大きい。
Conor Doherty: そこで飛び込んでその上に積み上げてほしい。なぜなら、背景にはオープンループのようなものがあるからだ。根本的な考え方、すなわち問題の枠組み自体を振り返ると、最終的に私たちが解決しようとしている問題に戻ってくる。ジョアネス、まずは君から、その後エリックにコメントを求めるよ。
ジョアネス、実はエリックが先ほどcapexとopexについて語ったのを聞いて、君がサプライチェーンにおけるプロダクト指向のデリバリーについて行った講義を思い出しながら話を始めたんだ。君はサプライチェーンはopexではなく、資産として扱われるべきcapexに再分類されるべきだと主張していた。その問題を単純に、サプライチェーンおよびその関連コストを、クッキーやペンのような一日の必需品とみなすのではなく、価値が上昇し拡大可能な資産として扱うという枠組みで捉えることが、議論の出発点として有益ではないかと思った。つまり、人を雇うにしてもソフトウェアを導入するにしても、そうすべきではないか。そこで、その違いについてもう少し詳しく説明してもらえるか？
Joannes Vermorel: そうだね、あくまで個人的な意見だが。ホワイトカラーの仕事を見ると、特に特別なものでなければ、企業が情報変換という一定のアウトプットを得るために支払うべきものに過ぎないと思う。ホワイトカラー労働者は基本的に情報を受け取り、さまざまな形で情報を出力する。しかし、多くの人々、特に大企業のバックオフィスでは、それがまさに彼らの業務内容だ。例えばサプライチェーンでは、ERPから在庫レベルや最近の売上など多数の指標を取得し、各SKU、すなわち保管単位ごとに「再注文が必要か、不要か」を決定する。管理すべきSKUが1000あるとすれば、組織は分業され、例えば1人のdemand plannerが1000のSKUを担当する。全体では80,000 SKUがあり、80人の需要供給プランナーがいて、それぞれが毎日1000のSKUをチェックし、その日の補充注文を発する。多くの企業はまさにこのように組織されている。
したがって、私の見解では、上記のようなサプライチェーンの実践を考えると、その人材は純粋なopexだ。企業が継続して運営されるためには、毎日その給与を支払い続けなければならない。もし支払いを止めれば、彼らは働かず、企業活動は停止し、商品の流れも止まる。Lokadのアプローチは「いいえ、我々はサプライチェーンの実践をcapexと捉えるべきだ。我々には何らかの方法でソフトウェアを設計するエンジニアがいる。ローコードなども含め、必ずしもコーディングする必要はないが、補充の意思決定を自動的に生み出すソフトウェアを構築している」という考え方だ。
そして、もし誰かに追加で支払うとすれば、それはシステムの改善のためである。この場合、あなたの投資はcapexとなる。このソフトウェアは自動で動作し、opexはそのソフトウェアのためだけにかかるので支出は非常に低い。そして、人に支出をかけるとすれば、それはシステムの改善のためであり、その結果として非常に資本主義的な、積み増し可能な資産となる。つまり、人への投資が資産となり、その人々の成果が企業にとって有形の資産、すなわちこの意思決定システムとなるのだ。
現代のデジタルトランスフォーメーションを見ると、純粋なopexであるホワイトカラーの仕事が膨大に存在しており、本来はcapexに転換されるべきものが多いという意味で、非常に控えめに感じる。人が1時間働けば、積み重ねられる何か、資産を構築する何か―おそらくはソフトウェアだが、企業にとって価値のある他の成果でもよい―を生み出すはずなのに。それは少し奇妙に聞こえるかもしれないが、まるでその人々が機械を設計し、その機械を無限に稼働させるかのようだ。もちろん、簡略化しているが、その機械にもメンテナンスなどが必要だ。しかし、私が見る限り、ほとんどのデジタルトランスフォーメーションは、単にopexとして利用される人材―すなわち使い捨てのようなもの―に依存しているため、非常に控えめである。何度も何度もその人々の時間を再利用しなければならないのだ。
ここで言っているのは、単に情報処理のタスクについてであって、レストランでバーガーを裏返す作業ではない。そのような作業には手が必要だ。バーガーを裏返すことができるロボットはまだ存在しない。しかし、私はホワイトカラーのバックオフィスの仕事全般について語っている。私にとって、多くのデジタルトランスフォーメーションは、実際にはそれらの業務の大部分を完全にロボット化すべきであるという事実にほとんど触れておらず、クライアントの前に出ることもない。全く内部の忙しい作業であり、多くの大企業では、ホワイトカラー労働力の3分の2が社内のバックオフィス業務に従事している。非常に頻繁に、これらのデジタルトランスフォーメーションは、capexに転換されるべき莫大なopexに対処できていないと感じるが、これはあくまで個人的な意見である。
Eric Kimberling: 非常に興味深い点、そしてテック業界、特に企業向け技術分野全体が直面する大きな課題に触れているね。君はcapexとopex、そしてITを資産として扱うことについて多く語ってきたが、テクノロジーベンダーの行く先を見れば、それは顧客にとっての資産ではなく、むしろベンダー自身の資産となるモデルに向かっている。もちろん、元々そうであった部分もある―彼らの製品であり、知的財産だからだ。しかし今、オンプレミス、つまり大きな資本投資を行い、ソフトウェアを自社のプロセスに合わせてカスタマイズし、それを減価償却する資産として扱う形から、すべてをクラウドに移行している。すべてのデータがクラウド上にあり、これがcapexからopexへの移行を意味している。そしてこれは単なる会計処理上の問題だけではない。
これは考え方の変革を意味している。例としてAIを見てみよう。大手テクノロジーベンダーは「我々には、貴社に素晴らしい価値を提供できるAI技術がある」と語る。それは事実かもしれないが、その過程で、我々は自社のデータや知的財産を取り出し、それを使って他の競合他社や企業で使用されるAIモデルを訓練している。結果として、力の中心は顧客からベンダーへと移っている。なぜなら、今やベンダーはデータを所有している訳ではなく、自社のデータを使って訓練されたより優れたAI技術を所有し、それを他社に販売するために活用しているからだ。
だから、これは非常に重要な問題だ。私たちにとってITとは何かという大きな疑問を投げかけるものである。ITは単なるバランスシートから排除したい、もしくは業務から外したいコモディティなのだろうか？それも一理あるかもしれない。しかし、君はAmazonやSpotifyの話に触れた。保証する、AmazonやSpotifyはITを誰かに管理させる単なるコモディティとは見なしていない。それは大きな競争上の優位性であり、我々全員がAmazonやSpotifyを目指す必要はないが、例えば「もし我々の競争力が非常に効率的なサプライチェーンにあるなら、誰よりも速く製品を顧客に届け、迅速にカスタマイズして提供できる。それが競争上の優位性だ。では、その優位性を模倣しにくい、あなただけの独自技術を構築しよう」という目標を持つべきだ。もし誰でも購入できるクラウドソリューションに頼ってしまえば、優位性を失ってしまう。
つまり、プロセスのクラウド標準化、他者の利益のためにデータを使ってAIモデルを訓練するという動き全体が変化していると思う。これは非常に危険な傾向であり、今後何年にもわたって多くの組織に後悔をもたらすだろう。だから、立ち止まって考えることが重要だ。我々がITを戦略的資産、すなわち差別化の要因としたいのであれば、そのプロジェクトをそのように扱うべきだ。おそらく、それはクラウド上の標準的な既製技術に頼るのではなく、よりカスタマイズされたソリューションを採用することを意味する。たとえ「カスタマイズ」や「カスタム開発」という言葉が好ましくなくとも、ITを戦略的優位性と見なすならば、それが正しい選択かもしれない。
Joannes Vermorel: 優位性、確かに。そして、もう一度指摘するが、多くのベンダーは全くひどいインセンティブを持っている。再び言うが、企業向けソフトウェアベンダーの大半は席ごとに料金を請求している。席単位で料金を取るということは、決して生産性の向上を追求していないということだ。もしソフトウェアをより非効率に、または生産性を下げることができれば、より多くの席を確保できるわけだから。
ご覧の通り、もちろん企業向けソフトウェアベンダーが悪意を持っているわけではない。ほとんどの従業員は、全体の90%と同様に良い人たちであり、製品を意図的に劣化させてまで席を増やそうとはしない。しかしながら、インセンティブの力は非常に重要なのだ。
例えば、ソフトウェアベンダーが、ソフトウェアを操作するために多数の人員を必要とする状況があれば、その結果として…ソフトウェア会社のCEOが自社の売上を見たとき、「おお、ここには大きな牽引力がある」と言うだろう。ここでは、ソフトウェアと相互作用する多くの人が必要とされるため、それが収益を牽引するのだ。
そして突然、事態は非常に複雑になる。もし次のアップグレードで席の90%がなくなる可能性がある状況で、席ごとに料金を請求しているのなら、ソフトウェアベンダーとして自らに挑戦する価値があるだろうか。それは非常に、非常に厳しい問題だ。ちなみに、歴史的にそれはすでにIBMにも起こった。IBMは1980年代や1990年代にMIPS（1秒あたり何百万命令）ごとに料金を請求しており、その結果、各世代ごとにソフトウェアがますます遅くなっていったのは明らかだ。
Eric Kimberling: そうだね、君はまた、期待の不一致やインセンティブのズレという、エピソード丸ごと語り合えるほどの別の話題を提起している。例えば、ソフトウェアベンダー、システムインテグレーター、そして主要な三者が全て非常に異なり、衝突するインセンティブを持っている場合、それを克服するのは困難だ。
Conor Doherty: 途中で失礼するが、エリックの時間を大切にしたい。君は非常に寛大に我々と共にいてくれたので、少なくとも後で皆の行動の倫理について話すかもしれないが、今日は締めくくりの考えに移る。まず明るい展望として、ジョアネス、君から始めてほしい。これまでの議論を踏まえて、あるいはこれまでのすべてを考慮して、デジタルトランスフォーメーションを始めようとしている組織にどんなアドバイスをする？
Joannes Vermorel: 40年以上にわたるソフトウェア愛好家として―若い頃は主にビデオゲームに熱中していたが―生涯にわたるソフトウェアファンとして、これほどソフトウェア技術に大きな可能性が感じられる時代は他にないと思う。私にとっては、ディープラーニング革命や、その子孫であるLLMなど、まるで魔法のようなものだ。自然言語を処理して多くのことを実行できるという考えは、実に驚異的だ。
絶対に信じられないほどで、これらの技術は容易に利用できます。必ずしも安価とは限りませんが、容易に利用できるのです。ですから、デジタルトランスフォーメーションからこれまで以上のことが期待できる時代はなかったと言えます。今、このデジタルトランスフォーメーションは、御社を全く異なる存在に変え、お客様にあらゆる面で大きな価値を提供するという約束を秘めています。お客様へのより良いサービス、よりスマートな運用、何でも可能です。その潜在能力は計り知れないほど大きいのです。
ですから、大きな夢を描き、その上で慎重にかつ段階的に投資していくべきだと思います。巨大プロジェクトのようなものではなく、リスクがあるためです―これがデジタルトランスフォーメーションにおける私のメッセージです。ソフトウェアベンダーとして言えるのは、クライアントに “Can you give me a really bad estimate for what will happen during the next six months?” と尋ねた場合、6ヶ月なら大雑把な見積もりができるかもしれません。ですが、1年になると難しくなり、2年になるとさらに複雑になります。なぜなら、人員が出入りすることもあり、2年にわたるプロジェクトは混乱を招く可能性があり、非常に困難だからです。
5年―ああ、これはまるでデス・スターの設計を試みているかのようです。つまり、私の見解では、デジタルトランスフォーメーションには巨大な可能性があるということです。それは素晴らしいことで、それほど費用もかからないのですから、動作することを確実にするために慎重になり過ぎるのではなく、むしろ挑戦すべきです。逆のアプローチ、すなわち小さなことから始め、迅速に実行し、早期に失敗を認識できる体制を整えるべきです。そうすれば、失敗した場合でもそれを沈没費用と認め、無駄な投資を倍々に増やす—まさにその結果、企業向けソフトウェアベンダーがクライアントに最初の支出の10倍もの費用を負わせるという事態を招くレシピを避けることができるのです。
あなたはこう言えるようにならなければなりません。「いや、やめるんだ。我々は試し、見て、終わった。世の中は広大だし、可能性は無限だ。最初の計画に固執する必要は全くない。3ヶ月後にイニシアチブが失敗しても構わない。しかし、3年後に失敗するのは決して許されない。」
Eric Kimberling: すでに数十億ドルまたは数億ドルを費やした後で。
Joannes Vermorel: はい、はい。
Conor Doherty: では、Eric、ここではゲストに最後の言葉を譲るのが習慣です。ですから、もう一度同じ質問ですが、これから旅を始めようとしている人々や企業に、何かアドバイスはありますか？
Eric Kimberling: ええ、つまり、あなたが先ほど提供した素晴らしいアドバイスに加えて、さらに申し上げるなら、チェンジマネジメント、つまり変革管理に投資することです。失敗を早期に回避できるよう、変革管理に時間を投資することを確認してください。しかし、確かに失敗を早く経験することも大事です。だからこそ、小さく始め、ゆっくりと進めてから加速する方が、最初から大きく急いで始めて後でスローダウンするよりもずっと効果的だと思います。そうしなければ、組織内で多くの士気の問題や、多くの 不確実性 と疑念を生むだけです。
つまり、早期に失敗を経験することも大切ですが、組織変革にも投資するべきです。そしてもう一つ言いたいのは、プロジェクトの最初の数ヶ月、技術の実装を始める前の段階で軌道が決まるので、その部分に十分な時間をかけるべきだということです。つまり、ビジョン、パラメーター、プロジェクトの方向性を確立するのです。その部分を確実に正しく設定してください。もしその明確さに疑問があるなら、時間をかけて確実なものにしてください。
なぜなら、初期段階でその部分を正しく整えるために多くの時間を費やせば、全体としての進行は速くなるからです。実際、初期でゆっくりと取り組むことで、実装はずっと速くなり、大幅に時間と費用を節約できます。後から加速することは可能ですが、まずはゆっくりと始めるべきです。これが私の最後の締めくくりのアドバイスです。
Conor Doherty: これ以上質問はありません。お時間をいただき、本当にありがとうございました、Eric。心から感謝しています。
Eric Kimberling: 素晴らしい会話でしたし、とても楽しく、私も楽しみました。
Conor Doherty: では、Joannes、これ以上申し上げることはありませんが、重ねてお時間をいただきありがとうございました、Eric。また、皆さん、ご視聴ありがとうございました。では、また次回お会いしましょう。
