» 【第2号】数との戦い

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第2号】数との戦い

DRI通信 2号                   1996.11.1
皆様こんにちは。つい先日、夏が終わったかと思ったら、もう冬がそこまで来て
います。歳をとると本当に、月日の過ぎるのがはやく感じられます。
まごつきながら1号を発信した後、皆様から励ましの返信をたくさんいただきま
した。やってよかったと安心しながら、今2号に取り組むことができます。アド
レスを公開してほしいといった声もありましたが、悪用されても困るので、目的
を良く考えて別の手段を考えたいと思います。ただユーザの声として、「俺にも
一言」というのならば、ペーストして送りますのでお寄せください。
「数との戦い」
■製品と部品
今ここでわれわれが問題にしている「情報」とは、「ビジネスに役にたつ画面・
帳票」と規定することができる。「役にたつ」とは「ライン業務における指図や
スタッフ業務における計画に使える」という意味である。この「画面・帳票」は
情報システムの製品であり、「データ項目」がその原材料/部品である。まずこ
の製品の仕様を固め、つぎにこれを構成する原材料/部品を洗い出してゆく、こ
れがデータ中心アプローチ(DOA)ということになる。


原材料/部品調達のために「入力処理」があり、製品組み立てのために「出力処
理」がある。また中間原料/半製品製造のために「加工処理」がある。先回、
「情報システムは一種の製造業」と言ったのはこの意味である。
なお従来、情報システムにおいてサブルーチンなど処理ロジックの単位を「部
品」ということがあったが、これはプログラムを「製品」とするプロセス中心の
パラダイムにおける用語である。これらはラインを流れる部品でなく、工作機械
/ロボットの部品相当を指すものといえる。
製造業では、用途の限定される製品の在庫を減らすために、極力注文を受けてか
ら製造しようと心がける。情報システムの部品や製品はコピーが容易なので、や
や事情が異なるが、「データベースを提供しますから、ご自分で画面・帳票をお
作りください」というEUC(End User Computing)は、無駄な製品を作らない
という意味で、これと似た発想である。
■クライアントとサーバーの役割
このようにユーザニーズにフィットした製品を安くタイムリーに提供してゆくた
めには、ユーザニーズを実現する、共用性が高くしかも自由に組み立て出来る、
品質の高い部品/半製品を用意しなければならない。これをサーバー(工場)に
置き、クライアント(営業所、もっと正確にいうと現地のノックダウン組み立て
工場)に送って組み立てるのである。共用部品の管理を一手に引き受けるのが
サーバーの役割であり、きめ細かくユーザニーズに対応するのがクライアントの
役割である。
なお、近ごろ騒がれている3層クライアント/サーバー・アーキテクチャでのア
プリケーション・サーバは、半製品を工場でも営業所でもない第3の場所で製造
しようというものであるが、論理的というよりは、効率を考慮した物理的な問題
として捉えるべきと考える。
■良いデータベースを作るには
著名なリレーショナルデータベースコンサルタントD.MacGoveran氏によると、
「良いデータベース」設計の3つの基準は、・直交性、・最小性、・完全性であ
るという。直交性とは冗長性のないこと、また完全性とは、アプリケーションで
必要とされる情報がリレーショナル操作によって作り出せることである。完全性
を判定するには全社的な視点が必要という。
したがって、この「良いデータベース」は、整合性のとれた部品から構成され、
ユーザは、安心して必要なデータを選択し、自分のほしい情報を組み立てること
ができるものである。このようなデータベースを作るために、しかし全社的な視
点にたった分析が必要とされるというのである。
DOAにおいては、処理と処理とが直接関係することはなく、処理と処理とはか
ならずデータベースを介して関係する。データとデータの絡みはすべてデータ
ベース上に記述され解決される。こうして処理はデータベースとの関係だけを念
頭に独立して動くことができる。このような個別アプリケーションのいわば「偏
見」から解放された、標準データから成るデータベースを、われわれはデータイ
ンフラと呼んでいる。
このようなデータインフラは1回作ればよい。「開発の中では無理があるので、
開発に先行して作ると良い」と先に述べた。しかしこれはマネジメント的にも、
技術的にも難しい問題を含んでいる。今回は技術的な問題について述べよう。
■数との戦い
最大の問題は、これは「数との戦い」ということである。全社をスコープに入れ
て考えると、一般にデータ項目の数は5000から50000ある。これらの整
合性をきちんととるにはかなりのスキルと時間を要する。ひとつひとつの品質の
積み上げが全体の品質を決める。したがって数が多いとひとつひとつの品質をよ
ほど高くしなければ
ならない。
n個の要素の2個づつの組み合わせの数は、n(n−1)/2であるから、シス
テムの複雑さ、その絡みを解決するための工数は、特別の工夫がないと要素の数
の2乗に比例する。かつてそれぞれ1年で開発できた2つのシステムを統合して
再構築するとき、多くの人は2倍の工数で開発できると錯覚する。実際は4倍か
かる可能性が高い。さらにこれが人間の頭の容量を超えていると、4倍かけても
収束しなくなる恐れがある。実際、一流のデータ分析コンサルタントでも、A4
で80ページにわたるデータベース統合図をレビュウすると、レビュウし終える
までに、初めの部分を忘れてしまい、レビュウの限界を感ずるという。
日経コンピュータ1996.9.16誌の特集「動かないコンピュータ」では、
「一にも二にも要求定義」とあるが、これが難しいので「防止策に王道なし」と
なったのであろう。またやや古いが、同じく日経コンピュータ1995.2.6
「失敗相次ぐ大規模開発」では「プロジェクト管理の徹底」が指摘されている。
しかしもっと根本的な問題が忘れられていないだろうか。
■対策不全で「動かないコンピュータ」
すなわち大規模問題への対策である。端的には、上に述べた「2乗の負荷」と
「頭に入り切れない」問題への対策である。CASEツールベンダーは小さな問
題をカッコ良く解いてこれを売りつける。ユーザも後は力仕事と甘く考える。学
者は原理が分かり仕掛けが出来れば後はプロジェクト管理の問題と興味を失って
しまう。化学装置の場合は、スケールアップの問題に、はるかに本格的に取り組
む。まずビーカーテストを行い、パイロットプラントを作り、これにより所期の
製品が出来ることが分かってから、はじめて本プラントの建設にはいる。
まず疑問に思うことは、「開発対象としているその大規模システムが、少なくと
もキーマンに、はっきり見えていたのであろうか」である。はたして抜けや矛盾
のみえる、鳥瞰可能なエンジニアリング図面を作っていたのであろうか。自分の
家のまわりなら地図がほしいとは思わない。しかし知らない土地に行けば地図が
ほしいと思う。目に見える範囲ならば地図はいらないが、広範囲の戦争に地図は
不可欠である。
部門別の小さなシステムならば、データ構造図なしでもやれる。スーパーSEは
すべてのデータやファイルを、自分の家の庭のようにしっかりと頭にいれている
であろう。しかし今や全社のスコープでデータの整合性を見なければならない。
ビジネスが変わり、これにつれてデータも変わる。これをフォロウし続けるのは
今や至難の業といえる。
物理ファイルのレコードレイアウトでは、データは断片的にしかみえない。詳し
いユーザも守備範囲は案外狭く、パッチワークのように互いの間にはすき間があ
る。スーパーSEとて歳をとり、引き継げば必ず品質が下がる。データ項目の識
別を項目名で行う人が多いが、これは昔のローカルなアプリケーションシステム
時代の名残であって、3000を超えるデータ項目を扱うには向かない。「数と
の戦い」への対策が万全でない。これが「動かないコンピュータ」の最大の原因
ではないだろうか。
■提案
数との戦いへの対策として次の2つを提案したい。
 ・独立して扱える部分に分割して一度に考えるべき数をへらす
 ・鳥瞰的エンジニアリング図面を作る
