DRI通信

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

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

【161号】「DOAは永遠です」

2010/03/01

■情報システム
情報システムは情報処理プロセスP1、P2、・・・のネットワークから構成され
ています。江戸時代には、プロセスはすべて人間が担当し、インターフェースの
メッセージは音声か紙の上に表現されていました。音声ならば蜜結合、紙ならば疎
結合になります。現代でも販売実績(要約データ)を見て、販売単価や発注量(意
思決定データ)を決め、また棚卸しをして棚残(観測データ)を修正したりなど、
人間のプロセスは残っていますが、多くのプロセスがコンピュータ・プログラムに
よって行われています。したがって、多くの電子化されたメッセージが飛び交うわ
けですが、人間が介在するところには、画面や紙が登場します。

■POAとDOA
プロセスは他のプロセスからインプットメッセージを受け取り、アウトプットメッ
セージを生成して他のプロセスに渡します。プロセス設計担当者が、「そのアウト
プットを誰(と誰)がどのような形式で必要としているかよりも、プロセスの機能
・性能を満たすことを優先して考える」というのが、POAということになります。
POAの場合は、一般にメッセージの形式は「送信側と受信側の2者間で決めれば
よい」として取り組まれ、プロセスが多くなると、そのネットワークはスパゲッ
ティ状を呈し、後々の保守に問題を残すことが多くなります。

これを避けるために、関与するプロセス間で送受信されるメッセージの通信場(D
H:Data Hub)を先行して設計し、これを前提にプロセス設計を行うのがDOAで
す。DH設計の素材はプロセス間メッセージですが、この実装独立の仕様はプロセ
スを設計しなくても、プロセスを識別した段階で確定可能なはずです。一般には現
行の画面・帳票が使われます。

POAでは送受信メッセージは「流れるもの」として実感されます。DOAでは送
受信メッセージは「DHに鎮座するもの」として実感されます。DHを太陽とすれ
ばプロセスは惑星になります。したがって、POAの設計者は自己中心的にプロセ
スからデータを見る天動説、一方DOAは太陽を中心に考える地動説の立場に立っ
ているかに見えます。DOAは他のプロセスの存在を意識しており、より広い世界
観を持っていると言えるでしょう。これによって逆に「送信は所定のメッセージを
DHに届けさえすれば良い、受信者は自分の都合のよいタイミングで、DHを検索
すればメッセージを受信できる(ただし単純検索を除く)」という簡素な通信が実
現できることになります。

インプットを与えられて、プロセスを設計し、アウトプットを考えるのは、自然な
順序なのでやさしい。しかし、「インプットから所定のアウトプットを得るための
プロセスは何か」を考えるのは難しい。逆算で、人間の性に反するからです。昔将
棋の故原田八段が3手の読みを指導していました。「こう指す、するとこう来る、
そこでこう指す、これで棋力がアップするよ」と言っていました。DOAは、先読
み、試行錯誤、逆算を要求するので、ちょっと高級な思考と言えます。

■インターフェースを素材にDHを設計
物理学は、分子、原子、素粒子と要素還元法によって細分化し物性を究明して行き
ました。情報システムでも、たとえば「資材購買を購買計画・購買依頼・見積発注
・・・と分解し、さらに見積発注を発注先決定・発注と言うように要素還元的に分
解し、これをWBSとして表現する」などはよく行われるわけですが、「分解した
プロセス名は記述するが、その間のインターフェースは記述しない」といったケー
スが多々見られます。これは、DH未確定のままプロセスの設計を行い、スパゲッ
ティ構造を招来するPOAの典型的な進め方かと思われます。国を作ったが、国境
を決めなかったので、後でトラブルが発生するのと良く似ています。

DHを設計するには、①素材メッセージを収集する、 ②抽象化を行って意味と粒
度を把握する、③矛盾を調整し整合性をとる、などの作業を行うことになりますが、
多くの場合③には政治が必要になります。このため企業内は可能でも、企業間は難
しい。DHは、概念DB構造図として表現されますので、成果物として、まず
「メッセージ対応のイベント系エンティティタイプおよびその属性、さらにこれら
属性を定義するリソースエンティティタイプおよびその属性」の仕様が確定するこ
とになります。

