第4章 電子文書フォーマット変換

4.1 概要

 この章ではアンテナハウスの代表取締役小林徳治氏が96年9月19日に行った“文書交換の標準形式について”の説明のヒアリング内容を元に,文書の標準化における現状と問題点,解決策の方向について述べる。

 まずはじめに,小林氏が述べたワープロ文書の交換における様々な現状を,開発者の視点,エンドユーザーの視点,規格制定者の視点からまとめ直した。そこで出てきたトピックスとしては,ワープロ間の違いには,機能,用語,開発思想の違いがあるということである。開発思想には,レイアウト重視と文書構造重視の二つがある。エンドユーザーは,レイアウトを重視することが挙げられている。

 この違いからくる問題を解決するには,文書交換を行う際,二つの設計思想の違いをはじめとする様々な違いをカバーする標準フォーマットを作成すればよい。そのようなフォーマットは,そのように作ればよいのだろうか。

 その問題を見る視点として,ここでは,コストとニーズとツールという3点を挙げてみている。そして,フォーマットの今後の予測として,長期的方法と短期的方法に分けて予測している。

 短期的には,デファクトスタンダードとなった文書(一太郎,Word,HTML)が,標準となっていく。他のワープロは,これらと文書交換できればよい。長期的には,新しいフォーマットができるはずである。しかし,そのとき,ユーザーニーズを汲み上げる必要がある。

 このような,ユーザーニーズを汲み上げながら,規格を作り上げていく動きとして,ARTS(The Association for Retail Technology Standerd)を紹介する。

 なお,アンテナハウスは,RTFJというワープロの文書交換形式を開発した企業であり,以下の製品を持つ。

4.2 開発者の点からみた文書交換の現状

 各社のワープロは,各々一つの閉じた世界を構成していると,小林氏は指摘している。つまり,日本語ワープロの機能や用語が非常に違い,極端に言うと,日本語ワープロを作っている人達というのは,他の会社のワープロをユーザが使っている,使う可能性があるということを全く考えていないし,ユーザが自社のワープロ以外のワープロも使っていて,文書の交換をする可能性があるということを全然考えていないと述べている。

 具体的な例として,用語の違いとしては,袋とじと行間と文字間におけるワープロ間の違いを指摘している。

 袋とじの違いとは,用紙サイズの指定で出来上がりのサイズを指定するものと,使用する用紙サイズを指定するものがあり,用紙の袋とじの折り方も長辺を指すものと短辺を指すものがあるため,同じ言葉を使っていても,出来上がりは全然違うということである。

 行間と文字間の違いとは,文字や行の間の空白を指す(文字アキ)ものと,文字や行のピッチ(文字送り)を指すものがあるということである。このことについて,同じ言葉を使っても,コントロールしている要素が全然違うと小林氏は指摘している。

 また機能の違いとしては,罫線や,行間等の操作の違いについて指摘している。

 罫線の違いとは,罫線を引く位置が,文字と文字の間に引くか,半角文字の中央に引くか,全角文字の中央に引くかというような,罫線を引く位置の違いと,罫線を文字扱いするかグラフィックにするか,文字扱いする場合には半角文字の扱いにするか全角文字の扱いにするかという,罫線の扱いの違いの2点を指摘している。

 行間等の操作の違いについては,行間や文字間を見栄えを良くするために,文字の大きさに応じて広げたり縮めたりという操作をしているが,その変化の仕方のモデルがワープロによって違うと指摘している。

 ここで,“変化の仕方のモデル”という言葉を使っているが,そもそも,ワープロのモデルには,大きく二つのモデルがある。レイアウト重視のモデルと,文書の論理構造重視のモデルである。小林氏は,開発思想という言葉を使って,この二つの違いを説明している。

 開発思想の違いとして,小林氏は,日本語ワープロと英文ワープロの違いと絡めて説明している。つまり,日本語ワープロは正方形の文字を一つづつ置いて行くという発想で作っているが,英文ワープロはそうではなくて,文書を作って,その文書の中にセクション,段落,文字があるというな階層構造を想定しているものが多いのではないかと述べている。その例として,Microsoft Wordを挙げている。

 このように,ワープロには,用語,機能,開発思想の違いがあり,そのような違いがあるからこそ,リッチテキストコンバーターのようなコンバーターのニーズがあるといえよう。それらの違いを埋めるためのワープロのコンバーターを開発する開発者の問題点としてはどのようなことがあるのだろうか。

 この点について,小林氏は,ファイルシステムの違い,文字集合の違い,表の違いから起こる問題点を挙げている。

 ファイルシステムの違いとは,コンバータ自身はパソコンのソフトで動くため,パソコンOSのファイルシステムを利用するが,ワープロ専用機はワープロ専用機独自のファイルシステムを持ち,ファイルシステムが違うという点である。

 文字集合の違いとは,ワープロの文書でどのような文字集合が使われているのかということであり,文字集合が違っている時に,どうやって対応付けるかということと,文字集合に定義されていない文字の扱いの問題である。文字集合に定義されていない文字は一般的に外字と呼ばれているが,外字の定義もかなり難しいと指摘している。

 表の問題は,表を作成するのに,文字を配置しておいて,その上に線を引いて,文字と文字の間をフリーに区切って意味を付けたり,文章上を線で区切って意味上の区切りを持たせるということを日本語ワープロは行なっているが,英文ワープロではしていないと思う点である。

 しかし変換上の一番大きな問題としては,やはり,開発思想の違いが影響しているようである。小林氏は,思想の違っているワープロの間で文書を変換するということは,かなり難しいと述べている。基本的な思想が同じであれば,変換するのは割とうまく出来るし,変換結果もそこそこのものになるが,思想が違うとかなり難しいと述べている。

 つまり,ワープロはそれぞれ独自性を持っていて,用語,機能,ファイルフォーマット,開発思想等の点で違いがある。だからこそコンバーターが必要になる。しかし,コンバーターを作成する場合でも,開発思想が異なる文書間のコンバートを行なうのは,難しいということである。

 しかし,ユーザーは,そのような,開発思想の違うものへのコンバートを望んでいるのだろうか。そもそも,ユーザーはコンバーターにどのようなことを望んでいるのだろうか。その点について後に述べる。

