業務システム設計に関する本

業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。
プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。

特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。
理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。
つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。

僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。

【1】グラス片手にデータベース設計編

グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)は、業務システムの中でも最も一般的な販売管理システムの業務をDBスペシャリストの観点から説明している。
著者の梅田弘之さんは、SI Objectブラウザの開発者らしいから、Oracleに強いのだろうと思う。
ER図はIDEF1なので正直読みづらいが、DFDや業務の説明は分かりやすい。

グラス片手にデータベース設計 ~会計システム編 (DBMagazine SELECTION)も同じ著者で、業務システムの中でも難しい部類である会計システムの業務をDBスペシャリストの観点で説明してくれている。
会計業務を説明している他の本は、会計士の観点だったり、簿記の知識がないと分かりにくかったりしてイマイチだった。
やはり、システム設計の観点、つまりデータモデリングの観点で書いてくれている方が読みやすいし、その方が実践で役立つ。
僕らの仕事は、お客様の業務を理解するよりも、いかにシステムへマッピングするか、という技術力が根底にあるから。

同じ著者で、グラス片手にデータベース設計 生産管理システム編 (DB Magazine SELECTION)があるけど、まだ読んでない。
今度読んでみたいと思う。

【2】渡辺さんシリーズ

業務別データベース設計のためのデータモデリング入門は、商品管理、販売管理、在庫管理など基本の業務に関するデータモデリングの本。
僕が初めてデータモデリングを勉強し始めた時に使った本。
ER図は渡辺さん独特の記法だが、具体的なデータも列挙してくれているので分かりやすい。

業務システムのための上流工程入門―要件定義から分析・設計までは、上流工程の要件定義やDB設計に重点を置いた本。
要件定義やDB設計ではまりやすいポイントを解説してくれている。

生産管理・原価管理システムのためのデータモデリングは、生産管理に関するデータモデリングの本。
MRPの仕組みについてとても詳しく書かれている。
生産管理は、データモデリングの中でも会計システムと並んで最も難解な分野。
製品や部品と言うマスタデータと、工程というプロセスに関するデータをいかにRDBに落としこんで、設計するか？

Oracleにある再帰SQLを使う場面があった時、この本を参考にした。
生産管理・原価管理システムのためのデータモデリングは全部理解できていないけど、時々読み返しては気付きがある。

業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題は、家計簿や医療システム、プロジェクト管理システムなどをデータモデリングの観点で解説してくれている。
実際の業務を分析しながら、ER図をどのように作っていくか、という観点がとても分かりやすい。

渡辺さんが作ったER図をRailsで実装すれば、Web上で簡単に動かせるので、業務システムのイメージを理解しやすくなるだろう。

【3】羽生さんシリーズ

楽々ERDレッスン (CodeZine BOOKS)は、DB正規化に関する説明と帳票(レシート)からER図を起こす実践例が非常に素晴らしい。

DB正規化で、コード体系とアイデンティファイアを区別しようと言う説明が出てくる。
コード体系は、ユーザが自分の業務の観点からユニークに作ったキー。
アイデンティファイアは、RDBのシーケンスであり、業務とは無関係なキー。

Railsでは複合キーと言う概念がない点は、DOA屋から非難される時があるが、昨今のWebシステムの現状を考えるとその方がいいと思う。
Railsで具現化されたRESTfulという設計思想とアイデンティファイアという発想はとても相性がいいからだ。
理由は、Web上で任意のデータにアクセスする時、リクエストパラメータはユニークなキーであるアイデンティファイア一つだけでいいからだ。
複合キーの場合、複数のキーをリクエストパラメータに渡さないといけないので、URLが醜くくなる。

そして、レシートからER図を起こす練習問題が素晴らしい。
コンビニのレシート、ファーストフードのレシート、病院のレシートから、業務を類推して、ER図を書き起こす。
この作業はプロならば3分で思いつかないといけないと羽生さんは言っている。
僕ももっと修行しなければならない。

データモデリングをマスターしたいならば、Railsで勉強した方が良いと思う。
ER図からマイグレーションのプログラムを書いて、DBスキーマを一発生成し、scafoldでCRUD画面を作る。
Web画面上でデータの遷移を見れば、データと業務の関係が見えてくるはずだ。

そんなことを思いながら、昨今の設計は実装にますます近くなっている気がする。
DB設計で悩むぐらいならば、RailsでプロトタイプのWebシステムを作り、実際にシミュレーションすればいい。
DOAとRailsはとても相性がいいはずだ。