ITアーキテクト黒澤の日記2008年分

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

標準化は1:9で推進せよ

2008/12/22

システム開発方法論やデータの標準化に成功した企業は沢山あります。正確に言えば、一時期成功したと思えるような成果が出た企業が沢山あり、その後、オープン化やWeb化の波にのまれて元に戻ってしまった企業も沢山あり、さらにもう一度チャレンジして標準化し直した企業も沢山あります。

『標準化は1:9で推進せよ』の続きを読む・・・


実世界の写像

2008/12/17

実世界には「もの」があり「こと」がありますが、我々はこれらを正確にモデル図に写像できているわけではありません。必ず、「人が認識する“もの”」、「人が認識する“こと”」の表現になってしまいます。その意味で、ビジネス世界のモデル化の対象とモデル図に表われる対象は、ピッタリと一致するわけではありません。

『実世界の写像』の続きを読む・・・


標準を強要される側の気持ち

2008/12/04

情報システムの開発プロジェクトにおいて、標準を強要される側になった人々の言葉をいくつか紹介します。

『標準を強要される側の気持ち』の続きを読む・・・


標準化の壁を越えよ

2008/12/03

業界全体ではなく、企業内でシステム開発方法論などを標準化する場合、さまざまな障害があります。
標準化に成功している企業は、最初に遭遇する壁を上手に乗り越えています。
最初の壁とは、標準化された作業手順・成果物を適用すべき最初のプロジェクトで、「策定された標準を使わない」という壁です。

『標準化の壁を越えよ』の続きを読む・・・


標準を大切にする心 

2008/12/02

先日、あるコンサルタントと話していたとき、こんなことを言われました。

『標準を大切にする心 』の続きを読む・・・


ものたち、出来事たちのモデリング

2008/11/27

「もの」や「出来事」のモデリングは、個々バラバラの存在だったインスタンスをタイプ化することです。たとえば、鈴木一郎、佐藤次郎、山田三郎という3つのインスタンスに「顧客」というタイプ化した名を与える行為です。
しかし、ビジネスの世界では、別なタイプ化も必要とされます。

『ものたち、出来事たちのモデリング』の続きを読む・・・


「出来事」であり「もの」でもある認識

2008/11/26

現実の世界に、それ自身独立して、確固たる存在としての「出来事」や「もの」があるのでしょうか。
認識は主体と客体の関係性によって決まります。そして、同じ主体、同じ客体であっても、見る視点が変われば、異なった様相として認識することがあるのです。
今回は、対象を「もの」と「出来事」に、明確に区別できることもあるができないこともある、というお話です。

『「出来事」であり「もの」でもある認識』の続きを読む・・・


もう1つの相互依存

2008/11/25

「もの」と「出来事」は相互依存の関係にあり、その2つを同時に決めているのは、モデリングのコンテクストである「場」です。
それでは、その「場」を決めているのは誰なのでしょうか?
それは、モデリングの主体、すなわち企業です。モデラーが勝手に「場」を決めるわけにはいきません。

『もう1つの相互依存』の続きを読む・・・


「もの」と「出来事」を決めるのは?

2008/11/20

「もの」と「出来事」が相互依存の関係にあるとして、依存する相手が無制限に拡がったのでは、モデリングが不可能になります。

『「もの」と「出来事」を決めるのは?』の続きを読む・・・


「もの」と「出来事」の相互依存

2008/11/19

「もの」は、それ自身では意味をなさない。つまり、「もの」のインスタンスに対してタイプ化した意味を表そうとしたとたん、「もの」は「出来事」との関わりを意識した「名」を必要とします。「もの」は「出来事」と無関係に存在するのではなく、「出来事」との関係において意味づけられるのです。

『「もの」と「出来事」の相互依存』の続きを読む・・・


「もの」よりも先に「出来事」を認識する

2008/11/18

