デジタルサービスのパラドックス　- デジタル化は何が難しいのか？ -

デジタルサービスのパラドックス デジタル化の困難性 Ⅰ B-frontier研究所 高橋 浩 ー デジタル化は何が難しいのか？ ー

自己紹介 - B-frontier研究所代表 高橋浩 • 略歴： • 元富士通 • 元宮城大学教授 • 元北陸先端科学技術大学院大学 非常勤講師 • 資格：博士(学術)(経営工学) • 趣味/関心： • 温泉巡り • 英語論文の翻訳 • それらに考察を加えて情報公開 • 主旨：“ビジネス(B)の未開拓地を研究する” 著書： 「デジタル融合市場」 ダイヤモンド社(2000),等 • SNS： hiroshi.takahashi.9693（facebook) ＠httakaha（Twitter）

目的 • デジタル技術の進展によって、製品、サービス、ビジネス モデルなど、多様なビジネス活動の本質が根本的に変化し た。 • そして、覇者の一人と目されていたGEの手痛い失敗などで、 デジタル化への適応には大きな困難が伴うとの認識も広 がった。 • 失敗の原因は何だったのだろうか？ • 現在、DX化推進によってB2Bビジネス世界でもデジタル化 は着実に進行している。 • そこで、その原因と困難な理由の明確化を行う。 3

目次 1. はじめに 2. パラドックスの原因と克服手法 3. デジタル時代のアジャイル開発 4. デジタルサービスのための組織化 5. これからのデジタルサービス 4

1.はじめに GEの失敗 • GEは、ジェフ・イメルト元会長兼CEOのイニシアティブで GE Digitalを創設し、「デジタル産業企業」としての地位を 再定義する取組みに着手した。 「昨晩、もし産業企業として就寝したとしても、今朝はソフ トウェアおよび分析企業として目を覚ますでしょう。」 ・・ジェフ・イメルト GEは40億ドル投資したDX化で失敗 5

デジタルサービスの事例 • 追跡管理、サイト最適化などを強化したデジタルカスタ マーサービス、などがある。 ✓多数の製品（車、ロボット、飛行機、建設機械、など）の運用、 性能を監視し分析・対処 ✓障害時や性能アンバランス時には適切な対応も実施 • サービス提供プロバイダー例：GE、SIEMENS、ABB、な ど多数 6

デジタルサービスの困難性 1. 技術の進歩が速すぎて複雑なデジタルシステムの開発に苦労す る。 2. デジタルシステム開発は社内R&D部門では対応できず、顧客と の接触で開発しなければならない。⇒真に顧客向けの価値創造 に苦労する。 3. また、殆どのプロバイダー、顧客は共創的イノベーションの準 備ができていない。 4. 結果、プロバイダー、顧客は多大な労力を費やしても真の顧客 価値創造に到らないことが多い。 5. その延長で、プロバイダー、顧客はどちらも投資に見合う利益 を上げられない。 ⇒ デジタルサービスのパラドックス 7

パラドックス克服の新たな方法は・・ • 更なるデジタル化による敏捷性の促進 • 価値共創のため顧客とのエコシステム上でのより大きな関 与の促進 • しかし、 ◆企業が敏捷性の原則を現場に一層浸透させるにはどうすれば よいのか？ ◆デジタルサービス価値の共創を適切に創造し運用・管理する 方法はどのようなものなのか？ 8

どのような方向性がありうるか？ • デジタル技術例： ✓AI ✓分析 ✓仮想プロトタイピング ✓運用プロセスシミュレーション、など • 新たな作業方法例： ✓実験 ✓調査 ✓高速失敗アプローチ、など 9

どのような方向性がありうるか？（続） • 顧客との価値共創を管理する手法は？ ✓デジタル化は顧客の役割を変革し、より顧客中心のアプロー チへの路を拓きはするが・・ ✓そのプロセスがどのように処理されるかは不明 ◆より明確なガバナンスが必要 ◆デジタル技術の使用が組織の境界を超えると、様々な部門 の枠を超えた主体者の役割と責任は変わる。・・それにどう 対処するか？ 10

