投稿者: 一倉 徹

ここ最近、データの大事さを認識する企業が増えてきているように感じます。データはDXを支える基本であるということも共通認識として定着してきているようです。また、データの民主化という言葉も、ちょっとした流行語（バズワードとも言う）になっているようです。しかし、その実践となるとかなり心もとない企業が多いのではないでしょうか。

ここでデータの話から、スーパーで売っている食料品と、それを使って作る料理の話に飛びます。私、料理はけっこう好きで、また、自分では料理得意と思っているのですが、料理と素材、データ分析とデータの対比で考えると共通点が多いように思います。

料理は、レシピ、素材が良いこと、コストもまた大事で、そのバランスが大事かと思います。でも、素材そのものが悪いとどうにもならないですし、また、調理しにくいものは結局は使わなくなってしまいます。

しかし、スーパーで以下のような状態で品物を売っていたら、どう思いますか？時間・手間暇がかかるものも含めて、あまり買いたくないケースを列挙してみました。

• 肉や魚の賞味期限、消費期限が不明（これは実際にはないと思いますが、ここでは仮に不明な場合を想定してください）
• お肉が何グラム入っているのかわからない（まあ、実際はお肉はグラム表示はありますが魚はないことがほとんどですね）
• 産地が不明（これは多いと思いますし、産地偽造とかもあります）
• 珍しそうな品物だが、初めて聞く名前で、どんな風に食べるのが美味しいのか不明（気の利いたお店では、調理方法の提案があったりしますが）
• 同じ野菜が、別々のコーナーで売っている。値段も少し違うようだが、違いがわからない
• 大きすぎる、多すぎる（まあ、ボリュームディスカウントがすごいコストコとかは値段に免じて許します）
• 泥がついたまま（これはこれで鮮度が保たれて良い場合もありますが、私はちょっと面倒に感じることが多いです）
• 魚など、下ごしらえに手間がかかるもの（お魚を３枚におろすとかですね、私、鰺ぐらいなら自分でやりますが、時間に余裕がないとやりたくないかな）

また、手抜きかもしれませんが、以下のような食材は便利ではあります。

• カット済の野菜（冷凍食品のカット野菜も含む）
• そのまま食卓にだせそうなお刺身（本当は柵のままのほうが鮮度良いけど、切れる包丁と技が必要）

楽さを追求すると（ほぼ料理不要なレベル）

• 味付け済のお肉
• 冷凍食品

データ分析で、お惣菜や冷凍食品にあたるのは定型レポート、カット済の野菜や素材の冷凍食品にあたるのは特定目的別のデータマートに例えられるかなと思います。ただ、最も基本となる素材の格納庫にあたるデータウェアハウスは、なかなか理想的な状態になっていないことが多いのでは。以下のようになっていませんか？

• 各業務システムからデータを、そのまま集めただけ。データタイプや桁数、単位が不統一なため、データの集計や比較を行うためには、まず、データを整えることから始めなくてはならない。これではタイムリーな分析もできないし、分析の都度、データを整えるというのは作業が繰り返し必要になる。
• コード体系が意味ありコードで、各桁の値によって分類が異なる。また、ある桁の値によって、他の桁の使い方が異なっているので、単純に分類できない。
• マスターデータが重複しているため、集計自体が困難である。顧客別売上とか、基本中の基本ですが、それが簡単にできなくなってしまいますね。
• 集計データしか格納されていないため、より、細かい単位でデータを分析しようとしても不可能である。明細からサマリーは作れますが、その逆は無理ですね。
• データを格納するタイミングがばらばらで、しかも、時点情報を持っていないために、期間や時点を基準とした集計を正確に行えない。
• データの項目名に、異音同義語や同音異義語があるため、どの項目を分析対象とすればよいのかわからない。特に事業部制の会社、合併会社では、これはあるあるでは。
• データの項目名だけでは、意味・内容がわかないため、社内で知っていそうな人に聞いて回わらないといけない。これが存在意義になっているベテラン社員とかもいたりします。

ちょっと乱暴ですが、データの素材を品質保証もぜず、ただ、データベースに格納するだけでは、それを使う人のことを考えていないと言われても仕方ないでしょう。また、特定目的のレポート用にデータを集約したものだけを格納するのは、それ以外の用途に使えません。データウェアハウスを提供するということは、データをきちんと商品として販売するのだという意識が不可欠です。

