スポンサードリンク
杉本啓さん フュージョンズの代表取締役の方
もう８年くらい経つと思いますがTwitterでよくやり取りをさせていただいています
その杉本さんが執筆した「データモデリングでドメインを駆動する」
基幹系システムの設計に関する濃厚な知識を得られる本
読み切ったので感想や私の考えをまとめてみます
この記事をもとに
で話をする予定です
目次
私の経験から
PMOになる前は、業務系SEでした
主に販売管理と財務管理でPKGカスタマイズ導入
２０年くらい前に国産ERPとして名を馳せた
COREPlusの経験が深く
いわゆるNEC系業務PKGの基本的な動きや
テーブルレイアウトは頭に入っています
その前提で読んでしまっているのもある
SoAとSoM
もう使い古された言葉かもしれないけど
SoRとSoEというシステムの分類分けがある
この本は基幹系システムなので、SoRの内容に含まれる
SoRはSoA（活動のシステム）と
SoM（経営管理のシステム）に分けることができる
SoAも物的管理、取引記録、会計評価で分割できる
活動を把握するシステムに携わることが多いので
この３つを考えながらどう使うか工夫すればいい
SoMのほうはPKG機能を使ってもらう
とか、BIツールでどうのみたいなのが多く
細かくは把握しきれていないかな
ただ、単位がMだったりBだったりするし
四捨五入や割り算が関わってくるので
完全な整合性は不要なのは知っている
会計システムについては
どの範囲までとるすか考えたら
BS・PL・キャッシュフロー計算書まででいいのかも
それ以外のものは
SoM範囲でうまく柔軟性があったほうがいい
原価計算関連は特にそうだ
Redmineなどの
PMIS（プロジェクトマネジメント情報システム）も
SoAの考え方がうまく当てはまる
システムの内部構造
キーの採番
自動採番（サロゲート）と手動採番（ナチュラル）についても、いつも悩む
伝票ナンバー以外は手動採番派なのだが
排他制御を考えた場合、自動採番もよいのかなと
柔軟性をもったほうがいいだろうなと考えを新たにしたり
ちなみにCOREPlusは伝票ナンバー以外は手動採番
Redmineはほとんど自動採番です
どういうふうにデータを持つか
データの縦持ちと横持ち
古いシステムは伝票６行をそのまま横にもっていたけど今はありえない
ただ、制約条件からそのようになっていたとも聞く
制約が変われば最適も変わる
そんな気もする
多次元情報のデータ化だが
入出力のデータ項目は外部設計で明確化して
テーブル設計を内部設計でというのは
リレーション型RDBの考え方から
ぬけきれていないのかも
SoMを考えたら道半ば
データの削除
論理削除の物理削除について
論理削除派ですが
それは基幹システムで情報を蓄えておくべき
過去分も見れるべき
という思いが強いからなのかもなあ
このへんは宗教戦争になるのかも
表に見えることと裏の複雑さ
どうしても発生するのかな
業務ごとに分ける
利用者や立ち位置・責任
視座・視野によって見える範囲は変わるし
大事な情報も変わる
エンティティとロールをうまく分割する
基幹システムは協業や制御も兼ねているから
全員がすべて見れる必要はない
それも考慮した権限設定も必須になるね
どんな立ち位置でも
ドメインエキスパートはいらっしゃるから
協力と傾聴で
一緒になって前に進めるように
Pri-TXを受け容れる・データがつぶやく
以前、杉本さんたちが企画されていた勉強会（AccountCode）で
宿題になったままになっているやつ
Pri-TX（プリトランザクション）とは
Pri-TXはトランザクションの前の情報
システムのデータになる前の情報のことを指します
いわゆるデータ化されていない非定型なもの
昔は帳簿に関するデータ（振替伝票）だけだったけど
売上・仕入 そして受注・発注
はたまた、見積と情報が前倒しになってきている
今だとマーケティングや企画の情報が
プリトランザクションに当てはまるのかな
またはSoM用の情報が
プリトランザクションとして基幹システムに含まれている
プリトランザクションを
受け入れられるだけの余白をどれだけ残せるか
いや、柔軟性よりも
制約条件を伝えられるシステム構築が重要な気がする
SoM用の情報であれば、すでにある情報の活用
「欲する情報を言い始める」ような流れを夢想する
業務移行とシステム移行
この内容は書かれていない範囲だけど
システム構築を考えた場合、避けられない
時間的制約から同じ項目でというのも
見かけなくもないが・・・ありたい姿ではない
オフコン（COBOLシステム）から移行するときに
徹底的にDB設計を見直す開発会社がある
現状を理解しどのように整理し直すか、
まさにデータモデリングの一例と思っている
設計し直したDBに向けてデータ移行の仕組みも作っている
利用者目線をもつこと
いつも思うが
俺は利用者目線が強く製造者目線は弱い
どうる作るではなくて
システムを使ってどうありたいのか
どうあって欲しいのかを考え抜いて
お互いの本音を聞き合える関係作りが必須だろう
誰もが、自分都合になるからね
それを回避し良くするのが
お互いの本音を聞きあえる関係
システムもステークホルダーの一つ
最近は、システムだって個性がある
と思い始めてきた
システムも人と同様に得意不得意があるから
それを把握して整理してどう振舞ってもらうか
どう活躍してもらいたいからこうやって作る
そんな考えも大事に思えてならない
システムがリソースではなく
ステークホルダーの中にが入ってきてもいい
シュチュワードシップ
業務系システムは組織の弱点が思い切り現れて
自分都合の権力者がいたら破綻する確率があがる
だからきついことが多い
きついことに向き合うための
設計者が設計者たる所以・矜持が書かれていた
いいバランスを見つけて
うまくいったときはヤミツキだから
このあたりは
プロジェクトマネジメントと近い気がします
総じて
本の感想を一言でいうと「濃厚」
ありたい姿は明確になりつつあるのだけど
自分の知ってることで
都合よく理解してる可能性がある
まとめてみてわかったのだけど
・データモデリングについて理解不足感あり
・DDDは踏み込んでいけてないなあ
って気がしている
時期をおいて読み直しすると
新しい発見があるよ
PMBOKがそうあるように
考えるヒントを何度でももらえばいい
