» 【130号】「可視化の条件」

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【130号】「可視化の条件」

■可視化への関心
業務や情報システムのあるべき姿を求めて、「可視化」や「見える化」の指摘
を耳にする機会が多くなりました。J−SOXのような業務の統制、またEAのよ
うな広域の情報流通・共有が強く求められるようになったからかと思われます。

機械や建物のようなハードウエアと違って、業務や情報そのものは直接目で
見ることができないため、毎日顔を合わせている隣の部や課の人たちの業務
や扱っている情報ですら、曖昧にしか理解していないということが多いものかと
思われます。またシステム化を担当する専門家も、担当するシステムは別とし
て、これと連携する隣のシステムのことは、どうもはっきり理解できていないと
いうことが多々あります。
■自然言語では不十分
自然言語によるドキュメンテーションは可視化の第一歩ですが、これで間に合
うというケースは例外的といえます。立法や裁判は何年も掛けて行われますが、
これは人間の行動の工学的モデルによる形式化が難しく、自然言語に基づいて
行われるためかと考えられます。しかし企業の業務や情報システムの扱いは、
何年も掛けて取り組むわけにはいきません。適切なモデルをベースに可視化し、
効率的なコミュニケーションを行う必要があります。
■プロジェクトエンジニアリング以前に
情報システムは受注生産型の一品ものです。私はかつて化学・石油プラントエ
ンジニアリングにかかわっていたため、このときのノウハウを活用してきまし
たが、本当は組立加工工業−それも多品種少量かつ製品が頻繁に変わる−の工
場建設に最も近いのではないかと思っています。プラントエンジニアリングに
おいては、もう50年も前になりますが、プロジェクトエンジニアリングの重
要性が叫ばれ、われわれもPERT図など盛んに勉強いたしました。しかしプ
ラントには、成果物をほとんど個人差なく表現するP&ID(配管計装線図)
が確立していました。
50年遅れて、情報システムにおいても、大規模化とともにプロジェクトエン
ジニアリングが話題となっているわけですが、P&ID相当の、作るべきもの
を個人差なく表現するドキュメントが確立していないというハンディがありま
す。指揮者がいくら優秀でも、演奏者がまちまちの楽譜をみているのでは、美
しい交響曲は生まれるはずがありません。そこで成果物共有のための可視化が
課題となるわけですが、「高品質が迅速に得られ、かつ読む人により解釈に差
の出ないもの」という条件が非常に重要と考えます。
■3種の言語
人と人とがコミュニケーションする手段として言語があるわけですが、これは
次の3種
(1)テキスト言語
(2)図面言語
(3)テーブル言語
に分類できると、私は考えます。
(1)は自然言語やCOBOL、JAVAなど、もっとも言語らしい言語ですが、
斜め読みは本質的に不可能であり、読みながら順次コンテキストをメンテしつ
つ読むもの、抜け・漏れ・矛盾の検出は容易ではありません。感情を伝える文
学には向きますが、論理的に業務や情報システムの構造を記述するには向きま
せん。
(2)は機械や建物の設計に不可欠の言語であり、要素と要素間関係を分かりやす
く表現するドキュメントとなります。左上から順次読むという制約はなく、見
たいところを直接見る「斜め読み」が可能です。ハードウエアは重力の関係で
上下が決まっており、3次元空間に存在するまま誰にも同じように見えますの
で、図面のレイアウトに人による差が出にくく、自然に同じLOOK&FEE
Lが得られます。
ところが業務や情報システムの場合は、どのような要素に分けるかが一致した
としても、適切なレイアウト基準をつくらないかぎり、各人勝手なレイアウト
で書くことになり情報共有を難しくします。
(3)は要素の仕様を記述するのにふさわしい言語で、EXCELやDBの形式そ
のものとも言えます。「斜め読み」が可能という点では(2)と同じです。
したがって、情報システムのエンジニアリングでは、(2)と(3)を活用して要素
間の関係と要素そのものを表現するのが基本となります。ビジネスユーザ、シ
ステムアナリスト、プログラマなどはこれらを介して正確なコミュニケーショ
ンを行うべきと考えます。さらに人間の共有した情報を機械が共有できれば、
システムの自動生成や自動運用が可能になります。このとき機械は(2)が処理で
きませんので、(3)に変換する必要があります。図に表現された情報をテーブル
化するわけです。
■IT独立
情報システムをコンピュータシステムとほとんど同義に捉える人々が多いよう
ですが、われわれは、顧客、商品、受注、出荷、請求、売掛のあった江戸時代
にも情報システムはあったと考えます。実装方式が変化しただけで、業務モデ
ルはさほど変わらないものだと考えます。
ITは日進月歩しますから、これを取り込んだドキュメントはすぐ陳腐化する。
これこそ本命の実装環境だと選んで実装してみると、思ったより速く寿命が来
てしまって作り直しを迫られた方も多いのではないでしょうか。
したがって、われわれはIT独立の業務モデルとソフトウエアシステムは分離
してドキュメントすべきと考えます。すなわち業務プロセスモデルと業務デー
タモデルを、(2)と(3)によって記述します。これを概念モデルとも言いますが、
決して概要モデルという意味ではありません。当初は概要から始まるとしても、
最終的には実装独立の詳細モデルであって、抜け・漏れ・矛盾のない−整合性
のとれた正しい−ことの検証されたモデルを指向します。
■概念基本4ドキュメント
このような前提の下にわれわれの到達した結論は、次の概念基本4ドキュメン
トです。
 a.IPF(Information Process Flow)チャート(2)
 b.画面帳票イラスト(2)
 c.概念DB構造図(2)
 d.データ定義書(3)
