» DRI通信41~50号

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
DRI通信41~50号

創業者、椿正明の過去の発信のアーカイブです

【第50号】要件定義の品質保証

2004/12/26

DRI通信50号「要件定義の品質保証」2000.11.1
ON対決が終わり晩秋を迎えます。スキーシーズンを前に、ジョギングにも気
合が入ります。景気はいまいちですが、IT関係ということで、ご多忙のこと
かと思います。風邪に気を付けて冬を迎えましょう。
先月は、「データとプロセス」と題してデータを明示する図や表の生産性を
説明いたしました。これに対してコンサルタント戸田さんから、次のような
コメントが寄せられました。
<コメント 氏名=‘戸田忠良’>
データとプロセスの関係は、どの視点で見るかにより大きく変化します。もの
の世界に例えれば、製品を製造する工場のライン側で見るのか、加工されて製
造される製品側で見るのかの問題です。
当論文でも指摘されていますように、組織は処理の集合体であり、従って、
業務組織の構成員からのインタビューは、当然ながら「プロセス中心」となら
ざるを得ないと思います。彼らの視点は、工場で言えば製造ライン側の製品を
組立・加工する側の視点であり、そのための手順が発言の中心となるのは、こ
れもまた自然なことです。
そして、現在の基幹系システムは、業務担当者の視点のシステム化ですから、
プロセス中心にならざるを得ないのはいわば、一種の宿命ではなかったかと思
います。

『【第50号】要件定義の品質保証』の続きを読む・・・


【第49号】データからプロセスが見える

DRi通信49号「データからプロセスが見える」2000.10.1
オリンピックが終わって、本格的な秋になりましたが、みなさま元気にご活躍
のことかと思います。ポータル、ナレマレ、BI、コラボレイティブなど、相
変わらず新しい言葉が流行しています。シーズが多ければ多いほど、われわれ
はニーズと体力に合った賢明な選択が重要かと思います。
■データとプロセス
さて今月はデータとプロセスの関係についての認識や表現について考察します。
その粒度(Granularity、大きさ)については
(データ)      (プロセス)
1 属性 (加工データ)    加工データ導出ロジック
2 ファイルや画面・帳票   入出力プログラム
3 データベース や画面帳票群 システム(グループ)
のように3階層くらいを考えます。

『【第49号】データからプロセスが見える』の続きを読む・・・


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

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

『【第48号】リポジトリと方法論』の続きを読む・・・


【第47号】要件定義

DRI通信47号「要件定義」2000.8.1
やや早めに梅雨が明けて、非常に暑い日々が続いています。そのなかで風邪
を引いたりしている人もありますが、皆様お元気ですか。森総理もITとい
うご時世、情報関係の景気はやや持ち直しているように感じます。
さて今月は、要件定義という題で、システム開発方法論を考えてみます。わ
れわれ、しばしば大手SIのプロジェクトの上流工程で、データモデリング
のお手伝いをさせて頂くことがありますが、不思議に思うことがあります。
それは、進捗管理がガントチャートで行われ、PERT図が使われない、そ
のためいつまでに要件定義が終わるのか、どのようなドキュメントが作られ
るのか、がはっきりしない、ということです。永らくその理由を考えていま
したが、ふと最近そのヒントらしきものを見つけました。そこでその仮説を
述べ、皆様のご意見を伺いたいと思った次第です。

『【第47号】要件定義』の続きを読む・・・


【第46号】3種の言語

DRI通信46号「3種の言語」1999.7.1
梅雨の真っ盛りですが、選挙が終わり、あじさいもやや色褪せて、夏の近
いことを思わせます。私は夏風邪で、4日間ダウンしてましたが、皆様い
かがですか。
ビジネスシステム工学についての45号については、何人かの化学工学出身
者から、ほぼ同感の感想をいただきましたが、アナロジーによる新展開が見
られるところまでは、行けませんでした。
さて今月は「3種の言語」について、考えてみます。「言語に3種ある」と
は、誰からも聞いていません。素人の私の勝手な仮説です。言語とは人間と
人間のコミュニケーションの手段です。この中に
・ 図面言語
・ 表言語
・ テキスト言語
の3種がある、と私は考えているのです。

