ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

DX 推進に向けたエンタープライズアーキテクチャの設計プロセスの検討
宗平 順己
武庫川女子大学経営学部
t_mune@mukogawa-u.ac.jp
要旨

Designed for Digital に記載内容も参照して整理する．第4 章ではデジタルエンタープライズへ変革する（＝DX）にあたってのシステム面でのアプローチ内容として 5
Building Block のフレームワークを紹介する．第 5 章ではデジタルエンタープライズを支えるデジタルプラットフォームについて，既に有効な取り組み事例が出てきていることを紹介し，第 6 章で DX 推進のアーキテクチャ面での課題として「既存システムのモダナイズの具体的なガイドの作成」があることを指摘する．第 7 章以降はこの課題への回答として，MIT Sloan の Architecture Maturity Stagesをベースとしたデジタル化への対応方法の検討結果を紹介する．

DX レポート 2 では，「デジタルトランスフォーメーションはデジタルエンタープライズになるまでのプロセスのことである」との定義がなされ，デジタルビジネス向けのシステムの開発と既存業務システムのデジタル化の両方の取組を同時に行う必要があるとされている．
デジタルビジネスを支えるデジタルプラットフォームのアーキテクチャについては IT ベンダー等から様々な提案がなされるだけでなく，AWS での構築事例も報告されている．
既存業務システムのアーキテクチャのベストプラクティ
スについても MIT Sloan からアーキテクチャ成熟度モデルが提案されている．
しかしながら，デジタルビジネスを支えるシステムは単独で構築されるよりも既存業務システムと関連することが多く，両者を連携させると同時に，既存業務システムのモダナイズも同時に進める必要がある．
しかしながら，その具体的な方法についてはＤＸレポート２には明確な提示はない．
本レポートでは，DX の教科書とでもいえる存在である
Designed for Digital をベースに，ＤＸに取り組む企業の指針となるアーキテクチャの設計プロセス検討結果を報告する．

2. DX レポート２
2020 年の年末，12 月 28 日に「デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DX レポート 2（中間取りまとめ）』」が経済産業省より公表された[1]．
このレポートにおいて，「デジタルトランスフォーメーションとはデジタルエンタープライズになるためのプロセスのことである」と定義されている．このレポートから要点を抜粋して，以下に記載する．[1]2.1. DX の誤った理解と取り組みの大幅な遅れ
独立行政法人情報処理推進機構（IPA）が 2020 年
10 月時点での企業約 500 社における DX 推進への取組状況を分析した結果，実に全体の９割以上の企業が DX にまったく取り組めていない（DX 未着手企業）レベルか，散発的な実施に留まっている（DX 途上企業）状況であることが明らかになった．（中略）我が国企業全体における DX への取組は全く不十分なレベルにあると認識せざるを得ない．
このことは，先般の DX レポートによるメッセージは正しく伝わっておらず，「DX＝レガシーシステム刷新」，あるいは，現時点で競争優位性が確保できていればこれ以上の DX は不要である，等の本質ではない解釈が是となっていたとも言える．

1. はじめに2020 年末に中間発表された DX レポート 2 はデジタ
ルトランスフォーメーション（以降ＤＸ）に取り組むためのより具体的な方法が提示され，デジタルビジネス向けのシステムの開発と既存業務システムのデジタル化の両方の取組を同時に行う必要があるとされている．
デジタルビジネス向けのシステムについては既に多くの意欲的な事例が多く出てきているものの，既存システムのデジタル化（モダナイズ）の方法については具体的な案が示されていない．
そこで，本論ではまず第 2 章においてＤＸレポート２について概観し，第 3 章ではこれから企業が目指すべきデジタルエンタープライズの特性について，MIT Sloan の2.2. 経営者の責任
DX の本質とは，単にレガシーなシステムを刷新する，

19

SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

3. デジタルエンタープライズの特性高度化するといったことにとどまるのではなく，事業環境の変化に迅速に適応する能力を身につけること，そしてその中で企業文化（固定観念）を変革（レガシー企業文化からの脱却）することにあると考えられる．
当然ながらこうした変革は誰かに任せて達成できるものではなく，経営トップが自ら変革を主導することが必要である．

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

