データモデルのスコープを広げよう

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

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

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

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

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

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

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

標準の作成と定着化について

今回は、会社や組織にデータマネジメント等を推進、定着化させるための一つの手段として、その専門領域の知識体系(BOK)(データマネジメント知識体系ガイド(DAMA―DMBOK)等)を活用した標準化、定着化の考え方、進め方を記載したいと思います。

世の中にはDMBOK以外に、「プロジェクトマネジメント知識体系ガイド(PMBOK):PMI」、「ビジネスアナリシス知識体系ガイド(BABOK):IIBA」、「ITアーキテクチャの知識体系(ITABoK):Iasa」、などなど、知識体系ガイド(BOK)が多くあります。

今回は多くの会社で、会社・組織の標準として規定されており、データマネジメントと「マネジメント」部分の名前が同じ、プロジェクトマネジメントの標準化を例として、考え方や、進め方を記載します。

そもそも標準化、もしくは標準文書の作成は必要なのでしょうか・・・。

多くの会社が標準文書は作成したものの、その後、活用されなくなり、形骸化して使われなくなってしまい、また何年か後に、新たに別の標準文書が作成され、また使われなくなり・・・と繰り返される場合があります。

当初は、ビジネスや業務を実施する上で、課題・リスクがあり、その原因を分析・評価した結果、マネジメント(プロジェクト、データマネジメント等)に問題があり、その解決策として、これまで実施していなかった、また属人的に実施していた「マネジメント活動」の実施、もしくは強化を図る事を考えられた事と思います。

そして、その手段の一つとして標準文書を作成し、それを基にビジネス活動を行うことによって、ビジネスを成功に導くことが目的・目標であったはずです。

上記のような理由があれば、標準文書の作成は必要性になりますし、その改善活動等が定着化・浸透してしまえば、ビジネス上の課題・リスクは無くなるため、標準文書を活用しなくてもよい場合もありますが、新しい人が増えた場合に維持していくのは難しいと思います。
また、標準文書を作成しても活用されないのは、標準文書の問題ではなく、定着化、浸透の仕方に問題がある場合が多いです。

よって、標準化、もしくは標準文書の作成は必要です。

  • 新たな取組みをする場合は、その取組みを文書化し、共通認識を図るために標準化、標準文書は必要です。
  • 属人的な活動に問題があり、ビジネスや業務に課題・リスクがあるため、業務を標準的、均一的に行うことによって、業務の品質向上、リスク軽減を図る施策の一つとして必要になります。
  • よって、ビジネスや業務を実施する上での「課題・リスク」を解決する手段の一つとして有効です。

何故、DMBOK、PMBOK等の知識体系があるのに、会社や組織の標準文書を作る必要があるのでしょうか・・・。

例としてPMBOKは、ビジネスの業界・業種を問わず、汎用的な知識体系となっており、ビル建設等のプロジェクトにも、ITのシステム開発プロジェクトにも、研究開発のプロジェクトにも特化しておらず、共通的、汎用的な知識体系となっています。
よって、ビジネスや業務を実施する上で、ある業界、業種、会社・組織に合った標準にする必要があります。

また、会社の課題、リスクを考えると、ある部分を詳しく定義、記載する必要があります。
それと、会社・組織には関係ない、必要ないプロセスやアクティビティもあります。最初は全ての範囲を実施するのではなく、段階的にステップを分けて、スモールスタートで順次拡張していくのであれば、最初から全てBOKと同じ範囲のもの全て作成する必要はありません。

よって、DMBOK、PMBOK等の知識体系があっても、会社や組織の標準文書の作成は必要になります。

会社や組織の標準文書作成時に、DMBOK、PMBOK等の知識体系を活用する理由は・・・。

これはDAMA日本支部会員の方々にはあらためて言う必要はありませんが(笑)、他の方にご説明される場合の参考として下さい。

専門領域の知識体系は、その専門領域の有識者のノウハウを結集していて、体系化されているため、全体を把握、俯瞰できることが重要になります。現在の自社の取り組みの評価をする際にもベンチマーク、リファレンスモデルとして活用できます。DMBOKですと、DAMA-DMBOKフレームワークやアクティビティで体系化されています。PMBOKでは知識エリアやプロセス群で体系化されています。

また各ガイドで使われている用語、定義を活用することにより、様々な人が共通な言葉でコミュニケーションが出来ることになり、それにより、コミュニケーションも早くなり、円滑にでき、そのメリットは大変重要になります。

