ソフトウェア・シンポジウム 2023 in 仙台

DX 推進に必要なデジタルプラットフォーム整備の課題
宗平 順己
武庫川女子大学経営学部
t_mune@mukogawa-u.ac.jp
要旨

既存事業の強化／延命のための IT・デジタル活用は
これまでの取り組みの延長なので，容易に取り組めているが，デジタルを活用した新たなビジネスの創造には苦労していることが DX 白書には示されている．

DX 白書 2023 はサブタイトルを「進み始めた「デジタル」，進まない「トランスフォーメーション」としており，日本の DX 推進の現状を示している．「トランスフォーメーション」推進に必要となるのがデジタルプラットフォームであるが，DX への取り組みが「デジタルオプティマイゼーション」にとどまり「デジタルトランスフォーメーション」にまで至らない原因の一つとして，デジタルプラットフォームがうまく整備されていないのではないかと考え，この仮説を検証することとした．
本レポートでは，日本の DX 取組の現状を DX 白書
2023 で確認後，まず DX の教科書とでもいえる存在である Designed for Digital をベースに，デジタルプラットフォームの要件を整理し，その後，日本で紹介されている事例（ＤＸ基盤と呼ばれることもある）をチェックし，デジタル
プラットフォーム整備における課題を明らかにする．

2. デジタルプラットフォームの要件
2.1. Digital Offering
デジタルエンタープライズではデジタル技術を用いて新たな顧客経験を提供するのであるが，MIT Sloan のRoss らは Designed for Digital において，「Digital Offering
によって顧客に新たな経験を提供する」というようにその研究成果をとりまとめた．[2]では，Digital Offering とは何か？ その概念を説明したのが次の図-2 である．

1. DX への取り組みにおける課題
DX 白書 2023 において，DX への取組の成果が出ている企業に対して，取組領域ごとの成果状況を尋ねた結果を示したのが図-1 である[1]．IT の延長線上である「「業務の効率化による生産性の向上」において，成果が出ている割合が約 80%であり米国と差がなくなっているのに対し，デジタルトランスフォーメーションに相当する「新規製品・サービスの創出」「顧客起点の価値創出によるビジネスモデルの根本的な変革」については 20％台で，米国の約 70％とは大きな差がある[1]．

※▲と〇，矢印は今回追記
図-2 Digital Offering
左側の円は顧客の期待（潜在ニーズと理解してよい），
右側の円は企業側の活動で，デジタル技術を活用した
新しいソリューションを示しており，両者が交わったところ
が Digital Offering であると定義している．
企業（IT 企業のみでなく DX に取り組む企業全般を指す）が新たな顧客経験を生み出そうとする場合，企業はデジタルで何ができるか経験が十分ではなく，顧客側は実際に手にするまで自分たちは何が欲しいのかわかっていないというのが現実の姿である．
企業は一生懸命マーケットリサーチをして，新たな製図-1 DX の取組内容と成果

1

SEA

ソフトウェア・シンポジウム 2023 in 仙台

品やサービスを提供するのであるが，ほとんどの場合，最初は多くのユーザの評価を得ることができない．ユーザも何が欲しいのか良くわかっていないので，手をかえ品をかえこの潜在ニーズを明らかにしていく必要がある．こうして改良を繰り返すことによって，やがては顧客の持つ潜在ニーズと合致し，ユーザがお金を払っても良いと考えるものに仕上がる．このような状態になったものを「Digital Offering」と呼んでいるわけである．なお，対応する日本語の概念は無いので，英語の表記のままにしておくこととする．
この改良プロセスのことを Ross らは Test–and–Learn のプロセスと名付けている[2]．一般には試行錯誤とか Try& Error と繰り返す呼ぶことが多いが，ユーザの評価が得られなかったのは失敗では無く，顧客の期待やニーズについての学びがあったという成果があったととらえ，次のTry に活かそうという意図が込められている．特に日本では，失敗があるとプロジェクトが中止になる企業が多いことから Test–and–Learn と呼ぶのは良いアイデアである．