2.3. もう以前には戻らない
コロナ禍によって，テレワーク等をはじめとしたデジタ
ル技術による社会活動の変化に対応し，新たな価値を次々と産み出している．これは，単なるコロナ環境下での一過性の現象ではなく，人々の固定観念が大きく変化したことを表しているのである．人々は新たな価値の重要性に気付き，コロナ禍において新しいサービスを大いに利用し，順応している．（中略）人々の固定観念が変化した今こそ企業文化を変革する絶好の機会である．ビジネ
スにおける価値創出の中心は急速にデジタル空間へ移行しており，今すぐ企業文化を刷新しビジネスを変革できない企業は，デジタル競争の敗者としての道を歩むことになるであろう．
2.4. 「両利きの経営」が必要～デジタル一辺倒ではない※▲と〇，矢印は今回追記
図-1 Digital Offering
左側の円は顧客の期待（潜在ニーズと理解してよい），右側の円は企業側の活動で，デジタル技術を活用した新しいソリューションを示しており，両者が交わったところが Digital Offering であると定義している．
企業が新たな顧客経験を生み出そうとする場合，企業はデジタルで何ができるか経験が十分ではなく，顧客側は実際に手にするまで自分たちは何が欲しいのかわかっていないというのが現実の姿である．
企業は一生懸命マーケットリサーチをして，新たな製品やサービスを提供するのであるが，ほとんどの場合，最初は多くのユーザの評価を得ることができない．ユーザも何が欲しいのか良くわかっていないので，手をかえ品をかえこの潜在ニーズを明らかにしていく必要がある．こうして改良を繰り返すことによって，やがては顧客の持つ潜在ニーズと合致し，ユーザがお金を払っても良いと考えるものに仕上がる．このような状態になったものを「Digital Offering」と呼んでいるわけである．なお，対応する日本語の概念は無いので，英語の表記のままにしておくこととする．
この改良プロセスのことを MIT は Test–and–Learn のプロセスと名付けている．一般には試行錯誤とか Try &Error と繰り返す呼ぶことが多いが，ユーザの評価が得ら「顧客や社会の問題の発見と解決による新たな価値の創出」と，「組織内の業務生産性向上や働き方の変革」という二つのアプローチを同時並行に進めることが重要である．いわゆる「両利きの経営」と言われるように，既存事業の効率化と新事業の創出は両輪で検討すべきである．
既存事業の見直しにより産まれた投資余力を新事業の創出にあてることで，企業の競争力と経営体力を高めることが出来る．
2.5. DX への取り組みの３つの段階
企業が DX の具体的なアクションを組織の成熟度ごとに設計できるように，DX をデジタイゼーション，デジタライゼーション，デジタルトランスフォーメーションという 3つの異なる段階に分解する．ここでは，デジタイゼーションは，アナログ・物理データの単純なデジタルデータ化のことであり，典型的には，紙文書の電子化である．デジタライゼーションは既存事業の業務・プロセスのデジタル化であり，さらに，デジタルトランスフォーメーションはデジタルエンタープライズとして顧客起点の価値創造ができるようになるために事業やビジネスモデル，システムを変革することである．

20SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)れなかったのは失敗では無く，顧客の期待やニーズについての学びがあったという成果があったととらえ，次の Tryに活かそうという意図が込められている．特に日本では，失敗があるとプロジェクトが中止になる企業が多いことから Test–and–Learn と呼ぶのは良いアイデアである．