『【第46号】3種の言語』の続きを読む・・・


【第45号】ビジネスシステム工学

DRI通信45号「ビジネスシステム工学」 2000.6.1
新緑とつつじの5月もあっという間に過ぎて、雲はどんよりと垂れ込めたり、
かっと太陽が照りつけたり、梅雨近しを思わせます。皆様お元気ですか。
データ総研も今年の10月で15周年を迎えます。「出し物は」と言われ、本
(仮題「情報システム成功のシナリオ」、マネージメント向け)を出版したいと考
え、連休中は原稿書きに終始しました。26日のビジネスモデルノウハウ
セミナー、11、18日のXMLセミナー、7月セミナーのレジメ2件、さら
に3件の特注顧客企業内講演、それとこのDRI通信というわけで、業績は少
しも良くないのに、日程的にはなかなか厳しい5月でした。
先の「3種類の通信モデル」については、やはり戸田忠良氏から、示唆に富む
コメントを頂きました。その一部を紹介します。
<コメント氏名=’戸田忠良’>
情報場の一部であるDB通信場は、実はそう易々と組織全体で統一などで
きないし、多義性を保証しないと機能しないと考えています。偏見には適切な
有効スコープがあり、全社統合などと幅広くとらえ過ぎると、あるone factの
解釈にも場所により多義性が生じるということです。そして、それはそれぞれ
の役割の違いが引き起こすもので、違いの所以をきちんと突き詰めることは必
要ですが、いたずらに統一することを目指すべきではないだろうと思います。
その意味で、オブジェクト指向は、それぞれのオブジェクトを正当と理解する
暗黙の有効スコープを持っているのではないでしょうか。つまり、あるクラス・
ライブラリーの利用者に同じ情報場の共有がないと普及は難しいということです。
人類の進歩とは、自分の経験を軸に偏見を生み続けることにより引き起こされ
ると考えます。その意味で、人類は意味や意思をどうのように伝えているのか
という通信の本質の議論はとても重要と考えます。それに対する小生の仮説が、
「情報場を介して行う」というものです。</コメント>

『【第45号】ビジネスシステム工学』の続きを読む・・・


【第44号】3種類の通信モデル

DRI通信44号「3種類の通信モデル」 2000.5.1
花祭りに桜は満開になり、スケジュールどおり新緑の季節となりました。Y2
Kが過ぎ、昨年よりは活気があるように感じますが、実質は掛け声ほどでなく、
安心はできません。皆様はいかがでしょうか。
先月は標準化について私見をのべましたが、特に反論もなく、標準化をからめて
1件の講演を依頼された状況でした。
今月は専門外なので、若干不安ですが、通信のモデルについて素人考えを述べて
見たいと思います。通信に関して次の3種のモデルがあるように見えるというこ
とです。
■3種の通信モデル
(1) 個体間通信モデル
CSV形式トランザクション
[組織1]――――――――――――――――――→[組織2]
DB1:ローカルリソースデータ プッシュ型通信 :各種イベントデータ
(2) DB通信場モデル
公開DB: (メタデータ)
:(リソースデータ)
:(イベント1)&(イベント2)&(イベント3)&…・
↑ |
| ↓ プル型通信
[組織1][組織2]
(3) EAIモデル (メタデータ)


(EAIメタ)
[EAIツール]
↑ |
| ↓ プッシュ型通信
「組織1」 「組織2」

『【第44号】3種類の通信モデル』の続きを読む・・・


【第43号】ソフトウエアの標準化

