FrameMaker 構造化（2）
前回の続きです。
文書の今後の展開をどう見積もることができるか？が重要ですね。そしてそれはクライアント側にしかできない見積もりです。
と言ったように、今後の文書の展開に対して
- どのように活用するか？
- 期限は？
- 費用は？
といったことを、大まかにでも想定することが肝要かと思います。
もちろんプロジェクトは変質していくものですし、最初からすべて把握できているわけではありません。ただプロジェクトにかかわる各個人の頭の中にあるイメージくらいは最初に吐き出しておくべきかと思います。
そして当然クライアントのお役に立てるようなものを構築していくのですから、自分勝手でもいけません。
「期限」「費用」については仕事の一般論になってしまいますね。でも一番重要なことですよね。
どのように活用するか？
情報の活用方法によって、そこにメタ情報として用意しておくものが変わります。文書の設計が変わるということです。
後々用途が変わったり想定していた状況のみでは対応できなくなったりといったことは、ままあることです。しかし、ある程度文書を作成してしまうと、その定義を後から変更するには工数が倍々で変わっていきます。プロジェクトの最初で知恵を絞って様々な状況を想定すべきかと思います。
技術的な想定はある程度外部の人間にもできますが、クライアント様の内部的な構想や都合は外部の人間には知り得ないものですので、この、「初期ミーティングで仕様を詰める」作業が、後々非常に重要な意味を持ってきます。
構造化したデータをどのように使用したいか、実際どのように使用できるか、（できれば）その効果はいかほどのものか、さらにその先は誰が（人や組織）関わり、どのように管理していくのが良いか、などです。使用方法や管理方法によっては、FrameMakerで構造化しないほうが良い場合もあります。
エディターとしてのFrameMaker
弊社は創業以来13年間（スタッフはそれ以前から）、FrameMakerを使用した業務に携わってきました。FrameMakerには長い歴史があり、それぞれの時代でエディターとして活躍してきました。
しかしFrameMaker6をシステムの中心に据えるには、解決すべき課題がありました。
- 他フォーマットへの展開
- ユニコード文字への対応
- アラビア語などへの対応
などが大きなところだと考えます。
1はver.6+SGMLでSGML、ver.7で統合されXMLに対応、2はver.8で対応され、3はver.13（FrameMaker2015）で対応されました。
つまるところ、FrameMakerをマルチパブリッシングの中心（あるいはその近く）に鎮座ましますものとして採用するのも「あり」ではないかということです。
更に、FrameMakerは「エディター」として活躍してきました。
その機能をも存分に発揮してもらえるというわけです。
「強力にXMLを取り扱え、エディターとしても高度に機能する」ことこそが、FrameMakerと他者を分ける境界線だと思えます。
とはいえ不満もあるんですよ。。。
細かいことではいろいろ。。。
しかしFrameMakerはそれを補って余りあるソフトウェアだと思います。