2.パラドックスの原因と克服手法 原因分析と克服手法 原因 手法 • デジタルサービスパラドックス発生の推定原因を提示 1. これらを克服することが期待される手法の提示 2. この手法の有効性検証のための枠組み 3. サンプル（インタビュー結果）による分析 11

デジタルサービスパラドックスの原因 • 収益源の過大評価（新しいデジタルサービスが生み出す売 上高予想はしばしば誇張される）。 • これは次のような理由で発生する。 ① デジタルサービスに多額の投資を行う企業は既存ビジネスを食う リスクがある(機器の最適使用は既存スペアパーツ販売、臨時メ ンテナンス収益を減少させる) ② 技術ソリューションが非常に複雑なため、収益モデルが顧客と一 致しないことがある(デジタルサービスの価格が高くなり顧客は 支払いを拒否する)。 ③ デジタルサービスは顧客に価値を提供するため相互依存を高度に カスタマイズさせなければならない(結果、拡張が難しくなり、 他顧客に販売できなくなる)。 12

デジタルサービスパラドックスの原因(続) • 維持・デリバリコストの予期しない増加（デジタルサービス は低コストで追加の顧客価値を生み出す安価な方法と見做さ れやすい）。 • これは次のような理由で発生する。 ① デジタルサービスを提供しようとすると、バックエンド、フロン トエンドでの新機能開発にかなりのコストがかかる(従来の日常 業務と操作が異なるので)。 ② 追跡管理や結果ベースの契約はプロバイダー側責任を利用しよう と顧客行動が変化する可能性がある(これへの対応に思わぬコス トがかかる)。 ③ プロバイダー、顧客双方は技術の変化や顧客要求への対応のため、 ソフトウェアやセンサーを定期的に更新することが求められる (これも思わぬコストがかかる)。 13

パラドックス克服の手法（例） • 上述の課題に対応するため、アジャイル共創プロセスの導入 を想定とする。 時間的プロセス フェーズ１ フェーズ２ フェーズ３ フェーズ４ フェーズ５ デジタル ニーズの 識別 デジタル化 価値の優先 順位付け マイクロ サービスの 開発 マイクロ サービスの 実装 マイクロ サービスの 評価 チーム編成 プロバイダーと顧客双方からのキーメンバーによる複数チームを設置し、そ れら間の相互作用によって管理する。 A デジタル化統 括チーム プロバイダーと顧客の利 益を一致させる役割 B C アジャイル開 発チーム 運用・実装 チーム デジタルサービスの可能性を テストし検証する役割 運用・実装を指示し最 適化を評価する役割 14

有効性検証のための方法 • 【デジタルサービスからの収益はデジタル開発への投資を充分 回収できないジレンマに常に直面していることを前提として】 • デジタルサービスのパラドックスの原因把握 • アジャイル共創プロセスを通じてこの課題にどのように対応し ているかをマッピング • 【サンプル事例における対応者のインタビュー結果を例示的に 対応付けることで】 15

インタビュー・サンプル事例 • B2Bにおけるプロバイダーと顧客間のデジタルサービス共 同作成に関わるインタビュー • サンプル：世界的プロバイダー（主にABB,Ericsson,Volvo 建機,Sandvikなどスエーデンの多国籍企業）とその顧客 世界4大ロボッ ト企業の１社 世界的な通信 機器企業 世界的な 建機企業 Mining機器、 超硬工具などの 世界的企業 • プロバイダーと顧客間で良好な関係を確立したケースを選別し て 16

フェーズ１：デジタルニーズの識別 • デジタル化の目標を定義する。（ A A） • 共通の目標に向けてKPIを作成する。 • プロバイダー、顧客に割り当てる資金量を決定する。（ A A） 「統括チームは、戦略的ニーズを設定し、ビジネス分析を 実施する責任があります。・・我々のアプローチは、テクノ ロジー主導でもデータ主導でもなく、ビジネス主導です。」 • システムの複雑性を理解し、全体的視点から通常見えない新た な可能性や機会を確認する。( B ) 「我々は、プロセスからビジネスを見ることにより、どのよう にそれらの業務を改善できるかを高いレベルから開始する 必要があります。・・」 17