分たちは何が欲しいのか不明である．
そのため test –and –learn のプロセスを繰り返すことによって顧客インサイトを得て企業でシェアできるようになる．
いろいろなアイデアの可能性を継続的に試すことが必要
で，このことを企業カルチャとして浸透させなければならない．
2.2.2. Operational Backbone
現行ビジネスを支える業務システムを指す．デジタル技術の活用について次の整理をしている．(日本とは言葉の定義が異なっていることに留意頂きたい)
Digitize : SMACIT（social, mobile, analytics, cloud, IoT）
でビジネスプロセスを強化すること．短期的な現行の競争優位の担保に必要であるが，将来の競争優位を作ることはできない．
Digital : これに対し SMACIT を顧客への価値提案のために適用することが Digital であり，デジタルトランスフォ
ーメーションの本質は Digital である．
しかしながら，Digital はすぐに主力になるわけではなく，
現行ビジネスを継続せねばならず，Digitization によってOperational Backbone の効率化(Operational Excellence)を追求する．

2.2. 5 Building Block
Ross らは新たな顧客価値を生み出す DX を実現するためのアプローチとして Designed for Digital において図-2 に示す 5 Building Blocks というフレームワークを提示しており，もし企業がしっかりとした Operational Backboneを構築していれば，他の４つのブロックはその上に築くことができるとしている．以降各ブロックについて説明する．
[2]

2.2.3. Digital Platform
Operational Backbone が信頼性と透明性で顧客満足に貢献するのに対し，Digital Platform は Digital Offeringの迅速かつ継続的な改良により顧客を喜ばせる．
このプラットフォームは，ビジネス，データ，インフラの３つのタイプの再利用型コンポーネントから構成され，Digital
Offering はこれらの組み合わせによって実現される．このため，各コンポーネントには API が実装される．

2.2.1. Shared Customer Insights
Digital Offering について企業はデジタルで何ができるか経験が十分ではなく，顧客側は実際に手にするまで自図-35 Building Blocks

2

SEAソフトウェア・シンポジウム 2023 in 仙台

当初，Digital Offering のためにモノシリックなシステムを構築してしまうことが多いが，継続的な改善，再利用性，両方の要求を満足するためには，コンポーネントベース（＝マイクロサービス）のアプリケーション開発を行う必要に気づく．

るためのものとして紹介する．
表-１ デジタルプラットフォームの要件[2]2.2.4. 2.2.4 External Developer Platform
Digital Platform の拡張機能であり，デジタルコンポー
ネントを活用するパートナーとのエコシステムをサポートする．顧客への新たな価値提案は企業が単独でなしうるものではなく，様々なパートナーと共同することで初めて提供できるものとなってきている．Panasonic や三菱電機
はデジタルプラットフォームをパートナーに公開している．
2.2.5. 2.2.5 Accountability Framework
階層型組織は標準化された業務プロセスの効率化には有効であるが，Digital Offering の開発プロセスは Test
& Learn であり，独立し empowerment されたイノベーショ
ンのチームにより推進される．
ただ各チームが独自の思惑で動くとカオス状態になることから component owner への Accountability Frameworkが必要となる．
Digital platform の各コンポーネントが Test & Learn によって絶えず更新されていきながら，図-6 に示す，API を通じて他のコンポーネントと協調して動くことを担保する（Autonomy and Alignment）８つの原則からなるマネジメ
ントのしくみが必要となる．

Operational Backbone

Digital Platform

目標とプロセスの効率化，予測

収益拡大につながる新しする成可能性，信頼性の向上にいデジタルサービスの迅速果よる収益性の向上

な革新

技術要安定した，拡張性のある，API に対応したビジネス，件

安全なオペレーションシス

データ，インフラストラクチ

テム，反復的なプロセスのャのコンポーネントのリポジ

自動化

トリ

必要な

正確でアクセス可能な取ビッグデータ（センサ，ソー

データ

引データおよびマスタデ

シャルメディアなど）の分析

ータに適した柔軟なリポジトリ

プロセ

トランザクション処理アプリ

デジタルオファリングの設

ス要件

ケーションの計画的・計画

計，開発，構成，商品化の的な設計と実装

反復

人的要

プロセスオーナ，データア

プラットフォームアーキテク件

ーキテクト，大規模プロジ

ト：コンポーネントの機能性

