» 【第70号】インターフェースの標準化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第70号】インターフェースの標準化

DRI通信70号「インターフェースの標準化」      2002.7.1
ワールドカップが終わり、梅雨も後半に入りますが、いかがお過ごしでしょうか。弊社は創立以来、夏と冬に外部の会場で大型セミナーを開いてきました。そろそろ17年になりますが、おかげさまにて今年は初めて2週間も前に満杯、お申し込みをお断りすることになりました。テーマは「グローバル経営を支援するデータ基盤戦略」ですが、時機を得たものだったかと喜んでおります。締め切り後もお申し込みがあるため、このミニ版を8月7日午後、弊社セミナールームにて行うことにいたしました。
さて今月は、システム化の前提となる標準化、特にインターフェースの標準化について考察いたします。
■機能先行
私事になりますが、私のノート型パソコンが、社内で一番古いとかで、先日Windows-XPに換えました。前のが繋がらないとかで、CDドライブも買い替えるはめになりました。また昨年はスイスにパソコンを持っていきましたが、日本のソケットでは繋がらず、現地でアダプターを買うことになりました。ソケットの仕様は、フランスは、またスイスとも違います。旅行者はマイノリティですから、一旦決めて建物に埋め込まれたソケットの仕様が、万国共通になることは期待できないでしょう。国対応にソケットを持ち歩くことになります。機能先行で、接続インターフェースは後追いになり永遠に追いつけないようです。