フェーズ２：デジタル化価値の優先順序付け • デジタル化の機会を選択しコンセプトを設計する。（ A A） • 複雑さに関するコストと期待収益をバランスさせる。 • どのような新しい技術にアクセスできるか、何をカスタマイズ すべきかを評価する。（ B ） 「まず、10〜50の異なる顧客の問題を特定し、そのうち の1つを選択して、価値提案の構築から開始します。(どう すれば作れるか？どうすれば問題を解決できるか？)」 • ソリューションの実装と使用に関する概念レビューに従事する。 (C C )「プロセス全体を通して、私たちは常に制作スタッフとミー ティングを行い、さまざまなソリューションについて話し合い ました…（あれまたはこれをどのように望みますか？）」 18

フェーズ３：マイクロサービスの開発 • 要件追加などによる繰り返し設計の発生も考慮して検討する。 （B B） • 要件を早い段階では凍結せず、要件の最終セットはプロバイダー、 顧客両サイドからの入力によって繰り返し開発する。 • 運用上の価値を確認するためのテスト、改善サイクル作業をかな りの量想定する。（ B ） 「データとデジタル環境を計画するために必要な時間・金 を適切に投資することをいとわない顧客が必要です。・・彼 らからの大きなコミットメントを必要とするからです。」 • AIや自動化ソリューションアプリなど最適化を行うものに対して も新しい作業手順を想定する。( C C) 19

フェーズ４：マイクロサービスの実装 • マイクロサービスの実装を組織からの賛同を得ながら管理する。 （A A） 「・・それはトップマネジメントからの真のビジョンとコミットメ ントを必要とします・・。」 • 実装サポートの提案と基盤技術の改良に注力する。 ( B B) 「大規模な実装では、コストが手に負えなくなる可能性が あるため、顧客とやり取りできる人が現場にいるでしょう」 • デジタルシステムの使用方法と作業プロセス、ルーチンを改善す る体系的トレーニングを行う。( C C) 「テストでは、eラーニング、試運転トレーニング、教室での トレーニングと現場でのトレーニングを行っています。」 20

フェーズ５：マイクロサービスの評価 • マイクロサービスのパフォーマンス監視と価値の実現、運用上の 収益性評価に重点を置く。（ A A） 「顧客は価値を得た場合にのみ毎月支払うことになります …。KPIが満たされていない場合は、顧客は契約をキャン セルする可能性があります。」 • この段階では価値拡大の機会を探索することに注力する。( B B) • マイクロサービスは定期的に改良が必要である。 • 運用に加えて、運用学習を捕捉しソリューションのパフォーマン スを定期的に確認する。 （ C C） 「毎月の運用会議を開催します。そこでは何を改善する 必要があるかについて良い洞察を得ることができます。ま た、顧客の関与を長期に渡って維持できます。」 21