積がなされている． 一方，フロントシステムである革新システム（Systems of Innovations）は，これらのシステムとは全く性格が異なり，最初に要件を定義することができない．
差別化システムでも，記録システムほど確実性は高くはないが，企業の戦略が先に立案され，その実現に資するものとして要件が定義されている．
これに対し，革新システムは何が正解かわからず，まずはリリースし，顧客や利用者の反応を見ながら，よりロイヤリティを高めるために，素早く改良を加えるということが求められる．リスクを早期に潰す反復型のアプローチでも反復頻度が間に合わず，アジャイル開発が必須であり，リリース期間を短縮するために DevOps を利用し，スケールアウト／インを迅速に行うためにクラウドが必須となっている．
先の DX レポート 2 の定義と照らし合わせると，デジタイゼーションが記録システム，デジタイゼーションが差別化システム，デジタルエンタープライズのシステムは SoIに相当する．
さて，図-4 は航空会社の座席予約システムの構成をペースレイヤーアプローチと関連して説明したものである．
[4]
デジタルエンタープライズのシステムは単独で構築されるように誤解されていることが多いが，実際にはこのように，３つのレイヤーのアプリケーションの組み合わせによって構築されることになる．

3.2. DX レポート２における表現
Digital Offering に該当するアプローチについて DX レ
ポート２では，アジャイルマインドでの継続した変革として，図-2 の様に表現している．[1]図-2 DX レポート 2 での説明
3.3. デジタルエンタープライズに求められるシステムの特性
図-3 に示すペースレイヤーアプローチはガートナーが2012 年に提唱したフレームワークで，主にシステムの変更頻度をもとにアプリケーションを分類するもので，ペースレイヤーごとに開発手法が異なる．[3]図-4 ３つのレイヤーの連係モデル

4. DX へのシステム面でのアプローチ
出典 5 を元に筆者が加筆
図-3 ペースレイヤーアプローチ
これまでの企業情報システムは，基幹システムと呼ぶ人が多い記録システム（Systems of Record）と戦略システムである差別化システム（Systems of differentiation）とで構成され，これらのシステム開発についてはノウハウの蓄

4.1. 両利き経営のアプローチ
DX レポート２では図-5 に示すように「デジタルトランスフォーメーションにおいて，既存システムは新規構築するシステムと相互に連携しながら見直し，デジタルエンター

21SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

プライズの実現を目指す」としており，図-4 と符合する．
[1]

現行ビジネスを継続せねばならず，Dizitization によってOperational Backbone の効率化(Operational Excellence)を追求する．
4.2.3.

Operational Backbone が信頼性と透明性で顧客満足に貢献するのに対し，Digital Platform は Digital Offeringの迅速かつ継続的な改良により顧客を喜ばせる．
このプラットフォームは，ビジネス，データ，インフラの３つのタイプの再利用型コンポーネ ントから構成され ，Digital Offering はこれらの組み合わせによって実現される．このため，各コンポーネントには API が実装される．
当初，Digital Offering のためにモノシリックなシステムを構築してしまうことが多いが，継続的な改善，再利用性，両方の要求を満足するためには，コンポーネントベース（＝マイクロサービス）のアプリケーション開発を行う必要に気づく．
必要なコンポーネントを早期に準備することは難しく，Digital Platform はインクリメンタルに増強することになる．
GE の Predix が Digital Platform の先駆けであり，日本
ではパナソニックが既に AWS 上に構築している．

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

4.2.4.

External Developer Platform

Digital Platform の拡張機能であり，デジタルコンポーネントを活用するパートナーとのエコシステムをサポートする．顧客への新たな価値提案は企業が単独でなしうるものではなく，様々なパートナーと共同することで初めて提供できるものとなってきている．先に示した Panasonic
や三菱電機はデジタルプラットフォームをパートナーに公開している．
＜DBS の事例＞⚫ 200 以上の Digital Components を API で公開している⚫ 認証などのインフラ系のコンポーネントもあるが多くはクレジットカード処理，ローン審査，外貨レート，顧客消費パターンなどビジネス系，データ系のコンポーネントである⚫ ハッカソンなどを通じてサードパーティとともに新たなサービスを構築している（SoCash が有名）
⚫ パートナーにはポータルを通じてコンポーネントを公開している➢ サイトへのサインアップ➢ 安全なサンドボックスでの自由な実験➢ DBS API の継続的な利用への申請

Shared Customer Insights

Digital Offering について企業はデジタルで何ができるか経験が十分ではなく，顧客側は実際に手にするまで自分たちは何が欲しいのか不明である．
そのため test –and –learn のプロセスを繰り返すことによって顧客インサイトを得て企業でシェアできるようになる．
いろいろなアイデアの可能性を継続的に試すことが必要で，このことを企業カルチャとして浸透させなければならない．
4.2.2.