DRI通信43号「ソフトウエアの標準化」2000.4.1
桜が咲き始めて、最悪の1999年度が終わりました。経営と情報の結合は
待った無しの急務です。そのためにはデータの広域流通が欠かせません。ネッ
トワークもデータベースも、データ流通のツールですが、いよいよ肝腎の高品
質のコンテンツを用意する番です。新年度はこれに向かって前向きに進む毎日
を迎えたいものです。皆様のご健闘を祈ります。
先月は「アーキテクチャ」を論じたわけですが、戸田コンサルタントから、
次のようなコメントをいただきました。
<コメント 氏名=戸田忠良>
さて、今回のアーキテクチャの話は、非常に重要でありながら、日本では本気
で議論されていない問題と思います。そこで、少しだけ私見を述べさせて頂き
ます。
「抽象化」とは、人間が自分の情報処理能力の限界を乗り越えるための手段で
あると思います。世界は、アナログな無限の情報を持つ世界です。その中で、
人間が理性的に生きるための手段が、適当な詳細さ(つまり、省略と簡略化)
で世界を観察するという方法です。
適当な詳細さとは、自分の情報処理能力を越えない要素数で問題となる対象を
説明しようとすることを意味します。これが、抽象化であると思います。

『【第43号】ソフトウエアの標準化』の続きを読む・・・


【第42号】アーキテクチャ

DRI通信42号「アーキテクチャ」2000.3.1
水仙、梅、ミモザが咲いています。しかし久しぶりに冬らしい冬、3メートル
以上のスキー場も沢山あって、スキー大好き人間にはうれしい2月でした。
とはいえ、厳しい決算、また来期の計画、どう立てるか頭の痛い2月でした。
きっとお役に立つはずの、われわれのデータ中心のノウハウは、まだ雪の中に
隠れているかのようです。これをご活用頂ける春が待たれます。
■コンピューティング・アーキテクチャ
さて今月は、Webの登場とともに最近話題されることの多くなったアーキテク
チャについて考えてみます。
「コンピュータがあってそれを回線で繋ぐのではない、まずネットワークが
あって、これにコンピュータを繋ぎ込むのだ」とは先の弊社主催のDB研での
協和発酵の岩沢部長の言葉ですが、今日のコンピューティング・アーキテク
チャを象徴する著しい言葉かと思われます。
おそらく1985年頃までは、メインフレームが主人(ホスト)であり、この周辺
に奴隷(スレイブ)としての端末がある、IMSやSNAの専制君主の時代が続
きました。その後1995年くらいまで、逆に何人かの顧客(クライアント)
が一人の召し使い(サーバー)を使うクライアント・サーバーが主流となり、続
いて今日のWebに時代を迎えています。土台/プラットフォームが短時間に
このように変化することは人類の歴史においても前例がなかったのではないで
しょうか。

『【第42号】アーキテクチャ』の続きを読む・・・


【第41号】リソース先行

DRI通信41号「リソース先行」2000.2.1
冬真っ盛りということで、寒い日もあるこの頃です。私も時々コートを着たり
することがあるようになりました。Y2Kがほぼ終わりeビジネス対応やシス
テム統合の課題など、中長期計画実現のための予算どりなどにお忙しいことか
と思います。
前回は「大規模システム開発の実態」を扱いましたが、とくに異論はなく、
「・・全く同感です。特に、発注者(弊社での現業部門と称している部署)の
コンピュータシステムに組み込まれてしまった業務知識部分の欠落が問題と
なっています。再構築したくても、現業部門が業務知識を持っていないのが現
実になっています。小職としては、現業部門が業務知識を復活することが必須
と考えています。・・」
「・・下記新年号、全てを言い当てていると感動しました。我々もご指摘のよ
うな事にならないよう、気を付けてこの暗黙知業界からの脱出を目指して行き
たいと思います。・・」
などのご意見を
頂きました。
38号において、レイヤードアプローチの中の「概念先行」を考察しました。
今回はこれに続く「リソース先行」を考察します。正確には「リソースデータ
はイベントデータに先立って決めるべきだ」という意味です。

『【第41号】リソース先行』の続きを読む・・・