【告知】SEA関西ではOOA、関西IT勉強宴会はDOAの勉強会あります

SEA関西ではOOAのお話を児玉公信さんが講演されます。
関西IT勉強宴会では、ＲＤＢ理論を打ち立てたコッド博士の原論文を読んで議論するDOAの勉強会があります。
モデリングに興味のある方は、是非参加してみると良いでしょう。
以下、OOAとDOAに関してラフなメモ書き。

【元ネタ】
1月14日 第46回 SEA関西プロセス分科会(大阪府)

第13回関西IT勉強宴会 : ATND

【1】僕は、OOAからモデリングに入りました。
最初にきちんと理解して読めた本が児玉公信さんの本「UMLモデリングの本質」です。
そこから、OOAやDOA、ビジネスモデリングの本を片っ端から読んできました。

僕の中では、OOAは児玉公信さんの本、DOAは渡辺幸三さんの本がBestです。
お二方とも内容は抽象的ではなく、とても実践的です。
業務ロジックや業務が抱える問題をどのようにモデルに表現して、モデルからその本質を取り出すのか、とても詳しく書かれているので、とても役立ったからです。
そのモデリング方法を、児玉さんは「モデルの揺さぶり」と呼んでいたのが印象的。

【2】児玉公信さんの本は一通り読んだ。
「UMLモデリングの本質」で教わった点は二つある。

一つは、クラス図は抽象的な図なので、オブジェクト図やシーケンス図で具体的にイメージしながら整合性を取って書くべき、という点。
クラス図における継承関係は、オブジェクト図に書くと一つのインスタンスに過ぎない。
つまり、継承関係は具体例を抽象化した図なので、常に具体例を意識して書かないと、単なるお絵描きに過ぎない。
だから、インスタンスでクラスの関連を書くようにすれば、クラス図の品質は上がるだろうと思う。

もう一つは、アナリシスパターンの実例が具体的に書かれていてとても分かりやすかったこと。
例えば、知識・操作レベルの話は、クラスの集合とクラスの関係で表現できる。
「エリック・エヴァンスのドメイン駆動設計」では、知識モデルとはリフレクションをドメイン層に適用したものに過ぎない、という優れた指摘がある。

あるいは、勘定パターンは会計モデルだけでなく在庫モデルにも出てくる。
面白かった点は、航空機チケットの予約システムをモデル化すると、実は小売業や製造業の倉庫の在庫管理システムと似ている点。
航空機チケットもJRチケットもホテルの部屋も四季劇場のチケットも、そのチケットや部屋というのは論理的な在庫であり、常に予約されなければ売上につながらない。
すなわち、小売業の商品や製造業の製品は倉庫に長期間保持せずできるだけ早く販売するように、在庫回転率を上げるような経営戦略を取る必要があるという法則がモデルから導き出される点が面白かった。
ここから、ソフトウェア開発のモデリングがビジネスモデリングにつながるわけだ。

児玉公信さんの本としては他に「システム開発の見積りのための実践ファンクションポイント法」も良かった。
内容は、ER図とDFDからモデルの開発規模を見積り、そこから工数や納期へ変換する手法を解説している。
児玉公信さんはファンクションポイント関係の学会にも所属しておられるので、とても内容は深い。

モデルが見積りと関係する理由は、システム提案や要件定義のような上流工程でモデルを作れば、システムの開発規模が大体分かり、そこから本来の工数や価格を提示することが出来るからだ。
そして、ゆくゆくはファンクションポイントをシステムの開発規模を表す単位として貨幣のように流通できれば、システム開発を投げ売りにしたり、高価格で売ることなく、本来のあるべき価格で開発できるはず、という主張が面白かった。
つまり、モデルの利用目的としては、ビジネスの戦略のサポートだけでなく、規模見積りも行いたいという暗黙的な存在理由もある。

【3】渡辺幸三さんの本も一通り読んだ。
「業務別データベース設計のためのデータモデリング入門 」「生産管理・原価管理システムのためのデータモデリング 」の本がとても良い。

渡辺幸三さんの本から学んだ点は二つある。
一つは、DOAの方がOOAよりもはるかに制約が強いために、ビジネスルールを明確に反映しやすいこと。
下記の記事にも書いたけれど、2次識別子や暗黙的なリレーションシップ(継承属性とも呼ぶ)の使い方の解説は秀逸だと思う。

(3-1)ボイスコッド正規化は2次識別子の制約を課す
(3-2)継承属性を明示することで暗黙的なリレーションシップを見出す

DOAとOOAの違い: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

日本のソフトウェア設計では、OOAよりもデータモデリング中心。
でも、DOAをより深くまで知り尽くして設計しているとは到底言えないと思う。

ER図を見れば、設計者がどのように業務をモデル化したのか、分かる。
テーブルの構造や関連に業務ルールを入れ込んで制約を表現することで、業務データの一貫性や整合性を保持しやすくなる。
「ERPの本質は統合DBの構築にある」と主張する「楽々ERDレッスン」の羽生さんが言う通り、業務データの設計はまさに業務システムの設計に直結する。

もう一つは、業務システムのDB設計の背後には簿記の知識が絡んでいること。
「販売管理システムで学ぶモデリング講座」では、販売管理システムを対象にそのDB設計を詳しく説明している。
だが単に業務ルールをER図へ埋め込むだけでなく、会計の観点ではどのような意味を示しているのか、も詳しく書かれている点が秀逸。

特に倉庫への材料や製品の入出庫に関する受払業務は、簿記2級の工業簿記の知識がなければ、本当に理解できたことにならないと思う。
例えば、材料が倉庫へ入庫して買掛金が発生した場合、材料が倉庫から出庫して工場へ仕掛品ないし製造間接費として消費された場合、製品が完成して倉庫へ入庫して販売を待つ場合、製品が倉庫から出庫して販売されて売上が発生した場合では、それぞれのケースで会計の仕訳が発生する。
つまり、倉庫の入出庫のタイミングで、費用や資産、売上が計上されて、モノの流れとお金の流れが連携してデータが変わっていく。

「エリック・エヴァンスのドメイン駆動設計」でも、そのモデルの背後には会計知識が絡んでいる。
下記にも書いたけれど、「船荷証券」「発生主義会計(つまり、未払費用・受取収益のような経過勘定科目)」という概念がOOAでも本質的に出てくるのだ。

Agile開発に足りないもの～モデリング技術: プログラマの思索

だが、仕入や売上の割引や返品のように、業務にもシステムと同じように例外処理があり、それも考慮しなければ良いモデルとは言えない。
当然その業務にも仕訳があり、モノの流れと同じようにお金の流れもモデルに組み込む必要がある。

ERPの落とし穴part2～業務の裏には会計あり: プログラマの思索

OOAでもDOAでも、ソフトウェアの対象となるビジネスや業務をモデル化する技術を提供してくれる。
個人的には、モデル化に必要な技法(OOA・DOA)とモデルの背後にある本質的な概念(例：簿記)を区別してまとめたいなと思う。