» DRI通信91~100号

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
DRI通信91~100号

創業者、椿正明の過去の発信のアーカイブです

【第100号】データモデルの統一

2004/12/28

DRI通信100号「データモデルの統一」 2005.1.4
あけましておめでとうございます。やっと雪の舞う冬が来ました。短めのお正月休み、いかがでしたか。
DRI通信も8年4ヶ月続いて、これで100号を迎えました。「毎月送られてくるDRI通信、楽しみにしてます」、などといわれると、本気にして気合を入れて書いてます。テーマは、いつも5個くらいは溜まっていて、その中のひとつを月中の土日に書きます。調子の良いときは5時間くらいで書けますが、それから数人の方にレビューを依頼します。誤解を招くところや、分かりにくいところを直し、推敲して月末に挨拶をつけ、営業から発行してもらいます。皆様、とくにレビューアの皆様のご協力によって、100号になりました。ありがとうございました。
12月6日には、DOA+コンソーシアムの1周年記念セミナーがありました。120名以上のご参加をいただき、内容的にもご満足いただけたようでした。特に協和発酵の中山嘉之さんの「協和発酵におけるモデリング20年とこれから」はDOA20年で数十億円の価値を生んだとするもの、事実の説得力が印象的でした。
■データモデルは統一しない
さて今月は「データモデルの統一」について述べます。DOA+コンソーシアム1周年記念セミナーでお話したことです。結論は「データモデルは、簡単な条件付ですが、今は統一しない」と言うものです。OOでは3アミーゴがUML表記について統一することになったため、その普及が進みました。これに倣って、DOA+コンソーシアムも「モデルを統一して欲しい」といった期待がありましたが、「その時機でない」と判断しました。

『【第100号】データモデルの統一』の続きを読む・・・


【第99号】ドキュメンテーションの進化

DRI通信99号「ドキュメンテーションの進化」 2004.12.1
いろいろあった今年もあと1月を残す時期となりました。北海道では雪とか、風邪に気をつけて元気にお正月を迎えましょう。
「部分最適でなく、全体最適」が注目されてきましたが、アウトソーシング環境の場合は、発注側がよほどしっかりしなければなりません。SIerは個別アプリのQCD(Quality, Cost, Delivery)が課題ですから、全体最適には取り組みません。発注側のCIO、経営企画、システム企画が協力して全体問題−データ流通と最適化、そのための可視化−に取り組む時代が来ているのではないでしょうか。
弊社が幹事を務めている、DOA+コンソーシアムでは12月6日(月)田町Granparkにて、1周年記念講演会を行います。1年目の活動報告、2年目の活動計画のほか、DOA先進企業、協和発酵の中山嘉之さんのご講演、さらに懇親会があります。ご都合のつく方は多数ご参加ください。
■ ドキュメンテーション
ドキュメンテーションと言っても、システム・ドキュメンテーション、それもOSやワープロソフトなどでなく、業務アプリケーションシステムのドキュメンテーションに限定して、これがどのように進化したかを考えることにいたします。操作マニュアルは当初より必須でしたので、これは除き、システムの構造を示すドキュメントに限定します。あまり細分しても難しくなりますので、やはり5段階に分け、その形式を論ずるものとします。

『【第99号】ドキュメンテーションの進化』の続きを読む・・・


【第98号】DOAスキルレベル

DRI通信98号「DOAスキルレベル」       2004.11.1
猛暑、台風、熊、地震と騒いでいるうちに、寒くなって風邪を引く人が出てまいりました。油断なく気をつけていると、風邪はほとんど防げます。冬へ向けて元気に過ごしましょう。
10月28日、本年最終回のDOA+第2分科会がありました。講師はNEC、BIGLOBE構築運営本部の桧垣さんで、タイトルは「ビジネスルール中心/アーキテクチャ中心による業務システムのノンプログラミング開発」です。変更が激しく、短納期、かつ絶対エラーの出せないBIGLOBE事業のアプリケーションを、ノンプログラミングで支えるために、4レベルに分けたビジネスルールをEXCEL上で組み立て整理し、それをビジネスルールエンジンで駆動するというユニークなものでした。
■DOA復活
電気製品は日本全国どこでも電源とつながります。コンセントの仕様、すなわちインターフェース仕様が標準化されているからです。プログラム同士や、いくつものプログラムから構成されるアプリケーション同士も、インターフェース仕様が標準化されていれば、自由につながるはずです。インターフェースはデータから構成されますから、まず個々のデータを標準化しよう。これがDOA、データ中心アプローチです。n個のコンポーネントのインターフェースは必然的にハブ構造を要求しますから、概念DBの標準化を推進することになります。

