「データモデリングライブ＠渋谷」報告

　先日開催した「データモデリングライブ＠渋谷」では「ライセンス管理システム」を取り上げた。有償ソフトウエアの手配やインストールを管理するためのシステムである。ハードウエア管理も含むので、資産管理システムに発展できるかもしれない。規模的にも複雑さでも適度なネタで、休憩をはさんで延べ３時間で描いたモデルの最終形は以下のとおりである。

業務フロー（ＤＦＤ）

データモデル（ＥＲＤ）

業務定義（アクションツリー）とＵＩ構成

　これらが「さんざん描き直された結果」であることに注意してほしい。じっさい、いかに高速に変化していったかを目撃しない限り、モデリング過程の効果は理解してもらえないだろう。もちろんそれなりにうまくまとまったのは、ひとえにエンドユーザ役として鋭いツッコミをどんどん入れてくれた参加者２０名の方々のおかげである。

　描きながらときどきモデリングのコツみたいな話をしたのだが、今回とくに説明したのは「事前に現状分析しなくてもモデリングできる」という点だった。ある種のモデリング技法は、現行の帳票やパネルの仕様、あるいは現行のＤＢ構造を参照することを前提にしている。ところが私が提唱するスタイル（三要素分析法）では、ユーザとおしゃべりしながら「To-Beモデル（あるべきモデル）」をいきなり描き始める。

　なぜそれが可能かというと、どんなシステムにしたいかについてはユーザが教えてくれるからだ。知らないことがあればどんどん訊けばいい。それでもわからないなら、あてずっぽうで描き広げてデッチアゲてしまえばいい。アカラサマにおかしい絵になればユーザがダメ出ししてくれる。そのときにはどんどん修正すればいい。このようにモデルの記法は一義的には「技術者同士がわかりあうため」ではなく、「ユーザと技術者がわかりあうため」にある。

　もちろん、現状分析（As-Isの調査）が不要という話ではない。現状分析は、To-Beモデルがまとまった「後」で実施して、モデルを精緻化するためのダシとして使いたおす。しかしこの順序を逆にしてはいけない。To-BeがAs-Isに変に引きずられしまうからだ。そんな調子では「タテのものをヨコにする」程度のカイゼンしか生み出せない。ふつうの「刷新プロジェクト」はそんなものは求めていない。

　モデリングというものは、本来は「生成的」というか「創造的」な営みである。そのような作用を発揮できない技法を使えば、現状分析を先行させ、かつ要件定義を緻密に実施せざるを得ない。そういったやり方では、分析工数が嵩（かさ）むわりに、ユーザの「思い」をしなやかに取り扱えない。「通り良き管（くだ）」としてのモデラーの役目も果たせない。ユーザと対話しながらその場でモデリングしてフィードバックするというスタイルこそ、彼らの曖昧模糊とした思いに形を与えるための最善の方法である。

　好評だったので、東京でもときおり開催したいと考えている。業務システムの分析・設計について関心のある方はぜひ参加してほしい。また、地方でも積極的に開催したいので、興味を持たれた方は連絡してほしい。