アジャイル共創プロセスのキー活動と役割 時間的 プロセス チーム編成 A デジタル化目標の 定義 ・戦略的ニーズの 定義 ・高次元KPI識別 ・共同開発投資 デジタル化の機会 の選択 ・使用価値に応じ た優先順位付け ・複雑さ/コストと 潜在的な価値のバ ランス確保 開発リソースの優 先順位付け ・スコープ変更の回 避 ・価値の低いマイク ロサービス概念の 除去 マイクロサービスソ リューション実装の 管理 ・適切な計画の確 保 ・実装リソースのコ ミット マイクロサービスパ フォーマンスの監視 ・KPIの評価 ・営業利益の評価 B デジタル化の機会 評価 ・運用プロセスのレ ビュー ・顧客改善ニーズ のマッピング ・ボトルネック特定 デジタルマイクロ サービスの概念設 計 ・価値想定の検証 ・潜在的メリットの 計算 マイクロサービスソ リューションの設計 ・デジタルシステム の統合 ・テスト改善サイク ルを使用して運用 上の価値の確認 マイクロサービスソ リューションの改善 ・実装サポート ・デジタルシステム の改良 価値拡大の機会 の探索 ・マイクロサービスソ リューションの改良 ・改善の必要性の 記録 C 運用上のニーズの 表現 ・ブレインストーミン グツールとイノベー ション ・内部作業プロセ スの評価 デジタルマイクロ サービスの概念の レビュー ・運用詳細の提供 ・マイクロサービス 価値の評価 マイクロサービスソ リューションの評価 ・デジタル対応ワー クプロセス開発の 評価 ・運用テストの実施 ・ソリューション フィードバック 運用能力の開発 ・デジタルシステム 使用に関するト レーニング ・運用ルーチンの改 善 ソリューションパ フォーマンスのレ ビュー ・定期的なフォロー アップ会議 ・ディバリーと使用 ルーチンの適応化 デジタル化 統括チーム アジャイル開 発チーム 運用・実装 チーム 22

３.デジタル時代のアジャイル開発 従来方式とアジャイル開発 • 従来方式の基本的考え方はイノベーションを事前に計画 し実行および制御する決定論的考え方。 • 不確実性は事前に制御し、その後の変更回避を目指す。 • 対照的に、アジャイル開発は実行の１つの短いフェーズ の結果が次のステージに通知され、反復的に計画・実行 する。 • 不確実性は実行プロセス中に継続的に発見され、対処さ れる。開発プロセス全体で変更に対処する考え方。 23

２つの開発モデルの比較 ステージゲート開発 タイプ アジャイル開発 マクロ計画 ミクロ計画 ハードウェア開発中心 ソフトウェア開発中心 目的 順次的な資源割り当てのための 開発モデル 主に自己管理されたチームを導く ための戦術モデル 焦点 リスクと品質 学習とスピード 論理 決定論的 確率論的 ほぼ線形的 非常に反復的 アイデアから立ち上げ 開発とテスト クロスファンクショナルチーム （R＆D、マーケティング、 セールス、オペレーション） 技術チーム（ソフトウェア開発 者、エンジニア、プロジェクト マネージャー） 一括的 連続的 主要な領域 方向性 主なスコープ オーナー 習慣的関与形態 24

アジャイル開発の適正分野 • 次のような場合にアジャイル開発はより適している。 ① 顧客が変化を好み、プロバイダーとのコラボレーションにも高い 意欲をしめしている。 ② 問題は複雑だが、連続する反復対応のために別個のモジュールへ の分割も可能である。 ③ 暫定的ミスが大きなリスクにはならず、却って貴重な学習機会と なることが期待できる。 • アジャイル開発は直面する多くの問題への万能薬ではないが、 デジタル時代には向いている面がある。 ⇒次頁以降に事例紹介 25

事例研究：ストリートスクーター • 起源：ドイツ・アーヘン工科大学の2人の教授によって 2010年に開始されたプロジェクト • 目的：（ドイツのような高賃金国でも）手頃な価格で販売 できる電気自動車の開発と製造 • 2011年、国際モーターショーで初期製品発表 • ドイツポストDHL（世界最大のロジスティックス企業）が 注目。ストリートスクーター社と開発で契約を締結した。 • 背景：DHLは費用対効果が高く環境に優しいモビリティ （デリバリー用EV車）を欲していたが、ドイツの既存自動 車企業全てから断られていた。 26

事例研究：ストリートスクーター（続） • 2012年、郵便配達用のデリバリー車両「Work」を発表 • 順次他のモデルも • 2014年、DHLはストリートスクーター社を買収。デリバ リー車両を自前で製造する立場に移行した。 • 2018年時点で8000台以上の車両を使用 27