4.3 エンドユーザーの点から見た文書変換の現状

 エンドユーザーからの要望としては,レイアウト重視の要望が多いようである。

 小林氏は,日本語ワープロの変換については文章のレイアウトが崩れない,そういう要望がかなり強いと思うと述べている。

 また,客から,“完全に”変換出来るかという質問をよく受けるという。“完全に”という意味は,小林氏の印象だと,多分,重ねて透かしてみてずれない,ということだろうと感じているそうである。

 具体的には,以下のような変換への配慮ということになる。

 ただし,上記の話から,日本語ワープロは,文書構造を重視していないとは結論づけられないようである。なぜなら,日本語ワープロを利用するユーザーは,文書の論理構造をレイアウトを利用して表現しているようだからである。

 この点に関して小林氏は,文書を作成する時,構造的な問題(要素)を(文書の階層)構造として区別するのではなくて,見かけを変えて区別をするという作り方をしていると述べている。フォントを変えて強調したり,特定の意味を持たせるといったように見かけを変えて(文書)構造を変えるという作り方をしているということである。

 したがって,ユーザーは,文書構造を重視する点からも,レイアウトを重視して変換することを要求しているのである。

 ユーザーの要望である,レイアウトの保存とは,行き着くところ,どうなるのであろうか。小林氏は,究極は印刷イメージをそのまま再現するということになるので,紙を電子化したファイルを作ってそれを交換すれば良いということになると述べている。そしてAdobeが文書をPDFに変換している例を挙げている。それを画面上に表示するツールとしてAcrobatを出していると述べている。

 ただし問題点として,PDFの方から元に戻すのが難しいのではないかと思うと小林氏は指摘している。また,この後Postscriptの変換の中で,ある委員はPostscriptに変換する際に,情報が欠落する問題について指摘している。

 これらの指摘は,レイアウト重視の行き着く先は,Postscriptのようなページ記述であり,その場合,たとえ論理的な構造,すなわち文章,単語のつながりすら失われても,文字の出力座標の情報さえ持っていれば,レイアウトは保たれるということが背景にある。

 このように,文章構造を持たないでレイアウトを変換しても,ワープロで修正ができなくなるので,文書変換としては,問題になるだろう。

 すなわち,レイアウト重視といっても文章の論理構造をある程度持つ必要はある。

