第3章 SGML

3.1 概要

 この章では,96年6月20日に行われた,凸版印刷の田中氏のヒヤリングに基づき実際の導入について,成功・不成功の内的・外的な要因,現在の問題点についてまとめ,第1章での提案に従い考察を行う。

 田中氏は,現在主に以下のケースでSGML支援を行っている。

3.1.1 導入の現状

 田中氏によるとSGMLの導入がうまくいかない最大の原因は,目的の問題だという。

 SGMLは,原理的な問題であり,こうすれば,こう出来るといったように論理的な理解は得られる,しかし,実際の運用の場面において,コストや作業負荷の問題が発生し,これと整合性が取れないと,導入はうまくいかないのである。

 必要に迫られての導入ならば,成功・失敗以前にやらざるを得ない状況が存在する。そうではなく,合理化とか効率化といったものに対する漠然とした期待で導入してみたら,思ったような効果があがらずに失敗するケースがある。

 田中氏は,その様なケースについて,必要が無かったからだと分析する。元々要求が無く,明確な目的をもたないで行っているということだ。

 また,SGML支援の要請を受けるときほとんどが,SGMLである必然性が乏しく,RDBで対応可能なものであるという。氏は,その時,RDBの方が良いという。SGML以前の問題として,管理すべき情報の有無と,情報の整理の問題があって,まずRDBでシステムを構築し,SGMLはその上で,検討すべき問題なのである。RDBで済むところをワザワザSGMLにすれば,却って効率が落ちることにもなるのだ。

 SGMLにするのが良いシステムとは,HTML,CD-ROM,印刷物といった様な即物的なニーズ・目的を持ったものである。それぞれのメディアのデータをどのように共有するかの解としてSGMLがある。コスト・期間で,SGMLで情報を共有した方がよいのか,個々にデータを作成した方がよいのかの検討の結果としてのSGMLならば,システムはうまくいくのである。

3.2 データベースと入力

 CD-ROM等の具体的な目的については,SGMLの役割は実に明解であった。しかし,SGMLを用いた文書データベースについては,用途・機能が不明解だ。

 SGMLの議論には,二つの方向性がある。データの作成の部分と,作成したデータを管理・利用するためのデータベースの部分である。

3.2.1 文書データベース

 文書データベースに対して期待される機能に,全文検索がある。現在,インターネット上には,多くのサーチエンジンがあるが,それでフリーワードによる全文検索をかけた時,非常に多くのデータが出力される。同じ状況が企業内の特定のデータ・議事録等を対象としたときも起こりうる。そうした時に,データベースの検索キーワードとして,例えば,或種のトランジスタについて知りたいと思ったときに,使いたいから調べるのか,作るために知りたいのか,或はメーカを知りたいのか,といったものを使用すれば情報は相当に絞り込める。

 コンピュータ側でそういった情報をハンドリングするための状況を提供してやらなくてはならない。現在そういったことをやろうとするとSGMLのようなものを利用することになる。SGMLのタグを検索のキーとして使うのである。

 ここで問題となるのが,3.1.1にあるように目的の有無である。あらゆる可能性を考慮してタグを付けようとするとすることは,文書分類の問題と,タグを付けることに対するコストの問題から現実的ではない。結局,どのような検索が行いたいのかといった「目的」がなくてはデータベースの設計が出来ない,データベースの設計が出来なければDTDができず,SGMLが作れないということになる。

 適当にDTDを作成してSGMLを作っておけば,後でなにか役に立つかといったものではなく,後でそのデータに対してどのような検索をするかといった「目的」が必要なのである。

3.2.2 入力の問題

 データを作成する側から考えると,データの形式は問題とならない。データの作成者は各々の分野のエキスパートであるから,作成されるデータの内容に価値があるのであって,作成されたデータの形式は何であってもかまわないのである。そもそも,作成されるデータの形式は議論の対象にすらならない。

 そのエキスパートに対してSGMLでデータを出しなさいということは難しい。よほどの強制力が働くならばよいが,そうでなければ拒否されてしまう。SGMLエディタといったものは,格子が嵌まっているだけで,どこになにを入れるか作成者が判断しなくてはならない。作成者にとって何のメリットも無いものだからである。

 3.2.1のデータベースの様に参照・検索等で作成者に対してメリットが提供されれば使ってもらえるようになるだろう。作成から利用までのプロセスがフィードバックされ,作成者にSGMLを使うメリットがあれば,システムが回りだす。

 ただ,データが溜まってくれば便利になるといったところで,最初は,作成者に何のメリットも無いのであるから,ここでも目的と用途について明確になっていなければならない。作成者は,データベースを作るために仕事などしないのである。

 また,実際にデータを作成する場合のDTDは,タグ入力に対するコストとそれによって得られるメリットの費用対効果から決定されるものだ。

