こうしたテクニカルコミュニケーションのためのドキュメント（テクニカルドキュメント）を扱う分野で、古くから利用されている著名なツールの一つに、アドビシステムズが提供する「Adobe FrameMaker」がある。一般的なワードプロセッサなど、ドキュメント作成のためのツールが数多くある中で、テクニカルドキュメントを扱うにあたって「FrameMaker」が選ばれ続けている理由は何なのか。
今回、実際にFrameMakerのユーザーであり、合わせて、FrameMakerを利用したシステムソリューションの提供も行っている、情報システムエンジニアリング（ISE）の黒田聡社長に話を聞いた。
FrameMakerが扱う「構造化ドキュメント」
――ISEでは現在、どのような事業を手がけているのでしょうか。
ISEは、1979年に設立したシステム開発会社です。テクニカルコミュニケーションに関する事業は25年ほど前から手がけており、現在ではシステム開発とテクニカルコミュニケーション事業の比率は、ほぼ半々になっています。
FrameMakerについては、Frame Technologyが扱っていた時代から、他社の競合製品も含めての評価や、それらを使ったテクニカルドキュメントソリューションの提供を行ってきました。
SIerとしての顔と、それを実際に使ってドキュメントを作ることができる企業としての顔という2つの側面があるのがISEの特長です。テクニカルコミュニケーションの分野については、大手メーカーに向けたシステムを導入したり、それを実際に運用する側と関わってコンテンツを作ったり、ユーザー企業が既存のサプライヤーさんとの間で、システムを使った業務フローを構築する際のお手伝いを、コンサルティングを通じて行ったりといったことをさせていただいています。
――FrameMakerを活用したソリューションとは、実際どのようなものなのでしょうか。
私（黒田）は、一般財団法人である「テクニカルコミュニケーター協会」の運営にも携わっています。この協会は、任意団体も含めて20年の歴史があり、電機メーカーやSIer、教育機関などを中心に、非常に幅広いジャンルの会員がいます。ここでは、テクニカルドキュメントの作成や運用のための効率的なツールの使い方や、より本質的な「テクニカルコミュニケーションとはどうあるべきか」といった議論が継続的に行われています。このテクニカルコミュニケーター協会で、5年ほど前にとったアンケートでは、会員の約25％が、ツールとしてFrameMakerを採用しているとのことでした。特に産業機器系での導入が多いようです。
FrameMakerの特長ですが、アドビが提供している「InDesign」をはじめとする他のツールは、主にコンテンツのビジュアル面や見た目のリッチさを訴求ポイントにしています。一方のFrameMakerは、ビジュアル面よりも、むしろ社内や特定のビジネスパートナーとの間で利用するコンテンツの管理や、メンテナンスの効率を上げていくことが目的のツールになります。
FrameMakerがその真価を発揮するのは、いわゆる「構造化ドキュメント」と呼ばれるものですが、FrameMakerには基本的な構造化支援機能が、はじめから用意されています。特別なCMSやDBなどと連携しなくても、導入コンサルティングの範囲内ですぐに、テクニカルドキュメントの管理ツールとして運用を始められるケースも多いのです。この手軽さが、FrameMakerが選ばれる理由の一つだと思います。
ただ、ユーザーの中には、すでに大量のテクニカルドキュメントを保有しており、バックエンドのCMSやDBなどと連携した、より高度な使い方をしたいというケースもあります。FrameMakerには、そうしたより大規模なシステムを構築するための基盤としての「安定感」もあります。
FrameMakerが長年支持され続けた理由
――テクニカルドキュメントを扱うシステム基盤としての「安定感」というのは、具体的にはどういうことでしょうか？
例えば、一般的なビジネスドキュメントの作成には、Office Wordのようなワープロソフトが使われるケースが多いと思います。こうしたワープロソフトは、個人が利用する際に使いやすい、パーソナルツールとしての使い勝手の向上を主眼に開発されています。典型的な例ですが、例えば環境設定などは、個々のユーザーが使っている端末に保存するというのが基本です。
テクニカルコミュニケーションの分野で扱われるドキュメントの世界では、複数の人が共同でドキュメントを作ったり、ある人が作ったドキュメントのメンテナンスを他の人が引き継いでいったりするというライフサイクルが前提になります。そのような場合に、パーソナルでの使い勝手を主眼にしたワープロのようなツールでソリューションを作ろうとすると、ソフトに起因する制限や、対応が難しい部分が、どうしても出てきてしまいます。
FrameMakerはその点、はじめからテクニカルドキュメントを扱うことを前提に作られているため、そのためのシステムの基盤として標準化しやすいのです。分業体制で作られるドキュメント、あるいは、5年以上の長いライフサイクルを持ったドキュメントを扱う場合も、安定したエンジンを供給できる点がポイントです。
――先ほど、FrameMakerは産業機器系での採用が多いとのお話しがありましたが、どのような理由があるのでしょうか。
FrameMakerのようなドキュメントツールは、当初、半導体や航空機のような製造業で多く使われていました。ただ近年、特にアドビの製品になってからは、社会的な環境の変化もあって、ユーザーの傾向も変わってきました。背景には、産業に関する法律やガイドラインが整備され、産業機器に求められるドキュメントの具体的な要件が固まってきたという事情があります。
一般に「可用性」という言葉で表現されるのですが、例えば、医療機器に関しては製品が出てから15年間、そのドキュメントをメンテナンスし続けることがメーカーに求められるようになっています。産業機器については、企業がそれを導入し、減価償却が終わるまでの期間については、メーカーの責任として、そのドキュメントをメンテナンスしなければなりません。
ITをベースにしたドキュメントソリューションには、求められる期間の間、安定して利用できるものが要求されるようになっています。そうしたシステムを構成する要素としては、頻繁にバージョンアップが行われ、仕様が変化するワープロソフトではなく、標準化された仕様に基づいてドキュメントを扱え、そのエンジンが安定しているという点でFrameMakerが好まれるというわけです。
近年、半導体や航空機のような非常に大規模なドキュメントを扱うソリューションは、どちらかというと「文書管理」から「データ処理」へと、主軸が移ってきています。それよりも若干規模が小さい、産業機械、医療機器といった中規模の分野では、FrameMakerが持っているドキュメントハンドリングのポテンシャルを十分に発揮できるケースが増えてきていると思います。
他にはない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を扱う技術者、開発者に対する技術面でのサポートを、引き続き充実させていってくれることを、アドビには望みたいですね。