もう一つ大事なのは、データの使い方をある程度、予測するることです。スーパーで珍しい野菜や魚を売るときは、調理方法も提案することに似ています。さらにデータを商品化するということはコストも時間もかかります。手あたり次第に商品化しようとしては、売れない商品を生み出すことになります。経営者、データサイエンティストと同じ目線で商品化の範囲を考えましょう。つまり、何を分析し、その結果をどう活かすかということです。販売分析であれば、

• 顧客の分類（これは年齢、性別、居住地、所得、職業・・・・多様な分類ができるので複数軸があります）
• 商品の分類（これも多様な分類ができるので複数軸があります）、商品間の相関関係
• 時点（いつ売れたのかなど）
• チャネル（どの販売経路で売れたのか）
• どこで売れたのか
• いくらで売れたのか

といったこと。その組み合わせとなります。分析軸と対象を5W1Hで考えるのも一考です。

また、データの民主化は、商品に産地、鮮度、意味定義といった情報（データに関するデータなので、メタデータといも言います）をきちんと提供することなしには実現できません。民主化のもう１つのポイントは、このメタデータを提供するのは一般市民でもよいということです。社内でWIKIを立ち上げている会社もありますが、これは民主化を加速する素晴らしい取り組みだと思います。

デジタル庁については，期待もあり，また，人材募集や組織図を見ていて，不安も覚えるというのが正直なところである。今回は，かつての特許庁のような大惨事に陥ることなく仕切り直しとなったことは評価する向きもあるが，それでも，中断に至った原因を分析し，その対応策が取れなければ再び失敗を繰り返すことになる。

公開された情報からは，事業所の定義ができないが，それだけではないといった曖昧な情報であったが，今は少し落ち着いて原因分析した日経XTECHの記事も出てきた。

事業所データ整備を中断したデジタル庁、「撤退」の次こそDX司令塔の真価が決まる

https://xtech.nikkei.com/atcl/nxt/column/18/00138/051801041/

この記事では，事業中断の原因として，事業所という言葉の概念が複雑かつ多岐にわたり，また，監督官庁も異なることをあげている。これは実際，その通りだろう。なので，そもそも事業所は何を指す概念かを定義しないといけない。

日経XTECHの記事では，ユースケースを限定し，目的を絞ってデータ整備したらどうかとあるが，これを安易にやってしまうと，また，新たな標準が１つ増え，データの体系化がさらに困難になるだろう。データを目的別に整理するのはデータモデルのアンチパターンである。全体を捉えたうえで，部分を定義しないとデータは体系化されない。全体は部分の寄せ集めではない。ユースケースで検証することは最低限必要なことだが，選択したユースケースが全体の構造を決めるうえで適切である保証はない。日経XTECHの記事は（日経さんなので期待も込めて書くが），掘り下げが浅すぎる。

では，これはどのように進められてきたのだろうか。ネットで検索すると，「ベース・レジストリの 検討状況について」という資料が公開されていた。

https://www.digitalservice.metro.tokyo.lg.jp/society5.0/pdf/211020_04.pdf

一般論としては良く書かれているが，気になったのは最後のページである。

2021年度に「調査研究・パイロット」，「首都圏等自治体と共働」とあるが，TOBEデータモデルを検討しているようには読み取れない。「調査研究・パイロット」で検討しているのかもしれないが，パイロットという単語からは，プロトタイプ・システムで検証するといったことを想定しているようにも見受けられる。

日経XTECHの記事では，多岐にわたる事業所，それを管轄するそれぞれの官庁，自治体ごとの違いが挙げられているので，まずは法人と紐づけし，事業所を整理構造化し（サブタイプ化），ステークホルダーを整理し，場合によっては，その官庁権限を変更し（これができないとデジタル庁は，単なるボトムアップ方式しかできなくなる，ただ，このもとになるのはTOBEデータモデルがあってこそ），TOBE/ASIS変換の仕組みを作成しないと，再び，同じ轍を踏むことになる。 実際のところは，さらにドロドロとした状況であるのかもしれないが，日本が前に進むためには乗り越えなくといけない道である。また、次回は，優秀なデータモデラー，データアーキテクトを，RFP以前に参画させることを願っています 。