aは情報システムの製品である画面帳票の目的を表すものであり、cはdと合
わせてこれを構成する部品の整合性を保証するものです。bはaとcを繋ぐも
のと言えます。したがって整合性の観点ではcが主役となります。
DOAではシステムの骨格はデータが作ると考えます。建物にたとえると柱や
梁に相当するものというわけです。プロセスはしたがって壁や内装ということ
になります。整合性の取れたデータモデルとは、柱と梁が正しく結合されてい
るということです。
■3種の整合性
私はcにおける整合性には、次の3つがあると考えます。
・EI(Entity Integrity)
・RI(Referential Integrity)
・DI(Derivation Integrity)
EIはあるエンティティが削除されたら、これを記述するデータはすべて削除
されるべきということです。レコードが冗長に散在していると、このメンテも
必ずしも容易ではありません。RIは参照整合性としてよく知られているもの、
KEY値が変更/削除されたらRKEY値に適切なメンテが必要ということで
す。DIは加工元データが変更/削除されたら、加工データに適切なメンテが
必要ということです。
単価が変われば金額は変わらなければなりませんし、5個出荷したら在庫は5
個減らなければならないはずです。私は、DIは本来DDLとして記述される
べきものと考えますが、これを実現するDBMSはまだありません。
DIの追求は概念DB構造の品質向上に極めて有効で−感覚的ですが65点が
95点にアップする−このためにわれわれはSPF(Schema Process Flow)チ
ャート記法を考案し、これを適用しやすいように概念DB構造図のレイアウト規
則を作りました。DBMSがサポートしないためと思われますが、DIについ
ての一般の関心は低く、DB図上でDIをトレースする方法論は、世界中でわれ
われのものだけかと思われます。
以上のa、b、c、dはシステム開発という一種のアプリケーションにおける
製品−実装独立の要件定義ドキュメント−であり、コンテンツはメタデータに
なります。したがってこれを素材にデータモデリングを行うことによって、シ
ステム開発のためのDB、リポジトリが設計できることになります。リポジト
リにおいて、不整合の発生しないことを確認し、a、b、c、dに冗長メタデ
ータが含まれないよう心掛けました。
■可視化の今後の課題
可視化という観点では、UMLが有名ですが、10種類以上のドキュメントが
含まれ、流派により「これは使わない」など、冗長メタデータの整理は十分で
きていないかに見えます。クラス図が中核だと言われますが、レイアウトの基
準がないため、LOOK&FEELは作成者に依存し、大規模システムでの整
合性のチェックは非常に難しいのではないかと想像します。アイコンの標準化
ができ、ツールが用意できたことは一歩前進ですが、まだツールベンダーが恩
恵に浴している段階のように思われます。
また可視化の対象は、今取り組んでいる開発対象システムだけを視野に入れた
のでは不十分、既存のレガシーやパッケージとの連携・共存を考えたグローバ
ル・全社に広がったものでなければならないと考えます。DOAのコンセプト
は、「プロセスのコミュニケーションの場をプロセスに先立って用意する」と
いうものです。プロセスをプログラムでなく、アプリケーションシステムの粒
度で考えると、これは「アプリケーションシステム横断のメッセージデータ/
トランザクションデータを素材に、その通信場を先に設計せよ」ということに
なります。したがって、今やドキュメントの可視化の条件は、これに耐えるも
のでなければならないものと思われます。