前提知識
TOC
TOC(制約理論)を用いて、全体最適につながるような品質改善を行う。
データがどこから生まれ、どういったライフサイクルを歩むのか？
どこに保存され、そのデータの所有権はどのコンテキストなのか？
だけでなく、データの品質改善も組織的なデータマネジメントには求められている。
データの品質改善にしても、ボトルネック部分にのみ選択集中しなくては、お金がいくらあっても足りなくなる。
ECRS原則
業務プロセス改善の際に使う、この順番に行いなさいという原則。
詳しくは以下を参照ください。
この原則は何もプロセス面においてのみ適用されるものではない。
データマネジメントにも適用できたので、その紹介をする。
多角的に把握する
あくまでも模式図であるものの、下図は立体を上から見た際の図としてみる。
たとえば辺AB部分がセキュリティの側面を表し、
辺DE部分がパフォーマンスの側面を表すとする。
ある品質の側面でのボトルネックだけでなく、
他の側面のボトルネックとの力学関係も仮説を持って把握しておく。
セキュリティ上のボトルネックを解消した結果、
パフォーマンス面のボトルネックをさらに悪化させてしまうという事態は、TOCの考え方である【全体最適】には反する。
状況によっては、求められる品質特性同士のトレードオフ両立が求められ、そこに対立解消図のクラウド法が求められる場面も出てくるはずと思っている。
考え方の土台
ベースの考え方自体は、アプリケーションのプロセス品質改善の考え方からそっくり引用できるものが多いと踏んでいる。
データ改善×ECRS
データの利活用前の改善段階においても、ECRS原則は使える。
DX案件やアジャイルなプロセスを必要とする不確実性の高いプロダクトでは、継続的なデータモデリングと共に、このECRSを意識した改善活動が求められる。
それでは、いくつか概要を説明していく。
通常のECRS原則同様に、まずはEから行っていくことをお勧めする。
しかしながら、その後のC(統合or分割)からは、プロセスの場合と違って順番を入れ替える必要もあった。
Eの段階
利活用前にまずは使われていない、削除しても問題ないテーブルを掃除する。
一番削除しても問題なさそうなものから少しずつ削除する。
これ自体は、以下に記載した戦術的フォークと一緒の考え方である。
これを行ったうえで、次のフェーズへ移行する。
Sの段階
簡潔にわかりやすくするフェーズ。
どういうことかというと、１つのデータドメイン内にあるテーブルが１つのみで、そこにすべてのカラムが収まっていることを想像してほしい。
簡単な例として出すなら、
注文テーブルと注文明細テーブルが１つにまとまっているとしよう。
※2つはすでに上の3つの工程によって、同じデータドメインに集められているものとする。
これを分かりやすいと言えるだろうか？
とてもじゃないが言えない。
この程度のものならまだかわいい方だが、
そこにさらに色んなデータ責務のものがくっついていたらどうだろうか？
いわば、いろんな大量のカラムの混在した神テーブルだ！
そのままでは正規化もろくに行われておらず、メンテもしにくい。
データの重複や不整合も起こりやすいと言えるだろう。
そこでその神テーブルを正規化に従って分けていく。
その結果、１つのテーブルは１つのデータの意味を表し、
そのデータドメインが何を表すものなのか？を一発でいえる。
ちなみにこのフェーズを行って、１つのテーブルが１つの責務になりうるように
シンプルな構造になっていないと、後述のデータドメイン(データのコンテキスト境界)の位置の判別が難しくなる。
よって、この後にCを行うことを推奨する。
Cの段階
この段階では統合や分解を行うフェーズ。
データの観点でのコンテキスト(データドメイン)を意識した統合や分解を行う。
つまり、データドメインが異なると判断したものは、
同じスキーマに含めないで、明確に境界を張って分けるとか。
この時点でモノリスなのか？ マイクロサービスなのか？は置いておいて、概念スキーマ上は分けておくという方法を取った方が、変にデータの静的な密結合を起こしにくい。
同様にして、同じデータドメイン内のもの
たとえば強い集約関係にあるものとかは、境界を引かずに、
同じデータドメインにまとめておく。
このようにドメインを意識して保守の観点で分ける以外にも、
セキュリティなどの運用特性も考慮した上で、
データドメインの境界の位置を定義しなくてはならない。
特にデータの境界位置の変更は、ロジックの境界位置の変更以上に行いづらいので、慎重に議論する必要性がある。
Rの段階
入れ替えを行う段階。
もともとはアナログな帳簿からデジタルな記録媒体に組み替えるなど。
他には、もともとはRDBであったものの、
整合性よりも他の品質特性が求められるようになってきたので、
DBの種類を変えたりすることを検討するフェーズ。
RDBが有名であり、もっとも使われているので、
モノリシックなアプリでRDBから他のデータベース種別へ変えるということは余程なことがない限りない。
この種別の置き換えは、主にマイクロサービスなどのような分散システムで、データベースが各コンテキスト内に１つあるような状況下で検討する事柄。
実体験だが、上の3つをすっ飛ばして、いきなりこのRからやろうとしたことがある。
後戻りできる段階であったからよかったものの、あと一歩で自分が大きな負債を生み出す１人になる所であった。
同じデータドメインのものは1つの種別のDBに格納する以上、
そこに集まってるデータは、同じ品質レベルが適用されてしまう。
注意事項
ちなみにドメイン的には、異なるスキーマであってほしいような
注文データドメインと発注データドメインがあったとしよう。
この時に安直に、それら２つを分けるってやってはいけない。
ビジネス上の都合で、そこの間に強い整合性、
トランザクション境界がその２つを包み込むようにしてあった場合には、注文と発注テーブル群を1つのデータドメイン内に配置する必要性がある。
その代わり、デメリットとしてそのデータドメインには、2つのデータの意味が混在していることも理解したビジネスモデルを構築しなくてはならないことは理解しておく必要がある。