ビジネスの世界では、契約すなわち「約束事」があって、それに基づき「物やサービスの提供」「対価の受取」が発生します。取引を行う当事者間で、あらかじめ決めておいた順序で「出来事」が発生します。契約が無い場合であっても、取引者の一方が提示した取引方法や商法で決められたルールがあって、その範囲で「出来事」が発生します。

『「もの」よりも先に「出来事」を認識する』の続きを読む・・・


「出来事」よりも先に「もの」を認識する

2008/11/13

「もの」中心の概念データモデリングでは、「出来事」よりも先に「もの」を認識します。「ものを最初に認識する方が簡単である」という主張は、前提となる条件があれば正しいでしょう。しかし、その条件を理解することなく、単純に受けいれることはできません。

『「出来事」よりも先に「もの」を認識する』の続きを読む・・・


「もの」中心の概念データモデリング

2008/11/11

「もの」は「出来事」と違って認識しやすい。従って、「もの」を先に認識し、その後「もの」の状態を変化させる「出来事」を認識すると良い。
そのようにアプローチする概念データモデリングが存在します。

『「もの」中心の概念データモデリング』の続きを読む・・・


グループCIO会議

2008/10/23

グループCIOが集まる勉強会に参加しました。
参加者のほとんどは情報システム子会社の社長さんです。
テーマはグループ企業のITガバナンスと情報システム子会社のミッションです。

『グループCIO会議』の続きを読む・・・


経営者は情報システム部門をどうしたい?

2008/10/21

経営者は情報システム部門をどうしたいのでしょうか?
ユーザ企業にとって、情報システム部門は間接部門です。したがって、コストダウンすることが情報システム部門の使命の1つであると思います。でも、それだけでしょうか。

『経営者は情報システム部門をどうしたい?』の続きを読む・・・


ビューマネジャー

2008/10/14

データベースやフラットファイルにアクセスする機能をもち、業務アプリケーションに対して実装独立のインタフェースを提供するプログラムをビューマネジャーと呼びます。(ビューマネジャーは一般用語ではありませんので悪しからず。)

『ビューマネジャー』の続きを読む・・・


業務設計の4工程4

2008/10/08

課題設定の工程は、達成すべき効果や到達したい姿をイメージしながら、新業務で実施すべきことを明確にします。新規設計の工程ではありませんので、詳らかに仕事の内容を定義する必要はありません。新しい業務では「○○すべき」という業務改善の中核を定義します。

『業務設計の4工程4』の続きを読む・・・


システム構造の可視化とは

2008/10/07

「既存システムがブラックボックスになって困っている」
システム再構築や保守の段階で良く聞く話です。
最近エンタープライズアーキテクチャの仕事が増えていますが、Asisモデルの作成時にも同様の声を聞きます。

『システム構造の可視化とは』の続きを読む・・・


何ら批判される理由のない人からの批判

2008/10/01

ある人が「自分が使っている概念データモデルはビジネスを表したもので、自動生成をねらうDOAはビジネスを表していない」と言います。骨格であろうと、ソフトウェアを生成できるほど詳細であろうと、実装独立にビジネスを表現している点は変わらないのに、その事実を知らずに批判します。

『何ら批判される理由のない人からの批判』の続きを読む・・・


業務設計の4工程3

2008/09/30

「現状分析がなぜ必要か?」
業務設計の4工程で紹介した、基本どおりの作業展開を提案すると、ユーザやシステム担当者の中には「現状分析工程を飛ばして、課題設定や新規設計からスタートすれば良い」と言う人たちがいます。

『業務設計の4工程3』の続きを読む・・・


業務設計の4工程2

2008/09/29

業務設計で2番目の工程が現状分析です。現状分析を簡潔に表現すれば「現状の業務を可視化し、問題点や課題を共有すること」です。業務機能の分解図や業務フロー図、概念データモデル図などを作成します。もちろん、問題点や課題の一覧表も重要です。

『業務設計の4工程2』の続きを読む・・・


業務設計の4工程

2008/09/24

システム再構築や比較的大きな保守において、業務設計工程は次の4つから構成されます。その4つとは、「目的・ねらいの設定」「現状分析」「課題設定」「新規設計」です。今日は、そのうちの「目的・ねらいの設定」について話します。