3.3 CALS

 委員の方からSGMLの一般的な認識の問題としてCALSの問題が指摘された。

 ISOの品質保証の問題と同じ様に,子会社の全てにまで同様の電子化が求められないかといったことであった。

 確かに,複数の企業間でプロジェクトを進めるとき,効率を上げるためには,データを電子化し,ネットワーク,通信回線でコンピュータ同士でデータをやり取りしなくては,ならない。一下請けであっても電子化されていなければ,全体の効率を落とすことになる。

 しかし,SGMLの導入には,大きなコストがかかり中小に企業においては,導入が困難である。

 これについて田中氏は,これはCALSのために社内の文書データを全てSGMLにすることを意味しない,社外とのデータ交換の部分でSGMLとなっていれば全体としての効率は,満たされるというのである。

 ここでも,導入は費用対効果で検討されるべきであり,タグについても最低限必要なものを満たせば,良いとのことであった。

3.4 SGMLの応用

 ワープロの世界ではデータの中味の解釈は人間しかやっていなかった,コンピュータが文章を読むということは考えていない,せいぜいフリーワード検索位の期待はするかも知れないが,起承転結のようなものは期待していない。

 SGMLというのは,或程度の知識情報を,コンピュータに分かる様に重要なものについてタグでマークしたものといえる。

 SGMLデータのタグの情報を基にした,処理の一つとして田中氏より,翻訳の話があった。機械翻訳を行う場合,タグが付いているから,同じ言葉が来ても,要素の属性(タイトル,脚注等)によってどのような文章がここに来るのかというようなことが,或程度ヒントとして与えられれば,タグを利用してもう少し良い翻訳ができないか,という話であった。

 SGMLの知識データとしての利用は,いくつか,研究はなされているが,具体的には,今後発明しなくてはならないものである。

3.5 「作る人」「かつぐ人」「使う人」

 ここまでの内容について,第1章の提案に従い,「作る人」「かつぐ人」「使う人」の視点から考察する。以下に1.1節に沿った図を示す。

 田中氏のヒヤリングの中でSGMLを導入するケースとして,CALSや省庁へのデータの提出でSGMLをやらなくては,ならない状況が存在することがあげられた。

 1980年代のアメリカでCALSが始まったときDODは,文書データとしてSGMLを要求した,当然プロジェクトに参加する企業は,SGMLをデータ出力することが必要であった。日本でのNNCALS,JCALSの運動,政府調達等でSGMLが必要となる。ここで,DODや省庁は,規格をかつぐ人の働きを果たしSGMLは多くの人の知るところとなった。

 通常,データフォーマットといったものは,それを利用する環境があって始めてユーザーに対して提供されるものだが,SGMLはデータフォーマットが必要とされる状況があり,利用するための環境はユーザー自らが用意するか,ベンダーに対して要求する必要があった(SGMLは,テキストデータであるから,テキストエディタがあれば書けないことは,無いが)。

 こうした,状況でSGMLは,その利用の環境が整っていないにもかかわらず,その知名度をユーザーに対して獲得していった。

3.5.1 規格

 デジュアの規格全般的にいえることであるが,ユーザーからの要望が反映しにくいことがあげられる。HTMLがこれだけ広まった背景として,ブラウザ毎に拡張された機能を取り入れること,その規格が無料であったことがあげられる。そうして急速にその応用範囲を広げたHTMLは,ネットワーク上のシステムの主流にさえなってしまった。

 SGMLは,作成にあたってDTDを必要とする。DTDにより多くの機能に対応できるためにSGML自体の規格は,ほとんど変わっていない。しかし,SGMLに先立ってDTDの開発を行わなくてはならないのは,ユーザー,ベンダーにとって多きな負担である。自動車業界等,ではDTDがきまっていて,利用されている。SGMLが広く利用されるには,オフィスで使用出来るDTDが一般的に安価に普及させることが必要だろう。

3.5.2 ベンダ

 現在,システムを提供する側での問題としては,ユーザビリティの高いツールの提供出来ていないこと,もう一つは,SGMLを活用したシステムの優位性,ユーザーに対するメリットを示し得ていないことだ。

 前者は,ユーザーが企業ユーザーにかぎられ,システムの規模が大きく,価格が高く,多くのベンダが参加してツールの洗練がされていくといった状況が,構成されにくいこによる。今後こういった市場が拡大していくことにより,より多くのベンダが参入し競争が起きなくては,急速な改善を望むのは,難しい。

 後者は,より本質的な問題でSGMLの活用の問題であり,ヒヤリングの中でもいくつかの提案がなされたが,これらをいかにユーザーのメリットに結びつけるかは,普及のかぎとなるだろう。今回のようなヒヤリングの中で活用法が提案されたように,ユーザーからのフィードバックが重要なものとなるだろう。

