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

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

ロングトランザクション

2009/12/24

Webサービスが登場した頃から、ロングトランザクションの問題が話題になっていました。
たとえば、こんな風に…
『ロングトランザクション』の続きを読む・・・


日本の製造業が強い理由

2009/12/16

ある人と日本の製造業が強い理由を議論していたときに、おもしろい仮説を聞いたのでご紹介します。
『日本の製造業が強い理由』の続きを読む・・・


Data centric platform 

2009/12/09

Paasが普及して、コンピューティングパワーがユーティリティ化した時代は、どのような情報システムアーキテクチャになるのだろうか。
どこまでもデータ中心アーキテクチャにこだわって考えてみる。
『Data centric platform 』の続きを読む・・・


認識とは選択であるⅢ

2009/12/02

あらかじめ自分が持っていた信念や価値観が、実世界を認識する際の選択基準になり、無意識のうちにそれらを検証・追体験するように、実世界を認識します。
『認識とは選択であるⅢ』の続きを読む・・・


DMBOK

2009/11/24

データモデリングやデータマネジメントのプロ仲間ではすでにご存知の方が多いと思いますが、一般の情報システム部門・システムエンジニアはどうでしょうか?
今日はDMBOKの話です。
『DMBOK』の続きを読む・・・


認識とは選択であるⅡ

2009/11/18

DB研を例に「認識とは選択である」を掘り下げます。
DB研とは、T氏が行っているデータベース研究会の通称です。データ総研が創立してから毎年1回実施していますから、もう20回を超えています。その年1年間のトレンドを紹介するセミナーですが、T氏は膨大な量の雑誌から特徴的な記事を見つけて紹介します。(とても好評で、私も大好きなセミナーの1つです)
『認識とは選択であるⅡ』の続きを読む・・・


認識とは選択である

2009/11/11

「今までにない画期的なシステム開発環境を創ろう」として活動していたプロジェクトでの出来事です。
『認識とは選択である』の続きを読む・・・


内製率を上げるⅡ 

2009/11/04

私たちのデータ中心アプローチでは、業務仕様と実装仕様をきちんと区別して設計工程を進めます。
たとえば、受注画面の定義。
『内製率を上げるⅡ 』の続きを読む・・・


内製率を上げる

2009/10/23

ユーザ企業が情報システムを構築する際に、最初の工程から一括発注することもあるでしょう。また、製造工程以降(場合によっては詳細設計工程以降)の工程を発注することもあるでしょう。もちろん、外に発注しないこともあるでしょう。その場合は内部の人間が構築することになります。
製造工程以降の仕事を自社の人間が実施している割合を、ここでは内製率と呼ぶこととします。
『内製率を上げる』の続きを読む・・・


なぜデータ中心で考えるか

2009/10/16

以前、DOA-RAD For XupperⅡのセミナを開催しました。
キリングループ様で標準採用された方法論(DOA-RAD)とツール(XupperⅡおよびソフトウェア自動生成機能をもつMDFrame/X)の事例紹介です。方法論もツールもDOAの考えに立脚しているので、「なぜデータ中心で考えるか」を説明しました。
その内容を紹介します。
『なぜデータ中心で考えるか』の続きを読む・・・


PaaS(Platform as a Service)

2009/10/09

先日同じ日に、衝撃を受ける話を続けて2回聞きました。どちらも共通のキーワードは、PaaSです。
そこで、今日はPaaSの利用法について少し極端な例を考えてみます。
『PaaS(Platform as a Service)』の続きを読む・・・


世間話が多くなった?!

2009/10/02

情報戦略立案、情報システム企画、フィージビリティスタディ、RFP作成など、上流工程で「世間話」を聞くことが多くなりました。
もちろん、ここでいう「世間話」は、一般的な世間話ではありません。選ぶ言葉や作法が洗練されていないため世間話のように感じる会話のことです。
『世間話が多くなった?!』の続きを読む・・・


見える化の“デメリット”は?

2009/09/25

「見える化のデメリットは?」
これも、前回と同様、以前、ストラテジックアーキテクトフォーラムのHagiさんのラウンドテーブルで出された質問です。
『見える化の“デメリット”は?』の続きを読む・・・


