IT組織の中でのデータマネジメントの位置付けについて

IT組織、IT人材育成の中でのデータマネジメントの位置付けについて、今回は、記載したいと思います。

データマネジメントの活動は、DMBOK(データマネジメント知識体系ガイド)に定義されていますが、企業や事業活動の中で、データマネジメントがどこに位置付けられるのか、考えてみました。また、人材育成面で、データマネジメントについて、定義されているものがあるか考えてみました。

企業や事業活動の中で、当たり前のように、データマネジメントが位置付けられていれば、もっともっと、よりデータマネジメントが認知され、価値が上がり、育成にも力を入れ、みなさんがより活動しやすくなるのではと思っております。

今回は一例です。データマネジメントは、ITに関わる組織、人、のみに関係するのではなく、企業全体での事業活動・取組みがデータマネジメントと思いますので、ITに特化した話をすべきではないと思っていますが、まずは、IT組織・活動の一例を記載したいと思います。

「i コンピテンシ ディクショナリ」というものをご存知でしょうか。ご存知の方も多いと思いますが、紹介したいと思います。

「i コンピテンシ ディクショナリ」とは、IPA(独立行政法人 情報処理推進機構)のIT人材育成事業の取り組みの一つで、人材育成の枠組みになります。

IPAが提供する「i コンピテンシ ディクショナリ」(以降、iCD)は、企業において、

  • ITを利活用するビジネスに求められる業務(タスク)
  • それを支えるIT人材の能力や素養(スキル)

を「タスクディクショナリ」、「スキルディクショナリ」として体系化したものになります。

「タスクディクショナリ」、「スキルディクショナリ」、それぞれ辞書のように参照できる形で構成立ててまとめられており、「タスクディクショナリ」は、タスク3階層と評価項目の計4階層で構成。「スキルディクショナリ」はスキル3階層と知識項目の計4階層で構成されています。

実際に、IT組織(IT部門、SI会社、IT関連会社等)の新規立上げ時の組織や業務の定義、また、事業・業務運営中の際も、改革・改善検討、役割整理の参照モデルとして「タスクディクショナリ」が使われていたり、人材育成時のスキルの棚卸し、定義、また人材評価の仕組みを策定する上での参照モデルとして、「スキルディクショナリ」が使われており、企業は経営戦略などの目的に応じた人材育成に利用することができます。

2014年7月31日にいiCDの試用版を公開し、パブリックコメントや産業界における実証実験などを踏まえ、2015年6月に正式版を公開されています。

以下、参照下さい。

https://www.ipa.go.jp/jinzai/hrd/i_competency_dictionary/icd.html

iCD2018から新たに「タスクディクショナリ」に、「データマネジメント」のタスク追加がされました。
オレンジ色の線で四角に囲っている部分です。

出典: iCD  タスクディクショナリ タスク構成図 から引用。

iCDのタスクディクショナリの「データマネジメント」タスクには、以下が定義されています。

  • データガバナンス
  • データセキュリティ管理
  • データ品質管理

iCDでは、上記の図の左の方には、戦略、企画、開発等のタスクが定義されていまずので、データマネジメントに関するタスクはその中にもあり、位置付けられています。(データ設計等)

当然、iCDと、皆さんが活用されているDMBOKは、別の目的で作られたものであり、カバーする範囲もカテゴライズも、異なりますが、 企業においてITを利活用するビジネスに求められる業務(タスク)の中で、データマネジメントが定義されているのか、また、どこに位置付けられているのか、参考にして頂ければと思います。

「スキルディクショナリ」には、スキル、職種が定義されており、データマネジメントに関するスキル、職種も探して頂ければ、参考になると思います。

iCDは、以下、オフィシャルサイトもありますのでご参考までに。

https://icd.ipa.go.jp/icd/

「タスクディクショナリ」、「スキルディクショナリ」 は上記サイトからダウンロード可能です。

以上

サブジェクトエリアを考える

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

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

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

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

まず,サブジェクトエリアの分割基準についてだが,理論的裏付けは難しいものの,ベスト・プラクティス,あるいはリファレンスとなるべきモデルはありそうである。残念ながら日本語訳は出ていないが,アメリカのデータモデラーであれば,まず絶対に読んでいる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以下といった経験を共有できた。数はけっこうバラつきが多いが,これはどこまでサブタイプを設定するかにもよるかと思う。あまりにも多い場合はさらに細分化した単位にサブジェクトエリアを分割するほうが良いだろう。

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

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