将来に続く「理想のデータモデル」を作るため、組織の知見を集約させよ：真に「データ中心の製造DX」を実現するには（3）（3/3 ページ）

[武井晋介, 山内一平／クニエ，MONOist]

• ステップ3：ユースケース検証
  　ステップ2では、業務機能単位で概念データモデルを作っている。個々の業務機能で見ると、これまでの業務改革やシステム改革のアプローチと同じで、概念データモデルを作る目的としては不十分だ。ステップ3のユースケース検証を通じて、業務機能を横断した概念データモデルに作り上げていく。
  　ユースケースは、顧客提供価値の向上や経営戦略で実現したいことを具体的なデータ活用シーンとして作る。バリューチェーンの多くの業務機能を横断するようなケースを複数個作成することが望ましい。作成に当たっては、経営層の要求や業務部門の知見が不可欠だ。ユースケース作成の過程で、業務部門の困りごとが明確になることも多く、それらが解決した姿をユースケースとすることで、今後の改革における業務部門の参画を促進しやすい。
  　ある企業ではユースケースとして、「顧客の需要変化に最速で対応するために、国や地域、グループ会社をまたいだサプライチェーン全体でのPSI（生産、販売計画、在庫）対応」や「部品物流／製造／製品物流におけるグリーン対応観点でのトレーサビリティー」「開発構想段階から海外の部品メーカーを巻き込んだバーチャルコンカレント開発とAIによる原価精査」などが作成された。
  　作成したユースケースに対して、ステップ2で作成した概念データモデルドラフト版の各データが発生、編集、活用されていく様を可視化し、概念データモデルドラフトを更新する。特に意識すべきはデータグループをつないでいるキーデータである。例えば商品コードや拠点番号、社員番号などが該当するが、これらのデータは業務領域内だけではなく業務領域間をつなぐ役割を果たす。（例えば商品コードは設計領域で生まれ、各種計画時に用いられるとともに、生産、販売などでも用いられる。）ステップ3は、ユースケース検証を通じた概念データモデルの初版の作成で完了となる。

図3：概念データモデル（バリューチェーン全体のうち一部分を記載）［クリックして拡大］ 出所：クニエ

　なお、ここまではユースケースの机上検証として述べた。しかし、机上検証では検討参加者、特にITに精通していないメンバーは概念データモデルの重要性、今後の運用イメージを持つことが難しい場合が多い。その状態でユースケース検証を進めていくと活動後半で検証の速度、精度が落ちることが懸念される。そういった状況に陥ることを防ぐためには、ETL（Extract：データの抽出、Transform：変換、Load：格納）ツールやBI（Business Intelligence）ツールを用い、PoC（概念実証）を行うのが有効である。

　例えば、ユースケースとして「各拠点の製品出荷の予実状況を監視し、予実差異が大きい拠点が発生した場合はアラートを出す」といったシーンを想定しよう。BIツールを用いて将来の実業務に近い環境で検証すると、ITに精通していないメンバーでも「予実差異は日次で監視していくべき」「生産計画情報とひも付ければ差異が実際に発生する前にアラートを出せる」など具体的なイメージを持ちやすい。これによって、効果的な概念データモデルの作成につなげられる。

　概念データモデルは、現状業務やITシステムを変えることなく効果を検証でき、PoCを実施しやすい。メンバーが議論であまり意見を出さない、などの状況に陥った際は、BIツールなどを用いたPoCを検討してほしい。

概念データモデルの維持管理

　前述した通り、概念データモデルは企業が目指すべきデータの流れをバリューチェーン全体で表したものになっているはずである。この特性を生かし、概念データモデルは業務改革やシステム改革の時に参照しながら、ガバナンスをかけるための憲法として、組織の中で継続的に活用していくことを想定している。よって、データモデルの陳腐化を防ぐことが重要だ。社内外の環境の変化によって目指す将来像や技術がアップデートされたり、必要なデータが変わったりした際にはメンテナンスが必要となる。

　継続的な維持管理を行うためには、メンテナンスのプロセスと役割を定めることが重要だ。概念データモデルのメンテナンスのプロセスは作成の手順と似ているため、ここではメンテナンスの役割について言及する。

　体制構築で述べたように、概念データモデル作成時はさまざまな人材が必要となるため、各部門から人材を集めたプロジェクトとして体制を構築することが多い。プロジェクト終了後は経営企画部門やDX部門、システム部門など、既存の各部門がメンテナンスの役割を担うことが多い。作成時はプロジェクトとして協働していても、終了後には部門間の連携が弱くなりがちだ。また、これらの部門に改編があると概念データモデルのメンテナンスという役割が宙に浮いてしまい、データモデルが陳腐化してしまうとともに、概念データモデルを作成した背景や意図が失われてしまうこともあり得る。

　これらの状況を防ぐため、従来の会社や部門の枠に捉われない、永続的な活動が必要だ。実際のデータの品質がデータモデルで想定したものになっているか、ルールが定められ、それに基づき運用されているかなどチェックし、社内にガバナンスを効かせる役割が求められる。この実現の一例としては、プロジェクト完了後に「データ管理委員会」といった組織横断のグループを立ち上げ、継続的に必要な人材を招集する手だてが考えられる。

おわりに

　第1回から第3回までは自社内での活用を前提として、概念データモデルを紹介してきた。第4回（最終回）では、自社での活用の先を見据え、企業間や業界／業種間のデータ連携の基準化などデータエコシステムとの関連について紹介する。

⇒本連載の目次はこちら
⇒記事のご感想はこちらから

武井晋介（たけい しんすけ）
株式会社クニエ データモデリング・データマネジメント改革担当 ディレクター

完成車メーカーにて新製品開発PMOに従事。その後、外資系マーケティングリサーチ会社に転身し、自動車業界を中心としたリサーチ企画／データ分析を担当する。外資系小売業においてプライシング戦略の立案と実行、デジタルトランスフォーメーションを推進。クニエでは、加工／組み立て系製造業において、バリューチェーンのデータ改革／業務改革／システム導入や事業統合、新事業企画、生産現場改善などに携わる。

山内一平（やまうち いっぺい）
株式会社クニエ データモデリング・データマネジメント改革担当 マネージャー

大手重工メーカーを経てクニエに入社。家電、建設機器など組み立て系製造業、化学、塗料などプロセス系製造業などに精通し、SCM、ECM領域の業務改革、データモデル構築、海外企業との業務統合、DXを企画から実現へ向けた計画策定、施策実施／定着、経営管理基盤の構想策定の支援など多数のプロジェクトをリードする。