見える化の“メリット”は?

2009/09/18

「見える化のメリットは?」
これは、以前、ストラテジックアーキテクトフォーラムのHagiさんのラウンドテーブルで出された質問です。5分で応えなければならなかったので、普段から思っていることが反射的に出てしまいます。
『見える化の“メリット”は?』の続きを読む・・・


ERPのデータ設計

2009/09/11

「ERPはパッケージだからデータモデリングなんてしないよね!」
「ERPはパッケージだからデータ設計はいらないよね!」
なんて話を良く聞きます。これは大きな間違いです。
『ERPのデータ設計』の続きを読む・・・


IT業界の生産性

2009/09/02

某SIベンダーの社長さんとお話したときにこんなことを言っていました。
『IT業界の生産性』の続きを読む・・・


エンタープライズアーキテクト推薦図書

2009/08/26

「ITアーキテクトがビジネスセンスや経営を学ぶためにどのような本を読めばよいでしょうか?3冊推薦してください」という依頼が某雑誌編集部から来ました。
私は、特にエンタープライズアーキテクト向けの本を推薦しました。

1 これから何が起こるのか(著者:田坂広志)
ビジネスの世界で起きてきたこと、これから起きることを考察しています。いままでの自分にはない、新しい着眼点を見つけられることでしょう。

2 稲盛和夫の実学(著者:稲盛和夫)
会計の視点から経営をみることを学べます。業務実態と数値が一致していることの重要性を再認識するでしょう。

3 打つ手は無限(著者:牟田學)
エンタープライズアーキテクトになるのであれば、社長と同じ土俵で物事を考察しなければなりません。社長が事業をどのように捉えるべきか、企業哲学の一端を学べます。

番外
四番目にあげるとすれば、この本を紹介します。
4 イノベーションの作法(著者:野中郁次郎,勝見 明)
企業変革の理論は本で学べますが、本当の成功要因はやはり人でしょう。成功事例を紹介しながら、その本質を解き明かしています。


見える化

2009/08/19

SCMの業務改善で次のようなことが語られます。
サプライチェーンを構成する各拠点で在庫を見える化し、欠品や過剰在庫を防ぐことによって、スループットを向上させよう・・・・。
ここで言う在庫の見える化は、「情報共有」を意味します。
『見える化』の続きを読む・・・


大規模で複雑な場合どうします?

2009/08/11

以前、次のような、ちょっと長いタイトルのセミナーで講演しました。
東京大学21世紀COEプログラム「先進国における《政策システム》の創出」
参加者は70名~80名程度だったと思います。
大学院の学生、教授、政府関係者、CIO補佐官が参加しました。

私は、「連結企業における情報システム最適化~情報統合から見える業務改革~」というテーマで話しました。プレゼンの後、大学の教授お二人・東レの情報システム部門長・私の4人でパネルディスカッションをしました。

表題の記述は、パネルディスカッションの最後に、受講者から受けた質問です。
民間の事例はそれなりに成功しているかもしれないが、政府のIT政策にそれを当てはめるとどうか?政府の情報システムは民間よりもずっと大規模で複雑なので、同じように考えられるのか?そういったことが気になって質問されたと思っています。

そのとき、私は次のように答えました。
「大規模で複雑なものを扱う場合には、人間が理解できる大きさに切ることです。ただし、やみくもに切ってもだめです。情報システムは安定的な部分と不安定な部分で構成されています。不変の部分はありません。すべての部分がなんらかの理由で変化します。変化のスピードは一様ではありません。速い部分と遅い部分が存在します。変化が何によってもたらされるか、その理由も含めて変化のスピードが異なる境界線を見極め、「切る」ことです。
もう1つの重要な視点は、「共通」「個別」です。ここでも「切る」ことができます。「共通」になる部分は、統制し標準化しスリム化の対象になります。「個別」の部分は逆に他の部分から独立させ、自由度を持たせます。
いずれにしても、対象を切って管理するためにはアーキテクチャが重要です。」
こんな感じだったかな・・・・。

やっぱりアーキテクチャは重要ですね。
そして「切れ目」を見つける視点が、アーキテクチャの良し悪しを決めてしまうのです。