『業務設計の4工程』の続きを読む・・・


データモデルはユーザがレビュするものではない?

2008/09/18

ある会社のシステム開発方法論を作成していたとき「データモデルを現状分析工程の成果物にして、ユーザにレビュしてもらおう」とある人が言いました。すると、別な人が「データモデルはシステム内部の構造を記述しているのだから、ユーザがレビュするような性質のものではない」と反論します。さて、どちらが正解なのでしょう?

『データモデルはユーザがレビュするものではない?』の続きを読む・・・


意味の等しい2つの正規化3

2008/09/17

在庫エンティティが見つかる画面や帳票を複数分析すると、次のような3種類のエンティティを認識することがあります。

『意味の等しい2つの正規化3』の続きを読む・・・


意味の等しい2つの正規化2

2008/09/16

先日、ご紹介した2つの事例ですが、厳密には同じ性質のものではありません。

『意味の等しい2つの正規化2』の続きを読む・・・


要約エンティティの件数

2008/09/12

A[受注番号]−(部署コード.商品コード.受注数.受注年月日・・・・・)というイベントエンティティのサマリー、つまり要約エンティティを考えてみます。
たとえばB[部署コード.商品コード.受注年月]−(受注合計数)です。

『要約エンティティの件数』の続きを読む・・・


意味の等しい2つの正規化

2008/09/11

数量データを扱っていると、意味の等しい2つの正規化に出会うことがあります。
たとえば、次のように。
A:[社員コード.給与支払年月]−(給与額)
B:[社員コード.給与支払年]−(1月給与額、2月給与額、・・・・、12月給与額)

『意味の等しい2つの正規化』の続きを読む・・・


加工データの種類

2008/09/10

加工データはその加工方法によっていくつかに分類できます。
たとえば四則演算、集合演算、JOINコピーなどです。

『加工データの種類』の続きを読む・・・


「データ中心のEA」執筆の動機

2008/09/09

「データ中心のエンタープライズアーキテクチャ」を執筆するきっかけは何ですか?と多くの人から質問されます。
私の場合、いつかは共著ではなく単独で本を執筆したいと思っていました。ですから正確に言えば、「なぜ今書くことにしたか」に応えることになります。

『「データ中心のEA」執筆の動機』の続きを読む・・・


加工式もエンティティである? 

2008/09/04

15年以上も前になりますが、「エンティティとは何か」を議論したことがあります。そのときの話を紹介します。

『加工式もエンティティである? 』の続きを読む・・・


データ構造

2008/09/03

概念データモデルで扱うデータ構造とは何か。
一言で表現すると「データ項目とデータ項目の関係」です。
ただし、業務的になんらかの意味が対応することが条件です。
データ項目とデータ項目の関係をもう少し細かくみると、次の関係が見つかります。

『データ構造』の続きを読む・・・


経営者の気構え

2008/09/02

私が経営者として尊敬する…

『経営者の気構え』の続きを読む・・・


アプリデータとメタデータ

2008/09/01

販売物流や会計などの概念データモデルを作成したとき、そこに表われるデータ項目は一般の業務で使われるものですから、アプリケーションのデータです。ここでは省略してアプリデータと呼びます。一方で、システム開発そのものを1つの業務領域と考えて概念データモデルを作成した場合、そこに表われるデータ項目はメタデータです。メタデータはアプリデータを説明するためのデータと言うこともできます。たとえば、データ項目番号、データ項目名、桁、定義域番号などです。

『アプリデータとメタデータ』の続きを読む・・・


選択された言葉が実世界の認識を決める

2008/08/22

今日は、ちょっとした遊びの話から。
競馬ではパドック(競争前の下見場)を回る馬たちを解説者が評価します。たとえば、こんな風に。

『選択された言葉が実世界の認識を決める』の続きを読む・・・


EAとDCA

2008/08/21