ストリートスクーターはアジャイル開発の典型か？ 次のような方針を実施していた • ラピッドプロトタイピング：ストリートスクーターの研究 チームはプロトタイプ作成とテストの重要性を強調 • 顧客統合：開発プロセスは最初から顧客と統合。そうする ことで顧客の特定ニーズに効率的に対応 • リスク管理：開発プロセスのリスクを非常に早い段階で管 理。このため、開発チームは現実的条件下で出来るだけ早 くプロトタイプのテストに着手 • 障害に優しい文化：経営陣は検証よりも試行錯誤を優先し、 失敗は敗北ではなく学習の重要な機会と見做す文化を確立 28

ストリートスクーターのその後 • ドイツポストDHLは物流EVの自社生産、自社利用に加え、 外販にも乗り出していた。 • 2014年以降、15,000台以上が導入・運行された。 • 2020年から、クロネコヤマトでも運用が開始された。 • しかし、全体的には苦戦した。2021年2月、今後は自社生 産を中止し既存車両の運用にとどめるとの方針を発表した。 • クロネコヤマトも500台導入段階で中止となった。 • 戦略見直しの背景には、物流EV車を巡る世界での競争激化 がある。（自社開発が負担になっていた模様） • 大手自動車メーカーやスタートアップが相次いで物流EV車への参 入を表明していた。 29

アジャイル開発（中間まとめ） 1. ストリートスクーターの例に見られるように、一時的に 成功しても継続が難しい場合もある。 2. アジャイル開発は動的で予測不可能な環境に対応できる のが特徴で、敏捷性の恩恵を受け易い分野に限定した適 応が重要になる。 3. そのためには常に変化する環境への追随の配慮と細心の 注意が求められる。 4. このような環境対応能力の醸成には業務能力に加え、総 合的なエコシステムでの組織変化対応能力がポイントに 成る。 30

４.デジタルサービスのための組織化 デジタルサービスによる組織変化の要因 • デジタル化によって • 企業境界が曖昧になり、確立されていた特定企業間の相互依存 性やネットワークの位置付けが変る。 原因 • サービスの性質を変えるデバイスや技術から情報が分離するか ら • この分離が知識の分散化につながり、社内組織のアクターだけ 結果 でなく、社外のアクターとの協力も生じさせる。 ◆製品とサービスの組織が分離する。 ◆地域の対応が個別化する。 ◆内部化と外部化がそれぞれに進行する。 ◆組織設計の見直しへと発展する。 ⇒従来方式との境界条件の違いを次頁に示す 31

ステージゲート開発とアジャイル開発の境界条件の違い ステージゲート開発 技術的特徴 顧客の特徴 タスクの特徴 組織の特徴 アジャイル開発 低い技術的ダイナミズム 高い技術的ダイナミズム 定義されたソリューション空間 定義されていないソリューショ ン空間 安定し既知の顧客の好み 顧客の好みが変化しているある いは不明 顧客の相互作用の意欲は限定的 顧客の相互作用の意欲は極めて 高い 完全に特定された製品を必要と している顧客 暫定製品（ベータ版）を利用で きる顧客 仕事のモジュール性は低い 仕事のモジュール性は高い 暫定的な障害に対する許容度は 低い 暫定的な障害に対する許容度は 高い 経営管理に対するニーズが強い 経営管理に対するニーズが弱い 32

デジタルサービス組織化検討の枠組み • ダイナミズムが高く未定/不明の要因も増える一方で、エコ システム上でのコラボレーションにより一定の方向性維持 も必要になる。 • この両側面のバランス確保はかなり難しい。 • これに関わる３つの側面について検討する。 ◼中央集権化 ◼統合/一体化 ◼組織/資源の再構成 33

中央集権化 • デジタルサービスの需要に対応するには組織の一元化が望 ましいことが多い。 ✓一元化された方が地域ユニットまで含めたトレーニングなどは容 易になる。 ✓一元化された意思決定と戦略はスケール化にも有利である。 ✓グローバルな効率化の要求への充足にも役立つ。 • そこで、組織構造の集中化の課題が登場する。 • しかし、集権化に向けた包括的組織再構成の実施は抵抗が 大きい。 • 実施は、既存組織の遺産の程度や企業文化、戦略、経営陣 のビジョンや覚悟に大きく依存することになる。 34

