楽水

人々の創造が自由に表現できる舞台づくり

DX

DXを成功させる3の鍵

投稿日:2021年11月8日 更新日:


前回の記事では、本当にDXを進める必要があるのか、という観点で説明しました。
今回は、本気でDXを考えている会社を対象に、DXを成功させるために重要だと考えられるポイントについて考えてみたいと思います。

DXによって会社はどう変わるべきか

前回の記事で、
企業のDX(デジタルトランスフォーメーション)とは、
デジタル技術を活用して、
企業の業務とシステムを、

  • 環境の変化に強い構造にし
  • 迅速に価値を創出し続ける体質にする

ことであると述べました。

なので、

  • これまでと同じアプローチでIT化を進めても、上図の左側の状態が延長されるだけでしかない
  • DXとは、企業の心身を変革する活動であり、相当な痛みを伴う活動であることを認識する必要がある

と説明したました。

DX成功の鍵

以上を認識した上で、VUCAの時代を生き残るために本気で企業の抜本的な変革をしたい場合、以下の3つのポイントを考慮する必要があると考えます。

  • 論理から物理へ
  • 企業を、変化に強い構造にするために、業務とシステムを、変わりにくい本質的な論理的構造と、技術の進歩によって変わりやすい物理的構造に分けて設計する。

  • 縦から横へ
  • 企業を、価値を生む構造にするために、価値を提供する相手を中心に業務とシステムを組み立てる。

  • 実験と実践
  • 実験と実践を繰り返す(走りながら考える)ことで価値を生み出し続ける体質にする。


一つ一つ見ていきましょう。

論理から物理へ

企業の業務とシステムを、環境の変化に強い構造にするには、まず、論理的な視点でアーキテクチャ(基本構造)を設計し、その上で物理的な構造を設計する必要があります。
ここでいう物理的構造、論理的構造とは以下のような意味で使います。

  • 物理的構造
  • 物理法則にかなっている対象や様子を表す構造。

  • 論理的構造
  • 論理(物事の間にある法則、筋道)にかなっている様を表す構造。
    筋道が通っていればよく、必ずしも物理法則に則っている必要はない。

モデル駆動アーキテクチャ

これらの違いを明確にするために、MDA(Model-Driven Architecture:モデル駆動アーキテクチャ)について説明します。
MDAは、標準化団体であるOMG(Object Management Group)が「20年持続するソフトウェアアーキテクチャ」を目標として2001年に提唱した概念で、以下の3つのモデルから構成されています。

  • CIM(Computation Independent Model)
  • 計算機処理に依存しないモデル。

  • PIM(Platform Independent Model)
  • IT基盤に依存しないモデル。

  • PSM(Platform Specific Model)
  • IT基盤に特化したモデル。

MDAでは、システムを構築するとき、この3つのモデルを分けて考え、CIM→PIM→PSMという流れで設計することで、より堅牢なシステムをつくることができるとしています。
まず、CIMですが、これは、業務の論理的構造を表すモデルで、
業務がシステムに依存してはならない
(システムが業務に依存する)
という考え方に則っています。
デジタル技術は時代とともに進化していきます。
なので、システムも、デジタル技術の進化に伴って新しいものに置き換わっていきます。
目的は、価値を生む業務を設計することで、システムは、そのための手段です。
目的である業務が手段であるシステムに依存して左右されてはならないのです。
次に、PIMとPSMですが、PIMがシステムの論理的構造、PSMがシステムの物理的構造を表すモデルで、
システムの論理構造が物理構造に依存してはならない
(物理構造が論理構造に依存する)
という考え方に則っています。
CIMの業務課題を解決する論理的構造であるPIMが、それを実現するデジタル技術の構造を表すPSMに依存してはならないのです。
このように、CIM、PIM、PSMを分けることで、変わりやすい部分と、変わりにくい部分を切り分けて考えることができるようになります。
例えば、デジタル技術が進歩し、新しい技術を導入したい場合、PSMだけ置き換えればよく、本質的な業務や、それを実現するメカニズムは変える必要はないのです。

モジュール化・カプセル化・カタログ化

次に、MDAをベースに業務とシステムを設計する際に重要となる、モジュール化、カプセル化、カタログ化について説明します。

  • モジュール化
  • モジュール化とは、業務やシステムの構成要素を、再利用可能な部品として考えることです。

  • カプセル化
  • カプセル化とは、業務やシステムの構成要素を実現する物理的手段やデータを隠蔽し(ブラックボックス化)、それらを交換可能にすることです。
    そのためには、構成要素を、論理的な仕様の部分(インターフェース)と、それを実現する物理的な部分に分けて設計し、構成要素を利用する相手に対してインターフェースのみ公開する必要があります。
    これによって、要素同士が疎結合することにより、相手の変更による影響を最小にする仕組みにすることができます。

  • カタログ化
  • カタログ化とは、業務やシステムの構成要素のインターフェース(仕様)をカタログとして公開することです。
    部品の仕様を可視化し、相手から使いやすくすることで、効率的かつ効果的に業務やシステムを構築することができます。


