« 「業務マニュアル」と「操作マニュアル」の違い | トップページ | 「データモデルなきアジャイル」の危うさ »

2012.08.18

データ中心アプローチと「業務モデル」

 前回のエントリーで「業務マニュアル」について説明したが、このドキュメントは「業務モデル」を整形して出力したものに他ならない。ほんらい重要な設計要素である業務モデルが、開発方法論の中でどのように扱われてきたか。個人的印象をおりまぜながら説明したい。

 1980年頃から、業務システム向けの新たな設計方法論としてDOA(データ中心アプローチ)が注目されるようになった。それまでは「DB構造は、事前に分析・設計されたデータの処理様式にもとづいて決定される」という考え方が主流だった。DOAはこれを「プロセス指向アプローチ(POA)」と呼んて批判した。

 POAに代わってDOAは「データの処理様式は、事前に分析・設計されたDB構造にもとづいて決定されるべきだ」と主張した。業務システムの開発においては「データのあり方(帳簿組織)」こそが一義的な設計課題であり、「機能のあり方(データの処理様式)」は従属的課題である――それは革新的かつ合理的な主張だった。自分たちが悩まされている保守性の悪いシステムが、POA的発想によって設計されたものであることも明白だった。私はDOAに一目惚れしてしまった。

 ただし、このときの「POA」はおおよそ「機能偏重」の姿勢として理解され、批判されていた。その批判じたいは有効ではあったが、「業務のあり方」をどう扱うべきかの観点が希薄だった。旧来の考え方には業務設計の視点も豊かに含まれていたはずなのだが、私にはDOAが問題を「データ設計と機能設計のどちらが大事か」という単純な二元論に矮小化しているように思えた。

 その後、試行錯誤を経て私がたどりついたのは「DOA的に『データのあり方』を確立しつつも、『機能のあり方』と『業務のあり方』までを明確にし、これらを互いに整合させる」という設計方法論だった。私はこの技法をDOAの発展形として「3要素分析法」と呼んで、これを支援するモデリングツールXEAD Modelerを自作した。Excel方眼紙やデータモデリングツールといった単機能アプリでは、多次元の広がりを持つ膨大な設計情報を管理し切れないことが明らかだったからだ。

 何のことはない。「2つのうちのどちらが大事か」ではなく「大事なものが3つあって、それらをいかに摺り合わせるか」が問題だったという話だ。前回記事の図に合わせて模式化すれば次のようになる。

20120818

 これらの3要素は、それぞれ固有の記述様式を持ちつつ、相互に「多対多」で関連する。したがって、相互に突き合せることでしか個々の妥当性も全体の整合性も見えてこない。遠回りした感じだが、この認識にはDOAでの開発経験を経ることでしかたどりつけなかっただろう。なにしろ「データのあり方」を独立した設計課題とする見方さえ、かつては想像を絶していたのだから。

 時は流れ、このところ「BPM(business process management)」が注目されている。そこで言う「ビジネスプロセス」とは、上述した「業務のあり方」に相当する。こんにち「プロセス指向」という言い方を耳にするとしたら、それは「業務のあり方をしっかり押さえよう」というまともな姿勢を示すもので、かつてDOAが批判したPOAとは意味合いが異なっている。

 それでも私は「イマドキのPOA」にも満足できない。業務システム開発というものが「業務のあり方さえ押さえたらうまくいく」と言えるほど単純な課題ではないからだ。それはかつてDOAによって批判された「機能のあり方さえ押さえたらうまくいく」と同程度にアマい観測と言わざるを得ない。

 「業務の形(業務モデル)」だけでなく、「処理されるデータの形(データモデル)」や「処理するための道具の形(機能モデル)」までを確立し、相互に摺り合わせる。もちろんそれじたい簡単な作業ではないのだが、これらの3要素さえ整合的に押さえておけば、基本設計レベルのミスはよほど軽減できる。必要なものは、手早く要件を洞察しモデルに落とし込むための技術、そして各設計要素を統合的に管理するための設計支援ツールだ。

|

« 「業務マニュアル」と「操作マニュアル」の違い | トップページ | 「データモデルなきアジャイル」の危うさ »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: データ中心アプローチと「業務モデル」:

« 「業務マニュアル」と「操作マニュアル」の違い | トップページ | 「データモデルなきアジャイル」の危うさ »