コロナでの日本（あえて日本政府でなく、日本と書きました）の対応で一番情けないのは、政府や地方自治体でデータが寸断され、必要な情報を得るのに時間がかかる、いや時間がかかっても正確な情報が得られないことです。様々な原因があって、いまだにFAXを使っていることや、ワクチン接種記録システム（VRS）への入力が大変で、遅れ気味の自治体が多いとか、これがOCR入力とか・・・・

もちろん、こうした状況になってしまった原因は、技術的なことよりも、政治であったり、古い仕組みを脱却できない人間に起因することの方が大きいと思います。ただ、これに似たような状況に陥っている企業も多いのではないかと思います。

国民背番号についての是非はともかくとして、管理したい対象については、ユニークに識別できるキーを振りたいわけですが、日本の場合、マイナンバー、住基ネット番号、保険証番号、年金番号、運転免許証番号、パスポート番号といったものが乱立しているわけです。パスポート番号や運転免許証番号は、必ずしも国民１人１人が持つキーではありませんが、これにより個人を識別していることが多いかと思います。

しかし、住基ネット番号は、そもそもマイナンバーがあれば不要、年金番号もマイナンバーへ統合可能でしょう。 保険証番号もマイナンバーで置き換え可能でしょう。 運転免許証番号で個人を識別する役割は終わらせることができるはずです（そのために高齢者が免許返上しにくいとかは馬鹿げています）。

用途ごとにキーを振るのではなく、管理対象に対してキーを振るという、データ管理であれば、当たり前のことができていないがために、多くの情報寸断が起き、集計に人手が必要となり、人手を介するがゆえにミスも生じてデータが不正確になる。これが国や地方自治体の効率性を妨げているわけです。ワクチン接種記録の入力に時間がかかったり、感染者の集計が遅れたり、漏れたりとかは、適切に設計されたデータモデルと、それに基づいて設計されたシステムがあれば起きなかったはず。

マイナンバーが住基ネットの番号に基づいて振られる、チェックディジットの不完全性のため入力ミスを100％防止できないなど、（相対的に小さな）問題点もありますが、大きくはマイナンバー自体をまず将来的（ＴＯＢＥ）に、これに統一していくというビジョンを定め、それを妨げる障害を１つ１つ除き、なりすましや情報漏洩を防ぐセキュリティ、管理されている情報のオプトイン、オプトアウトなどを整備し、徐々に適用範囲を広げていくことが重要なのではないかと思います。マイナンバーカードを作ることのメリットを訴求するのはマイナポイントではなくビジョンであるべきです。

企業のシステムでも、新旧のコード体系混在や、目的別に振ったIDなど、実は同様の問題を抱えていることが多いようです（特に歴史ある大企業）。まずはTOBEをきちんと定め、データ管理をもう一度見直していくべきです。

大規模なデータモデリングを行う場合，データモデルをいくつかに分割して作成するのが一般的である。この部分図を，データモデリングツールではサブジェクトエリア（ERwin），あるいはサブモデル（ER/Studio）と呼んでいる。以下，このBlogではサブジェクトエリアという用語を使用する。

データモデリング分科会で，このサブジェクトエリアはどういった単位で作成すべきか，あるいは，その単位には理論的な裏付けがあるのだろうかという問題提起があり，これについて分科会でディスカッションを行った。

大規模システムの設計・開発では，いくつかのサブシステムに分割し，それぞれのサブシステムごとに設計・開発が行われるのが普通だが，大規模データモデルも同様に分割してモデリングすることが妥当と思われる。しかし，時々，模造紙を何枚も張り合わせた，ものすごく巨大なデータモデルを見ることがある。さぞかし，維持管理が大変だろうと思われるが，分割したら分割されたサブジェクトエリア間の関連がわかりにくくなるという問題もあるのか、あるいはサブジェクトエリアにデータモデルを分割するという概念に馴染みがないのかもしれない。