モジュール化、カプセル化、カタログ化により、新しい業務やシステムを構築するとき、既にある部品を再利用することができるので、生産性を高めることができ、企業を変化に強い構造にすることができます。
また、部品を使う相手は、そのインターフェースのみ依存するので、実現部分を変更しても影響を受けず、高い保守性を実現することができ、企業を変化に強い構造にすることができます。
例えば、アプリケーションシステムをマイクロサービスでモジュール化すると以下の図のようになります。

この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一斎影響受けないので、高い保守性を実現することができ、企業を変化に強い構造にすることができます。

縦から横へ

多くの会社では、自部門のことはわかるが、他部門のことはわからないというセクショナリズムに陥り、会社が部分最適化されています。
そのため、部門間のコンフリクトによる品質の低下や、納期の遅延など、会社の価値を落としかねない事態を招くこともあるようです。
顧客に価値を提供し続けることが企業の大目的です。
なので、顧客を中心にすべての活動が組み立てられている必要があります。
これは、基準を組織からビジネスプロセスに移して考える必要があるということです。
ビジネスプロセスとは、それを構成する活動が資産を消費することで顧客などビジネスの利害関係者(ステークホルダー)に対する価値を生み出し、結果的に資産の状態を変化(増減)させる組織横断的な単位です。

つまり、組織とビジネスプロセスは、縦と横の関係になります。
「縦から横へ」とは、視点を企業の内部(内部的視点)から、価値を提供する相手の立場(外部的視点)にシフトして考えるということです。
視点を相手の立場(外部的視点)に置くことで、
相手にとっての価値とは何か、
それをどう実現すればよいか
考えることができるようになります。
価値の実現という基準で、資産や活動を再設計することで、企業を部分最適から全体最適へ移すことができます。
具体的には、業務やシステムを以下のような手順で設計します。

  • 機能
  • 相手に対して何の価値を提供するのか(Whatの視点)。
    相手に提供する機能を考える。

  • 構造
  • それを誰が実現するのか(Whoの視点)。
    機能を実現する業構やシステムの構成要素と、それらの関係(構造)を考える。

  • 振舞
  • どのように実現するのか(Howの視点)。
    業構やシステムの構成要素がどのように協調動作しながら顧客に対する機能を実現するのかを考える。


なお、振舞は、業構やシステムの構成要素がちゃんと機能を実現できるか、内部構造の妥当性を検証するステップです。

実験と実践

実験と実践の動画


先行き不透明で予測困難な時代、これまでうまくいった方法を前提に計画、実行、検証、改善というPDCAサイクルをまわしても、前提自体が間違っている場合、うまく機能しません。
このような時代、まず、実験して、うまくいく方法を探してから、その方法を実践するというアプローチのほうが有効です。
つまり、まず、仮説をたて、実験し、その結果を検証して改善する仮説検証プロセスが重要なのです。

この仮説検証プロセスですが、これは、
まず、なんらかの現象を観察することで問題(事象)を発見するところから始まり、
その原因を推定し、それを解決するための計画をたてて、
実験する
その結果を検証し、
学びを得る、
そして、うまくいかなければ、再度実験計画を改善する。
このような仮説検証サイクルをまわすことです。

これを、論理的推論という観点で考えてみましょう。
論理的推論には、大きく以下の3つがあります。

  • 演繹(Deduction)
  • 演繹は、規則と前提から結論を導きます。
    前提を原因、結論を結果と考えても良いでしょう。
    また、規則とは、前提が真であれば結論も必ず真になるという論理的関係のことです。
    数学者は、通常、演繹的に推論します。
    演繹の場合、前提が真ならば結論も真になることを保証します。

  • 帰納(Induction)
  • 帰納は、前提が結論を伴ういくつかの事例を観察した結果として規則を推論します。
    科学者は、通常、帰納的に推論します。
    帰納の場合、推論した規則が真であることを保証しないので蓋然的、つまり、確率的な推論になります。

  • 仮説推論(Abduction)
  • 仮説推論は、結論に規則を当てはめて前提を推論します。
    医者や探偵、コンサルタントは、通常、仮説推論をします。
    仮説推論の場合、推論した前提が真であることを保証しないので蓋然的、つまり、確率的な推論になります。


さて、ここで、仮説検証プロセスの仮説を立案する部分を次のように考えてみましょう。

  • 問題の分析
  • まず、どこで問題や事象が生じているか分析する。

  • 原因の推定
  • 次に、問題が発生する原因や、問題を起こしている要素の特徴を推定する。

  • 課題の設定
  • 次に、原因を取り除くための課題と根拠を明確にする。

  • 解決策の設計
  • 最後に、課題に対する解決策を設計する。

