ＤＲＩ通信４１号「リソース先行」２０００．２．１
冬真っ盛りということで、寒い日もあるこの頃です。私も時々コートを着たり
することがあるようになりました。Ｙ２Ｋがほぼ終わりｅビジネス対応やシス
テム統合の課題など、中長期計画実現のための予算どりなどにお忙しいことか
と思います。
前回は「大規模システム開発の実態」を扱いましたが、とくに異論はなく、
「・・全く同感です。特に、発注者（弊社での現業部門と称している部署）の
コンピュータシステムに組み込まれてしまった業務知識部分の欠落が問題と
なっています。再構築したくても、現業部門が業務知識を持っていないのが現
実になっています。小職としては、現業部門が業務知識を復活することが必須
と考えています。・・」
「・・下記新年号、全てを言い当てていると感動しました。我々もご指摘のよ
うな事にならないよう、気を付けてこの暗黙知業界からの脱出を目指して行き
たいと思います。・・」
などのご意見を
頂きました。
３８号において、レイヤードアプローチの中の「概念先行」を考察しました。
今回はこれに続く「リソース先行」を考察します。正確には「リソースデータ
はイベントデータに先立って決めるべきだ」という意味です。
■リソースデータとは
リソースデータとは、経営資源である、社員、部署、設備、顧客、協力会社、
商品、原材料、勘定科目などに関するデータです。安定していて共用性が高く、
データインフラの中核を形成します。一般に「マスターファイルのデータ」な
どと呼ばれていましたが、ＤＷＨの登場とともに「ディメンショナルデータ」
などと呼ばれることも多くなりました。
ビジネスを行うには社員、顧客、商品が不可欠であることから、私はこれらを
３大リソースと呼び、これがリソースデータの最重要データであると考えてい
ます。たとえばこのリソースデータがそろったところで営業開始ができ、基本
的に次のような受注イベントデータが発生することになります（＃は番号、
また［ ］はＫＥＹ（識別子）を表す）。
［受注＃］−（顧客＃、商品＃、数量、受注日、納期、受注社員＃）
ここで、受注社員＃は「誰だれが」を、顧客＃は「誰だれに」を、商品＃は
「何なにを」を表すために使われます。ちなみにこの「誰だれが」、「誰だれ
に」、「何なにを」などを、データモデル屋はリソースデータのイベントにおける
役割（ＲＯＬＥ）と呼んでいます。
これらのリソースデータを分類する、より抽象的なデータ、たとえば、部署、
支店、事業部、工場、業種、地域、商品分類、勘定大分類などもリソースと呼
び、またこれらを組合わせた単価を記述するための「品番．顧客分類＃」のよ
うな複合的ＫＥＹを持つファイルなどもリソース系として扱います。
■協定がないとバラバラ
上述受注イベントデータは、実は顧客が発注データとして発行したものに他なり
ませんが、特に協定しない限り「誰だれが」、「誰だれに」、「何なにを」等を表す
データは、企業毎に異なり一致するはずがありません。現在リソースデータは各
企業ごとに独自に設定することになっているからです。食品など最終消費材では
業界標準コードとして商品を識別するＪＡＮコードが設定されていますが、これ
はまだ例外的なことと考えられます。
事態はしかし一般にもっと深刻です。企業間どころでなく、企業内・部門間で
リソースデータがバラバラに設定され、データが流通・共用できずに困ってい
る企業が多くあります。営業と経理と生産、それも事業部ごとに製商品＃の
体系や値がちがっている場合も珍しくありません。業務のやり方は商品の大
分類ごとに違っていることが多いのですが、その大分類コードがいろいろで混
乱しているうケースも良く見かけます。部門コードや取引先コードにも同じ
問題があります。これをそのままにしてシステム間でデータ――それはイベン
トデータとしてですが――をやりとりしようとすると非常に複雑なインター
フェースになり、後でメンテナンス地獄を招来することになります。
■データ標準化・共用の要
逆にリソースデータさえしっかり標準化されていれば事態は非常に単純化され
ます。それなのにこれまでＳＥの間に、非常に性格の異なるリソースデータと
イベントデータを区分して扱う考え方・習慣が不思議なくらい発達していませ
んでした。リソースデータもイベントデータと一緒に各アプリケーションＤＢ
に埋没させて重複させて実装することが、ごく普通に行われていたからです。
するとリソースデータがどうしてもアプリケーションの偏見を反映する結果に
なって、後でＤＷＨ構築などの際トラブルが発生し、「しまった」と言うことに
なるわけです。なぜでしょうか。直接的にはスポンサー対応、すなわち開発プ
ロジェクト対応に無計画にアプリケーションＤＢを作ったためですが、わたし
はＤＢＭＳがリソースとイベントを区別する設計コンセプトを持っていなかっ
たのが、根本原因ではないかと考えています。
ＥＲＰシステムとレガシーシステムの統合、あるいはＳＣＭやＭ＆Ａにおける
統合の際も、リソースデータをいかに調整するかが最大の課題になります。
はじめにこの違いを明らかにし、統一や読み替えの可否・方法を考えなければ
なりません。「標準なくして共用なし、共用物先行設計」は鉄則ではないでし
ょうか。実際「ヤマハ発動機殿」、「協和発酵殿」、「竹中工務店殿」ほかＤＯＡ
成功企業はいずれもリソース先行で情報システムを再構築されました。
■信号でなく意味が通じなければコミュニケートはできない
リソースとイベントの関係は、単語と文章の関係と良く似ています。単語が文
章に埋め込まれて使われるように、リソースがイベントに埋め込まれて使われ
ます。「左手を怪我した」と言うときと「あの手この手で」と言うときの「手」
の意味は違います。同じ記号が同じ意味かどうかは文章に戻って決めなければ
なりません。同様にリソースの意味を確定するために、われわれはイベントに
戻ります。イベントは画面・帳票に表れていますので、営業、生産、経理など
の画面・帳票上に表れたデータを分析して、たとえばＡ１２３４が顧客、サプ
ライヤー、取引先のいずれを表しているかなどを判定し、その違いをあきらか
にします。
「手」は多くの場合「Ｈａｎｄ］と翻訳できるでしょうが、「Ｍｅｔｈｏｄ」
となる場合もあります。文化が違うと記号と意味の対応が違うわけですが、
リソースデータにおいても部門や企業が違えば、文化の違いから記号と意味
の対応が違ってきます。信号が届いても意味が通じなければコミュニケーショ
ンは成り立ちません。電話が通じても英語の分からない人は、アメリカからの
電話を受け取ることができないように、インターネットが利用できても品番の
体系が違っていればコミュニケーションは成り立ちません。このためＣＡＬＳ
などの活動が行われているわけですが、リソースデータの標準化が根本的課題
となります。
■先憂後楽のマネジメント
リソース先行の最大の問題点は、初期投資が必要だということです。リソース
を２０個のアプリケーションで使うとすると、理論的には始めのアプリケーシ
ョン開発時に２０個分のインフラ投資が必要になるわけです。実際には初期投
資を減らすべくいろいろ工夫しますが、要員教育を含め最低限の初期投資が必
要になります。目先最適化ではありませんから、先憂後楽を実現するマネジメ
ント・政治が必要になります。
■リソースデータの調整がＭ＆Ａの課題
Ｍ＆Ａが盛んですが、人の組織よりも情報システムの統合が大変です。手順も
違うでしょうが、データの違い、それもリソースデータの違いを解決すること
が基本になります。われわれはデータ分析法ＰＬＡＮ−ＤＢを通じて、常時、
ボトムアップにデータの違いを調整し統一する手法を実践し、ノウハウを蓄積
してまいりました。このノウハウはぜひ活用させていただきたいものです。
データはメタデータ、リソースデータ、イベントデータ（正しくは在庫や要約
を含めた業務データ）に大分類することができますが、安定度・共用度はこの
順に低くなります。安定度・共用度の高い順に先行して固めなければなりませ
ん。メタデータの先行は必然ですが、リソースデータの先行はあまり注目され
ていないようです。スマートな運用・保守を実現するリソース先行を心がけて
頂きたいと思います。