Digital Platform

Operational Backbone

現行ビジネスを支える業務システムを指す．デジタル技術の活用について次の整理をしている．
Digitize : SMACIT（social, mobile, analytics, cloud, IoT）
でビジネスプロセスを強化すること．短期的な現行の競争優位の担保に必要であるが，将来の競争優位を作ることはできない．
Digital : これに対し SMACIT を顧客への価値提案のために適用することが Digital であり，デジタルトランスフォーメーションの本質は Digital である．
しかしながら，Digital はすぐに主力になるわけではなく，

22SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

図-6

5 Building Blocks

4.2.5 Accountability Framework5.

階層型組織は標準化された業務プロセスの効率化には有効であるが，Digital Offering の開発プロセスは Test& Learn であり，独立し empowerment されたイノベーションのチームにより推進される．
ただ各チームが独自の思惑で動くとカオス状態になることから component owner への Accountability Frameworkが必要となる．
Digital platform の各コンポーネントが Test & Learn によって絶えず更新されていきながら，図-7 に示す，API を通じて他のコンポーネントと協調して動くことを担保する（Autonomy and Alignment）８つの原則からなるマネジメントのしくみが必要となる．

Digital Platform の例

デ ジ タ ル エ ン タ ー プ ラ イ ズ の 基 盤 と な る Digital
Platform についてはすでに多くの構築事例がある．
5.1. みずほ FG の事例
図-8 はみずほ FG が構築した銀行 API であるが，5Building Block の External Developer Platform に相当す
る．[5]図-8 みずほ FG API
基幹システムの再構築の際に，業務ロジックを処理する共通業務 AP 層と，顧客との接点となるプレゼンテーション層に分けるというアーキテクチャを採用し，業務ロジックは再利⽤可能な粒度で Web サービスとして実装していたことから，公開する API をスムースに構築することができた．また，API の仕様も銀行の視点ではなく，Fintech 企
業が新しいサービスを構築できるようにするという視点で設計されている．

図-7 デジタルコンポーネントのマネジメント原則

23SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)5.2. Panasonic の事例
図-9 は IoT 家電を支える Panasonic Cloud Service
Platform のアーキテクチャである．[6]図-9 Panasonic のアーキテクチャ
IoT 家電の前段となるスマート家電サービスには 2012
年から取り組んでおり，当初はオンプレミス環境で自前主義でしくみを構築していたが，継続的な進化を続けるために，まずクラウドファーストとし，家電サービスと共通機能を分離し，個々に進化できるアーキテクチャに変更した．従来型のモノシリックなシステムでは，高速な進化に対応できないことから設計したものであり，各サービスが独立して運用が行えることを狙いとしている．そして，マイクロサービス化し，次々とサービスを追加できるようにしている．
そして，図-10 に示す Panasonic Digital Platform の構築を進めている．[7]図-11 Panasonic の External Developer Platform

6. DX 推進のアーキテクチャ面での課題
4 章でみたように，Digital Offering を提供する Digital
Platform については，意欲的な取り組みが進められており，AWS をはじめクラウドベンダーも新たなサービスを次々と構築してくれている．
例えば AWS の Re:Invent2020 において，JPMORGANCHASE が AWS の種々のサービスを使って DigitalPlatform を構築している旨の講演があった．既存アプリケーションの再構築を共同で進めていることへの言及もあった．
Digital Platform と既存システムの連携については，既存システム側に API を設けることが一般的である．
なお，フロントシステムと業務システムとの連携はＥＣサ
イトの開発で例えば在庫連携など多くの事例がある．ＥＣ
サイトの開発と業務システムの開発は一般にベンダーが異なるだけでなく，開発の作法も大きく異なる．そのため両社が共同で開発するということはなく，両システム間のインターフェイスの取り決めのみを行い，それぞれ独立して開発を進めるのが通例になっている．
そのため，API で既存システムとデジタル側を疎結合にするというアーキテクチャはなじみ深い．（ただし既存システム側のハードルは高い）
ここで課題となるのが，既存システムのモダナイズである．既に述べたように，DX レポート２では「デジタルトラン
スフォーメーションにおいて，既存システムは新規構築するシステムと相互に連携しながら見直す」とされており，また 5 Building Block においても既存ビジネスの競争力を当面担保するために，既存システムにデジタル技術の導図-10 Panasonic Digital Platform
さらにこの Panasonic Digital Platform を BtoB 向けに公開したのが図-11 に示す µSockets であり，5 Building
Block の External Developer Platform に相当する．[8]24SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

