» 【第109号】可視化

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

お彼岸過ぎてようやく涼しくなってまいりました。
全般に景気は良いとのことですが、皆様のところはいかがですか。
9月27日、DOA+第3分科会が50名ほどの参加者を集めて行われました。
趣旨は、データモデルを、発案者以外の人が紹介するということで、PFU
の稲見さんがTM(旧T字形)について、分かりやすく紹介されました。有志
がDOA手法を、従来法で構築された環境のなかに、草の根的に持ち込ん
で変革を行う難しさが印象的でした。


■可視化とは
最近流行なのか、「可視化」、「みえる化」という言葉を良く耳にします。物流
では、「世界中の在庫がかなり正確にわかり、在庫削減ができた」、また宅配
では、「預かった荷物がどこにあるか、正確にわかることが、ビジネスの必須
条件」などといわれます。一方可視化不全のため、多くのシステム部門で、
多数のデータやプログラムがどのように関係しているかがつかみきれず、
生産性の悪い保守に頭を悩ませています。私は昔、目隠しをして将棋を指し
たことがありますが、かなり格下の人といい勝負でした。可視化できれば実
態が正確に把握され、つまらない試行錯誤がなくなり、正しい対処が容易に
行われることになります。
可視化とは、「紙や画面上に実態が表現されること」かと考えますが、情報化
時代の今日、その実態は、「DBとして記録され、これが適宜紙や画面上に表\n現できる」という意味として解釈できると思われます。情報を電子データ化し、
DBにストアすることによって、処理や通信が非常に迅速かつ容易になり、情
報共有が進みますので、これを可視化の不可欠の前提として考えます。した
がって、「人に見えるべきものは、コンピュータにも見えるべき」となり、これが
DB構造設計におけるひとつの条件となります。


■メタデータの可視化
上述の在庫や荷物の所在は、ビジネスユーザのためのデータですが、データ
やプログラムの関係などは、システム関係者(以下SEらと言う)のためのデー
タです。前者をレベル1のアプリデータ、後者をレベル2のメタデータということ
があります。可視化はいずれにおいても重要ですが、ここでは以下SEらの扱
うメタデータについて論ずることにします。
情報システムにおけるコミュニケーションの局面は、おおまかに、次の4種に
分類できると考えます。
 a.ビジネスユーザ→SEら(要件定義、業務モデル)
 b.SEら→コンピュータ(プログラム、ソフトドキュメント)
 c.コンピュータ→コンピュータ(メッセージ、ファイル)
 d.コンピュータ→ビジネスユーザ(画面・帳票)