エンタープライズアーキテクチャに関する話題を日記で書いてほしいという要望がありました。
実は、EAの仕事が最近多くなり、リアルタイムでご支援するお客様もあるため、日記に書くことは避けていました。しかし、頻繁に遭遇する課題やよくある質問を話題にするのは問題ないと思います。

『EAとDCA』の続きを読む・・・


データ管理 番号派・名称派

2008/08/20

データディクショナリあるいはリポジトリを使ってデータ項目を管理する場合、メタモデル上ではこれらを識別するメタデータが必要になります。
データ項目を識別するメタデータは、データ項目番号またはデータ項目名です。
番号であっても名称であっても管理する対象が識別できれば良いわけですが、「番号派」と「名称派」それぞれに好みやこだわりがあるようです。

『データ管理 番号派・名称派』の続きを読む・・・


取引パターン(データモデルパターンの紹介)

2008/08/19

前回お話した伝票型の画面や帳票の中には、ヘッダ・明細の形になっているものが多く見つかります。たとえば、受注伝票は受注ヘッダと受注明細から出来ています。この種の画面や帳票を素材に作成した概念データモデルはすべて同じ型をしています。すなわちヘッダエンティティと明細エンティティの構造です。これを取引パターンと呼びます。

『取引パターン(データモデルパターンの紹介)』の続きを読む・・・


画面・帳票のパターン

2008/08/07

概念データモデリングの素材として、ユーザが実際に使っている画面や帳票を使うことがあります。
多くのモデリング経験から画面・帳票は3つのパターンに分類できることが知られています。

『画面・帳票のパターン』の続きを読む・・・


要約・断面エンティティのKEY

2008/08/06

要約エンティティは、月別の販売合計数・日別の販売合計金額などのフローデータを従属データにもつエンティティです。
KEYのなかに、合計対象の期間を表す年・半期・年月・年月日などのデータ項目が含まれます。

『要約・断面エンティティのKEY』の続きを読む・・・


KEYとコンテクスト

2008/08/05

KEYは、データとして管理する対象を識別する記号ですから、コンテクストを背負っています。

『KEYとコンテクスト』の続きを読む・・・


データ項目名とコンテクスト

2008/08/01

受注エンティティのデータ項目名を考えてみます。

『データ項目名とコンテクスト』の続きを読む・・・


データ項目の命名ルール

2008/07/31

顧客エンティティのSタイプのKEY名は、顧客コードとなります。この名称を分解すると
顧客コード=「顧客」+「コード」となります。

『データ項目の命名ルール』の続きを読む・・・


エンティティ名とKEY名

2008/07/30

顧客エンティティのSタイプのKEY名は、顧客コードとなります。
社員エンティティのSタイプのKEY名は、社員コードとなります。
受注エンティティのSタイプのKEY名は、受注番号となります。

『エンティティ名とKEY名』の続きを読む・・・


Sタイプ・RSタイプ・RRタイプ

2008/07/29

KEYの形式を別な観点で分類してみます。
Sタイプ:発番対象のエンティティめがけて発番するKEYの形式です。「連番」だけでKEYを構成します。SタイプのSは、シーケンシャルの略。
例)顧客コード、社員コード、受注番号

『Sタイプ・RSタイプ・RRタイプ』の続きを読む・・・


連番のあるKEYと無いKEY

2008/07/22

KEYの一般形は[発番範囲.発番期間.連番]ですが、連番が入る場合とそうでない場合があります。
 請求エンティティa [顧客コード.請求年月]
 請求エンティティb [請求番号]

『連番のあるKEYと無いKEY』の続きを読む・・・


KEYの一般形

2008/07/17

エンティティを識別するKEYは、エンティティと等価の意味をもっています。概念データモデルを深く理解するためには、KEYに関してもいろいろな角度から考察しておくと良いでしょう。そこで、今日はKEYの一般形を紹介します。

『KEYの一般形』の続きを読む・・・


一物一コード

2008/07/16

個別業務領域を越えて、広い範囲でコードを統一する企業が増えています。一部上場企業のほとんどが、なんらかのコード統一課題を抱えていると言っても過言ではありません。