入を進めなければならないとされている．
残念ながら DX レポート 2 では，既存システムを技術的負債として，計画的な刷新が必要であること，デジタルビジネスと関連する部分から順に再構築するという抽象度の高い記述しかない．
DX の取り組みにあたっては，デジタル側と既存ビジネス側の両方の取り組みが必要なのであるが，「既存システムのモダナイズの具体的なガイドの作成」という重大な課題がある．

化以前に記述されたものであり，したがって，DX で使うには Architecture Maturity Stages をデジタル技術を反映したものにブラッシュアップしなければならない．
Stage2 は共通インフラの構築であり，VPC を含めてプライベートクラウドを構築することで多くの企業は対応済である．したがってデジタル技術反映の対象となるのはStage3 である．
表-2 は Stage3 での取り組み内容を EA の体系に従って整理したものである．コアコンピタンスを支えるビジネス
プロセス，データ，アプリケーションの標準化を進める．

7. Operational Backbone のモダナイズ
Operational Backbone の整備に関して，MIT Sloan は2006 年に Enterprise Architecture As Strategy[9]においてArchitecture Maturity Stages というフレームワークを提示しており，Designed for Digital ではこのフレームワークを参照するようにとしている．

表-2

BA

7.1. Architecture Maturity Stages
Architecture Maturity Stages は，MIT Sloan の Center
for Information Systems Research (CISR)が，1995 年から2006 年にかけて 456 の企業を研究調査した結果をまとめたもので，企業が SOA の導入成果を得るために，図-2に示すように次の４つのステージを順にステップアップしていく必要があるとしている．
Stage１：Business Silos:
個々の利用部門のビジネスニーズやシステムへの要求を最大限満たすことに注力しているStage２：Standardized Technology:
技術の標準化や集中化を通じて，ＩＴの効率化を追求する
Stage３：Optimized Core:
企業のビジネスモデルに応じて，全社視点からのコア業務とコアデータの標準化を進める
Stage４：Business Modularity:
疎結合状態でサービス化されたビジネスプロ
セスコンポーネントを再利用して，コア部分はグローバル標準を担保しつつ，ローカルの自由度を許している

DAAATAマネジメント

5 Building Block において，「企業がしっかりとしたOperational Backbone を構築していれば，他の４つのブロックはその上に築くことができる」としているが，これは企業が Architecture Maturity Stages の Stage3 に到達していることを求めている．
ただし，Enterprise Architecture As Strategy はデジタル

Architecture Maturity Stages の内容
Stage3
Optimized Core・ビジネスプロセスの標準化を進めている
・定義されたビジネスプロセスは企業のコアコンピタンスをとらえている・コアプロセスの変更は難しいが，新たなプロセスの追加は容易かつ迅速になっている・再利用可能なデータとビジネスプロセスはコアプロセのセットとして構築されている．
・共通データやコアプロセスの標準化では，ビジネスプロセスの設計の主体を個別ビジネスリーダから移管する・データを企業全体の視点からみる
・個々のアプリからトランザクションデータを抽出することで冗長性を減少させ，他のアプリから利用できるようにする
・重要な企業データへのインターフェイスを準備している・コアデータが企業のコアコンピタンスを反映している・コアデータの変更は難しいが新たなサービスを追加は容易かつ迅速になっている・再利用可能なデータとビジネスプロセスはコアプロセのセットとして構築されている．
・アプリを企業全体の視点からみる
・アプリケーションの標準化を進めている・共通インフラに関わる投資はほぼ終息し，投資の重点は共通アプリ，共通データ整備移行する・インフラ部分については効率化が次の課題となる・IT 投資が個別アプリやシェアードインフラから全社システムやシェアードデータに移る
・IT の役割は再利用可能なデータとビジネスプラットフォームを構築することにより企業の目標達成を容易にすることである
・CIO は標準化がイノベーションを可能にすると信じている・コアデータやコアプロセスは既存および新規の業務や顧客対応のための基盤を提供している・各企業のユニークな戦略的優位性はこの基盤の構築に起因している・標準化やコアの定義はトップダウンでのみ実現できる

