« 「仮想DB」としての開発用プラットフォーム | トップページ | プログラマの地位向上のためにやれること »

2011.05.13

企業システムに現れるフラクタル構造

 企業システムを、社会システムではなく純然たるソフトウエアとして眺める。遠目で見れば1個のソフトウエアでしかないが、拡大すると「いくつかのモジュールの相互作用」として見えてくる。オーソドックスな例としては、「会計管理システム」、「事業管理システム」、「人事給与管理システム」、「共通データ管理システム」といったモジュールの組み合わせとして見える。この階層のモジュールが、いわゆる「業務システム」と呼ばれるソフトウエアだ。

 企業システムを俯瞰している文脈において、業務システムは「サブシステム」である。「サブシステム」とはこのように「システムの直下の階層における構成要素」の意味で本来は使われる。つまり、「システム」や「サブシステム」の本質的実体が存在するわけではなく、システムと呼ばれていたものが文脈によってはサブシステムと呼ばれたり、その逆だったりもする。

 それはさておき、では1個の「業務システム」を拡大するとどんな風景が見えてくるのだろう。「プログラムの相互作用」だろうか。いやそれでは理解しやすいシステムとはいいがたい。なぜなら、業務システムの直下の階層(サブシステム)がいきなりプログラムだとしたら、構成要素の数として多すぎるからだ。段落のない論述文が読みにくいのと同じ話である。

  論述文  業務システム
  ↑     ↑
  段落   サブシステム
  ↑     ↑
  文    プログラム

 ゆえに、システムの可読性や保守性を高めるために、いくつかのプログラムの集まりの中間層を意図的に導入して、これを「サブシステム」とすべきだ。それがシステムを把握するための「章立て・節立て」になってくれる。たとえば「CONCEPTWARE/販売管理」には、以下の12個のサブシステムが含まれている。

№ サブシステム名      TBL  PGM
1 組織マスター管理      5   14
2 商品マスター管理      4   11
3 買掛残高データ管理     5   27
4 売掛残高データ管理     6   24
5 在庫残高データ管理     5   16
6 発注・入荷データ管理    5   25
7 受注・出荷データ管理    7   35
8 一般仕入取引データ管理   2   12
9 一般売上取引データ管理   2   11
10 一般在庫取引データ管理  5   27
11 統計データ管理      9   26
12 システム制御データ管理  10   22

 それぞれのサブシステムにはいくつかのデータ(テーブル)とメソッド(プログラム)とが含まれている点に注意してほしい。これらの上位階層を成す「業務システム」がそうであるように、サブシステムもまたそれぞれが「いくつかのデータとメソッドの複合体」である。したがって、業務システム内のすべてのテーブルや機能は、いずれかのサブシステムに所属するように強制されることになる。

 当たり前の議論に聞こえるかもしれないが、そうでもない。従来の業務システムの設計・開発環境において「サブシステム」はこのように重要なレイヤとしては扱われていなかった。欠落しているか、せいぜい「いくつかのクラスの集まり(パッケージ)」や「いくつかの機能を業務別にまとめたもの」程度の比較的ゆるいカテゴリーとして想定されていた程度で、「いくつかのテーブルと機能の集まり」として積極的に定義されるべき階層とはみなされていなかった。とくに、テーブルがいずれかのサブシステムに所属されるべき要素であるという考え方は、筆者は寡聞にして知らない。

 いっぽう、業務システムを設計する際に「いくつかのテーブルと機能の複合体」としてのサブシステム階層を活用することで、システムの可読性や保守性が高まることに筆者は昔から気づいていた。拙書「上流工程入門」でもそれを説明しているし、拙作のモデリングツール「XEAD Modeler」にもその設計方針が反映されている。

 そんな方法論やモデリングツールを駆使しながら設計するのであれば、開発ツールがその枠組みに追随していていれば理想的だ。ところが、上述のようなサブシステムを扱える開発環境もやはり聞いたことがない。そんなわけで、オリジナルの開発ツール「XEAD Driver/Editor」を自作しようと決めたときの課題のひとつが「実装されるべき実体」としてサブシステムを扱えるようにすることだった。

 では、なぜサブシステムを「いくつかのテーブルと機能の複合体」とみなすことが効果的なのだろう。キーワードは「フラクタル」だ。

 サブシステムの下位モジュールに相当するものは「プログラム」である。これもまた「いくつかのデータとメソッドの複合体」だ。つまり、「企業システム」→「業務システム」→「サブシステム」→「プログラム」と階層を一段ずつ降りてゆく過程で、同じ風景が繰り返し現れることになる。

 このように、どんなに拡大しても同じ構造が出現するあり方(フラクタル構造)を生み出す枠組みは、複雑膨大な構造物を組み立てるためのものとして筋がいい。なぜなら、拡大するたびにいちいち異質な風景が見えてくるとしたら、全体を理解するためのコストがかかりすぎるからだ。じっさいにXEAD Editorで眺めてもらえば、サブシステムの組み合わせとして眺めることでずいぶん見通しがよくなることを実感できるだろう。

Img110513

|

« 「仮想DB」としての開発用プラットフォーム | トップページ | プログラマの地位向上のためにやれること »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 企業システムに現れるフラクタル構造:

« 「仮想DB」としての開発用プラットフォーム | トップページ | プログラマの地位向上のためにやれること »