ェクトにおけるプロジェクト

を仮説，テスト，管理できるリーダ

コンポーネントオーナ

2.4. デジタルプラットフォームの詳細仕様
Digital Offering を提供するために必要となるのが，デジタルプラットフォームであるが，その仕様について文献
2 に記載されている内容を抜粋・要約し，見出しを付けたものを以下に記載する．
① 再利用可能なコンポーネントから構成
・デジタルプラットフォームは，ビジネス，データ，インフラストラクチャのコンポーネントのリポジトリであり，デジタ
ルサービスを迅速に構成するために使用する．
・再利用可能なデジタルコンポーネントデジタルプラット
フォームを構築すると，企業は将来のデジタルサービスに役立つ可能性のあるコンポーネントのポートフォリ
オを蓄積していく．
・コンポーネントは，特定のタスクを実行するコンポーネン
トである．例えば，顧客の口座残高を取得する，ある場
所への道順を指定する，センサーの測定値から機器の故障確率を計算する，ショッピングカートに顧客の注文を蓄積する，ユーザの身元を確認する，ダッシュボードでパフォーマンス結果を表示する，などのタスクを実行するコンポーネントがある．
・これらのコンポーネントをデジタルプラットフォーム上に配置することで，新しいソフトウェアプロダクトを開発する個人が利用できるようになる．開発者は，ソフトウェア
プロダクトに必要なすべての機能に対応するコードを

図-4 デジタルコンポーネントのマネジメント原則
2.3. デジタルプラットフォームの設計要件
表 -1 に ， デ ジ タ ル プ ラ ッ ト フ ォ ー ム と Operational
Backbone の要件を対比したものである（出典 2 より著者が翻訳）．デジタルプラットフォームの設計要件を理解す

3

SEAソフトウェア・シンポジウム 2023 in 仙台

記述する代わりに，既存のコンポーネントを「呼び出す」
ことでソフトウェアプロダクトを構成することができる．
② 各コンポーネントは API 経由で接続
・コンポーネントを再利用可能にする（つまり，開発者が新しいコードを書く代わりにコンポーネントを呼び出せるようにする）ために，開発者はコンポーネントを API対応にする．
・よく設計されたデジタルプラットフォームでは，各コンポーネントが API を提供する（つまり，API が有効である）．
そのため，API を利用することで，独立したコンポーネント間の事前定義された「プラグアンドプレイ」接続が可能になる．
③ ３つのタイプのコンポーネント
デジタルプラットフォームは，クラウド技術をベースに構築された以下の 3 つのリポジトリで構成される．
データコンポーネント
インフラストラクチャコンポーネント
ビジネスコンポーネント・データコンポーネント
このリポジトリはデジタルプラットフォームの中心となる．
企業は，デジタルサービスを構築する際，業務用バッ
クボーンの業務データを活用するだけでなく，センサ
ーやスマートデバイス，その他のウェブサービスからデータを購入・収集することになる．そして，再利用可能
な API 対応のソフトウェアコンポーネントを構築または購入する．それぞれのコンポーネントには，データのい
くつかの要素を保存，操作，分析，表示するコードが含まれている．
・インフラストラクチャコンポーネント
このリポジトリは，クラウドプラットフォームに組み込まれたサービスを，企業の提供するサービスや顧客の特定のニーズに適合させるための技術的なサービスコンポ
ーネントを提供する．このコンポーネントには，ユーザ認証とアクセス制御，スマートデバイスの接続性，デバイス間の通信のオーケストレーション，使用状況の追跡とデータプライバシーを保証するサービスなどが含まれる．これらのコンポーネントは，ビジネスコンポーネントとクラウドサービスの橋渡し役として機能し，ビジネ
スコンポーネントが特定のクラウドプロバイダーのプラットフォームサービスを直接利用することを避け，特定のプロバイダーにロックインされないようにすることを目的としている．
・ビジネスコンポーネント
このリポジトリは，複数のデジタルサービスに必要な機能を提供する．これらのサービスには，ダッシュボード，特定のイベントを顧客や従業員に通知するルール，新規顧客との関係を構築するオンボーディングプロセス，
顧客に標準的なサポートサービスを提供するボットなどが含まれる可能性がある．企業によっては，関連性のない複数のデジタルビジネスを展開しているため，共通のビジネスコンポーネントのリポジトリが複数存在する場合もある．
④ コンポーネントの独立性
・デジタルプラットフォームは，1 コンポーネントずつ段階的に開発することができ，その構成要素は使い物にならなくなったら捨てることができる．
⑤ スケーラビリティ
・デジタルプラットフォームは継続的に進化することが可能であり，またそうでなければならない．
⑥ コンポーネントガバナンス
・デジタルプラットフォームは，ひとつのデジタル製品/サービスに必要なコンポーネントからスタートすることが考えられる．PoC が成功すれば，ビジネスチャンスが見つかり，企業は必要なコンポーネントの構築を開始することができる．しかし，このようなアプローチでは，初期のサービス提供の開始が遅れる．そのため，特定のサービスの機能を一回限りのモノリシックな方法でコーディングしかねない．しかし，このようなやり方は，初期のソフトウェアプロダクトでは有効かもしれないが，顧客の要求に対応するための機会が増えてくると，手戻りが発生する．
・デジタルプラットフォーム構築の段階的アプローチにおける課題は，正式な管理が必要となる十分な数のコンポーネントが揃うまで，プラットフォームが重要でない（あるいは，問題にする価値がない）ように思われることである．企業全体がデジタルプラットフォームの必要性を認識する頃には，誰も責任を負いたくないモノリシッ
クなデジタルソフトウェアプロダクトという，かなり厄介なレガシーを構築してしまっている可能性がある．
・このため提案されたソフトウェアプロダクトをレビューして再利用可能なコンポーネントを特定するためのアーキ
テクトの役割と関連プロセスを確立する．例えば，BNY
メロンでは，CIO のレポート担当者が，提案された新規
または刷新された金融サービスのレビューを行い，どの機能が他のサービスで再利用できる可能性が最も高いかを判断する役割を担っている．

