» 【第43号】ソフトウエアの標準化

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

DRI通信43号「ソフトウエアの標準化」2000.4.1
桜が咲き始めて、最悪の1999年度が終わりました。経営と情報の結合は
待った無しの急務です。そのためにはデータの広域流通が欠かせません。ネッ
トワークもデータベースも、データ流通のツールですが、いよいよ肝腎の高品
質のコンテンツを用意する番です。新年度はこれに向かって前向きに進む毎日
を迎えたいものです。皆様のご健闘を祈ります。
先月は「アーキテクチャ」を論じたわけですが、戸田コンサルタントから、
次のようなコメントをいただきました。
<コメント 氏名=戸田忠良>
さて、今回のアーキテクチャの話は、非常に重要でありながら、日本では本気
で議論されていない問題と思います。そこで、少しだけ私見を述べさせて頂き
ます。
「抽象化」とは、人間が自分の情報処理能力の限界を乗り越えるための手段で
あると思います。世界は、アナログな無限の情報を持つ世界です。その中で、
人間が理性的に生きるための手段が、適当な詳細さ(つまり、省略と簡略化)
で世界を観察するという方法です。
適当な詳細さとは、自分の情報処理能力を越えない要素数で問題となる対象を
説明しようとすることを意味します。これが、抽象化であると思います。


