» 【第48号】リポジトリと方法論

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

DRI通信48号「リポジトリと方法論」2000.9.1
猛暑の夏が続いていますが、オリンピックの9月に入りました。夏休み返上で
頑張っておられる方も多かったようですが、お元気ですか。長かった不況が
終わったかと思ったら今度は人が足りません。遅まきながら採用したくても、
皆さん、世界一のビジネスモデリング・コンサルティング会社よりも、大手
企業に望まれて行ってしまうようです。
47号では「要件定義」を扱いましたが、数人の方からご意見をいただきま
した。大手SIの開発方式については、「そのとおり」とか「もっと低次元・・・
顧客の業務部門の人とコミュニケーションできる人は例外的」「大手SIに
とっては物理が商品だから」とのこと。さらに「概念詳細をやると4−6ヶ
月かかる。並行的にやって時間を短縮したい」との切実な声もありました。
PERT図については、元武田薬品の公江様から「新人の訓練に良い。管理
ツールというより、分析ツール、コンセンサス用ツールと考えた方がよさそ
う。情報システム開発では、細部が不確定で、意味のあるブレークダウンが
難しい。できない人はできないからやらない、できる人は細部が暗黙知とし
て頭の中にありガントチャートで十分なのでやらない」と、ご経験を思わせ
る貴重な指摘をいただきました。
さて今月はシステム開発・保守のためのデータベース「リポジトリ」と開発・
保守の「方法論」との関係について考えてみます。


■リポジトリとは
リポジトリは、かつてはDD/D(Data Dictionary Directory)と呼ばれて
いました。DATAMANAGER がその代表的パッケージです。特定のDBMS
環境を記述するものとして、ADABAS用のPredict、IDMS用のIDD(後の
Encyclopedia)などもリポジトリと呼ばれています。
リポジトリとは、一口でいうならばメタデータ、すなわちデータ項目に関す
るのデータをストアする一種のデータベースです。たとえばリソースデータ
ベースにおいて
(顧客ファイル) (商品ファイル)
顧客番号 顧客氏名 勤務先名 商品コード 商品名
――――――――――――――――― ――――――――――
123 田中彰 トヨタ自動車 .. ..
124 中村肇 IBM
125 山口雅子 松下電器
.. .. ..
とするとき、顧客ファイル、顧客番号、顧客氏名、勤務先、商品ファイル、
商品コード、商品名などの見出し部分(線から上)がメタデータになります。
これはシステム開発時、開発担当者が洗い出してきます。この例には、ファ
イルとデータ項目しか表れていませんが、画面・帳票、プログラム、ユーザ、
パスワード、端末、コンピュータ、回線などもリポジトリの記述対象として、
これに含まれます。
■3層リポジトリ
しかしリポジトリはその運用環境対応に、次の3層に分けて考えられます
(椿の仮設、DRI通信10号参照)。
(1) 業務モデルリポジトリ(企業対応に1個存在、概念ファイル・データ
項目・画面・帳票などを規定、10号ではビジネスモデル・リポジトリと
呼んでいた)
(2) ソフトウエアリポジトリ(ソフト環境ごとに1個存在、プログラム・
物理ファイルなどを規定)
(3) 運用リポジトリ(運用環境ごとに1個存在、ユーザ・パスワード・
端末・コンピュータ・回線などを規定)
■メタデータ
今回は(1)の業務モデルリポジトリに絞って話しを続けます。業務モデル・リポジ
トリには
(ファイルファイル) (データ項目ファイル)
ファイル番号 ファイル名 データ項目番号 データ項目名 桁数
―――――――――――― ――――――――――――――――――
F10 顧客ファイル D101 顧客番号 8
F11 商品ファイル D102 顧客氏名 30
.. D103 勤務先名 30
などがストアされることになりますが、開発担当者が洗い出してきたメタデ
ータがストアされています(線の下)。このメタデータのメタデータ(線の
上)はしばしばメタメタデータと呼ばれますが、これがリポジトリの構造を
決めています。「メタメタデータとして何を用意すべきか」、すなわち「リポ
ジトリの構造はどうあるべきか」、は情報システムにとって最大の課題かと
思われますが、これが今回のテーマです。
■決めるものか決まるものか
リポジトリの構造が決まれば、メタデータの流通が確保され、システム開発・
保守が大幅に合理化されるので、各種標準化団体が取り組んでいます。しか
しこれは「皆で決めれば良い」ものでしょうか。「決めれば良い」ものは
決めれば良いのですが、「決まってくる」ものを決めると矛盾が発生してき
ます。すなわち何を独立変数(決めるもの)に選び、何を従属変数(決まる
もの)に選ぶかをはっきり認識した上での議論になっているかが問題です。
われわれは、PLAN−DBのなかで「情報システムの製品であるIOの仕
様(含まれるデータ項目)を決めれば、(その原料であるデータ項目を整理
した)DBの構造は従属的に(個人差なく)決まる」として
DB=f(IOs) ここにf=PLAN−DB手法、sは複数を表す
と説明しています。
したがってわれわれは、われわれの業務モデルリポジトリ(THeRepository、
現在開発中、V1は今年10月完成予定、予約販売受付中)の
構造を決めるに当たり、PLAN−DBを中核にした方法論PLAN−DOA
を固め、次にユーザ要件を完璧に記述できる(仮設)基本4ドキュメント
(1)IPF(Information Process Flow)チャート
(2) IOイラスト
(3) 概念DB構造図(業務データ関連図)
(4) データ定義書(加工データに関するSPFチャートを含む)
の形式を確定してから、PLAN−DB手法によりこれらをデータ分析しまし
た。
■システム開発システム
システム開発は、上流の要件定義および下流のソフトウエア開発から成る一
種のアプリケーションシステムです。この上流工程の結果をストアするのが
業務モデルリポジトリであり、下流工程の結果をストアするのがソフトウエ
アリポジトリです。
すなわち
生産管理業務ルール→生産管理ドキュメント→生産管理DB構造
販売管理業務ルール→販売管理ドキュメント→販売管理DB構造
などと同様に
システム開発方法論→システム開発ドキュメント→リポジトリ構造
の関係がありますから、リポジトリ構造だけが一人歩きしてもらってもユー
ザは、その前提となる方法論およびドキュメントが曖昧な間は旨く使えませ
ん。かつてのIBMのリポジトリマネジャープロジェクトが失敗に終わった
根本原因はここにあったと思われます。DATAMANAGERユーザも、自ら方
法論を固め、開発ドキュメントを規定し、これに合わせたカスタマイズに成
功したところだけがこれを使いこなしています。ただしカスタマイズにより
他社リポジトリとのメタデータの流通が難しくなるが、それは考えなくて良
いことにして。
■標準化の動き
いま欧米の大手ベンダーを中心にリポジトリ構造の確定・標準化の動きがあ
りますが、業務モデルとソフトウエアや運用の分離の話しは聞こえてまいり
ません。また開発・保守方法論や前提とするドキュメントに関する吟味の話し
も聞きません。リポジトリ構造を独立変数にして、ドキュメントや方法論を
従属的に決めるべきと考えているのでしようか。生産管理DB構造をコンセ
ンサスベースでまず決めて、それからこれに合わせた生産管理業務を行いま
しょう、と言うようなアプローチで、はたしてうまくいくのか心配になりま
す。それともCreate文を生成したりできる、EXCELのような小道具の
類として、リポジトリを位置づけているのでしょうか。「IRMの真の成功は
正しい方法論との連携を待って」と思われるのですがいかがですか。