ワンソース・マルチユースの可能性
1997年11月4日
今回はいつもと違って、マニュアルを作ったあとのことを考えてみたいと思います。作成後の話としては、DTPデータの管理とDTPデータの流用のしかた、ということが検討課題となってくるかと思いますが、今回は後者について、ちょっと考えてみましょう。
DTPデータを効率良く流用してますか？
いまのご時世、マニュアルをDTPで制作していないところはないと思います。ところで、皆さん何故DTPでマニュアルを制作することにしたのですか？
導入のしかたもよりますが、DTP化のメリットとしては、コストダウンができる、制作工程を短縮できる、外部会社に委託する仕事を減らせる、などいろいろあります。
当研究所としては以上のメリットもさることながら、データの流用可能範囲が劇的に拡大したことこそ最大のメリットであると考えています。確かに電算写植の時代でも、それなりにデータの流用はできました。しかし、印刷会社を変更したときにデータの互換がとれるかというと「はなはだ心許ない」というところが正直なところであったと思います。
DTP化によってこのような状況が改善されて、かなりの範囲でオープンなデータ流用／交換ができるようになったということは認めなければなりません。
レイアウトを含む完全なDTPデータの流用から、テキスト部分のみを抽出した形でのデータ流用、イラストデータのみのデータ流用といった、幅広い形で既存の制作データを流用できるようになったです。
使用するアプリケーションソフトが異なっても、一定のルールを制定しておくことで自由に、そして気軽にデータ流用／交換ができるということは、DTP時代の特色と言わねばなりません。
しかし、DTPデータの互換性を上げるには、それなりのデータの作りかたを考えなければなりません。つまり流用／転用を前提としたデータの作りかたを検討する必要がでてくるのです。また、この研究発表の後半で詳述しますが、特定のアプリケーションソフトやプラットフォームに依存する制作システムは構築しないことも考えておかなければならないでしょう。
紙媒体以外に転用する − PDF、HTMLなど
DTP化の進展によってデータを単に次の紙マニュアルのために流用するだけでなく、紙以外の電子メディアにも転用する道が開けます。
この研究発表でも何回か扱ったPDFやHTMLといった形で、既存のデータを比較的容易に電子マニュアルとして展開できるようになったのです。これもDTPという形でデータを保持していたからこそできる芸当である、と言わなければなりません。
とはいえ、サービスやユーザーサポートのためにアーカイブとして残しておくといった用途以外には、すでに制作した紙マニュアルを電子マニュアルにすることへの需要はあまり多くはないでしょう。
制作システム自体を紙マニュアルのまま残しておいて、PDF化して電子マニュアルだけを添付するという方法が広まってきている気配もありますが、以前の研究発表でも述べた通り、こんな方法は論外です。よほど質の高い電子マニュアルであるならばともかく、現状のお手軽PDFでお茶を濁すなど、論外以前と言わなければならないでしょう。
しかし、電子マニュアルへのデータ流用については常に考慮しておく必要があります。実際、いつ必要になるかわかったものではありません。それに加えて、電子マニュアルへの転用を前提とするならば、それなりのDTPデータの作りかたをする必要が生じるからです。
レイアウト中心のPDFマニュアルやMacromedia Directorで制作したマルチメディアタイトルといった例外を除けば、電子マニュアルの本質は、見出しによる論理階層構造とハイパーリンクにあると言っても過言ではありません。それはすなわち、DTPデータのデータ構造そのものの質が問題となるということなのです。
階層構造が明確ではなく、装飾でごまかしているようなデータの作りかたをしていては、電子マニュアルへの転用は極端に難しくなることを理解しておく必要があります。
補足
PDFの使用法として、最近面白いものを発見しました。
Enfocus社という会社が、自社のWebサイトでソフトのデモ版と同様に、PDFマニュアルをダウンロードできるようにしているのです。「製品版のユーザーには紙のマニュアルが必要だが、デモ版のユーザーにはPDFで充分」という判断かどうかはわかりませんが、こういう使いかたもあったのかと感心しております。
なお、Enfocus社ではPDF中のイラストやテキストを変更できるAdobe Acrobat Exchange 3.0用のプラグイン、PitStopを発売しています。デモ版もダウンロードでき、当研究所で確認したかぎりでは日本語版Acrobatでも動作しました。
実はデータの作りかたが重要
ここまでの話の流れを見ていると、『マニュアルを作ったあとのことを』と言っておいて、実は作る過程が重要だったというなりますね。
実用的な流用のしかたのテクニックの話かと期待されていた方は申し訳ありません（笑）。
ここまでの話をまとめると、データを流用／交換できることこそDTP化のメリットであるが、注意しなければならない点もある、ということになります。
注意点としては、次の2点です。この際ですから理由もまとめて説明しましょう。
- 特定のアプリケーションソフトやプラットフォームに依存する制作システムは構築しないこと
現状のシステムがベストとは限りません。例えばお得意先や遠隔地の販売会社から「××形式でデータをくれ」と要求されたときにどうします？
平家物語ではありませんが盛者必衰はこの世の理、絶対の強さを持つWindows＋Microsoft Wordでデータを持っていても安心ではないのです。また、「このソフトで作ったデータなら読み込めるから何とかなる」といった低レベルの互換性に頼るのではなく、オープンな形で展開可能なデータを最初から持っていたほうが良いはずです。
そのためには、容易に展開可能なデータ形式で書き出しができることを重視しなければなりません。また、アプリケーション独自の機能を使いすぎることによって、データの汎用性が限られてしまうことも注意しておかなければなりません。
例としては、調子に乗ってアプリケーション独自の表組機能を使いすぎないことですね（笑）。 - 電子マニュアルへの展開もにらみ、階層構造を重視したデータを構築すること
別にすべてのデータをSGML形式で保存していなければならない、などというつもりは毛頭ありません。「見出しごとに適用するスタイルをしっかり決めて、常にそれを適用する」ことだけでも素晴らしい努力と言えます。
ここで重視することは、HTMLのようにタグつきテキストとしてデータ書き出しをしたときに、論理階層構造を維持できるかということなのですから。
本文スタイルをあとからいじって見出しスタイルに合わせるようなデータの作りかたをしていては、データを書き出したあとで本当はこの文はどの論理レベルなんだ？と泣きを見ることになります。
これらの点が守られていてば、基本的には流用しやすいDTPデータを作れるのではないかと思います。当研究所のおすすめは、タグつきASCII生テキスト＋イラストデータで完全に書き出せるアプリケーションソフトでデータを制作することです。
今のところそのようなソフトはほとんどないので、できるだけこの線に近い作りかたをしておくことをおすすめします。将来はデータベースから自動でひな形を作る制作システムが絶対でてくるでしょうから、その準備という観点からいっても必要です。
このあたりの統一した指示は、メーカーの担当者が実制作にあたる担当者に出すのが筋です。流用しやすいデータを持っていれば流用料金を叩くことができるので、メーカーの担当者としては大喜びですね。
今回挙げた例は、ほんの基本です。間違っても実制作に携わる人から聞かないと何もわからないといったマヌケな事態にならないよう、メーカーの担当者は日々情報収集と勉強に励まなければなりません。
というわけで、作成したDTPデータを使いまわすには、実はデータの作りかたが重要だったというお話はおしまいです。
いかがでしたか？
「表題にだまされたー」と感じた方、申し訳ありません。そうはいっても、流用するためにはデータの作りかたが本当に重要なのです。今回の発表でその辺の事情をご理解いただければ幸いです。