問題提起された課題は以下が代表的なものである。
１　サブジェクトエリアび分割の基準や理論的裏付けはあるのか？
２　サブジェクトエリアに書かれるエンティティ数はどのくらいが妥当か？
３　サブジェクトエリア間で，重複して描かれるエンティティがあっても良いのか？それとも，サブジェクトエリア間でエンティティは排他であるべきか？

まず，サブジェクトエリアの分割基準についてだが，理論的裏付けは難しいものの，ベスト・プラクティス，あるいはリファレンスとなるべきモデルはありそうである。残念ながら日本語訳は出ていないが，アメリカのデータモデラーであれば，まず絶対に読んでいるData Model Resource Book（L. Silverston）のVol.1では，
People and Organization
Products
Ordering Products
Shipments
Work Effort
Invoicing
Accounting and Budgeting
Human Resources
といったサブジェクトをあげている。サブジェクトエリアを考えるうえで，かなり拠り所になるかと思う。ちなみにアメリカでは業界団体，あるいはIBMやOracle，テラデータといったベンダーが提供しているデータモデルも，これに類似したサブジェクトエリアを設定している。理論的裏付けはともかく，かなり類似しているように感じている。これらのサブジェクトエリアは，図書分類に似ているという指摘もあった。分割範囲が大分類から細分化していく点も図書分類に類似している。

次にサブジェクトエリア単位のエンティティ数について。これは分科会で数10から，最大100以下といった経験を共有できた。数はけっこうバラつきが多いが，これはどこまでサブタイプを設定するかにもよるかと思う。あまりにも多い場合はさらに細分化した単位にサブジェクトエリアを分割するほうが良いだろう。

サブジェクトエリア間でエンティティが重複して良いのかについて。サブジェクトエリアを図書分類のように考えると，１つのエンティティが複数のサブジェクトエリアに所属するということはあり得ない。しかし，厳密に重複なしとすると，いろいろと支障が出てしまう。例えば，製品の担当者の関連，製品と売上の関連といったものは，図書分類的なサブジェクトエリアでは表現できない。こうした関連を表すためのアプローチの１つとしては，あるサブジェクトエリアのデータモデル図に，そこに属するエンティティと関連がある周辺サブジェクトエリアのエンティティも参考として書き加えるというテクニックがある。みもう１つは業務視点（たとえば受注業務）でデータモデル図を作成することである。これを組み合わせるとサブジェクトエリアを縦軸と横軸で表すことになり，ビジネスルール等をデータモデルで表現することができる。（全てのビジネスルールではないが，データ構造で表現できるビジネスルール），ただ，この縦軸・横軸の組み合わせをサブジェクトエリアとして考えるべきではという問いかけもあった。

参考となるサブジェクトエリアを，それぞれの企業にあてはめ，そこに独自部分をモデリングしていくと，出来上がるデータモデルの品質やモデリングにかかる時間の点で大きなメリットがあると信じている。このテーマについては今後もより具体的、実践的に議論を深めていきたいと考えており，データモデリング分科会では再度，取り上げていきたいテーマである。

データ管理は何のためにやるのでしょうか？
企業であれば，競争に打ち勝つため，極論をいうと生き抜くためのマネジメントの一環だと私は思っています。

であれば，データに携わる我々はもっと経営について関心をもつべきかと思います。ということで，今年のお正月は、復刻版の「マネジメントへの挑戦（一倉定）」を読んでみました。私にとっては遠縁かつ高校（旧制中学）の先輩にあたる方ですが，これまで著作は読んだことはなく，名前のみ知っていました。

基本的に読みやすい本なのですが，目から鱗の個所が多々あり，今年はいいスタートが切れた感じです。その中で，いくつか内容を紹介したいと思います。

① バランスのとれた組織ではダメ
「すぐれた会社，成長する企業は，組織面だけでなく，いろいろな面でつねにバランスをやぶって前進している。アンバランスが成長途次の姿なのである。」

組織のアンバランスさを大事にする，組織がどんどん変化する。こうしたことに情報システムはポジティブに反応できていないのではないか。組織変更するとシステム改修が発生して大変とか，時間がかかるとかはよく聞く話ですよね。要件定義の要素として可変性分析がありますが，組織については可変であるという前提で，データモデリングしておきたいところです。

