» 【第72号】3種類の言語つづき

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

DRI通信72号「3種類の言語つづき」            2002.9.2
さすがの猛暑も、台風13号以後勢いを失い、しのぎやすくなってまいりました。8月20日のK2W勉強会は、30人以上の盛況で、
札幌スパークルの桑原さんの実践経験に基づく迫力あるお話に[目から鱗]との感想も聞かれました。
データの流通を、1メインフレーム内から、C/S内、さらにWeb環境内と拡大すべくITが進化する一方、分社化、M&A、
アウトソーシング、SCM、CRM、連結会計など組織・業務環境が激変します。この変化と成長へのお荷物にならない情報システムを
如何に造るか。これが今の最大の戦略的課題と、あらためて認識させられた次第です。
さて今月は、先月の「3種類の言語」についての2件のコメントを紹介させていただくことにしました。
■ 戸田忠良氏(戸田ソフトウエアオフィス)
本稿の結論に賛成です。テーブル言語の活用を上流の設計から利用すべきと思います。
テキスト言語(特に自然言語)による設計文書の作成とそれを使った人間VS人間、ま
たは人間VSコンピュータ間のコミュニケーションの非効率性が、現在のシステム開発
の最大の問題点です。


それは、内容の正確性が担保できていないということです。とにかく、早期に仕様を
論理的に正確に記述し、それをその後も利用するということができないと、システム
開発の工程ごとに作られる設計文書により、”伝言ゲーム”のように内容の正確性が
徐々に毀損されることになります。また、現在、行われようとしている異なる自然言語間の変換
(日本語VS英語、または中国語など)により、記述内容の正確性が更に低下することが懸念されます。
テキスト言語による記述の正確性の確認は、ソフトウェアのテストに見られるように、とてもコストのかかるものです。
テーブル言語の記述の正確性の確認は、それに比べて人間の直感と論理的検証システムの完備により、簡単に行うことが出来ます。
特に、上流で業務内容を記述する場合に、このようなテーブル言語を活用し、正確な検証された仕様にしてしまうことが大切と思います。
■ 桧垣清志氏(NECソリューションズ)
 今月号は、とても気に入りました。私にとってまさに、という内容でした。昔からのDRI通信や椿さんの著作物でも、
部品表と部品の組み合わせで全て表現することの大切さが強調されていましたが、今回は今までより鮮明になっているように思いました。
□エンジニアリングが確立した世界(建設、プラント、、)では、
 ・部品表で、部品をキチッと定義し、
 ・エンジニアリング図面で、部品間の関係を正しく描く
ができている。だから、SWでもこれができない訳がない。しかし、意味を配置や記号で図面に記述できるようにすることで、
ポンチ絵も、エンジニアリング図面になるんだということは、あまりSW開発者の一般世間では了解されてないようです。
□「プログラム=テキスト言語」であり、処理はメタデータでテーブル言語に変えられる。SWの間違いは、いつまでも処理を
処理だと思っていることだと思います。処理は、概念のズレや概念の粒度の違ったままでも誤魔化せてしまうのが大きな問題です。
プログラム屋さんの仕様書を見ると、図面(ポンチ絵)上とプログラム名がズレていることなど日常茶飯事です。これがまさに処理で、
概念のズレをひねっている証拠であり、それを許しているのがSW開発の現状だと思います。仕様書は、テキスト一辺倒、一覧表\n(椿さんのいうところのテーブル言語)を書いても、仕様書や表毎に概念がずれていたりしています。この頭で変換し解釈し、
プログラムで誤魔化す習慣をなんとか止めないといけないと考えています。
□順次処理は、人間が順次自分の頭の中の概念構造(これがいわゆる暗黙知)にハメて行く作業だと思います。他人が書いたテキスト言語
(プログラムや仕様書等)をレビューすると頭が疲れるのはこのためかと思います。他人が書いたものを、その順に読み、
行間から概念や背景など読みとりながら、問題点を抜かないといけませんから大変です。プログラマが30代で20代に負けるという話も
良く分かります。
□「図で考える人は仕事ができる」。 図の場合、テキスト言語のように順次処理する必要がないので、仕様書レビューの時など
脳みそのCPUを、本来の仕事(書いてある意味の解釈以外)に使えるので仕事が速い、できるということだと思っています。
また図は直感が働き易いため、因果関係が追い易いという意味もあると思います。
□これらを解決するのに、メタ構造によりテーブルに意味構造を待たせ、テキスト言語を、極力テーブル言語で表すのが良いと
いうことだと解釈しました。これについて、とても同意です。
現在私の方で取り組んでいるプログラムレス化は、これに当たります。この時重要なのは、意味的な構造です。これが分かれば、
このテーブル言語を読みながら動作するエンジンがあれば良い分けです。あとは、データ項目間のマッピングという作業で
ほとんどのことができると考えています。
またテーブル言語化し、エンジニアリング図面に描けば、粒度が揃ってないとおかしく見えるので、レビュー等での発見が容易であり
精度が上がります。
□「DOAは、テーブル言語アプローチでもある」。テーブル化する=きちっと概念を整理設計するという構図が理解できている人には、
この表現でも良いと思いますが、ずばりDOAは、「意味の構造化方法論を追求する」、「メタ構造の開発方法論である」
などと言っても良いのではないでしょうか。
■追伸
2件のコメントは以上ですが、「図と表を活用すべし」への強力なサポート、ありがたく感謝いたします。
ところで、どうして言語が次々と考案されるのでしょうか。「コンピュータは処理機械だ、処理仕様はテキスト言語以外考えられない」
と言うことなのでしょうか。
私にとって昔からの身近な疑問は、なぜDDL(データ定義言語)なのか、です。リポジトリに投入すべきメタデータなのに、
これをDBMSごとにそれぞれ固有のテキスト言語DDLを発明することになったのはなぜなのか。CODASYLの方々も大
きな影響を与えたかと思うのですが、なぜテーブル言語にしなかったのか。ご存知の方は教えてください。