他にはないFrameMakerならではの強み
――ワープロソフトとFrameMakerの違いについては、よく分かりました。では、他のテクニカルドキュメントツールと比較した場合に、FrameMakerの利点はどこでしょうか。
近年、さまざまな分野で「ドキュメントの電子化」が叫ばれています。ただ、10年後、20年後に電子化された文書がきちんと保全されている環境がどのようなものかについて考えたとき、現状、PDFの代替になるものがない状況です。
しかし、他のツールを利用した構造化ドキュメントのソリューションに、PDFを生成できる環境を組み入れようとすると、PDF作成エンジンを導入するコストが別にかかってしまいます。これはアドビ製品であることの強みですが、FrameMakerでは、フロントエンドで直接PDFを生成することができます。
さらに、共同でドキュメントを作っていく環境では「校正」のワークフローを入れる必要が出てきます。これを、例えばHTMLベースでやろうとすると非常に面倒なのですが、FrameMakerを利用していれば、PDFの生成はFrameMakerでやり、レビュー環境にはAcrobatや無料のAdobe Readerを用意しておけば、簡単に履歴が残る「校正」のフローを組み入れることができます。標準でPDFを生成できる機能があるというのは、非常に大きなメリットだと思います。
PDF以外の出力フォーマットも多彩です。ドキュメントの電子化は、BtoCの分野ではかなり進んだ印象がありますが、BtoBの世界、特に役所に対しての申請や届出といった分野では、まだまだ「紙」への出力が必要になるケースが多いです。FrameMakerは、先ほどのPDFへの出力に加えて、紙への出力を適切に行うための機能もあらかじめ持っています。
さらには、EPUBやHTML5といった形式への変換機能もあります。そして、これもアドビの製品である「RoboHelp」と連携することで、Windowsのヘルプファイルを容易に生成できるという強みがあります。
ドキュメントを閲覧する環境は、技術の進歩によって変わっていきますので、こうした部分に着実に対応してもらえているのは嬉しいですね。
――そのほかにも、システム開発会社とユーザーとしてのそれぞれの視点で、FrameMakerの良い点があればお聞かせください。
ドキュメントというと「文字」のイメージが強いかもしれませんが、例えば、産業機器に関するドキュメントでは、図面やテクニカルイラスト、CADデータなどを大量に扱います。こうしたオブジェクトを、サイズや点数が大きくなってもドキュメントの構成要素として安定して扱えるエンジンを持っている点も良いですね。
また、フロントエンドとしての扱いやすさも、FrameMakerを採用する大きな理由になっていると思います。近年、技術情報を扱うためのXMLアーキテクチャである「DITA（Darwin Information Typing Architecture）」なども標準化されましたが、一般的なXMLエディタは、構造化ドキュメントに関するかなり専門的な勉強をした人でないと、扱いが難しいのが実状です。こうしたXMLオペレーターの育成も、テクニカルコミュニケーションの分野では一つの課題です。
ただ、一般的な企業では、そうした専門性を持ったオペレーターを、専任でドキュメント管理にあてることは難しい状況です。主業務のかたわらに、ドキュメント管理をやっているというケースがほとんどだと思います。その点で、FrameMakerは、前出のDITAを含む構造化ドキュメントをきちんと扱え、他のシステムとの連携も可能でありながら、非常にユーザーフレンドリーなインターフェースを持っている点もポイントです。内部ではしっかりとドキュメントを扱いつつ、フロントの使い勝手は一般的なワープロソフトとそれほど変わらないという環境を実現できるのです。
企業がやりたいのは、「構造化ドキュメントを効率的に作り、管理する」ことです。場合によっては、それをグローバルに展開する必要があるケースもあります。あくまでも導入する側は、その際のコストや効率、生産性を考えます。その点で「効率」と「正確性」さらに「生産性」が価値を持つ現場には、FrameMakerは受け入れられやすいのではないかと思います。
価値を持つ現場と非常にマッチする』と語る黒田氏
FrameMakerが広げるビジネスの可能性
――主にビジネスアプリケーションのようなシステム開発の現場では、FrameMakerにどのような利用形態が考えられるでしょうか。
個人的な印象ですが、システムエンジニア個人が、開発のための仕様書のようなドキュメントを、1人で大量に作りたいという場合には、他にも適したソリューションがあるかもしれません。
一方で、社外とコミュニケーションするためのドキュメント、例えば、開発会社とそのクライアントとの間で、責任分担を明確にするためのドキュメントや、リスクマネジメントのようなコミュニケーションの分野では、FrameMakerのようなツールが使える場面が増えてくると思います。
――FrameMakerをフロントエンドとするようなシステムソリューションは、導入も大規模なものが中心になるのでしょうか。
そうとは限りません。ISEとしては、まず「ドキュメントの構造化」そのものを、FrameMakerでスムーズに行えるよう、コンサルティングベースのサポートからスタートするケースが多いですね。FrameMakerには、基本的な構造化機能、変数の機能、異なるファイル形式のオブジェクトを1つのファイルにまとめて管理できるような機能が用意されており、それらだけで運用を始められるケースも多いのです。
まずは導入し、運用を進めていく中で、新しい機能が欲しくなってくるケースも出てきます。例えば、テクニカルコミュニケーションの世界では、用語の統一や禁則表現などの校正を適切にやる必要があるので、それを支援するための環境作るといったことも考えられます。ISEでは、ジャストシステムが提供している校正支援ツール「Just Right!」をFrameMakerの環境に組み入れるといったソリューションも提供しています。この連携のニーズは高いですね。このようなカスタマイズの自由度が大きく、そのためのツールキットが提供されていることもFrameMakerの特徴の一つです。
さらに、ドキュメントを扱う人数が増え、データが蓄積されてくれば、排他制御が必要になり、DBやCMSなどとの連携を考える必要も出てくるでしょう。このように、非常に小規模で運用を始め、段階的に規模を拡張していくことも可能です。必要に応じて、実際にドキュメントを作る現場でのサポートも、ISEでは行っています。こうした分野でのノウハウには、一日の長があると自負しています。
――今後のFrameMakerに対して要望があればお聞かせください。
これまでも繰り返し述べてきましたが、FrameMakerが求められる現場というのは、「長期にわたって保存し、メンテナンスを続けなければならないドキュメント」を扱う現場です。なので、まずはファイルの互換性、安定したエンジンを今後も維持し続けてほしいという点です。
付加価値としては、現在でも新たな標準フォーマットや出力デバイスへの対応が行われていますが、今後も主流になるかもしれない新しい標準やデバイスが出るようなことがあれば、そうしたものへの対応を迅速に行ってほしいです。
今後、テクニカルドキュメントやテクニカルコミュニケーションの世界がどのように変化していくかは分からない部分も多くあります。技術的な変化も急速です。しかし、その中で、長期にわたって保存、管理しなければならないドキュメントを、効率的に扱っていきたいというニーズは変わらないはずです。そのためのシステムを維持していくためにも、FrameMakerを扱う技術者、開発者に対する技術面でのサポートを、引き続き充実させていってくれることを、アドビには望みたいですね。
