構造化FrameMakerを使って多言語展開ドキュメントを制作する理由

多言語に展開するドキュメントを制作する方法としてもっとも標準的なのは、 XMLで内容を記述して、何らかの方法で読みやすい形式(PDF,HTML等)に変換する という手法だと思う。

実際オープンソースのソフトウェアで成功しているプロジェクトの多くは多言語に対応したヘルプを制作するためにこの方法を利用している。 (たとえば GNOME Documentation Project など)

プログラマの立場でマニュアル制作会社と関わってきて疑問に思ってきたのは、 どうしてそんな非効率な方法でドキュメント/マニュアル制作をしているのか？ということ。

従来型DTPからの脱却を目指す

Word,InDesign,非構造化FrameMakerでの制作...ほとんどは信じられなくくらい大変なDTP作業をしている。DTP作業者への指示を作成する人は大量に紙を消費して(緑を大切に...)ドキュメントを印刷して机に山積して赤入れをしている。顧客からの要求はうつろいやすく、常に厳しい納期を要求される...追加変更が入っても、納品日だけは変更されない... そんなデスマーチ状態が延々と繰り返される。

確かに、日本語だけのドキュメント、日本語と英語の2言語展開だけのドキュメント制作では、従来型のDTPで制作するのはコストに見合うと思う。 しかしそれ以上の言語へ展開する場合で、ページ数が100ページを超えるようなドキュメントの場合、 間違いなくXMLで内容を記述して、構造化FrameMakerを使ってフォーマットした方が効率的だと思う。何より、拷問のような作業から制作者が開放されるという意味で（たとえ同じコストだったとしても）精神衛生上望ましいはずだ。

何より、日本の人件費はとても高い。もし、中国へのオフシェア制作などが普及すれば到底立ちゆかなくなるに違いない。たとえ、DTPを外注化しとんでもない安い時給で仕事をしてもらったとしても、従来のDTP作業方式では難しいのではないか。 そして翻訳プロセスなどは既に中国等へのオフシェア制作が行われているのではないだろうか？

XMLのフォーマットに構造化FrameMakerを使う理由

XMLのフォーマットといえば、XML-FOがある。

Apache FOP というフリーの実装や XML-Formatterという商用版のXML-FO製品（アンテナハウス） がある。

XMLで内容を制作して...方式（以下方式Xと呼ぶ）を具体的なプロジェクトで実践する以前は、プログラマ的な判断としてXMLのフォーマットはXML-FOで問題なんじゃないか？と思っていた。とはいえ、関係者への説得などを考えるとネームバリューがある AdobeのFrameMaker を使った方がよい... という程度の認識だった。

しかし方式Xを実践してみた結果AdobeFrameMakerがXML-FOよりいくつかの点で良いことがわかった。

• EDDやテンプレートを使ってフォーマットを設定するのだが、これが従来型DTP作業に近いため現場で導入しやすい。
• 制作会社やましてやお客さんでXML-FOを知っている人があまりいない（信用を得るためのコストの問題）。
• 納品データがFrameMaker形式で、という条件が設定されていることがある。
• FrameMakerはVersion9 までバージョンアップされている商用ソフトウェアのことだけはあり、厳しい顧客からの要求に耐えられる機能が用意されている。
• FrameMakerがサポートしていないから、というエクスキューズが使える。
• フォントのサポートがある。（たぶんXML-Formatterのような商用版XML-FOでは問題ないとは思いますが）
• 最終的にタッチアップによる手作業でのレイアウト修正対応が可能であること。

実践してみてわかったのは、顧客からの容赦ないレイアウト要求がある、ということ。XMLのフォーマットというと title要素はタイトル的に...というように要素ごと/要素の出現位置に応じたスタイルを設定のようなルールベースでフォーマットすればよいという印象がある。（実際のところHTML/XHTMLのCSSによるフォーマットはそんな感じだ。）しかし、紙媒体用のフォーマットはそういうルールベースのフォーマットだけでは済まない。ひとまとまりの情報を適切なページ内に（たとえば見開きとか）収めていくための 詰め 作業が必須になる。タイトルが長くなって折り返すなら長体をかけて一行に収めなければならないし、そういうルールベースでレイアウトをコントロールできない部分の対処が必要になる。

レイアウト指定全体からすれば1割程度のことだが、この部分の対処に非常にコストがかかってしまうのだ。