読終えてふと思った。
著者（渡辺さん）は、この本を書くより実際に販売 管理システムを作った方が楽だったに違いない。
 | 販売管理システムで学ぶモデリング講座 渡辺 幸三 翔泳社 2008-05-29 Amazonで詳しく見る by G-Tools |
「業務システム本」はいくつか世に出ているが、具体的なシステム設計の説明にここまでこだわった本は、他にないのではないか。
著者のねらいは、販売管理システムという具体的な例を通じて、著者が提唱しているシステム設計記法（三要素分析法）の実用性を実証 することにある。しかしそのねらいを達成する手段として事例の具体性にとことん拘ったが故に、ダシというには面白すぎる素材がこのサ ンプルシステムに含まれることになった。
僕が特に注目したいのは、販売管理における各種取引を、売上（売掛金）・仕入（買掛金）・在庫という３つの企業財産に与える影響と いう視点から分析していく手口だ。
ちょっと脇に逸れるが、会計の世界、特に欧米流の会計では、会計業務の責任をB/S勘定別に分割する考え方があり、Accounting Department は、Accounts Payable（A/P: 買掛・未払金） 担当とか、Accounts Receivable（A/R: 売掛・未収金） 担当といった具合に職務分 割されることが多い。欧米系 ERPパッケージもそのような職務分割を反映した構成になっている。一方、日本では、売上取引・仕入取引と いった取引の種類別に（経理以外の部門も含めて）業務分担することが多い。
欧米流の勘定別責任分割アプローチでは、いったん分割された業務をどうやってつないで効率的な業務プロセスを実現するかが問題にな るし（例えば、未収金と買掛金の相殺はA/R担当者とA/P担当者にまたがる業務になる）。日本流の取引種類別責任分割アプローチでは、各 B/S勘定の残高を管理する責任の所在について曖昧な部分が残らないよう注意が必要である（内部統制が重視される今後は特に）。
話を戻すと、著者が示す販売管理システムの設計は、基本的には日本流に取引基準で業務を分割しながら（そのために「取引管理No.」 を導入する）、その一方、裏側ではB/S勘定別に（すなわち、売掛金・買掛金・在庫について）増減を記録し、取引と増減明細を巧妙に紐付 けていくという思想に貫かれている。概念的には、取引処理レイヤと勘定別管理レイヤの二階層構造になっているわけで、上述した欧米流 と日本流のハイブリッドモデルである。
アプリケーションシステムの姿かたちについてのこういった思想こそが、アプリケーションにとって真に「アーキテクチャ」の名に値す る。システムのアーキテクチャといえば従来は、ユーザインターフェース層、ドメイン層、データアクセス層からなる三層アーキテクチャ が良いとか、いや四階層なんだといった話が中心だった。これら、従来型のアーキテクチャ論議は多岐にわたるが、そこで語られる「アー キテクチャ」のほとんどに共通する特徴がひとつある。「ユーザから見えない」ということだ。アーキテクチャとかアーキテクトといった 用語は例によって建設業界から借りてきたものだと思うが、それにしてもこの転用はいかがなものか。「ＩＴ業界では、アーキテクトはユ ーザに見えない部分を設計するんですよ」と、あちらの業界のアーキテクトに言ったら妙な顔をされるに違いない。従来型のアーキテクチ ャが不要だと言うわけではない。しかし、語の意味をずらした転用のせいで「ユーザに見えるアーキテクチャ」の存在が忘れられていない か。アプリケーションを設計する行為には、ユーザの言葉を理解して機械の言葉に翻訳する以上のことが含まれていると僕は思うのだが。
著者が主張する三要素分析法は、「ユーザアーキテクチャ」すなわちユーザの目からみた業務／システムの構造を伝達する手段として特 徴づけられている。著者が設計記法の説明において具体的なシステムに拘る理由もここにあると僕は推察する。すなわち、アーキテクチャ を記述する記法の実用性は、具体的なアーキテクチャをうまく表現することでしか証明できない。伝えたいアーキテクチャが伝えられ理解 されてこそ、「なるほどね、この記法だとよく理解できるね」と言ってもらえる。すなわち証明すべきは、人間（特にユーザ）を相手にし た表現力の十分さであり、工学的完全性はその一条件に過ぎないのだ。それゆえにこそ、冒頭で述べたような、一冊の本には不釣り合いと も思える努力を、著者はこの本に投入したのだろう。
著者は「方法論からサンプルライブラリの時代へ」と言う。僕流にこれを解釈すれば、これからはユーザアーキテクチャの時代というこ とになる。本当だろうか。本当かもしれないが、僕はそれほど楽観視はしていない。かといって、楽観できない現状を悲しんでいるわけで もない。なんとなれば、「ユーザアーキテクチャ」は、主流であろうと傍流であろうと関係なく、現実のプロジェクトに役立つ上、それ自 体実に刺激的でおもしろいからだ。ひょっとしたらあり得るかもしれない業務の姿についてフランクに話し合える仲間と、チャンスを与え てくれるクライアントと、仕事の後の旨い酒があれば、それ以上を望む必要もない（もっと色々あっても別に困らないけどね）。
