« DOAは自動生成の夢を見るか | トップページ | 妥当性検査をDB側に集約する »

2010.01.10

サブシステムを「使い捨てる」ためのアーキテクチャ

 友人から、最近の「薬品卸売業界」の話を聞いた。知られているように、規制緩和によって一部の薬がコンビニや電器量販店でも扱えるようになった。そうすると薬品卸売業としては、多様な販売先に対応したきめ細かい受注・出荷体制や棚割ノウハウの提供が求められるようになる。ところが、規制緩和したからといって国民がいきなり市販薬をより多く買うようになるわけではない。結果的に、新しいタイプの顧客からの売上が増えるいっぽうで、その分だけ既顧客からの売上は減る。

 その業界で生き延びてきた企業の多くは、販売管理システムを手作りすることでサービスレベルの向上をはかってきた。この経営方針は「サービスレベルを向上させつつ物流コストを抑えるためには、システムを手作りしたほうがまだトータルのコストを抑えられる」という経済合理性にもとづいている。しかし、この方針は売上高が右肩上がりで増大することを前提としている。より多様な顧客へのきめ細かい対応が求められつつ全体の売上が増えないのなら、こういう方針を維持できるわけがない。

 その結果、ごたぶんにもれずその業界でも再編の嵐が吹き荒れている。合併して売上規模を拡大することが、とりあえず生き延びるための方策だからだ。だが悪いことに、「顧客毎のきめ細かい対応」を強みとする企業同士が合併すれば、複雑化したシステム統合に手間がかかるし維持費もかさむ。だからといって出来合いのパッケージを使えば、これまでのサービスレベルを維持できない(維持しようと思えば莫大な修正コストがかかる)。

 まさに八方ふさがりという感じだが、これは一部の業界の特殊な事情などではない。他の多くの業界でも、規制緩和や法令改正によって企業の外部環境が劇的に変化しているし、企業合併も日常的だったりする。低コストかつきめ細かいシステムで自社の強みを維持していかなければいけない。そんな共通の難題をかかえている企業はいくらでもある。

 以上の課題を与件とした業務システムを実現しなければならない。そのために、「システム管理」「マスター管理」、「残高管理」、「取引管理」の4階層からなるアーキテクチャ(図)を意識したい。これは私の発明でも何でもなくて、経験を重ねたSEは自然にこのような形で業務システムのモジュール構造を考えるようになるものだ。

   ┌────────┐
   |  取引管理  │
  ┌┴────────┴┐
  |   残高管理   │
 ┌┴──────────┴┐
 │   マスター管理   │
┌┴────────────┴┐
│    システム管理    │
└──────────────┘
   4階層アーキテクチャ

 このアーキテクチャの眼目は、4つの階層が下から「変化しにくい順」にしたがって積み上げられている点にある。それぞれのレベルにはいくつかのサブシステムが含まれるが、どのレベルに含まれるかで変化のしやすさが異なる。すなわち、階層の最上位である「取引管理レベル」に置かれるサブシステムはもっとも変化しやすいモジュールとみなされている。上述した「顧客毎のきめ細かい対応」はこの階層のモジュールで実現すればよい。

 「CONCEPTWARE/販売管理」を例にすれば、この階層には「受注・出荷管理サブシステム」が含まれる。このサブシステムは、すべての商品とすべての顧客に対する受注・出荷を扱うための汎用的なモジュールなのだが、必要ならばこれをコピーして「X社向け受注・出荷管理サブシステム」といった特定顧客専用のモジュールを作り出せばよい。たとえば大方の「ふつうの顧客」を汎用的なモジュールで扱って、「ややこしい顧客」については専用のモジュールを用意してきめ細かく対応できるようにする。

 この場合、新たなサブシステムにおいてトランザクションテーブルが追加されることになるので、残高管理レベルのモジュールに対する変更が必要になる。売上実績や受払実績に、新しいトランザクションテーブルにもとづく取引区分を盛り込んで、売掛残高や在庫残高のテーブルにその区分に対応する残高項目を追加する。このように「4階層モデル」では、「取引管理レベル」のモジュールが追加されても「残高管理レベル」までの修正で済むケースが多くなる。もちろん、特定顧客向けのサブシステムなんかを追加すれば業務プロセスがそのぶん複雑になるが、「ややこしい顧客」からの利益が一定以上見込めるのであれば引き合う。

 「4階層モデル」においては、変化しにくい部分と変化しやすい部分を区別して、後者については「使い捨て」するくらいの気軽さで作ったり捨てたりできるようになる。データの移行やクリーニングのために「ゴミプロ」と称される一時処理用プログラムを作ることがあるが、ちょうどそんな感覚だ。安価な実装手段を提供するだけでなく、システムアーキテクチャレベルでも保守性の高さを追及したいところだ。参考にしてほしい。

|

« DOAは自動生成の夢を見るか | トップページ | 妥当性検査をDB側に集約する »

コメント

お世話になっております。
記事で紹介されている4階層アーキテクチャとは「業務システムのための上流工程入門」でサブシステム構成のパターンとして記述されている3階層モデルにシステム管理レベルの階層が加わったものでしょうか?
その場合、具体的にはシステム管理レベルの階層には、どのようなサブシステムが含まれるのでしょうか?

投稿: くまきち | 2010.01.11 21:56

くまきちさん

どもどもです。「システム管理レベル」には、システム変数のようなシステム全体に影響するマスターやセッションログなどを管理するためのサブシステム「システム制御サブシステム」が唯一含まれることになります。このサブシステムは案件毎の違いが小さいので、フレームワークにおいて作り置きされていたらよいでしょうね。

投稿: わたなべ | 2010.01.12 07:17

はじめまして、
最近XEADを利用するようになりました。
ニコニコして利用させていただいています。
「CONCEPTWARE」も素晴らしい内容で大変参考になります。
これまでは、設計図は頭の中だけ、せいぜいパワーポイントで思いついたことを記録する程度でシステム構築をしてきました。
業務をデータモデルとして分析することが必要なことは、実務の中で感じていました。
データモデリングの書籍も何冊か読みましたが、実際にその手法を自分自身で取り込むことは、困難でした。
XEADを使用させていただくようになり、その手がかりを得ることができました。
今までの作成手法は、「業務システムのための上流工程入門」のP.167にある「親子頻発型」のアンチパターンであることに気づかされました。
私には、XEADのようなツールなしには、これ以上の展開は難しいと思いました。
現行システムや新規作成中のシステムをXEADにて整理中です。
設計者の発言も楽しみに読ませていただいています。
素晴らしいツールの提供感謝いたします。ありがとうございます。

投稿: 黒麹 | 2010.01.27 18:02

黒麹さん

励まし感謝です。ニコニコしながらXEADを使っていただけてうれしいでっす(^^)

投稿: わたなべ | 2010.01.28 19:53

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: サブシステムを「使い捨てる」ためのアーキテクチャ:

« DOAは自動生成の夢を見るか | トップページ | 妥当性検査をDB側に集約する »