このように考えると、
問題を分析し、何らかの規則に則って原因を推定する流れは、論理的推論でいうと仮説推論(アブダクション)になることがわかります。
つまり、論理的推論で考えると、仮説推論(アブダクション)で、何らかの規則を過程して、原因を推定し、実験計画を立て、実験、検証して、その規則を帰納的に実証する部分が仮説検証プロセスということになります。
ちなみに、規則が帰納的に実証されれば、それを使って、演繹的に問題を解決していく。
この部分は、通常のPDCA(計画・実行・検証・改善)をまわす実践プロセスということになります。

さて、仮説立案の部分に戻って、問題の分析から解決策の設計までに、ロジカル思考、システム思考、デザイン思考という思考法をあてはめてみると、
ロジカル思考のロジックツリーを使って、どこで問題や事象が生じているか分析することができ、
システム思考の因果ループを使って問題が発生する原因や、問題を起こしている要素の特徴を推定し、
ロジカル思考のピラミッドストラクチャで、原因を取り除くための課題と根拠を明確にし、
デザイン思考で、課題に対する解決策を設計することができます。
なお、解決策を設計する一環としてアクションプランとして実験計画を策定します。

次に、仮説立案とデータ分析の関係を考えてみましょう。
データ分析は、次の3つに分けることができます。

  • 記述的分析(Descriptive Analytics)
  • 過去に何が起こったかをデータから読み取り説明する分析。

  • 予測的分析(Predictive Analytics)
  • 将来何が起こるかデータから読み取り予測する分析。

  • 処方的分析(Prescriptive Analytics)
  • データを活用して複雑な意思決定を自動化する分析。

記述的分析は、通常の統計的な分析、予測的分析、処方的分析には機械学習やAIを活用します。
予測的分析、処方的分析の詳細については、データサイエンスを参照ください。
仮説立案にデータ分析を適用してみると、まず、問題を分析して、問題を特定するときに、記述的分析でデータの様子(分布や相関)を確認します。
次に、機械学習やAIを活用して、問題に対する原因を探究し、将来を予測します。
例えば、仮説推論の規則として、線形回帰モデルなどが想定されます。
このとき、分析するために必要なデータがあるかないか、どこにあるか、データ品質はどうか確認します。
そして、解決策を設計するとき、機械学習モデルを適用することで、どの程度の利益が期待できるのか、予測される結果に対する期待値を算定します。

そして、仮説として立案された実験計画にそって、それを実験を通して検証することで、うまくいく方法を見つけ出すのです。
なお、実験結果は、仮説検定など統計的な方法によって検証されます。
また、仮説検証によって実証された機会学習モデルやノウハウは組織ナレッジとして蓄積されます。

一般的に予測的分析や処方的分析によるデータサイエンスは、前提と結論の事実であるデータから線形回帰モデルのような規則を推論する帰納的推論とされています。
ここでは、線形回帰モデルの型を規則として、結果(目的変数)から原因(説明変数)の当たりをつけて(仮説推論)、それをランダム化比較実験によって検証するというアプローチを考えています。
次に、ビジネスにおける仮説検証プロセスの位置付けについて考えてみましょう。
事業戦略を、財務の視点、顧客の視点、活動の視点、資産の視点で考えると、
収益を上げるためのビジネス課題
顧客価値を上げるためにビジネス課題
コアコンピタンスを上げるためのビジネス課題
資産価値を上げるためのビジネス課題
が考えられ、それらを解決するための仮説検証が実行されることになります。

-DX

執筆者:

関連記事

アジャイル開発とは何か【わかりやすく解説】

最近、アジャイル開発という言葉が、大分、定着してきました。 しかし、全体的に、アジャイル開発の手法やツールなど技術的側面がクローズアップしているように思えます。 そのせいか、開発プロジェクトにアジャイ …

データマネジメント知識体系【DMBOK】とは

5Gが普及すると、ますます、IoTなどにより発生するビッグデータを、AIを活用してビジネスに活かすことが当たり前になってきます。 データは21世紀の石油と言われています。 「稼ぐ力を持つ資産としてのデ …

ビジネスモデルの作り方【俺のフレンチを題材に解説】

ここでは、ビジネスモデルの作り方について以下の観点で説明します。 ビジネスモデルとは何か 良いビジネスモデルの条件 ビジネスモデルを作る手順 ビジネスモデルとは何か ビジネスモデルとは何か、文字通りに …

テクノロジーアーキテクチャ(TA)とは

エンタープライズアーキテクチャ(EA)とはという記事で、テクノロジーアーキテクチャ(Technology Architecture)とは、IT基盤の設計思想、および、基本構造を表すと書きました。 また …

エンタープライズアーキテクチャ(EA)とは【わかりやすく解説】

ここでは、以下の観点で、エンタープライズアーキテクチャ(EA)について解説します。 エンタープライズアーキテクチャ(EA)とは エンタープライズアーキテクチャ(EA)の重要性 エンタープライズアーキテ …