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