「きびしい でも 暖かい」そんな企業

2009/08/05

雇用情勢が厳しい現在に通じる話です。私の記憶では、EAの本を執筆中だったのでおそらく2003年ごろのことですが、グループ企業の人事政策に違和感を覚えておりました。
『「きびしい でも 暖かい」そんな企業』の続きを読む・・・


データモデルパターンの提供 

2009/07/30

データ総研では、2001年4月よりデータモデルパターンを提供するビジネスを始めています。
おそらく日本では最初だと思っています。
『データモデルパターンの提供 』の続きを読む・・・


リバースエンジニアリング

2009/07/21

近年、基幹系システムの開発は、ほとんどが再構築です。再構築が抱える悩みの1つは、そのコストパフォーマンスでしょう。
『リバースエンジニアリング』の続きを読む・・・


人間リポジトリの威力

2009/07/15

最近、ある事例を研究して、非常にショックを受けています。
その事例は、各業務アプリケーションが属人化し、他人に引き継げない状況になっていました。このような状況の場合、「業務仕様やソフトウェア仕様を人間リポジトリから工学的リポジトリに乗せ替えましょう。」と指導するのが一般的です。
『人間リポジトリの威力』の続きを読む・・・


物流と商流[3]

2009/06/30

物流種別と商流種別をきちんと区別して設計していない問題について、もう少し深堀します。線(物流種別)で説明すると複雑になるので、なるべく、点(拠点)で説明を進めます。
『物流と商流[3]』の続きを読む・・・


物流と商流[2]

2009/06/17

(物流と商流の続きです。)
ここで商流と呼んでいるのは所有権の異動です。
所有権の異動を考える際、「企業間」における所有権の異動を捉えることは当然ですが、「組織間」における所有権の異動も捉える必要があります。
『物流と商流[2]』の続きを読む・・・


物流と商流

2009/06/08

今日は販売物流やSCMの業務設計時に使うノウハウの一端をご紹介します。
『物流と商流』の続きを読む・・・


コンサルティングとは何か?

2009/06/02

コンサルティングという仕事は、高尚なにおいがする一方で、どこか胡散臭いと思われることもあるようです。良いイメージと悪いイメージが混在しています。
『コンサルティングとは何か?』の続きを読む・・・


データ構造100年、Java20年

2009/05/28

以前、IT系会社の人たちが集まる会議に出席しました。その情報交換会である人がこう言いました。
「データ構造は100年もつから、一番ROIが良いよね。Java Java って騒いでいるかもしれないがせいぜいもって20年。やっぱりデータ構造は重要だね。もしかするとデータ構造は会社の寿命よりも長いかもしれないよ・・・」
『データ構造100年、Java20年』の続きを読む・・・


成功の反対

2009/05/19

「成功の反対は失敗」と思っている人が多いかもしれません。ある意味でこれは正解でした。
特に、高度成長時代で、普通に仕事してそれなりに結果が出た時代は・・・・・。
失敗しないこと、マイナス点がつかないこと、それが普通だったし出世の条件だったのかもしれません。
『成功の反対』の続きを読む・・・


メンテナビリティのパワー

2009/05/12

以前弊社の特別セミナー「システム資産の変化対応力が事業パフォーマンスを決める」において、4社ほどのユーザ企業が自社の事例を紹介してくれました。その中で感動した話を1つご紹介します。
『メンテナビリティのパワー』の続きを読む・・・


やっぱりモデラー 

2009/05/07

かつて、サッカーくじで6億円が当たったニュースを見て子供が話しかけてきました。
「6億円っていうと、仮に毎年1000万円使ったとしても60年遊んで暮らせるね。お父さん、働かなくても暮らせるようになったら何するの?」

私は、考える間もなく「やっぱりモデラー」
『やっぱりモデラー 』の続きを読む・・・


言葉を使った実世界の認識

2009/04/13

概念データモデル図はビジネス世界の物事の写像です。しかし、個々人が直接的に実世界を感じ、対象を表現したものではありません。個々人の直接的認識ではなく、業務に関わる多くの人が共通に与える言葉を通して、対象を表現したものです。ある意味では、間接的認識と言っても良いでしょう。

