1. DX、データドリブンな経営、データ改革の実情を振り返る

筆者らは、特に組立加工型製造業における業務改革、現場改善、システム導入を中心にコンサルティングサービスを提供している。その中で、最近はやはり、「DXやデータドリブン経営、データ改革」といった言葉を多く聞くようになった。
 
このような活動を通じて、たびたびお客さまと議論になるのは「DX、データドリブン経営、データ改革とは、どういうことが効果として得られた状態なのか？」ということである。用語に統一した定義がなく、立場や人によって考え方が異なるケースが多いようだ。デジタイゼーション、デジタライゼーション、デジタルトランスフォーメーションなど、DXの成熟度合いが細分化され、多くの企業がDXを推進していると感じることは多い一方で、帳票のデジタル化、エクセルのシステム化などに留まってしまう企業も多いのではないだろうか。
 
筆者らがコンサルティングを通じて、改めて実感することが多いのは、DXの肝になるのはデータということだ。「そんなの当たり前だよ」というお𠮟りを受けそうだが、実際の現場ではデータ検討が後回しになっていると感じることが多々ある。DX案件や、モダナイゼーション案件などの機会に触れると、お客さまも私たちも「データを中心に据えた改革」という共通理解は持つものの、実際の検討になるとデータが後回しになっていることが多いのも事実である。

2. 重要なはずのデータ検討が後回しにされている実態

DXやモダナイゼーションを企画・推進する際は、多くの場合、業務改革やシステム刷新がセットになる。その際によく用いられる考え方にEnterprise Architecture（EA）がある。EAは、業務層（Business Architecture：BA）、データ層（Data Architecture：DA）、アプリケーション層（Application Architecture：AA）、テクノロジー層（Technology Architecture：TA）に分けて、業務からシステムまでの要件や改革ポイントを整理していく考え方である。

中でも、業務要件を決めてからシステム要件を決めるアプローチは、Fit & Gapと呼ばれ、以下のような流れで進める。

1. 自社業務のありたい姿を決めて、それと現状業務の差を明らかにし、業務改革ポイントを決める（BA）
2. 1に対し、必要なデータが決まる（DA）
3. 2のデータを収集・処理・活用するためのシステム機能が決まる（AA）
4. システム機能を実現する具体的なシステムが決まる（TA）

また、Fit to Standardという考え方もあり、この場合は以下のように逆の流れのアプローチとなる。

1. 具体的なシステム（多くの場合既製システム（パッケージシステム））を決める（TA）
2. そのシステムで実現できるシステム機能（AA）とそのシステム機能で扱っているデータが明確になる（DA）
3. そのデータを登録・活用するように業務を変える（BA）

Fit & Gapが、自社のありたい姿と現実との差の解消に着目しているのに対して、Fit to Standardは既製システムをそのまま活用して業務を行うことを目指している。
どちらも業務改革・システム改革の手段の1つだが、注目すべきはDAの位置付けである。どちらのアプローチを採用しても、データは従属的に決まることになっている。データを中心に据えた改革のはずなのに、データが従属的に決まるということに違和感がないだろうか。

図1：データ起点のEnterprise Architecture

そこで、筆者らは文字通り「データを中心に据えた改革」を実現できるように、「概念データモデル」という考え方を推奨している。

3. 概念データモデルとは

概念データモデルは、その中に「概念」という言葉があるだけあって抽象的で理解しづらい考えではある。そこで、システム導入時に作られるデータモデル「論理データモデル」と対比して整理したい。

図2：概念データモデル・論理データモデル・物理データモデルの比較

論理データモデルは、「システムを設計・開発するために必要なデータに関する要件が記載されたモデル」と理解するとわかりやすい。業務要件が決まったあとに作成するもので、それを実現するデータテーブル（エンティティということもある）やテーブル内の個々のデータ項目、データ項目の構造が記載される。データ項目の構造とは、例えば、そのデータ項目は選択肢型か、数値型か、文字型かといった内容や、文字型なら何文字まで入力可能か、選択肢型であれば初期値は何が記載されているか、などが該当する。論理データモデルはシステムを作るためのデータの設計書である。