3. 日本のデジタルプラットフォームの検証
以上，Designed for Digital に記載されたデジタルプラ
ットフォームの定義と対比する形で，日本で紹介されてい4

SEAソフトウェア・シンポジウム 2023 in 仙台

るデジタルプラットフォームについて検証を進める．

れている．
スミセイデータプラットフォームはデジタルプラットフォームに該当するもので，顧客な大規模なライフログ健康
データを蓄積し，Amazon SageMaker などによる分析を通じて，Well-being as a Service を提供している．[5]3.1. 検証対象としたデジタルプラットフォーム
日経クロステック：失敗しない DX 基盤の作り方より
・東京日動火災海上
・住友生命
・オイシックス・三菱伊勢丹・ZOZO

3.2.3. オイシックス
オイシックスは，モノリシックになってしまったアプリを柔軟に変更できるようにするために，コンテナ環境を有するマイクロサービスベースの開発基盤を Azure 上に構築した．
当初は，既存システムから機能単位でデータをとアプ
リを切り出して個別サービスとしてサービス化しようとしたが，アプリとデータベースの関係が複雑なものがあり，既存の OracleDB を利用する必要のある機能は一つのサービスに集約し，独立できるものは個別サービス，切り出せる DB は個別 DB を構築している．[6]NDL-OPAC の検索結果より・建物デジタルプラットフォーム
202１年度発表より
・みずほ FG・Panasonic
DX 実践手引書より
・スサノオ・フレームワーク