それと、各BOKは、バージョンアップされる事が多いため、世の中の動向や実績に追従したノウハウを習得できると思います。

但し、これはあくまで私見ではありますが、各知識体系やその業界の標準は、ある程度業界内で定着した後に、体系化され、まとめられている場合もあります。そういった場合は、ある程度古い(語弊がありますが)やり方になっている可能性もあり、現在の早いスピードで動いている世の中では、見直し・拡張が必要な場合もあると考えます。これも、前述の会社や組織の標準文書作成の必要性の一つと思っています。

よって、まだマネジメント等の取り組みがなされていなければ、専門領域の基礎知識として活用し、知識体系がバージョンアップされることで、最新の知識体系も取り入れることができます。また、実際に実施されている業務の取組みの方が進んでいれば、そこは前述の会社や組織の標準の中で拡張すればいいと思います。

今後、標準化・標準文書作成を検討するにあたって・・・。

  • 標準化・標準文書の作成は、ビジネス・業務の課題・リスクを十分整理した上で、その目的・目標を明確にして検討・作成が必要になります。
  • 標準文書が活用されなくなるのは、標準化や標準文書を作成する事がよくないのではなく、その目的・目標がはっきりしていないから。目的・目標に合った、範囲や内容の標準化、文書とする必要があります。
  • BOK等の専門領域の知識体系は、全体網羅でき、体系化され、また共通の言葉・用語で会話できるため有用です。
  • 標準化、標準文書作成だけで終わるのではなく、定着化や浸透の施策が必要であり、重要です。作成した後の取り組みが不可欠になります。

以上

データモデリングから始めませんか?

 DMBOKガイド第1版ではデータモデリングは「データ開発」の一部でしたが、第2版では新たに「データモデリングとデザイン」という章が設けられました。
 果たして、日本の企業での中でどれ位、データモデリングが行われているでしょうか?残念ながら、あまり多くないというのが私の印象です。或いは、データベース設計のためにのみ使われ、開発後に維持されていないことが多いとも思います。あるSIerの中では、「最近は全く新規でのシステム開発ということが殆どないので、データモデリングを習っても実践する場がなくなった」と言われていました。
 新規のデータベース設計がなくても、業務分析しかり、現行システムのデータ構造の逆解析など色々と用途があるのに勿体ない話です。
 例の「2025年の崖」への対策としてレガシーからの脱却を図るということであれば、先ずはデータモデリングを用いた分析から取り掛かってはいかがでしょうか。

 私は受託開発を行う際の分析と、その開発のための方法を探っていた中でデータモデリングに辿り着いたので、その視点からデータマネジメントにおけるデータモデリングについて少し考察してみます。

データマネジメントにどこから手を付けるか?

データマネジメントはDMBOKガイドの目次を見てもわかる通り、非常に多岐に渡る活動やスキルから成っています。データマネジメントに取り組むきっかけも色々でしょうし、これまでの環境や現在の要求事項に応えるために取り組みの優先順位が決まることもあるでしょう。それでも敢えて取り組みのための順序を考えるならば、次のようではないかと私は考えます。
 最初に必要なことは、実際の活動母体となる組織作りでしょう。本格的な専任の部署でも、ワーキンググループのようなものでも構いませんが、業務とITの両方の視点が必要なので、一人きりで始めるより、できれば数人で始めたいです。例えば利活用のためのPoCに向けて作られたWGとかでも良いです。そして、更に可能であれば経営者のコミットメントが欲しいところです。

 次に取り組むのにはデータモデリングが良いのでは考えています。データをマネジメントすると言うのだから、そのデータがどんな構造をしていて、何処にあるのかが明らかになっている必要があります。