繰り返しになるが、論理データモデルは、業務要件が決まった後に作られるものだ。言い換えると業務を検討した範囲しか作られないということになる。例えば、製品設計領域の業務要件が決まれば、その範囲の論理データモデルが作られる。仮にここで、製品設計、調達、生産の業務要件が別の時期に個々に決まってしまうと、それぞれに応じた論理データモデルが作成され、そこにはデータ項目の矛盾、ズレ、重複などが往々にして発生する。それを回避するためにMDMやデータマネジメントが着目されているわけだが、それぞれが決まったあとのため、解消には困難を伴う。

一方、概念データモデルは個々の業務改革やモダナイゼーションに着手する前に作成するデータモデルである。特定の業務領域だけでなく、製造業のバリューチェーン全体をモデルとして表現する。論理データモデルのような厳密さは不要で、関連するデータをグループ化したデータ群と、そのキー項目（全てのデータ項目は不要）、データ群のつながりを示す。業務要件やシステム要件を検討する前段階で作るため、経営戦略や将来動向などを踏まえモデル化していく。また、中長期的な内部要因・外部要因の変化に対応できるようなデータ構造を模索しながら作っていく。この概念データモデルを利用して、個々の業務改革やシステムモダナイゼーションを推進すると、データを起点、かつガバナンスを土台とした活動が可能になる。バリューチェーン全体を俯瞰した概念データモデルがあるからこそ、企業全体の改革に一本の芯が通ることになるのだ。あるお客さまは、概念データモデルのことを“自社の憲法”と表現されていたが、まさにその通りである。

ここで、筆者らが作った概念データモデルを紹介したい（図3）。ご覧いただくとわかる通り、概念と言いながらも非常に細かい内容になっている。製造業のバリューチェーン全体をモデル化しているため、データ群だけでこの図のようになる。

図3：概念データモデルで扱うデータ群の実例

図4：概念データモデルで扱うデータ群とデータ項目の抜粋

この概念データモデルには、例えば「支給品管理」のような以前からある業務に関するデータもあれば、温室効果ガスの排出量や人権、紛争鉱物などのトレーサビリティといった今後重要度が高まるであろうデータや、メタバースやブロックチェーンといったトレンドのIT技術などの観点を盛り込む必要がある。
 
そして、もっとも大切なことは経営者の想いや経営戦略といった観点を入れることだ。現状の業務要件やシステム要件を表現するだけでなく、経営の意思決定に必要となるデータや、長期的な自社の将来像や社会を意識しながらモデル化に取り組むことが肝要である。これらが入っているからこそ、それぞれの改革に対して“自社の憲法”になることができる。

4. 概念データモデルの効果・活用方法

ここで、概念データモデルが効果を発揮するシーンを3つ挙げる。

1つ目は、経営環境や業務・ITが変化したシーンだ。例えば、M&Aでは買収か統合か、自社が主となるか、従となるかによらず、複数の企業のデータを1つにする、あるいはつながるようにする必要がある。その時に概念データモデルがあると、新しいデータと既存のデータの接続を容易に検討できる。自社から一部の事業がM&A先に譲渡されるような場合でも、概念データモデルがあると切り出す範囲を特定しやすい。概念データモデルは、経営環境の変化や業務・ITの変化に応じてデータを着脱させやすいという特徴を持つ。
このデータの着脱性という特徴が効果を発揮するのはM&Aに限った話ではない。業務改革やIT改革を通じて、データを登録・活用するシステムを変えるような場合にも効果を発揮する。例えばこれまでERP（ヒト・モノ・カネ）で管理していた「取引先（ここでは部品や原材料の発注先とする）」データを、コンカレント開発^＊によってPLM（製品のライフサイクル）での管理に改革したいような場合だ。それぞれが個別に検討していては上手くデータが接続しない恐れがある。しかし、あらかじめ概念データモデルで、「取引先」データを明確にしておけば、ERPかPLMか、量産中かコンカレント開発かを問わず、同じ考え方でデータを登録・活用することが容易になる。
＊コンカレント開発：設計、生産、調達などの複数の工程を同時進行させ、開発リードタイム短縮・効率化する手法のこと
 
