» 【第46号】3種の言語

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

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


図面言語とは、地図、機械組立図、配線図、建築平面図、プラント配管計装
線図(P&ID)などです。2次元平面に、ものとものとの関係が示されま
す。機械、電気、建築、プラントなどのエンジニアリングにおいて、最も重
要なドキュメントになります。原則として、構成する全部品が表示され、抜
けや矛盾が、視覚により、高速かつ高精度に検出されます。特にスキルのあ
る人は一瞬にして、感覚的に欠陥を発見します。パターンでチェックするこ
とができるからでしょう。囲碁や将棋で名人が、10面指しなどできるのは、
このためと考えられます。実際、2次元図面ほど目の能力を発揮させるも
のはないのではないでしょうか。
表言語とは、一覧表です。部品表、IOリスト、データ項目リスト、要する
にECXELシートです。これも2次元表示です。目の能力を発揮させます。
一般に同じ属性を持つ同種のエンティティについての一覧表に使うと有効で
す。そこで図面言語に記述されたエンティティについて、同種のものの詳細
属性を記述するために使われます。
表が目の能力を発揮させるからといって、物と物との関係の表現に使うのは
邪道だと思います。パターンによるチェックができないからです。N個の物
があると、N*Nのマトリックスになるので、N=10でも100の目が出
来、これを一つ一つ、こころを静めてチェックしなければなりません。これ
は大変な精神的緊張を要求します。だからデータ項目間の関係をCRUD
(Create, Refer, Update, Delete)などを調べるために表にする方式があり
ますが、これには反対です。
テキスト言語とは、英語、日本語などの自然言語やCOBOL、JAVA、
SQLなどのプログラム言語です。元々自然言語は、話し言葉でした。時系
列的に耳で聞いて理解するものです。順次アクセスが基本です。文字が発明
されて、目でも見ることができるようになりました。順次アクセスの制約を
緩和するために、新聞では見出しを工夫し、2次元的にランダムアクセスで
きるようにしています。本を斜め読みするテクニックがあるようですが、根
本的には順次アクセスの制約から、逃れることはできません。
プログラム言語も、順次処理しなければなりません。コンピュータには目は
なく、耳しかないのでしょう。アセンブラーから、COBOL、
FORTORAN、SQL、C、VB、JAVAなど、コンピュータに仕事
をしてもらうためには、人間はその思いを、順次の言語に翻訳しなければな
りません。如何に高速を実現するかとともに、順次処理に翻訳するのが、
プログラマの役割になります。
コンピュータには理解できても、人間にとっては分かりにくい言語になりま
す。COBOLの50ステートメントのプログラムを、一目見て、誤りを発
見できる人はいるでしょうか。データを頭に描き、1命令ごとに、これがど
う変化するかを追跡していかないと、正しいか否か分かりません。プロセス
/HOWの羅列だからです。
われわれは、コンピュータによる処理を、如何に分かりやすく表現するかと
いうことから、次のようなSPF(Schema Process Flow)チャートなるも
のを考案しました。
[受注#]−(顧客#、品#、数量、年月日)

J−[品#]−(単価) JはJOIN(結合操作)

[受注#]−(顧客#、品#、(単価)、数量、年月日)

G 金額=f(単価、数量) GはGenerate(加工操作)

[受注#]−(顧客#、品#、(単価)、数量、<金額>、年月日)
これは、加工データ<金額>を、算出ないし定義する、図面言語の1種で、
プログラム言語ではありませんが、プロセス/HOWだけでなく、処理結果
をいちいち書いているため、正しいか否かが、直ぐにわかります。この表現
と、プログラムの表現は、対応がとりやすく、一旦このSPFチャートを経
由すると、プログラムの検証がやさしくなります。われわれは、これを複雑
な加工データ算出ロジックや、アウトプット導出ロジックの表現に活用して
います。
今までユーザの情報要求はどのような形式で書かれていたでしょうか。自然
言語主体の情報システム/プログラム仕様書に、画面・帳票のサンプルを添
えたような物ではなかったでしょうか。ユーザ要件を疑義のない形式知で書
ききれていなかったのではなかったでしょうか。人間の目の能力は素晴らし
いものがあります。これをフルに活用する、図面言語、表言語が開発されて
いなかったのではないでしょうか。このような図と表を活用するエンジニア
リングアプローチが、職人的なシステム開発の世界に掛けていた。
私どもはこのような考察に基づいて、上流工程でのユーザ要件定義ドキュ
メント形式を追求してきて、宣伝になって恐縮ですが、次のDOA基本4
ドキュメントに絞り込んでまいりました。
(1) IPF(Information Process Flow)チャート(業務プロセスフローチャート)
(2) 画面・帳票イラスト
(3) 概念DB構造図(業務データ関連図)
(4) データ定義書(加工データについてのSPFチャートを含む)
このうちの(1)、(2)、(3)は図面言語、(4)は表言語になります。
いずれも個人差のでない、文法を持っており、効率的なレビュー、コミュニ
ケーションを可能にしております。