はじめに
本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。
本記事で一番伝えたいこと
- データモデリングについての考えが深まるぞ
- 開発者が読むともっと役立てることができると思うぞ
- QAエンジニアである私が読んでも役立つぞ
目次
本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい
本書籍では、データモデリングをするにあたっての思考の整理が素晴らしかったです。また、整理するにあたり、筆者の考えを元にした様々な用語の提案がされています。その提案は具体例を添えて語っており非常に分かりやすく、かつ納得のいく提案に感じました。本記事では、特に響いた部分を記載します。
SoAとSoMという整理
一般的に、「SoE（Systems of Engagement、関わり合いのシステム）」と「SoR（Systems of Record、記録のシステム）」という区分がよく聞かれます。SoEとSoRの詳細な説明は他記事に任せるとして（ググれば出てきます）、本書籍ではSoRをさらに「SoA（Systems of Activities、活動のシステム）」と「SoM（Systems of Management、経営管理のシステム）」に分けて整理しています。このSoAとSoMという考え方が、書籍全体の核となっています。
書籍の中で、「なぜSoRをSoAとSoMに分けて考えるべきなのか」に明確に答えています。書籍内に書かれている分かりやすい題材を元に、私は「SoAとSoMは、関心を持っている対象も、データとしての表現の仕方も異なっている」ということを理解できました。
詳しくは書籍を読んでもらえればと思います。書籍全体で語っているものの、第4章と第5章あたりを読むと特に理解できるかもしれません。
「残」という概念
筆者は、書籍の中で「残」という概念を提案しています。書籍を読んで理解した範囲内で、「残」について説明してみたいと思います。以下で載せている例は、書籍内の表現ではなく、私が勝手に例示している点にご注意ください。
例えば、ECサイトで何か商品を購入した場合を考えてみます。この時、クレジットカード会社から入金がされた時点でECサイトの運営会社においてはお金について作業が残っていません。これを「お金の残が無い」と表現します*2。一方で、購入が発生した時点ではまた商品のお届けがされておらず、商品の残作業があります。対面の販売のようにお金と商品がリアルタイムで交換されているわけではないからです。この時、「注文商品については残がまだある」と表現しています。
このように、1つの注文を見ても、商品にはタイムラグが生じます。本書籍では、これを「残」という概念で表現しています。また、注文という部分以外にも目を向けると、在庫管理についても「残」が発生するかもしれません*3。この「残」の管理をする（「残」が発生してから解消されるまでを管理する）ために、システムを導入しているといえるのです。
私の拙い説明ではイメージしづらいかもしれません。ただ個人的には、書籍を読んで、この「残」という概念は非常に腹落ちしました。書籍では私の数倍うまく説明していますので、詳しくは書籍を読んでください。第4章あたりに書いてあります。
データベース設計とは違う「データモデリング」という考え方
一般的に「どのようにデータを扱うか」と考えると、データベース設計に注目しがちです。しかし、本書籍では、データベース設計とは別の「データモデリング」という考え方を丁寧に説明しています。あくまでもデータモデリングは帳簿のデザインであると解説しています。それにより、データベース設計で発生する技術的関心事と分離を行うこともできます。
しかし同時に、本書籍では「データベース設計が不要である」とは主張していません。どのように使い分けて行なっていくのかについても本書籍では丁寧に説明していますので、詳しくは書籍を読んでください。第3章や第11章あたりと第8章の一部に書いてあります。
QAエンジニアとして、業務に役立てそうなこと
私はQAエンジニアです。開発者とは違い、システム自体を開発していません。そんな私にとって、「どのように開発者が設計をしているのか」という部分以外に、本書籍の内容が役立てる（応用できる）部分があるように感じました。それを述べていきます。
「業務プロセスは業務機能を横断する」をシステムテストに応用する
「2.2 活動のシステム(SoA)は現場活動を支える」の中では以下のように解説しています。
業務機能の分割は「残」に基づく
業務プロセスは業務機能を横断する
これをテストレベルに当てはめると、業務プロセスのテストがシステムテストレベルに当てはまるように感じました。業務機能の分割を行い、テストをした上で、業務プロセスのテストを行うのは理にかなっていそうな気がしました。特に図2-2-2のような表現は勉強になりました。
データモデリング作成時の思考とテスト要求分析時の思考は似ている
「3.2 ユーザーインタフェース設計だけでは帳簿をデザインできない」の中で以下のように述べています。
画面や帳簿のデザインは、業務の流れ（ユースケース）に依存します。一方で、帳簿の構造は、基本的には業務の流れに依存しないようにデザインするほうが良いのです。
画面や帳票の設計は帳簿デザインではないと述べましたが、逆に帳簿のデザイン--データモデリング--に際して、画面や帳簿のスケッチを利用することは、有用ですし、多くの場合、極めて重要でさえあります。
これは私がテスト要求分析を行う時の思考に似ていると感じました。私が行なっているテスト要求分析の考え方については以下をご覧ください。
イケてない部分
ここまで良かったことを書きましたが、イケてないと感じた部分も書いておきます。ただしどれも技術的におかしいことを書いているわけではなく、言いたいことをうまく伝えきれてないなーと感じた部分です。
「帳簿」という言葉から受け取るイメージに乖離がある
私が商業に詳しくないが故かもしれませんが、私の中では「帳簿＝会計帳簿」というイメージが強く、「会計帳簿以外にも帳簿の概念がある」ということを理解するまで時間がかかりました。
「データモデリング」と「データベース設計」の区別が付いていない読者へのフォローが少ない
「データモデリングでドメインを駆動する」という書籍名だけだと、「データベース設計の本かな？」と想像してしまいました。データベース設計の本だと感じて手に取らない人が出てきたら勿体ないと感じました。
データベース設計とは違うということは「はじめに」で1行だけ述べており、その後は第3章まで読まないと理解できませんでした。例えば「1.2 データモデリングはなぜ必要なのか」でフォローしても良いように感じました。
第5章の説明が難解
第5章「経営管理のシステム(SoM)」が他の章に比べて少し読みづらかったです。
この点については筆者も認識している点なので、ここでは詳しく言及しません。
Amazonでの書評で、第5章「経営管理のシステム(SoM)」でつまづいたというものがありました。すみません。これはそうかもしれない。第5章は、こなれ方が足りないのかも。あまりこだわらずに読み進めて頂ければと思います。第5章が分からなければその後の章が分からない、というものではないので。
— 杉本啓 (@sugimoto_kei) 2024年3月5日
おわりに
最後に「イケてない部分」を書きましたが、総じて非常に良い本だと感じました。今のところ、2024年のベストバイな気がします。
QAエンジニアにとっても、実装から目を離し、業務から見つめ直せる点で、有用だと思います。
ちなみに、5/28に本書籍の読書感想会のイベントがあるようなので、気になる方はこちらもぜひご参加くださいませ！*4