4.4 規格を定める側の点からみた文書変換の現状

 数社のワープロ間の文書変換を行なう場合,各社のワープロ間毎に変換プログラムを作成する方法と,標準的なフォーマットを作成し,その標準フォーマットへの変換方法を作成する方法の2通りがある。

 リッチテキストコンバーターは,後者の方法を取ったものであり,その標準フォーマットがRTFJである。そしてアンテナハウスは,このRTFJの規格の制定を行なっている。

 後者の方法を取ったことについて,小林氏は,中間ファイルあるいは標準ファイルを使うメリットとして,ワープロの種類が沢山増えて来ると非常に顕著になってくると述べている。ただし,ワープロの種類が少ない場合は,直接変換する機能を一対一に対応付けするコンバータを作る方が開発の投資効率は良いと思うと述べている。

 また,標準フォーマットを作った場合の問題として,小林氏は,仕様変更と最適化の問題を挙げている。

 つまり,中間形式を使うやり方は,最適化をする場合に非常に苦労をする所が有る。RTFJの場合は制御単語というものを使っていて,テキストの中にその文字列がどういうものであるのかを示すタグを付けているが,その解釈を時々少し変えないとまずい,あるいは制御単語の仕様を少し変更した方が良いのではないか,ということが出た時に,全部のワープロのことを考えて仕様を最適化するようなやり方をしないといけないと述べている。一つ制御単語の意味/解釈を少し変更するだけで,変換エンジンを全部作り直すということが場合によってはあるからだそうだ。具体的には,現在,コンバータのエンジンを37個くらい持っているので,37種類全部を少し作り直すだけでも非常に負荷があり,メインテナンスが物凄く重くなって来るという話を挙げている。

 そして,この辺は,ワープロからワープロへ一対一で変換をして行く方が柔軟に対処出来ると思うと述べている。なぜなら,特定のワープロとワープロの組み合わせの部分だけを少し変えるというのは,そこだけで閉じてしまう話なので,そうやって最適化して行く方が,数が少ない時は簡単だからである。

 しかし,実際30種類以上のワープロを変換しようとすると,変換方向だけで30×29で870方向であり,今コンバータは千方向以上変換出来るが,そういうものを全部個別に最適化するのは現実には不可能に近いとも述べている。

 つまり,中間ファイルを使って全体的に見て最適化をして行くやり方を採らざるを得ないのだが,最適化するためには,なかなか難しい問題が有るということを述べている。

 そして,この最適化をする場合,変換の目標が何処にあるのかということが問題になると述べている。直したいという時に,本当にやるべきかどうか,一方を追及すると他方が出来なくなるということがあるので,何を目標にするのかということを何時も考えなければならないと述べている。

 すなわち,文書交換には,標準フォーマットは必要であるが,その標準フォーマットを決める規格制定者にとっては,何を目標にするのかということを考えなければならないということである。

 ここで,最適化などしなくても,すべてのフォーマットの規格をすべて包含するような標準フォーマットを決めればよいのではないかと思うかもしれない。

 しかし,これには,実装するときのコストが問題になる。そのことについても,小林氏は述べている。

 小林氏は,標準形式の仕様を作る場合,大きな仕様から小さな仕様まである。MS-DOSのテキストファイルのようなものや,SGMLのように基本的にはDTDを作れば何でも出来る,という(大きな仕様の)ものもあると述べている。

 では,SGMLさえあればいいかというと,そもそも実装するのに問題がある。その点について小林氏は,SGMLは,アメリカのメーカがほとんどで,あとカナダのメーカがベンダになっているが,アメリカの場合は多分,軍の金でソフトを作っていると思う。民間の市場ではないと思うと述べている。カナダの場合は,カナダ政府がソフトに投資すると考えているようで,カナダの電力会社や石油会社などにハードを付けて,そこに随分金を注ぎ込んでいる。そのように,完全に民間の市場で作ったらSGMLのツールが本当に揃ったかどうかというのは疑問があり,日本でもSGMLは5年位前に紹介されていると思うが,ツールが揃うまでにかなり時間が掛かっている。最近になってようやく各メーカがSGMLのツールを出して来ていると述べている。

 ちなみに,ではコストを小さくして変換を行なっても,ユーザーは納得するかというと,そうもいかない。コストが低い変換というと,テキストファイル変換が挙げられるが,それについては,内容のテキスト部分だけ変換出来れば良いという考え方は,15年くらい前には製品としてお客さんに買って貰えたが,現在ではそういったものでは市場では製品としての価値は無いと思うと述べている。

 つまり,規格を制定する際に,すべてのフォーマットを包含するような(SGMLのような)大きな規格を作ることは,実装コストが大きく,よい手段ではない。やはり規格も最適化を図るべきであるといえる。

 なお,ここで出てくるコストという問題は,今まで述べてきた,開発者,エンドユーザー,規格制定者それぞれに,違ったコストがある。それを小林氏の発言と,ヒアリング時に配られた資料をもとにまとめると,以下のようになる。

 なお,採用コストも同様に,発言を元にまとめると以下の三つになる。