3.2.4. 三越伊勢丹
三越伊勢丹じゃ短期間のサービス開発・リリースを実現するために DevOps 環境を Azure,AWS が提供する機
能を組み合わせて構築している．
ここで構築されたデジタル系のアプリはビジネスプラッ
トフォームという API 群を経由して基幹システムと連携している．基幹システムとの連携が必要になる都度 API を作成してこのプラットフォームに登録している．[7]3.2. 各デジタルプラットフォームの概要
3.2.1. 東京日動火災海上
東京日動火災海上では，迅速なサービス開発と継続的な改善を続けるために，マイクロサービスとサーバレス
を組み合わせた CI/CD に対応した DevOps 基盤を AWS上に構築している．基幹システムとは API を介して保険契約に関わる情報を連携している．[3]DevOps 基盤と対をなすようにデータ分析基盤とデー
タ活用基盤が整備されている．顧客のふるまいを解析するなど，新たなサービスのヒントをつかんだり，リリースした
新たなサービスの利用状況を分析したりするために利用している．
基幹システムからのデータ取り込みにあたってはオペレーショナルデータストアというシステムによって，プロジェ
クト毎に異なるデータ項目などを統一できるようにしてからデータストアに蓄積するようになっている．[4]3.2.5. ZOZOZOZO がアプリケーションの開発スピードを向上させる
ため，モノリシックな既存システムをマイクロサービスに移行するためにマイクロサービス環境を構築した．スマホア
プリは API ゲートウエイを経由して，機能単位に構築されたマイクロサービスを呼び出すようになっている．
従来システムから機能単位にマイクロサービスに段階的に移行するというアプローチを採用している．[8]3.2.6. 建物デジタルプラットフォーム

3.2.2. 住友生命

清水建設が建物運用にあたって，多種多様な設備機器類の制御アプリケーションの相互連携を可能にするために構築したデジタルプラットフォームが図-5 に示す建物 OS である．[9]東京海上日動と同様に顧客分析のためのデータ分析
基盤を住友生命も構築している．
主にレポーティングのための新情報分析システムと AI
開発のためのスミセイデータプラットフォームから構成さ

5

SEA

ソフトウェア・シンポジウム 2023 in 仙台

たことから，公開する API をスムースに構築することができた．また，API の仕様も銀行の視点ではなく，Fintech 企
業が新しいサービスを構築できるようにするという視点で設計されている．
3.2.8. Panasonic
図-8 は IoT 家電を支える Panasonic Cloud Service
Platform のアーキテクチャである．[12]図-5 建物 OS
この利用イメージを図-6 に示す．3 密場所での換気強化のユースケースで，監視カメラ設備②の画像で，人の混雑を検知③したらその場所の換気量①を増やし，その制御結果をメッセージソフト⑤でスマホ④に知らせる．

図-8 Panasonic のアーキテクチャ
IoT 家電の前段となるスマート家電サービスには 2012
年から取り組んでおり，当初はオンプレミス環境で自前主
義でしくみを構築していたが，継続的な進化を続けるた
めに，まずクラウドファーストとし，家電サービスと共通機能を分離し，個々に進化できるアーキテクチャに変更した．従来型のモノシリックなシステムでは，高速な進化に対応できないことから設計したものであり，各サービスが独立して運用が行えることを狙いとしている．そして，マイクロサービス化し，次々とサービスを追加できるようにしている．
そして，図-9 に示す Panasonic Digital Platform の構築を進めている．[13]図-6 建物 OS の利用イメージ
また，API 連携としているため，③の入替，⑤の追加が容易にできることを示している．[10]3.2.7. みずほ FG
図-7 はみずほ FG が構築した銀行 API である．[11]図-7 みずほ FG API
基幹システムの再構築の際に，業務ロジックを処理する共通業務 AP 層と，顧客との接点となるプレゼンテーシ
ョン層に分けるというアーキテクチャを採用し，業務ロジッ
クは再利⽤可能な粒度で Web サービスとして実装してい図-9 Panasonic Digital Platform

6

SEA

ソフトウェア・シンポジウム 2023 in 仙台

3.2.9. スサノオ・フレームワーク

フェイスとしている．顧客や市場の変化に耐えうるため，競争領域の独自アプリケーション(A)を，顧客や取引企業と接点を持つアプリケーションとしている．社内の現行業務を維持するとともに，競争領域の独自アプリケーショ
ン(A)と連携する形で，現行システム(B)をおいている．現
行システム(B)を再構築する際には，移行を助けるため，媒介層(C)が他の IT システムとの連携を仲介する．また，媒介層(C)は，現行システム(B)が他の IT システムと連携する役割も担う．そうした，社内の IT システムや社外から取得するデータを，集約し，蓄積して，分析するため，
データ活用基盤(D)・データ分析基盤(E)をデータ活用のための基盤としている．以上の組織内のサービスについて，システムリソースの柔軟な変更などを可能とするため，システム基盤(G)を稼働環境としている．
顧客や取引企業との設定を持つ競争領域の独自アプ
リケーション(A)が提供する機能を強化するため，特化した個別の機能は，外部サービス(H)と連携する．また，非競争領域となる業務は，外部が提供する環境を利用する
ため，外部共通基盤(I)と連携する．企業内にあるデータと，組み合わせることで，整理や分析に活用するため，社外データソース(J)を取り込むことも可能としている．」(以上引用おわり)
また，競争領域の独自アプリケーション(A)の構築に関する技術として，マイクロサービスアーキテクチャの採用を提案しており，開発体制としては，１つのチームが，１つのサービスを開発し，その運用を行うこととしている．