統合/一体化 • 組織構造を変更する場合でも、その統合/一体化の程度も問 題になる。 • サービス組織は独自の利益・損失の責任を持つのかどう か？（以前は製品サポートの役割のみであった） • また、サービス機能の分離はサービス組織の新たなステー タス追求のキッカケにもなる（不利にはなりたくない）。 • そこで、経営者主導によるサービス中心の新ビジョンに基 づくイニシアティブが必要になる。 • 更に、新たなビジョン構築においてはパートナーとの連携 も含めた根本的変革が求められる。 35

組織/資源の再構成 • 上述のような変革は焦点企業の業種、規模、実績などで大 きく変わる（例：グローバルビジネスを展開する多国籍企 業(MNC)、など）。 • 多国籍の外部顧客、OEM、システムインテグレーター、各 種サービスプロバイダー、などとも関係する。 • 特にデジタルサービス提供時のエコシステム上の各アク ターの重要性が浮上する。 • そして、デジタルサービスの信頼性確保（例：サイバーセ キュリティ、など）も重要になってくる。 36

デジタルサービス提供に伴う不測の事態と組織化要因 テーマ 不測の事態の要因 組織的活動 •グローバルな運営と組織化 の管理上の遺産 •地元組織の能力と自由度 •変革への企業内の準備 •一元化された意思決定と戦略は、管理構造、慣行、およびルーチン を維持することで、デジタルサービスをスケールアップさせる。 •重要なIT能力をローカルで利用できるようにするには、グローバル な集中化が必要である。 •透明性、ベンチマーク、および包括的なデジタルサービス化イニシ アチブのために、企業全体でデジタルツールとリソースプールを共有 する。 •テクノロジーのスケーラビリティを実現することで、企業全体での デジタルサービスを可能にできる。 統合/一体 化 •製品とサービス組織の分離 /力関係/コラボレーション •フロントエンドとバックエ ンドの役割と責任 •一般的な製品中心あるいは サービス中心の考え方 •グローバルカスタマーサポートを備えたデジタルセンターの作成に よるフロントエンド統合で、すべての顧客対応テクノロジーを統合で きる。 •バックオフィスの機能と役割の統合により、企業全体でデータの構 造化と情報の相互接続が可能になる。 •サービス組織と製品組織間の緊密なコラボレーションとそれらの研 究開発努力の統合により、デジタルサービスが可能になる。 •企業の製品をソフトウェア独立にすることで、デジタルサービスの 範囲を広げる。 組織/資源 の再構成 •市場のダイナミズム、ルー ル、競争 •エコシステムの特徴 •エコシステム内での位置付 け •デジタル化関連の問題と期 待 中央集権化 •デジタル化による高いダイナミズムと複雑なデジタルサービス化の ために内部関係者および外部関係者との緊密なコラボレーションを行 う。 •デジタルサービスの包括的なビジョン設定で、従業員は変化に備え ることができ、主要な利害関係者を参加させることができる。 •デジタルプラットフォームを介して知識と情報を共有することで、 当事者間の信頼と継続的な相互作用がさらにサポートされる。 37

５.これからのデジタルサービス デジタルサービス起因の変化（概要） • デジタルサービス化は「デバイス/技術と情報の分離」のよ うな根本的な変化を伴う。 • これに伴い、不確定要因はミクロからマクロまで多方面に 及ぶ。 • （２節で述べたような）デジタルサービスパラドックスを 克服するような方法自体は想定しうる。 • しかし、システムそのものは、ニッチシステムから基幹シ ステムの更新までと多様でありうる。 • その結果（4節で述べたような）組織化の課題まで考慮する と、なお、未解決の課題は多数存在することになる。 38