4.5 現状と問題点のまとめ

 開発者,エンドユーザー,規格制定者のそれぞれの問題をまとめると,以下の通りである。

 まず,開発者,エンドユーザー,規格制定者の立場を,1.1節で利用されている図で図示すると,以下の通りである。

 そして,それぞれの問題点をまとめると,以下の通りになる。

 開発者:ワープロの機能,用語に差がある。特に設計思想において,レイアウト重視と,文章構造重視の二つの考え方の違いがある。

 エンドユーザー:レイアウト重視のニーズがある。しかし,ページレイアウト言語でレイアウトを合わせても,編集できなくては,ワープロの文書交換として不十分である。

 規格制定者:ワープロの機能差に対し,すべてのワープロが持つ最低機能を実装(テキストファイル変換等)したのでは,交換情報が少ないし,最大機能(SGML等)を実装したのでは,実装コストが大きすぎる。

 つまり,問題点は,ワープロの機能,用語,設計思想に大きな差がありすぎるため,その差を埋めるような標準的な文書フォーマットを作成する場合,ユーザーを満足させるために単純に大きな規格を作ると実装にコストがかかり,小さな規格を作ると実装できてもユーザーが満足しないということである。

 そのため,ユーザーの目的を明確にし,それに合った最適化されたフォーマットを生み出さなければならないということである。

 さて,それでは,今後,そのような標準フォーマットが産み出され,広まるのであろうか。

 それを考えるには,そもそも,標準フォーマットが広まるには,何が必要かということを検討しなくてはならない。

 今まで見てきたことから,ニーズがあること,ローコストであることが必要なことが理解されよう。

 それ以外の要件として,小林氏は,標準形式を表立って使うためには色々なツールというものの新しいマーケットの存在が必要であると述べている。

 つまり,新しい標準形式を作った時に,それを使うためには,色々な投資をしてツールを作らなければならない。標準を普及させるためにはツールが必要だが,それが果たして投資効果が有るのかどうかという問題が出て来ると思うと述べている。

 小林氏の話の中では,テキストファイルの例がこれにあたる。つまり,テキストファイルは十数年前はまだそれ程ポピュラーではなかったが,その後ずっとパソコンのテキストファイルを扱うツール,エディタやテキスト整形ツールとか検索ツールとかそういうソフトが沢山出てきて,テキストファイル仕様というものがポピュラーになって,皆が使うようになったという例である。

 このように,標準フォーマットの普及について考える場合,ニーズ,コスト,ツールという三つの視点が必要なのである。

4.6 将来予測

 それでは,将来的に標準フォーマットは,そのようになっていくか,小林氏は,パソコンの世界のde facto standardとして,Wordと一太郎とHTMLの3種類のフォーマットに収束して行く,という予想を持っている。しかし,短期的にはそうなっても,長期的にはそうなるかどうかというのは,非常に疑問を持っていて,十年とかそういうスパンで見た時に,一太郎とWordとHTMLで終わるかと言うと,そんなことはない。やはり,新しいフォーマットがどんどん出て来るのではないかと思っているとのことである。

 この指摘は,いままでの,ニーズとコストとツールという視点からも納得できる。つまり,現時点では,Wordと一太郎とHTMLがツールも多く,導入コストが小さい。しかし,将来的には,世の中のニーズが変っていくであろうから,これら以外のフォーマットも必要になってきるであろう。ただし,その場合,ニーズというのが問題になるであろう。小林氏も,新しい標準を作るのであれば,市場性が無いと意味が無いと述べている。

 その点で,アンテナハウスの最近の動向としてはTagmeR2がある。これは,ヒアリング中には具体的に話は無かったが,後日資料が送られてきたものである。それによると,TagmeR2は,中間ファイルを作成し,それを各種のSGMLやHTMLに変換するものである。その際,変換に対しては,カスタマイズサービスを行っている。つまり,市場ニーズのある形式(CD-ROM,データベース等)のSGML文書に変換するツールを提供し,さらにユーザーコストを下げるため,カスタマイズを行うというアプローチを取っている。

