以下の書を読んだので読書ノートを残す。
背景
見習い参加している読書会の課題図書であったことが切っ掛け。ただ自分自身、そもそも20代の頃はERPパッケージの導入支援をやっていた時期が長く、基幹システムについては多少の前提知識も持っている。なので「業務システム・基幹システムを捉え直す」という本書の問題意識には興味を惹かれた。そして事実、ERP以外も通った今だからこそ理解できた内容も多かった。
サマリ
肉厚だったが、面白かった。
- まえがきにも有る通り、業務システム・基幹システムを捉え直すうえで、今一度データモデリングの重要性を捉え直そうという試みの書。
- 前半はまずSoRなシステムが対象とする業務を、SoA、SoMにブレークダウンして更に捉え直す試み。このあたりは業務システムが捉えようとする企業の基幹業務についての整理が中心。導入時にERPに対して感じていたギャップは、かなり言語化してくれた爽快感がある。
- 後半、終盤はデータモデリングの観点整理と、著者の提案。リレーショナルモデルの話や、DDDに対する軌道修正の話など。業務システムのデータベース設計やDDDベースのモデリングで苦しんだ経験があれば、色々納得できる話。
タイトルと目次をざっと見た時は全体像を想像しきれなかったが、読み終わってからタイトルと副題を見ると、著者の経験に裏打ちされた主張がしっかり込められている。とはいえ要求されている前提知識も内容も肉厚で、自分の実力で咀嚼しきれた自信はまだない。
ピックアップ
自信の読書ノートも兼ねて、いくつか印象に残ったトピックを挙げる。
SoRを更にSoAとSoMにブレークダウンして捉え直す
- SOR：System of RecordとSOE：System of Engagementという捉え方に加え、SORの中に更にSOAとSOMという捉え方を追加する。
- SoA：System of Activities…活動のシステム。現場の業務活動を行うためのシステム。受注管理とか、在庫管理とか。
- SoM：System of Management…経営管理のシステム。企業の儲けの状態や適正在庫のトラッキング。BIダッシュボードとかが好例。
- SoA⇔SoMがシステム上重要視する要件は異なる。件別データ⇔要約データ、RDB⇔RDB＋α￥、履歴管理⇔バージョン管理
- ↑を踏まえるとSoAとSoMをモノリシックにやろうとするのは筋が悪い。
この枠組みは本書を通じて使用される著者提唱の枠組みだけど、ものすごく強力で納得感が有る。（SoMで重視されるのは履歴管理ではなくバージョン管理、というのはすごく納得がいった）ERPをやったことある人なら、SoM的なものとして挙げられているBIや連結会計がSoA的なモジュールと違う目的で動いている、というのは実感していると思う。
SoAとは残管理である
- 現場活動は「あと何が残っているか」の「残管理」である。例えばソフトウェア開発で使うバックログも代表的な残管理。
- 残の発生と解消の紐づけがSoAのコア。残が有ることで業務は駆動し可視化されるし、同期/非同期が分割される。残の管理主体の違いが業務の境目にもなる。
この部分はERP関係なく身近な業務でも想像できるので非常に納得しやすいのでは。当たり前のことだが、ソフトウェア開発でも、販売プロセスも、生産プロセスも、確かに全ては残管理で成り立っている。これも強力で汎用的な考え方だと感じた。
業務システムの道具性を上げるためのアプローチ
- ソフトウェアに可変性を組み込むことで、ソフトウェアの道具性を高めることができる。
これらのアプローチそのものは具体例を見れば、割に身近なものじゃないだろうか。プロダクト的なものを実装しつつ個社要件を吸収したいケースとか、それこそパッケージERPにもこういう機能はよくある。ただ、本書の中では、あくまでミニマリズムを達成するための可変性を確保するため、という立ち位置で、このアプローチの有用性と重要性を説明しているのが新鮮に感じた。
モデリングについて、データモデルとDDD
- 概念モデル＞論理モデル＞物理モデルという定義が一般的に存在するが、論理モデルと物理モデルは「論理データ設計」「物理データ設計」として、データベース設計の関心事として捉えるべき。そしてデータモデルは言うまでもなく概念的。
- ユーザーにとって重要なのは、事業活動を行うための情報（＝帳簿）のデータモデル。データモデルは業務活動を行うための情報のデザインでしかない。
- データモデルはドメインモデルのサブセット。ドメインモデルは実世界の実体そのものをモデリングするというより、解決したい問題領域に存在するモデル。メンタルモデル。
- そしてドメインモデル＝レイヤードアーキテクチャにおけるドメイン層、に同一視してはいけない。ドメイン層以外にもドメインモデルは現れる。その前提でデータモデル(＝事業活動を行うための情報＝帳簿)にも目を向けるべき。
おそらく最後のポイントは、DDDを愚直にやろうとしたときに結構な人が誤解して通るんじゃないだろうか。結局ドメイン層じゃない部分にドメインモデルの知識が表現されてしまうのは有る有るだと思ってたが、鮮やかに説明されたとともに、本書のタイトルであるデータモデリングの位置づけがよく理解できた。
個人的な所感
以上、ピックアップを書きながら他にもまとめたい内容がちらほら有ったのだが、一旦ここまでとする。以下は所感や思い出話を書く。
思い出話(統合ERPの夢)
冒頭にも書いたが、自分は2010年代くらいはパッケージERPの導入支援をやっていた。SAP経験者と働くことも多く、本書を読んでいると色々な思い出が蘇ってきた。
- 「ERPで業務システムを統合しよう！」という号令でビッグバン導入を顧客に勧める。でも経験的には、1パッケージで統合しようとする案件ほど燃える事を知っている。そして統合したと言いつつ、現場業務は謎Excelや帳票ツールが現行維持のため残る。（この記憶があったのでSoAや残管理のくだりに有った著者の「分けるべき」という主張には強く同意する）
- 「この機会にマスタを販売管理システムの販売先マスタと会計システムの顧客マスタを統一しましょう」→地獄を見る。そして諦める。（これも同様の問題への言及が有った）
- お仕着せのBIダッシュボードは提案時は目を引くものの、たいてい使われない。いっぽうで顧客要望盛り盛りで作った帳票が経営判断に直結して活用されてる。そして改修要望がめっちゃ多い。（この時PC苦手な顧客が印刷したBIレポートを毎日保管して差分を見ていた記憶があったので「SoMで重視されるのはバージョン管理」という言葉の意味が少し理解できた。当時は内心小馬鹿にしていたが…）
本書のSoA、SoMのくだりだったり、色々なところで上記の思い出が蘇り、あれはそういう事だったのか、と今になって腹落ちすることが多かった。
エンタープライズに立ち向かう者への応援歌
また本書を読んで個人的に感傷的になったのは、業務システムに携わる人々への熱いメッセージが込められていたことだ(終章 ドメインを駆動する設計)。自分が似たようなメッセージと言うか、励ましを感じた書籍として思い出したのは「The DevOps 勝利をつかめ! 技術的負債を一掃せよ」で、この書籍も自分は大好きだ。（タイトルは邦題ではなく原題の「The Unicorn Project」のほうが好きだが…）モダンな技術も枯れたノウハウも全て駆使して、自社のビジネス課題と業務システムに立ち向かい続けるマキシンお嬢は最高にかっこいい。
この領域に光を当てる書籍（技術書）はそう多くないと思っているのだが、いずれもキャリアを通じて思い返す大事な書籍になることが多い。本書も自分にとってそういった一冊になりそうだ。