② 二つの原価計算
全部原価計算と直接原価計算
すごく乱暴な言い方をすると，全部原価計算とは，間接費も案分・配賦して製品ごとの原価を算出する財務会計としての原価，直接原価計算は直接費と間接費に分けて管理する管理会計としての原価

本書では，どの製品を捨て，どの製品を伸ばしていくかは直接原価計算でなければ判定できないということを主張しているわけです。詳細は省きますが，全部原価計算の場合，配賦ということが経営判断を誤らせる元凶ではないかと思います。

企業が大きく，複雑になってくると，この配賦コストの仕組みも複雑になり，これを取り去った直接費を取り出して分析することが困難になってきます。これは，情報システムが全てのデータを最小粒度で保持していれば，直接費と間接費を分離できるかもしれませんが，事業部門，子会社，関連会社を通して原価を正しく分析しようとしても，データフローの途中でデータが合算され分離できなくなっているケースが多々あります。トランザクションデータを加工前の状態で保持していれば，集計軸を変えれば良いだけですが，合算されてしまうとどうにもなりません。

他にも企業レベルで情報システムとそのデータモデルを考えるうえで，多くの示唆を得られる個所が多々あります。機会あれば，他の個所もデータ管理やデータモデルと絡めて紹介したいと思います。

小規模なシステムで，単独で稼働するようなものであればデータモデルはDB設計の前段と捉えてもそれほど問題にならないが，企業や政府のシステムは複雑で，多数のシステムから構成されているため，全体を見通すことが難しい。企業合併や買収もあると，システムがそこかしこで分断され，無理やりのデータ変換や，EXCEL等の利用も含めた人間系を介在させることで，なんとかやりくりしていることも多い。

また，多数のシステムのうちのいくつかは外部から購入したパッケージやクラウドサービスを利用しているのも普通であろう。これらは内部のデータ構造はブラックボックスであることも多く，当該組織に合わせて最適なデータモデルというわけにはいかないことも多いだろう。しかし，全て自前のカスタムシステムで組織全体のシステムを構築することは時間的にも，コストの面でも現実的ではない。いや，時間をかけてもビジネスの変化についていけないシステムを長期間かけて構築することになりかねず，出来上がったときは，既に陳腐化している恐れもある。パッケージやクラウドサービスを組み合わせて使うことを前提として考えるべきだろう。

では，その前提に立ち、システム群を全体最適な構造に再構成し、どう維持していくかという課題に対する答えが、システム群を横断するエンタープライズレベルのデータモデルである。注意してほしいのは、個々のシステム内に閉じているローカルなデータは対象とせず、システム間で共有、連携されるグローバルなデータにフォーカスすることである。

データモデルとDB設計は密接な関係があるが（混同されている場合も多い），パッケージやクラウドサービス，継続使用可能なレガシーシステムを活かしつつ，アドホックでなく，アーキテクチャとしての連携を成功させる鍵は、システム群を横断するデータモデルである。DB設計のスコープは個々のシステムだが，エンタープライズレベルにスコープを広げたデータモデルが必要とされているのである。ただし、DB設計だけに引き継がれるのではなく、連携データのフォーマットやメタデータ定義、コード定義につながるのである。

DMBOK２では，DMBOK１にはなかった幾つかの章があるが，その１つとして「第8章　データ統合と相互運用性」がある。ここでは直接、データモデルに言及しておらず、テクニカルなデータ連携アーキテクチャに関する記述がメインだが、それだけではデータ統合はできない。 データHUB，EAI，ESB等が取り上げられているが，こうしたテクニカルなプラットフォームだけでは，個々のパーツ（システムやサービス）を全体最適の観点でつなぎあわせることはできない。

データモデルの適用スコープをここまで広げ，複数のシステムが会話する共通語としてデータモデルとメタデータ定義を行い，それに基づいて，個々のシステムが会話，連携できるようにすることがポイントである。アイテムや顧客についてはエンタープライズレベルのデータモデルに合わせてることで、複数のシステムが無理なく連携可能となる。

種々の事情があり，制約も多いため，安易な批判は避けたいが，特別給付金の電子受付と個々の自治体のシステムがうまく連携できなかったのも，こうした複数システムのスコープでモデルを作成できなかったことも関係しているのではないかとも思えるのである。