« 「フィールド値の色」をテーブル定義に組み込む | トップページ | 「業務マニュアル」と「操作マニュアル」の違い »

2012.08.07

アンチパターン「大規模集積回路モデル」

 もう10年も昔の話だが、あるソフト開発会社の部長さんとおしゃべりしたときのことだ。その方はDOA(データ中心手法)の造詣が深く、私がその頃に書いた「データモデリング入門」を読んで興味を持ってくださったようだ。私もデータモデルのことならどんな話でも聞きたかったので喜んで会った。

 会うなり紙袋から取り出されたのは何やら分厚い紙の束で、彼はそれを嬉々として広げ始めた。テープでA3用紙を4×4枚でつなげたもので、その上には大規模集積回路のように輻輳したデータモデルが印刷されていた。

 それはまさに、ずっと昔に読んだJ・マーチンの技法書にあったアンチパターンの実例だった。「膨大な数のテーブルを含むデータモデルは、壁一面を占める形に張り出して他人に強い印象を与えるくらいの効果しかない」とその本では皮肉られていた。目の前でその実物がバリバリと音をたてて広げられるのを見ながら私は「おお、これが例のあれか!」と興奮していた。惜しいことに、そのときどんな話をしたかをほとんど覚えていない。広げられたその印刷物そのものの印象が強烈すぎたからで、J・マーチンが書いていたことは本当だったのだ。

 モデリングそのものが的確であるかどうかや、それを印刷するかしないかにも関係なく、たった1枚にまとめられたデータモデルはそれを設計した本人以外には役に立たない。データモデルというものは、テーブルの主キーと属性、およびテーブル間の関係を直観的に理解するための図面だ。ひとつのモデルにまとめたら、その上にあまりに多くのテーブルが置かれるゆえに、第三者が直観的に理解することは難しい。このアンチパターンを「大規模集積回路モデル」と呼ぼう。

 けっきょく、巨大な図面の「全体を見渡せる」だけでは問題は解決しないということだ。ちょうど「章立て節立てや段落のない大論文」を一挙に印刷出力してもその読みやすさが改善されないのと同じ話である。決定的な問題は「モジュール化」の観点が欠けている点にある。

 すなわち、テーブル数が数十個を越えたあたりから、業務システムの設計情報は機能的なモジュールに分けて管理されるべきだ。モジュール単体として、またモジュールの連係として、設計妥当性を確認できるようにするためだ。また何よりも、段階的詳細化の基本にしたがって、設計情報の第三者に対する可読性を高めるためだ。

 そしてこれはモデリング手法の問題でありながら、利用するモデリングツールの問題でもある。複雑膨大な設計要素を構造化して管理するための適切なまとまり――そういう概念が用意されている手法や設計情報管理ツールを選定することが鍵だ。またテーブル定義だけでなく、プログラム定義までを含めた形で設計情報をブロック化できるようでなければいけない。さらに、そのようなブロックを「実装されるべきモジュール」として扱える実装環境であれば理想的である。「設計情報管理上の論理的なまとまり」であるだけでは心もとないからだ。

 そういうわけで、「大規模集積回路モデル」の中のどこらへんを今見ているかを示すナビゲート機能とか、他人に変に強い印象を与える大凧風印刷物の出力機能には注意したほうがいい。それらは便利機能というよりは、本来不要なマッチポンプのようなもので、モデリング手法やツールの馬脚がそこに現れているだけなのかもしれない。

本ブログでの参考記事:
全テーブルが載っているデータモデルは便利か

|

« 「フィールド値の色」をテーブル定義に組み込む | トップページ | 「業務マニュアル」と「操作マニュアル」の違い »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: アンチパターン「大規模集積回路モデル」:

« 「フィールド値の色」をテーブル定義に組み込む | トップページ | 「業務マニュアル」と「操作マニュアル」の違い »