『【第98号】DOAスキルレベル』の続きを読む・・・


【第97号】属性と定義域

DRI通信97号「属性と定義域」       2004.10.1
10月の声を聞いて、ようやく涼しくなってまいりました。皆さんお元気ですか。
DOA+コンソーシアムの代表ということで、私は、さる9月22日、モデリングフォラム2004において、「DOAとオブジェクト指向の連携」というプレゼンをいたしました。「合計値」といったメタメタデータにロジックを用意すれば、「受注合計金額」とか「月次売上数量」といったメタデータごとにロジックを用意する必要はなくなります。この方式、DOAによって、メタデータとメタメタデータの関係を明らかにし、オブジェクト指向によって、メタメタデータに対するロジックを用意する役割分担が、正解ではないか、と提案いたしました。
また9月28日には、DOA+コンソーシアム第2分科会において、住友電工(株)中村伸祐氏より「DOA+とOOPによるモデル駆動型アプリケーション開発」の発表がありました。あらかじめ標準化して作成したJavaコンポーネントが、リポジトリに蓄えた設計情報を読み込んで即実行する方式で、生産性はCOBOLの約3倍上がり、さらに倍増をねらっているとのことでした。
今月は久しぶりに、情報システムのマネジメント問題を離れ、データモデルの基本問題を考えます。
■ 属性
属性とは、エンティティの性質を記述するためのデータ項目で、たとえば製品、発注について次のように表現します。
 製品:[品#]−(品名、単価、品種*、・・)
 発注:[発注#]−(発注先#*、メーカ#*、品#*、数量、納期、発注日付、・・)
ここに、角括弧にはKEY(識別子)属性を、丸括弧には従属属性を書きます。#は番号と読んでください。*は参照KEYと呼ばれる性質の属性で、「どこかでKEYとして定義されているからこれを参照している」と言うことを表します。俗に言えば、「コード類です、テーブルを参照してください」と言うことです。この属性のことを、英語では、昔はPropertyとも呼んでいましたが、最近はAttributeが一般的のようです。

『【第97号】属性と定義域』の続きを読む・・・


【第96号】気づかれにくい問題

DRI通信96号「気づかれにくい問題」       2004.9.1
さすがの酷暑も9月の声とともに、過ごしやすくなってまいりました。夏休みもオリンピックも終わり、仕事に専念の体制が整ったと言うところかと思われます。
DOA+コンソーシアムでは、8/6(金)第1分科会(第4回)において、「上流設計工程における「『Xupper』のデータモデルとデータモデリング手法」をケン・システムコンサルティング株式会社の本村智之様より、また8/26(木)第2分科会において「QuiQpro-Java」を富士通システムソリューションズの川端功微様よりご紹介を頂きました。ここでもやはり、「上流はDOA、下流はOOP」とのことでした。
■劣化しないシステム
ソフトウエア業界では、ERP、EAなどと並んでプロジェクトマネジメント、RFP(Request For Proposal)、オブジェクト指向開発などが話題を集めています。そしてその多くが、単発アプリケーションを、ユーザが発注し、SIがこれを請けるという開発環境の中で語られています。そこでは案件のQCD(Quality, Cost, Delivery)が目標とされ、これが実現できれば、「めでたしめでたし」として、カットオーバーのセレモニーが行われることになります。
これは単発アプリケーションの発注・請負のビジネスの中では、極めて自然であり、問題があるようには思われません。しかしこの繰り返しの中から、属人的で見えにくい、スパゲッティインターフェースのため、トラブルの発生しやすい、保守コストのかかる、動脈硬化したシステムができていくことがあります。しかし、いま厄介もの扱いされているシステムも、カットオーバーしたばかりは、多くの課題を解決した、すばらしいシステムとして評価されていたのではないでしょうか。

『【第96号】気づかれにくい問題』の続きを読む・・・


【第95号】メタとメタメタ(続き)

DRI通信95号「メタとメタメタ(続き)」       2004.8.2
冷夏の反対は、暑夏というのでしょうか、熱夏というのでしょうか、大変な暑さですが、皆様お元気ですか。
第2回DOA+初心者向け講座(7月14日@ゆうぽうと、講師:佐藤正美&椿)は約100名の参加をいただき無事終了いたしました。分科会での議論、DOA各流派の違いなどを紹介したため、一部中級以上の内容が混じってしまい心配しましたが、ほぼ「有意義」とのアンケートをいただき、「ほっ」といたしました。
第6回DOA+OOP分科会(7月21日@住友電工)ではセントラルコンピュータサービスの三河様からDOAとOOを繋ぐ開発方法論Coupについて、上流にXupper、下流にKonesaを使うケースでの紹介がありました。BFD(Business Flow Diagram)からユースケース経由ロバストネス図を作るところがOO的ということでした。
先月「メタとメタメタ」としてシステム・コンポーネントを概念と物理、DB側とIO側、データと生成プロセスに分け考察しました。メタはDOAで、メタメタはOOで再利用を図るのが適切ではないか、との考えからですが、OOに詳しい方々からも貴重なご意見をいただきました。
■識者のご意見
たとえば、
佐藤英人氏(東京国際大学):「メタメタとメタの関係はクラス−インスタンスの関係です。メタメタデータとパラメータ化されたプログラム(椿氏のメタメタプロセス)を対応付けて考える、という意見に全面的に賛成です。個々のプログラムは、このメタメタ
データに対する値(メタデータ=上記パラメータの値)を読み込んで動くエンジンに
置き換えることができます。問題は、メタメタデータとして何を用意すれば十\n分かという点にあると思います。」
細川努氏(日本総研):「大変興味深く拝読させていただきました。しかしオブジェクト指向で、定義域の明確化やデータ属性の標準化をやってもいいはず。OOもDOAもテクニックの違いだから、お互いいいところ取りするのは大いに結構ではなないか。」

『【第95号】メタとメタメタ(続き)』の続きを読む・・・


【第94号】メタとメタメタ

DRI通信94号「メタとメタメタ」       2004.7.1
第1四半期が終わり、梅雨の後半戦になりますが、今年も厳しいですね。
DOA+コンソーシアムでは、6月28日、五反田ゆうぽーとで、はじめての試み、初心者向け講座を開催しました。講師は堀越(データ総研)、真野(CAC)、本村(ケンシステムコンサルティング)。無料ということもあってか、140名ほどの参加をいただきました。プレゼンは今までの技術を棚卸しし整理するもので、初心者というより中級者向けでしたが、参加者層とほぼマッチしていたようで、例外はあるものの好評でした。また6月22日には、アルゴシステム創研の勝藤さまより「Hybrid型開発技法B-DM」の紹介がありました。「上流はDOAで下流はOOで」という意味のHybridということですが、プログラミングのパラダイムを上流に持ち込むのは無理との判断からのようでした。
■ メタとメタメタ
この話題、抽象的で苦手と言う人もあるかと思います。しかし情報システムの設計にかかわる人にとって避けて通れない概念ですし、落ち着いて考えればそんなに難しいものではありません。まずこれから考える対象を次のように、分類コードをつけて、整理しておきます。
          サーバー側(S)      クライアント側(C)
概念データ(DC) 概念DBデータ(D*CS) 概念画面・帳票(D*CC)
物理データ(DP) 物理DBデータ(D*PS) 物理画面・帳票(D*PC)
ここで画面・帳票を概念と物理に分けることに違和感を持たれる方があるかと思われます。われわれはしかし、ビジネスユーザの情報要求の本質は概念画面・帳票として把握でき、操作性などに関わる要件は、むしろシステムユーザ/オペレータのための二次的なもの(大事でないと言う意味ではなくIT環境などによる変化に対応すべきと言う意味)として分離し、物理画面・帳票として捉えます。なお、サーバー側とは原料となるデータをストックするDB側、クライアント側とは製品となる画面・帳票を扱うユーザ側という意味で、特定のIT環境を想定したものではありません。
以上、データだけを4種類に分けましたが、データにはこれを生成するプロセスが4種類それぞれ対応付けられます。以下これらについてメタとメタメタを考察することになります。

『【第94号】メタとメタメタ』の続きを読む・・・


【第93号】ハイレベルDOA

DRI通信93号「ハイレベルDOA」       2004.6.1
ゴールデンウイークに山で痛めた脚が治ったら、もうアジサイが咲いてホトトギスが鳴く6月です。皆様、今期の出足はいかがですか。
5月28日に行われたDOA+第2分科会はウルシステムズさんから、UMLautの紹介がありました。生産性を挙げるべくJ2EEを補強したソフトウエアフレームワークを基に、SQLを含むJAVAプログラムを自動生成する点はOOなのでしょうが、オブジェクトの再利用はねらいでなく、RDBベースなので分析設計はDOA、そしてORならぬROマッピングというきわめてDOA的なものでした。
また、最近NECの桧垣さんからうかがった言葉、「建築工学の卒業生はアーキテクチャを学んでくる。しかし情報工学の卒業生はプログラミング言語を学んでくるだけで、アーキテクチャを知らない。鉋の使い方、釘の打ち方を習得してくるようなものだ」は印象的でした。情報工学の先生方、何とかしてください。
■DOAの分割
データ中心アプローチ、DOAといっても、いろいろな流儀があります。これを整理することを考えていたときに、ひとつのアプリケーションの中で考えるDOAと、異質なアプリケーション横断(注1)で考える、いわば2階建てのDOAとがあり、これを意識すべきことに気づきました。前者をロウレベルDOA(lDOA)、後者をハイレベルDOA(hDOA)と呼ぶことにします。DOAとしてのねらいも、両者で若干異なります。
(注1)横断対象となるアプリケーションには、何らかの壁があるものとします。ユーザの職種の違い、顧客の業界の違いなどにより、用語/文化がちがったりします。過去のシステム化の歴史の違いや、ハードやソフトの環境の違いも多くみられます。これらが壁をつくるものと思われます。

『【第93号】ハイレベルDOA』の続きを読む・・・


【第92号】データ先行・リソース先行・概念先行の意義

DRI通信92号「データ先行・リソース先行・概念先行の意義」  2004.5.6
ゴールデンウイークはやはり素晴しい季節ですね。皆様お元気ですか。さわやかに晴れた日の森の中で、新緑がきらきらと輝いています。今期も始まったばかりで、追い込まれていないのがなお良いですね。
4月22日には、DOA+OOP第3回分科会が住友電工殿の会場で行われました。スピーカーは東京国際大学の佐藤英人教授で、RADON法が紹介されました。処理をどのデータに対応付けるべきかという論点で、伝統的OOの実世界モデルアプローチおよび機能場アプローチは属人的になりやすい、と指摘されました。加工データ(チェックデータを含む)の処理に関しては、弊社のDOAと同じ結果が得られるようでした。
■DOAの条件
私はDOA(Data Oriented Approach)の条件として、「データ先行・リソース先行・概念先行」ということを申し上げています。多くの方は開発のアプローチとして受け取っておられるようですが、開発だけでなく、運用・保守、またユーザの利用にも、したがって情報システムの理解全般において常に有用なアプローチと考えています。そこで、その理由を以下述べてみたいと思います。

『【第92号】データ先行・リソース先行・概念先行の意義』の続きを読む・・・


【第91号】成熟度モデルを考える

DRI通信91号「成熟度モデルを考える」  2004.4.1
「暑さ寒さも彼岸まで」を修正しなければならないような日々が続き、風邪を引いたりする人が目立ちましたが、皆様いかがですか。
2月末のDOA+コンソーシアムの第2分科会ではメディア情報開発の山田、下地様からWebtribeの、また第1分科会ではSDIの佐藤様からT字形DB設計法のプレゼンテーションがあり、活発なQ&Aもあって理解を深めることができました。
■技術成熟のS字カーブ
このところ3号続けて、成熟度モデルを扱いました。それはシステムアーキテクチャ(SAMM)、メタデータリポジトリ(MRMM)、およびデータモデル(DMMM)に関するものでした。成熟度モデルとは、基礎技術の革新によって、成熟度が大きく向上していく様子を示すものです。初めに、あるニーズを満たす技術Aが生まれますが、その効果は一般にS字カーブ/成長曲線を描いて向上します。すなわち初めは目に見えて効果が出てきますが、あるところで効果逓減の法則にしたがって、伸びが止まってきます。そこで、それまでひそかに準備されてきた次世代技術Bが登場し、Aを追い抜いていきます。そのBにもやがて限界が見え、次の技術Cがこれを代替してゆくというわけです。

『【第91号】成熟度モデルを考える』の続きを読む・・・