マニュアル制作データベース？

1999年4月 2日

最近「マニュアルのデータをすべてSGMLでデータベース化して云々」という話をよく聞きます。

膨大な数に上る製品マニュアルをデータベース化して利用しましょうといわれると、何かコストダウンに直結する感じがして思わずぐらぐらしてしまう人は（特にマネージャークラスの人に）多いように思えますが、マニュアルの制作データベースというものは本当に実用になるのでしょうか？

2種類のデータベースを混同しないこと

一口にマニュアルのデータベースと言われますが、完成取説のデータベースの話と、データベースを用いてマニュアル制作する話を混同してしまっている人が多いようです。どちらの方向性を持ったデータベースを構築するのかによって、議論が全くかみ合わなくなってしまうことが多いので注意が必要です。

• 完成データベースとして活用する場合
  後からユーザーの再配布やサービスセンターなどの社内用途向けにデータベースを構築するのであるならば、完成データのPDFをストックしておけば十分でしょう。PDFのデータベースに検索用の管理ソフトを組み合わせるといった構成で、十分に機能すると思われます。
  先日発表されたAdobe Acrobat4を使うことで、追加プラグインなしでPDF自体のイラストや文章をある程度再利用することもできます。
• 制作のためのデータベース
  マニュアルのデータベースといった場合、本命はこちらになるでしょう。 制作データをSGMLやXMLなどの汎用マークアップ言語で書き出したものをデータベース化し、そのテキスト／グラフィックデータを再利用して自動レイアウトを行えば、マニュアルの完全な一貫性を保ったままでコストダウンできるというわけです。
  しかし、一見バラ色に見えるこの考え方ですが、実は問題も潜んでいるのです。

スタイルパレットは万能ではない

SGMLやXMLといったマークアップ言語でデータベースを利用してデータベースを構築するためのテキストデータは、DTPソフトウェアから書き出すという形を取ることになります。
しかし、その際に階層構造を示すものは、スタイルパレットの情報しかありません。スタイルパレットは見出しの階層（レベル）を規定するだけでなく、そのレベルがどのような外見（文字の書体や大きさ、インデントの設定など）を持つのかを規定しています。
これだけ見るとすぐにマニュアルの制作データはデータベース化できそうですが、そうは問屋がおろしません。実際のマニュアルは手順内手順が存在したり、同じ階層でもインデントによって数種類のスタイルが存在したりするため、1階層1スタイルという運用はできないのが実状です。
そのうえ、ビジュアル処理を優先させることで、本来階層的には1つ下であるべき見出しに対して、1つ上の階層のスタイルを適用することも日常的に行われています（このような処理を認めないと、スタイルパレット内のスタイルの数が管理不能なほど増えてしまいます）。
例えば「ご注意」といった種類の情報が常に「サブ見出し」といったスタイルを取るとは限りません。「フロッピーディスクの取り扱いのご注意」といった見出しの場合には、意味的にもサブ情報ではなく、独立した情報のまとまりとなります。

つまり、スタイル名と階層、内容が場合によって変動することが多いのです。これは階層と外見だけでなく、情報の意味／内容をスタイルで定義していないために起こる問題です（SGMLやXMLではこの辺の対処もできるでしょうが、DTPソフトウェアで制作する以上、スタイルに関連するこれらの問題を解決することはできないでしょう）。制作効率を維持するためには、よく言えば柔軟な（悪く言えば管理の甘い）スタイルパレットを用いた方が良いのですが、データベースで自動組版では、このような考え方は通用しません。

見出しレベルとビジュアル処理、そして情報の意味／内容を厳密に運用できるものでなければ、自動組版なんて夢のまた夢です。後工程での手間を考慮に入れるならば、かえってコストアップにつながる可能性すらあります。

コンスーマ向けのマニュアルに導入する価値は？

コンスーマー向けのマニュアルがどういう作りになっているのかを考えれば、このような問題はすぐに明らかになります。まず、見やすさや分かりやすさを優先するために、見出しレベルの選択は厳密な階層構造を維持することよりも、ビジュアル面での見栄えに重点が置かれます。そのため、自動で書き出されたデータでは、本来の意味での階層構造の情報が失われているということになります。
また、ビジュアルとテキストを統合したレイアウトを採用している場合には、テキスト部分のみの抽出は困難となりますし、仮に抽出しても、それだけでは意味が通らないことになります。見開きレイアウトの維持といったデザイン要素も考慮に入れなければならないため、結局後工程の手間がかなりかかることになるでしょう。

自動処理の作業性を優先するのであるならば、ビジュアル的に見栄えのするマニュアルは、ある程度あきらめる覚悟が必要です。確かにデータベースパブリッシングはマニュアルなどの定型レイアウト向きといわれますが、最近のユーザーの求めているマニュアル像を考えたとき、定型レイアウトの杓子定規的なレイアウトをこのまま踏襲すべきものなのかどうかに関して、疑問が残ることも確かです。
そのうえ、一冊を通した筋書き／流れがあるマニュアルでは、結局流し込んでからの修正作業が必要になることも忘れてはなりません（汎用のパーツには場所ごとに異なる表情がないためです）。
詳細なレイアウトができないため、結局成り行きレイアウトが可能なグリッドシステム＋後工程となると、根本的な省力化とは程遠い上に、ビジュアルデザインの一層の貧弱化を招くことにはならないと言い切れるでしょうか？

もし導入するならば . . .

マニュアルにおけるデータベースの意義とは、異機種／異カテゴリー間の共通文書の管理にあるはずです。従って、以下のような場合には間違いなくそれなりの効果が期待できるでしょう。

• より多機能な機種から単機能製品のマニュアルを制作する場合（例：DVDからLDへ）
• 同じ文章を使う別カテゴリー商品のデータを共用する場合（例：ノートPCとデスクトップPC）
• カテゴリーを問わず必要となる注意文を共用する場合（例：PL関係、使用上の注意など）

しかし、特にコンスーマー製品のマニュアルに関しては、全体をデータベースパブリッシングで制作するというのは無理があります。逆に、データベースパブリッシングが通用するようなジャンルの情報であるならば、それが本当に紙媒体で提供する必要があるのかどうか、一度検討してみた方が良いかもしれません（例：コマンドリファレンスなどの単調な情報の電子マニュアル化）。
また、個別機種の設計担当者、マニュアル制作者がデータベースパブリッシングの趣旨を理解していない（個別作り込み主義）を取っているならば、データベースで制作する意味はあまりないでしょう。データベースの展開先でいちいち表現を変更しているようでは、データの統一管理による再利用というメリットが全く生かされないことになるからです。

いかがでしたか？

データベースによる制作システムに関しては「制作の現実を知らない管理部門がセールストークを鵜呑みにしてしまう」という話をよく聞きます。今回の研究発表ではデータベースパブリッシングのネガティブな側面が中心となってしまいましたが、これはあくまで当研究所が志向している、コンスーマー向けのわかりやすいマニュアルづくりには役に立たないのでは？という疑問を提示したものです。実際に役立てているかたの情報などありましたら、ぜひご意見などいただきたく思います。