はじめに
今回は杉本 啓さんの「データモデリングでドメインを駆動する」(以降書籍と呼びます)を読んでいきます。
これまでの記事で、ドメイン駆動設計の基本的な思想や設計手法については書いてきましたが、実際に基幹システムを例にしてデータモデリングを行うとなると、どのように進めていけばよいのか、また、どのような視点でデータモデリングを行うべきなのか、といったことについては深く考えることができていませんでした。
今回は書籍をもとに基本的な概念の理解をしたあと、実際に弊社のようなPOSシステムのようなドメインだとどうなるのか、といったことについて考えていきたいと思います。
今回の記事の対象は1章から3章あたりまでを対象としています。
システムの分類
に登場する用語として、システムを分類した呼称がいくつか登場するので、まずは呼称について整理します。 読み進めるうえでも頻出し、英語の名称なので混乱することが多かったので、整理しておきます。
SoEとSoR
- SoE: System of Engagement
- 日本語に訳せば「関わり合いのシステム」です。
- 顧客やサプライヤーとの関係を構築するためのシステムです。
- SoR: System of Record
- 日本語に訳せば「記録のシステム」です。
書籍では基幹系システムをSoRとして位置づけています。
SoRをさらにSoAとSoMに分類する
書籍ではSoRを中心に扱いますが、その上でSoRをさらに2つに分類しています。
- SoA: System of Activities
- 日本語に訳せば「活動のシステム」です。
- SoRの中でも、業務の進行を支援するためのシステムです。
- SoM: System of Management
- 日本語に訳せば「経営管理のシステム」です。
- SoRの中でも、業務の進行を管理するためのシステムです。
書籍にも登場する通り、下記の表のような性質がシステムとして大きく異なります。
| 活動のシステム SoA | 経営管理のシステム SoM | |
|---|---|---|
| 扱うデータの粒度 | 細粒度(件別のデータ) | 粗粒度(要約レベルのデータ) |
| 集計パターン | 限定可能(多次元集計は必須ではない) | 多様(多次元集計が必須) |
| 適合するデータモデル形式 | リレーショナルモデル | リレーショナルモデル + 多次元データモデル |
| 記録の履歴管理 | 重要(修正は赤黒方式が望ましい) | 細かい修正履歴は重要ではない |
| バージョン管理 | さほど重要ではない(確定した取引事実の把握) | 重要(計画、見込の変遷を把握) |
基幹システムの多くはSoAにおけるデータ処理を主に念頭に置き、データの整合性を重視しているが、経営管理のシステムの要件にはさほどマッチしていません。そのために、開発における苦痛の割にユーザーにとって使い勝手が悪いシステムが数多く作られてきた、というのが書籍の主張です。
かなり抽象的なので、具体例もいくつか挙げられています。
システムに変更が加わるタイミングの観点から、SoAとSoMの違いについて考えてみます。まず、現場業務に合わせてSoAを設計します。そのため、現場での業務が変わらない限り、SoAは変更されることはありません。一方で、SoMは経営管理の要件に合わせて設計されるため、経営管理の要件が変わるとSoMも変更されることがあります。
例えば、在庫管理において、在庫の増減自体はSoA的な業務の流れに当たるものですが、例えば欠品が生じたときだけ補充するのか、売れ筋のものは多めに在庫を持つのかといった部分はまさしく経営管理の要件であり、SoM的です。
会計上、在庫の評価額を査定する方法はFIFO、LIFO、加重平均法などがありますが、これは経営管理の要件によって変わるため、SoM的な要件です。 この基準が変更されようとも、現場の業務のための仕組み、SoAはほとんど影響しないはずです。
SoAとSoMはソフトウェア設計で強調される「関心の分離」を基幹システムに適用したものだと書籍では述べられています。
書籍ではSoA、SoMのそれぞれの内容や具体例、業務プロセスや機能の違いについても詳しく記載されているので、興味がある方はぜひ読んでみてください。
「残」という概念
書籍に登場する重要な概念として、筆者は「残」という概念を挙げています。
業務機能の最小単位として、残を核として業務機能を分割していきます。
この「残」とは、未処理の業務対象です。 例えば受注してまだ未出荷のものは「受注残」、支払いがまだ完了していないものは「支払い残」といったように、業務の進行状況を表すものです。
得意先に出荷した商品に関しては請求がなされますが、入金までの間には「請求残」が残ります。入金までの間、未入金の請求残を把握し、入金遅れがないかを適宜チェックする必要があります。
このように、現場活動は残の管理と解消に駆動されて実施されています。残と業務機能が必ずしも一致するわけではありませんが、ある特定の残の発生から消滅までを管理する仕事の単位がSoAにおける業務機能の最小単位と言えます。
書籍ではSoAの分割の切り口として「残」に着目することを提案している点が特徴的です。ただ、この残は独自の概念ではなく、業務プロセスの分析手法としては一般的なものです。ただ、「残」が基幹システムの分割における最小単位であることが強調されている点が書籍の特徴と言えるでしょう。
これまでに「残」が最小単位として扱われてこなかった理由を書籍内で3つ挙げています。
- SoAとSoMを区別する視点が弱かったこと。
- 業務プロセスに着目すると業務の流れが第一の関心事になってしまい、残が最小単位である点が見えづらくなること。
- 業務責任を区分することのない日本の文化
- 欧米製の会計システムでは、経理業務に関するサブシステムが売掛金システム、買掛金システムというように分割されている。
- 日本の場合は処理の流れのほうが重要視されがちで、こちらのほうが効率的になるが、データに齟齬が発生した場合等の例外に弱い
POSシステムにおける「残」の概念
弊社スマレジのようなPOSシステムにおいても、残の概念で分割することができると思うので、具体例を挙げてみます。
在庫残
在庫残とは、店舗や倉庫において現在保管されている商品の数を指します。商品が売れた場合や新たに入荷した場合、在庫残は変動します。例えば、店頭である商品が販売された際にはその商品の在庫残が減少し、同時に「販売残」として記録されると考える事ができます。
また、倉庫から店舗に商品が補充された際には倉庫の在庫残が減少し、店舗の在庫残が増加します。在庫管理においては、複数の倉庫をすべて別物として扱うのかどうか、近くの倉庫は同じとして扱うのかといった運送ドメインと、販売に関わるドメインでは担当者が分かれているのが普通で、関心事が分離していると言えます。
注文残
注文残とは、顧客から注文を受けたが、まだ発送されていない商品やサービスの状況を指します。例えば、オンラインストアで顧客が商品を購入した際、その商品がまだ発送されていなければ、その商品は注文残として残ります。この注文残が発生するのは、商品の在庫切れや、発送準備、顧客からの特定の納品希望日などの要因があります。
基幹システムとしてはこれらの残を記録しておき、解消していく必要があります。
売上残
売上残とは、販売された商品やサービスの代金がまだ回収されていない状態を指します。POSシステムでは、顧客にクレジットカードや請求書払いのオプションを提供することがあります。この場合は販売が完了しても、代金が口座に振り込まれるまで売上残が残ります。また、商品の返品やクレジットカードの不正利用などの理由で売上残が発生することもあります。売上残が多い場合はキャッシュフローに影響を及ぼすため、ビジネス上非常に重要になります。
上記の様に、POSシステム上にも様々な「残」が存在し、それぞれの単位で管理することで責務を分割することができます。業務プロセスの中でどこに滞りが生じているかを可視化しやすくなり、問題が発生した際にも迅速に対応することができるでしょう。
弊社スマレジアプリマーケットでは、POS本体と連携できる様々なアプリを連携することができ、この仕組みはまさしく「残」の単位で管理されている個別のシステムを組み合わせて業務プロセスを構築することができます。
まとめ
今回は書籍「データモデリングでドメインを駆動する」の1章から3章あたりまでを読んでみました。
主にSoAとSoMの違い、そして「残」という概念について整理しました。
書籍には更に詳しい具体例や、業務プロセスの分析手法についても記載されているので、興味がある方はぜひ読んでみてください。
また、書籍を読みながら、具体的な例をPOSシステムを通じて考えてみることで、理解が深まったなと感じました。
次回は4章以降を読んでいき、また記事にしたいと思います。