リソースは、社員・顧客・商品などの経営資源を疑義なく表現するものであり、イ
ベントは受発注・生産などにおいて、これらリソースがどう関与しているか、ビジ
ネスの枠組みを表現しています。これをTHデータモデルでは、たとえば
 [品#]-(品名、単価、重量、・・・)
 [受注#]-(顧客#*、(顧客名)、受注品#*、(品名)、(単価)、受注
単価!、数量、
<受注金額>、届先住所、・・・)

(注)[A]-(B)はAがKEYであり、BがAの従属属性であることを示す。
*は
参照KEYであること、従属項目を囲む()は冗長属性、<>は加工属性、また!
は意思決定データを示す。

のように記述します。このビジネスの枠組みを規定する、メタデータと呼ばれる、
エンティティや属性は、情報システムの根幹を規定する、企業レベルの貴重なデー
タです。リソースを識別するコード体系と並んで、全社データ流通を実現する鍵と
なるものであるため、私は「システム広辞苑」と呼んでいます。

■DOA推進の障害
しかしこのメタデータ管理は、開発担当者任せなど、ほとんどの企業においてうま
く行っておらず、DOA推進の障害となっています。その理由としては、まず次の
ようなものが考えられます。
 ・情報流通を実現するために全社レベルで共有管理すべき企業資産であるとの
認識が、マネジメントにも担当者にも欠けている。その理由は、マネジメントは情
報問題は担当者に任せたつもり、一方担当者は個別アプリの開発しか頼まれていな
いと考える。
 ・メタデータに関する知識は、開発時OJT的に経験しないと身につきにくい
高度な内容を含み、プログラムメンテと言った、他の業務と違って新入社員には引
き継げない。
 ・習得した人は、視野が広がり的確な判断ができるため、開発に動員され、保
守段階になると担当者が不在となってしまう。
 ・メタデータ管理は、縁の下の仕事で地味で変化が少なく、「成功するのが当
たり前、失敗したら怒られる」。またマネジメントの評価も低いので、担当者は続
けたいと思わない。
 ・メタデータモデルは、まだ情報システムの全局面をサポートしておらず、未
完成の部分を残している。

しかし、それ以前に「情報システム=ソフトウエアシステム」の発想から、
 ・可視化は目的ではない、要はユーザが使えるプログラムを作ることだ
 ・パッケージ依存やSIer丸投げで済ましても、安ければよい
 ・レガシーやパッケージを繋ぐときスパゲッティが出来るのは仕方のない必要悪だ
 ・ソフトには寿命があり、5-10年ごとに作り直すもの、問題は開発プロジェクト
  の中で解決するのが基本
と考えるスタンスが根本原因になっているケースも多々あると考えられます。

■DOA推進の技術的対策
このようにDOAへの障害は種々あるわけですが、「情報システムは商品・サービ
スにおける競争力を支援すべきもの」と考える企業においては、その根幹はDOA
によって構築すべきであり、技術的には次のような対策が有効と、筆者は考えます。
 ①DOAの可視化コンセプトを身につけるために、IPFチャートを作る
 ②プログラミングレスを実現する
 ③データ管理のSaaS化を行う
 ④メタデータの標準を確立する

①で可視化の突破口として、IPFチャートを選んだのは、分かりやすさから
です。データモデル図は初心者にとって若干とっつきにくいのですが、IPF
チャートは多少の規則はあるものの、抵抗感を持つ人はほとんどありません。素材
はデータモデルと同様、画面・帳票サンプルです。特に新入社員教育の中に取り込
む案が面白いと考えます。先輩が会社業務の説明を行う代わりに、新入社員を2-
4人のチームに分け、これにアプリ対応の数枚の画面・帳票を与え、若干の説明を
してIPFチャートを作らせます。レビュー後発表会を開きます。これによって、
新入社員は会社業務を広く深く理解し、同時にこれまで暗黙知だった業務フロー図
が整備されます。新入社員は情報部門およびユーザ部門に配属になるでしょうが、
以後お互いIPFチャートを共有して効率的なコミュニケーションが行われるもの
と期待されます。またIPFチャートは、業務処理よりその成果物であるIOを優
先して認識し、かつ発生した情報はすべて一旦DBにストアすべきとしていますの
で、知らず知らずに「DOAアーキテクチャが当然」という世界観を身につけるよ
うになる-この点はBPMNなどを大きく上回る-と期待されます。

②は、当初からのDOAのターゲットです。まだ改良の余地は残されています
が、丹青ビジネス社ほか、種々のアプローチが成功し始めています。将来ともプロ
グラミングの名人に依存すべきものが若干残るでしょうが、大部分の通常の画面・
帳票対応のプログラムは自動化できるでしょう。そのときの保守はメタデータだけ
となるはずですから、保守は大幅に合理化されると考えます。

③は定型的なメタデータ管理をアウトソースするものです。コアとなるビジネ
スモデルの変更は自社で握らなければなりませんが、機械的な整合性管理など、大
部分のメタデータ管理は外部依存が可能になると思われます。

④メタデータの構造の最終形は、まだ見えていないと考えられます。メタデー
タのカバーすべき範囲が確定していませんし、その設計素材が確定していません。
素材に実装従属の要素が混入すると、IT進化により揺れ動き、収拾がつかなくな
る恐れがあります。したがって安易な多数決や政治決着でない、メタデータの標準
の確立が望まれます。

■ DOA推進のマネジメント
しかしDOAの成功に欠かせないのは、DOAのマネジメントだと考えます。今多
くの企業における情報システム問題として
 ・保守に時間と費用がかかる
 ・保守に人がとられて新規案件にかかれない
 ・システムは暗黙知となり、かつSILOシステム間にスパゲッティ通信があ
り、誰も全貌がつかめない
などが挙げられています。その第一の原因は、ユーザ部門の要求に基づいて、戦略
計画不在のまま、個別アプリを構築してきたからだと考えます。この責任は、所定
の機能を所定の期間と予算で開発した、ユーザ部門にも、開発担当責任者にも問う
ことが出来ません。本来はシステム部長やCIOの責任ともいえますが、多くのS
ILOシステムは着任以前から稼動していたというケースも多いでしょう。した
がって、「従来の延長線上では解決しない、これからどのような責任体制で臨むべ
きか」が問われていると考えます。

そこで筆者は、開発プロジェクト以前の、会社における情報システムの位置づけ・
コンセプト・体制の見直しを提案したい。今までの体制は、定期的にソフトウエア
の再構築を繰り返すPOA向けの体制だったのではないか。メタデータやリソース
データは勿論、イベント系のデータ構造も、再構築ごとにスクラッチするようなも
のではありません。業務ルールの変更やM&Aに対応して変更が発生するといって
もプログラムとは雲泥の差です。DOAの成果物を、プロジェクト単位のPOA的
ライフサイクル感覚で扱うのはミスマッチではないでしょうか。またプロジェクト
単位で問題解決を図るSIerの体質にもフィットしません。DOAのライフサイ
クルに合ったコンセプト・体制を指向すべきと考えます。またDOAではシステム
スコープをアプリ横断に、時として企業横断に拡大して取り組むため、標準の異な
るアプリシステム間をつなぐ-POA時代には、SILOを大きくしてスパゲッ
ティの複雑度を下げるなど、本格的には取り組まれていない-問題を解決しなけれ
ばなりません。

したがって、次のようなソフト開発以前の、TOP、LOB(Line of Business)、
一般社員、DMO(Data Management Office)の役割について、見直す必要があり
ます。
 ・TOP :リソース(人・組織、設備、顧客、商品・サービス等)の先行手
配、および業務モデル設計(誰がどの情報を扱うか)
 ・LOB :既存リソース(在庫、資金等)の有効稼動管理(SCMを含む)
 ・一般社員:日常オペレーション
 ・DMO :業務モデル把握管理

今までTOPは、情報問題はシステム部門に一任してきた企業が多かったでしょう。
そのため個別アプリのSILOができて、後追いで対応するためにスパゲッティ化
が進んだと見られます。やはり全社情報戦略計画には、TOP/CIOの関与が必
須のはずです。DMOは業務モデルを分かりやすく可視化して、TOP/CIOを
サポートする必要があります。こうして経営と情報のタイアップを図るのが、今後
のあり方ではないでしょうか。

■DOAは死なず
「DOAは古い」、「OOだ」、「SOAだ」と流行は変わりますが、いずれも定
期的にソフトを作り直すPOAの世界観を前提としたものに見えます。ユーザの情
報要求である画面・帳票、これに含まれたデータを、実装独立の世界で正しく位置
づけ、これをベースに情報システムを構築・運用するDOAがどうして古くなるの
でしょうか。私は、「DOAは死ぬはずがない、DRIはこれを追求して最先端を
行く限り、当初理解する顧客は限られるとしても生き残れる。逆に確実な短期のR
OIを指向して、多くの顧客の理解する流行技術に目がいくと、大手との体力勝負
になって危ない」と考えていました。最後に申し上げたい、「DOAはジャイアン
ツに劣らず永遠です」と。

以上で、13年続けたDRI通信も、終わりとします。長らくありがとうございま
した。

追伸:
先の160号で述べましたように、私の今年の課題は、概念リポジトリの決定版
(?)を本にすることですが、フリーで動けますので、認知症が始まるまで、日本
のDOA推進のための若干の活動は可能だと考えています。DRIの事業にマイナ
スとならない範囲で、時間は限られますが、DOA推進のためのマネジメントや技
術に関する相談・講演などでお役に立てればと思います。国から年金が出ています
から、交通費・宿泊費のみで対応できます。メール等で遠慮なく、mtsubaki@kce.
biglobe.ne.jpまでご連絡ください。

なお、皆様には宿題をお願いしたいと思っています。私はDOA手法の開発にあた
り、次の7つの仮説-他のDOAでは必ずしも前提としていない-を置きましたが、
検証不十分のものがあると思います。「おかしい、こう修正すべきだ」などがあり
ましたらお知らせください。

7つの仮説
①ビジネスは6業種に分類できる。
建設、生産財製造、消費財製造、小売、卸、サービス
②企業のビジネスシステムは、リソースを使う基幹系と、これを作るリソース整備
系に大別できる
③処理システムは5階層から成る
 業務ドメイン-システム-業務プロセス-業務/IO-IOデータ
④3階層通信場
 E1(個別アプリ)-E2(アプリ横断)-E3(企業横断)
⑤エンティティタイプ5種類(大分類)
 リソース、在庫型、断面、要約、イベント
⑥データ機能コードと加工データ13種類
 K、R、(加工)W、T、S、I、G、X、D、A、C、B、E、V、R
⑦SPF操作子11種類
 P、J、G、S、E、M、H、V、U、R、C


【160号】「PLAN―DBの出自」

2010/02/03

■DOA40年
2000年に社長を、2006年に会長をやめ、フェローの肩書きで勤めていまし
たが、この2月でDB研と中断中のK2Wを締めくくって、社員も辞めることにい
たしました。そこで、DOA40年にわたるPLAN-DBの出自と今後の展望を
つづってみることにしました。

■千代田化工での化工設計
私は1959年工学部化学工学を卒業して、化学プラントの最上流の設計「化工設
計」に携わりたいと、千代田化工建設に入社しました。石油化学はなやかなりし頃
で、反応・分離・加熱・冷却などの単位操作(処理工程)を組合わせて、所定の物
質を作るプロセスを設計する仕事です。設計結果はプロセスフローシートと呼ばれ
る図面に表現されます。図面の書き方は、ほぼ標準化されていて、設計者によって
若干の違いはあるものの、読む人にとって気になるほどのものではありません。図
面言語としては完成度の高いものが確立していたと言えるでしょう。

設計の中心は、顧客の要求する製品を作り出すための物質・熱収支計算です。これ
は機器と機器のインターフェース「ストリーム」の整合性を保証するものとなって
います。これを実現するための機器の形状・寸法・材質・強度などの設計は、物質
・熱収支計算の後で行います。すなわち実装独立の整合性を保障し、その結果をも
とに実装設計を行う手順となっています。

入社当時はまだコンピュータはなく、気液平衡の試行錯誤計算も、計算尺や手回し
の計算機を使ってやっていました。入社5年後くらいにIBM360が導入され、
技術計算はFORTRANで、事務計算はCOBOLで機械計算ができるようにな
り、手計算は機械計算に移行していきました。

化工計算では機器に出入りするストリームは、エタン、プロパンなどの各分子のモ
ル流量を表すベクトル(アレイ)で表現されますので、これを処理する機器の働き
は変換マトリクスで表現することができます。このベクトルとマトリクスによる、
リニアモデルと呼ばれる表現が、所期の製品を作るための最も単純化されたプロセ
スの表現となります。私はこれをベースにプロセスシミュレータを作るべく、かな
り早い段階に化工エンジニアから足を洗うことになりました。と同時にこのいわば
GOA(Goal Oriented Approach)は、「整合性のとれた実装独立設計先行」とと
もに、私の体にしみ付いて、以後の活動に影響を与えて行ったように思われます。
実装独立すなわち「概念」と「論理」の区別の曖昧なシステム屋を見かけますが、
この真の理解にはユーザ部門での原体験が必要なのかもしれません。

当時はまだ、インプットはカードパンチ、アウトプットは紙です。事務計算のアウ
トプットは、早めに順次ファイルに移行していきましたが、プログラマーの関心事
は処理をいかに機械化するかでした。千代田化工の仕事は、最上流の化工計算から、
反応器・蒸留塔・熱交換器・ポンプなどの機器や配管の形状・寸法・材質決定・強
度設計、これら機器・配管の調達、工事計画、工事管理と続きます。この各作業で
コンピュータが使われるわけですが、このままいくと「人間はコンピュータのアウ
トプットを見て次のインプットを作る係りになるな」と思いました。

■Information Algebraをベースに
そこで早晩、各作業を連携するために各アプリケーションがどのようなデータを受
け渡ししているかを解明しなければならないと考えました。データをどう表現すべ
きかを考えているときに遭遇したのが、CODASYLのInformation Algebraという文献
でした。そこでは、V=A(E)すなわち
 Value=Attribute ( Entity )
が紹介されていました。「われわれの眼にする値は、あるエンティティの属性であ
る」とのこと。したがって縦軸にエンティティ(インスタンス)を、横軸に属性を
並べ、その交点に値を書きこれを適宜並べ替えると、エンティティタイプおよび共
通の属性が見えてくるはずです。これを基にTH(椿・穂鷹)モデルの原型を作り、
種々の下流工程の帳票を分析して行きました。1970年頃、40年前のことです。
「これによって、上流から下流に至る各アプリケーションを連携できると」いう確
信を得ることができました。そこで個別業務の機械化と同時に、これらを統合する
CHEIS(CHiyoda Engineering Information System)の開発が必要であると、
その構想を提案しました。

■ミドルウエアDPLSの開発
当時はまだデータベースという言葉はありませんでした。化工関係のアメリカの学
会で、プロジェクトファイルというアイデアが発表されました。プロジェクトの上
流から下流をコンピュータ上で繋ごうという、似たアイデアです。CHEIS実現
のためには、「OSの機能だけでは難しい、ミドルウエアが必要である」と考えま
した。IBMにPLANというソフトがあることが分かりました。必要なサブプロ
グムを事前にリンクしておかなくても、実行時にリンクするダイナミックリンクの
機能があります。今のStored ProcedureないしWeb Servicesに近い機能です。顧客
ごとに異なった機器構成からなるプロセスを扱うには非常に好都合です。またコマ
ンド言語があり、これによりユーザは処理とそのためのパラメータを、アプリによ
らず統一的な形式で定義できます。まだGUIはなく、CUI(Command User
Interface)の時代ですが、今のXMLに似た形式の言語です。当時プログラマーが
思い思いのユーザインターフェースを設計し、ユーザはその対応にまごついていた
わけですが、これが解消できます。そこでこのPLANにDBMS機能を付加し、
DPLS(Database Programbase Languagebase Support)というミドルウエアを開
発することになりました。

DBMS機能はISM(Information Structure Model)、DSM(Data
Structure Model)、SSM(Storage Structure Model)の3階層からなる、今で
言う概念、論理、物理を分離したモデルでした。また今でいうリソースDB、また
プロジェクトごとに用意すべき複数個のイベントDBなどn個のDBから成る環境
を管理するために、DD/D-今で言うリポジトリ-を内蔵するものとしました。
当時SIerの部長だった穂鷹さんと共同で、THデータモデルをほぼ完成させま
したが、彼は「DPLSは自己記述型の先進的DBMS」と評し、大手メーカーへ
の説明会をアレンジしてくれました。私は1975年ボストンの第1回VLDB
(Very Large Data Base)学会で発表しましたが、それはP. P. ChenのERモデル
と同時でした。

社内で、説明のためデモシステムを作りましたが、高い生産性を確認することがで
きました。私は35年後の今でも非常によくできたエンジニアリングDBMSだっ
たと思います。うまく活用できれば、最も難しいエンジニアリング企業のミドルウ
エアとして大きな貢献ができたのではないかと残念に思います。しかし、会社はD
PLSでなく、当時ようやく登場したIMSを使うと決めました。「DPLSを使
うには広汎なデータの洗い出しと整理が必要だ。IMSならその必要がない」と言
われました。技術でなく、人間との戦いは人生の浪費になると思って千代田化工を
辞めることにしました。

■方法論PRIDEとの出会い
そこで入ったのが、日本システミックスというシステムコンサルティングの会社で
す。アメリカのMBA社からシステム開発方法論PRIDEを輸入販売していました。
「情報システムはInformation Resource から構成すべき、だからInformation
Resourceの管理が鍵だ」という、組立加工製造業的な方法論です。その思想に問題
は無いのですが、データモデルの面で不十分な点があったので、THデータモデル
でこれを補うこととしました。

「PRIDE+THデータモデル」による先進企業に対するコンサルは、非常に高
い成功率だったと思います。THモデルに加えて、これを補強する業務フローを記
述するIPF(Information Process Flow)チャート、SPF(Schema Process
Flow)チャートも実プロジェクトに適用し有効であることを確認することができま
した。PRIDE技法では、「サブシステム」という処理粒度の基準、またIOか
らDBを決めるべきとする考え方が参考になりました。

なお、同社に在籍したとき、n個のDBから成る環境を前提としたミドルウエアD
BCMS(DB Complex Management System)に関する調査レポートを作り、IPA
に納入しました。私の今の3階層DHアーキテクチャはこの延長上にあると言えま
す。

■PLAN-DBコンサルテーション
しかし1985年、「THデータモデルによるDOAは、PRIDEユーザ以外に
も普及すべき」との思いからDRIを創立することにいたしました。当時はシステ
ム部門主導で、メインフレーム上に基幹系システムのRDB構築を行っていた時代、
THモデルを中核にした、弊社の方法論PLAN-DBは好評でした。「リソース
DBは全社に1個、個別アプリと切り離すべき」という主張はほとんどの顧客で受
け入れられ、1980年代に今で言うMDM(Master Data Management)が実現で
き、その企業では後の混乱を避けることができました。それから20年以上経過す
るわけですが、「保守や開発の合理化は1%台ではなく10%以上と考えられるの
で、顧客には大変なROI-大きいところでは5千万円が100億円になる-を提
供できたはず」とは、私の皮算用です。

1990年代に入ると、C/Sによるダウンサイズが流行し、システム部門による
統制が効かなくなりMDMが劣化していきました。バブルがはじけ、パッケージ導
入が多くなり、Y2Kに忙殺され、システム部門のビジネス理解力がダウンしてい
きました。

私は
「情報システム=ビジネスシステム+ソフトウエアシステム」
だと考えますが、「情報システム=ソフトウエアシステム」との誤解があるので
しょうか、パッケージやSIerに丸投げする企業も少なくありません。ユーザ企
業の情報システム部門は、ビジネスシステムを全社横断で可視化し経営をサポート
する役割があるはずです。可視化には分かりやすい正しい図面言語が必須のはずで
す。

これまで統制不十分のままシステム化を進めてきたため、「アプリが1000個以
上ある、データ項目は40000以上ある、パッケージも入れた、さらにグローバ
ル化、M&Aが進められる、これに迅速に対応すべし」など誰の手にも負えないよ
うな状況になりつつある企業も少なくないと思われます。これらの整理は機械では
できません。人手になりますので如何に巧妙に進めるかが問われます。進め方その
ものを試行錯誤により決めていかなければなりません。

私は初めが肝心、分かりやすい主なアプリを選択し、このアプリ間のデータ(先の
DRI通信159号の3階層DHアーキテクチャにおけるE2データ)を手掛かり
にE2(アプリ間のイベントデータハブ)の構造の可視化から進めるのが得策と考
えています。したがって個別アプリ内のE1(アプリ内のイベントデータハブ)の
データは当面眼をつぶります。E2に登場するリソースは共用性の高い重要なデー
タですから、標準化不全ならばこれから手をつけなければなりません。この作業-
2,3ヶ月を想定しています-の中から、その企業に合った効率的な進め方、整理す
べきアプリなどが発見できると考えます。

■今後の課題
これまで40年かけて、DOAの方法論を追求し、コンサルティングを通じて人材
育成を図ってきたわけですが、1990年まではよいとして、その後はなかなか苦
戦だったように思われます。方法論もツールも進化していますので、「規模が拡大
し、体制がとりにくくなった顧客における環境変化」が主な原因かと思われます。
しかし策はあります。MDMは必須条件として、「スパゲッティフリーを実現する
3階層DHアーキテクチャとプログラミングレスを実現するリポジトリツール」が
鍵ではないかと考えています。

以上の記述にあたり、昔を省みたわけですが、実装独立先行、そこでの整合性保障,
GOA、マルチDBなど化工設計やプラントエンジニアリングから習得したものが
多いのに気づきました。その意味では私にとっての化工設計の10年弱は、その後
のDOA開発方法論開発のための準備期間だったのかもしれません。確かに情報シ
ステムと最もよく似たハードのシステムは化学プラントだと思います。都度一品物
を設計して建設します。図面をベースに成果物を共有しなければなりません。この
ため設計方法論も似てくるようです。ただ、ハードシステムは重力が働くため、図
において特に約束を設けなくても個人差は出ませんが、情報の場合は重力の規制が
ないため、各人思いのままに図を書きます。私はエンティティの粒度によって、粗
いものが上、細かいものが下と、配置規則を決めましたが、成功だったようです。
またリソース系は標準部品の定義ですから、これを「システム広辞苑だ」として、
成果物のイベント系データ構造図から分離するものとしました。

私は、Information Algebra以外、参考にしたい文献を発見できませんでした。
1971年頃、E. F. CoddのRDMの論文を読みましたが、意味論が抜けているし、
n個のDBを扱っていないのでツールはできても、企業モデルにはなりえないと考え
ました。また、P. P. ChenのERモデルは意味論的アプローチでしたが、属性よりも
エンティティタイプを優先するので、整合性-特に加工・加工元データの整合性-が
取りきれず、品質が上がりにくい、またサブジェクトエリアの概念ではn個のDBが
構成する全社モデルが裁ききれないと考えました。結局、コンサルで取り組んだ200
近いアプリケーション、特にその画面・帳票と格闘しながら、方法論を作っていきま
した。困ったときは「プラントの場合はどうしているか」を考えました。概念モデル
に限定してですが、3階層DHアーキテクチャによって、スパゲッティフリーが実現
できると考えたので、プログラミングレスを実現できる、私なりのメタデータの決定
版を確定し本にしよう、これを2010年の課題としたい、と考えています。
注文などありましたらお寄せいただきたいと思います。


【159号】「3階層通信場をサポートするリポジトリ」

2010/01/04

■概念ミドルウエア
先の158号において、スパゲッティフリーを実現する2つのミドルウエア
 ・ACMGR-iDBMS(Access Manager-intelligent DBMS)
 ・WFMGR(Work Flow Manager)
を紹介しました。その後のセミナーにおいて、「アーキテクチャと言うからには、
データ通信場だけでなく、それらを連携するミドルウエアを明示すべきではないか。
EA、SOAの議論が分かりにくく、かみ合わないのはそのためではないか」と提
言したところ、「実装独立のアーキテクチャになぜソフトウエアが登場するのか」
というご質問をいただきました。「ミドルウエア=ソフトウエア」の誤解を招いた
ようでした。「概念ミドルウエア」とでも言うべきだったのかもしれません。

実装独立のインプットから、実装独立のアウトプットを生成する処理は、実装独立
の処理と言えるでしょう。これがアプリレベルでなく、より汎用的レベルだったた
め、ミドルウエアと呼んだまで。別にメインフレームかクラウドか、COBOLか
JAVAか、などが絡む話ではありません。上記2つのミドルウエアは、リポジト
リを参照することによって、エンティティレコードやメッセージレコードの、汎用
的な通信処理を行います。したがって、このとき参照するリポジトリの構造が課題
となります。

■3種のリポジトリ
ディレクトリ、DD/D、リポジトリなどと、メタデータをストアするDBは、機
能の向上-当初はDB構造記述、データ定義、CASEツールサポート、後に業務
フロー記述、アプリ間通信など-とともに名前を変えてきたわけですが、その最終
的な姿はまだ見えていないと言えるでしょう。最大の問題はITが変化/進化する
ため、プラットフォームが変化し、これによってソフトウエアが変化するためです。
したがって、筆者はリポジトリを考えるにあたっては、IT変化の受け方に応じて、
まず
 ・業務モデル・リポジトリ(ビジネス世界のデータ、プロセス等を記述)
 ・ソフトウエア・リポジトリ(プログラムや電子化ファイル等を記述)
 ・プラットフォーム・リポジトリ(PC、サーバー、ディスク、NW等を記述)
に分けて考えるべきだ、と主張しています。しかしこれは、リポジトリ製品をビジ
ネスとして扱う、ソフトウエアベンダーにとっては、あまり興味を引く課題ではあ
りません。今のニーズに応えて、市場を確立し、たくさん売ることが課題だからで
す。こうして多くのリポジトリ製品が発表されましたが、ITの変化がより激しかった
ためか、この分離を無視した多くの製品が、予想以上に速く姿を消していきました。

■リポジトリの最終形
筆者は、ソフトウエア・リポジトリやプラットフォーム・リポジトリはプロジェク
トが具体化し、環境が確定してから検討すべき課題と考えるため、まずは業務モデ
ル・リポジトリに限って考察しているわけですが、業務モデルに限っても「これが
最終的な姿だ」と立証することは、非常に難しい課題だと考えています。標準化団
体に属する有識者が、多数決で「これをリポジトリ構造の標準にしよう」と決めれ
ばそれで決まるといった性質の問題ではないと考えるからです。世の中には、サイ
エンスが対象とする「決まっている問題」と、人間が相談して「決めればよい」問
題があるわけですが、リポジトリ構造には前者が種々含まれており、提案されたリ
ポジトリ構造の姿から、これを判定することは神ならぬ有識者にも難しいと考える
からです。

それではどうするか。筆者は多くの業務アプリケーションでのモデル化の経験、
すなわち、
 ①DB構造は、素材となる画面・帳票に立脚する
 ②PLAN-DB技法によって、個人差なく同じ概念DB構造が得られた
 ③DBのスコープは素材となる画面・帳票によって決まるから、その画面・帳
票は適切に選択しなければならない
を通じて、「リポジトリ=メタデータDB」においても、リポジトリ構造の決定の
ために、①業務アプリケーションを表現する画面・帳票-業務フロー図、概念DB
構造図、システムアーキテクチャ図、WBS、データ定義書など-の形式がいかに
あるべきか、②この画面・帳票から個人差なく概念DB構造を導く技法、③適切な
スコープの設定による素材の選択、が必須条件になるのではないかと考えます。

すなわち、少なくとも①、②、③の議論が収束してはじめて、概念リポジトリ構造
の標準化の議論が進められるのではないか、と考えます。最大の問題は、①の
システムドキュメントに関してで、現在、業務フロー図としてDFD、BPMN、
IPFチャートなど、また概念DB構造図において、リソースデータを分離する/しない、
加工データを明示する/しない、などまちまちなものが使われており、標準化
には程遠い状況かと思われるからです。やはり、「製品=システムドキュメント」
を決めなければ、「部品=リポジトリ属性」は決められないのではないでしょうか。
これらシステムドキュメントは、発注画面、生産指図書などの業務アプリケーショ
ンのドキュメントに比較して、システム開発という抽象的な業務を支援するために、
収束が難しいわけですが、リポジトリ構造はこれに依存するために、一層収束が
難しいのだと思われます。

②に関しては、たとえばTH図やIPFチャートなど、図特有の分析の難しさは
ありますが、システムドキュメントにおいても、PLAN-DB技法(f)により、
DB=f(IOs)
すなわち、「主要なn個のIOを決めればほぼ客観的にDB構造が決まる」が受け
入れられ、あまり問題は発生しないのでは、と予想します。

③に関しては、従来DBMSやCASEツールなどは、個別アプリの世界に終始し、
標準の異なるアプリの連携や、B2Bでの連携は対象外としており、逆にESB等
通信ツールは個別アプリの業務モデルの記述を除外するなど、メタデータの世界を
適宜「つまみ食い」する形式でカバーしてきたため、スコープの全貌がはっきりし
ませんでした。しかし、先の158号に述べた「3階層通信場アーキテクチャ」で
は、2つのミドルウエア「ACMGRおよびWFMGR」が、アプリケーション/
データハブの追加、すなわちスコープの拡大に、スパゲッティを発生させることな
く対応しますので、従来の業務データや業務プロセスを記述する部分とあわせて、
リポジトリのカバーすべき全体が、すでに抑えられている-いや「こんなメタデー
タが抜けているではないか」というご指摘があれば是非お寄せください、大歓迎で
す-と考えました。したがって、「A2Aとして扱うべきか、B2Bとして扱うべきか
議論の発生する、グローバルな協力会社の扱い」など運用上の問題は残りますが、
リポジトリ構造の収束は③に関しては解決可能と考えます。

■試作リポジトリにおいて
DRI通信誌上で、リポジトリ構造を議論するのは、あまりにこみいっていて、適当
でないと思われますので、別の機会に譲りますが、弊社システムドキュメントを
前提に試作いたしましたところ、リポジトリは大きく次の4つのパート
 BP.業務プロセス(WBSやIPFチャート、画面・帳票など)
 DH.データハブ・アーキテクチャ(データハブ間の関係など)
 AT.属性(概念DB構造図や加工データ仕様など)
 CV.標準変換(レガシーやパッケージなどとの変換)
から構成することができました。

この場合、ACMGRはDH、CV、およびATの一部(主に属性がどのデータハブ
に属するか)、iDBMSはATの一部(加工データ仕様)、またWFMGRは
DHおよびCVをアクセスすればよい、という結果になりました。このリポジトリ
を構成する一部のメタメタ属性は、これまでの文献等では見かけなかったもの
のように思いました。

もし以上の設計が正しいとすれば、各企業は、勿論コンテンツは違うわけですが、
全く同じリ汎用ポジトリ構造(注)により、その業務モデルを記述でき、A2Aは
当然として、B2Bでのスムーズな連携が可能になると考えました。

(注)ここではリポジトリの概念構造のみを述べています。これをどう分散し実装
 実装するかなどリポジトリの実装は別途設計すべきものとしております。
 したがってテーブルやプログラムなどのソフトウエア部品は対象外です。念の為。


【158号】3階層通信場アーキテクチャにおけるSOA

2009/12/01

■サービスはE2/E3通信場にある
POAでは、当該スコープのプロセスの設計を先行させ、他のプロセスとの連携/
通信はこの後で考えるため、その通信は必然的にスパゲッティ構造を作ります。
DOAはこれを避けるべく、まずプロセス間で通信されるべきデータを抽出し、これ
を標準化して通信場(DH:Data Hub)を設計し、これを前提にプロセスを設計し
ます。実装独立の通信場ですから、その素材は現状ビジネスでやり取りされている
帳票等から入手できます。通信場を規定する標準そのものは、値についてはリソー
スDB、形式についてはリポジトリDBに規定されるべきと考えます。

3階層通信場アーキテクチャでは、このDHを個別アプリ内(E1)、アプリ間
(E2)、企業間(E3)に用意し、プロセスは直接的でなく、必ずDHを介して
通信するものとします。SOAはSILO化したレガシーやパッケージを活用して、
安く速く連携しようというもので、当該DB/E1のデータは対象外ですから、S
OAを考えるときは、E2およびE3だけが対象になります。この場合、ユーザ/
AP(アプリケーションプログラム)の要求するサービスは、E2、E3設計時に
識別され、すでに存在していることになります(注1)。

(注1)リソースDBへの検索-顧客住所の検索、部品の電気特性検索など-や
   リポジトリDBへの検索-顧客番号の形式の検索、部品属性の一覧表作成
   など-は、ここではサービスから除いて考えます。

■E2/E3のデータの形式
E2、E3内のデータの形式は、次の2つと考えられます。
 ・エンティティレコード:正規形、形式はリポジトリに記述、宛先なし
 ・メッセージレコード :非正規形、形式、宛先はレコード内に記述

エンティティレコードとしては、製品在庫、売掛残高、今期実績利益(E2)や予
約座席(E3)などがあるわけですが、メッセージレコードとしては次のような-
近年XMLなどでの実装が話題となっている-ものが含まれます。
E2:①営業→生産、生産依頼
   ②生産→営業、納期回答
   ③生産→営業、出荷案内
E3:④バイヤー→サプライヤー、発注
   ⑤サプライヤー→バイヤー、納期回答
   ⑥サプライヤー→バイヤー、出荷案内

受取側にとってはこれがサービスになりますから、生産にとっての①、営業にとっ
ての②、③、またサプライヤーにとっての④、バイヤーにとっての⑤、⑥がサービ
スになります。

サービスとしては、エンティティレコードについては必要な結合処理を行う必要が
ありますが、メッセージレコードについては、そのままでサービスとして提供でき
ると考えます。

ただしSOAミドルウエアとしては、そのE1の形式や値に関する標準が、レガ
シーやパッケージなどで、E2やE3と異なっている場合の変換を行い、またメッ
セージレコードについては、そのユーザ/APへの送信を行うことになります。こ
の変換を行うミドルウエアをサポートするために、リポジトリとして属性対応テー
ブル、またリソースDBとしてコード変換テーブルを用意する必要があります。

■アプリ間データには何があるか
SOAの主題は企業内アプリ横断の通信ですから、3階層データ通信場アーキテク
チャにおいてはE2が主役となります。E2として扱うべきデータの種類はかなり
限定され、かつ安定しているのではないか。たとえば経営、購買、生産、販売、経
理、などを連携するデータが10年経ってもさほど変わるわけがない。したがって
これを可視化することによって、CIOの戦略立案が合理化できるはず、と考えま
した。

そこでE2のデータとして何があるかを考えました。考察だけなので仮説に過ぎま
せんが、筆者の仮説「3種類のアプリ間データ」
 ①計画・追跡データ
 ②在庫・引当データ
 ③要求・回答データ
について、以下述べることにします。

①は月、期、年などで立てた計画を、タイミングに応じて追跡するデータです。た
とえば年間利益計画(E2)について、「6ヶ月経ったが、半分行っているか」を
見る、などです。追跡には多くのアプリ(E1)のデータの反映が必要となります。
またプロジェクト業務の場合は、月、期、年でなく、構成作業単位ごと、進捗ステ
イタスごとにコスト計画(E2)を立てますので、これをアプリ(E1)のデータ
で追跡する、などとなります。

②は、在庫管理です。部品在庫は購買がプラスし、生産がマイナスします。製品在
庫は生産がプラスし、営業がマイナスします。売掛残は営業がプラスし、経理がマ
イナスします。このように、見込生産・販売などに多く見られるアプリ横断の在庫
データは-各E1アプリが重複して持つのでなく-E2で一元管理すべきと筆者は
主張します。

③は、要求・回答データをE2所属とするものです。特注品などは在庫しませんの
で、営業が生産に生産依頼し、生産が回答するような形式となります。宛先が決
まっているのだから、E2経由にするメリットがないようにも見えます-事実従来
は直接通信がほとんどです-が、リポジトリの内容だけで、1個のロジックにより
すべてを制御でき、またアプリ間の通信はすべてE2経由ということで、SOAが
分かりやすくなり、変更・管理がやさしくなると考えます。いま話題のESBは、
③からストレージ機能を除き即時配信としたものに一致する-したがって③はES
Bを包含する-ものと思われます。

「E2データとして、以上の①、②、③のほかに何があるか」は筆者の課題として
いますが、あってもさほど多くはない、したがって管理すべきメタデータも多くな
く、その追加・変更だけで、以後のアプリケーション連携の追加・変更に、いわば
「スパゲッティフリー」に対応できます。筆者は、保守の2大強敵は「個別リソー
ス」と「スパゲッティ通信」であり、前者はMDMによって、後者は3階層データ
通信場によって解決できるのではないか、「スコープの拡大には、スパゲッティは
必然」と考える従来のPOAに比べて、格段に保守が容易になるはず、と考えます。

■3階層データ通信場アーキテクチャのイメージ
さてこの3階層データ通信場アーキテクチャにおいて、どのようなミドルウエアが
位置づけられるべきかを考えます。紙面の制約から、リソース系DBとしてR3、
R2、・・、また3階層イベント系DHとしてE3、E2のほか、自社アプリ購買、
生産、営業などに対応するE1(n個)、また他社アプリとしてA、Bなどがある
ものとして考えます。ミドルウエアとして2種類、すなわち①自社アプリの生成し
たレコードを裁くACMGR-iDBMS(iDBMSを従えたAccess Manager)
および、②E2/E3にストアされたレコードを配信するWFMGR(Work Flow
Manager)を導入したイメージを図示します。

ACMGRはアプリケーションの生成したメッセージレコードおよびiDBMSの
生成したエンティティレコード(DRI通信154号参照)を受け取り、必要な変
換を行い、所定のDH、E1/E2/E3にストアするもの、またWFMGRはE
2/E3のデータに必要な変換を行い、所定のエントリーポイントに、所定のタイ
ミングで送信するミドルウエアです。リポジトリはこれらミドルウエアをサポート
し、変換、送信先識別、送信タイミング、iDBMSによる整合性データ生成など
に使われます。

図はもちろん検証されたものではありません。3階層データ通信場のイメージアッ
プのための議論のスタートが切れれば良いとして示しました。

 ┌――[WFMGR]←―――――――――REPO
 |    ↑   ↑                  |
 |┌-→E3 E2  E1 E1 E1・・・     |  R3 R2 ・・・
 ||   ↑   ↑   ↑  ↑  ↑       |   | |
 ||   ↓   ↓   ↓  ↓  ↓       ↓  ↓  ↓ 
 || [*******ACMGR-iDBMS*******]
 ||          ↑   ↑  ↑    ↑
 ||          ↓   ↓  ↓    ↓
 ||        購買  生産  営業 ・・・・・・自社アプリ(注2)
 ||          ↑    ↑   ↑   ↑
 └――┬――┬―┴――┴――┴――┴
  |  ↓    ↓
  |  A     B ・・・他社アプリ
  └―┴――┴―――
図-3階層データ通信場アーキテクチャへのミドルウエアの導入イメージ

(注2)入力チェックのために、各アプリもデータタイプ、桁数などメタデータを
利用しますが、コンパイル時(Compile 方式)なら直接、また実行時
(Interpreting方式)ならばACMGR経由入手するものとします。
アプリ機能は、加工データ整 合性をiDBMSに委託できるため、
ユーザからの入力を整えるだけと単純化 でき、自動生成/プログラム
レスが容易になっていると考えます。

■メタデータの全貌
リポジトリにストアされるメタデータの応用は、当初はエンティティタイプ、属性、
RDBテーブル、カラム、モジュールなどから始まったわけですが、その応用は従
来になく広がっています。ミドルウエアはメタデータの活用が前提です。仮説の域
を出ませんが、次号以降に、報告できればと考えます。先の仮説「3種類のアプリ
間データ」に対するコメントを含めて皆様の声を寄せていただければありがたいと
思います。


【157号】アーキテクチャを考える

2009/11/02

■アーキテクチャへのニーズ
EAとかSOAとか、業務横断、さらには企業横断の広域アーキテクチャが問題に
なっています。「なぜ今」、また「これにどう対処すべきか」について考えてみま
す。

アーキテクチャとはもともと建築の様式の意味でした。構造や設計法、工法に関わ
るとのことですが、芸術性はさておき、その建築物に課せられた機能を最大限に発
揮する構造を追及するものだったのではないでしょうか。機能の欠落や重複は論外、
適正な機能の配置、空間、調和が必須かと思われます。

このためには機能の列挙、整理、標準化が必要になるかと考えます。コンサート
ホールにはコンサートホールの、単身者マンションには単身者マンションのアーキ
テクチャが求められます。しかし建築には、何千年もの経験の蓄積があり、目に見
えるため、十分なフィードバックが行われてきました。

ところが情報システムの世界はどうでしょう。歴史が浅い、目に見えない、ITの
変化が激しい。さらにビジネスニーズの変化-単なる変化というより、当初想定し
なかった他のシステムとの連携によるスコープの拡大など-も激しい。したがって、
機能の欠落、重複は累々。その列挙、整理、標準化が追いつきません。本来必要な
はずの10倍の-作成タイミング、作成者の異なる-プログラムが稼動していて、
10倍の保守コストと時間を要求し、ときどきちぐはぐな答えを出力し担当者をあ
わてさせます。そこから、アーキテクチャ、アーキテクトが叫ばれてきたものと思
われます。今、アーキテクトによる青写真が求められているのでしょう。

青写真無しに都市を作るとどうなるでしょう。勝手に建物を建てます。道路はその
隙間をぬって、後から作ります。どうしても邪魔な建物は壊して別のところに建て
直さなければなりません。情報システム部門は、これまでこんなことを繰り返して
きたのではないでしょうか。都市計画は、日本でも奈良時代から行われてきたわけ
ですが、多くの企業の情報システム計画は、まだ奈良時代以前の状況のように思
われます。

■必要な取り組み
では情報システムアーキテクチャを構築するための取り組みはどうあるべきなので
しょうか。まだ試案レベルですが、私は次の7項目を提案したいと考えます。

 ①データの整理から入る
 ②実装独立に進める
 ③外部設計に留意する
 ④抽象化思考に慣れる
 ⑤データの関係を見る
 ⑥機能の共通化を図る
 ⑦機能分割に際しインターフェースの識別を重視する

①は、私がDOA屋だからではありません。データに欠落・重複・矛盾があれば、
必ず機能にこれが反映されるからです。結局、正しいデータモデリングが必要に
なるはずです。経験者は、スピードアップのために、トップダウンに行うことを主張
する傾向がありますが、原則はボトムアップに、属性、エンティティタイプ、DB
タイプと積み上げるべきと考えます。トップダウンは往々にして、ミドルダウンと
なってスコープが狭すぎたり、思い込み優先で、顧客と仕入先を取引先として統一
するチャンスを失ったりするからです。

②はSE思考の方が、特に留意すべきことです。RDBのテーブルを作ることでは
ありません。ITの違いや変化に影響を受けず、ビジネスユーザと正しくコミュニ
ケーションをするためです。

③は他システムとの連携が後追い設計にならないためです(注1)。多くの設計は
スコープを決めると、その中だけに注力し、外部との連携は後追いで対応するため、
スパゲッティ構造を招き、保守に問題を残し、寿命を縮めます。外部設計をどこま
で行うかの難しい問題はありますが、当該システムをどう位置づけるかは重要な課
題です。SIerには難しい課題であり、ユーザ企業のシステム企画者への期待が
大の課題です。

(注1)外部設計には、システムアーキテクト向けの「他システムとの連携」の意
味と、SE向けの「単なるユーザインターフェース」の意味と2つあるようです。
ここでは前者の意味で使っています。

④はモデル化といっても良いでしょう。物事の、とくにデータの共通点や相違点の
判定に不可欠のものです。たとえば、品番、顧客番号、受注番号には共通点と相違
点があります。すべてKEY(識別子)であり、特に品番、顧客番号はリソースの
KEYですが、受注番号はイベントのKEYです。これが発番や整合性管理のロ
ジックに影響を与え、正しく把握できないとき、冗長コーディングを発生させます。
在庫数量と売掛残高の共通点と相違点についても同様のことが言えます。
われわれはエンティティタイプを、リソース、イベント、在庫型、要約、断面に5大分類し、
また加工データを13種類に分類しています-ここまで抽象化を要求するデータモ
デル手法は世界中でほかにないようです-が、これによって処理ロジックの共通化
ができ、冗長性が除かれると考えるからです。また個別対応が減り、処理ロジック
の事前準備ができますので、信頼性の向上が期待できると考えます。

⑤は、データがそれ自身の性質と同時に、他のデータとの関係が非常に重要だから
です。特にEI(Entity Integrity)、RI(Referential Integrity)、DI(Derivation Integrity)
が、整合性管理のため重要と考えます。EIは必要な属性が定義されていること、逆に
不要な属性が定義されてないことを要求するものです。顧客に与信限度額が未定義、
工事に終盤になっても実行予算金額が未定義は困るといった制約です。RIは参照
KEYに対応するKEY値が定義されていること。受注エンティティの顧客#は正しく
定義されていなければなりません。DIは加工データが加工元データと正しく対応
定義されているべきと要求するものです。5個出荷したならば、残高は5個減るべき
ですし、売掛残はその分増えなければなりません。この値が月次売上金額といつ整合
すべきか、またサブタイプ対応に処理が異なる場合など、そのルールをはっきり把握し
メタデータとして定義しなければなりません。こうして実装独立段階に整合性を取りきり、
この負担をプログラム設計者から開放するのが、DOAの本来の進め方と考えます。

⑥はデータの整理だけでなく、これに基づいて機能の共通化まで見届けるべきと考
えるものです。EAの提案には、整理の結果ミドルウエアがどう用意されるかが読
み取れず、この点から未完成と感じます。逆に「ESBを使えばSOA」にも、
「ESB機能の共通化だけでは」と感じざるを得ません。

⑦は機能分割に際しての留意点です。大きな機能はそのままでは扱いに限度があり
ますので、より小さなサブ機能に分割するわけですが、このときサブ機能を識別し、
機能を説明するだけで終わらせてしまうケースを良く見ます。サブ機能間のインター
フェースが明示されていないと、そこにスパゲッティ構造が残ります。インター
フェースを集め、整理・標準化を行うことによって、ハブ&スポーク構造が作られ、
きれいなアーキテクチャができて行きます。国を決め、首都や代表者を決めても、
国境が決まってないと、トラブルが続出するのと同様です。インターフェース明示
の重要性を指摘したいと思います。

さきの3階層通信場アーキテクチャは、通信場を個別アプリ内、アプリ横断、企業
横断に分け機能の共通化をすすめ、スリムで高信頼性のミドルウエアを用意したい
というものでした。次号以降にこれを述べたいと思います。


【156号】 3階層通信場アーキテクチャの考察

2009/10/01

■3階層通信場
先の155号でDOA的SOAの前提として、3階層通信場を提案しました。スパ
ゲッティ化を避けるとき、プロセス間の直接的通信はなくなり、n個のプロセスが
やり取りするメッセージを集め、データの標準化を行い、その結果できる通信場を
共用するDOAの通信形式になります。これを
 L1:個別アプリ内
 L2:個別アプリ間(全社、注1)
 L3:企業間
のように分類したわけです。L1では生産、販売、経理など個性的なデータを扱う。
L2では品物やお金の残高など、経営リソースの有効活用の鍵を握るデータを扱う。
L3には企業の利害に係るネゴマターが含まれる。このため4階層、5階層などい
ろいろな考え方があるとしても、3階層がやはり最も本質的なものである、と考え
たのです。

注1:大手エンジニアリング会社の場合は、ここは全社でなく1プロジェクト全体
となる。

またメッセージの中で用語の役割を果たすリソースデータ(取引先や製商品など)
は、「システム広辞苑」とも言うべき通信の要であり、原則としてL2ないしL3
とすべきものと考えました。ここでL3のリソースとは、業界標準の商品や組織な
どの情報であり、将来的にはサプライヤーが公開し、ユーザは仮想的にこれにアク
セスできるため、自社DBに取り込む必要がなくなると予想されるものです。一方、
いわゆるアプリケーションパッケージにはL1のリソースデータが含まれますが、
これは他との通信において変換を必要とする、今MDMとして課題になっている
データです。

■通信場の5分類
したがって、3階層の通信場(DH:Data Hub)をリソース系とイベント系に分け、
これらをR、Eとして示すと(R1DHは除かれるので)、
 R2DH、R3DH、E1DH、E2DH、E3DH
ように5つに分類でき、E1DHについてはさらに生産、販売、経理などと、個別
アプリごとに分類されると考えられます。全社標準化を進めることによって、企業
内は将来R2DHとE2DHに統一できるとしても、当面はレガシーの継続活用、
パッケージの導入などにより、各種標準間の変換を行いながら運用せざるを得ない
ものと考えます。

通信場通信においては、プロセスのオペレーションは参照も更新も、DHに対して
行われます。参照の場合はメッセージ種別を指定する定型、また個別に属性を指定
する不定型、いずれの場合も、正しく該当する標準を選択することのほか、特別の
配慮は不要なので、以下更新の場合について考察するものとします。

■事例研究
更新の事例として、購買システムにおける「発注」を考えましょう。そのメッセー
ジは次のような形をしているものとします(スペース節約のため省略記号を使いま
す)。

発注:[発#]-(仕入先#、品#、 @、数量、¥、  納期、  届先#、・・・)
     123    S15   P01  5  10  50  9日15時  F4

このデータが購買DB(E1DH)にストアされるわけですが、同時に整合性保障
のため、次のようなデータを生成し、先日付在庫および仕入先に対する買掛残を更
新すべきとします。

先日付在庫:[品#. 倉庫#. 締時]-(初残、末残、安全残、残チェック)
          P01. F4. 9日18時   30  40   20  0(正常)

買掛残  :[仕入先#. 締時]-(初残、末残、残チェック)
         S15. 9日24時  100  150  0(正常)

そしてこれらは、他の生産や経理システムからも更新されるデータですから、E2
DHにストアされるべきと考えます。これらはE2DHの言わば全社標準のデータ
ですから、購買システムが独自の標準を採用している場合は、形式についてはメタ
データの、また値についてはリソースの、変換テーブルに基づく変換を行ってから
更新をかけることになります。

また、発注データは仕入先に届けるべく、E3DHにストアされます。E3DHは
種々のイベントデータの行き交う企業間通信場ですから、次のようにメッセージの
KEYに宛先、イベント種別(E種)、発番箇所を補う必要があります。

発注MSG:[宛先.E種.発番箇所.発#]-(仕入先#、品#、・・・)
        S15 発注 TB02  123    S15   P01

この発注MSGは、宛先が適時E3DHをスキャンして入手するか、ワークフロー
機能に委託して入手し処理することになります。いずれにしても、E3DHの標準
によるデータですから、形式や値に関して、自らの標準に変換する必要があります。
この発注MSGは仕入先によって処理され、回答の形でE3DHに戻ってきます。
これを入手した購買アプリは先日付在庫や買掛残を予定から確定に変えてE2DH
にストアすることになります(以下省略)。

■統一的なミドルウエアで裁く
このように3階層通信場アーキテクチャでは、アプリ間のメッセージは所定の通信
場に属するものとすることによって、整合性管理、標準変換、配信などの処理を統
一的なミドルウエアで裁き、簡素化と高信頼性を実現するものと考えます。これに
よって従来、「製品在庫を販売システムと生産システムの両方で抱え、厄介なオペ
レーションを行っていた」などの問題は未然に防げるのではないでしょうか。また、
大手企業の力によるEDI通信場が、このようなE3DHに容易にシフトするとは
考えられませんが、通信場先行のDOA的アーキテクチャの特徴を理解しておくこ
との重要性が、今後増大してくると考えます。

3階層通信場アーキテクチャのイメージ理解のために、製造業の基幹システムが経
営・経理・購買・生産・販売からなるものとし、これらの間、およびサプライ
チェーン先A、B、C、・・・との間にどのような通信場が形成されるかを描いて
みます。

      経営  経理
       |  |
       E2DH(社内アプリ間通信場)
      /  | \
     購買 生産 販売
       \   /
        E3DH(企業間通信場)
         /||\
       A B C ・・・

理解しやすくするために、単純化していますが、3階層通信場アーキテクチャの本
質は表現できているように思われます。通信場アーキテクチャがいかにあるべきか
は、まだ今後の検討を要する課題ですが、これに言及しないで済ませる問題ではな
いと考えます。EAやSOAの成果を実りあるものにするための前提として提案し
たいと考えました。

追伸:
発注を事例としたため、E2DHでは在庫引当型通信、E3DHでは要求回答型通
信が登場しました。しかし、E2DHでも販売が特殊仕様の製品を生産に依頼する
場合は、要求回答型通信が、またE3DHでも座席予約のような場合は在庫引当型
通信が登場すると考えられます。このほかE2DHには、月次販売・生産・購買計
画数量のような多部門にまたがる経営計画を追跡するデータが所属します。個別ア
プリのインターフェースとなるE2DHのデータおよびこの加工元データは、多く
の企業においてまだ可視化されていないように見えますが、経営の役割と部門の役
割の関係を明快に示すための、今後の課題かと思われます。


【155号】 DB通信場再考

2009/09/01

■DB通信場
いま広域統合のためのSOA(Service Oriented Architecture)が話題になって
います。しかしサービスと言う言葉の持つ意味の広さや、各人の立場・背景からく
る、この言葉についての意味づけの違いから噛み合った議論が難しくなっています。
筆者もその一人に過ぎませんが、DOAの延長線上に位置づけたSOAを考えて
います。そのアーキテクチャを構成する主役は3階層の通信場-P2P(Program
to Program)、A2A(Application to Application)、B2B(Business to
Business)-です。「通信場」といっても、この生硬な用語の意味は、十分共有
できない心配があります。そこでまず、P2PにおけるDB通信場を手がかりにその
意味を再考したいと考えました。

DBおよびこれを制御するDBMSは1970年代に登場しました。それまではア
プリケーションプログラムはQSAMやBSAMと呼ばれるファイルに書き出し、
これを読むことによって通信を行っていました。いわゆるバケツリレーです。一般
に下流のプログラムは、上流のプログラムの決めたファイル形式にしたがってこれ
を読むことになりましたから、上流のプログラムがファイル形式を変更したときは、
下流プログラムはこれに合せた変更をしなければなりません。下流プログラムの
都合を取り入れたとしても、インターフェースについての約束事は2者間のローカ
ルマターに過ぎません。プログラムがn個あるとすると、そのインターフェースの
数は理論的には、n(n-1)/2になりますので、Peer to Peerのいわゆるスパ
ゲッティ構造となり、メンテが難しくなります。DBMSが登場しても当初は、
ヘッダー・ディテール構造や部品展開が表現でき、また論理インターフェースを活
用し、項目追加の容易な便利なアクセスメソッドとして使われるだけで、スパゲッ
ティ構造はそのまま残されました。

しかし実装独立のデータモデル論が登場し、RDBMSが実用化されて、「DBは
実務の世界の写像である」とする実装独立のDB通信場の考え方が普及してい
きました。リレーショナルモデルの提唱者E. F. Coddは「プログラムは、他のプログラ
ムとは独立に、DBにアクセスすべきだ」というデータ独立性の主張をしました。
こうしてDBを、一種の伝言板、ハブ通信場とする、Hub & Spokeのアーキテクチャ
ができていきました。実際筆者は、「DBとはストレージ機能より通信場機能が本質」
ではないかと考えます。

DBがハブ通信場として機能する条件は、構成するデータ―属性の形式と値-
の標準化です。このためには原則として関わる全メッセージを素材に、データモデ
リングを行い、標準化・整合化を行います。その結果はリポジトリ(メタデータDB)
およびリソースDBに記述されます。またプログラムは、実務の世界の変化-受注
や生産完成など-を可及的速やかに把握しこれを反映する更新系と、実務の
世界を参照し適切なアクション-発注や生産指図など-につなげるための、意思
決定元データを参照する参照系との2種類に分かれます。こうしてDB通信場が
介在するために、留守電やインターネットメールのように、プログラムPiとプログラムPj
が直接交信することがなくなりますが、同時にPiの記述した内容は、Pkも参照
できることになります。

このようにデータが通信場に「鎮座」し、これにアクセスすることによって通信が
実現すると考えるのがDOAの発想であり、逆にプロセスは「鎮座」し、データが
流れることによって通信が実現すると考えるのがPOAの発想と言えます。データ
は標準化によって1個のハブにまとめられますが、プロセスはn個のままですから、
POAでは脱スパゲッティができません。「通信においてはデータが流れる」と考
えるのは、POAや実装従属の発想から脱しきれないとろから来るもののように
思われます。

■孤島システム/SILOの出現
DBによるハブ通信場にはしかし、守備範囲が存在します。生産関係のメッセージ
から作れば生産DBが、また販売関係のメッセージから作れば販売DBが作られま
す。「これでは困る」と両者のメッセージを集めれば生産&販売DBができますが、
生産技術者と営業マンは異なった文化を持っており、お互いの用語を理解し標準
化を進めるデータ管理者は容易には見当たらず、時間も掛かります。開発の動機や
スポンサーが異なるという理由もあるわけですが、分野統合のDB構築は必ずしも
得策でないことから、これまで一部の例外を除き行われてきませんでした。その例
外はERPです。パッケージにして沢山売ればコストと時間が回収できるという計算
から行われたわけです。

こうして多くの企業で、個別アプリケーションDBが作られてきたわけですが、アプ
リケーション間のコミュニケーション不全の、いわゆる孤島システム/SILOと呼
ばれる、次の二つの大きな問題、

①アプリごとに社内外組織や製商品・部品などのリソースデータの定義が異なる
②アプリ間でやり取りするデータの所在はどこにすべきか基準がないが残されました。

生産指図、完成、受注、出荷などのイベントを文章表現したとき、担当者、顧客、
商品などのリソースデータは用語に相当します。①はこの用語がアプリケーションごと
に異なると言うことです。また、たとえ用語が異ならなくても2重管理になりコストの
点でマイナスですし、他のアプリケーションのリソースを参照することになれば、RPC
(Remote Procedure Call)やWebサービスを多用したスパゲッティ構造を招くことに
なります。いま話題になっているMDM(Master Data Management)の問題となる
わけですが、根本は本来全社的に管理すべきものを個別アプリケーションに任せた
結果と言えます。

②は、たとえば製品残高のようなデータの問題です。これは生産システムの生産
完成でプラスされ、販売・物流システムの出荷でマイナスされるアプリ横断のデータ
ですが、どこに所在すべきかはっきりした基準を持たないため、2箇所にストアしたりし
ている企業も少なくないように見受けられます。これも全社レベルで管理すべきもの
を個別アプリケーションに任せた結果であり、スパゲッティ構造を招き、メンテを難しく
します。また、証券業務における約定残高なども、フロントとバックで共用されますが、
よく似た問題を抱えています。

■3階層ハブアーキテクチャ
そこで、EDIなどの社外への拡張をも配慮して、データに次のようなレベル付け
L1:個別アプリケーション内でだけ使われるP2Pデータ
L2:アプリケーション横断/全社レベルで使われるA2Aデータ
L3:企業横断で使われるB2Bデータ
をします。すると上述は、筆者の提案する3階層ハブアーキテクチャの原則
・独自の文化を持つ個別アプリは、迅速対応・コストなどの観点からL1のDBを
中心に作る(注1)。
・アプリ横断のデータはL2のハブ所属として管理する。
・企業横断のデータはL3のハブ所属として管理する。
のように、まとめられると考えます。

(注1)L1とL2、L3の記述が違いますが、L1の場合はハブをさらにDBと
限定しても問題がないと考えたためで、すべてハブ通信場であることに変わりはあ
りません。

この場合リソースデータは、L1は特にローカルなものに限られるので、ほとんどL2
として管理すべきと考えます。実際われわれは1980年以降のプロジェクトでは「リ
ソースは全社にひとつ」を原則としてコンサルを行ってきましたが、これを採用いただ
いた会社では、以後スムーズなシステム開発が展開でき大成功だったと考えます。
また実例はこれからかと思われますが、使用頻度の低い部品仕様などは、L3-
実データは部品メーカにストアされているが仮想化してL3で公開する-として参照
できるのが理想的だと考えます。この方式のポイントは、物理記憶ではなく、部品
仕様の形式と値の標準をL3で規定することです。

イベントデータの多くはL1となりますが、アプリ横断の在庫データ-先の製品在庫や
買掛・売掛残高など-はL2、また企業横断の在庫データ-ホテルや飛行機の座席
など-はL3として位置づけられると思います。在庫データはアプリAがプラスし、
アプリBがマイナスするわけですが、これは需要が予測できる場合のアプリ間に見られる
「在庫引当型コミュニケーション」の形式だと考えられます。需要が予測できない場合は、
発注に対して、回答、納入、検収が続くような、「要求・回答型コミュニケーション」
が行われますが、これもL2、L3レベルに見ることができます。

またイベント系の一種に、L2データとして、多部門に関わる全社計画・実績データが
あります。たとえば月次販売計画数量・金額ですと、月次製品生産計画、月次資材
購入計画との整合関係が存在するため、これは購買、生産、販売、経理に関わる部門
横断のデータとして扱われ、L2の管轄となります。

■ハイリターンの期待されるL2・L3通信場の可視化
L1を構成するデータの属性は、アプリの個性を反映して、多様かつ変化も激しいので
すが、L2やL3を構成するデータの属性は、たとえば生産アプリと販売アプリ間でやり
取りされるメッセージを考えても分かると思いますが、数も限られかつ安定しています。
現在は多くの企業や企業間において、個別アプリの観点から設計されたL1のデータ
モデルはあるとしても、L2、L3におけるデータモデリングは未着手と思われます。
このためアプリ間インターフェースはちぐはぐであり、ある変更が当該システム内で収まる
か、他に波及するかの判定にすら、多大のコストと時間を投入せざるを得なかったりします。

L1の各アプリの範囲を如何に設定すべきかは、決め事であり難題ですが、これを
決めればL2、L3のデータモデリングは、アプリ間のメッセージを収集すれば可能
であり、技術的に難しい問題はありません。L2、L3のプロセスモデル図およびデータ
モデル図は、経営とITが会話するための必須のドキュメントとなるのでないかと筆者は
予測します。これらは、日本の交通問題を、高速道路と新幹線が解決したのと同様
の役割を果たすことができるのではないかと期待されます。

以上ハブ通信場を3階層に分けるフェデレーション・アーキテクチャにより、孤島/S
ILO問題を解決する提案をいたしました。L2、L3の通信場を構成するメッセージ
は、サービスと呼べるものかと思われますので、以上はDOAの拡張「DOA的SOA」
と呼ぶことができるかと思われます。


【154号】 iDBMSの勧め

2009/08/03

■DI対策
先々号で「現行DBMSの欠陥」を述べましたが、今回はその
「③DI(Derivation Integrity:加工データ整合性)の抜け」に対する対策を
考察します。

分かりやすさのため、部品入庫により部品残高および買掛残高が増える事例を考えます。
すなわち、いま

[入庫#]-(品、倉、入庫数、入庫金額、取引先、区分)
  5      P W  5    ¥50    S   買

のレコードが発生したとします。これによって次のように、部品残高および掛残高は
s1からs2に変化します。

[品.倉]-(部品残高)   [取引先.区分]―(掛残高)
s1: P W    100         S   買     ¥200
s2: P W    105        S   買     ¥250

この場合、従来法ではDBMSに向けて、アプリケーションプログラム(AP)から、
次のように3つの更新トランザクション(TRX)が発行されるものと思われます。

 ┌-(入庫TRX)――┐ 
AP―(品残更新TRX)+→DBMS-DB
 └―(掛残更新TRX)┘

すなわち、実世界では1件のイベントが発生し、ユーザは1件の入力をしただけですが、
APは整合性を保障するために、3件のTRXを発生させ、これをDBMSに依頼して
いるわけです。これではDBMSは、ただ指定された場所にデータを入れているだけで、
「DBを管理するシステム」とは言えないのではないでしょうか。

■iDBMSの登場
そこでiDBMS(intelligent DBMS)が登場するわけです。すなわち、次のようにDI
の整合性管理をiDBMSが引受けます。
 
                   ┌-(入庫TRX)――┐ 
AP―(入庫TRX)→iDBMS―+―(品残更新TRX)+→DBMS-DB
                   └―(掛残更新TRX)┘

こうして、iDBMS+DBMSが本来のDBMSの役割を果たすと考えるわけです。
このために、iDBMSは次のようなリポジトリ情報を活用し、

[加工データ.加工元データ]-(参照KEY)
  部品残高 入庫数      品.倉
  掛残高  入庫金額     取引先.区分

「入庫数、入庫金額が加工元データであり、対応する加工データが[品.倉]エンティ
ティの部品残高、および[取引先.区分]の入庫金額であること」を突き止め、加工
データ対応に記述された加工ロジック(ここでは省略)を参照して、部品残高=100+5、
および入庫金額=200+50を計算し、DBMSに更新依頼することになります(注1)。

(注1)部品残高および掛残高は、生産システムや経理システムからもアクセスされる
ため、アプリ横断のDB中にストアされるべきとも考えられますが、これはリポジトリ
情報から判断できますので、iDBMSによる対応は可能と考えます。

入力データの値や形式の制約チェックも、iDBMSに任せることができますから、AP
の仕事は、実世界に発生した情報を素直にコンピュータの世界で扱えるデータに変換して、
iDBMSに渡すだけになります。整合性にかかわる配慮は不要になりますので、APは
ユーザ・サービスに徹することができます。

従来は、AP開発担当者とDB設計担当者が分業していても、AP担当者もDIの絡む
データ間の複雑な関係-特にサブタイプが絡むとき複雑で抜けも発生しやすい-を認識しな
ければならず、両者の認識が違っていたり、抜けが発生して、トラブルの発生する危険性が
高かったのですが、きれいに分業ができ(注2)、ドキュメントが単純化されます。データ
の設計は、DIを含めて、データモデラーが実装独立に、先行して完結することができます
ので、実装工程からのやり直し依頼はなくなり、開発・保守ともに大幅に合理化されると期
待されます。

(注2)最近、DBの整合性を保障すべく、DBMSは各種ストアードプロセジャー機能を
充実させてきていますが、「データモデラーが実装独立段階に設計すべし」という設計思想
ではなく、プログラマを支援するもののように思われます。

DIにおいては、①加工元データを加工データの所属するエンティティに集め、②これを演
算するわけですが、②の非定型処理ステートメント以外にはプログラム言語による記述は
(iDBMSが肩代わりするため)不要なので、AP側以外にはプログラミングは不要にな
ると期待されます。すなわち、オブジェクト指向言語なしで、その狙いをカバーするものに
なるのではないかと思われるのですがいかがでしょう。またAP側も、一覧表型、ヘッダー
ディテール型、マトリックス型、個票型、など画面・帳票のパターンを用意することによって、
大幅にプログラミング工数を削減することができると考えます。

■課題
この場合心配は、次のようなものかと思われます。
①すべてのDIを受け止めるリポジトリ構造が設計できるか 
②これを活用する、十分な効率を持つ、iDBMSが設計できるか
③データモデラーが、リポジトリに登録すべき高品質のデータを効率よく作れるか

もちろん、世の中のすべての加工データについて検証したわけではありませんが、筆者は①は、
ほぼ完成に近いものが設計できている、ただし、②における機械効率のための工夫がリポジトリ
構造にも必要と考えますので、この課題が若干残されているかと考えます。DIはビジネスルール
/業務知識の中核であり、これは「プログラムで書くもの」との先入観を持っておられる方もある
ようですが、私はメタデータとしてリポジトリに記述すべきもの、これによって実装独立段階の
仕事にできる、と考えています。

②は、これから実証すべきテーマですが、1個のプログラムが対象であり、多少の試行錯誤はある
でしょうが、必ず解決できる課題と考えます(注3)。

③は、これまでSEをやっていた、多くの新参データモデラーにとって未経験の部分を含んでい
ますので、設計手順や教育など、まだ課題が残されているかと思われます。しかし、プログラミ
ングのような個人差が発生しませんので、さほど難題ではないと思われます。

また、当面iDBMSが用意できなくても、APのロジックからiDBMS部分を分割し、この
設計をデータモデラーの担当とすることによって、大幅な合理化が達成できると考えます。

(注3)方式としては、事前にプログラムを自動生成しこれをiDBMSから呼び出すプログラム
ジェネレータ方式(コンパイル方式とも呼ぶ)と、実行時リポジトリを解析して動くインタープリ
ーター方式があるかと思われます。技術的には前者が易しいと思われます。

なお、科学技術計算などの加工データ-たとえば流体の流量対応のパイプ径、地震に耐える鉄骨寸法、
流体の温度・圧力での蒸気圧など-は、自動生成でなく従来どおりのプログラミングを行い、
iDBMSから加工ロジックとして呼び出すのが適切かと思われます。


【153号】 IPFチャートの設計条件

2009/07/01

■IPFチャートの成り立ち
IPF(Information Process Flow)チャートは、弊社が標準としている業務フ
ローチャートです。古くはDFD、UMLのアクティビティ図、最近話題のBP
MNとほぼ同じ粒度の業務プロセスを記述する図といえます。
『【153号】 IPFチャートの設計条件』の続きを読む・・・


【152号】 現行DBMSの欠陥

2009/06/01

■現行DBMSの欠陥
現行DBMSとは、ほとんどRDBMSかと思われます。RDBMSは構造型D
BMSのポインター操作からプログラマーを開放し、オプティマイザーを始め多
くの改良を施し、E. F. Coddの提案する12のルールを消化して、多くの情報シ
ステムの不可欠の基盤となっています。しかし一方、いま多くの情報システム部
門の抱えている問題のうち、現行RDBMSに起因すると考えられるものも少な
くないので、これについて私見を述べたいと思います。

『【152号】 現行DBMSの欠陥』の続きを読む・・・


【151号】 ユーザ企業の役割、SIerの役割

2009/05/01

■情報システムアーキテクチャの進化
情報システムアーキテクチャは、相互に通信すべきメッセージデータ(=トラン
ザクションデータ、イベントデータ)の通信の方式によって、
 G1:ロウレベルPOA(個別プログラムが適宜データを通信する)
 G2:ロウレベルDOA(プログラムはアプリDBを介してデータを通信する)
 G3:ハイレベルPOA(アプリ同士適宜データを通信する)
 G4:ハイレベルDOA(アプリはアプリ間通信場DBを介してデータを通信
する)
のように、進化するかに見えます。
『【151号】 ユーザ企業の役割、SIerの役割』の続きを読む・・・


【150号】 POAの世界観とDOAの世界観

2009/04/01

■POAの世界観
POAの世界観とは、与えられたインプット(I)から要求されるアウトプッ
ト(O)を、いかに速く安くうまく作るかを課題とする世界観だと考えます。
『【150号】 POAの世界観とDOAの世界観』の続きを読む・・・


【149号】 情報システムの進化

2009/03/02

■POAから第1世代DOAへ
私が会社に入ったときは、コンピュータはありませんでした。石油のある溜分
が、ある温度・圧力でどのように気体・液体に分かれるかを算盤や計算尺でト
ライアル計算する時代でした。処理結果は紙に書かれ、人がこれを手渡す業務
プロセスでした。1965年ころコンピュータが入ったわけですが、コンピュー
タの役割は機械処理であって、処理結果はそれまでどおり、紙に出力され人が
手渡していました。
『【149号】 情報システムの進化』の続きを読む・・・


【148号】 リポジトリ構造の設計条件

2009/02/01

■メタデータ
「メタデータ」のメタは超越といった意味のようですが、日本語に言い換えて
も抽象的で、いまひとつ分かりにくい。
『【148号】 リポジトリ構造の設計条件』の続きを読む・・・


【147号】 利用は分散、管理は集中

2009/01/01

■コンピュータはなくても情報システム
収穫した野菜を朝市に並べて、現金決済で売って帰ってくるような場合はさて
おき、仕入れた品物を売って、月末に回収するとなると、コンピュータはなくて
も情報システムが必要になります。
『【147号】 利用は分散、管理は集中』の続きを読む・・・


【146号】 エンティティタイプをどう決めるか

2008/12/01

■エンティティタイプは決めるもの
決めるものを決めないと前に進みません。決まるものを決めると矛盾が発生し
ます。決めるものは独立変数、決まるものは従属変数だからです。
『【146号】 エンティティタイプをどう決めるか』の続きを読む・・・


【145号】 データモデルの要件

2008/11/01

■情報の発生と共有
「子供が生まれた」、「商品が売れた」、「お金を下ろした」など、情報はイ
ベントで発生します。人間はこれをデータ化し、共有−昔の自分と今の自分と
の共有を含めて−します。初めは発生順に記録するだけかもしれませんが、情
報の形式対応に分類して記録するようになります。データには構造があり、こ
れに沿って記録するのが得策だと悟るからです。
『【145号】 データモデルの要件』の続きを読む・・・


【144号】 サービスとは何か

2008/10/01

■SOAの目的
SOAプロジェクトにおいて最も重要な課題は、サービスの列挙だと言われま
す。このためにはサービスとは何かが、はっきりしなければなりませんが、人
によって説明が違い、議論がかみ合いにくくなっています。これは「SOA技
術は未完成」の証左と言えるでしょう。
『【144号】 サービスとは何か』の続きを読む・・・


【143号】 分かりやすいSOA設計の提案

2008/09/02

■分かりにくいSOA
昨年来、SOAの話題が花盛りですが、その説明はいまひとつわかりにくく、
議論がかみ合っていないように見えます。
『【143号】 分かりやすいSOA設計の提案』の続きを読む・・・


【142号】 IO設計のガイド

2008/08/01

■IOがビジネスシステムの核
前号で述べた「情報システム=ビジネスシステム」とするユーザ企業の立場に
立つと、「製品=IO、部品=IOデータ」と言うことになります。
『【142号】 IO設計のガイド』の続きを読む・・・


【141号】 WHATとHOWの情報システム

2008/07/02

■部品表
自動車産業では、ユーザニーズにフィットしたどのような新車を出すかが最大
の問題です。しかし安価・安全・高品質のために、その部品としては、できる
だけ確かな標準品を使用します。製品の生産数量を決めたらこれに必要な部品
を手配しなければなりません。そのために部品表が使われます。
『【141号】 WHATとHOWの情報システム』の続きを読む・・・


【140号】参照KEY−その3

2008/06/02

■参照KEYの役割
参照KEYの主要な役割は、イベントの中での5W1Hと言えます。
『【140号】参照KEY−その3』の続きを読む・・・


【139号】参照KEY−その2

2008/05/01

■KEYかつ参照KEYによる1:1の表現
いま営業部は、
[顧客c]−(顧客名、口座#*、顧客ランク*、与信限度額)
のような顧客ファイル(注1)を使っており、
『【139号】参照KEY−その2』の続きを読む・・・


【138号】参照KEY:その1

2008/04/01

■参照KEYひとつで関係表現
THデータモデルで参照KEYないしRKEYと呼んでいるデータ項目は、リ
レーショナルモデルで外部キーと呼ばれるもので、たとえば
『【138号】参照KEY:その1』の続きを読む・・・


【137号】ビジネスアーキテクト

2008/03/03

■アーキテクトのニーズ
EA(Enterprise Architecture)が引き金になったのでしょうか、このところ、
ITアーキテクト、データアーキテクトなど、アーキテクトを標榜する名刺を見
かけることが多くなりました。
『【137号】ビジネスアーキテクト』の続きを読む・・・


【136号】4種類のDB

2008/02/01

■DBの分類
DB、といっても概念DBですが、これをどう分類するか、観点により、
人によりいろいろな考え方がありうると思われますが、私は次の4種類
・リソースDB ・イベント系DB
・DWH系DB ・メタ系DB(リポジトリ系DB)
に大分類したいと考えます。
『【136号】4種類のDB』の続きを読む・・・


【135号】画面・帳票の位置づけ

2007/12/04

■ものづくり屋指向とユーザ指向
画面・帳票を情報システムにどう位置づけるかは、その人がこれまで情報シス
テムにどうかかわって来たかによって、大きく違ってくるようです。
『【135号】画面・帳票の位置づけ』の続きを読む・・・


【134号】人材開発のためのシステム開発

■人材開発は難問
人材開発・育成はどの分野、どの企業にもある永遠の課題ではありますが、情
報化投資でアメリカに、情報志向の人数でインドに大幅に立遅れるなど、日本
の情報産業を支えるべき人たちの質・量の衰退が心配されています。
『【134号】人材開発のためのシステム開発』の続きを読む・・・


【133号】データモデリングの課題−その2

2007/11/01

■DOAの問題―加工データの排除
先の132号において、DOA最大の問題は「個別アプリケーションへの適用
に限られ、孤島システムを乱立させたこと」と述べました。
『【133号】データモデリングの課題−その2』の続きを読む・・・


【132号】データモデリングの課題−その1

2007/10/01

■ビジネス系システムの課題
私は、今日のビジネス系システムの4大課題は
・過不足のない要件定義 ・保守工数削減
・全体最適 ・迅速対応
であると考えています。
『【132号】データモデリングの課題−その1』の続きを読む・・・


【131号】フェデレーション・アーキテクチャ

2007/09/06

■情報システムがビジネスの足を引っ張る
SCMやWeb2.0のロングテールなど、かつてないIT活用によるビジネス展開が
見られる一方、金がかかる、重大トラブル発生、3K職場、対応が遅いなど、情報
社会の進展にともなう問題が山積しています。
『【131号】フェデレーション・アーキテクチャ』の続きを読む・・・


【130号】「可視化の条件」

2007/08/02

■可視化への関心
業務や情報システムのあるべき姿を求めて、「可視化」や「見える化」の指摘
を耳にする機会が多くなりました。J−SOXのような業務の統制、またEAのよ
うな広域の情報流通・共有が強く求められるようになったからかと思われます。
『【130号】「可視化の条件」』の続きを読む・・・


【129号】日本の情報システム

2007/07/03

■日本と欧米の違い
われわれの概念DB設計法は、まずユーザニーズを満たす画面・帳票を設計し、
これを構成する部品=属性を分析・整理するボトムアップ手法です。
『【129号】日本の情報システム』の続きを読む・・・


【128号】「DOAにおけるSOAを考える」

2007/06/01

■分かりにくいSOA
SOA大全(日経BP)によると、SOAの定義は「SOAとはアプリケーシ
ョンフロントエンド、サービス、サービスリポジトリ、サービスバスという主
要な概念により構成されるソフトウエアアーキテクチャである。
『【128号】「DOAにおけるSOAを考える」』の続きを読む・・・


【127号】DOA2.0の胎動

2007/05/01

■5年サイクルで変わるトレンド
今振返ると、弊社データ総研は1985年創立以来一貫してDOAを追求して
来ましたが、世の中のトレンドは、5年サイクルで
『【127号】DOA2.0の胎動』の続きを読む・・・


【126号】DOAの本質は自己相対化の世界観

2007/04/02

■世界観は自己中心からスタート
われわれは、宇宙→銀河系→太陽系→地球→日本→自分と言った位置づけを
知っていますが、コロンブス前の人々は自分の周辺からしか自分を位置づけること
ができませんでした。
『【126号】DOAの本質は自己相対化の世界観』の続きを読む・・・


【125号】情報システムのサイエンス(3)

2007/03/07

■部品展開のエンジニアリング
124号で述べましたように、情報システムの部品展開に関して個人差の出な
い−「決まる」−結果を得るための、7つの基準を提案したわけですが、やはり
決着までには担当者が都度判断して「決める」べき課題が残されます。
『【125号】情報システムのサイエンス(3)』の続きを読む・・・


【124号】情報システムのサイエンス(2)

2007/02/01

■部品の標準化から始める
前回、サイエンス指向の前提として、「実装独立」「データ中心」「フェデレー
ション・アーキテクチャ」述べました。フェデレーション・アーキテクチャで
は上位にデータインフラを位置づけ、ここにリソースデータが含まれますので、
「共用リソース中心」を含みます。
『【124号】情報システムのサイエンス(2)』の続きを読む・・・


【123号】情報システムのサイエンス(1)

2007/01/05

■職人芸の時代
私がはじめてコンピュータを使ったのは、1964年(昭和39年)ころ、東
大に出向し、計算センターでアルゴルのプログラムを紙テープに穿孔して作っ
た時でした。
『【123号】情報システムのサイエンス(1)』の続きを読む・・・


【122号】参照KEYの意味論

2006/12/04

われわれのTHモデルの中では、参照KEYはきわめて重要な役割を占めてい
ます。リレーショナルモデルにおける外部KEYと同じものと理解されておら
れる方も少なくないと思われますが、このため多くは意味論的な問題から、こ
れに起因した誤解も発生するようです。そこで参照KEYについて整理してみ
ます。
『【122号】参照KEYの意味論』の続きを読む・・・


【121号】ユーザ企業とSIerの協業

2006/11/01

情報システムが、経営ニーズに応えていてほとんど問題がないという企業は、
今日例外的でしょう。そこで今月はこの問題の根本的原因を探り、対策を考え
て見ましょう。
『【121号】ユーザ企業とSIerの協業』の続きを読む・・・


【120号】現行画面・帳票を素材に

2006/10/03

今月は119号に続いて、114号の「リレーショナルモデルの問題点」の、
「④DB設計の素材について言及がない」の対策を考えました。「現行画面・
帳票こそがDB設計の素材」の提案です。
『【120号】現行画面・帳票を素材に』の続きを読む・・・


【119号】フェデレーション・アーキテクチャ

2006/09/06

今月は118号に続いて、114号の「リレーショナルモデルの問題点」の、
「③DBのスコープの設定について言及がない」の対策を考えました。フェデレー
ション・アーキテクチャの提案です。
『【119号】フェデレーション・アーキテクチャ』の続きを読む・・・


【118号】i−DBMSはいかが

2006/08/02

さきに114号で「リレーショナルモデルの問題点」として、次の4つ
 ①実装独立の概念モデルでない
 ②加工・加工元データの整合性について言及がない
 ③DBのスコープの設定について言及がない
 ④DB設計の素材について言及がない
を挙げましたが、対策については特に述べませんでした。そこで今回は①、②
の対策として、i-DBMS(インテリジェントDBMS)を提案してみます。
『【118号】i−DBMSはいかが』の続きを読む・・・


【117号】情報システム設計の方向

2006/07/03

■DOAとは何
DOA+コンソーシアムは2年半前、2003年12月に発足しました。この
「+」はこれまでのDOAと違う、これを超えたもの、という思いを込めたも
のでした。しかしここで言う「これまでのDOA」の内容、意味については、
かなり個人差のあるものだったかと思われます。近頃でも「まだDOAなの?」
といった声を聞くことがあります。
『【117号】情報システム設計の方向』の続きを読む・・・


【116号】システム設計2つのアプローチ

2006/06/02

■システム設計アプローチ
システム設計アプローチは、次のA、B、2つの大別できるように思われます。
 A:テンプレート修正アプローチ
 B:要件統合アプローチ
『【116号】システム設計2つのアプローチ』の続きを読む・・・


【第115号】DBアーキテクチャ

2006/05/01

■アーキテクチャへの関心
最近ITアーキテクトという肩書きの名刺を頂くことが多い、と思っていたら
ITアーキテクトという雑誌が登場しました。ITアーキテクチャに関する関
心の高まりを物語っているのでしょう。
『【第115号】DBアーキテクチャ』の続きを読む・・・


【第114号】リレーショナルモデルの問題点

2006/04/04

■アクセスメソッドからDBMSへ
今やRDB全盛、RDBによらないシステムはほとんどない、と言って良いほ
どです。しかし、近頃よくそのベースとなるRDM(Relational Data Model)
に起因すると思われる問題に遭遇します。そこでDBMS誕生のころからかか
わってきたモデル屋として、「私見が強すぎる」との批判を覚悟して、以下ま
とめてみたいと思います。
『【第114号】リレーショナルモデルの問題点』の続きを読む・・・


【第113号】情報システムは有機体

2006/03/02

雪が降って、氷が張って、久しぶりに冬らしい冬、インフルエンザも姉歯も、
ホリエモンで影が薄くなっていますが、皆様お元気ですか。
1986年から続けている冬の弊社大型セミナー、通称「DB研」は2月8日(水)
青学会館で行います。まず椿が2005年の約400件の文献から80件を選択
し、これをベースに動向を整理編集してお話します。SCM・CRM・BIなどを支
えるSOA・BPM・EDWなどが話題の中心です。続いて若杉がDAMA参加報
告により海外のDOA動向を紹介します。午後は「新しいIT部門へのチャレンジ」
として、小栗様(日揮)・桜井様(システムトラスト研究所)・重松様(東レ)の3氏
から経営につなぐITをお話いただきます。ふるってご参加ください。
■情報システムの強度
先月発信した「欠陥システム構築を防止するには」に対して、弊社市堀誠治(元
平和情報センター)から次のようなコメントをもらいました。「震度8に耐える情報
システムとは、面白い考え方ですが、建築やモノの製造と情報システムには本
質的な違いがあると思います。情報システムの強度は、システム自体の強度と
それを開発・維持する人間系の強度が密接に絡み合っています。システム自体
を強化する技術は既にたくさんあり、それなりに適用されているのが現状だと思
います。しかし、もう1つの側面である開発・維持する人間系の強化をどう実現す
るかが最大の課題です。この分野の最強の技術であるモデリング技術やデータ
の意味管理の技術も、技術としては十分枯れています。問題は、システムを開発・
維持する人がそれを実適用し、その中でよりその技術を高めてゆくような風土や
仕組みがこの業界にないことです。・・」

『【第113号】情報システムは有機体』の続きを読む・・・


【第112号】欠陥システム構築を防止するには

2006/02/07

暖冬改め寒冬のお正月はいかがでしたでしょうか。鳥でなくてもインフルエン
ザに気をつけて、元気にこの冬を乗り切りましょう。
■他山の石
姉歯建築士の問題が騒がれています。建設コストを下げるために、ごまかして
鉄骨・鉄筋を抜いて震度5で倒壊する欠陥建築を作ったと言う話です。ポイン
トは
(1) 誰しも巻き込まれる可能性のある、命にかかわる身近な問題である
(2) 信じられないごまかし、モラルの低下
(3) 責任者が直ちに特定できない体制の不備
(4) 虎の子の大金が無駄になる、そして時間がとられる
などにあるかと思われますが、これを欠陥システム問題と対比してみるとどう
なるか、他山の石として考えてみました。

『【第112号】欠陥システム構築を防止するには』の続きを読む・・・


【第111号】守りのシステム・攻めのシステム

2006/01/10

雪の便りが来て、平地でも紅葉が真っ赤に燃えています。インフルエン
ザ大流行などの不気味な予告もあります。うがいを励行し油断なく元気
にお正月を迎えましょう。
■システム
システムとは要素とその相互関係から構成されるものと考えます。これを
システマティックに構成すること、システマティック化こそがシステム化だと
思われます。その意味では、鉄砲を巧みに使った織田信長や、ベルトコン
ベアを使って自動車の大量生産を実現したフォードは、システム化の天才
だったと言えるでしょう。しかし今やシステム化とは「コンピュータを使った
情報処理の機械化」と限定した使い方をする人が多くなっているようです。

『【第111号】守りのシステム・攻めのシステム』の続きを読む・・・


【第110号】方法論の違い

2005/12/02

ロッテが勝ったり、すっきりした秋晴れの少なかった10月が終わりました。
弊社はこの10月3日で、創立20周年を迎えることができました。1990年
以降、情報システム衰退の10年といった傾向の中、皆様のご支援をいた
だき、おかげさまでなんとか生き延びることができました。
10月24日、DOA+コンソーシアム第3分科会では、弊社堀越が、THモ
デルについて、「処理が読める」などの特徴を交えて、紹介いたしました。

『【第110号】方法論の違い』の続きを読む・・・


【第109号】可視化

2005/11/01

お彼岸過ぎてようやく涼しくなってまいりました。
全般に景気は良いとのことですが、皆様のところはいかがですか。
9月27日、DOA+第3分科会が50名ほどの参加者を集めて行われました。
趣旨は、データモデルを、発案者以外の人が紹介するということで、PFU
の稲見さんがTM(旧T字形)について、分かりやすく紹介されました。有志
がDOA手法を、従来法で構築された環境のなかに、草の根的に持ち込ん
で変革を行う難しさが印象的でした。

『【第109号】可視化』の続きを読む・・・


【第108号】属性の意味

2005/10/07

百日紅の紅が夏の終わりを告げ、朝夕すこししのぎやすくなりました。私は
鳥海山に行って、無理をして腰を痛めて帰ってきましたが、皆様この夏は
いかがでしたでしょうか。
このところ、学生やプログラム開発しか経験のない、データに関しては素人
の方にデータモデリングの説明をする機会が多く、これを自分の課題として
おります。そのとき、「システムとはプログラムの寄せ集めではない、むしろ
属性と属性間の関係の集まりである」という気持ちを伝えるために、次の
ような式を書いています。うまく通じますかね。
 SY≠ΣPG
 SY=ΣD*D (Dは属性/データ項目、*は関係のつもり)
なお、法政大学・イノベーションマネジメント科の公開講座(無料・18時30分
―20時)[データ中心アプローチによる情報システム分析・設計]後期は、
10月4日から1月17日まで12回行うことになりました。お申し込みは同科
の溝口教授のホームページhttps://www.hosei.org/kouza/S059001.php
をご参照ください。
(追記:既に申し込みは締め切っております。ありがとうございました。)

『【第108号】属性の意味』の続きを読む・・・


DRI通信購読お申し込み

2005/09/29

DRI通信とは、弊社フェロー 椿正明が、DOAをベースに情報システムとはどうあるべきかを、独自の視点から述べているもので、1996年10月以来、毎月1回のペースでメール配信しています。
既に4,000名以上の方々にご購読いただいています。
定期購読をご希望の場合は、「DRI通信購読お申し込みフォーム」からお申し込下さい。


【第107号】データモデリングと標準化

2005/09/01

台風が通り過ぎて、本格的な夏ですね。皆様お元気ですか。
7月14日のDOA+第3分科会には150人の参加をいただきました。当初
の目的「初心者にRDBについての正しい理解を持っていただく」も、アンケ
ートにおいて多数の「DOA+の手法を試してみたい」との回答をいただく
など、一応達成できた模様でした。7月25日の第1分科会では、DOA高度
化として、システム間で、やり取りされるメッセージの意味の流通を保証す
るために、メタモデルを議論していますが、もう少しこれまでの成果を調べ
ましょうということになりました。

『【第107号】データモデリングと標準化』の続きを読む・・・


【第106号】データモデルのスコープ

2005/08/01

■システムの大きさ
多くの企業で、予算を用意し、システム開発プロジェクトが企画されます。
そのときのシステムの規模はどのようにして決められるのでしょうか。30年
の昔、BSP(Business System Planning)という手法がIBMから紹介されま
した。顧客企業のDBをどう設定すべきかをガイドする、IBMのIMS販売戦
略から生まれたものと思われますが、RDBの時代になって聞かなくなりま
した。10年前、ERPの時代になって、n個のアプリケーションがシステム化
の対象となりました。しかし、かならずしも全社がカバーされるわけでもなく、
他システムとの連携のありかたや、Monolithicで柔軟性に欠けるサブシステ
ム独立性の課題にどう対処するかなど、課題は多々残されています。最近
EA(Enterprise Architecture)が話題になっていますが、システムの大きさ
について「こうあるべき」の基準は見当たりません。
『【第106号】データモデルのスコープ』の続きを読む・・・


【第105号】孤島システム対策

2005/07/08

DRI通信105号「孤島システム対策」        2005.6.1
大型のゴールデンウイークも終わり、本年度も軌道に乗ってきた頃かと思
われます。全般に「景気は良い」とのことですが、皆様のところはいかがで
しょうか。5月30日のDOA+コンソーシアム第1分科会は、データモデル
の標準化に関して3件すなわち、堀内先生から「メタデータとメタモデルの
動向−IRDSからMMFIまで」、大林さん(管理工学研究所)から「MOFに
関する2件」、岡部さん(東京電力)から「Metamodel for Ontology Registration」
のプレゼンがありました。内容に比し時間が足りなかったので、質疑は次回
6月27日(月)に行うことになりました。
■ 孤島システムとは
英語ではSilo Systemといわれますが、他システムとのデータの流通がう
まく行かないため、システムが孤立してしまう孤島システム問題は、1990
年代半ば頃から盛んに論ぜられるようになりました。ユーザの要求を汲み
取って、QCD(Quality, Cost, Delivery)の満たされたシステムが出来上が
っても、その後で他システムとのデータのやり取りを行うために、変換など
を含むインターフェースを用意する必要があるというのでは困る。このような
システムがひとつ二つなら対応できるとしても、これが10,20となってくると、
保守コスト、信頼性など、行き詰まり状態となってきます。

『【第105号】孤島システム対策』の続きを読む・・・


【第104号】SI業の方法論再建のシナリオ(後編)

2005/06/16

DRI通信104号「SI業の方法論再建のシナリオ(続き)」 2005.5.9
発行が遅れました。5月2日と6日が、DRI20周年の特別休暇となったため
です。「20年経ってまだこんな規模?」という声と、「よくも20年続いた」という
声とが聞こえます。「商品がソリューションになってない、ROIが悪い」との指
摘があります。でも20年前にわれわれが支援させていただいて、20年間で、
私の勝手な試算ですが、コンサルフィー5千万円投入し、100億円は回収
した会社があります。このROIはどう計算するのでしょうか。このような商品、
あと2,3年で引退するCIOはどう評価し意思決定するのでしょうか。
■再建の条件
先回述べたように、理想とのギャップは通常非常に大きいのですが、基本的
条件は満たさなければなりません。方法論は何を(ドキュメント)、いつ(手順)、
誰が(体制)、を規定するわけですが、やはり個人差の出ない高品質の部品
を切り出すドキュメントが鍵となります。ドキュメントは、自然言語の文章やプロ
グラムのように順次トレースしなければ理解できない、いわば「順次記述ドキュ
メント」と、建築図面やデータ構造図のように一見して理解できる、いわば「状
態記述ドキュメント」とになりますが、レビュー効率の点で「状態記述ドキュメン
ト」が有利です。さらにレイアウト規則を導入し人間の優れたパターン認識能\n力を活用できるドキュメントは、エキスパートの経験が短時間で活用でき、高
品質を実現する上で極めて有効です。羽生名人が一目で形勢判断をする
ようなもので、モデルによる「可視化」のねらいは、まさにここにあると考えてよい
でしょう。

『【第104号】SI業の方法論再建のシナリオ(後編)』の続きを読む・・・


【第103号】SI業の方法論再建のシナリオ(前編)

2005/05/11

DRI通信103号「SI業の方法論再建のシナリオ(前編)」 2005.4.1
3月後半の冷え込みで、桜は遅れているようですが、木蓮や雪柳があざ
やかに咲き、鶯が「どうだ、うまいだろう」というように、鳴き始めています。
2005年度のスタートです。花粉症のマスクが目立ちますが、あと少しの
辛抱です。がんばりましょう。
DOA+第1分科会(第3回)は3月23日、定義域をテーマに行いました。
私が定義域と属性の違いとその関係、とくに属性定義の品質を効率的に
上げるための定義域のあり方について述べた後、弊社堀越が過去のIRM
における実体験、また住友電工の中村氏が楽々フレームワークの適用に
際して採用しておられる定義域活用事例について話されました。また堀内
教授(東京国際大学)からは定義域やコードの標準化についての紹介と、
DOA+として定義域の標準を作成すべきとの提案がありました。
■ 解決策を考える前に
90年代初め、バブルがはじけた頃からでしょうか、「情報システムはコア
コンピタンスでない」との判断のもとに、ユーザ企業の情報部門のスリム化
が進みました。その結果、開発・保守要員の多くがSIerに移っていったよう
です。そしてそのSIerが先号に述べたような質的な問題を抱え、またユー
ザ企業も要件を正しく切り出せなくなって、トラブル発生を招いているようで
す。SIerだけで解決できる性質の問題ではないようです。そこで本号では、
ユーザ企業とSIer全体の問題として捉え、まず本来あるべき理想像を考え
てみることにします。

『【第103号】SI業の方法論再建のシナリオ(前編)』の続きを読む・・・


【第102号】SI業での方法論の衰退

2005/04/01

DRI通信102号「SI業での方法論の衰退」 2005.3.2
風はまだひんやりしますが、陽の光は春の明るさになりました。風邪や花粉
を吹き飛ばして、せわしない期末を乗り切りましょう。
さて、DOA+コンソーシアムでは、2月15日、教育・普及を目的とする第
3分科会の第1回、「データモデリングって実際どうなの」を開催しました。
参加者は70名。はじめにテプコシステムズの国澤さんから基調講演があり、
その後パネラー真野(CAC)、堀越(データ総研)、渡辺(DBC)、稲見
(PFU)、佐野(NECネクサ)のみなさん、これをとりまとめる本村さん(ケン
システムコンサル)の名司会により、充実した内容になりました。かなり詳しい
報告がDOA+のWEBサイトに掲載されていますので、ご覧ください。
また、第1分科会第2回は2月28日、[アーキテクチャの整理とモデルメタ
構造]をテーマに議論しました。システム、DB、モデル、パターン、フレーム
ワークなどいろいろな言葉が登場しますが、人により、ときによりその意味や
相互関係が違い、かみ合わない無駄な議論が発生します。これを少しでも
解消していくために、まずどのようなアーキテクチャでこれらを考えているのか、
そのベースを整えるためでした。一度では無理でしょうが、そのきっかけが
多少はできたのではないかと思いました。
■方法論のShelfware化
2007年問題が取りざたされています。団塊世代以降のSEは、「出来上が
ったシステムに手を入れただけで、ゼロベースで考える力を持っていない」
などと言われます。われわれも、90年代はじめまでは、PLAN−DBの普及
を通じて、データモデルをベースに噛み合った議論のできる人が大勢育ち、
ユーザ会でも充実感のある議論ができていたのに、90年代半ば以降は、
そのような人がめっきり少なくなったように感じております。
一方、大手SIerの方法論なども名前は残っているものの、ほとんどShelfware
(棚の飾り物)化しているかに見えます。実際の開発は中小のSIerに任せる
ため、そのPMに強制することもままならず、QCD(Quality, Cost, Delivery)
だけに関心を持つ手配師となっていったかに見えます。

『【第102号】SI業での方法論の衰退』の続きを読む・・・


【第101号】システム部門の文化の進化

2005/02/01

DRI通信101号「システム部門の文化の進化」 2005.2.1
ついこの間お正月だと思っていたのに、もう2月になりました。実感は2週間
くらいしか経ってない。「人生の、はじめのほうから見ると結構長いのに、終
わりの方から振り返るとあまりにも短い」とか。ほんとですね。
2005年の第1分科会が動き出しました。
(詳細はDOA+コンソーシアムのウェブサイトをご確認下さい。)
24日、DOAを議論するときに、前提としているアーキテクチャについて、MSの萩原さん、椿、東京国際大学の堀内さんがプレゼンして、議論しました。予想通り多岐にわたるアーキテクチャがでてきてまとめきれず、2月28日もう1回やることにしました。
■システム部門の文化
強いシステム部門は、進化したシステム部門の文化を築き上げています。
先進的なIT技術を消化し、過酷なユーザニーズの変化に前向きに取り組み、
成功させて成長を続けていきます。弱いシステム部門は、ビジネスニーズに
応えるために、コンサルタントやSIerの支援を得て、先進技術に取り組みま
すが、失敗したり、成功したとしても大変な時間やコストの犠牲をともなった
上で、となります。中学生が大学受験しても合格がおぼつかないように、弱い
システム部門のままで、ERP、SCM、CRMなどに取り組んでも、所期の成
果を得ることは容易でありません。システム部門の文化とは何か、これを進
化させるにはどうすべきか、など考えてみます。

『【第101号】システム部門の文化の進化』の続きを読む・・・


DRI通信とは

2005/01/14

DRI通信とは、弊社創業者の椿正明が、DOAをベースに情報システムとはどうあるべきかを、独自の視点から述べているもので、1996年10月以来、毎月1回のペースでメール配信しています。
2004年12月現在では、4,000名以上の方々にご購読いただいています。
2005年より100号発行を記念して、Blog化して公開することとなりました。
尚、定期購読をご希望の場合は、「DRI通信購読お申し込みフォーム」からお申し込みいただけます。


【第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号】成熟度モデルを考える』の続きを読む・・・


【第90号】データモデルの進化

2004/12/27

DRI通信90号「データモデルの進化」  2004.3.1
氷の張るのを見ないまま、22日には21度になって、あっけなく冬が通り過ぎ、冬大好きのスキーファンにとっては、ちょっとさびしい気がします。花粉を防ぐためのマスクが目立ち始めましたが、皆様お元気ですか。
昨年暮れから始めたDOA+コンソーシアムには、皆様の関心が予想以上に高く、分科会も会場探しに苦労するほどの参加をいただき、今後どう運用しようかが、幹事会の課題となっている状況です。このエネルギーを日本の情報システムのレベルアップにどう活かすか、皆様とともに考えて行きたいと思っています。
■ データモデル
データモデルとは、データ構造、データ仕様を把握する枠組み・型・パターンと言う意味で用いられていますが、2つの使われ方があります。ひとつは「A社の販売システムのデータモデル」、「B社の生産管理システムのデータモデル」といったデータモデル個体に、もうひとつは「ERモデル」、「THモデル」といったデータモデルの種別を表すものに、です。学者は後者をDMF(Data Modeling Facility)と呼ぼうと提案しましたが使われていないようです。ここでは後者についてその進化を検討します。やや独断が混じりますが、ことの性質上客観は難しいので、ひとつの見方としてご容赦いただきたいと思います。
■ DMMM
前々回から進化を成熟度モデルとして扱ってきましたので、今回のはDMMM(Data Model Maturity Model)ということになります。次の5段階に分けて考えました。
(1)構造型DBMSモデル
(2) リレーショナルモデル
(3)ERモデル
(4) THモデル
(5) THeモデル

『【第90号】データモデルの進化』の続きを読む・・・


【第89号】メタデータ扱いの進化

DRI通信89号「メタデータ扱いの進化」  2004.2.2
本格的な冬を迎えていますが、いかがお過ごしですか。
さる1月20日、50名の出席者を迎えDOA+コンソーシアム分科会をスタートしました。初回で「各種DOA方法論の特徴・相互関係を理解するためにどのように議論を進めるべきか」がテーマでしたが、私の資料がややPLAN−DBの中身の見えすぎるものだったためか、議論を呼びました。しかし今後出てきそうな議論の片鱗が見えたので、対策を講ずると言う意味ではかえってよかったのかも知れません。参加の皆様から期待と貢献を伺いましたが、非常に熱心で今後の展開が楽しみです。
また、1月27日は35名の参加により、K2W勉強会(第15回)を行いました。ブレイズコンサルティングの鈴木秀美さまから「戦略経営とIT戦略の整合の重要性−エンタープライズ・アーキテクチャ」のプレゼンを頂いた後、「EAへの取り組み」として小島薫さま(BIT)、羽生田栄一さま(豆蔵)、萩原正義さま(MS)、真野正さま(CAC)、黒澤基博(DRI)によるパネル討論を行いました。足掛け4年続けかなりフランクな話ができるようになりましたが、DOA+に注力することもあって、これをもって第1期は終了とすることにいたしました。ご協力の皆様大変ありがとうございました。
■ メタデータ
「メタデータとは、データのデータである」などと説明されています。これは定義として不十分ですが、たとえば社員レコード
[1] −(椿正明、男、68、会長)
[2] −(竹下茂、男、62、専務)

 [社員番号]−(社員氏名、性別、年齢、役職)
として捉えるときの、社員番号、社員氏名、性別などである、と言えばおおむね理解していただけるでしょう。

『【第89号】メタデータ扱いの進化』の続きを読む・・・


【第88号】情報システムのアーキテクチャの進化

DRI通信88号「情報システムのアーキテクチャの進化」  2004.1.5
あけましておめでとうございます。おだやかな年明けでした。皆様お元気ですか。昨年末DOA+コンソーシアムを立ち上げました。今年こそDOA氷河期を終わらせたいと期待しています。データの図面を共有して、環境変化に柔軟に対応できる全体最適化の条件を整備したいものです。どうぞよろしくお願いします。
■ アーキテクチャへの関心
EA(Enterprise Architecture)が話題となり、ITアーキテクトといった肩書きの名刺を頂いたりするこのごろ、情報システムにおけるアーキテクチャへの関心が高まりつつあるかに見えます。アーキテクチャはシステムの寿命に関わります。10億円かけて開発して、5年で陳腐化するか、15年持つかは大違いですが、従来あまり問題にされてこなかったようです。うすうすこれを感じて問題にし始めたということでしょうか。
ハードの世界では、90年代ホスト(主人)がサーバー(僕、しもべ)にリプレースされ、さらに今これがWebの海に浮かぶというアーキテクチャの変革が進みつつあるわけですが、最近のアーキテクチャは主に90年代、短期ソリューションを目指して出来上がったバラバラシステムを、統合連携させようという、ソフトや業務モデル寄りのものに見えます。

『【第88号】情報システムのアーキテクチャの進化』の続きを読む・・・


【第87号】情報システムのスケールアップ問題

DRI通信87号「情報システムのスケールアップ問題」 2003.12.1
日が短くなって、葉が落ち、平地の紅葉も終盤戦になりました。気を抜かず注意していると風邪も引きにくく、また引いても早めに対策が打て、軽症で済ますことができます。元気にお正月を迎えましょう。
すでに案内申し上げましたが、正しい先進的DOAを普及しようと、幹事会社22社とDOA+コンソーシアムの立ち上げを企画し、12月12日(金)にDOA+コンソーシアム設立記念セミナーをひらくことになりました。会場の都合で人数に限りがありますので、お断りする可能性もありますが、そのときはどうかご容赦ください。1月以降、月1回くらいのペースで開く2つの分科会を中心に活動を展開する予定です。皆様のご協力をお願いいたします。
■ スケールアップ問題
ナイロン、テトロン、ポリエチ、ポリプロ、合成ゴムなどが工業化された、もう半世紀も前の石油化学時代、われわれケミカルエンジニアは、ビーカーの中で起きた化学反応がプラントの中ではそのとおり起きないからと、スケールアップ問題の重要性を教えられました。「規模/量の問題と質の問題は決して独立ではない」ということです。
情報システムにはたくさんのプログラムが含まれています。これを1本1本作って繋いでいけばうまく大規模システムができるか、というのが今回の情報システムのスケールアップ問題かと思われます。

『【第87号】情報システムのスケールアップ問題』の続きを読む・・・


【第86号】データモデルの設計思想

DRI通信86号「データモデルの設計思想」     2003.11.4
11月を迎え、平地でも木々の葉が色づき始めました。朝早く自転車で北鎌倉駅
まで、ライトをつけ手袋をはめ、さらに冷気で涙が出るのを防ぐためゴーグルを
つけて下る時期となりました。
10月30日(木)第14回K2W勉強会は、35名の参加のもと、「経営に役
立つ情報システム企画を立てるには」というテーマで行いました。サヴィオンテ
クノロジーの宇野澤社長からはBPM、ヘッドストロング瀬賀取締役からは
EAIについてのプレゼンをいただき、活発な議論が展開されました。次回は1
月27日(火)やはりBPMやEA関係のテーマで行いたいと考えています。
■ モデル化の目的と適用範囲
データモデルに限らず、モデルがないとすると、本や新聞のように、対象を自然言語主体で記述しなければなりません。自由度がありすぎて、属人的になり、抜けや矛盾の摘出が難しくなります。モデル化は、対象の持つ構造を捉えて、この自由度を必要十分かつ最低限に抑え、できればパラメータを指定するだけで、記述を完成させようとするものです。したがって、ある対象に対して、自由度のある、いろいろな記述のできるモデルは一般的に自然言語よりの未完成なモデルと考えられます。
化学プラントやデータモデルなど構造を問題とする対象は、一般に要素とその関係から構成されるので、箱と線を主体とした図と表で記述することになります。コンピュータは、図が解釈できないので、コンピュータ処理のためには、これを表−リレーショナルテーブルなど−に変換します。3次元物体は、目に見えるので、これに制約され、図の描き方にバリエーションが出にくいのですが、情報がらみの対象は、目に見えないため、多様な表現が考えられ、その標準化が難しくなります。

『【第86号】データモデルの設計思想』の続きを読む・・・


【第85号】DOAにおける処理の考え方

DRI通信85号「DOAにおける処理の考え方」     2003.10.1
8月と逆転したような9月でしたが、ここに来て秋らしくなってきました。厳しい状況が続きますが、皆様いかがお過ごしですか。
システムの規模をデータの共用される範囲とするならば、それは世界がひとつになるまで拡大しなければ止まないものように思われます。種々のトラブルを耳にするとき、このニーズへの対応力が企業競争力の要因のひとつとして、ますます大きくなっていくように感じられます。
「(情報)処理」という言葉が、いろいろな局面において使われますが、その内容、とくに粒度などが、まちまちとなって誤解が発生することが少なくないようです。以下その整理をDOAの観点から試みました。ご意見など歓迎です。気軽にお寄せください。
■データベースをハブにして
データ中心アプローチとは、それまでのプログラム中心アプローチを改めるべきものとして登場しました。プログラム中心の場合は、一般にその出力を次のプログラムが受け取るバケツリレー方式になりますので、インターフェースがスパゲッティになりやすく、またあるプログラムの変更がその下流のプログラムに次々と波及し保守性が非常に悪くなります。
データ中心の場合は、データベースをハブにして、プログラムはここから入力を受け取り、ここへ出力を返します。一般にデータベースはデータの記憶場所としての役割を果たすものと理解されていますが、むしろ通信の場としての役割の方が重要ではないかと考えられます。これによって各プログラムはデータベース通信場とのインターフェースだけ考えればよいので独立性が高まり保守性が向上します。

『【第85号】DOAにおける処理の考え方』の続きを読む・・・


【第84号】DOA第2ラウンド

DRI通信84号「DOA第2ラウンド」       2003.9.1
東京電力には良かったのでしょうが、大変涼しい夏でした。結局、海水浴はせず、ジョギングやサイクリングで体力維持を図ることになりましたが、皆様はいかがでしたか。
8月26日(火)第13回K2W勉強会は、「企業情報システムの役割、これまでと今後」というテーマで、8名の講師、45名の参加をいただき、やや発散気味の感もありましたが、熱心な討議が行われました。「業務システムは各部門の責任で開発・運用すべし」「システム部門は人的を含めたインフラ整備により全体最適をはかり、事業競争力のある先進的IT企業を実現すべき」などが指摘されました。
■DOA第1ラウンド
東京国際大学の堀内一先生(当時日立製作所)の命名されたDOA(Data Oriented Approach)が日経コンピュータ誌上で紹介されたのが1985年、その年の10月に弊社DRIは創立しました。ほぼ18年前になります。80年代は結構受けて、大企業の情報システム部門に対し、DOAによるシステム開発方法論「PLAN−DB」の教育・コンサルテーションを行うことができました。開発/再構築の手ごろなアプリケーションを選んで、3ヶ月くらいで概念DBを設計し、その中で人を養成します。従来のPOA(Process Oriented Approach)を脱し、DOA的考え方を身につけるには、どうしても3ヶ月くらいは必要でした。

『【第84号】DOA第2ラウンド』の続きを読む・・・


【第83号】LSVの目的と進め方

DRI通信83号「LSVの目的と進め方」   2003.8.1
長い梅雨ですね。皆様お元気ですか。私は大学4年の夏(1958)梅雨明けが待ちきれなくて、友達と二人でテントかついで北アルプスに出かけましたが、毎日雨、雲の平で往生したことを思い出します。ビールやクーラーも大変でしょうが、東北は地震もあって気の毒ですね。
会員の方にはすでにお知らせしましたが、8月26日(火)「企業情報システム部門の役割、これまでとこれから」という題でK2W勉強会を開きます。参加されたい方は弊社CRMグループまでご連絡ください。
■レガシーシステム
我が家の付近は昭和40年ころ開拓された住宅地ですが、世代交代の時期にあたり、更地にして売りに出される物件を良く見ます。この場合、建物はマイナスの評価とされているわけです。同様に、かつては資産であったソフトウエアが、もはや維持費のかかる負債であると評価されたりします。これは、高度成長期、短期的ニーズに対応して、田舎の温泉旅館の増築さながら、コピー機能を活用して、次々とソフトウエアを増産して作られたレガシーシステムに多いように思われます。
このところ2007年問題という言葉を耳にします。1947年生まれの団塊の世代が2007年に定年引退すると、彼らの作ったシステムのメンテナンスができなくなり、大きなトラブルが発生する、との心配です。度重なる場当たり的メンテナンスによって、ドキュメントとスパゲッティ化したソフトはすでに乖離していて、スーパーマンの暗黙知が頼りとなっている、その彼らがまもなく引退する、ということでの問題提起です。

『【第83号】LSVの目的と進め方』の続きを読む・・・


【第82号】高品質データモデリングの要諦

DRI通信82号「高品質データモデリングの要諦」   2003.7.1
厳しい第1四半期が終わりました。SARSも終盤のようです。梅雨は奄美大島までが明けたとか、風邪などにも注意してがんばりましょう。
弊社では恒例の夏のセミナーとして、今年はデータインフラ−?メタデータ、?コードデータ、?オペレーショナルDW−を取り上げました。?はリアルタイムDWとも言われますが、このところ非常に注目されてきています。システム間でやり取りされるハイレベルメッセージをストアし、オペレーショナル業務の意思決定のスピードと品質向上を狙うもの、ERPパッケージの狙いをより容易かつスマートに実現する可能性を持っていると期待されます。
■ データモデリング復活のきざし
情報産業はファッション産業でしょうか、90年代C/S、ERPなどに押されて影の薄かったデータモデリングが、こところ復活してきたように見えます。「既存システムのDB構造を見れば大体のデータ構造は分かる」、「小ぶりのC/Sシステムならデータモデリングと言うほどのものは必要ない」、「One Fact in One Placeなどと言っていると調整に時間がかかって間に合わない」、などの理由からしばらく敬遠されていたわけですが、SCM、CRM、連結会計など、出来上がった孤島システムを繋ぐニーズが顕在化して、「システム間インターフェースはデータから成る、その意味を合わせるデータモデリングと、その形式を合わせるコード統一が不可欠」となってきたのではないでしょうか。

『【第82号】高品質データモデリングの要諦』の続きを読む・・・


【第81号】ハイレベルLSVの提案

DRI通信81号「ハイレベルLSVの提案」   2003.6.1
梅雨のはしりの涼しい雨、風邪を引いたりする人が目立ちますが、皆様お元気ですか。
今年度も厳しいスタート、そして今は地球の限定された場所、限定された期間と思われているマスク姿が、100年後には「あちこち、いばしば」となったら悲しいなと思ったりする日々です。
今月は、聞いたこともない「ハイレベルLSV」をテーマとしました。LSVとはLegacy System Visualization すなわち「レガシーシステム可視化」という意味です。ハイレベルとは、「アプリケーション間で共通の」といった意味で、ロウレベルの「アプリケーション内固有の」という意味に対比するものです。したがって「アプリケーションの骨格構造の可視化」と理解していただいて良いかとも思います。
■成熟期に入った情報システム
企業による差はありますが、多くの企業において1990年ころまでに業務アプリケーションのシステム化と称するコンピュータ化が大幅に進められました。コンピューティングコストの低下とRDBMSの実用化が、これに大きく寄与したものと思われます。「白地」の未コンピュータ化業務は非常に少なくなり、処理の自動化による合理化が進んだわけですが、開発時期・スポンサー・開発担当者が違っていて、できたのは多くの場合、相互データ流通の難しい、いわゆる孤島システムでした。90年代に入っても、ユーザ主導のC/Sシステム開発など、この延長線上でたくさんの分散バラバラシステムがつくられました。

『【第81号】ハイレベルLSVの提案』の続きを読む・・・


【第80号】情報システムのサイエンス・工学

DRI通信80号「情報システムのサイエンス・工学」   2003.5.1
桜が咲いて1ヶ月経つと、緑、緑、緑のゴールデンウイークです。皆様お元気ですか。
システムを開発するときは、「10年先は分からない、とりあえず5年くらい先を考えて」と構想を立てるけれど、できてしまえば10年も15年も使い続ける。そうすると生き残っているシステムは皆賞味期限を過ぎたものばかりとなってしまう。このジレンマをどう解決すべきなのでしょう。
ところで5月20日(火)K2W勉強会を行います。テーマは「オブジェクト指向アーキテクチャとDOA」です。MSの萩原さんから「DOAと.NETのSOAの融合」また豆蔵の萩本さんから「J2EE、.NETアーキテクチャをベースとするオブジェクト指向開発」のプレゼンがあります。ご出席になりたい方は会員登録の上お申し込みください。
さて今月は「やはり勘と経験の世界」と言われてきた情報システムへの、サイエンスやエンジニアリングの適用はどうあるべきかについて考えてみました。
■ 情報システム
ここで「情報システムとは、企業などの業務アプリケーションシステムを指す」ことにします。ソフトウエアパッケージならばテレビや自動車の仲間かもしれませんが、オーダー品として建物やプラントの仲間として位置づけるべきものを考えます。実際その建設にかかわるSI業のデータ構造は、建設業/プラント建設業のデータ構造と酷似しています。
これら「ものづくり」にかかわる製造業・建設業では、電気工学、機械工学、建築工学、化学工学などの工学があり、図面の書き方が決まっていて、これをベースにユーザ要件/RFP(Request for Proposal)がつくられます。ところが情報システムの場合は、これに類する工学や図面の書き方が確立していません(情報工学という言葉はあっても内容が整っていないようです)。まだまだART、属人的な職人技から脱していません。今回はこれをテーマに考えてみたいと思います。

『【第80号】情報システムのサイエンス・工学』の続きを読む・・・


【第79号】システムの可視化

DRI通信79号「システムの可視化」           2003.4.1
イラク戦争の最中ですが、桜が咲き始めました。厳しい2002年度でしたが、
おかげさまでなんとか2003年度を迎えることができました。皆様はいかがでしたでしょうか。
インフラというとハードやネットワークを想定される方も多いようですが、われわれはメタやコードを中心にしたデータインフラを対象としています。標準化という縁の下の力持ちのような仕事なので、地味で即効性に欠け、それゆえにビジネス的に難しいのかと理解しています。しかしこれがあってはじめて、変化に即応する情報システムが構築できると、今年度もがんばって行きたいと考えています。どうぞよろしくお願いします。
■ いろいろなシステム
システムというと、コンピュータを用いて実装された情報システムを想定される方も少なくないかと思われますが、ここでは一旦、交通システム、社会システム、生態系システム、さらには化学プラントや建物などを含めて、もっと広義に捉えるものとします。一般に大規模かつ複雑なため、要素とその相互関係に分解して取り扱われるといった共通点を持ちます。

『【第79号】システムの可視化』の続きを読む・・・


【第78号】意思決定データ

DRI通信78号「意思決定データ」           2003.3.3
東京地方、雪は積もりませんでしたが、冬らしい冬で、桃が咲くにはまだ間がありそうです。秘策を講じていましたが、私もついに風邪にやられました。皆様はいかがですか。
2月6日には恒例の「データベース特別研究会」を行いましたが、多数ご参加いただき、また、奥井規晶様(ベリングポイント)、中山嘉之様(協和発酵)、はじめ時機を得た、実のあるご講演をいただき、大変好評を頂くことができました。
■インプットデータ
われわれがコンピュータを使うとき、キーボードやマウスを使ってインプットをするわけですが、そのインプットするデータは、次のように分類できます。
A.コンピュータの使い方に関するデータ(パスワード、プログラム名、ファイル名など)
B.コンピュータにストアさせるデータ
B1.リソースデータ
B11.定義データ(品番マスターや顧客マスターなど)
B12.ビジネスルールデータ(標準単価、発注点、標準出荷倉庫など)
B2.イベントデータ
B21.観測データ(POSデータ、受注データなど)
B22.意思決定データ(販売予測データ、発注データ、人事考課データなど)
C.コンピュータに送信させるデータ(EMAILの内容など)
今回はこのうちのB22.意思決定データについて考えて見ます。

『【第78号】意思決定データ』の続きを読む・・・


【第77号】業務アプリケーションのユーザ要件定義

DRI通信77号「業務アプリケーションのユーザ要件定義」 2003.2.3
厳冬の中にも、梅がほころび、日が少し延びて、春の近いのが感じられます。ひどい風邪にやられている人が目立ちますが、皆様いかがですか。
情報システムの世界にも流行があるのでしょうか、一時ERP、OOなどに押され気味だったDOAが、このところB2B、EAI、WEBサービスなどの広域統合問題解決の鍵として、再び注目されるようになったように思われます。先週行われたK2W勉強会では、新会社メタジトリの丸山則夫、松本聰両氏から、アパレル業界のデータ流通のためのリポジトリ応用の紹介がありましたが、これも鍵はXMLのタグの標準化のためのデータ項目の標準化というDOA問題でした。
ちょっと蒸し返しと思われるかもしれませんが、今月はこのテーマ「業務アプリケーションのユーザ要件定義」を選びました。業務アプリケーションを考えるときのスタートポイントを決める重要なテーマですが、その内容が人によって意外に違っていて、困ったからです。
■ユーザとは
まず「ユーザ」の捕らえ方ですが、「ユーザ会」などのイメージから来るのでしょうか、ハードメーカやSIベンダーなどですと、SEなど情報システムの専門家が含まれていたりすることがあります。この人たちを「業務アプリケーションのユーザ」と考えるのは妥当ではないでしょう。

『【第77号】業務アプリケーションのユーザ要件定義』の続きを読む・・・


【第76号】データベース通信場

DRI通信76号「データベース通信場」        2003.1.6
あけましておめでとうございます。
2002年は北朝鮮、イラク、不況と不穏のうちに過ぎていきましたが、今年はどんな年となるのでしょう。田中秀征元経企庁長官によると、このデフレは東西経済圏の統合から来るもので、「質実国家」を目指さなければならない、との指摘があります。となれば、情報問題も短期的な先送りでなく、問題の本質を見極めた、抜本的な対策が必須となってくることかと思われます。健康に留意して、厳しさの予想される2003年、強い情報システムを目指して、元気に立ち向かって行きましょう。
データベース(DB)は、今ではリレーショナル(RDB)が主流ですが、初めはTOTAL、IMSなどを用いた構造型DBでした。フラットファイルでは扱えない受注―受注明細や部品表(BOM)といったデータ構造が扱えるということで普及していきました。そのDBは、そのアプリケーション専属のデータの入れ物であって、複数アプリケーションによるデータの共用のためという発想は、まだほとんどありませんでした。

『【第76号】データベース通信場』の続きを読む・・・


【第75号】情報システム部門の役割その2

DRI通信75号「情報システム部門の役割その2」 2002.12.2
短い秋が過ぎて、早めの冬がやってきました。12月の声を聞くと、時の過ぎるのが速く「老年老いやすし」の感ひとしおです。
今年のK2W(Know What are the problems and Who know them)勉強会はアプリケーション・アーキテクチャを主題としてやっていますが、11月12日は東洋ビジネスエンジニアリング中村尚志(一世)さんの「ERP・レガシー共存のアーキテクチャ」に関する熱演で、参加の皆様方には十分ご満足いただけたようでした。次回は1月30日の予定です。ご興味のある方は是非会員登録(会費無料)していただきたいと思います。
73号でユーザ企業の情報システム部門の役割を論じ、74号で開発・保守を請けるSI業の対応について考察いたしました。本格的な調査を行ったわけではなく、日頃見聞きしたことを整理しただけで、皆様の認識とどの程度一致しているか、若干の不安もありましたが、かなり当たっているとの評価をいただきました。
■各氏の声を整理して
そこで今月は、コメント頂きました皆様方−峯岸輝明(住友金属)、新藤一豊(日揮情報)、油谷泉(SCS)、堀越雅朗(DRI)、小西了(NSRI)、長谷川泰司(DRI)、丸山則夫()、小松昭英(名商大)、長谷川兆秀(大和総研) 、上野則男(システム企画研修)、戸田忠良(戸田ソフトウエア事務所)ら各氏(敬称略)−の声を整理しながら、情報システムのありかたを考えてみたいと思います。

『【第75号】情報システム部門の役割その2』の続きを読む・・・


【第74号】大手SI企業病

DRI通信74号「大手SI企業病」      2002.11.1
桜の葉はすっかり落ち、紅葉が平地に降り始めました。流感で1週間低空飛行を
して、やっと治ってきました。今年のはしつこいようですから、ご用心ください。
ことのほか厳しい不況をかみ締めていますが、皆様いかがですか。情報関係、
全般には悪くないとのことですが、膨大なレガシーを抱え、「遅い、高い、ト
ラブル」情報システムの根本問題の解決への道はまだまだのようです。がんばりま
しょう。
■開発の主役は大手SIに
ERP、SCM、CRMなどの3文字英語が象徴するように、対象とすべきシステムの大きさが、ここ10年で1ランク上がったように見えます。そして情報システム部門の弱体化、またそのパッケージやSIサービスに関する調達部門化は、これと軌を一にするものに見えます。となると開発の主体は、SI業、それも大規模プロジェクトのリスクヘッジの観点から大手SI業、にシフトしていくことになります。情報システム開発の主役は大手SIとなる、その大手SIが日本の情報システムのレベルを決める。そんなことから、やや語弊のあるきらいはありますが、今回は「大企業病」ならぬ「大手SI企業病」として問題をとりあげました。

『【第74号】大手SI企業病』の続きを読む・・・


【第73号】情報システム部門の役割

DRI通信73号「情報システム部門の役割」 2002.10.1
彼岸花の赤と金木犀の香りがお彼岸を送ると、急に涼しくなってまいりました。
世界不況の中、皆様の02年上期はいかがでしたでしょうか。
暗黒大陸化したレガシーシステムの重圧は、増大する地球の炭酸ガスと同様なか
なか手ごわいもののようですが、解決の道を求めてがんばっていきたいと思います。
■弱体化する情報システム部門
成長を当たり前とする時代が終わって、M&A、カンパニー制、組織の再編や統合が日常
茶飯事として行われるようになってきました。リストラと称する人員削減が、情報システ
ム部門にも一律に行われたりします。経営にとっての情報の重要性は、低くなるはずもあ
りませんが、情報システム部門−親会社の仕事しかしないシステム子会社を含む−への評
価は、むしろ低くなることすらあるかに見えます。そこで今回は情報システム部門の役割
について考察いたします。

『【第73号】情報システム部門の役割』の続きを読む・・・


【第72号】3種類の言語つづき

DRI通信72号「3種類の言語つづき」            2002.9.2
さすがの猛暑も、台風13号以後勢いを失い、しのぎやすくなってまいりました。8月20日のK2W勉強会は、30人以上の盛況で、
札幌スパークルの桑原さんの実践経験に基づく迫力あるお話に[目から鱗]との感想も聞かれました。
データの流通を、1メインフレーム内から、C/S内、さらにWeb環境内と拡大すべくITが進化する一方、分社化、M&A、
アウトソーシング、SCM、CRM、連結会計など組織・業務環境が激変します。この変化と成長へのお荷物にならない情報システムを
如何に造るか。これが今の最大の戦略的課題と、あらためて認識させられた次第です。
さて今月は、先月の「3種類の言語」についての2件のコメントを紹介させていただくことにしました。
■ 戸田忠良氏(戸田ソフトウエアオフィス)
本稿の結論に賛成です。テーブル言語の活用を上流の設計から利用すべきと思います。
テキスト言語(特に自然言語)による設計文書の作成とそれを使った人間VS人間、ま
たは人間VSコンピュータ間のコミュニケーションの非効率性が、現在のシステム開発
の最大の問題点です。

『【第72号】3種類の言語つづき』の続きを読む・・・


【第71号】3種類の言語

DRI通信71号「3種類の言語」            2002.8.1
7月10日の弊社セミナー、創業以来始めて[札止め]とさせていただきましたが、
事例発表も[広域統合はこの方向で間違いない]を確信させる内容で、大変うれしく思いました。
標準化を実践する企業文化が前提になりますので、地道な活動ですが、高品質とスピードを求めて、
さらにがんばっていきたいと勇気づけられました。暑さの盛りを迎えますが、皆様のご活躍を期待いたします。
さて今月は、3種類の言語の特性から、情報システムの仕様(What)にかかわるコミュニケーションは
如何にあるべきかを考察します。言語とはコミュニケーションの道具ですが、その形式から
・ テキスト言語
・ 図面言語
・ テーブル言語
の3つに分類できると私は考えます。一般の論文もこの3つで構成されています。コミュニケーションの
種類としては、
a.ユーザとシステム設計者
b.システム設計者とプログラマ
c.プログラマとコンピュータ
を考えます。トップマネジメント/スポンサーとユーザの間のコミュニケーションなどはWhatというよりも
Whyにかかわるものであるため、ここでは除きます。

『【第71号】3種類の言語』の続きを読む・・・


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

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

『【第70号】インターフェースの標準化』の続きを読む・・・


【第69号】システムと企業文化

DRI通信69号「システムと企業文化」      2002.6.1
景気底這いの中、速く良い大規模システムを作れという難題に挑戦されておられる方が多いかと思われます。
金で買えないデータと人材のインフラの差が成功か否かを分けるようです。インフラを作りながら、
開発にも対応する、その知恵が要求されています。
われわれもこの難題に日夜挑戦しております。お気軽にご相談ください。
今月は、やや趣向を変えて、いろいろな人や情報を通じて感じている、「システムと企業文化」と言った
問題について記してみます。
やや独断や偏見が過ぎるかもしれませんが、他意はありませんので、ご容赦ください。
■ 各社各様
仕事柄いろいろな企業の、情報システムをあずかる人々とお付き合いさせていただいております。
通り一遍の説明でなく、業務の流れ、画面・帳票サンプル、物理ファイルフォーマットまで、見せていただくため、
情報システムの実態を、奥深く拝見することになります。

『【第69号】システムと企業文化』の続きを読む・・・


【第68号】業務アプリケーションの分類

DRI通信68号「業務アプリケーションの分類」 2002.5.1
新緑も半月ばかり早く来て、この先梅雨や夏がどうなるのかちょっと心配ですが、皆様お元気ですか。
UFJに限らずどこでも発生しうると、申し上げた矢先、みずほでさらに大きなトラブルが発生しました。
担当者の志気やトップの判断というより、システム構築技術アプローチ−暗黙知のまま自然言語だけで
コミュニケーションを行う−の限界を越えてシステムが肥大化したのが、根本原因のように見えます。
われわれは業務モデルを可視化して共有する方法論に解を求めていきたいと思います。よろしくお願いします。
■「はんぺん型」と「かまぼこ型」
私は66号でアプリケーションソフトは「はんぺん型」と「かまぼこ型」の2種に大別できるのではないか、
という仮説を提案しました。すなわち「はんぺん型」とはミドルウエアなどのシステムアプリで、
ユーザがデータ構造を意識しないもの、「かまぼこ型」とは販売物流や経理などの業務アプリで、
ユーザがデータ構造を意識するものです。かまぼこの板がデータ構造で、プログラムは板に縛られるため、
メンテ時、項目の追加には対応するが、削除は行わず、大規模化・複雑化の一途をたどり劣化します。

『【第68号】業務アプリケーションの分類』の続きを読む・・・


【第67号】保守の対策

DRI通信67号「保守の対策」 2002.4.1
政治の昏迷、経済の停滞のなかで、2002年度がスタートします。皆様いか
がお過ごしでしょうか。
システムは、ともすると野放図に大規模化・劣化し、制御不可能になりがちで
す。厳しい環境下ではありますが、われわれは、これをいかに制御し経営に役
立たせるべきか、コンサルティング現場の中で種々の知見を蓄積・整理しつつ
あります。完成したノウハウというよりも、実際のプロジェクトに適用して完
成に近づけていくべきものかと考えます。本年度も皆様のご配慮・ご支援をよ
ろしくおねがいします。
さて今月の67号では、2月28日開催の第7回K2W「保守の対策」をまとめます。
これはさきの64号で第6回K2W報告を兼ねた「保守の実態」に続くものです。
無計画に肥大化したレガシーシステムの保守問題は、永遠の課題ですが、K2W勉強会
としては、保守問題は一旦きりあげ、広域統合など別の話題をとりあげていきたいと考えています。
「保守の対策」の議論は「巨大化・暗黒大陸・つぎはぎ・属人化・スパゲッティ状態」
のレガシーシステムを抱えた大手A社(詳細は省略)に対するコンサルティング提案を募り、
この紹介をもとに行いました。

『【第67号】保守の対策』の続きを読む・・・


【第66号】第2のアンバンドリング

DRI通信66号「第2のアンバンドリング」 2002.3.1
Y2Kが終わり、ERPの限界が見えてきたためでしょうか、「IT上級副社
長の第1の関心事はメタデータである」など、このところ英文の文献では、
メタデータや統合についての記事が目立ちます。データ流通のためのデータの
整備・標準化は、建物における基礎工事のように、人目を惹きませんが、シス
テム規模の拡大とともに、重要性を増してくるものかと思われます。厳しい経
営がつづきますが、日夜がんばっています。ご支援よろしくお願いします。
■アンバンドリング
さて今月のタイトルには「アンバンドリング」などと言う、年寄りには懐かし
い、しかし今時の若者には聞きなれない言葉が登場しました。きっかけは最近
読んだ「情報サービス産業人物列伝−ソフトウエアに賭ける人たち」(コンピ
ュータエイジ社)にあります。日本のソフト産業をリードしてこられた24人
の方々を紹介しているわけですが、佐藤孜氏(日立ソフトウエアエンジニアリ
ング)、佐藤雄二朗氏(アルゴ21)、服部正氏(構造計画研究所)など何人も
の方が、ハードウエアのおまけのような位置づけだったソフトウエアの価値を
認めさせるためにご苦労され、結局ソフトウエアのアンバンドリングによって
それが達成されていったと語られていたからです。

『【第66号】第2のアンバンドリング』の続きを読む・・・


【第65号】要件定義

DRI通信65号「要件定義」 2002.2.1
2002年も不況下、田中外相の更迭があるなど、不穏な幕開けとなっていま
すが、皆様いかがお過ごしでしょうか。
一昨日弊社恒例のセミナーには80名を超すご参加をいただき、2001年の
トレンドやレガシーシステムの可視化などお話させて頂きました。レガシーシ
ステムの実態を弊社長谷川は、「巨大化・暗黒大陸・つぎはぎ・属人化・スパ
ゲッティ状態」と説明しておりましたが、「UFJ銀18万件28億円二重引
き落し」もいつどこで起きても不思議でない、われわれシステム関係者の抱え
る共通の難題として認識した次第でした。
64号「保守の実態」に関して、コメントを頂いておりますが、次回に回し、今月は
昨年6月および8月に行われたK2Wでの議論も踏まえて、DOAの本題とも言える
「要件定義」について考察いたします。
情報システムに対するユーザの要求は、「所定のタイミングで出力される、所定の
データ項目を含む画面・帳票」ですから、情報システムはデータベースにストアさ
れたデータを部品とし、画面・帳票を製品とする組立加工製造業と見ることができます。

『【第65号】要件定義』の続きを読む・・・


【第64号】保守の実態

DRI通信64号「保守の実態」 2002.1.1
21世紀第1年目は、テロと不況のなかあっという間に過ぎて行きました。問
題は常に発生するもの、これを解決しながら進めるのが人生と、明るく前向き
にがんばりましょう。
さて先月の63号では、弊社の取り組んだ実験的プロジェクトをもとに、レガシー可視化
を扱いましたが、今月はアンケートやK2W勉強会での議論から、保守の実態およびある
べき姿についてまとめることにしました。なおこの64号をもって、K2W勉強会報告を
も兼ねたいと思いますので会員の方々よろしく。
■会員アンケートから
K2W会員の方々にアンケートを依頼し、ご協力いただきました。ソフトハウスなどで保
守案件を持っておられない方々もあり、12件のご回答しか頂けませんでしたが、平均的
には次のような実態でした。
・保守ボリュームは、予想以上に具体的に把握されていない
・保守要員が何人かは、あまりはっきりつかまれていない
・一般には開発に関わったSE・プログラマが主体で保守を担当している
・知識は、先輩からOJT的に受け継いでいる
・手順・フォームを決めて実施するケースがほとんど
・プログラムを直接トレースしている
・保守のスピード・コストが問題になっている
・その原因は改訂箇所の特定に時間がかかること
・方法論・体制・ツールによってこれを削減するつもり

『【第64号】保守の実態』の続きを読む・・・