■紙データベースの時代
コンピュータの無い時代、われわれは紙でコミュニケーションしていました。設計建設プロジェクトでは、日々新しい情報が生まれ、また改定が発生しますので、これを集め、管理・分配するドキュメント管理チームが設置され活躍していました。紙データベースを管理する人間DBMS、さらに配信にも責任を持ちますので人間EAIと言った機能でした。
ドキュメントは、テキスト言語(プラントメーカーだったので、英語混じり日本語)、テーブル言語(機器・配管材料などのリスト)、図面言語(プロセスフローシート、配管・計装線図など)から成るものでしたが、見るのは人間ですから、一応の形式さえ整っていれば、理解することができました。
プロジェクトを超えて、全社を見渡しても、紙ドキュメントデータベースによるコミュニケーション体制であることには変わりありません。紙データベースは、部門ごとあるいは担当者ごとに分散管理されていました。管理は不十分ですから、紛失したり、改定情報が届かなかったり
することがありました。
コンピュータの時代になっても初めは、ドキュメント作成を省力化するだけで、コミュニケーションは、従来のドキュメントベースを踏襲するものでした。コンピュータの処理機能だけが注目されていた時代です。したがって処理を規定するプログラミングが最大の関心事でした。標準化としてはプログラミング言語やこれを扱うためのストラクチャードプログラミング、汎用サブルーチンなどが話題の中心でした。少しでも早く処理の自動化を実現したいということから、コミュニケーション問題は後送りにした「孤島システム」がたくさん作られました。
■データベースの通信ハブ機能\nデータベース時代となり、その通信ハブ機能が、紙データベースによるコミュニケーションに取って代わるものであることが分かってきました。そして紙は当事者がデータベースの内容を、端末を補足して確認するためのものとなってきました。こうして電子データを流通させるための、
インターフェースの標準化、これを構成するデータ項目の形式・意味や値の標準化が問題とされるようになりました。人間のような融通が利きませんから、標準化は非常に厳密なものでなければなりません。
ところで、データベースもはじめは、BOMなど複雑な構造を持ったデータのための便利な入れ物として受け止められていました。中小型のアプリケーションのための専用ファイルがたくさん作られ、アプリケーション間は、ファイルやメッセージで個別に繋いでいました。これが「孤島システム」の実態ということになります。これでは部分最適化しかできない、全体最適、それも企業の枠を超えたサプライチェーン、あるいは連結決算などのニーズが顕在化してきて、データベースの通信ハブ機能が脚光を浴びてきたのだと思います。
■Whatの標準化
こうして広域のデータ項目の形式・意味および値の標準化がクローズアップされてきました。このWhatさえ確立していれば、残る標準化はHow・実装、したがって造り手のかかわる二次的なものに限定されるので気が楽になります。How・実装にかかわる標準化は、実装環境に依存しますので、一般にローカルで、かつ変化が激しく、コストをかけても陳腐化が速くペイしにくい。ソフトウエアエンジニアリングがあまり成功しなかった理由もこの辺にあると思われます。一般論として、標準化の点ではWhatの方がHowよりも桁違いに重要といえます。
■「決まっているもの」「決めるもの」
いまデータ項目の標準化とは何かを考えて見ます。たとえば発注というイベントにおいてどんなデータ項目がやりとりされるのでしょうか。
THモデル方式で書くと、おそらく
[発注#]−(発注先#、品#、数量、納期、金額、届先#、発注日)
のような形式になります。ここに8個のデータ項目が使われていますが、これらは不可欠なもの、標準化によって増えたり減ったりすることにはならないもの、すなわち「決まっているもの」かと思われます。
一方、標準化の対象になるもの、すなわち「決めるもの」は、
a.データ項目名称(発注番号かOrderNoかなど)(XMLのタグ名称を含めて)
b.発注先#と届先#が同じエンティティタイプを参照しているか否か
c.品#の参照先のエンティティの粒度(荷姿や仕向地などまで含むか否か)
d.品#のコード体系や桁数
e.品#=1234(4桁として)が何を表すか
f.金額の単位や位取り記号
などいろいろあります。標準化とは、データ項目名称一つ考えても、日本語・英語・スペイン語などの中から、単語を選んで組み合わせるわけですが、無限の可能性の中から一つを選んで決めることになりますから容易ではありません。使用者の慣れから、多くの場合は従来使ってきたものを極力生かし、矛盾、重複、類似物の統一などなどを施して行うことになります。
「決まっているもの」はサイエンスの領域にあり、人間が誤って「決めて」はなりません。数学的には従属変数の位置づけになります(収束計算のための初期値を[与える]ことはあります)。一方「決めるもの」は、独立変数であり、最適化によって決めるのが理想です。しかし数式モデルを作って計算することが難しく、経験者が判断して決めざるを得ないものが多いのも事実です。選択肢が多く判断する人が多ければ多いほど標準化は難しくなります。膨大なレガシーシステムを抱えた大会社のデータ項目の標準化、さらにそのM&Aにおける標準化の難しさは一通りではありません。
■標準化はアウトソースできない
しかし「標準化なくして共用なし」「共用なくしてデータの流通なし」ですから、放置するわけには行きません。共用ニーズの高いものから順次標準化を進めなければ、システムは動脈硬化をおこし、システム部門はそのケアだけで忙殺されてしまう心配があります。標準化は本来自社で手がけるものであって、大手SIにアウトソースして解決できるものではありません。しかもSIはソフトを作るノウハウは蓄積してきましたが、コンテンツの標準化には、儲かりにくいためでしょうが、あまり関心がなく、ノウハウの蓄積は遅れています。
データ項目の標準化が、従来まったく行われなかったというわけではありません。しかしシステム開発プロジェクトの中で、そのスポンサーの予算で、その期限の中で、そのアプリケーションのために行われることが多かった。そのソフト開発が目的ですから、全社的とか、企業グループを視野に入れた標準化は、たとえ必要性が感じられても、先送りということになります。こうして開発のたびに中途半端な標準化が何回も繰り返されてきました。
■トップ主導の広域データ標準化
したがって今必要なことは、時期を見て、特定アプリケーション開発と独立した、トップマネジメント主導による、全社ないし企業グループにおけるデータ項目の標準化プロジェクトに踏み切ることだと思います。これに取り組むか否かによって10年後が決まるのではないでしょうか。
ERPを導入しても、多くは大型孤島システムの様相を残し、レガシーシステムやDWH、B2Bとのデータ流通に問題を残しています。日本の一流企業には、データがさらさら流れるコレステロールのないデータベースを構築し、激動の21世紀を戦っていってほしいと願っています。