『一物一コード』の続きを読む・・・


一般解と特殊解

2008/07/15

ERPパッケージは、一般的な業務構造および一般的な実装手段を提供しています。私の言葉で言えば、実装独立の仕様も実装従属の仕様も一般解を提供するソリューションです。

『一般解と特殊解』の続きを読む・・・


インフォメーションバリューチェーン

2008/07/09

「人とツールと方法論とコンテンツ」の完結編です。

『インフォメーションバリューチェーン』の続きを読む・・・


もう1つのプロダクトライン

2008/07/08

人とツールと方法論とコンテンツを組み合わせた結果、業務アプリケーションを効率良く製造するしくみが出来上がります。一種のプロダクトラインです。

『もう1つのプロダクトライン』の続きを読む・・・


人とツールと方法論とコンテンツ

2008/07/03

理想的なシステム開発・保守の環境として「人とツールと方法論」を話してきましたが、もう1つ重要なことを追加しておきます。

『人とツールと方法論とコンテンツ』の続きを読む・・・


人とツールと方法論3

2008/07/02

人とツールと方法論のシナジー効果を出すためには充分な準備が必要です。

『人とツールと方法論3』の続きを読む・・・


人とツールと方法論2

2008/07/01

人とツールと方法論のシナジー効果は、一朝一夕に得られません。
充分な準備が必要です。

『人とツールと方法論2』の続きを読む・・・


人とツールと方法論

2008/06/25

理想的なシステム開発・保守の環境とは「人とツールと方法論」の3つがバランスよく組み合わされた環境です。

『人とツールと方法論』の続きを読む・・・


Whatだけを相手にしたい 

2008/06/24

前回お話したデータ共用のアーキテクチャのうち、概念データオープンアーキテクチャを採用した場合、各オブジェクトは標準化された概念データ項目を自由に利用できます。

『Whatだけを相手にしたい 』の続きを読む・・・


2種類のデータ共用アーキテクチャ

2008/06/18

データ共用のアーキテクチャについて、次の2つを考えて見ます。

『2種類のデータ共用アーキテクチャ』の続きを読む・・・


認識の経済学2

2008/05/27

企業が社員の結婚を捉える際に、認識の経済学が働きます。
企業の管理目的を気にしなければ、結婚のエンティティ構成は次のようになります。

『認識の経済学2』の続きを読む・・・


認識の経済学 

2008/05/23

ピュアなエンティティを切り出す仕事、すなわち概念データモデリングの仕事をしていると、ビジネスに携わる人々が、いかに手抜きをして実世界を認識しているかがわかります。

『認識の経済学 』の続きを読む・・・


設計思想を表すことばを共有しよう

2008/05/22

 「One fact in one place=1つの事実を一箇所に」
 「One fact to all users=1つの事実を利用者全員に」
この2つは、データ設計上の基本的な考え方を表現したことばです。

『設計思想を表すことばを共有しよう』の続きを読む・・・


社長としての修行

2008/05/14

ある人から「会社がどうあるべきか、これを見て勉強しなさい」と言われ、「NHKスペシャル井深大が語る本田宗一郎」のDVDを渡されました。

『社長としての修行』の続きを読む・・・


正規化絶対反対?

2008/05/13

私がデータ総研に入社したころは、リレーショナルデータベースが市場に出始めた時期です。当時、データの正規化はリレーショナルデータベースを使うために必要な設計技法と言われていました。
しかし、実際のところ、パフォーマンスが出ずに正規化したデータ構造は使えませんでした。

『正規化絶対反対?』の続きを読む・・・


情報システムの強度

2008/05/09

DRI通信(113号)「情報システムは有機体」の中に「情報システムの強度」の一節があります。

『情報システムの強度』の続きを読む・・・


すべてが時間の中にある

2008/05/08