IPA「DX 実践手引書 IT システム構築編」には，DX を実現するための IT システムの共通的な要素には，IT シ
ステムとその開発運用の体制が変化に対して俊敏かつ柔軟に対応できる「スピード・アジリティ」，社内外の円滑かつ効率的なシステム間連携を目指す「社会最適」，データ活用を中心に据えて社内外へ新たな価値を生み出してゆく「データ活用」の三つが挙げられるとして，この３つの要件を備えるようなシステムのあり方として図-10 が示されている．[14]図‐10 あるべき IT システムの要件
そしてこのシステム要件を実現する技術要素群が図‐11 に示すもので，これを「スサノオ・フレームワーク」と名付けている．以下，その説明を引用する．
「あるべき IT システムは，各企業の競争領域として，変化に強い独自アプリケーションやそこに生かすデータの活用を行う基盤など自社の独自性を強化するための「組織内サービス」と，各企業の社内リソースを競争領域に注力するために，外のサービスや共通の基盤など，社外のリソースを活用する「外部サービス」を組み合わせた構成となっている．

3.3. 日本のデジタルプラットフォーム例の検証
Ross らのデジタルプラットフォームへの要求事項に対し，これまで紹介してきた日本のデジタルプラットフォームの例がどのように対応しているかをまとめたものを表-2 に示す．以下，個々の評価内容について示す．
・東京日動火災海上
継続的な発展を考慮したマイクロサービスベースの開発基盤であり，ほぼデジタルプラットフォームの要件を満たしているのではあるが，マイクロサービスの種類を意識しているかどうかは不確かであり，また重複開発やモノリ
シックを防ぐようなガバナンスを有しているかどうかは定か
ではない．
・住友生命
アプリケーションに関し，レポーティングは Tableau，AI
開発は SageMaker を使っており，マイクロサービスを使った開発環境については，対外発表されていない．
・オイシックス
全体を吟味してマイクロサービスを構築していることか

図‐11 スサノオ・フレームワーク
あるべき IT システムの個々の要素は，社内外の様々なサブシステムと連携するため，API(F)を基本のインター

7

SEAソフトウェア・シンポジウム 2023 in 仙台

表-2 日本のデジタルプラットフォーム例の評価結果
MIT Digital Platformの要求事項 再利用可能な 各コンポーネン ビジネスコン
コンポーネント トはAPI経由で ポーネント
から構成
接続
〇
〇
△
東京火災海上インフラコン
ポーネント

データコンポー コンポーネント スケーラビリ
ネント
の独立性
ティ

コンポーネント
ガバナンス

△

△

〇

〇

？

住友生命

？

？

？

？

〇

？

？

？

オイシックス

〇

〇

〇

△

〇

〇

？

△

三菱伊勢丹

〇

？

？

？

？

？

?

?

ZOZO

〇

〇

〇

〇

△

〇

？

？

建物OS

？

〇

？

？

△

〇

?

?

みずほFG

？

〇

△

〇

△

〇

?

〇

Panasonic

〇

〇

〇

〇

〇

〇

〇

？

スサノオ・フレームワーク

〇

〇

？

？

〇

〇

？

〇