アジャイル共創プロセスの視点からの示唆 • プロバイダー、顧客は複雑な本格的ソリューションを一気 に開発するのではなく、段階的に対応することを示唆して いる。 • ソリューションを個別ニーズに分割しマイクロサービス形 態で開発することも出来る。 • そうすることで、デジタル製品/サービスを取り巻く不確実 性に対処し易くなる。 • そして、個別マイクロサービスの迅速で反復的な開発で変 化する顧客要件に対応することもできる。 • 加えて、この過程で起きる学習を通じて真の顧客ニーズ実 現への道筋を期待できるようになる。 39

アジャイル開発の視点からの示唆 • アジャイル開発はより根本的なイノベーションをもたらす はずだが、市場と技術基盤両方からの大きな不確実性の影 響も受ける。 • この方式選択の可否は制御の必要性に大きく依存する。 • 早い段階からの顧客との統合は、これまでにはなかった可 能性を明らかにするのには役立つ。 • また、「速く失敗し、間違いから学ぶ」姿勢にかけること とも大きく関係する。 • しかし、それには、それなりの新たな方法に精通する準備 と覚悟が求められる。 40

デジタルサービス組織化の視点からの示唆 • デジタルサービスの普及によって競争環境は変化すること が多くなった。 • そうすると、多様なアクター間のこれまでにない新たなコ ラボレーションが促進される。 • その場合、促進の程度は焦点企業、顧客、エコシステム内 アクターに共有されるビジョンや目指す目標の堅牢性に依 存する。 • また、促進の仕方は既存ローカル組織の遺産や制御を如何 にローカルユニットから中央管理に移しうるかにも影響さ れる。 • 一本化された意思決定や適正なローカルプレゼンス維持な どは経営陣のイニシアティブに大きく依存する。 41

結論：これからのデジタルサービス 1. 変化のペースが速いデジタルサービス環境では従来の線 形的開発プロセスでは不充分であり、新しいアジャイル 開発実行の機会は増える。 2. 依然として真の顧客価値創出に成功していない企業は特 に新方式に挑戦することが求められる。 3. 種々の困難が伴うが、これまでの（多数の失敗を含む） 種々の経験から幾つかの面で知見や示唆も提示されてい る（本資料はその代表例を取りまとめた）。 4. 現状はこれらを総合的に咀嚼し、自らの課題に沿って適 切な手法を選択し推進することが肝要である。 42

補足：GEは何故失敗したのか？ • GEが産業プラットフォームPredixに賭けたのは、マイクロソフト 出身者から「真価を引き出したいならマイクロソフトのWindows のようなプラットフォーム構築を目指すべきだ」との進言があった からだとも言われる。 • しかし、産業プラットフォームの世界は、WindowsやAppStoreの 世界とは大きく異なることは今や明白である。 • GEは先行者であったが故に、B2B世界での新たな産業アプリ構築 というデジタルサービス世界の未知の特性を充分把握できないま まに先を急ぎ過ぎたことが失敗の原因だったかと思われる。 • 現在、IoTプラットフォームを立ち上げたと主張するベンダーは枚 挙に暇がない（世界で500社を超えるとも言われる）。そして現時 点ではプラットフォーム寡占化は起きていない。 • 結果論ではあるが、B2B世界の産業アプリはプロバイダー、顧客 の共創の世界で、プラットフォームは複雑なデジタルサービス世 界の一要素に過ぎなかったかと思われる。 43

文献 • 2節は主に、David Sjödin et al., An agile co-creation process for digital servitization: A micro-service innovation approach, Journal of Business Research 112 (2020) 478–491を参考に加筆、修正した。 • 3節は主に、Stefanie Paluch et al., Stage-gate and agile development in the digital age: Promises, perils, and boundary conditions, Journal of Business Research 110 (2020) 495–501を参考に加筆、修正した。 • 4節は主に、Alexey Sklyar et al., Organizing for digital servitization: A service ecosystem perspective, Journal of Business Research 104 (2019) 450–460を参考に加 筆、修正した。 44