製造業の製品設計工程を支援する業務アプリケーションでは、部品構成表を扱います。設計のバージョンが上がるたびに、製品を構成する部品の多くが入れ替わり、変更履歴を残すのは大変です。2つのバージョンを比較しても、共通部品がほんの少ししかないこともあります。しかも、非常に短い時間の中でこれらの変更が発生します。

『すべてが時間の中にある』の続きを読む・・・


統合・分割の履歴エンティティ

2008/05/02

一般に、履歴エンティティは、履歴を残す対象(インスタンス)が安定的で、その従属項目値の変化を時系列に保持するものです。社員エンティティに対する社員異動エンティティは、履歴エンティティの典型的な例です。

『統合・分割の履歴エンティティ』の続きを読む・・・


時間軸を考慮した正規化

2008/05/01

一般に、正規化するとデータ項目は1つのエンティティに従属します。
しかし、時間の経過を考慮すると、そのデータ項目が複数の値をもつこともありえます。

『時間軸を考慮した正規化』の続きを読む・・・


履歴エンティティ 

2008/04/30

取引先、組織、商品、契約などの主要なエンティティには、変更内容を時系列に保持する履歴エンティティが存在します。

『履歴エンティティ 』の続きを読む・・・


概念モデルと概要モデル

2008/04/24

概念モデルを概要モデルと勘違いしている人がいます。たまに、会話が成立しないため困ります。
“概要モデル=「粒度があらい」「緻密でなくても良い」モデル”なのですが、“概念モデル”も同様にとらえる方がいるのですね。

『概念モデルと概要モデル』の続きを読む・・・


エンティティとインタフェース

2008/04/23

概念データモデリングの結果、実世界の「もの・こと」に対応したエンティティが洗い出されます。
その後工程で、エンティティは論理ファイルとして実装されます。
論理ファイルを設計する段階では、エンティティは、データを蓄積する対象としてとらえられます。

『エンティティとインタフェース』の続きを読む・・・


何をするのが幸せか

2008/04/22

私の娘が「将来何をすればよいか迷っている」とつぶやきました。

『何をするのが幸せか』の続きを読む・・・


値を見て正規化する

2008/04/17

正規化の形として第一正規形・第二正規形・第三正規形・コッド正規形などが有名です。
しかし、正規化のプロセスに関しては、あまり良い作法が語られていません。

『値を見て正規化する』の続きを読む・・・


自己変革と関係

2008/04/16

自分自身の中に自分自身を変えるためのエネルギーを創り出すのは難しいことです。

『自己変革と関係』の続きを読む・・・


イベントエンティティと業務改善

2008/03/26

イベントエンティティとイベントエンティティの関係は、1:1、1:n、n:1、分解集約型n:m、集約分解型n:mの5パターンがあります。

『イベントエンティティと業務改善』の続きを読む・・・


インタフェースデータ

2008/03/25

人と人あるいは仕事と仕事のインタフェースデータは画面や帳票に表われます。

『インタフェースデータ』の続きを読む・・・


体・技・心

2008/03/13

あるスポーツ選手のインタビュを聞いていたときです。「スポーツは心技体と言うでしょ。でもほんとうは体技心だと思うんです」とコメントしていました。

『体・技・心』の続きを読む・・・


モデリングと問題解決

2008/03/12

モデル図が問題解決に貢献することがあります。

『モデリングと問題解決』の続きを読む・・・


モデリングとコミュニケーションの関係

2008/03/11

自然言語を使う場合と比較して、モデル図は「対象」と「対象」の関係を表現するのに適しています。
そしてモデリングは、表現された「対象」に適切な言葉を割り当てる作業です。
言葉の意味は相対的ですから、言葉の意味を構造的に理解するためにはモデル図が適していると思います。

『モデリングとコミュニケーションの関係』の続きを読む・・・


業務設計がなぜできない?

2008/03/06

画面の紙芝居をいくら作成しても、新規業務の内容を詰めることはできません。
画面や帳票の数が300程度以上の規模で、紙芝居アプローチをとって失敗するプロジェクトが多いようです。

『業務設計がなぜできない?』の続きを読む・・・


