前回，全社的なアプリケーション設計を共通化する上での課題について述べた。この記事について，読者から「アプリケーション設計の多様性をもたらす源泉は業務プロセスの多様性である」とのコメントをいただいたが，まさにおっしゃる通りで，一番，自明な理由を書き忘れてしまった。どうもすみません。

　さて，今回は，このアプリケーション設計の多様性について，もう少し突っ込んで考えてみたい。特に，データ設計の多様性上の課題についてである。前回，データ設計の多様性の例として，製品コード体系がシステムによって異なるなどのケースを挙げた。しかし，このような多様性は，目に見えやすいものであり，まだ御しやすいと言える。本当に注意が必要なデータ設計の多様性とは，データの意味（セマンティクス）の多様性である。

◆セマンティクスとは？

　セマンティクスとは「意味論」という意味であるが，単に（データの）「意味」という意味で使われる場合もある（データの文法的な要素である「シンタックス」に対応する概念であると言える）。また，システムが提供する機能の挙動という意味で使われる場合もある（例えば，UNIXファイル・システムのセマンティクスといった使い方である）。ここでは，「データの意味」という意味でセマンティクスという言葉を使っていく。

　現実の情報システムにおいては，直感的に考えて意味が明らかと思える用語の中でも，アプリケーションによって微妙にセマンティクスが異なるケースが多い。

　例えば，「月次売り上げ」というデータ項目が様々なアプリケーションで使用されていたとする。日本語として見た時にこの言葉が表す「意味」は自明であろう。各システムでは，MON_SALES，G_URIAGE，GETUURIなどの様々な名称が使用されていたとする。

　ここで，これらのデータを相互に利用しデータを統合するためには，単に名称を統一したり，「月次売り上げは10桁の10進数（単位は円）とする」という標準化を行うだけでは十分ではない。これだけでは，シンタックスの多様性の問題を解決しているに過ぎないからである。

　本当に業務アプリケーションとしてのデータ連係を行うためには，セマンティクスにまで突っ込んだ標準化を行う必要がある。例えば，「月次」とは月末締めなのか20日締めなのか，「売り上げ」とは返品を加味した正味売り上げなのか，それとも返品を考えない売り上げなのか，「返品」とはあらゆる返品なのか，それとも破損品などの過失によるものだけなのか，などなど細かく泥臭い話がいくらでもある。

　ここで，経理系のアプリケーションであれば，返品後の正味売り上げを売り上げデータとし，営業管理アプリケーションであれば，過失によるものは売り上げから差し引かないなどアプリケーションによって扱いが異なってくることは十分あり得る。つまり，「月次売り上げ」の字面は同じだが，そのセマンティクスは多様である。これを，“セマンティクス・ギャップ”と呼ぶことにしよう。

◆セマンティクス・ギャップの過小評価に気をつけよう

　このようなセマンティクス・ギャップの問題は，全社的アーキテクチャの確立だけではなく，EAI（全社的アプリケーション統合）やデータウエアハウスの構築など，アプリケーションの境界をまたがって何らかの統合作業を行おうとする時に大きな障害になる。建築設計レベルのアーキテクチャではあまり問題とならないが，都市計画レベルのアーキテクチャにおいては大きな問題となるポイントである。

　さて，ここまでの話は，実際に現場でシステム分析，設計，開発を行っている方であれば，自明のことであり，わざわざ説明するまでのこともないポイントだろう。しかし，実際には，多くの場合に，セマンティクス・ギャップが過小評価されることで問題が発生している。

　例えば，ガートナーの調査では，米国におけるデータウエアハウス構築プロジェクトの80％において，データウエアハウスへのデータのローディング部分における開発コストが見積もりより大きくなってしまうことが判明している。そして，この予期せぬコスト増の原因の多くが，データ供給元のアプリケーションのセマンティクス・ギャップによるものと推定している。セマンティクス・ギャップはツールやミドルウエアだけでは解決できず，泥臭い分析作業と業務ロジック・レベルのコーディングが必要となるからである。

　現場経験が少ないコンサルタントがトップダウンで上流の設計を行い，きれいな“絵”を成果物として出し，下流行程でその“絵”を実現するために，予想以上の困難を伴なうというパターンもありがちだろう。例えば，各アプリケーションにある売り上げデータを統合するというのは“絵”で書けば数本の矢印ですむかもしれない。しかし，その“矢印”を実装するために予想以上の負荷がかかることが多いのである。

　ここで，きれいな“絵”を書くことを否定するわけではない（あるべき姿を描くのは悪いことではない）。ただ，それを実装する際の負荷の大きさを過小評価してはならない，ということである。ここで，セマンティクス・ギャップの過小評価には特に注意が必要だ。全社的アーキテクチャ構築プロジェクトにおいても，まさに，同様の注意が当てはまるだろう。