« 「趣味はシステム設計」くらい言えていい | トップページ | 開発手法と「クリティカル・スキル」 »

2016.10.05

タコヤキ業務にタコヤキテーブルは必要か

 前々回と前回の記事で紹介した「WEBサービス事業管理システム」のモデルと実装が、「CONCEPTWARE/サービス管理」として近日公開される(2016/10/12に公開済)。このモデリング課題にもとづいて大阪と東京でハンズオンセミナーを開催したわけだが、その中で気づいたことをひとつ紹介したい。DB構造が業務構成や機能構成に必要以上に引きずられてはいけないという話だ。

 1回目のセミナーではシステム要件をほとんど口頭で説明しただけだったのだが、2回目では時間の節約のために、あらかじめリストにしたものを事前に配布したうえでデータモデリングしてもらった。その一部が以下である。

・顧客に利用明細書を送付した時点で売上確定され、顧客は規定の銀行口座に利用料を振り込む
・利用料が未入金であるような顧客に対しては、適宜に督促メールを送信する

 4~5名で8チームに分かれてモデリングしたのだが、ほとんどのチームが「請求」と「入金」と「督促」のテーブルを置いていた。システム設計にある程度慣れている技術者であれば、このことを不自然と思わないかもしれない。しかし私はそれらのモデルを見て奇妙な感じがした。間違っていたように見えたからではなく、自分の発想とあまりに違っていたからだ。

 たしかに上掲の要件説明からは、「請求業務(利用明細書の発送)」、「入金確認業務(銀行からの入金報告の取り込み)」、「督促業務(未入金であるような顧客へのメール送信)」を切り出せる。それらの業務に対して個々にテーブルをあてがえることで、データモデルの基本形が出来上がるように思えるかもしれない。

 しかし、私はそのようにモデリングすることはない。要件からそれらの業務を読み取るところまでは同様なのだが、「どんな業務が求められているか」と「どんなDB構造が求められているか」とは、私にとって異質な問題である。支援される業務のことを考えつつも、DB設計については基本的にDB設計に固有な枠組みで捉えている。すなわち、それらの業務全体が規定する「関数従属性」や「ユニーク制約」にもとづいてデータ構造をまとめている。

 じっさい、私がまとめた「CONCEPTWARE/サービス管理」において請求・入金・督促を管理するための起点となるテーブルは、次図の「顧客別月次サマリ」の1本だ。もちろん、案件によっては「請求テーブル」や「入金テーブル」や「督促テーブル」を置くこともある。しかしそれはたまたまそのような構造が必要と判断したからであって、「タコヤキ業務を支援するのだから、タコヤキテーブルを置こう」といった機械的な発想はしない。
20161005

 同じように、ユースケース図から「ユーザが利用する機能」を認識し、それらについてテーブル構成を考えるといった発想もない。また、ある種のDB設計手法のように、「入金確認する」と言えるからには「入金確認」のイベントが存在するということだから、それを管理するためのイベントテーブルを置けばよい、といった考え方もしない(そもそも、あるデータがリソースかイベントかトランザクションかマスターかといった区別は、私にとってはどうでもいい問題だ)。そんな「字面」で分析的に考えても、包括的かつ効果的なDB構造を創案できるとは思えない。

 「データ構成(データの形)」と「業務構成(仕事の進め方)」と「機能構成(アプリの形)」とを、それぞれ固有な特性を帯びる直交軸として扱おう――これが、私の提唱する「三要素分析法」の基本テーゼである。業務構成を考えるときにはあるべき業務態勢としてまとめ、データ構成を考えるときにはあるべきDB構造としてまとめ、機能構成を考えるときにはあるべき機能の一覧としてまとめる。それでありながら、3要素間の牽制関係が満たされている。そのようなシステム仕様を「創造」することが、業務システム設計者の役割だ。

 その役割を果たすためには、「業務駆動」や「機能駆動(ユースケース駆動)」のようにプロセス指向的な発想では手に余る。DB構造が不必要に業務構成や機能構成に引きずられてしまうからだ。だいいち、業務や機能を切り出すたびにテーブルを追加していては、テーブルが無駄に増えてシステムの保守性が低下する(そんなシステムがそこらじゅうにある)。なによりもそういった分析的なやり方では、モデリングが持つクリエイティブな側面を味わえない。

 重要なので繰り返そう。そのシステムが「タコヤキ業務」を支援したり「タコヤキ機能」を提供するからといって、「タコヤキテーブル」が必要になるとは限らない。「データ構成」と「業務構成」と「機能構成」とは、精妙な牽制関係を持ちながらも、それぞれに固有な特性を帯びた異なる問題である。この考え方の有効性を理解してもらうためにも、「CONCEPTWARE/サービス管理」をダウンロードして、モデルのあり方やシステムの動作を確認してみてほしい。

|

« 「趣味はシステム設計」くらい言えていい | トップページ | 開発手法と「クリティカル・スキル」 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: タコヤキ業務にタコヤキテーブルは必要か:

« 「趣味はシステム設計」くらい言えていい | トップページ | 開発手法と「クリティカル・スキル」 »