『言葉を使った実世界の認識』の続きを読む・・・


エンティティは機能である

2009/04/02

製造業における販売物流業務を例に、どのようなエンティティが列挙できるか、考えて見ます。

『エンティティは機能である』の続きを読む・・・


データ中心のプログラム単位

2009/03/27

今日は、プログラムの話です。
データ中心で業務アプリケーションの「プログラム単位=モジュール」を考えて見ます。
すでに何度か説明しているように、データ中心では、「データのあるところに処理がある」と考えます。
「データのあるところ」は、処理を行った結果の「データの組」を指します。そして、この「データの組」に対して処理をカプセル化して考え、1つのモジュールを導き出します。

『データ中心のプログラム単位』の続きを読む・・・


見えないものが観える

2009/03/24

それぞれの分野には、プロフェッショナルと呼ぶにふさわしい人物がいます。我々ITの世界も同様です。彼らは、普通の人が見えないものを看破し、問題点や課題を指摘します。才能があって偉大なプロになっている人もいるでしょうが、私は普段の心がけが彼らをそうさせていると思っています。

『見えないものが観える』の続きを読む・・・


静から動を読む

2009/03/20

住宅の見取り図は設計・施工のために必要な図面です。家を持ちたいと思っている人々と設計者・施工者を結びつける図面?言わばユーザ要件の定義書です。
建築関係者でない素人でも、少々の勉強で見取り図を読めるようになります。

『静から動を読む』の続きを読む・・・


BI・DWH・EDW

2009/03/17

BI(ビジネスインテリジェンス)とかDWH(データウェアハウス)とか、情報系のシステムを構築する案件が多くなってきました。
「データ統合の成熟度モデル」や「データマネジメントを専門とする組織を立ち上げるべき」など、さまざまなソリューションが提案されているようです。

『BI・DWH・EDW』の続きを読む・・・


Asis,Tobe,Canbeの正しさ[2]

2009/03/13

Asisモデル図、Tobeモデル図、Canbeモデル図を評価する視点をまとめておきましょう。

『Asis,Tobe,Canbeの正しさ[2]』の続きを読む・・・


Asis,Tobe,Canbeの正しさ[1]

2009/03/10

Asisモデル図、Tobeモデル図、Canbeモデル図は、その正しさを評価する視点が異なります。それらの視点を無視して図を作成してしまうと、とんでもないエンタープライズアーキテクチャになるので、注意が必要です。

『Asis,Tobe,Canbeの正しさ[1]』の続きを読む・・・


Asis,Tobe,Canbe

2009/03/06

エンタープライズアーキテクチャの話題になると、多くの場合Asisモデル図、Tobeモデル図が登場します。Asisモデル図はまさに現状を表現したモデル図であり、Tobeモデル図は将来を表現したモデル図です。

『Asis,Tobe,Canbe』の続きを読む・・・


統合した顧客IDの管理

2009/03/03

金融業や通信業において、顧客に販売した個々の商品を管理する単位は「契約エンティティ」でした。契約エンティティのKEY(識別子)は、証書番号や保険番号あるいは電話番号です。昔はこれらのIDがあれば、契約の管理のみならず契約者や支払者を管理するのも簡単でした。

『統合した顧客IDの管理』の続きを読む・・・


エンタープライズデータアーキテクチャの設計

2009/02/27

エンタープライズデータアーキテクチャに関する話題は、リアルタイムでご支援している企業もあることから避けていましたが、「たまには良いか・・・・。」と思い記述します。

『エンタープライズデータアーキテクチャの設計』の続きを読む・・・


となりの人が理解する業務 

2009/02/24

業務を可視化しその内容を共有することができるとしても、細かい内容を共有することには限界があります。実際の「業務=DO」をほんとうに知っているのは、担当している本人だけだからです。

『となりの人が理解する業務 』の続きを読む・・・


業務を可視化する[8]

2009/02/20

業務を可視化する、最後にご紹介する要素は「業務改善に必要な要素」です。
先日の日記では、業務の数を減らすことが業務改善の一種であることをご紹介しました。今回は、企業が一般的に考える業務改善の基礎的要素です。

