« 実装スキルと業務知識を統合するために | トップページ | 「生産管理」で業務知識の学びを効率化しよう »

2012.10.03

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

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

業務フロー(DFD)
Img_3379

データモデル(ERD)
Img_3380

業務定義(アクションツリー)とUI構成
Img_3381

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

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

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

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

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

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

|

« 実装スキルと業務知識を統合するために | トップページ | 「生産管理」で業務知識の学びを効率化しよう »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「データモデリングライブ@渋谷」報告:

« 実装スキルと業務知識を統合するために | トップページ | 「生産管理」で業務知識の学びを効率化しよう »