» 【第71号】3種類の言語

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

DRI通信71号「3種類の言語」            2002.8.1
7月10日の弊社セミナー、創業以来始めて[札止め]とさせていただきましたが、
事例発表も[広域統合はこの方向で間違いない]を確信させる内容で、大変うれしく思いました。
標準化を実践する企業文化が前提になりますので、地道な活動ですが、高品質とスピードを求めて、
さらにがんばっていきたいと勇気づけられました。暑さの盛りを迎えますが、皆様のご活躍を期待いたします。
さて今月は、3種類の言語の特性から、情報システムの仕様(What)にかかわるコミュニケーションは
如何にあるべきかを考察します。言語とはコミュニケーションの道具ですが、その形式から
・ テキスト言語
・ 図面言語
・ テーブル言語
の3つに分類できると私は考えます。一般の論文もこの3つで構成されています。コミュニケーションの
種類としては、
a.ユーザとシステム設計者
b.システム設計者とプログラマ
c.プログラマとコンピュータ
を考えます。トップマネジメント/スポンサーとユーザの間のコミュニケーションなどはWhatというよりも
Whyにかかわるものであるため、ここでは除きます。


■ テキスト言語
最も代表的な言語らしい言語は、日本語や英語などの自然言語です。はじめは耳で聞く話し言葉でした。
文字が発明されて、文章が書かれ目で見ることができるようになりました。速読術、斜め読みなどの工夫がありますが、
順次処理が本来の姿ですから、限界があります。単語と文法から成りますから、これを習得する必要があります。
慣れると空気のように意識しませんし、一応何でもこなせるため、つい濫用しコミュニケーションを阻害することがあります。
習得の負荷が大きいことは、外国語を勉強するとすぐ実感できるかと思います。
順次処理しかできないコンピュータの解釈する言語は、COBOL、4GL、JAVAなどのどれをとっても自然言語と
同様な性質を持っています。次々とプログラム言語を習得する人もいますが、いつまでもCOBOLにしがみついている人もいます。
その内容に抜けや矛盾があるかは、表現形式だけを追っていても分かりません。その意味を検証しなければなりませんが、
机上デバッグでは限界がありますので、テストケースを洗い出して徹底的なテストを行うことになります。これは裁判官が、
有罪か無罪かを判定するために、何年もかけて法律文書を解釈するのと、一脈通ずるところがあるように思います。
■ 図面言語
最も古くから用いられていた図面言語は、地図ではないかと思われます。戦国時代すでに戦争には地図は必須だったかと思われます。
土木工事や建築にも古くから図面が使われていたはずです。工業社会になって機械の組立図、電気の配線図、
プラントのプロセスフローシートやP&I(配管計装)線図など必須の図面が考案されました。設計とは図面を書くこととほとんど
同義になっている場合もあります。
図面は2次元の記述で、目で鳥瞰して見るものです。ものとものとの関係を把握するための最高の表現形式と言えます。
複雑な対象物(広義のシステム)は、複数の要素を含み、これらが相互に関係しあっています。この関係は図面言語によって
最も分かりやすく表現されます。最近、日経から「図で考える人は仕事ができる」(久恒啓一著)という本が出ていますが、
そのとおりだと思います。
地図や建物の平面図、また機械の組立図などは、実物を縮小した形で書けるので、個人差が出にくいから良いのですが、
そうでないもの−DB構造図や業務フロー図はその代表−は人によりまちまちな図面が作られるので、コミュニケーションの効率を
損なう恐れがあります。そこで図面にも「誰が書いても同じものは同じに表現される文法」が必要になります。その内容としては
レイアウト標準が最も重要です。また要素自体が、より小さい要素から成るシステムとなっている場合もありますから、
図に描く要素の粒度にも基準を定めなければなりません。これがしっかりしていれば、単なるポンチ絵/マンガでなく
エンジニアリング図面となります。基準に合った粒度の要素は、共通認識され、共用・再利用されることになります。
■ テーブル言語
これは、社員リスト、商品リスト、支店別売上リスト、本の目次など単なる表です。2次元的表現なので、目で鳥瞰的に
アクセスすることができます。関心のある項目だけ縦にアクセスして検索したり、数字はグラフとして表現することができます。
結果がそのまま表現されているので、テキスト言語に比較して、抜けや矛盾の発見が容易です。
テーブルの1行はエンティティ(オカレンス)、テーブル全体はエンティティタイプにほぼ対応し、項目は属性に対応します。
したがってテーブル言語になって、初めてメタデータが明示されてきたことになります。テキスト言語でも同じ内容が表現できますので、
比較してみますと、「テキスト言語のときの文法が、テーブル言語ではメタデータに置き換わった」、
したがって「テーブル言語は、テーブルコンテンツとメタデータから構成されている」と言うことができるでしょう。
メタデータは一般に安定しています。またテーブル言語での、中身や項目の追加変更は、テキスト言語の場合に比較して、
非常に容易ですから、テーブル言語は変更に強い言語と言えます。
テーブルはときどき、ヘッダー・デテイルの親子構成になることがあります。たとえば発注レコードですと、同じ発注先に
同じタイミングで発注するものは、事務を簡素化するために、一括する場合があります。すると発注先とタイミングを含む
ヘッダーテーブルが発生することになります。受注におけるヘッダー・デテイルの構成は、これを引き継いだものと言えます。
最近話題の階層構造を扱うXMLは、文法というより、コンテンツとメタデータから構成されますので、やや変則的ですが、
テーブル言語の1種と考えられます。
■ 3種類の言語の使い方
コミュニケーションの種類として、まず先のa.ユーザとシステム設計者およびb.システム設計者とプログラマ、
すなわち人と人とのコミュニケーションを考えます。人は目が使えますから、要素についてはテーブル言語、関係については
図面言語を使うべきでしょう。あいまいになりがちなテキスト言語は摘要程度に留めるべきと考えます。
実際、私はかつてプラントエンジニアリングに携わっていましたが、図面と機器・配管材料リストなどでその仕様を規定し、
何の不都合もありませんでした。
次に、c.のうちの人からコンピュータへのコミュニケーションを考えます。コンピュータは順次処理しかできませんので、
図面は使えません。そこで、テーブル言語とテキスト言語と言うことになりますが、変更に強くするために、
極力テーブル言語を使うべきと考えます。従来「処理仕様だからテキスト言語によらなければならない」と考えられていたものも、
メタデータを活用することによって、かなりの部分がテーブル言語化できます。われわれの研究では、どうしてもテキスト言語によるべき、
あるいはテキスト言語の方が適当と思われるものは、給与計算などの不定形の加工データだけであり、
これによってプログラミングのボリュームは現在の5%程度にできるものと予想しています。
c.のうちのコンピュータから人では、3種類の言語がすべて使われます。ただし図面言語は、コストが高いことを
覚悟しなければなりません。
DOA/データ中心アプローチは、インターフェース先行アプローチですが、同時にテーブル言語アプローチでもあります。
テーブル言語は安定しかつ変更に強い。
世の中の変化が激しく、経営からは、Agileな対応が要求される今日、DOAの文化や人材の養成が必須となりつつあると思います。