アーキテクチャも当然、そのような抽象化の産物です。問題は、対象のスコー
プとレベルがどこにあるのかということです。多くのコンピュータ技術者の
抽象化されたコンピュータ・モデルは、プログラミング教育により、形成され
ていると考えられます。認識のレベルは、コンピュータの処理空間を前提とし
ていると、ネットワーク接続される要素は、辺境の要素に過ぎません。
コンピュータを主人(ホスト)とする世界観が、極めて自然に発生します。
しかし、現在のインターネットを認識・理解しようとすると、そのような個別
的な処理空間は、いわばネットワークに接続されるブラックボックスの中のミ
クロ構造の中にしか、出てきません。したがって、自分が主な世界と認識して
いる処理(プログラミング)空間が、出てこないものを肯定することはできな
いということになります。
現在、情報処理の世界のスコープが急激に拡大しているので、そのスコープの
インフレーションに合せて、コンピューティング・アーキテクチャが変化する
ことは自然です。このような状況の中では、対象とする世界の拡大に伴う認識
の対象の拡大に、意識的に取組む、主体的な意志の有無が問われるのだろうと
思います。つまり、自分が見ている状況を、どうしても理解してみたいという
前向きの意欲が必要ということになります。
日本でも、そのような認識のスコープを最大限に広げたアークテクチャ論議が
行われて欲しいと小生は常々感じています。そうでないと、ソフトウェア論議
が、プログラマーの世界観から出ることができないと感じるからです。
</コメント>
さて今月はソフトウエアの標準化について考えてみます。別に参考書を参照し
たわけでもなく、自分の日頃の考えをまとめただけなので、あるいは偏見があ
るかもしれません。遠慮なくご指摘頂ければ幸いです。
■標準化の目的
ソフトウエアに限らず、そもそも標準化の目的は何でしょうか。私は二つある
ように思います。一つは設計結果の共用による作業の節約、何回も同じ設計作
業をしなくて済むということです。同じ仕様で繰り返し作るとき、不具合が修
正され、ノウハウが蓄積され、品質の向上と、コストダウンが図れます。もう
一つは接続性です。コンセントの仕様、ネジの形と寸法、配管サイズ、鉄道の
レールの間隔、A3・A4といった紙のサイズ、通信プロトコル、SQL、い
ずれも接続性の確保が目的です。Windows、JAVA、100ボルトの
電圧も広義の接続性と言えるのではないでしょうか。いずれにしても一般に共
用・節約より接続性の方が重要かと思われます。
ソフトウエアの場合は、コピーが容易なため製造コストの比重が小さく、共用・
節約より、接続性がより重要と言えるのではないでしょうか。
■標準化の要件
時期尚早の標準化は、進歩を妨げる恐れがありますが、広域的かつ長期的最適
化をねらって行うものですから、必ず先行投資を必要とします。相当の時間と
コストが掛かるため次のような要件を満たす必要があります。
・ 安定不変であること
・ 要素に対するものであること(ここでは要素性と呼びたい)
・ 個人差が出ないような客観的基準があること
■安定不変
標準とは、理論的に「決まっている」ものではなく、人間が便宜的に「決める」
ものです。皆の賛同を得なければなりません。そこには利害、価値観が関与し
てきますので、政治が絡み、時間とコストがかかるわけです。したがって折角
決めたものが、直ぐに陳腐化するようでは、困ります。寿命永く、広範囲で使
えるものでなくてはなりません。
これまで、ソフトウエアの標準化には、ソフトウエア工学などといって、多く
の人によって努力が続けられてきましたが、はかばかしい結果が得られていま
せん。むしろ失敗だったように見えます。実装独立でなかったために、ITの
進歩によって、その土台が揺さぶられ続けたからのように思われます。やはり
ソフトウエア=業務モデル*IT
のように分離し、まずは前者についての標準化を考えるべきではないでしょうか。
■要素性
多くの要素から成る複雑な構造物は、要素の組合わせに対応したバリエーショ
ンがあるため、標準化の対象としては得策でありません。その要素を標準化し、
これを組み合せていろいろなニーズに対応するのが自然、ということになりま
す。自動車も、パソコンも、部品を標準化し、これをアッセンブルして作られ
ます。情報システム(業務アプリケーション)の製品である画面・帳票はデー
タ項目をアッセンブルして作られますから、その要素、データ項目の標準化が
ベースになります。
データ項目の標準化は接続性実現のためにも、不可欠のものとなります。オブ
ジェクト指向が、まずデータモデリングを行うのは、この接続性実現のためと
考えられます。
業務アプリケーション・プログラムには、n個の入力データ項目とm個の出力
データ項目が絡みますので、n*m個の要素がからみ、データ項目の標準化に
比べ、格段に難しく、標準化の対象としてはかなり不利と言えます。プログラ
ムを含めた標準化をねらう、オブジェクト指向はこれをどう解決しようとして
いるのでしょうか。
■客観的基準
要素の標準化にあたっては、その要素のきり出しにおいて、個人差の出ない基
準が必要と考えます。そうでないと、ユーザは折角用意された標準にめぐりあ
うことができにくくなります。すると、目的とする「共用による節約」が、数
人の仲間内などごく限られたものにしかなりません。
客観的基準のためには、科学的モデルが必要になります。これがユーザ要件の
WHATを規定します。ITが絡むと、職人の経験のHOWの世界になり、科
学的モデル化ができなくなります。したがって長期的視野に立つときは、IT
の絡まない、実装独立が必須条件になります。業務アプリケーションへのオブ
ジェクト指向の適用は、このオブジェクトきり出しの客観的基準についてもま
だ十分答えていないように思われます。
■ 標準は先行しなければならない
標準があってこれを利用してはじめて効果が出てきます。しかし一番初めは、
標準はありません。ここにジレンマがあります。ネジでもはじめはいろいろな
形・寸法のものがつくられたのでしょう。これを収集し4ミリの次は5ミリと
いうように、とびとびに規格を決めて行ったものかと思われます。
データ項目の場合は、各アプリケーションごとに、少しずつ違った意味のデー
タに少しずつ違ったデータ項目が設定されているのが普通です。うまい落とし所
を作って、これらを調整・整理することになります。この作業はシステム開発
の一部というより、事前の標準化、データインフラ構築として、企画・管理し
た方がうまくいくようです。
■ 標準はメンテナンスしなければならない
標準は皆が準拠してこそ意味があります。必然ではありませんから、「最低限
のしつけ」は必要ですが、「守ると得をするしかけ」が用意されなければなり
ません。また緊急対応などの際発生する、標準の乱れの監視と修復体制、すな
わち標準のメンテナンス体制が必要になります。「メンテなくして標準なし、
標準なくして共用なし」だからです。
よくソフトウエアとドキュメントの乖離が指摘されます。ドキュメントは、
DB技術が適用されて次第にリポジトリ化されて行きますが、この場合、概念
リポジトリと物理リポジトリと分けると、そこに乖離が発生すると言われます。
わたしは、これは在庫管理における理論在庫と実在庫の乖離のようなものだと
考えます。
在庫管理では定期的棚卸しが必須となっています。プラントでは定期点検・
定期修理が行われています。トラブルの都度対応するより、定期的メンテナン
スが良いことが経験により分かったからです。ソフトウエアは歴史が浅いせいで
しょうか。また直ぐに再構築が行われてきたからでしょうか。定期的メンテナ
ンスのコンセプトがありません。このため概念リポジトリと物理リポジトリの
整合をとる作業は余分な仕事、悪だと見られているようです。
棚卸しなくして在庫管理システムは機能しません。定期点検・定期修理なくし
てプラントの安定稼動はありません。同様に情報システムにおいても、標準化
対象の中心となるデータ項目定義のメンテナンス、とくに概念・物理の乖離の
メンテナンスなしではうまく行かないと私は考えます。皆様どう思われますで
しょうか。