標準化は1:9で推進せよ
2008/12/22システム開発方法論やデータの標準化に成功した企業は沢山あります。正確に言えば、一時期成功したと思えるような成果が出た企業が沢山あり、その後、オープン化やWeb化の波にのまれて元に戻ってしまった企業も沢山あり、さらにもう一度チャレンジして標準化し直した企業も沢山あります。
システム開発方法論やデータの標準化に成功した企業は沢山あります。正確に言えば、一時期成功したと思えるような成果が出た企業が沢山あり、その後、オープン化やWeb化の波にのまれて元に戻ってしまった企業も沢山あり、さらにもう一度チャレンジして標準化し直した企業も沢山あります。
実世界には「もの」があり「こと」がありますが、我々はこれらを正確にモデル図に写像できているわけではありません。必ず、「人が認識する“もの”」、「人が認識する“こと”」の表現になってしまいます。その意味で、ビジネス世界のモデル化の対象とモデル図に表われる対象は、ピッタリと一致するわけではありません。
業界全体ではなく、企業内でシステム開発方法論などを標準化する場合、さまざまな障害があります。
標準化に成功している企業は、最初に遭遇する壁を上手に乗り越えています。
最初の壁とは、標準化された作業手順・成果物を適用すべき最初のプロジェクトで、「策定された標準を使わない」という壁です。
「もの」や「出来事」のモデリングは、個々バラバラの存在だったインスタンスをタイプ化することです。たとえば、鈴木一郎、佐藤次郎、山田三郎という3つのインスタンスに「顧客」というタイプ化した名を与える行為です。
しかし、ビジネスの世界では、別なタイプ化も必要とされます。
現実の世界に、それ自身独立して、確固たる存在としての「出来事」や「もの」があるのでしょうか。
認識は主体と客体の関係性によって決まります。そして、同じ主体、同じ客体であっても、見る視点が変われば、異なった様相として認識することがあるのです。
今回は、対象を「もの」と「出来事」に、明確に区別できることもあるができないこともある、というお話です。
「もの」と「出来事」は相互依存の関係にあり、その2つを同時に決めているのは、モデリングのコンテクストである「場」です。
それでは、その「場」を決めているのは誰なのでしょうか?
それは、モデリングの主体、すなわち企業です。モデラーが勝手に「場」を決めるわけにはいきません。
「もの」と「出来事」が相互依存の関係にあるとして、依存する相手が無制限に拡がったのでは、モデリングが不可能になります。
「もの」は、それ自身では意味をなさない。つまり、「もの」のインスタンスに対してタイプ化した意味を表そうとしたとたん、「もの」は「出来事」との関わりを意識した「名」を必要とします。「もの」は「出来事」と無関係に存在するのではなく、「出来事」との関係において意味づけられるのです。
ビジネスの世界では、契約すなわち「約束事」があって、それに基づき「物やサービスの提供」「対価の受取」が発生します。取引を行う当事者間で、あらかじめ決めておいた順序で「出来事」が発生します。契約が無い場合であっても、取引者の一方が提示した取引方法や商法で決められたルールがあって、その範囲で「出来事」が発生します。
「もの」中心の概念データモデリングでは、「出来事」よりも先に「もの」を認識します。「ものを最初に認識する方が簡単である」という主張は、前提となる条件があれば正しいでしょう。しかし、その条件を理解することなく、単純に受けいれることはできません。
「もの」は「出来事」と違って認識しやすい。従って、「もの」を先に認識し、その後「もの」の状態を変化させる「出来事」を認識すると良い。
そのようにアプローチする概念データモデリングが存在します。
グループCIOが集まる勉強会に参加しました。
参加者のほとんどは情報システム子会社の社長さんです。
テーマはグループ企業のITガバナンスと情報システム子会社のミッションです。
経営者は情報システム部門をどうしたいのでしょうか?
ユーザ企業にとって、情報システム部門は間接部門です。したがって、コストダウンすることが情報システム部門の使命の1つであると思います。でも、それだけでしょうか。
データベースやフラットファイルにアクセスする機能をもち、業務アプリケーションに対して実装独立のインタフェースを提供するプログラムをビューマネジャーと呼びます。(ビューマネジャーは一般用語ではありませんので悪しからず。)
課題設定の工程は、達成すべき効果や到達したい姿をイメージしながら、新業務で実施すべきことを明確にします。新規設計の工程ではありませんので、詳らかに仕事の内容を定義する必要はありません。新しい業務では「○○すべき」という業務改善の中核を定義します。
「既存システムがブラックボックスになって困っている」
システム再構築や保守の段階で良く聞く話です。
最近エンタープライズアーキテクチャの仕事が増えていますが、Asisモデルの作成時にも同様の声を聞きます。
ある人が「自分が使っている概念データモデルはビジネスを表したもので、自動生成をねらうDOAはビジネスを表していない」と言います。骨格であろうと、ソフトウェアを生成できるほど詳細であろうと、実装独立にビジネスを表現している点は変わらないのに、その事実を知らずに批判します。
「現状分析がなぜ必要か?」
業務設計の4工程で紹介した、基本どおりの作業展開を提案すると、ユーザやシステム担当者の中には「現状分析工程を飛ばして、課題設定や新規設計からスタートすれば良い」と言う人たちがいます。
業務設計で2番目の工程が現状分析です。現状分析を簡潔に表現すれば「現状の業務を可視化し、問題点や課題を共有すること」です。業務機能の分解図や業務フロー図、概念データモデル図などを作成します。もちろん、問題点や課題の一覧表も重要です。
システム再構築や比較的大きな保守において、業務設計工程は次の4つから構成されます。その4つとは、「目的・ねらいの設定」「現状分析」「課題設定」「新規設計」です。今日は、そのうちの「目的・ねらいの設定」について話します。
ある会社のシステム開発方法論を作成していたとき「データモデルを現状分析工程の成果物にして、ユーザにレビュしてもらおう」とある人が言いました。すると、別な人が「データモデルはシステム内部の構造を記述しているのだから、ユーザがレビュするような性質のものではない」と反論します。さて、どちらが正解なのでしょう?
在庫エンティティが見つかる画面や帳票を複数分析すると、次のような3種類のエンティティを認識することがあります。
A[受注番号]−(部署コード.商品コード.受注数.受注年月日・・・・・)というイベントエンティティのサマリー、つまり要約エンティティを考えてみます。
たとえばB[部署コード.商品コード.受注年月]−(受注合計数)です。
数量データを扱っていると、意味の等しい2つの正規化に出会うことがあります。
たとえば、次のように。
A:[社員コード.給与支払年月]−(給与額)
B:[社員コード.給与支払年]−(1月給与額、2月給与額、・・・・、12月給与額)
「データ中心のエンタープライズアーキテクチャ」を執筆するきっかけは何ですか?と多くの人から質問されます。
私の場合、いつかは共著ではなく単独で本を執筆したいと思っていました。ですから正確に言えば、「なぜ今書くことにしたか」に応えることになります。
15年以上も前になりますが、「エンティティとは何か」を議論したことがあります。そのときの話を紹介します。
概念データモデルで扱うデータ構造とは何か。
一言で表現すると「データ項目とデータ項目の関係」です。
ただし、業務的になんらかの意味が対応することが条件です。
データ項目とデータ項目の関係をもう少し細かくみると、次の関係が見つかります。
販売物流や会計などの概念データモデルを作成したとき、そこに表われるデータ項目は一般の業務で使われるものですから、アプリケーションのデータです。ここでは省略してアプリデータと呼びます。一方で、システム開発そのものを1つの業務領域と考えて概念データモデルを作成した場合、そこに表われるデータ項目はメタデータです。メタデータはアプリデータを説明するためのデータと言うこともできます。たとえば、データ項目番号、データ項目名、桁、定義域番号などです。
今日は、ちょっとした遊びの話から。
競馬ではパドック(競争前の下見場)を回る馬たちを解説者が評価します。たとえば、こんな風に。
エンタープライズアーキテクチャに関する話題を日記で書いてほしいという要望がありました。
実は、EAの仕事が最近多くなり、リアルタイムでご支援するお客様もあるため、日記に書くことは避けていました。しかし、頻繁に遭遇する課題やよくある質問を話題にするのは問題ないと思います。
データディクショナリあるいはリポジトリを使ってデータ項目を管理する場合、メタモデル上ではこれらを識別するメタデータが必要になります。
データ項目を識別するメタデータは、データ項目番号またはデータ項目名です。
番号であっても名称であっても管理する対象が識別できれば良いわけですが、「番号派」と「名称派」それぞれに好みやこだわりがあるようです。
前回お話した伝票型の画面や帳票の中には、ヘッダ・明細の形になっているものが多く見つかります。たとえば、受注伝票は受注ヘッダと受注明細から出来ています。この種の画面や帳票を素材に作成した概念データモデルはすべて同じ型をしています。すなわちヘッダエンティティと明細エンティティの構造です。これを取引パターンと呼びます。
概念データモデリングの素材として、ユーザが実際に使っている画面や帳票を使うことがあります。
多くのモデリング経験から画面・帳票は3つのパターンに分類できることが知られています。
要約エンティティは、月別の販売合計数・日別の販売合計金額などのフローデータを従属データにもつエンティティです。
KEYのなかに、合計対象の期間を表す年・半期・年月・年月日などのデータ項目が含まれます。
顧客エンティティのSタイプのKEY名は、顧客コードとなります。この名称を分解すると
顧客コード=「顧客」+「コード」となります。
顧客エンティティのSタイプのKEY名は、顧客コードとなります。
社員エンティティのSタイプのKEY名は、社員コードとなります。
受注エンティティのSタイプのKEY名は、受注番号となります。
KEYの形式を別な観点で分類してみます。
Sタイプ:発番対象のエンティティめがけて発番するKEYの形式です。「連番」だけでKEYを構成します。SタイプのSは、シーケンシャルの略。
例)顧客コード、社員コード、受注番号
KEYの一般形は[発番範囲.発番期間.連番]ですが、連番が入る場合とそうでない場合があります。
請求エンティティa [顧客コード.請求年月]
請求エンティティb [請求番号]
エンティティを識別するKEYは、エンティティと等価の意味をもっています。概念データモデルを深く理解するためには、KEYに関してもいろいろな角度から考察しておくと良いでしょう。そこで、今日はKEYの一般形を紹介します。
個別業務領域を越えて、広い範囲でコードを統一する企業が増えています。一部上場企業のほとんどが、なんらかのコード統一課題を抱えていると言っても過言ではありません。
ERPパッケージは、一般的な業務構造および一般的な実装手段を提供しています。私の言葉で言えば、実装独立の仕様も実装従属の仕様も一般解を提供するソリューションです。
人とツールと方法論とコンテンツを組み合わせた結果、業務アプリケーションを効率良く製造するしくみが出来上がります。一種のプロダクトラインです。
理想的なシステム開発・保守の環境として「人とツールと方法論」を話してきましたが、もう1つ重要なことを追加しておきます。
前回お話したデータ共用のアーキテクチャのうち、概念データオープンアーキテクチャを採用した場合、各オブジェクトは標準化された概念データ項目を自由に利用できます。
企業が社員の結婚を捉える際に、認識の経済学が働きます。
企業の管理目的を気にしなければ、結婚のエンティティ構成は次のようになります。
ピュアなエンティティを切り出す仕事、すなわち概念データモデリングの仕事をしていると、ビジネスに携わる人々が、いかに手抜きをして実世界を認識しているかがわかります。
「One fact in one place=1つの事実を一箇所に」
「One fact to all users=1つの事実を利用者全員に」
この2つは、データ設計上の基本的な考え方を表現したことばです。
ある人から「会社がどうあるべきか、これを見て勉強しなさい」と言われ、「NHKスペシャル井深大が語る本田宗一郎」のDVDを渡されました。
私がデータ総研に入社したころは、リレーショナルデータベースが市場に出始めた時期です。当時、データの正規化はリレーショナルデータベースを使うために必要な設計技法と言われていました。
しかし、実際のところ、パフォーマンスが出ずに正規化したデータ構造は使えませんでした。
製造業の製品設計工程を支援する業務アプリケーションでは、部品構成表を扱います。設計のバージョンが上がるたびに、製品を構成する部品の多くが入れ替わり、変更履歴を残すのは大変です。2つのバージョンを比較しても、共通部品がほんの少ししかないこともあります。しかも、非常に短い時間の中でこれらの変更が発生します。
一般に、履歴エンティティは、履歴を残す対象(インスタンス)が安定的で、その従属項目値の変化を時系列に保持するものです。社員エンティティに対する社員異動エンティティは、履歴エンティティの典型的な例です。
一般に、正規化するとデータ項目は1つのエンティティに従属します。
しかし、時間の経過を考慮すると、そのデータ項目が複数の値をもつこともありえます。
概念モデルを概要モデルと勘違いしている人がいます。たまに、会話が成立しないため困ります。
“概要モデル=「粒度があらい」「緻密でなくても良い」モデル”なのですが、“概念モデル”も同様にとらえる方がいるのですね。
概念データモデリングの結果、実世界の「もの・こと」に対応したエンティティが洗い出されます。
その後工程で、エンティティは論理ファイルとして実装されます。
論理ファイルを設計する段階では、エンティティは、データを蓄積する対象としてとらえられます。
正規化の形として第一正規形・第二正規形・第三正規形・コッド正規形などが有名です。
しかし、正規化のプロセスに関しては、あまり良い作法が語られていません。
イベントエンティティとイベントエンティティの関係は、1:1、1:n、n:1、分解集約型n:m、集約分解型n:mの5パターンがあります。
あるスポーツ選手のインタビュを聞いていたときです。「スポーツは心技体と言うでしょ。でもほんとうは体技心だと思うんです」とコメントしていました。
自然言語を使う場合と比較して、モデル図は「対象」と「対象」の関係を表現するのに適しています。
そしてモデリングは、表現された「対象」に適切な言葉を割り当てる作業です。
言葉の意味は相対的ですから、言葉の意味を構造的に理解するためにはモデル図が適していると思います。
画面の紙芝居をいくら作成しても、新規業務の内容を詰めることはできません。
画面や帳票の数が300程度以上の規模で、紙芝居アプローチをとって失敗するプロジェクトが多いようです。
今日は、概念データモデリングの奥義を1つ紹介します。
PLAN-DBは、エンティティの配置を非常に大切にします。概念データモデル全体の中で、位置が意味を表しレビュの品質を上げるからです。
「RDBを使うからデータモデリングするんでしょ!」そう言うシステムエンジニアが多いようです。
オブジェクト指向で概念モデルを知っているはずの人でさえ「RDBを使うからUMLでなくてもERモデルでOK」などと言うのです。
新しいデータモデルテンプレートを考えているとき、イベントエンティティとイベントエンティティの関係にいくつかのパターンがあることに気づきました。
良いたとえかどうか自信がないのですが、将棋のプロを目指すとします。
3級の人が3級の人と将棋を打っても、それほど上達しません。本で棋譜を覚えても、自力で5段になるのは難しいでしょう。大抵は誰かの弟子になるか、そうでなければ5段以上の人と頻繁に将棋を打てる環境が必要です。
「心は形をもとめ、形は心をもとめる」は、拙著「データ中心のエンタープライズアーキテクチャ」の「はじめに」で書いた言葉です。
今の会社に入社したとき、私の尊敬するコンサルタントから教えていただきました。
企業を経営していると多くの人のさまざまな夢に出会います。個々人の夢と企業の夢がピッタリ一致することは稀ですが、2つの夢を重ね合わせて仕事ができれば、個々人にとって幸せです。
製造引当の場合、受注時点で部品・材料の未来日付の在庫を引当しなければなりません。商品から部品・材料の所要量を算出するためには、BOM(Bill Of Materials:部品構成表)が必要です。
「200日先の未来日付在庫を引当てる」ということを前回話しました。
ここでの引当対象は出来上がった商品在庫です。
注文を受け付けた時点で、在庫場所に存在する商品をその顧客のために確保することを引当と言います。通常は引当済みの数や未引当の数を管理します。データモデルとしては
[商品コード.倉庫コード]−(在庫商品数、引当済商品数、未引当商品数)となります。
この場合、時間軸は現時点を表しています。
在庫エンティティは、[商品コード.倉庫コード]−(商品数)となります。
通常、倉庫コードは実在する倉庫を表しますが、たまに実在する倉庫を表さない値のときがあります。これがダミー倉庫です。