ら，コンポーネントガバナンスがある程度効いていることは推測されるが，インフラコンポーネントに相当するもの
は公表資料にはなく，またスケーラビリティについての仕組みも定かではない．
・三菱伊勢丹コンテナ基盤をベースとした DevOps 基盤ではあるが，マイクロサービスの開発環境については公表されておらず，ほとんどの項目について判断ができない．
・ZOZO
マイクロサービスをその機能を意識して開発しており，
デジタルプラットフォームの要件を良く満たしてはいるが，徐々に移行するにあたってのガバナンスや既存マイクロ
サービスのレベルアップなどの方策をとっているかどうかは定かではない．
・建物デジタルプラットフォーム
デジタルプラットフォームと命名してはいるが，実態は各機器の持つソフトウェア間のデータ連携基盤である．
各機器のソフトウェアを開発する機能は有していない．
・みずほ FG
API ガバナンスが効いた構造になっているが，API の再利用性やスケーラビリティについての機能は公開資料には見当たらない．またインフラ以外のコンポーネントの種類としてどのようなものがあるのかも不明である．
・Panasonicコンポーネントガバナンスについては不明ではあるが，デジタルプラットフォームの要件を満たしている．
・スサノオ・フレームワーク
マイクロサービスの利用とその開発運用体制については示しているが，マイクロサービスの再利用やスケーラビ
リティについては言及されていない．

できる．
⚫ マイクロサービスを使うことは前提としているが，どのようなタイプのものがあるのかがまだわかっていない．
⚫ データ連携を ESB の様なイメージで捉えている．
⚫ データコンポーネントについてはクラウドサービスを使うなどしてデータ分析基盤として構築している．
⚫ API はマイクロサービス間の連携というよりも既存システムやデータ分析基盤との連携のツールとして認識されており，このためデジタルプラットフォ
ーム＝データ連携基盤という理解をしているものも見受けられる．
スケーラビリティやコンポーネントガバナンスについて
はほんど考慮されている様子が見られない．

Web メディアの記事などからの情報であるため，入手委できている情報は限定的なものであることは考慮にいれる必要があるが，全体的な特徴として以下の点が指摘

図-18 AI の導入目的
AI の活用においても日本ではこれまでの開発手法を適用しやすい，効率化や品質向上への適用が中心にな

4. DX 推進の技術面での課題
4.1. 日本の DX 推進の現状との関連「DX への取り組みにおける課題」において新たな顧客価値創出への取り組みに大きな遅れがみられることをしめしたが，図-18 に示すように，同様の結果が AI への取り組みにおいてもみられている．[1]8SEAソフトウェア・シンポジウム 2023 in 仙台っているのに対し，米国では顧客価値向上のために AIを活用する方へとシフトしている．
なぜ，このような違いが生まれるのか，その理由の一つとして，新たな開発手法の採用が遅れていることにあることが，図-19 から分かる．[1]効率性向上のためのデジタル技術の活用は従来型のIT 導入と同様に，ウォーターフォール型でも開発を進めやすい．
これに対し，顧客価値向上のための開発は，Test-andLearn で進めなければならないが，図-19 に示すようにそのために必要な開発手法の導入が米国と比して大きく遅れている．

発といった Test-and-Learn において必要な開発手法の導入も進んでいないことから，国内において十分な知見が溜まっていないのではないかと推測できる．
スサノオ・フレームワークにも上記の点が欠けていることも，このことから納得できる．
しかしながら，今後利活用が進むと知見が溜まるから大丈夫かというとそういうことではない．
Ross らは「⑥コンポーネントガバナンス」に関して以下の様な記述をしている．
「企業全体がデジタルプラットフォームの必要性を認識する頃には，誰も責任を負いたくないモノリシックなデジタル製品という，かなり厄介なレガシーを構築してしまっている可能性がある．
実際，デジタルプラットフォームが十分に発達している
企業は，平均して，デジタル製品の 61%を再利用可能なコンポーネントから構築しているのに対し，デジタルプラ
ットフォームがあまり発達していない企業では 32%にとどまっている．」[2]
日本がこのまま手探りでデジタルプラットフォーム上での開発を続けると，同じことを繰り返す危険が大いにあると考えている．
米国では，SOA の導入が進んでいたことから，「再利用可能なコンポーネント」の重要性やそのためのガバナ
ンス（SOA ガバナンス）の理解があったと思われるが，それでも上述の様にまずい対応をする企業も多いということである．
SOA の導入があまり進まなかった日本ではさらに大きな混乱が生じるものと危惧される．
米国など先行して取り組んでいる企業の知見を調査し，日本企業にガイドとして紹介することが早急に必要になると考えられる．