データモデリングとデータカタログ作成

 どんなデータが何処にあり、どういった関係かを明らかにするための手段には、次のものがあります。一つには、データモデリングを行い、業務に必要なデータ、あるいは現在運用されているデータとその関係を明らかにしていく方法です。
 それだけでは、実際のシステムにて、何処にそのデータが存在するのかわかりません。そのためには、ツールの力を使ってデータカタログ作成を行うことと、その過程で実際に格納されているデータのプロファイリングを行うことが必要です 。

 順序については、置かれている環境(人のスキルも含めて)によって異なりますが、可能であれば、1)データモデリングにより業務におけるデータ構造をあきらかにする。2)プロファイリングを伴ったデータカタログ作成を行う。といった順で進めることが良いと思います。
 データモデリングは飛ばしてデータカタログだけ作るのではダメか?という方もあるでしょう。データカタログ作成により、存在する項目は明らかになり、似通った項目の統合もある程度進めることができると思います。
 しかしながら、データ項目間の関係を明らかにすることは難しいです。また、実装の都合が強く反映されている場合もあります。たとえ参照整合性制約があっても、その関係をパッと目で見て取ることができません。開発時に、表形式のデータベース設計書のみを作れば良いか、データモデルを書くべきなのかということも議論されますが、データモデルを書く方が良いと考えます 。

 データカタログ作成より、できればデータモデリングを先に行うことをお薦めします。メタデータを明らかしていく上で、項目の名称以外に意味を定義する必要がありますが、それには関係を問いながら掘り下げていくことができるデータモデリングが有効です。もちろん、事情によってはともかく現状のデータの在り方を明らかにするために、ツールによってデータカタログを作成し、その後に解析を行うために部分的にデータモデリングを併用するという方法もあります。そのためには、いずれにせよデータモデリングを実践できるスキルを持った人が必要になります。

 データモデリングは誤解されていることが多く、RDBの項目定義と同等のものを 単に箱と線で書かれたER図を作っていくことがデータモデリングだと思われていて、IE法やIDEF1Xなどの表記ばかりが取り沙汰されます。しかしながら、そこにはビジネスを解析するための方法論があります。
 データベース設計を目指すだけでなくデータを起点にビジネスを解析することができます。ある企業にて作成支援をし、作成したモデルを別のモデラーたちが初見でどれ位に現状のビジネス課題を出せるかという実験をしたところ、依頼した企業の業務側の人が驚くほど正確に課題が出されてきました。モデル上でモデラーにとって気持ち悪い記述のところには、何らかの無理がかかっていることが読み取れるというだけのことですが、モデリングの威力を知って貰うには良い機会でした。
 それが可能なように、あるビジネスをなるべく同じ視点で解析し、同じモデルが書けるようになるための方法論が必要です。

 ここで一つだけ、私のお気に入りのモデリング手法を紹介しておきます。佐藤正美さんが考案したTMと呼ばれる手法です(私は「T之字」と読んでいます)。

 もちろん、 企業によって事情が大きく異なると思います。データカタログを作る中で殆ど意味の定義も問題なくできる企業もあれば、データプロファイリングも並行しないと意味がとれないような場合もあります。また、モデリングを先行させ、データカタログを作りながらプロファイリングを進める方が良いという企業が多いのではないでしょうか。いずれにせよ、有意義なモデルを作れるデータモデラーを確保できているか、という点が課題になります 。

 私の次回分では、データモデラーのお噺にしようかと思います。

新型コロナウイルスとオープンデータ

今回のコロナ禍の中、オープンデータの活用が目を引く機会が増えてきているように思われます。(下図<東洋経済オンライン>は、皆さんも良くご覧になっているのではないでしょうか。)そこで、オープンデータの現況について調べてみました。

私が、オープンデータを知った契機は、某ソリューション会社にてデータの利活用状況について動向調査をしていた時でした。米国のDATA.GOVを覗いたところ、そこに、当時(2013年)のオバマ大統領のメッセージとして「参加型の民主主義をより一層推進するためにこのサイトを立ち上げた~云々」といった内容が高らかに謳われており、妙に感心したことを覚えています。

日本では、2011年の東日本大震災発生時に、それまで電子政府の取組みを進めていたにもかかわらず、緊急事態に即応する行政のデータがなかなか提供できない中、Google/Twitter社による携帯電話やSNS等からのいわゆるビッグデータ活用した取組みが大きな話題を呼びました。

その後、公共データ等を集約して二次利用可能な形に整備して提供できるような体制が求められ、2012年に「電子行政オープンデータ戦略」が策定され、推進されてきました。 それから大分時が経過しましたが、日本のオープンデータの現状は、どうでしょうか?

The Open Data Barometer ホームページより

WWW財団による、Open Data Barometer によると、2018年の世界の上位は、上の表のようになっています。
日本はニュージーランドと並んで6位にランクされています。
意外(?)とも思えますが、実際の状況はどうでしょうか。

1.政府の状況

当初、データ公開中心の取組みであった「オープンデータ1.0」から、2016年には、データの利活用を前提とした「課題解決型のオープンデータ」の実現を目指す「オープンデータ2.0」にステップアップし進められてきました。(政府の取組みについての詳細は、「オープンデータへの取組み」参照。)

