DXとデータマネジメント
DXとは
2004年、スウェーデンのウメオ大学教授、エリック・ストルターマンは
「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」
ことを、DX（デジタルトランスフォーメーション）という言葉で表現しました。
総務省から出ている2018年版・情報通信白書ではDXによる社会の変化を次にように述べています。
この変化は段階を経て社会に浸透し、大きな影響を及ぼすこととなる。
まず、インフラ、制度、組織、生産方法など従来の社会・経済システムに、AI、IoTなどのICTが導入される。
次に、社会・経済システムはそれらICTを活用できるように変革される。
さらに、ICTの能力を最大限に引き出すことのできる新たな社会・経済システムが誕生することになろう。
これは、デジタル技術の浸透によって社会全体が大きく変わっていくこと（社会のデジタルトランスフォーメーション）を示しています。
それでは、デジタル技術によって社会全体が変化していく中、企業はデジタル技術を活用してどのように変わっていけばよいのでしょうか（企業のデジタルトランスフォーメーション）。
IDC Japan 株式会社は、企業におけるDXを次にように定義しています。
企業が外部エコシステム(顧客、市場)の破壊的な変化に対応しつつ、
内部エコシステム(組織、文化、従業員)の変革をけん引しながら、
第3のプラ ットフォーム(クラウド、モビリティ、ビッグデータ/アナリティクス、ソーシャル技術)を利用して、
新しい製品やサービス、新しいビジネスモデルを通して、
ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで
価値を創出し、競争上の優位性を確立すること 。
また、経済産業省がおこなっているDX調査2020では、DXを
企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること
と定義し、DXで取り組むべき分野を以下のように表しています。
以上より、DXにはレベルがあることがわかります。
企業レベルのDX
企業レベルのDXとは、上記JDCジャパンの定義にあるように、特定の企業でDXを進めるレベルです。
ブロックチェーンで言えば、一つの企業で構築運営するプライベートブロックチェーンを活用してDXを進めるレベルです。産業レベルのDX
産業レベルのDXとは、複数の企業が所属する産業全体でDXを進めるレベルです。
この場合、産業に所属する企業全体に共通のIT基盤を整備する必要があります。
デジタル技術を活用して新しい産業が生み出される場合もこのレベルに属します。
ブロックチェーンで言えば、同じ産業に属する複数の組織が管理するコンソーシアムブロックチェーンを構築してDXを進めるレベルです。社会レベルのDX
社会レベルのDXとは、産業を包括した社会全体でDXを進めるレベルです。
この場合、特定の国、あるいは、全世界で共通のIT基盤を整備する必要があります。
ブロックチェーンで言えば、管理者がおらず、誰でも自由に参加でき、ネットワークが自律的に維持・運営されるパブリックブロックチェーンによってDXを進めるレベルです。
ここでは、ここでは、企業レベルのDXを想定して話を進めます。
DXが求められる背景
先行き不透明で予測困難な昨今、環境の変化にアジャイルに対応しながらビジネスを展開していく必要がありますが、複雑化、ブラックボックス化した既存の業務やシステムが足かせとなってスムーズに適応できない会社が多々あるようです。
多くの会社が、ビジネスの変化が加速し、ビジネスとITが密接化する中、全体の設計図もなく、必要に応じてシステムを導入してきた結果、
大規模で複雑なシステムがサイロのように乱立している
重複して整合していないデータが散在している
個別の業務やシステムは詳しいが全体を理解できる人や資料がない
というカオスで雁字搦めな状況に陥っています。
経済産業省が2018年に出したDXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～では、企業におけるDXの必要性について次のように述べています。
あらゆるモノがつながる IoT 等を通じて活用できるデータが爆発的に増加し、また、AI、 クラウド、マイクロサービスやクラウドを活用したアジャイルアプリケーション開発、ブロ ックチェーン、AR/VR 等データを扱う新たなデジタル技術の活用の可能性が広がっている。
こうした中で、あらゆる産業において、これらの新たなデジタル技術を活用してこれまで にないビジネス・モデルを展開する新規参入者が登場し、デジタル・ディスラプションと呼ばれるゲームチェンジが起きつつある。
このような環境において、各企業は、競争力維持・ 強化のために、DXをスピーディーに進めていくことが死活問題となっている。
また、同レポートでは、企業がDXに対応できない現状を、
既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化している
経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中(=経営改革そのもの)、現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている
と分析した上で、このような状況を改善できない場合、
データを活用しきれず、DXを実現できないため、市場の変化に対応して、ビジネス・モデルを柔軟・迅速に変更することができずデジタル競争の敗者になる
多くの技術的負債を抱え、業務基盤その ものの維持・継承が困難になる
保守運用の担い手不在で、サイバーセキュリティや事故・災害によるシステムトラブルやデータ滅失等のリスクの高まる
という状況に陥り、DXが実現できないのみでなく、2025年以降、全体で最大12兆円/年(現在の約3倍)の経済損失が生じる可能性(2025年の崖）と予想しています。
※技術的負債(Technical debt)とは、短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態のことです。
DXによって会社はどう変わるべきか
以上より、企業のDXを次のように定義することができます。
企業を
データやデジタル技術を活用することで
環境の変化に応じて迅速に事業を変革・創出し
顧客を中心としたステークホルダーに価値を提供し続ける
体質にすること
ここで重要なのは、DXは一過性のものではなく、持続可能な体質をつくること（体質変換）、つまり、企業を学習し進化する組織に変えることだということです。
最近、DXを経営戦略の中心に据え、デジタル技術を導入している会社が増えているようです。
しかし、デジタル技術を導入しただけでは、企業を環境の変化に応じて迅速に事業を変革・創出し続ける体質に変換することはできません。
令和２年に経済産業省から出された「DXレポート２」ではDXを、次の３つの段階に分けています。
デジタイゼーション
アナロ グ・物理データの単純なデジタルデータ化。デジタライゼーション
個別業務・プロセスのデジタル化。デジタルフォーメーション
全社的な業務・プロセスのデジタル化、および、顧客起点の 価値創造に向けた事業やビジネスモデルの変革。
デジタル技術を導入した状態はデジタライゼーションで、デジタルフォーメーションにはならないからです。
ここでは、企業の体質変換を成功させる上で重要な鍵は次の３つだと考えています。
仮説検証の仕組
変化に強い構造
価値創出の企業文化
まず、仮説検証の仕組みについて説明します。
先行き不透明で予測困難な時代、これまでうまくいった方法を前提に計画、実行、検証、改善というPDCAサイクルをまわしても、前提自体が間違っている場合、うまく機能しません。
このような時代、環境の変化に応じて迅速に事業を変革・創出し続けるためには、環境の変化を察知して仮説を立て、実験してうまくいく方法を探してから、その方法を実践するという仮説検証型のアプローチのほうが有効です。
つまり、仮説検証を繰り返すことで持続可能性を高める、やればやるほど成功の確度が上がる仕組みをつくることが重要なのです。
次に、変化に強い構造について説明します。
仮説検証を通してうまくいく方法が見つかっても、新しい方法に業務とシステムが適応できないと、その方法は実現されません。
環境の変化に応じて迅速に事業を変革・創出するためには、業務とシステムを環境変化に柔軟に適応できる、つまり、変化に強い構造にしておくことが必要です。
最後に、価値創出の企業文化についてです。
業務やシステムの仕組みは整っていても、それを運用する人が動かなければ絵に描いたもちで終わってしまいます。
環境の変化に応じて迅速に事業を変革・創出するためには、企業を、それを構成するメンバー一人一人が環境の変化に気づき、アイデアを出し、仮説を立てて行動する状態に変える必要があります。
社員の創造の種が開花する土壌をつくる必要があるのです。
一つひとつ詳しく見ていきましょう。
仮説検証の仕組み（実験と実践）
仮説検証の仕組みを構築する上で重要なことは、
仮説検証を通して体系的に組織ナレッジが蓄積され、やればやるほど成功の確度が上がる仕組み
をつくることです。
社員の気づきからアイデアを起こし、仮説を立案し（Proof of Concept：概念実証）、実験計画を組み立てて実験を行い、検証結果から学びを得るというサイクルを繰り返すことで体系的に組織ナレッジが蓄積され成功の確率が上がっていきます。
仮説どおりうまくいった場合は「XXをする」というノウハウになり、
うまくいかない場合、「XXをしない」というノウハウになります。
なお、仮説は、人が考えるだけでなく機械に学習させてモデル化することもできます（仮説検証におけるビッグデータとAIの活用）。
蓄積された組織ナレッジは、通常のマネジメントサイクルで実践され、やればやるほど持続可能性の高い組織として成長していきます。
このように実験（Experiment）と実践（Execution）を繰り返しながら組織が成長するのですが、実験には、探索（Exploration）と深化（Exploitation）という二つのタイプがあります。
これは、「両利きの経営」という書籍で紹介された「知の探索」と「知の深化」と同じ概念です。
探索（Exploration）は、新しい方法を探すための実験で、イノベーション（革新）により事業を変革・創出するレベルになりますが、
深化（Exploitation）は、与えられた方法をよりよいものに改善するための実験で、オペレーション（運用）を改善するレベルになります。
例えば、生物のホメオスタシス（恒常性）のように、環境の変化に適応するために組織の状態を最適にすることを「自律」、生物であれば「種」が変化（遺伝子レベルの変化）するように、環境の変化に適応するために、新しく構造そのものを変えることを「進化」と考えると、深化は組織の自律を促し、探索は組織の進化を促す行為だと考えることができます。
ここで、ビジネスのライフサイクルを考えてみましょう。
次の図は、ビジネスのライフサイクルを表しています。
ビジネスには、その存在意義になる事業パーパスがあります。
「ビジョナリーカンパニーZERO」という書籍では、事業パーパスを
組織が存在する根本理由
とし、組織の行方を照らす星のように、常に努力すべき目標ではあるが、完全に達成されることはない（100年間に渡って会社の指針となる）と明記しています。
それに対して、ビジョン（書籍ではミッション）は、
大胆で説得力のある野心的目標
とし、明確なゴールと具体的期限がある、達成されると、新たなビジョンが設定される（理想的な時間軸は10年から25年）と明記しています。
以下、ビジョナリーカンパニーZEROからの引用です。
…
山岳地帯で案内星を追いかけるたとえ話を思い出してほしい。
パーパスはこの案内星で、常に地平線上に浮かんでいる。
決して手の届かないものだが、常に前へ前へと導いてくれる。
一方、ミッションはあなたがその時々に登っている山だ。
頂上に着いたら、再び案内星に視線を戻し、次に登るべき山を選ぶ。
ビジネスがビジョンを設定して、それを実現するための事業戦略を策定し、実行するサイクルを、ここでは「戦略サイクル」と呼びます。
戦略サイクルは、次のフェーズから構成されます。
設計フェーズ
ビジネスの本質的な型（ビジネスモデル）を設計するとともに、事業戦略の本質である戦略マップを策定し、戦略目標に対するリスクとコントロールを設計するフェーズです。戦略フェーズ
事業パーパスを具体化したビジョンを設定し、それを実現するための事業戦略を、戦略マップを具体化することで、策定します。
事業戦略は、BSCとアクションプランに展開されます。
※BSCのKPI目標値にはリスクの許容度を反映します。構築フェーズ
戦略フェーズのアクションプランに基づいて、ビジネスシステムを構築します。運用フェーズ
構築されたビジネスシステムを、会計期間ごとのマネジメントサイクル（PDCA）を通して運用します。
この戦略サイクルで考えると、探索は、設計レベル、戦略レベルの事業創出・変革であり、深化は、運用レベルの業務改革・改善になります。
社員一人ひとりがデータを利活用して自律的に業務課題を解決することができる状態を目指す「データドリブン経営」は、運用レベルの業務改革・改善になります。
変化に強い構造（アーキテクチャの設計）
企業を環境の変化に応じて迅速に事業を変革・創出し続ける体質に変換するためには、業務とシステムが環境の変化に柔軟に適応できるよう、業務とシステムを変化に強い、堅牢（Robust）な構造（アーキテクチャ）にする必要があります。
変化に強い構造とは、業務とシステムが、生産性、保守性が高い仕組みになっているということです。
生産性が高い仕組み
新しい業務とシステムがすぐに構築できる。保守性が高い仕組み
既存の業務とシステムをすぐに変更できる。
変化に強い構造にするときのポイント（アーキテクチャの設計思想）は次の３つです。
モジュール化
レイヤ化
プロセス統合
モジュール化
モジュールとは、システムを構成する交換可能な要素、部品のことです。
モジュール化とは、ビジネスや情報システムの構成要素を、インターフェース（仕様）と実装（実現）部分に分離し、相手の要素にはインターフェースだけを公開し、実装（実現）部分はブラックボックにすることです。
これによって、相手の要素にはインターフェースだけにアクセスできるようになり、実装（実現）部分を変更しても影響を受けることはありません。
なので、実装部分が自由に交換でき、保守性が向上するとともに、モジュールを再利用することによって生産性が向上します。
つまり、モジュール化によって交換可能性と再利用性が上がり、結果的に保守性と生産性を高めるのです。
レイヤ化
レイヤ化とは、ビジネスや情報システムを抽象レベルによって階層化することです。
ここでは、システムを、抽象レベルが高い順に、概念レベル、論理レベル、物理レベルと定義しています。
抽象レベルの高いレイヤは、環境が変化しても変化しにくい部分で、低いレイヤは、環境の変化に応じて変化します。
抽象レベルによって変化しにくい本質の部分と、変化しやすい現象の部分を分け、下位の要素が上位の要素に依存する関係にすることで、環境が変化した場合、変化する部分だけ置き換えることができるようになり、環境の変化に柔軟に適応できるようになります。
レイヤ化の要は、システムの本質を見極めることです。
ビジネスであれば、誰に何の価値をどのように提供するのかというビジネスモデルです。
不変的なビジネスモデルを見極めた上で、それを実現するため手段を柔軟に変えることができることが重要なのです。
プロセス統合
プロセス統合とは、ビジネスや情報システムの構成要素（モジュール）を、情報システムのユーザーやビジネスのステークホルダーなどに価値を提供するプロセスをベースに統合することで、これによってビジネスや情報システムを価値を提供する仕組にすることができます。
このように、変化に強いシステムを創るための３つのポイントは、システムを、それを構成要素に分けて、価値を提供する構造にする分析と統合のプロセスなのです。
ここで、情報システムと業務（ビジネス）についてそれぞれ見ていきましょう。
変化に強い情報システム
情報システムのモジュール化
次の図は、モジュール化された情報システムと、モジュール化されていない情報システムを比較したものです。
これを見るとモジュール化された情報システムのほうがシンプルでわかりやすいことがわかります。
モジュール化されていない場合、サブルーチンを構成する処理に、他の処理が直接アクセスするので、さまざま処理な処理にさまざまな処理がアクセスし、複雑になるとともに、処理を変更することで、それにアクセスする多くの処理影響を及ぼすことになります。
つまり、サブルーチンはホワイトボックスなので、他の処理によって雁字搦めになり、交換かつ再利用不可能な状態になります。
一方、モジュール化された情報システムの場合、モジュールのインターフェースだけ公開しているので、ブラックボックス化された実装（実現）部分を交換しても、他のモジュールに影響することはなく、再利用可能な単位として活用することができます。
オブジェクト指向プログラミングは、オブジェクトというモジュール同士の相互作用（メッセージパッシング）によってソフトウェアを組み立てることで、ソフトウェアの再利用性を高める手法です。
特に、オブジェクトとの多態性（ポリモーフィズム）という性質を利用することによって、オブジェクトと再利用性を上げることができます。
さて、次の図は、企業のアプリケーションシステムをマイクロサービスでモジュール化した例です。
マイクロサービスとは、ビジネス機能を一つのサービスとして提供したソフトウェア部品のことです。
この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一切影響受けないので、高い保守性を実現することができ、企業の情報システムを変化に強い構造にすることができます。
情報システムのレイヤ化
情報システムのレイヤ構造の例として、MDA（Model-Driven Architecture：モデル駆動アーキテクチャ）を紹介します。
MDAは、標準化団体であるOMG(Object Management Group)が「20年持続するソフトウェアアーキテクチャ」を目標として2001年に提唱した概念で、以下の３つのモデルから構成されています。
CIM（Computation Independent Model）
計算機処理に依存しないモデル。PIM（Platform Independent Model）
IT基盤に依存しないモデル。PSM（Platform Specific Model）
IT基盤に特化したモデル。
MDAでは、システムを構築するとき、この３つのモデルを分けて考え、CIM→PIM→PSMという流れで設計することで、より堅牢なシステムをつくることができるとしています。
まず、CIMですが、これは、業務の概念構造を表すモデルで、
業務がシステムに依存してはならない（システムが業務に依存する）
という考え方に基づいて設計します。
概念構造とは、私たちが認識する概念の意味的な関係に基づいて、構成要素を組み立てたモデルのことです。
デジタル技術は時代とともに進化していきます。
なので、システムも、デジタル技術の進化に伴って新しいものに置き換わっていきます。
目的は、価値を生む業務を設計することで、システムは、そのための手段です。
目的である業務が手段であるシステムに依存して左右されてはならないのです。
次に、PIMとPSMですが、PIMがシステムの論理的構造、PSMがシステムの物理的構造を表すモデルで、
システムの論理構造が物理構造に依存してはならない（物理構造が論理構造に依存する）
という考え方に基づいて設計します。
論理的構造とは、理論やルールに基づいて、構成要素を組み立てた（モデルのことで、物理的構造とは、物理法則に基づいて、構成要素を組み立てたモデルのことです。
CIMの業務課題を解決する論理的構造（目的）であるPIMが、それを実現するデジタル技術の物理的構造（手段）を表すPSMに依存してはならないのです。
このように、CIM、PIM、PSMを分けることで、変わりやすい部分と、変わりにくい部分を切り分けて考えることができるようになります。
例えば、デジタル技術が進歩し、新しい技術を導入したい場合、PSMだけ置き換えればよく、本質的な業務や、それを実現するメカニズムは変える必要はないのです。
このシステムから業務への依存関係、物理構造から論理構造への依存関係は、ソフトウェアの設計原則の一つ依存性逆転の原則（DIP）と同じ考え方です。
情報システムのプロセス統合
情報システムの場合、ユーザーに価値を提供するプロセスをシステムのユースケースとして考えます。
このユースケースを起点としてシステム開発の各工程が進められる考え方をユースケース駆動開発といいます。
ユースケース駆動開発では、まず、要件定義で、システムが実現すべき機能をユースケースとして定義し、そのあとの工程で、その機能を、システムを構成するモジュールがどう実現するのか分析、設計し、実装します。
ユースケース駆動開発によって、情報システムを構成するモジュールがユースケースによって統合され、ユーザーに価値を提供するシステムを実現します。
変化に強いビジネス
ビジネスのモジュール化
システムの構成要素であるモジュールは、相手の要素にインターフェースだけを公開し、実装（実現）部分はブラックボックすることで、実装部分が自由に交換でき、保守性が向上するとともに、モジュールを再利用することによって生産性が向上すると説明しました。
ビジネスの場合、モジュールの仕様部分がジョブ（職務）、それを実現するのがメンバー、アプリケーション、製品などの資産になります。
なお、ここでいう資産とは、価値を生み出すもの、ビジネスでいうと利益獲得能力（稼ぐ力）を持つものを指しており、財務的な資産だけでなく、人、もの、金、情報すべて含めた概念です。
ジョブはビジネスを遂行する機能単位で、その仕様は、職務記述書（ジョブディスクリプション）によって規定されます。
ビジネスをモジュール化することで、例えば、ジョブを実現する資産が人から機械に変わっても、人でも機械でも受け付けれられるようインターフェースを統一しておけば、そのジョブに関わる他のジョブの資産が影響受けることはありません。
このように、ジョブはビジネスの機能の仕様になるので、会社がジョブ型雇用を採用するしないにかかわらず、ジョブを定義することは大変重要です。
ビジネスのレイヤ化
ビジネスや情報システムを抽象レベルによってレイヤ化し、変化しにくい本質の部分と、変化しやすい現象の部分を分けることで、環境が変化した場合、変化する部分だけ置き換えることができるようになり、環境の変化に柔軟に適応できるようになると説明しました。
ビジネスの場合、レイヤ構造の概念レベル、論理レベル、物理レベルを、型（タイプ）、種類（カテゴリ）、実例（インスタンス）というように階層化します。
概念レベルの型（タイプ）が最も本質的な概念で、論理レベルの種類（カテゴリ）は、その部分集合になります。
述語論理でいう集合の条件で分類（カテゴライズ）するわけです。
そして、実例（インスタンス）は、集合に所属する物理的な実体、つまり、集合に属する要素を表します。
なので、型（タイプ）は、分類基準や評価指標などの属性や機能（集合の条件）を持ち、実例（インスタンス）は、その値や実装を持ちます。
型（タイプ）の違いは、それが持っている属性や機能（集合の条件）の違いであり、種類（カテゴリ）の違いは型の分類基準の値の違いになります。
例えば、顧客の場合、型を法人顧客にすると、種類は、それを業種、企業規模、エリアで分類した市場セグメントになり、実例は、その市場セグメントに属する個別の会社になります。下図の例の場合、論理レベルでは、業種が製造業で、企業規模が大規模、エリアが関東地方（集合の条件）に属する法人顧客という部分集合をつくっています。
また、製品の場合、型を衣類にすると、種類は、それを色、サイズ、デザインで分類した製品アイテムになり、実例は、そのアイテムに属する個別の製品になります。下図の例場合、論理レベルでは、色が青で、サイズがM、あるデザイン（集合の条件）に属する衣類という部分集合をつくっています。
ここでは、概念である型を考える活動を「設計」、型を論理的に分類する活動を「戦略」、戦略に従って実例を構築、あるいは、取得し、それを運用する活動を「構築・運用」と呼びます。
事業ライフサイクルで考えると、戦略サイクルの設計フェーズの活動が「設計」、戦略フェーズの活動が「戦略」、構築および運用フェーズの活動が「構築・運用」になります。
上記例でいうと、論理レベルで、業種が製造業で、企業規模が大規模、エリアが関東地方という集合（分類）の条件を考えることは、資源を集中すべきセグメントを考えること、つまり「戦略」を考えることになるからです。
マーケティング戦略の変更により市場セグメントは変わり、顧客層も変化しますが、法人顧客がビジネスに求める本質的な価値観は不変です。
ビジネスのライフサイクルの各戦略サイクルに設計フェーズがありますが、戦略フェーズは、法人顧客がビジネスに求める不変的な価値観を創出、提供する資産や活動を見直すタイミングになります。
さて、ビジネスを、縦軸に構成要素（目的・資産・場所・機能・活動）、横軸にレイヤ構造で分けると次の図のようになります。
これをビジネスストラクチャマトリクスと呼びます。
ここでは、資産を、価値を生み出すもの、ビジネスでいうと利益獲得能力（稼ぐ力）を持つ人、もの、金、情報、つまり、人的資産、知的資産、財務資産、情報資産としてとらえており、顧客、製品、メンバー、パートナー、アプリケーション、データ、IT基盤、財務資産に分類しています。
そして機能がジョブ、機能をいつどういう順番で実行するのかを示すのが活動であるビジネスプロセスになります。
本図は、各構成要素を型から種類、実例に展開しています。
例えば、ジョブを市場×製品、つまり、戦略別に分類したものが部門になります。
また、ビジネスプロセスを戦略別に展開したものがアクションプランです。
なぜ、誰に、何の価値を、誰が何を使って、どこで、いつどのように提供するのかというように、事業パーパスを起点にビジネスを組み立てることによってパーパスベース経営を実現することができます。
部門やアクションプランなど戦略レベルのから、もっとも本質的なビジネスの型（ビジネスモデル）を考えることによって、ビジネスをメタ認知することができます。
戦略を変えることで、アクションプランや組織は変わりますが、本質的なビジネスモデルは不変です。
また、戦略は同じでも、戦術の見直しによって、それを実現している個々の実体を変えることは頻繁にあると思います。
このように、不変的な部分と変動する部分を分けて可視化することによって、環境の変化によって変えるべき部分が明確になり、より柔軟に適応することができるようになります。
ビジネスプロセス統合
ビジネスや情報システムの構成要素（モジュール）を、情報システムのユーザーやビジネスのステークホルダーなどに価値を提供するプロセスをベースに統合することで、ビジネスや情報システムを価値を提供する仕組にすることができると上述しました。
ビジネスの場合、顧客を中心としたステークホルダーに価値を提供するプロセスは、ビジネスプロセスになります。
ビジネスストラクチャマトリクスでいいうとビジネスプロセスは最下層の部分になります。
パーパスを実現するために価値を生み出す資産によって実現される各ジョブをビジネスプロセスとして統合するのです。
ビジネスプロセスは、ジョブのタスク（課業）を活動の連鎖（業務フロー）として記述します。
ステークホルダーに対して価値を生み出す活動を強化し、価値を生み出さない活動を代替、削除することで業務を改善することができます。
なお、ビジネスプロセスは、戦略策定の段階でアクションプランに展開され、ワークフローとして実行されます。
価値創出の企業文化
最後に、価値創出の企業文化について説明します。
業務やシステムの仕組みは整っていても、それを運用する人が動かなければ絵に描いたもちで終わってしまいます。
仮説検証の仕組みができていても、社員の気づきやアイデアが次から次へでてこなければサイクルが回転しません。
企業の構造や仕組み（身体）は、魂を吹き込んで初めて動き始めるのです。
それでは、社員の創造に対するモチベーションを上げるにはどうすればよいのでしょうか。
もちろん、報酬などの形でインセンティブを付与したり、承認欲求を満たすための施策を設ける、オンラインミーティングツールなどデジタル技術を活用するなどテクニカルなやり方はあるとは思いますが、ここでは、社員のモチベーションの源泉は、
会社と共に成長できるという成長の喜び
会社の目的に貢献できるという貢献の喜び
ではないかと考えます。
社員が貢献と成長の喜びを得られる企業文化を構築するためにどうすればよいか。
そのためには、まず、経営や評価をオープンにしガラス張りにする必要がああります。
ホワイトボックス経営
社員が貢献と成長の喜びを得るためには、少なくとも
社員の行動の動機となる価値観である事業目的（パーパス）
事業目的を実現するためのビジネスモデル
会社が向かうべき先としてのビジョン
ビジョンを実現するための事業戦略
が社員に共有されており、
自分の作業が事業戦略のどの部分を担っているか把握できる
ようになっている必要があります。
そして、社員の作業、気づき、アイデアなどが公開され、誰もが自由に評価できるようになっていること。
この透明で公平な評価によって、結果の良し悪しに関わらず、社員は、そこから成長の糧を得ることができます。
また、検証された組織ナレッジは、全社員に公開されるので、それを実践することで社員は会社とともに成長することができます。
もしろん、事業目的（パーパス）やビジョンに対して社員が共感しなければ行動につながらないでしょうし、経営陣が率先して行動しなければ企業文化を構築することはできません。
しかし、
自分が何のために作業しているのかわからない
作業の結果が一部の上司の主観によって評価される
というブラックボックス化された歯車の中では社員の創造に対する動機づけは育たないのではないでしょうか。
学習し進化する組織
価値創出の企業文化を土台に、変化に強い構造、仮説検証の仕組みが組み立てられてて、初めて自ら学習し進化する組織ができあがります。
そして、これこそが、環境の変化に応じて迅速に事業を変革・創出し続ける体質であり、DXの目指すところなのです。
DX実現の戦略
次の図は、DXの戦略マップを表したものです。
本DX戦略マップは、経済産業省が行ったDX調査2020にある「DXで取り組むべき３つの分野」がベースになっています。
革新的な生産性向上
既存ビジネスの変革
新規ビジネスの創出
まず、戦略マップの土台となるのが企業情報基盤です。
これは、DXのベースとなる企業の中枢神経になります。
企業情報基盤を通して、さまざまな業務課題を解決することで、その結果が中枢神経にフィードバックされることで、企業情報基盤が学習し、さらなる企業の成長をもたらします。
次に、企業情報基盤として設計、構築されたIT基盤、データ、アプリケーション、ビジネスプロセスを運営することでデータドリブン経営を実現します。
ここでいうデータドリブン経営ができている状態とは、
社員一人ひとりがデータを活用して自律的に業務課題を解決することができる状態
のことです。
特定のマネジメントがデータを活用して企業の方向づけを行うだででなく、全社員が自律的にデータを活用して、各レベルの業務課題を解決することができる状態を目指します。
なので、全社員共通の価値観をベースとした組織文化が醸成されている必要があります。
その結果、データドリブン経営は、企業に革新的な生産性の向上をもたらします。
データドリブン経営を実現するためには、IT基盤とコミュニケーション基盤を運営して実現するITマネジメント、アプリケーション基盤を運用して実現するアプリケーションマネジメント、データ基盤を運用して実現するデータマネジメント、BPM基盤を運用して実現するビジネスプロセスマネジメントが必要です。
ビジネスプロセスマネジメントは、継続的に業務改善をするための体系的な手法です。
アプリケーションマネジメントは、DevOpsやマイクロサービスアーキテクチャによって、アプリケーション開発の生産性や保守性を改善します。
なので、業務改善の一環としてアプリケーションの開発や改良が必要な場合、それを速やかに実現します。
なお、COBITやITILは、アプリケーションマネジメントとITマネジメントを合わせたスコープになります。
このように、データマネジメントは、DXを実現するための重要な要素になります。
そして、データドリブン経営によって、IoTやAI、ブロックチェーンなど最新の技術を活用した変革アプリケーションが創出されます。
企業の中枢神経と変革アプリケーションが会社の神経系統を作り上げ、さまざまな業務課題を解決するために必要な情報を効率的、かつ、効果的に提供します。
それでは、DXはどう実現していけばよいのでしょうか。
DXは、ビジネスのライフサイクルの戦略サイクルで実現します。
DXの進め方のプロセスは次次のようになります。
企業情報基盤（論理基盤）の設計
企業情報基盤の論理基盤は、大きく、経営方針とエンタープライズアーキテクチャに分けることができます。
次の図は、ビジネスストラクチャマトリクスのレベル別に整理した、経営方針とエンタープライズアーキテクチャを表しています。
設計フェーズ
経営理念の明確化
企業のメンバーやパートナーの判断の拠り所でり、行動指針になる経営理念を明確にします。事業ドメインの見直し
事業ドメインの構成を見直します。
企業に複数の事業ドメインがある場合、それらの共通項は何か、活動（主要活動、支援活動）、資産（人的資産、知的資産、情報資産、財務資産）、ジョブ、場所の観点から抽出し、企業全体でシナジー効果を出すためにはどうすればよいかデザインします。事業パーパスの明確化
事業ドメインの事業パーパスを明確にします。事業成長モデルの設計
事業を持続的に成長させるための事業成長モデルを設計します。戦略マップの設計
事業成長モデルを価値創造プロセスである戦略マップに展開します。ビジネスプロセスマネジメントモデルの設計
ビジネスプロセスマネジメントの目的と方針を設定し、それを実現するためのビジネスアーキテクチャ（概念レベル）、ビジネスプロセスマネジメント基盤（基準レベル）、ビジネスプロセスマネジメント組織（ジョブ）、ビジネスプロセスマネジメントプロセスを設計し、ビジネスプロセスマネジメントポリシー（目的、方針、基準、手順）としてまとめます。
なお、ビジネスアーキテクチャはエンタープライズアーキテクチャ（EA）の一要素です。
また、ビジネスプロセスマネジメント基盤は、テクノロジーアーキテクチャの一要素です。ITサービスマネジメントモデルの設計
ITサービスマネジメントの目的と方針を設定し、それを実現するためのテクニカルアーキテクチャ（概念レベル）、IT基盤（基準レベル）、ITサービスマネジメント組織（ジョブ）、ITサービスマネジメントプロセスを設計し、ITサービスマネジメントポリシー（目的、方針、基準、手順）としてまとめます。
なお、テクニカルアーキテクチャはエンタープライズアーキテクチャ（EA）の一要素です。アプリケーションマネジメントモデルの設計
アプリケーションマネジメントの目的と方針を設定し、それを実現するためのアプリケーションアーキテクチャ（概念レベル）、アプリケーション基盤（基準レベル）、アプリケーションマネジメント組織（ジョブ）、アプリケーションマネジメントプロセスを設計し、アプリケーションマネジメントポリシー（目的、方針、基準、手順）としてまとめます。
なお、アプリケーションアーキテクチャはエンタープライズアーキテクチャ（EA）の一要素です。
また、アプリケーション基盤は、テクノロジーアーキテクチャの一要素です。データマネジメントモデルの設計
データマネジメントの目的と方針を設定し、それを実現するためのデータアーキテクチャ（概念レベル）、データ管理基盤（基準レベル）、データマネジメント組織（ジョブ）、データマネジメントプロセスを設計し、データマネジメントポリシー（目的、方針、基準、手順）としてまとめます。
なお、データアーキテクチャはエンタープライズアーキテクチャ（EA）の一要素です。
また、データ管理基盤は、テクノロジーアーキテクチャの一要素です。
戦略フェーズ
事業単位の見直し
事業ドメインを具体的な事業単位として定義します。事業ビジョンの明確化
事業パーパスを具体的な事業ビジョンとして表明します。事業戦略の策定
戦略マップを具体的な事業戦略に展開します。ビジネスプロセスマネジメント戦略の策定
ビジネスプロセスマネジメントのビジョンを設定し、それを実現するためのビジネスアーキテクチャ（論理レベル）、ビジネスプロセスマネジメント基盤（製品レベル）、ビジネスプロセスマネジメント組織（部門）、ビジネスプロセスマネジメントシステム構築プランを設計、策定します。ITサービスマネジメント戦略の策定
ITサービスマネジメントのビジョンを設定し、それを実現するためのテクニカルアーキテクチャ（論理レベル）、IT基盤（製品レベル）、ITサービスマネジメント組織（部門）、ITサービスマネジメントシステム構築プランを設計、策定します。アプリケーションマネジメント戦略の策定
アプリケーションマネジメントのビジョンを設定し、それを実現するためのアプリケーションアーキテクチャ（論理レベル）、アプリケーション基盤（製品レベル）、アプリケーションマネジメント組織（部門）、アプリケーションマネジメントシステム構築プランを設計、策定します。データマネジメント戦略の策定
データマネジメントのビジョンを設定し、それを実現するためのデータアーキテクチャ（論理レベル）、データ管理基盤（製品）、データマネジメント組織（部門）、データマネジメントシステム構築プランを設計、策定します。
企業情報基盤（物理基盤）の構築
IT基盤の構築
ITサービスマネジメントシステム構築プラン（IT基盤構築プラン）に従って、IT基盤を構築します。アプリケーション基盤の構築
アプリケーションマネジメントシステム構築プラン（アプリケーション基盤構築プラン）に従って、アプリケーション基盤を構築します。
アプリケーション基盤は、ERP、SCM、CRM、PLMなど企業の基幹システムと、ESB/EAIなどアプリケーション連携基盤から構成されます。
基幹システムを構築するときは、アプリケーション基盤構築プランは、通常のアプリケーション開発プロセス（要件定義、分析、設計、実装、テスト）をベースに策定されます。
アプリケーションアーキテクチャ（論理レベル）でアプリケーション機能の機能要件、アプリケーション基盤（製品レベル）でアプリケーションの非機能要件が定義されているので、それをベースに要件定義を進めます。
また、データアーキテクチャ（論理レベル）でテクニカルビジネスメタデータが定義され、データ要件（品質要件、セキュリティ要件）が定義されているので、それも参考にして要件定義を進めます。
基幹システムにパッケージ製品を適用する場合、分析工程で、Fit&Gap分析を実施します。データ管理基盤の構築
データマネジメントシステム構築プラン（データ管理基盤構築プラン）に従って、データ管理基盤を構築します。ビジネスプロセスマネジメント基盤の構築
ビジネスプロセスマネジメントシステム構築プラン（ビジネスプロセスマネジメント基盤構築プラン）に従って、ビジネスプロセスマネジメント基盤を構築します。
データドリブン経営の実現
ITサービスマネジメント組織の構築
ITサービスマネジメントシステム構築プラン（ITサービスマネジメント組織の構築プラン）に従って、ITサービスマネジメント組織を構築します。ITサービスマネジメントシステムの検証
ITサービスマネジメントプロセスに従って、ITサービスマネジメントシステムを運用し検証します。アプリケーションマネジメント組織の構築
アプリケーションマネジメントシステム構築プラン（アプリケーションマネジメント組織の構築プラン）に従って、アプリケーションマネジメント組織を構築します。アプリケーションマネジメントシステムの検証
アプリケーションマネジメントプロセスに従って、アプリケーションマネジメントシステムを運用し検証します。データマネジメント組織の構築
データマネジメントシステム構築プラン（データマネジメント組織の構築プラン）に従って、データマネジメント組織を構築します。データマネジメントシステムの検証
データマネジメントプロセスに従って、データマネジメントシステム運用し検証します。ビジネスプロセスマネジメント組織の構築
ビジネスプロセスマネジメントシステム構築プラン（ビジネスプロセスマネジメント組織の構築プラン）に従って、ビジネスプロセスマネジメント組織を構築します。ビジネスプロセスマネジメントシステムの検証
ビジネスプロセスマネジメントプロセスに従って、ビジネスプロセスマネジメントシステムを運用し検証ます。
企業文化の醸成
企業情報基盤（物理基盤）の構築、および、データドリブン経営の実現と平行して、企業情報基盤（論理基盤）の一環として明確にした経営理念を醸成します。
変革アプリを活用した事業の創出・変革
変革アプリを活用して以下を実現します。
革新的な生産性の向上
既存事業の変革
新規事業の創出
ビジネスのライフサイクルの戦略サイクルで見ると、企業情報基盤（論理基盤）の設計が設計フェーズ、および、戦略フェーズ、企業情報基盤（物理基盤）の構築、データドリブン経営の実現、企業文化の醸成、変革アプリを活用した事業創出・変革が構築フェーズ、その後の事業の運用が運用フェーズになります。
令和２年に経済産業省から出された「DXレポート２」ではDXを、次の３つの段階に分けています。
デジタイゼーション
アナロ グ・物理データの単純なデジタルデータ化。デジタライゼーション
個別業務・プロセスのデジタル化。デジタルフォーメーション
全社的な業務・プロセスのデジタル化、および、顧客起点の 価値創造に向けた事業やビジネスモデルの変革。
この段階でいうと、企業情報基盤（物理基盤）の構築までがデジタライゼーションであり、企業文化を醸成するとともに、データドリブン経営を実現し、変革アプリを活用して事業を創出・変革できるようになるまでがデジタルフォーメーション（体質変換）になります。
さて、DXの進め方のプロセスのうち、以下がデータマネジメントの領域になります。
データマネジメントモデルの設計
データマネジメント戦略の策定
データ管理基盤の構築
データマネジメント組織の構築
データマネジメントシステムの検証
詳細は、「データマネジメントの導入」を参照してください。
この記事が気に入ったらサポートをしてみませんか？