« 業務単位は「疎結合」されている | トップページ | わかりやすさと論理性を両立させる(前編) »

2005.10.22

複数の視点で描かれた図面同士の牽制が重要

 データモデルは重要な図面ではあるが、業務システムというものを特定の視点で眺めた見方でしかない。これを描いただけではシステム全体を把握したことにはならないし、他の視点で眺めた見方に牽制されていないという意味で、データモデルとしての正しさもまたおぼつかない。特定の視点でモデリングしただけではまともなモデルは生まれないということだ。
RITTAI
 「上から見たら丸で、前から見たら四角で、横から見たら三角に見える立体」を想像できるだろうか。ちょっと考えるとありえない感じに思えるが、ふつうに存在する。

 3方向からまったく異なる見え方をする立体とはいえ、その異なり方にはけっこう制約がある。円の直径と四角と三角の底辺とが一致していなければならない。また、四角と三角の高さとが一致していなければならない。一般に立体の3方向からの見え方は、それぞれ独自でありつつも互いに一定の制約がある。

 業務システムの設計図についても同様のことがいえる。筆者が提唱する「三要素分析法」で作成される3つのモデル(業務モデル、機能モデル、データモデル)のあり方は、それぞれ独自でありつつも互いに一定の制約がある。立体と同様、同一の対象を視点を変えて眺めただけのものであるからには当然のことではある。

 これは、3つのモデルのうちのひとつだけを専門とする仕事が成立しにくいことを示している。業務フローだけを描くコンサルティングとか、パネルイメージだけを描いて実装してしまう開発法もあるにはあるが、筆者に言わせればいかにもアテにならない。データモデルを描くだけの仕事があるのかどうかは知らないが、あるとすればそれも危うい感じだ。

 なぜかというと、ユーザーの話にもとづいてそれぞれの視点でのあり方をまとめるだけの作業は「配慮すべき事項が少ないので容易すぎる」からだ。「こんな風に仕事を進めるような体制にしたい」と言われたらそれにもとづいて業務フローを見栄えよくまとめればいい。「こんな風なパネルにしてほしい」と言われたらもっともらしいパネルのモックアップを組み立てればいい。関係するデータ項目を挙げられたら適当に線をつないで「これがデータモデルです」と言って渡せばいい。これらの仕事を単独の仕事としてやることが許されるのなら、システム設計はなんて簡単な仕事かと思う。他の視点からの「牽制」がないので、描いたモデルの正しさを検証しにくい。ゆえに「描きっぱなし」で済む公算が高いからだ。

 「業務のあり方」と「機能のあり方」と「データのあり方」との整合性をはかることこそが、業務システム設計の難しさであり、本質でもある。じっさい三要素分析法において、先行してまとめられた業務モデルとデータモデルにもとづいて機能モデルをまとめる段階(機能モデリング)になると、作業はぐっと難しくなる。使いやすそうなデザインのパネルであればいいというだけではなく、業務手順の流れに沿っていなければならないし、テーブル構造と矛盾した形になってもいけない。機能モデリングの段階で、整合性をはかるためにデータモデルや業務モデルを描き直してしまうことも少なくない。

 三要素分析法は、業務システムの特性に合わせてモデリングの枠組みが最適化されているので、設計問題に対してガチンコで取り組める体系ではある。しかし、「設計全体の整合性のはかりやすさ」と「素人にとってのわかりやすさ」を優先している結果でもあるが、おせじにも「誰でも簡単に進められる体系」とは言えない。この手法を誰よりも活用している筆者でさえ、いまだに両耳から煙が出るほど頭を酷使しながらモデリングしている。しかしその過程の「三つどもえの制約感」がなんとも魅惑的でハマっちゃうのだよ、これが。

|

« 業務単位は「疎結合」されている | トップページ | わかりやすさと論理性を両立させる(前編) »

コメント

素朴な疑問です。
方法論の話から少しそれますが、渡辺さんは通常モデリング(というよりも要件定義)を何人ぐらいでやられてますか?
エンティティ数が300を超えるようなシステムになると、業務、機能、データをすべて一人で把握するのはかなり苦しいと思います。そんな場合には、業務/機能をサブシステムに分けて、それぞれを個別に担当するメンバー/チームを置き、それとは別にデータモデリングのチームを作って横串で整合性を取る体制で仕事を進める必要があると思います。でもって私はもっぱらデータモデリング担当なので、危うい人間なのかもしれません。自分でもその自覚はあります(笑)。

投稿: ひらさわ | 2005.10.23 01:08

ひらさわさん

ブロック間のデータ構成の整合性をとるためだけの専任を置ける力のあるベンダーはそれをやればいいとは思います。現実には、サブシステム別のチームが互いに共通な部分を時々集まって調整するという態勢で十分なのではないでしょうか。けっきょく業務構成や機能構成も調整されなければならないので。

いずれにせよ、そこらへんの分業体制の違いはベンダーの規模とか方針の違いから来るもので、たいした問題ではないと思います。

私がどうかと思うのは「三要素」のいずれかのみをまとめることで検収される受託サービスとか開発手順なんですよね。それは「牽制」がないゆえに簡単ではあるけれど危ういんじゃないかと。

投稿: わたなべ | 2005.10.23 10:22

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 複数の視点で描かれた図面同士の牽制が重要:

« 業務単位は「疎結合」されている | トップページ | わかりやすさと論理性を両立させる(前編) »