25

SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

たは会社内において他の３つのどのオペレーティングモデルに該当するのかの検討を行う必要がある．

7.2. Operating Model
この Stage3 おいてコアの標準化を図る場合，自社（グループ）の事業モデル（Operating Model）が，表-3 の４つのモデルのいずれに該当するか見極めたうえで，コアプロセスの標準化を進めるべきであるとしている．

以降，Optimized Core の Operating Model 毎のアプ
ローチ方法をレビューしつつ，デジタル対応の方法について考察する．ただし，Diversification についてはインフラの共通化のみとなるので，対象とはしない．

表-3 ４つの Operating Model
Business
High Coordination
Unification
ProcessIntegration
Low Diversification

8. Operating Model 毎のデジタル化の検討

Replication

8.1. Unification
Unification での EA 設計方法を示したのが図-13 である．図の上段は設計プロセス，下段は成果物の表現方法を示している．この２段構図は４つのオペレーティングモデルに共通である．
Unification ではまず主要顧客を特定し，その顧客にサービス・商品を提供するためのコアプロセスを特定し，その標準プロセスを設計するとともに連携させるアプリケーションを決定する．並行して共有化すべきデータも特定する．どのような技術を用いるかは決定するがこれだけは主に IT 部門の役割となる．

LowHighBusiness Process Standardization
Stage3 での標準化の範囲が図-12 に示すようにオペレーティングモデルによって異なるからである．
①Unification
全社的に基盤プロセス の共通化を進めるこのオペ
レーティングモデルでは BA，AA，DA，TA 全てのレイヤーで標準化を行う．

図-12 Operating Model とその標準化ポイント②Replication
扱う商品や顧客ターゲットが異なるものの業務プロ
セスが類似するこのオペレーティングモデルでは DA以外を標準化する．
③Coordination
バリューチェーンプロセス毎に事業部制を敷く場合に該当するこのオペレーティングモデルでは，顧客は共通であるが，各事業部のプロセスは固有であることから，DA と TA が標準化対象となる．
④Diversification
このオペレーティングモデルは顧客も業務プロセスも異なるが持ち株会社によってグループ化されている場合が該当するため，標準化の対象は TA のみとなる．
ただし，グループ傘下の各社はそれぞれの事業群ま図-13 Unification での EA 設計方法
この設計手法を用いてデルタ航空の EA を表現したのが図-14 である．
デルタ航空の例では Operational Pipeline，Customer
Experience ， Business Reflexes ， Employee RelationshipManagement の４つのコアプロセスが識別され，それらで共通利用すべき９つのデータベースが定義されている．

26SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

この設計手法を用いて ING Direct 社の EA を表現したのが図-16 である．
ING Direct 社は Direct Banking サービスを各国で展開するにあたり，ローカルルールは許さない替わりに，各国で利用するビジネスモジュールを選択できることにしており，図には７つのサービスグループとして表示されている．

図-14 Unification での EA 設計例＜デジタル化のポイント＞
標準化の対象となるコアプロセスは主要顧客に商品やサービスを提供するプロセスであることから，プロセス識別後の詳細なデザインはサービスデザイン／デザイン思考を用いるデジタルエンタープライズの設計プロセスと同じものを採用する必要がある．この設計プロセスではサービスブループリントを描いてフロント側と業務システム側のインタラクションを定義し，その後システム要件の詳細定義を行う．
デジタル化の要素としてはフロント側からの Input がIoT に な っ た り ， デ ー タ 処 理 に お い て AI を 用 い てPersonalization を行うことなどが想定される．