4.7 標準フォーマット制定に対する提言

 4.6で,“新しい標準を作るのであれば,市場性が無いと意味が無い”とあったが,それでは市場性のある,標準フォーマットを作成するには,どうしたらよいだろうか。

 ここで考えておきたいこととして,ある委員の標準に関する発言が挙げられる。

 彼は,純粋に標準そのものには価値が無くて,誰もお金を出さないと思うと述べている。例えば,日本語ワープロの歴史はあるのだけれども,一所懸命バージョンアップしたり新しいものを買ったりするのは,今度こんな罫線が引けるようになったとかこんな飾りが出来るようになったとかだと思う。形式が標準であるというのは,そのずっと後に来るものだと思う。交換のニーズが有るにも拘わらず。そうすると,SGMLのメリットは何かといった時に,標準としか言えないと,ちょっと勝負出来ないなということが正直なところあるという発言である。

 この発言中の,純粋に標準そのものには価値がないという言葉は,検討する必要がある。

 なぜ,標準に価値がないのだろうか。それを理解するには,1.1節で利用されている図で確認するとよい。

 彼が指摘する日本語ワープロのバージョンアップを1.1節で利用している図で表現すると,以下のようになる。

 このとき,ユーザーニーズの流れは,雑誌の反響や,卸・販売店の要求,実際の売れ行きなどから起こってくる。

 一方,SGMLは,以下のようになる。

 (SGML)製品に対するユーザーニーズは,雑誌の反響や,卸・販売店の要求,実際の売れ行きなどから起こってくる。しかし,そのニーズが規格制定者に直接には反映されない。

 製品開発者を中継して,ユーザーニーズが反映されるという,間接的な形になっている。

 この図をみてわかるように,SGMLは,ユーザーから規格を作成する者へ直接行く線がないのである。言い換えると,ユーザーからのニーズを吸い上げて規格化するという線がないのである。つまり,先程から見てきた,フォーマットが広まるための視点である,ニーズとコスト,ツールの視点のうち,ニーズが欠落しやすい状況にある。

 そこで,そのあと,彼が発言しているように,例えばSGMLでデータベースを作るとこんなことが出来ます,と言えないと国際標準だからといくら言っても,そうですかで終わってしまうのではないか,という危機感があるということになるのであろう。

 つまり,ユーザーに,データベース化というニーズがあれば,それに見合うコストを払ってまでも導入することを検討するが,いくら国際標準だからといっても,ニーズがなければ,コストを支払ってまで導入することは考えないのである。つまり,ユーザーにとっては,自分に関係ない,価値のない規格なのである。

 しかし,規格開発者には,ニーズがあるかどうかが,分かりにくい構図になっているのである。

 そう考えていくと,1.1節で示されている,デジュアの図からみて,デジュアの規格は,広めるのに不利になる。デジュアの図は,下の通りである。

 この図からすると,規約が制定される際に,ユーザーニーズを聞き取る所がない。したがって,ニーズがないのに規格だけ作ってしまう可能性がある。

 この点に関して,小林氏も,例えば最近,ISOは全体的に新しい技術が商品になる前に標準を作ろうと考えている,と思うが,そうすると標準は作るが誰も使わないというものが出て来るのではないかと思うと発言している。

 一方,デファクトからの規格を考えると,下図に示すとおり,ユーザーニーズを捕らえて規格化している。

 したがって,市場性のあるフォーマットを決めるには,たとえデジュアのようなトップダウン型の規格でも,ユーザーのニーズを取り入れて,フォーマットを決める必要がある。そうすれば,コストが低ければ,新しいフォーマットとしてニーズがある限り,受け入れられる可能性がある。

 しかし,そのようなユーザーのニーズを取り入れながら規格を制定するような取り組みができるのであろうか。ここで,ある団体について考えてみたい。それはARTSという団体である。

 ARTSとは,The Association for Retail Technology Standardであり,小売業の店舗レベルにおけるデータ・アクセスを中心としたグローバルな標準化を推進する国際的な団体である。世界29ケ国,小売業約110社,ハードウエア・ソフトウエアベンダー約160のメンバーを有する団体である(1997年2月現在)。

 流通業においては,このような小売業であるユーザーと,ベンダーである開発者が共同してデータモデル等の標準化を行なっている。

 今まで見てきた考え方では,このようなユーザーニーズを吸い上げた場合,あとコストとツールが揃えば,この規格(データモデルが,その規格にあたる)が広まる可能性がある。

 コストとツールという点では,ARTS-AP(ARTS ASIA PACIFIC)は,OPOS-Jと協調することで,カバーしている。OPOS-Jとは,OLE POS Technology Council,Japan(OLE POS技術協議会)の略であり,Microsoft WindowsのOLE技術を利用して,POSの周辺装置を成業する方式を標準化するものである。これにより,開発コストを下げ,POSレジを始めとする各種ツールを揃えつつある。

 もし,今までの考察が正しければ,今後,ARTSのような団体が制定した規格が受け入れられていくはずである。その結果はまだ分からないが,今後,このような団体の動きに注目していく必要があろう。

(c)1996 JEIDA