この本の概要
この本では、業務システムの設計をどのように進めるか提言している。 難しくてまだ途中までしか読めていないが、今読んだ範囲での感想を書いて学びを落とし込んでいく。
おすすめしたい人
- 業務システムの設計に悩んでいる方
- 業務システムの要件整理、システムへの落とし込み方に悩んでいる方
学んだこと
SoAとSoM
基幹システムはSoA（活動のシステム）とSoM（経営管理のシステム）に分かれる。
この本では主にSoAを扱う。 SoAは業務プロセス層と業務機能層で成り立っている。
業務プロセスは業務フローのことであり、受注管理、在庫管理、発注管理、売掛金管理などに分かれる。 業務機能の分割は残に基づく受注残、在庫残、発注残などがある。残とは、活動の記録。
現場活動は残の解消を目的に動いている。 特定の残の解消に向けての仕事の単位を業務機能の最小単位として切り出すことができる。1つの仕事で1つの責任を完結することが保証されることを前提に仕事の分割は行われる。 業務プロセスではなく残を軸とするとで、責任の所在を明確にすることができる。
帳簿
残を管理するのが、帳簿だ。
帳簿デザインの進め方は3つある。
- 帳票/画面などのUI設計ベース
- DB設計ベース
- データモデルベース
画面や帳票は、特定のユースケース・業務プロセスのために設計するので、ユースケース・業務プロセスへの依存性が高くデータの定義が不安定である。 帳簿は業務の流れに対して横断的な要件を満たすために存在し、複数業務に対して1つしか存在しない。ユースケース・業務プロセスへに依存しにくい。データ定義が複数存在しうる画面や帳票とは別で帳簿を設計すべきである。
DB設計は技術的な関心が混ざってしまうため、純粋に残と向き合うには帳簿デザインとDB設計は分けるべきである。
感想
- 残念ながらこの本を読破するには自分の抽象化能力がまだまだ足りないことに気づいた。今までやってきたシステム開発の具体的な事例と、この本で書かれている中小を行き来しながら読み進めていきたい。
- 画面デザイン・帳票デザインと帳簿は異なるというのはとても共感する一方、画面デザイン・帳票デザインには重きを置く一方帳簿デザインをする工程を含めないプロジェクトもあるなあと思います（私も経験があります）。前者は目に見えるものなのでイメージしやすいけれども、後者は前者ほど具体的なイメージがつきにくいのがステップを省いてしまう原因かも？と思いました。
- 帳簿デザインをするだけの工程がどうしてもとれない場合、「画面デザイン・帳票デザインがあれば実装できるはず」ではなく、実装に入る前に帳簿デザインを考えてデザイナーやプロダクトオーナーに確認してから実装に入るなど、どうやったら帳簿を考える機会を作れるか考えたい。