『業務を可視化する[8]』の続きを読む・・・


業務を可視化する[7]

2009/02/17

要素の6つ目は「DOにかかわる5W2H」です。
我々は、言葉を使った認識法から逃れられません。つまり文の構成要素である「Why、What 、Who 、Where、When、How、How much」を「Do」とともに知ることができなければ、理解したとは言えないのです。

『業務を可視化する[7]』の続きを読む・・・


業務を可視化する[6]

2009/02/13

要素の5つ目は「もの(たとえば材料・商品)・サービスと金の流れ」です。
IPF(インフォメーションプロセスフロー)やBPMN(ビジネスプロセスモデリングノーテーション)など使って業務を記述したとき、もの・サービスと金の流れを明示することは大切です。もの・サービス・金のやりとりが、ビジネスそのものだからです。

『業務を可視化する[6]』の続きを読む・・・


業務を可視化する[5]

2009/02/10

要素の4つ目は、「トリガ(きっかけ)」です。
業務は一連の流れを持っていますが、それぞれの業務をどのようなきっかけで始めることになるのでしょう?
具体的な業務を想定してみます。

『業務を可視化する[5]』の続きを読む・・・


サイエンスと仏教哲学

2009/02/06

椿氏の「情報システムの構築にサイエンスを持ち込みたい」という思いはすばらしい。私も充分理解できますし、同意できるところが沢山あります。
しかし一方で、私自身は仏教哲学の影響を受けています。
(今回はいきなり哲学の話ですいません…)

『サイエンスと仏教哲学』の続きを読む・・・


椿氏の講演

2009/02/03

先日、久しぶりに椿氏の講演を聞きました。
いままでの集大成ということで、情報システムを捉える際の視点や今後に残された課題を話されました。椿氏とは20年近いつきあいですが、椿氏の考えを再度確認することができました。1つ1つの言葉に含蓄があり、中身の濃いプレゼンでした。
印象に残ったことを1つだけ紹介します。

『椿氏の講演』の続きを読む・・・


業務を可視化する[4]

2009/01/27

要素3は、「責任・権限」です。
大企業の新規業務設計をご支援していると、「社内での調整ごとや軋轢に対して、多くの人がそれを避ける行動をとりがちである」ことに気づきます。トラブル等、言い争いの場面では「君の言っていることは筋が通らない」といった発言もあるでしょう。「筋が通る」というのは、「本来やるべき仕事を責任部署が実施する。」「担当なのだからそれにふさわしい発言・行動を行う」ことを意味します。

『業務を可視化する[4]』の続きを読む・・・


業務を可視化する[3]

2009/01/23

前回は、要素2=「業務間の関係あるいは構造」の中で、
直線的理解に有効な「分解の方向」「時系列の方向」を紹介しました。通常は、WBSやIPFなどでこれらの構造が明らかになります。

『業務を可視化する[3]』の続きを読む・・・


業務を可視化する[2]

2009/01/20

前回、業務を分解して理解することに触れました。今回はその部分をもう少し深堀りしてみます。
業務は単独で存在するのではなく、別な業務との関係を持っています。業務を可視化するためには、この関係を捉える必要があります。
業務を可視化するための、要素2=「業務間の関係あるいは構造」です。

『業務を可視化する[2]』の続きを読む・・・


業務を可視化する

2009/01/15

情報システムの構築には、業務の理解が不可欠です。まず業務を可視化し・理解し、その中でコンピュータシステムが果たす役割を明示します。
今日は、「何を聞き出し何を表現すれば業務を可視化したことになるか」というお話です。

『業務を可視化する』の続きを読む・・・


インデックスばかりのWeb

2009/01/13

先日、使っていたパソコンのマザーボードがダメになり、新しいパソコンに移行しました。突然故障したため、URLのバックアップがありません。

『インデックスばかりのWeb』の続きを読む・・・


Web2.0とエンティティのKEY

2009/01/07

最近、Web2.0の話題をいろいろなところで耳にします。私の場合、どちらかといえば、技術面よりもビジネス面で議論することが多いようです。

『Web2.0とエンティティのKEY』の続きを読む・・・