3.5.3 ユーザー

 田中氏のヒヤリングの中でもユーザーに対しての指摘がいくつかあるが,多媒体へのコンテンツの展開を図るといった具体的な対象については,SGMLの是非は,明確である,SGMLを使ってデータ共有した場合と,個々のデータを作った場合との比較で済む。

 しかし,文書データベースといったものでは,ベンダがSGMLを活用したシステムの優位性,ユーザーに対するメリットを示し得ていない。

 この現状において,文書データベースの導入を図るには,ユーザーが自ら明確な導入目的をもちシステムを構築していく必要がある。

 ユーザーは,文書データベースに対して期待する具体的な機能を設定して,費用対効果の検討から,DTDを設計してデータベースを構築することになる。

 その際の問題としてユーザーの各種ドキュメントの書式が標準化され,整理されていてるかどうかということがある。ユーザー側に文書データベースといったものを利用していく体制の有無だ。データベース以前の問題としてデータベース化しようとするデータが整理されていることが必要で,データベースを入れたからといって,データが整理できるわけではない。データが整理されていなければ,データベースには,なり得ないのだ。

 SGML導入時の最大の問題は,やはりエンドユーザーの入力の問題だろう。ユーザビリティの良いツールがあること,SGMLで入力することのメリットが入力者にフィードバックされることの要請は,すでに出てきた。これらは,エンドユーザーが,納得してSGMLデータを作成するためのものであったが,もう一点,日本では,文書の論理構造に対する認識が低いため,エンドユーザー自身に構造化した文書を作成するための,能力,習慣を付けるための教育も必要となる。

 ヒヤリング中では,触れられていないが,既存の紙ベースのデータ,ワープロのデータの変換も導入時に問題となるだろう。

 既存の文書をSGMLなりに変換するのは非常にコストがかかる,単にSGMLの形式にすればよいのならば,紙ならスキャナで取り込み画データとして扱い,ワープロデータはプレーンテキストのデータににして最低限のタグを付ければよい。

 しかし,知識データとして利用するためには,DTDに基づきタグを付与する必要がある,文書形式が標準化されれいれば,ある程度,自動変換可能だろうが,そうでなければ,文書を読んで解釈するといった作業が必要となる。

3.5.4 SGMLへの欲求

 現在,文書データのデータベース化が企業において検討される理由は,いくつか考えられる。

 外的なものとしては,CALS,ISO 9000等で厳密な文書管理が求められ,文書の管理といったこれまでは,社内的な問題が品質保証として社外での評価の基準となってきていることがあげられる。文書が整理,管理されていないことが,社内的な業務の非効率といったものに止まらず,製品の品質の評価に影響するのだ。

 内的には,情報が紙,ワープロデータの形では,利用がされにくい状況がある。紙はもちろんワープロデータも,イントラネットで流通性は高まったが,依然,機能的には全文検索があるぐらいであった。

 情報化,電子化の中で,ホワイトカラーの生産性は,必ずしも向上しているとは,いえなかった。業務に必要とされるのは,定型的な表計算などではなく,非定型な知識情報の活用であったからだ。これらの情報は,これまで,単なるワープロの文書データの情報として扱われていたものであり,可能な処理といえば単純な検索程度のものであった。人工知能をいったら大袈裟になるが,ある程度の知識情報を活用するための環境が,SGMLとデータベースとによって構築できるようになった。

 しかし,結局,文書データベースの導入は,個々の企業が自らの将来に対する投資として捉え費用対効果の検討の上で選択されるものである。各国のCALSは,当初は,100%の電子化をうたって始められる,韓国では,2005年を目標に動きは盛んのようだが,よりCALSの先進国である,アメリカ,ヨーロッパの各国では,SGMLの導入について,費用対効果が導入の最重要事項となっている。原理的な機能についての議論,それに関連した研究が落ち着いて,実際に導入を検討する際に問題となるのは,やはりコストである。

3.6 まとめ

 現在,SGMLを求めるユーザーにとって,デジュアであることがどれほどの意味を持つだろうか。田中氏のヒヤリングの中でもSGMLに対する着目点は国際標準であることではなく,ソリューションとしてのSGMLを用いたシステムの機能についてであった。

 出力としてSGMLを求める以外,文書データベースにユーザーが要求していることの本質は,業務効率の改善でありデータの有効活用である。そのためのデータベースでありシステムであるはずである,データ自体がSGMLであるかどうかは,問題ではない,要求する機能をシステムが満たすならば,システムで使用されているデータがなんであるかは,どうでもいいことなのだ。ならば,SGMLは,ユーザーが要求する目的を満たすための選択肢の一つとして捉えるべきであろう。

 しかし,世の中には,文書データ形式は,ただ一つだけあって覇権を握ると考える人たちもいるようである。確かに,ただ一つのデータフォーマットというものは利用する側には大きなメリットがある。データ交換はもちろん,将来にわたってのデータ利用を保証するものだからである。

 ならば,SGMLは,その覇権をにぎるのだろうか?将来に対しての予測はだれも出来ない。現状においてさえもSGMLは,他のフォーマットに対しての明確な優位性を示せないでいるのだ。データの共有,データベースでの利用を現在,考える上でSGMLは,データフォーマットの解である,しかし,まだ唯一の解とは,なっていない。

(c)1996 JEIDA