今回はPDFと特にマニュアルとの関係について検討してみたいと思います。
製品マニュアルをPDFで提供する場合、大きく分けて以下の2つのパターンが考えられます。今回は以下の2パターンそれぞれについて、マニュアルとPDFの相性を検討していき、最後にPDFをどう使うかについて考えてみたいと思います。
「どちらにしてもディスプレイ上で見れば電子マニュアルでは？」という意見もあるかと思いますが、制作者の目的としてどちらを優先しているのかという視点で区別しました。
WebサイトからマニュアルのPDFデータをダウンロードできるようにしたり、CD-ROMにマニュアルのPDFデータを入れておく、というPDFマニュアルの提供方法を最近よく見かけます。
ネットワーク経由でソフトウェアをダウンロードしたり、CD-ROMを配付したりといった方法には、厚くて重い紙マニュアルの介在する余地は非常に小さくなります。
ましてや体験版やベータ版となると、マニュアル自体にコストをかけるわけにはいきません。
また、「あの機種のなくしてしまったマニュアルがインターネット上にあればなあ」と思われたかたも多いと思います。メーカー側としても、マニュアルを紛失してしまったユーザーのために、補修部品としてマニュアルをある程度の量だけストックしておくことにも多くのコストがかかります。
ところが、紙マニュアルをPDF化して配付することによって、こうした問題はある程度解決できるようになりました。ユーザーとしてもプラットフォームを選ばずに閲覧したりプリントアウトしたりできるので、メリットは大きいと思われます。
この側面でのPDFの役割は非常に大きいと言えるでしょう。
この形態には、配付するPDFの元データとして、すでに何らかの形で紙マニュアル用に作成したDTPのデータが存在するという前提があります。
しかし、紙マニュアルの定型サイズをAcrobat Reader上で100%表示するには、それなりの解像度が必要です。SVGAクラスの解像度の場合、A5の横サイズでギリギリ表示できるかどうかです（PDFの特徴である「しおり」を表示させてしまえば、間違いなく100%表示はできません）。実際にはA5サイズという面積に多くの情報を盛り込むことは難しいため、多くのマニュアルはB5サイズ程度の大きさをもっているのが現状です。
したがって、紙マニュアル用に作成されたDTPデータを単にPDF化しただけでは、解像度のあまり高くない表示デバイス上では、可読性に問題があるという結果になります。全体表示ではつぶれてしまい、実寸表示ではあふれてしまうというわけです。紙マニュアルをベースとしたPDFを配付するメーカーは、この点に注意しておかなければなりません。せめてVGAやSVGA環境で見るとどうなるかくらいのテストは、あらかじめ行っておいてほしいところです。
しかしそのためにDTPデータを修正していては、DTPデータの有効利用というPDFの利点を放棄するも同然で、PDFを利用する意味がなくなってしまいます。
基本的にこの問題は、可読性とコストのトレードオフということになります。配付形態およびPDFのマニュアルを利用する現状のユーザー層を考慮に入れると、可読性よりもコストメリットが優先される現状もやむを得ないでしょう。
実際には、紙マニュアルのPDFファイルはプリントアウトして使用するユーザーが多いので、可読性の問題が表面化しないだけとも考えられます。
それでは、PDFを電子マニュアルとして利用する場合についても検討を加えてみましょう。今までの話と違うのは、製品自体の正規マニュアルとして、PDFを電子マニュアルとして紙マニュアルの代わりに利用することです。紙マニュアルと組み合わせて使う電子マニュアルとしてPDFを利用する、という例もここではまとめて検討します。
紙マニュアルの代用案は、紙マニュアルのコストが馬鹿にならないため、コスト削減のためにコスト管理屋に特に狙われている節があります。
まずPDFのマニュアルだけということが決して認められないことは、これまで当研究所の研究発表を読んでいただいているかたには良くお分かりいただけるかと思います。
何らかのビューワーを必要とするメディアだけでマニュアルを提供することは、メーカーとしての責任を放棄していると言わざるを得ません。PDFマニュアル自体の導入ガイドと、（PDFで閲覧できない状況も十分に考えられるため）エラーへの対処のしかた、 − もちろん関連法規で規定されている情報も含めて − は必ず紙で提供する義務があります。
次に問題になることは、PDFがあまりに多くの表示面積を必要とすることです。先程、SVGAではA5横くらいが精一杯という話をしましたが、これはあくまで全画面表示の場合です。
実際には操作しながらマニュアルを見ることが必要になるため、電子マニュアル（特にヘルプシステム）としてPDFを利用する場合には、この点についてあらかじめ十分に検討する必要があります。特にワープロやDTPといった分野のソフトウェアでは、画面全体にソフトウェアのウィンドウを広げた状態で作業するため、ヘルプシステムによって占有されてしまう画面面積の大小は、ユーザーにとって重大な問題となります。
確かにPDFはアンチエイリアスがかかった美しい文字を表示できるのですが、一定面積に必要な情報を押し込む必要のあるヘルプシステムでは、この長所がかえって仇となります。小さな文字はアンチエイリアスによって表示が潰れてしまうため、ある程度の大きさをとっておかなければならないのです。
表示デバイス上の限られた面積の中で必要な情報を伝えるだけであるならば、各OSが提供しているヘルプエンジンを利用するほうが情報量／面積の効率が良く、可読性も優れています。また、最近とみに表現力の向上してきたHTMLを使用したほうが、実際のニーズにより近い場合すらあります。
最後に問題となるのは、これもヘルプシステムとして利用するときの話なのですが、PDFが使用しているソフトウェアとの連係を取りにくいことがあげられます。
使いやすさの向上という観点から見て、ソフトウェアとヘルプシステムの関係が、現在よりもより密接な連係を重視するようになってくることは疑いありません。あるツールを使うために必要な情報自体がそのツールに含まれている、という取扱情報のインターフェース化が進行し、システム自体がユーザーの操作を直接支援するようになってくる流れの中では、ソフトウェア側からヘルプの特定のページを表示させたり、ヘルプ側からソフトウェアの現在の状況を調べたりといったことが直接、間接を問わずできることが求められるようになります。
この面で見る限りでは、各OSの提供しているヘルプシステムがこのあたりの機能を強化していることと裏腹に、PDFのヘルプシステムとしての能力は心細く見えます。PDFがプラットフォーム非依存であることが裏目に出ている、と言えなくもありません。
何はともあれ、今後の流れを考慮に入れると、PDFでヘルプシステムを代用させるのは無理があるというのが、当研究所の判断です。
ここまで、実はPDFはマニュアルとしてはあまり使えないのでは？という話をしてきましたが、いくつかの分野ではメーカー、ユーザーともにメリットのある利用のしかたが考えられます。
まず考えられるのは、大多数のユーザーにとって必要なわけではないが、一部のユーザーには絶対必要、といった情報を提供するために利用するというものです。
一部のユーザーのためだけにマニュアルの部品コストがあがってしまうことを避けるために、比較的技術情報の色彩が強い分野をPDF化して提供するということが例として考えられます。
こういった分野の情報は情報量が多く、紙マニュアルにするとかなりのページ数をとってしまう割に、その情報を必要とするユーザーが極端に限られています。大多数のユーザーにはコストメリットを、情報を必要とするユーザーには必要な情報を、メーカーはコストダウンをそれぞれ手にするという寸法です。
次に、ヘルプシステムの代用と考えるのではなく、簡易マルチメディアタイトルとして利用するという方法も考えられます。
プラットフォームに依存せず、動画や音声も組み込め、最近のバージョンアップにより各種スクリプトでの簡易制御もできるようになったPDFは、マルチメディアタイトルの土台としても十分に機能しうると言えるでしょう。
Macromedia社のDirectorなどといった本職のオーサリングソフトウェアで制作されたタイトルには機能面や表現力で比較の対象になりえませんが、通常のDTPソフトウェアやワープロから書き出しできることを考えると、オーサリングの手間を削減しつつ、見栄えの良い簡易マルチメディアタイトルが作成できるというメリットは捨てがたいのではないかと思います。特に、文字を主体としたものであれば、PDFの作業性の良さ、表現力は絶対というものがあるのではないかと思えます。
いかがでしたか？
PDFをマニュアルとして利用する場合、どう使えばメーカー、ユーザー双方の利点になるのかということを、現状の問題点を中心に検討してみました。いろいろ不具合はあがりましたが、今回の研究発表はあくまで一般論であることを明確にしておきたいと思います。個別の環境においてはPDFが最適なソリューションであることも十分に考えられます。PDFはマニュアルとして決して使えないわけではなく、あくまで十分な事前検討が必要であることを認識しておく必要がある、というのが今回の結論です。
研究発表