2つ目の活用シーンとしては、バリューチェーン全体を俯瞰した業務改革やシステム改革がある。概念データモデルは作成範囲がバリューチェーン全体におよぶことから、特定の業務部門やシステム部門では作りづらく、データ管理部門が作成することが多い。データ管理部門はこの概念データモデルを持って、個別の業務改革やシステム改革に関わっていくことになる。例えば、業務部門によって新しい業務機能や業務フローが作られたときに、新業務を通じて概念データモデルのどのデータが作成・活用されるかを明らかにし、バリューチェーン全体の中でデータがサイロ化しないように業務部門に働きかける。複数事業やグループ会社間でのデータのやり取りが多い企業では、商品番号や部品番号、個体識別番号などと、それらの接続関係を個々の改革の前に決めることで、統一された考え方に基づいたデータ改革が実現できる。このアクションを通じて、経営者が意思決定に必要なデータがグループ企業間、事業間で分断されず接続可能な状態を作ることができる。
 
3つ目のシーンは、若手人財の教育である。概念データモデルは、バリューチェーン全体を俯瞰したデータモデルだ。よって、製造業がどのようにして経営されているかをデータで追体験することが可能になる。もちろん、詳細な知識やスキルを身につけられるわけではないが、全体のつながりの“あるべき姿”を捉えることができる。本稿読者は、製造業の方やデータに関心が高い方が多いと想像しているが、自社でバリューチェーン全体をデータで語れる人財はいるだろうか。また、そのような人財を抜きにしてDX・データドリブン経営・モダナイゼーション・データマネジメントが可能だろうか。ぜひ一度、自社をデータで表現してみてほしい。

私たちは、これらの観点は厳密な記述が求められる論理データモデルでは実現しづらく、個々の改革の前に概念データモデルを作ることが重要な例と考えている。

5. データ規格化の動向と概念データモデル

データモデルを語る上では、数年前から注目されている規格化との関係を整理する必要がある。特に欧州発で規格化の動きがあり、企業間のデータ連携を狙ったGAIA-Xやその1プロジェクトである自動車業界のCatena-X、システムベンダー製品間のデータ交換を狙ったOPC-UAなどがある。

これらと概念データモデルの違いは、目的と対象としているデータの詳細さにある。概念データモデルは自社のデータモデルであるのに対して、規格は企業横断的な標準である。この標準に完全に準拠する形で自社の経営・業務を遂行できれば良いのだが、おそらくは難しいと思われる。それができるくらいなら、Fit to Standard型の改革が上手くいき、自社のシステムはカスタマイズゼロの完全パッケージ製品だけで成り立つからだ。カスタマイズ、マイクロサービス、System of Engagement、System of Record、System of Insightいう考え方が発生したことがそれを物語っている。したがって重要になるのは、業務やシステムだけではなくデータの世界においても、世の中の標準がどうかの前に、自社のあるべき姿・ありたい姿が何か、それに対して標準はどうなっているか、どこを標準と合わせてどこを自社固有にするかであると言える。

おわりに

今後、業務（BA）やシステム（TA）の重要性は相対的に低くなり、代わってデータ（DA）が重要になるだろう。
業務に関しては、自動化・AI化の流れは避けられない。どの業務を自動化・AI化するか、それによってどのような効果を期待するかなどの議論はあるが、この流れ自体は不可避と考える。これまで人が担っていた業務の多くは自動化・AI化され、人に求められるのはそれらをどのように企画・実現し、維持・更新していくかになる。当然ながら、必要になる知識・スキルは変わってくる。そのために重要となる１つが、自社をデータで俯瞰できることと考えている。自動化やAI化の技術的な知識やスキルは外部に求めることが可能だが、自社がどう成り立っているかは、自社の人財でないと把握できない。
 
また、システムについては、今後ますます技術革新のスピードが速くなり、ベンダー製品間の連携も進むと思われる。そのため、業務と同様システムも相対的な重要度は低くなり、必要な機能を内部・外部の環境変化にクイックに対応できる瞬発力が必要になると思われる。疎結合の考え方と言ってしまえばそれまでだが、システム機能を着脱可能な単位に分割して考えることがますます重要になり、それに対応してデータ・業務の着脱性も求められる。
 
これらに対応した考え方が概念データモデルだ。論理データモデルや物理データモデルと比較して、抽象度が高いため理解しづらい考え方ではある。しかし自社の成り立ちをデータで表現し、経営戦略や世の中の変化をデータモデルに取り込むという考え方は、業務やシステムが細分化され、それぞれが爆発的なスピードで変化する環境下において有効なアプローチであると考えている。