背景
アジャイルメトリクスという書籍の内容やDXプロジェクトでのデータ利活用という文化に触れてみて、
さらにそこに品質向上という自分の中に今来てる波との双方の観点から
自分のたどちらのプロジェクトでもデータマネジメントの文化を推奨しなくてはいけないと強く感じた。
アジャイルに進めて仮説検証をするにしても検証するための材料となるデータがなくては話にならない。
データを仮説検証をしながら適切に利活用し、質の向上をはかっていきたいと感じた。
結論から先に述べると、DX実現のためにはデータマネジメントの知見やアジャイル活動が必須となる。
また個人的には継続的なGQMワークショップによる、新たなより価値を生むデータの企画なども。
そこで以下ではデータマネジメントの動画コンテンツを通して知り得た内容を記載する。
また補足として、データアーキテクチャ層が全体のどこに位置づくかの図は以下を参照。
データマネジメントの現状
データマネジメントでは、ToBeから逆算してデータを管理することが求められる。
これがきちんと整備されていないと、
「このデータって誰に向けて、何のために使うの？」という
なんだか使用目的のわからないデータがどんどん増えていってしまう。
ある企業の調査によると、ITを導入する国内企業のうちデータ利活用ができているのは全体の約15%に留まるという。
つまり、大多数が「このデータ多分必要だから取りためておこう」て根拠なくため込んでいるか、
もしくは組織的な理由により整備されていないことが容易に想像がつく。
さらにこのデータに関しても、ビジネスアーキテクチャ同様に
MissionレベルからResourceレベルまで各抽象度に応じて存在する。
よって、UAFの枠組みに則って考えることがデータアーキテクチャでも可能である。
そのデータの出どころはビジネスアーキテクチャで取り決めたメジャメントパラメタなどステークホルダーの関心である。
それだけでなく「こういったToBeになりたいけど今仮説的に考えてるものが目標に向かっているのか確かめたい。
その結果を用いて適時軌道修正をはかりたい。」
という時にどんなデータを採取すればその検証ができるのか？
逆にどんなデータは影響度が無視できるほど小さいから採取するまでもないのか？
を実際に実験的にチェックしていかなくてはならない。
しかもそれは実際に採取可能なデータなのか？まで考えられていなくてはならない。
(例えば、芸術的センスの高さ、みたいなものは数値化が困難であるため採取不可)
これらの作業はぱっと見ですぐに結果が出るようなものではないし、
暗黙的に真のアジャイル活動を前提としているためにあまり実施できていないのが現実と思われる。
データマネジメントの考えの重要性
データによる質の向上はエンドユーザーへのフィードバックというアンケート調査だけに留まらず、
開発者視点な品質向上、仕事のパフォーマンス向上においても役立つ考え方である。
【アジャイルメトリクス】という書籍によると、
MTTRという平均修復時間やリードタイムなどを用いて保守性を計測するという試みがなされている。
これを読むまでは「開発者視点でならLCOMといった凝集度や循環複雑度などのメトリクスでが保守性では？」と感じたが、
どうやらここでもビューの思想が用いられている。
外部視点での測定方法が、平均時間修復時間やリードタイムといったものを使って計測。
内部の詳細視点での測定方法がLCOMなどといった凝集度や結合度合いといったものでの計測。
これを用いてどう生かすのかというと、
コアドメインに近いコアドメインと関連のあるドメインであり、かつMTTRが長いものは
「コアドメインに影響を与えるほど保守性が下がっている可能性がある。」
←リファクタリング優先順位高めに選別
「保守性は下がってるけどコアドメインに影響をほとんど与えない。」
←リファクタリング優先順位低めに選別
といった具合に戦略的に品質改善プランも立てやすいし、しかもそれを適時軌道修正しやすい。
こんな感じで状況と用途に合わせて、またそこにある程度の仮説も交えてデータを設計し管理し、質の向上に励んでいく。
以下ではデータマネジメントを構成する11個の項目についての概要を記載する。
①データアーキテクチャ
データがどうビジネスに利活用されているか？を俯瞰して見られる設計図のこと。
既存のデータがどこから取得され、どのように保存管理され、
最終的にそれがどのようにビジネスに利活用されるのか？を
理解したうえで、無駄に蓄積しているデータを削除して、本当に必要なデータを定義する。
②データモデリングとデザイン
データ同士の関連は通常ER図で描かれるが、運用していく中で形骸化してしまうと
そもそもデータが使い物にならなくなり得るので、
だれがどのようなタイミングで更新かけるのか？定期的な運用設計も必要である。
この運用設計に関しては、データアーキテクチャ層だけでなく他の層と同様の考え方のようだ。
③データストレージとオペレーション
ビジネス要件にマッチしたデータベースの保守運用を行うことを指す。
セキュリティとビジネス要件の観点からデータベースの設計を行う必要がある。
ここに関してはUAFでビジネスアーキテクチャにて、
Informationに対するリスク分析などした結果や各抽象度のInformationに対する要件などを
この部分にて考えることになると思われる。
④データ統合と相互運用性
データ活用の観点から使いやすい・活用しやすい形のデータを作成し、
それを適切な場所へ保存しようという考えをする領域である。
⑤データウェアハウジングとビジネスインテリジェンス
データウェアハウジング(DWH)・・・ビジネス上生まれる様々なデータを格納しておく場所
ビジネスインテリジェンス(BI)・・・データを可視化し、データをトラッキングしたり分析に使用したりする。
DWHでデータをビジネスに利活用しやすい形で保存しておき、BIツールを使ってPDCAサイクルを回していく。
BIダッシュボードは、誰のための何のダッシュボードなのか？を常に明確にしていないと
目的が不透明なダッシュボードがただつくられるだけで、形骸化しやすい。
⑥ドキュメントとコンテンツ管理
プロジェクト計画書やデータ分析レポートなどの非構造化データに関しても管理が重要。
このようなデータは構造化データに比べて放置されやすく、大量のデータの中に埋もれてしまいがちである。
それを避けるために定期的にメンテナンスして管理する体制が必要である。
⑦参照データとマスターデータ
マスターデータ・・・常に最新の状態であり、信頼できるデータのこと
参照データ・・・データ同士を紐づけるためのデータ
マスターデータの管理は非常に重要であり、
マスターデータと似たようなテーブルが存在すると、どれが本当のマスタデータかわからなくなる。
なのでマスタデータの管理・運用ルールのガバナンスを定義することが重要。
⑧メタデータ管理
メタデータ・・・データを管理するためのデータのこと
どのデータがどこに、どのセキュリティレベルで置いてあるのか？を一元把握する
⑨データ品質
データが最新でなかったり、欠損していたりするとデータ活用に不具合が発生してしまう。
一度生じたデータの不備は、復元に非常にコスト(特に時間コストトがかかってしまう。
そのため必ずデータの品質を常に担保できるようにしておくのが重要。
⑩データセキュリティ
ビジネス観点でデータを運用するとともに、そのデータをセキュリティ観点で管理することも重要。
（やはりUAFでInformationにおいてSecurityビュー観点での要求ツリーも必要と思われる）
たとえば、顧客の個人情報を誰にでもオープンな形で保存するのはNGというように、
データのセキュリティレベルを適切に管理し、アクセス権限をコントロールする必要がある。
万が一のリスクの情報漏洩などが起きて、ユーザーとの信頼関係を損なわないためにも、
企業活動の一環として非常に重要な部分である。
時代の流れとともにセキュリティの考え方が変わっていくので、そこに合わせてアップデートしなくてはならない。
⑪データガバナンス
⑩までの要点を押さえたうえで、これらの要点をガバナンスきかせて運用体制設計が重要。
これは経営レベルであるStrategicビューから現場レベルのResourceビューまで
一貫したデータに関するガバナンスをUAFと同様のFWを用いて設計することが求められる。
まとめ
データマネジメントは一見守りのDXに感じるが、攻めのDX(攻めのデータ経営)をするうえで非常に重要な部分である。
特に自分がもっとも炎上していると感じた案件で扱っている領域において、
データに関するマネジメントがおろそかになっているように感じたので要注意事項に感じている。
参考用語
MTTR・・・
障害が検出された時点を起点とし、診断、修復、テストなど、エンドユーザーが再びサービスを利用できるようになるまでに行われるあらゆるアクティビティの時間が含まれます。MTTRが短い場合、そのコンポーネントやサービスは短時間で修復できることを示しています。したがって、ITの問題が発生してもビジネスに及ぼす影響は小さいと推測できます。対してMTTRが長い場合は、そのデバイスの障害が重大なサービス中断を引き起こし、ビジネスに大きな影響を及ぼす可能性があることを示唆しています。
リードタイム・・・新機能が定義されてから顧客に届くまでにかかる時間
コアドメイン・・・そのシステム内においてもっとも価値を生み出している部分であり、そのシステム内でもっとも重要なドメイン。
販売サービスなどにおいては、所有権の譲渡といったルール系のものがこれに該当する。
ちなみに時間経過に伴う外部環境変化の影響などのよってこれの位置は変化していく。