可視化は人間のためですから、受け取り手が人間であるaとdが対象になりま
すが、dは、必ず可視化されていますから、aが対象になります。ところがほと
んどの場合ビジネスユーザは、要件定義/業務モデルを可視化する方法を
知りませんので、SEらが代行しビジネスユーザに確認をとる方式をとることに
なります。ところが、SEらも、要件定義/業務モデルを可視化する方法に不
慣れで、プログラムを作るためのソフトドキュメントで代替する傾向があります。
ソフトドキュメントにはどうしてもITが混入しますので、ビジネスユーザには取
り付きにくく、またIT変化が激しいため、折角のドキュメントが陳腐化しやすい。
「可視化すべし」を「ソフトドキュメントを作れ」と解釈するSEらもまだ多いので
はないでしょうか。今までSEら同士、如何に作るかのソフトドキュメントで会話
してきたので、無理からぬこととも思われますが、情報システムにおける可視
化とは、「要件定義/業務モデル」の可視化と考えます。
注)bやcにおいては、受け手がコンピュータですから、可視化の必要はありま
せん。しかしこれらの通信を支援する人がいて、その仕掛けを可視化すべき、
という意見があります。これはしかし、原則として、案件ごとの可視化ではなく、
ソフト化標準とか通信環境など、メタレベルの可視化であるため、除くことにし
ます。
■3種の言語
人間と人間がコミュニケーションするために言語が使われますが、広義に解釈
するとき、これには次の3種ある、と考えます。
(1)テキスト言語:日本語、COBOL、JAVAなど
(2)図面言語:地図、建築平面図、データモデル図など
(3)テーブル言語:社員名簿、部品表、DBなど
(1)テキスト言語は、最も言語らしい言語です。日本語などの自然言語は、
もともと音声しかなく、文字を発明してから、文章が作られるようになりました。
個人差はほとんど必然であり、抜けや不整合の検出は、法律文書や契約書
などでは不可欠ですが、容易ではありません。図や表と違って1次元表示/
順次記述であるため、コンテキストを確認しながら、頭から読んでいかなくて
はなりません。ダイレクトアクセス(斜め読み)は本来不可能なものです。これ
はCOBOLやJAVAなどのプログラム言語についても同様です。このため、
エンジニアリングにおいては、「ドキュメントは図面言語とテーブル言語により、
テキスト言語は備考程度にとどめる」のが原則かと思われます。
(2)図面言語は2次元記述であり、人間のパターン認識に訴えるため、ダイレ
クトアクセスが可能です。とくにモノ(エンティティ)とモノとの関係に関して、高
速の理解が可能で、関係/接続における誤りは図上で直ちに検出されます。
このため建築をはじめ、ほとんど全てのエンジニアリングにおいて、活用され
ています。
情報システムは、建物やプラントに似た構築物であり、エンジニアリング手法
を適用すべき対象と考えられますが、図面言語の適用は未完成、まだ試行錯
誤の段階に見えます。建物や自動車などのハードウエアは目に見えるため、
その図面の書き方は、自ずと決まって参りますが、情報システムは、目に見え
ないため多様な提案が生まれます。データモデル図と業務フロー図が主役で
あることは共有されつつありますが、UMLではこのほか種々の図面が提案さ
れたりしています。
図面の種類と同時に、その書き方も試行錯誤の段階にあると思われます。
大きな課題は、対象とすべき範囲とレイアウトだと、私は考えます。販売、生産、
経理、人事など業務ごとに分けて書くことは共有されていますが、これらを横断
する図面をどう書くか。また業務横断のシームレスなコミュニケーションを実現
するために、リソースDB(マスターDB)は分離独立すべきと、私は考えますが、
あまり認識・実践されていません。
また、レイアウトルールの重要性についての認識も不十分に思われます。
「同じアプリケーションのデータモデル図は誰が書いても同じ形になる、似た
アプリケーションのデータモデル図は見た目似た図面になる」ということでない
と、人間のパターン認識が活用できず、過去の経験が生かしにくい。レビュー
アーが高速に高品質のレビューをするには、このようなレイアウトルールが必
須と考えます。さらに、データモデル図には、資材所要量、在庫数量、品別月
別売上金額などの加工データが記述されますが、この導出過程はレイアウト
を工夫することによって、図上で簡単にトレースすることができます。これによ
って、図の品質/整合性を格段に向上させることができます。しかし、データ
モデル図を、単にリレーショナルDBのテーブル設計のため、と認識している人
がほとんどのように思われます。
(3)テーブル言語も2次元ですが、同種のモノ(エンティティ)の仕様(属性値)
を一覧形式で表現します。これは、人間はリストとして、またコンピュータはファ
イルとして、ともに手馴れたものとして、扱うことができます。
■システムの可視化
一般にシステムとは要素/モノとその関係から構成されます。このため基本的
に、要素はテーブル言語で、また関係は図面言語で記述することになります。
両者ともに、2次元記述でダイレクトアクセス可能の状態記述言語で記述でき
ます。人間は図面言語とテーブル言語が得意、コンピュータは図面は苦手で、
テーブル言語とプログラミング言語が得意ということになりますので、人間から
コンピュータへの指図には、テーブル言語を用いるのが、最善の方策ということ
になります。そこでビジネスユーザに分かりやすい高品質の要件定義/業務
モデルを作ると同時に、これを構成する図面をいかにテーブル言語/DB(メタ
DB、リポジトリ)にマッピングするかが課題となります。
■要件定義基本4ドキュメント
われわれは、このような可視化を実現するものとして、次の要件定義基本4
ドキュメント
(4) 概念DB構造図
(5) データ定義書
(6) IPF(Information Process Flow)チャート
(7) 画面・帳票イラスト
を規定しました。またわれわれの開発したTheRepositoryは、この基本部分を
コンピュータに伝えるためのテーブル言語/DBということができます。私は高
品質のTheRepositoryのコンテンツをベースに、最終的には業務アプリケーション
の95%のプログラムに関する自動化ができるのではないかと考えています。
95%とはソフト化標準の適用できる工業製品としての画面・帳票の割合であり、
標準の適用できない芸術的画面・帳票が5%は残ると考えてのことです。