「オープンデータ2.0」構想のもと、2017年5月には、「オープンデータ基本指針」が策定されました。オープンデータの意義や定義とともに、行政手続きや情報システムの企画・設計段階からオープンデータ・バイ・デザインの考え方を取り入れることを前提として、基本ルールが以下のように定められています。

行政保有のデータは公開を原則とし、二次利用も積極的に促進すること、公開環境として容易に検索・利用できるウェブサイトを利用すること、データの形式はWWWの創設者Tim Berbers-Lee が提唱した「5つ星」の指標を参考にする、オープンデータのメタ情報をデータカタログサイト「DATA.GO.JP」に登録し、公開することなど。 また、公開・活用を促す仕組みとして、官民でデータの公開・活用の在り方を対話する「オープンデータ官民ラウンドテーブル」が2018年1月から開催されています。

2.地方自治体の状況

政府のみならず、2016年の「官民データ活用推進基本法」により、都道府県での推進計画策定が義務付けられたこともあり、また「オープン&ビッグデータ活用・地方創生推進機構」等の活動にもより、一応全都道府県でサイトが立ち上げられています(左図のように全都道府県にサイトが設置)。

市町村では、推進計画の策定は努力義務にとどまっていますが、鯖江市横浜市などがいち早くポータルサイトを立ち上げました。
2020年までに地方公共団体のオープンデータ取組率を100%にすることを目標としていましたが、2019年9月17日現在で37%(652/1,788自治体)に留まっています。

3.民間との連携

様々な事業体や地方自治体の利活用事例やアクティビティは、「オープンデータ100」として、政府CIOポータルに掲載されています。(2020年5月現在、事例64、アクティビティ6)

こうした取組みを推進していくために、シビックテック(Civic Tech=市民+テクノロジー)という、市民自身がテクノロジーを活用して社会や地域の課題解決を目指す、一種の運動が進められています。Code for JapanやCode for XX(XXは事業者や自治体等の名称)という活動により、行政・市民・企業の三者による地域づくりへの試みが各地にて行われています。

より詳しく知りたい方は下記をご覧ください。
地方におけるオープンデータの取組状況について」(2019.10.16)内閣官房情報通信技術総合戦略室
オープンデータを活用したアプリケーション等に関する調査研究報告書」(2019.06.21)

4.新型コロナウイルス対策とオープンデータ

今回の新型コロナ対策として、東京都でいち早く(3月3日)「新型コロナウイルス感染症対策サイト」(下図)がシビックテックによりオープンソースとして立ち上げられ、その後全国80サイトに波及しているそうです。

内閣官房IT総合戦略室、総務省、経産省は3月9日、新型コロナウイルス感染症対策にまつわるテレワークやeラーニングなどの支援サービスを無償/期間限定で提供する情報をまとめたWebサイト「#民間支援情報ナビ/VS COVID-19」を公開しました。企業やシビックテック各団体と連携し、オープンデータを活用した情報検索サイトが構築され、各種支援サービスの検索が可能となっています。

また、緊急事態宣言発令にあたって、病床数不足が挙げられていましたが、全国の病床の使用率を一覧化したダッシュボードも公開されています。これも鯖江市のシビックテック Code for Sabaeの福野泰介さんらにより開発されています。
行政側で公開されているデータは、まだまだPDF等の機械に判読不能の「一つ星」データですが、これをより機械判読性を高めたデータ形式で公開できるよう促すべく、シビックテックの有志が協同して「オープンデータ項目定義書」を作成したりという動きも出てきています。

これに関する総務省の資料は下記を参照してください。
新型コロナウイルス感染症対策サイトのためのデータ公開について(2020.03.21)

5.所感

上記のように、新型コロナウイルス問題をきっかけとして、オープンデータに関しても様々な試みが行われています。日本各地で民間と連携して色々な取組みが行われていることを知り、その進展に期待を持ちたいと思いました。ただし、取組み事態は結構なのですが、今回顕わになってきたのは、ITインフラに関する様々な脆弱性です。
 いちいち上げると情けなくなってくるのでそれは止めますが、根本的には、データ利活用の仕組みや考え方が根付いていないことが大きな原因の一つのように思われます。昨今DX(Digital Transformation)が叫ばれていますが、個人的には、デジタルインフラの大きな中心の一つはデータインフラであり、ITに係る全ての関係者にデータリテラシーが求められているのではないかと思っています。
 今こそ、ラジカルにデータマネジメントを熟慮し実現していかなければならない時代だと痛感されます。

以上