» 【第41号】リソース先行

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

DRI通信41号「リソース先行」2000.2.1
冬真っ盛りということで、寒い日もあるこの頃です。私も時々コートを着たり
することがあるようになりました。Y2Kがほぼ終わりeビジネス対応やシス
テム統合の課題など、中長期計画実現のための予算どりなどにお忙しいことか
と思います。
前回は「大規模システム開発の実態」を扱いましたが、とくに異論はなく、
「・・全く同感です。特に、発注者(弊社での現業部門と称している部署)の
コンピュータシステムに組み込まれてしまった業務知識部分の欠落が問題と
なっています。再構築したくても、現業部門が業務知識を持っていないのが現
実になっています。小職としては、現業部門が業務知識を復活することが必須
と考えています。・・」
「・・下記新年号、全てを言い当てていると感動しました。我々もご指摘のよ
うな事にならないよう、気を付けてこの暗黙知業界からの脱出を目指して行き
たいと思います。・・」
などのご意見を
頂きました。
38号において、レイヤードアプローチの中の「概念先行」を考察しました。
今回はこれに続く「リソース先行」を考察します。正確には「リソースデータ
はイベントデータに先立って決めるべきだ」という意味です。


■リソースデータとは
リソースデータとは、経営資源である、社員、部署、設備、顧客、協力会社、
商品、原材料、勘定科目などに関するデータです。安定していて共用性が高く、
データインフラの中核を形成します。一般に「マスターファイルのデータ」な
どと呼ばれていましたが、DWHの登場とともに「ディメンショナルデータ」
などと呼ばれることも多くなりました。
ビジネスを行うには社員、顧客、商品が不可欠であることから、私はこれらを
3大リソースと呼び、これがリソースデータの最重要データであると考えてい
ます。たとえばこのリソースデータがそろったところで営業開始ができ、基本
的に次のような受注イベントデータが発生することになります(#は番号、
また[ ]はKEY(識別子)を表す)。
[受注#]−(顧客#、商品#、数量、受注日、納期、受注社員#)
ここで、受注社員#は「誰だれが」を、顧客#は「誰だれに」を、商品#は
「何なにを」を表すために使われます。ちなみにこの「誰だれが」、「誰だれ
に」、「何なにを」などを、データモデル屋はリソースデータのイベントにおける
役割(ROLE)と呼んでいます。
これらのリソースデータを分類する、より抽象的なデータ、たとえば、部署、
支店、事業部、工場、業種、地域、商品分類、勘定大分類などもリソースと呼
び、またこれらを組合わせた単価を記述するための「品番.顧客分類#」のよ
うな複合的KEYを持つファイルなどもリソース系として扱います。
■協定がないとバラバラ
上述受注イベントデータは、実は顧客が発注データとして発行したものに他なり
ませんが、特に協定しない限り「誰だれが」、「誰だれに」、「何なにを」等を表す
データは、企業毎に異なり一致するはずがありません。現在リソースデータは各
企業ごとに独自に設定することになっているからです。食品など最終消費材では
業界標準コードとして商品を識別するJANコードが設定されていますが、これ
はまだ例外的なことと考えられます。
事態はしかし一般にもっと深刻です。企業間どころでなく、企業内・部門間で
リソースデータがバラバラに設定され、データが流通・共用できずに困ってい
る企業が多くあります。営業と経理と生産、それも事業部ごとに製商品#の
体系や値がちがっている場合も珍しくありません。業務のやり方は商品の大
分類ごとに違っていることが多いのですが、その大分類コードがいろいろで混
乱しているうケースも良く見かけます。部門コードや取引先コードにも同じ
問題があります。これをそのままにしてシステム間でデータ――それはイベン
トデータとしてですが――をやりとりしようとすると非常に複雑なインター
フェースになり、後でメンテナンス地獄を招来することになります。
■データ標準化・共用の要
逆にリソースデータさえしっかり標準化されていれば事態は非常に単純化され
ます。それなのにこれまでSEの間に、非常に性格の異なるリソースデータと
イベントデータを区分して扱う考え方・習慣が不思議なくらい発達していませ
んでした。リソースデータもイベントデータと一緒に各アプリケーションDB
に埋没させて重複させて実装することが、ごく普通に行われていたからです。
するとリソースデータがどうしてもアプリケーションの偏見を反映する結果に
なって、後でDWH構築などの際トラブルが発生し、「しまった」と言うことに
なるわけです。なぜでしょうか。直接的にはスポンサー対応、すなわち開発プ
ロジェクト対応に無計画にアプリケーションDBを作ったためですが、わたし
はDBMSがリソースとイベントを区別する設計コンセプトを持っていなかっ
たのが、根本原因ではないかと考えています。
ERPシステムとレガシーシステムの統合、あるいはSCMやM&Aにおける
統合の際も、リソースデータをいかに調整するかが最大の課題になります。
はじめにこの違いを明らかにし、統一や読み替えの可否・方法を考えなければ
なりません。「標準なくして共用なし、共用物先行設計」は鉄則ではないでし
ょうか。実際「ヤマハ発動機殿」、「協和発酵殿」、「竹中工務店殿」ほかDOA
成功企業はいずれもリソース先行で情報システムを再構築されました。
■信号でなく意味が通じなければコミュニケートはできない
リソースとイベントの関係は、単語と文章の関係と良く似ています。単語が文
章に埋め込まれて使われるように、リソースがイベントに埋め込まれて使われ
ます。「左手を怪我した」と言うときと「あの手この手で」と言うときの「手」
の意味は違います。同じ記号が同じ意味かどうかは文章に戻って決めなければ
なりません。同様にリソースの意味を確定するために、われわれはイベントに
戻ります。イベントは画面・帳票に表れていますので、営業、生産、経理など
の画面・帳票上に表れたデータを分析して、たとえばA1234が顧客、サプ
ライヤー、取引先のいずれを表しているかなどを判定し、その違いをあきらか
にします。
「手」は多くの場合「Hand]と翻訳できるでしょうが、「Method」
となる場合もあります。文化が違うと記号と意味の対応が違うわけですが、
リソースデータにおいても部門や企業が違えば、文化の違いから記号と意味
の対応が違ってきます。信号が届いても意味が通じなければコミュニケーショ
ンは成り立ちません。電話が通じても英語の分からない人は、アメリカからの
電話を受け取ることができないように、インターネットが利用できても品番の
体系が違っていればコミュニケーションは成り立ちません。このためCALS
などの活動が行われているわけですが、リソースデータの標準化が根本的課題
となります。
■先憂後楽のマネジメント
リソース先行の最大の問題点は、初期投資が必要だということです。リソース
を20個のアプリケーションで使うとすると、理論的には始めのアプリケーシ
ョン開発時に20個分のインフラ投資が必要になるわけです。実際には初期投
資を減らすべくいろいろ工夫しますが、要員教育を含め最低限の初期投資が必
要になります。目先最適化ではありませんから、先憂後楽を実現するマネジメ
ント・政治が必要になります。
■リソースデータの調整がM&Aの課題
M&Aが盛んですが、人の組織よりも情報システムの統合が大変です。手順も
違うでしょうが、データの違い、それもリソースデータの違いを解決すること
が基本になります。われわれはデータ分析法PLAN−DBを通じて、常時、
ボトムアップにデータの違いを調整し統一する手法を実践し、ノウハウを蓄積
してまいりました。このノウハウはぜひ活用させていただきたいものです。
データはメタデータ、リソースデータ、イベントデータ(正しくは在庫や要約
を含めた業務データ)に大分類することができますが、安定度・共用度はこの
順に低くなります。安定度・共用度の高い順に先行して固めなければなりませ
ん。メタデータの先行は必然ですが、リソースデータの先行はあまり注目され
ていないようです。スマートな運用・保守を実現するリソース先行を心がけて
頂きたいと思います。