・としては次のような分割が考えられる。
 ・クライアント相、サーバー相、基本プロセス相
 ・サーバー相について概念(論理)レベル、物理レベル
 ・概念レベルについて
    リソース系
      社内関係、設備関係、社外関係、製商品原材料、勘定科目などの別
    イベント系
      業務分野別
     要約系
なお、クライアント相、サーバー相、基本プロセス相とは、戸田・菅沼の3相独
立モデル(ソフトウエア部品革命、日本生産性本部出版)にもとづくものであ
る。部品化を考えるとき、この3相を区分しないために混乱を招くことが多いの
で注意したい。
・鳥瞰的エンジニアリング図面としては、まず個人差の出ない、処理の読める概
念データベース構造図をつくるべきである。従来は、データベース構造図を書く
にしても、個人差の出やすい、処理の読めない、半ばプレゼンテーション図面を
書いていた。大規模システムにおける品質という点では限界がある。
概念データベース構造図とて、必ずしもすべてが科学的に立証されたものではな
いが、大規模問題をいかに速くかつ品質高く解くかとして、多くのデータ分析業
務に適用され洗練されたPLAN−DBにおける工学的図面である。
データインフラ構築は、21世紀における一流企業としては避けて通ることので
きない課題のはずである。諸般の事情により今すぐは難しいとしても、ここ数年
のうちに前向きに取り組むべき戦略的課題として受け止めていただきたい。
追伸
・このDRI通信は、システム担当者は勿論、システム戦略を預かるトップの
方々に、間違いのない情報システム戦略をたてていただくことを願って、作って
いるものであります。メイルアドレスさえ分かれば、その方がたにも配信いたし
たく思いますので、ぜひご連絡ください。今回はやや多めでしたが、毎月1回配
信したいと思っています。なお不要の場合もご連絡ください。アドレスを消去い
たします。
・ユーザ各位には既にご連絡いたしましたとおり、今年のPLAN−DBシンポ
ジュウムは11月15、16日、リポジトリの決定版について議論する予定で
す。お申し込みはお早めに。