« 「アジャイルなスクラッチ開発」ではダメ | トップページ | 業務システムとWEBサービス »

2011.10.11

語られないアーキテクチャの謎

 業務システム開発の世界でも「アーキテクチャ」という言葉がふつうに使われるようになった。この場合のアーキテクチャとは「ソフトウエアのコンポーネント構造やそれらの相互関係に関する基本方針」くらいの意味なのだが、業務システムのように複雑で巨大なソフトウエアを効率的に開発・保守してゆくためには、アーキテクチャが適切にプランされていなければいけない。

 私が不思議に思うのは、アーキテクチャが「フレームワーク」のレベルで饒舌に語られるわりに、「アプリケーション」のレベルでほとんど語られない点だ。

 ここで言う「アプリケーション」とは、「全社システム」やその1モジュールである「営業管理システム(生産管理システム等の企業の本業を支援するシステム)」のようなソフトウエアのことを言う。いっぽう「フレームワーク」とは、ここでは「アプリケーションを開発するためのミドルウエア」を指している。「実装基盤」と呼んでもいい。

 では、「アプリケーションのアーキテクチャに関する語り」とはどんなものか。たとえば全社システムのコンポーネント構造に関して、以下のように検討されたりする。

      ┌─────────────┐
  レイヤ3|     会計管理    │
     ┌┴────┬────┬───┴┐
 レイヤ2│人事・給与│財務管理│営業管理│
    ┌┴─────┴────┴────┴┐
レイヤ1│     共通データ管理     │
    └─────────────────┘

 全社で共通利用されるデータは最下層の「共通データ管理」のサブシステムで扱われ、これが上位のレイヤ2に必要なデータを提供する。レイヤ2で発生した実績データが、さらに上位のレイヤ3(会計管理)で扱われる。つまり、図の上で上位のモジュールが下位のモジュールで扱われるデータを参照する、という関係にある。アーキテクチャなどと気取って呼んでいるが、ようするに「ソフトウエアの論理的なモジュール構造」くらいの意味だ。

 図の上で、財務管理システムと会計管理システムが分かれている点が不思議に思われるかもしれない。ここで言う財務管理モジュールとは、企業の資産を管理するためのもので、いわゆる「制度会計」のしくみを概念上含んでいない。ふつうは財務管理と制度会計とを包含した会計パッケージが導入されるので、実装としては上図の構造をとらない。しかし、論理的には上のような構造として考えると全社システムのアーキテクチャとしてわかりやすい。本来は、制度会計や管理会計のしくみは、レイヤ2のすべてのモジュールからデータを参照するレイヤ3に含まれる、と考えたほうが適切だ。

 なお、それぞれのモジュール(営業管理システム等の個々のサブシステム)毎のアーキテクチャもまた、アプリケーションのレベルでじっくり検討されるべき設計課題である。本ブログの記事「サブシステムを使い捨てるためのアーキテクチャ」では以下のような基本構造が提示されている。

   ┌────────┐
   |  取引管理  │
  ┌┴────────┴┐
  |   残高管理   │
 ┌┴──────────┴┐
 │   マスター管理   │
┌┴────────────┴┐
│    システム管理    │
└──────────────┘

 このアーキテクチャにもとづく卸売業向けのサブシステム構造は次のようになる(単純にするために一部のサブシステムが省略されている)。多種多様なデータ処理プログラムをいかにブロック化するかだけでなく、それぞれのモジュールが扱うべき帳簿組織(データモデル)までが強く意識されている。つまり、これらのサブシステムは「プログラムの集合体」ではなく、「プログラムとテーブルの集合体」なのである。

    ┌─────┬──────┬─────┐
    |発注・入荷│ 在庫取引 │受注・出荷│
  ┌─┴────┬┴──────┴┬────┴─┐
  | 買掛管理 │ 在庫残高管理 │ 売掛管理 │
 ┌┴──────┴────────┴──────┴┐
 │         マスター管理         │
┌┴────────────────────────┴┐
│          システム管理          │
└──────────────────────────┘

 とまあ、こんな調子で「アプリケーションのアーキテクチャ」は語られるはずなのだが、なぜかほとんど聞かれない。いっぽうの「饒舌に語られるほうのアーキテクチャ」、すなわち「フレームワークのアーキテクチャ」とはどんなものか。

 それは、MVCとかDAOとかサーバといった用語で語られる問題だ。アーキテクチャの用語を冠して語られる言説のほとんどがここらへんの領域をターゲットにしている。いわゆる「ITアーキテクト」と呼ばれる人々の語りもフレームワークまわりに集中している。みんなが大好きな問題だ。

 たしかにそこらへんの話題は技術的に興味深いのだが、あくまでも「前提となる実装条件」でしかない。フレームワークの選定段階ではアーキテクチャを比較検討することにも意味があるが、いったんいずれかに決めてしまえば、開発時にはほとんど意識する必要はない。いちいち意識しなければ開発できないとすれば、ミドルウエアとして出来が良いとは言いがたい。

 いったん利用すべきフレームワークを決めてしまえば、次の検討課題はアプリケーションのアーキテクチャである。これらは直交関係にあって、前者のアーキテクチャが後者のアーキテクチャまでを規定したりガイドしたりしてくれるわけではないからだ。そして、アプリケーションのアーキテクチャが適切でないとすれば、システムの保守性や拡張容易性に隠然と悪影響を与え続ける。

 にもかかわらず、アプリケーションのアーキテクチャは表立って語られることがほとんどない。なぜ「売掛残高データ管理サブシステムをモジュールとして切り出そう。そこには売掛残高テーブルとその管理機能を置こう。なぜならこうすることによって...」といった議論が聞こえてこないのだろう。そこらへんは自分が悩むべき問題ではないとでも思われているのだろうか。それとも「アジャイルだから考える必要はない」とでも思われているのだろうか。

|

« 「アジャイルなスクラッチ開発」ではダメ | トップページ | 業務システムとWEBサービス »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 語られないアーキテクチャの謎:

« 「アジャイルなスクラッチ開発」ではダメ | トップページ | 業務システムとWEBサービス »