図-19 新たなシステム開発手法・技術の活用状況
4.2. 日本の DX 推進の技術的課題
本論の初期仮説は，「DX への取り組みが「デジタルオ
プティマイゼーション」にとどまり「デジタルトランスフォーメーション」にまで至らない原因の一つとして，デジタルプ
ラットフォームがうまく整備されていないのではないか」ということであった．
この観点から公開情報から様々なデジタルプラットフォームの事例を検証したが，以下の点が明らかになった．
⚫ マイクロサービスを使うことは前提としているが，どのようなタイプのものがあるのかがまだわかっていない．
⚫ スケーラビリティやコンポーネントガバナンスについてはほんど考慮されている様子が見られない．

参考文献[1] 独立行政法人情報処理推進機構, 「DX 白書 2023」,
https://www.ipa.go.jp/files/000108041.pdf,
2023/2/9[2] Jeanne W. Ross, Cynthia M. Beath, Martin Mocker,“Designed for Digital: How to Architect Your
Business for Sustained Success”, The MIT Press
September 2019.
[3] 森山徹, 「DX の「エンジン」になる IT 基盤，先行事
例に見る 2 つの不可欠な要素とは」,
https://xtech.nikkei.com/atcl/nxt/column/18/016
88/070200008/, 2021/7/12[4] 森山徹, 「東京海上日動が新たな「データ活用基盤」

なぜマイクロサービスの利用にあたって，重要な観点である上記の内容が欠けているのか疑問であったが，図19 に示すように，日本ではそもそもマイクロサービスの導入が進んでおらず，加えて，デザイン思考，アジャイル開9

SEAソフトウェア・シンポジウム 2023 in 仙台

で DX 加 速 ， AI ア プ リ を 次 々 生 み 出 す 」 ,https://xtech.nikkei.com/atcl/nxt/column/18/016
88/061400001/, 2021/6/16[5] 森山徹, 「DWH とデータレイクを運用する住友生命，
なぜ 2 つのデータ分析基盤が必要なのか」,
https://xtech.nikkei.com/atcl/nxt/column/18/016
88/070200006/, 2021/7/6[6] 森山徹, 「マイクロサービスに挑むオイシックス，既存システムの機能とデータをどう切り出すか」,
https://xtech.nikkei.com/atcl/nxt/column/18/016
88/070200004/, 2021/7/8[7] 森山徹, 「三越伊勢丹は DX で「4 倍速開発」，下支
え す る 2 つ の IT 基 盤 と は 」 ,https://xtech.nikkei.com/atcl/nxt/column/18/016
88/061600003/, 2021/6/18[8] 森山徹, 「ZOZO が API ゲートウエイを「自作」，クラウ ド の サ ー ビ ス は 使 わ な い ワ ケ 」 ,https://xtech.nikkei.com/atcl/nxt/column/18/016
88/061500002/, 2021/6/17[9] 菅裕之, 「デジタルプラットフォームによる高度運用の促進とデジタルツイン」, 空気調和・衛生工学，大95 巻第 11 号，2021/11, pp31-36[10] 山崎元明, 廣瀬啓一, 白石 理人, 「建物デジタル
プラットフォーム「DX-Core(建物 OS)」の開発」, 清
水建設研究報告 第 99 号, 2021/12, pp23-27[11] https://www.ibm.com/blogs/solutions/jp-ja/camizuho/[12] 大穂雅博,箱田航太郎,「パナソニックの IoT 家電を支えるクラウド基盤の進化」，AWS SUMMIT Tokyo2019[13] 浅井将則他「パナソニックの IoT サービスを支えるクラウドプラットフォームの開発」,Panasonic Technical
Journal Vol.64 No.1,May 2018, pp9-14[14] 独立行政法人情報処理推進機構 社会基盤センタ
ー , 「 DX 実 践 手 引 書 IT シ ス テ ム 構 築 編 」 ,https://www.ipa.go.jp/files/000094497.pdf,
2023/3/2

10

SEA