景色が一変する言葉

2008/03/05

先日、テレビの番組でこんなコメントを聞きました。

『景色が一変する言葉』の続きを読む・・・


相似形に着眼せよ

2008/03/04

今日は、概念データモデリングの奥義を1つ紹介します。
PLAN-DBは、エンティティの配置を非常に大切にします。概念データモデル全体の中で、位置が意味を表しレビュの品質を上げるからです。

『相似形に着眼せよ』の続きを読む・・・


RDB使うからデータモデリング?

2008/02/28

「RDBを使うからデータモデリングするんでしょ!」そう言うシステムエンジニアが多いようです。
オブジェクト指向で概念モデルを知っているはずの人でさえ「RDBを使うからUMLでなくてもERモデルでOK」などと言うのです。

『RDB使うからデータモデリング?』の続きを読む・・・


在庫編: 在庫はイベントをつなぐ間接部品

2008/02/27

新しいデータモデルテンプレートを考えているとき、イベントエンティティとイベントエンティティの関係にいくつかのパターンがあることに気づきました。

『在庫編: 在庫はイベントをつなぐ間接部品』の続きを読む・・・


データモデリングは師匠から教えてもらおう

2008/02/26

良いたとえかどうか自信がないのですが、将棋のプロを目指すとします。
3級の人が3級の人と将棋を打っても、それほど上達しません。本で棋譜を覚えても、自力で5段になるのは難しいでしょう。大抵は誰かの弟子になるか、そうでなければ5段以上の人と頻繁に将棋を打てる環境が必要です。

『データモデリングは師匠から教えてもらおう』の続きを読む・・・


心は形をもとめ、形は心をもとめる

2008/02/25

「心は形をもとめ、形は心をもとめる」は、拙著「データ中心のエンタープライズアーキテクチャ」の「はじめに」で書いた言葉です。
今の会社に入社したとき、私の尊敬するコンサルタントから教えていただきました。

『心は形をもとめ、形は心をもとめる』の続きを読む・・・


夢と使命

2008/02/20

企業を経営していると多くの人のさまざまな夢に出会います。個々人の夢と企業の夢がピッタリ一致することは稀ですが、2つの夢を重ね合わせて仕事ができれば、個々人にとって幸せです。

『夢と使命』の続きを読む・・・


在庫編: 製造引当とBOM

2008/02/19

製造引当の場合、受注時点で部品・材料の未来日付の在庫を引当しなければなりません。商品から部品・材料の所要量を算出するためには、BOM(Bill Of Materials:部品構成表)が必要です。

『在庫編: 製造引当とBOM』の続きを読む・・・


概念データ構造はDNA

2008/02/13

概念データ構造は、ITに依存せず、業務のあり方に依存します。

『概念データ構造はDNA』の続きを読む・・・


在庫編: 在庫引当と製造引当

2008/01/31

「200日先の未来日付在庫を引当てる」ということを前回話しました。
ここでの引当対象は出来上がった商品在庫です。

『在庫編: 在庫引当と製造引当』の続きを読む・・・


在庫編: 時間軸を考慮した在庫

2008/01/22

注文を受け付けた時点で、在庫場所に存在する商品をその顧客のために確保することを引当と言います。通常は引当済みの数や未引当の数を管理します。データモデルとしては
[商品コード.倉庫コード]−(在庫商品数、引当済商品数、未引当商品数)となります。
この場合、時間軸は現時点を表しています。

『在庫編: 時間軸を考慮した在庫』の続きを読む・・・


在庫編: ダミー倉庫

2008/01/16

在庫エンティティは、[商品コード.倉庫コード]−(商品数)となります。
通常、倉庫コードは実在する倉庫を表しますが、たまに実在する倉庫を表さない値のときがあります。これがダミー倉庫です。

『在庫編: ダミー倉庫』の続きを読む・・・


在庫

2008/01/08

在庫エンティティや在庫パターンに関しては語るべきことが多くあります。

『在庫』の続きを読む・・・