日本型DXの成功にはデータ中心型ビジネスアプローチ（DxBA 通称DOBA)が有効！
以下は、3月に日経クロステックに掲載された記事の元原稿を校正したものの第二回目分になります。
内容はデータ中心型ビジネスアプローチ(DxBA 通称DOBA)についての(前回からの）説明の続きになります。
DOBAはDXを実践する際にも当然のことながら有効である。DX時代の今、データの重要性は益々高まっている。DXのDはデジタルではなくてデータでもいいのではないかという人もいるくらいだ。
人によっては当たり前かもしれないが重要なことなので改めて書く。
データは繋がることにより価値が増大する。
もう4年以上前の話になるが、筆者はコロナ禍前にLasVegasで開催されたCESに初めて参加した。
CESとは世界最大のテクノロジーの祭典である。
ハードが中心とはいえ最新、そして未来のテクノロジーの姿がそこにはあった。その際、このカンファレンスの空間を現地で体験して確信に変わったことがある。
「テクノロジーは益々データの繋がりを指向する、そしてその流れは止めることができない」という思いだ。
もちろん業務ITシステムも例外ではない。3年が経って、この思いは筆者の想像を超えて現実になろうとしている。DXは当然この文脈の中で実践すべきである。
DXとは、ご存じの通り、もともとは「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念のことを指す。DXとはDigital Transformationの略だから、デジタルテクノロジーによる変革が前提になる。
テクノロジーの進化は著しいものがあり、これからは、その進化を柔軟に受け入れることができるシステムが当たり前のように求められることになる。
ではデータの繋がりを今まで以上に指向してDXを実践するためにはどうすればよいか。
実はDXでも基本やることは同じ。EAにおけるBA、ビジネス（業務）体系を構築することから始めるべきだ。
例えば、デジタルディスクリプションを目指すなら「ビジネス鳥瞰図」をビジネス自体も見直しつつ納得がいくまで仕上げることだ。ここで一応仕上がったらそれを「ビジネス地図」「ビジネス航路図」「ビジネス行動図」に落とし込んでいく。この3つを作成したら、常に4つの図をセットで改訂していく。繰り返し、納得がいくまで。場合によってはビジネスの調整を行う。DXの場合、「ビジネス航路図」は業務フローよりも、少し粒度の細かいシナリオの方がわかりやすい場合もあるかもしれない。そういった場合は躊躇なく記法を変更して作成していく。
そしてビジネス（業務）体系として形になったら、実現すべき他の体系DA、AA、TAを構築していく。現状を意識しすぎると単なる改善になってしまう。どこまで制約、前提を取り払ってあるべき姿を考えられるか、が重要になる。これが通常のシステム開発とはやや異なることかもしれない。
昨今、テクノロジーの進化は無視できない。確実にＢＡに影響を与える。進化が前提になることも多い。
例えばTA：技術体系であればなんといっても「クラウド」ベースである。DXはクラウドファーストで考えるのが常識だ。AA:適用処理体系であれば「アジャイル開発」「ノーコード／ローコード開発」等が当たり前になった。基幹系システムでは「ERP」使用が当たり前になっている。SaaSのサービスの進化もすさまじい。
受けた影響については当然、BA:ビジネス(業務)体系に取り込んでいくことになる。
☆ビジネス地図としてのデータモデルをどう成長させていくか
DXが、技術進化の影響を受けつつデータを指向する以上、創造的なビジネス地図、すなわち概念データモデルが益々重要になることはいうまでもない。
DX含むプロジェクト単位の概念データモデルを書いたら全社単位に統合していこう。これこそが企業全体のシステム設計図におけるビジネス（業務）体系全てを網羅するビジネス地図になる。カタカナ用語では「エンタープライズデータモデル」を書くことになる。断片のようなモデルをパズルに当てはめるように全社モデルを作り上げる。その前にマスター、コードに関しては当初から全社で一元化して常に整合性を確保しておくことが望ましい。
☆DXスキル標準
経産省、IPAよりDXスキル標準が公開された。
この中で新たな職種の提示がなされた。ただ、どの職種の人がデータモデル書くのか？は書かれていない。(少なくても筆者にはわからなかった）
データに関しては活用するための視点ばかり強調されているように筆者には思えた。
ビジネスアーキクテクト？ デザイナー？ データサイエンティスト？ 多分デザイナーが担当することになるのだろうか。
DXはデータが命である。非構造データも含めてデータをきちんと管理できなければ話にならない。そのためにはまずデータの器を作り、その器にデータを適切に流し込まなければならないはずだ。DX関係の資料では、データは既にあるものでそれをどう生かすかどうかにばかり焦点があたっている。データ構造及び、どのように生成、参照、更新、削除されるのか、といった大事なことが欠落しているように思える。
スキル標準のいずれかの職種のミッションとしてDOBA、データモデル作成を主要なミッションで加えて欲しいものだ。
☆DXならば、SaaS、ERP、ノーコード／ローコードへの対応は不可欠
先ほども説明したようにDX実現手段は多岐にわたる。SaaSサービス、ERP、ノーコード／ローコード、IoＴは当たり前に使われる。そして当たり前のようにデータ連携が益々増えてくる。
一昔前のように基幹系システム再構築といった一から大規模な開発を行うケースは少なくなった。最近のシステム開発のトレンドはいかにシステムを組み合わせて構築を行うか、になっている。DXも例外ではない。いいものがあればどんどん使う、そしてデータ連携、統合を行って価値を高めていく。DOBA及びビジネス地図としての概念データモデルの重要性は益々高まることになる。
☆やっかいなデータ統合
データが繋がることは、連携だけでなく、統合によってもなされていく。
データ統合悩ましい問題だ。
マスター統合だけでなく、コードの統合も難敵だ。
ある値が片方のシステムでは1、もう片方のシステムでは２の場合、本当に2に片寄せしてよいのか。
データの中身だけを見つめていても解決しない。
統合後の「入力する前のプロセス」「入力後のプロセス」を新たに定義してシナリオを作成しなければ、実運用には耐えられない。
データとともにプロセスはやはり重要である。その際、データとデータをハンドリングするプロセスをどうすべきか、という観点で考えるべきだ。この場合はDXとは異なり、今ある姿からあるべき姿を作り上げることになる。
ここでもDOBAの４つの図式、特にビジネス地図である概念データモデルが重要な役割を果たす。
☆データモデルに対するイメージ
改めて、聞きたい。データモデルに対して読者はどのようなイメージをお持ちだろうか。
またDOAとか小難しいやつだろ、
少し前に流行ったよね、
でも今時どうなの
概念とか論理とか物理とか、訳わからん、
データモデルとかDOAでやるとガチガチのシステムができそう、
データモデルなんて今更書くこと自体が時代遅れ、
一昔前に開発時に強制的にやらされて酷い目にあった、トラウマはなかなか消えない、
という人もいる。
かたや、データモデルをしっかり書いたことにより関わったシステム開発は失敗したことがない、という人もいる。
ただ、一つはっきりしておきたい。上記は全てDOCA(前回参照のこと）の話である、と。
従来からある開発、設計手法としてのDOA(データ中心設計）なのである。
別にデータモデル書いたりDOAでやらなくても成功したシステムはたくさんある。それ以外の手法でも成功するノウハウをお持ちの方もいることだろう。書きたくなければデータモデルを今更書かなくていい。嫌々やっても、無理やりやらせてもうまくいかない。
DOCAをやるかどうかは、プロジェクトの性質、メンバーのスキル等を考慮して決めていけばいい。他にも良い方法論はたくさんある。得意なやり方でやればいい。
今やるべきはDOCAではなくDOBAであり、書くべきはビジネス地図としての概念データモデルである。
☆DOBAにおける概念データモデルの書き方
図9 概念データモデル例
ビジネス地図としての概念データモデルでは、実体と呼ばれるエンティティという「箱」（上記の図であれば「学校」「学生」「応募書類」）と、実体同士の関係を表すリレーションシップという矢印付きの線（上記の図であれば「学校」と「学生」の間にひかれた線、「学生」と「応募書類」の間にひかれた線）で表現する。エンティティの名称、リレーションシップの定義はきちんと日本語で表記する。
上の図であれば
・「学校」は「学生」を「在籍させる」
・「学生」は「応募書類」を「提出する」
（線の元エンティティ：主語）は（線の先エンティティ：目的語）を（矢印線：述語）する、という表記になる。ビジネスのあり方を示す以上、すべてを日本語でわかりやすく記述することだ。この繰り返しでモデルが出来上がる。
ビジネス地図はDOBAにおいてビジネス創出とほぼ同時にビジネス地図として作成するものの、書き方、記法については従来のデータモデル、ER図と同じでも構わない。
以下、作成時の留意点を挙げておこう。
・前述した通りエンティティ（実体）という「箱」をリレーションシップ（関係）という「線」で結んで表現する。
・日本語表記は必須。
・属性は後回しで構わない。
・エンティティ名、属性等は把握したら用語集に登録する。
・明らかになったビジネスルールはルール集に記載する。
・全体から一部切り出し（下図参照）て、一つ一つ定義していってもよい。
図10 データモデルを一部切り出して関係を確認
・わかりやすさ優先で記述する。過度な抽象化はおこなわない
(関わるメンバーが理解可能なレベルに合わせる）
・リソース（マスターになりうるもの）のあり方、外部連携（主にデータ連携）はきちんと把握しておく。
こんなところだろうか。これだけできればビジネス地図としての概念データモデルとしては上出来だ。
☆最後に
DXでどうしてよいかわからず焦っている人へ
データをかき集られるだけ集めたけどどうしていいかわからない人へ、
もちろん基幹系システム再構築（ERP,SaaSサービス切り替え含む）しなければならない人へ
複数のサービスを組み合わせてシステム構築しなくてはいけない人へ
データの洪水におぼれそうであれば、全社を対象に
DX実現であればビジネス創造とともに
全てDOBAをやって解決しないか？ そしてビジネス地図としての概念データモデルを書いてみないか？
この記事が気に入ったらサポートをしてみませんか？