図-16 Replication での EA 設計例＜デジタル対応のポイント＞
アプリケーションについて標準化と若干のローカライズを許可するようにする必要があることから，SaaS のマルチテナントと同様の設計をする必要がある．また個々のロジック部分についても AI の導入なども検討する必要がある．

8.2. Replication
Replication での EA 設計方法を示したのが図-15 である．Replication では標準化（複写される）プロセスを特定し，その標準化プロセスを支え共通利用させるアプリケーションとその技術を決定する．その後必要に応じてグループ企業／事業部門ごとのデータを設計する．

8.3. Coordination
Coordination での EA 設計方法を示したのが図-17 である．

図-17 Coordination での EA 設計方法
このオペレーティングモデルでは複数のビジネスユニ図-15 Replication での EA 設計方法

27

SEA

ソフトウェア・シンポジウム 2021 in 大分 (オンライン開催)

ットで顧客を共有することから，まずはその対象となる顧客を見極め関連して共有すべきデータを決める．このデータを共有し連携するプロセスを抽出し，そのうえで IT 部門はどのように共有データへのアクセスやプロセス連携を実現するのかを決める．
この設計例を示す図－18 では，さまざまな保険・金融商品の横断的な統合顧客サービスを実現するイメージが示されている．左側は顧客側のプロセス，右側は Metlife
社内のアプリケーションを示しており，統合 HUB という概念で統合データにアクセスさせている．

モダナイズ事例を調査し，今回考察したフレームワークとの整合性を検証することが必要である．その際，Operating Model の検討にあたって，全社を画一的に議論することは現実的ではない．業務群ごとにどのOperating Model を採用するのかを検討すべきであることも留意しておく必要がある．

参考文献[1] デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DX レポート 2（中間取りまとめ）https://www.meti.go.jp/press/2020/12/202012280
04/20201228004.html[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] https://www.slideshare.net/jeffshuey/pacelayered-approach-and-winshuttle-share-pointconference-nov-2012-jeff-shuey[4] Mary Mesaglio, Matthew Hotle, “Pace-Layered
Application Strategy and IT Organizational Design:
How to Structure the Application Team for Success”,
Gartner, 2016.7
https://www.gartner.com/binaries/content/assets/
events/keywords/applications/apn30/pacelayered-applications-researchreport.pdf#search=%27PaceLayered%27[5] https://www.ibm.com/blogs/solutions/jp-ja/camizuho/[6] 大穂雅博,箱田航太郎,「パナソニックの IoT 家電を支えるクラウド基盤の進化」，AWS SUMMIT Tokyo2019[7] 浅井将則他「パナソニックの IoT サービスを支えるクラウドプラットフォームの開発」,Panasonic Technical
Journal Vol.64 No.1,May 2018[8] https://news.panasonic.com/jp/press/data/2017/1
0/jn171002-4/jn171002-4.html[9] Jeanne W. Ross, Peter Weill, David Robertson,“Enterprise Architecture As Strategy: Creating aFoundation for Business Execution”, Harvard
Business School Press; 2006/8/8

図-18 Coordination での EA 設計例＜デジタル対応のポイント＞
Coordination ではデータ基盤のアクセスへの設計が鍵となる．
共有するデータにＩｏＴやＳＮＳのデータなどが含まれることを想定したデータ基盤を設計する必要がある．ＡＩなどの分析系の技術の適用は個別アプリで検討することとなる．

9. おわりに
以上，ＤＸの検討において課題となっている，既存業
務システムのモダナイズの方法について Architecture
Maturity Stages の Stage3 に到達するものとし，OperatingModel 具体的なに基づいた設計プロセスについて検討した．
検討した結果，デジタル化以前にまとめられたフレームワークではあるが，実装方法で最近のデジタル技術の適用を考慮する必要はあるものの，設計プロセスそのものは変更なく適用できることは分かった．
今後の課題として，DX の事例研究ではデジタルエンタープライズ側の取り組みに焦点が当たっていることが多いことから，同時並行的に進められている既存システムの28

SEA