杉本啓さんの #データモデリングでドメインを駆動する を読んで

スポンサードリンク


杉本啓さん フュージョンズの代表取締役の方
もう8年くらい経つと思いますがTwitterでよくやり取りをさせていただいています
その杉本さんが執筆した「データモデリングでドメインを駆動する」
基幹系システムの設計に関する濃厚な知識を得られる本
読み切ったので感想や私の考えをまとめてみます

この記事をもとに


で話をする予定です

私の経験から

PMOになる前は、業務系SEでした
主に販売管理と財務管理でPKGカスタマイズ導入
20年くらい前に国産ERPとして名を馳せた
COREPlusの経験が深く
いわゆるNEC系業務PKGの基本的な動きや
テーブルレイアウトは頭に入っています
その前提で読んでしまっているのもある

SoAとSoM

もう使い古された言葉かもしれないけど
SoRとSoEというシステムの分類分けがある
この本は基幹系システムなので、SoRの内容に含まれる

SoRはSoA(活動のシステム)と
SoM(経営管理のシステム)に分けることができる

SoAも物的管理、取引記録、会計評価で分割できる
活動を把握するシステムに携わることが多いので
この3つを考えながらどう使うか工夫すればいい

SoMのほうはPKG機能を使ってもらう
とか、BIツールでどうのみたいなのが多く
細かくは把握しきれていないかな
ただ、単位がMだったりBだったりするし
四捨五入や割り算が関わってくるので
完全な整合性は不要なのは知っている

会計システムについては
どの範囲までとるすか考えたら
BS・PL・キャッシュフロー計算書まででいいのかも
それ以外のものは
SoM範囲でうまく柔軟性があったほうがいい
原価計算関連は特にそうだ

Redmineなどの
PMIS(プロジェクトマネジメント情報システム)も
SoAの考え方がうまく当てはまる

システムの内部構造

キーの採番

自動採番(サロゲート)と手動採番(ナチュラル)についても、いつも悩む
伝票ナンバー以外は手動採番派なのだが
排他制御を考えた場合、自動採番もよいのかなと
柔軟性をもったほうがいいだろうなと考えを新たにしたり
ちなみにCOREPlusは伝票ナンバー以外は手動採番
Redmineはほとんど自動採番です

どういうふうにデータを持つか

データの縦持ちと横持ち
古いシステムは伝票6行をそのまま横にもっていたけど今はありえない
ただ、制約条件からそのようになっていたとも聞く
制約が変われば最適も変わる
そんな気もする

多次元情報のデータ化だが
入出力のデータ項目は外部設計で明確化して
テーブル設計を内部設計でというのは
リレーション型RDBの考え方から
ぬけきれていないのかも
SoMを考えたら道半ば

データの削除

論理削除の物理削除について
論理削除派ですが
それは基幹システムで情報を蓄えておくべき
過去分も見れるべき
という思いが強いからなのかもなあ

このへんは宗教戦争になるのかも

表に見えることと裏の複雑さ
どうしても発生するのかな

業務ごとに分ける

利用者や立ち位置・責任
視座・視野によって見える範囲は変わるし
大事な情報も変わる

エンティティとロールをうまく分割する
基幹システムは協業や制御も兼ねているから
全員がすべて見れる必要はない

それも考慮した権限設定も必須になるね

どんな立ち位置でも
ドメインエキスパートはいらっしゃるから
協力と傾聴で
一緒になって前に進めるように

Pre-TXを受け容れる・データがつぶやく

以前、杉本さんたちが企画されていた勉強会(AccountCode)で
宿題になったままになっているやつ

Pre-TX(プリトランザクション)とは
トランザクションの前の情報
システムのデータになる前の情報のことを指します

いわゆるデータ化されていない非定型なもの
昔は帳簿に関するデータ(振替伝票)だけだったけど
売上・仕入 そして受注・発注
はたまた、見積と情報が前倒しになってきている
今だとマーケティングや企画の情報が
プリトランザクションに当てはまるのかな
またはSoM用の情報が
プリトランザクションとして基幹システムに含まれている

プリトランザクションを
受け入れられるだけの余白をどれだけ残せるか
いや、柔軟性よりも
制約条件を伝えられるシステム構築が重要な気がする

SoM用の情報であれば、すでにある情報の活用
「欲する情報を言い始める」ような流れを夢想する

業務移行とシステム移行

この内容は書かれていない範囲だけど
システム構築を考えた場合、避けられない
時間的制約から同じ項目でというのも
見かけなくもないが・・・ありたい姿ではない

オフコン(COBOLシステム)から移行するときに
徹底的にDB設計を見直す開発会社がある
現状を理解しどのように整理し直すか、
まさにデータモデリングの一例と思っている
設計し直したDBに向けてデータ移行の仕組みも作っている

利用者目線をもつこと

いつも思うが
俺は利用者目線が強く製造者目線は弱い

どうる作るではなくて
システムを使ってどうありたいのか
どうあって欲しいのかを考え抜いて
お互いの本音を聞き合える関係作りが必須だろう
誰もが、自分都合になるからね

それを回避し良くするのが
お互いの本音を聞きあえる関係

システムもステークホルダーの一つ

最近は、システムだって個性がある
と思い始めてきた

システムも人と同様に得意不得意があるから
それを把握して整理してどう振舞ってもらうか
どう活躍してもらいたいからこうやって作る
そんな考えも大事に思えてならない

システムがリソースではなく
ステークホルダーの中にが入ってきてもいい

シュチュワードシップ

業務系システムは組織の弱点が思い切り現れて
自分都合の権力者がいたら破綻する確率があがる
だからきついことが多い

きついことに向き合うための
設計者が設計者たる所以・矜持が書かれていた
いいバランスを見つけて
うまくいったときはヤミツキだから

このあたりは
プロジェクトマネジメントと近い気がします

総じて

本の感想を一言でいうと「濃厚」

ありたい姿は明確になりつつあるのだけど
自分の知ってることで
都合よく理解してる可能性がある

まとめてみてわかったのだけど
・データモデリングについて理解不足感あり
・DDDは踏み込んでいけてないなあ
って気がしている

時期をおいて読み直しすると
新しい発見があるよ
PMBOKがそうあるように

考えるヒントを何度でももらえばいい

人形町今半にて すきやきを

やると決めた自分を信じてみる

関連記事

  1. FACTFULLNESSを身につけ思い込みを乗り…

    FACTFULLNESS世の中が…

  2. ドラクエウォーク3周年を本で振り返る

    ドラゴンクエストウォーク毎日やってるゲーム毎日やってるか…

  3. プロ野球と鉄道 移動との歴史を探る

    プロ野球と鉄道何という俺好みの本!ということで、早速購入…

  4. 「匠Method」を書籍で学ぶ

    匠塾 Advent Calendar 2021 12/4の記事です…

  5. サラリーマンの悩みのほとんどにはすでに学問的な「…

    医療統計を専門にされている西内啓さんの本2012年発売で定期的に…

  6. 「伝わる」プレゼンテーションテクニック

    connpassの企画で【書籍の公募献本】『Keynoteで魅せ…

  7. 本能寺の変 外様のプレッシャーを想像する

    織田信長の配下武将で誰が好きですか?やはり、羽柴秀吉かな前田…

  8. ネガティブ・ケイパビリティ 答えの出ない事態に耐…

    ネガティブ・ケイパビリティ答えの出ない事態に耐える力精神…

PAGE TOP