FrameMakerコラム

合成の誤謬 (Fallacy of Composition)

いままで述べてきたことは「個々には正しくても、集うと正しくない様」という状況ですので、合成の誤謬ごびゅう (Fallacy of composition) と呼ばれる、経済学や論理学で使われる概念に非常に近いかと思います。
合成の誤謬とは、個々の要素にとっては正しいことが、それらの要素が集合した全体にとっても常に正しいとは限らない、という考え方です。逆は「分解の誤謬」と呼ばれます。

なぜこのような状況が起こるのか？

この現象が起こる主な理由は、部分最適が全体のシステムに影響を与え、その結果として予期せぬ、あるいは望ましくない全体の結果が生まれるためです。個々の機能が独立しているのではなく、複雑に絡み合っている場合に起こりやすくなります。

またこの状況は非常に認識しにくい場合が多く、CCMSの場合においては

• 個々の機能は「正しく見える」から
• 結果が間接的・遅れて現れるから

の2点が大きな原因だと思います。
個々に謳われる機能は素晴らしいが、実際のところは、運用してみないとわからない。という状況です。
CCMS導入検討の判断材料は不足しているとお思いではないでしょうか。

実際の運用は？

ドキュメントの内容を細分化して管理し、複数の（可能な限り多くの）ドキュメントで共有したり、翻訳の進捗管理したりするのはとても良いアイデアです。

ただ、実際に運用するには細分化も共有ドキュメントの数も制限する必要があるでしょう。
進捗管理しているがゆえに作業が煩雑になる可能性もあります。

また、個々の機能が複雑に絡み合っているので、全体を把握している人間でないと判断が難しくなる可能性があり、結果として属人性が高まる傾向にあります。
CMSではアクセス権を詳細に定義することができ、分業を促進することもメリットとして考えられていますが、実は分業することで全体の効率が落ちるのではないか？ということです。

FrameMaker案

で、あれば、FrameMakerでよろしいのではないでしょうか？

• 印刷用データ（PDF）のデザイン性については推して知るべし。FrameMakerに一日の長があると思います。
• HTMLなどのWebデータへの変換も、XML化し変換プログラムを介せば自由度は高いです。
• 複数モデル間でのデータの共有は、コンディショナルテキスト機能で、ある程度は実現可能です。共有の規模感については、CMSでも実際の運用段階では規模を縮小する必要があることを考えると、一考の価値はあると思います。
• 翻訳については、FrameMakerはmif形式（Maker Interchange Format）で対応します。同ファイル内でのイラストキャプションもmif一枚に含まれていますので、別手配の必要はありません。
• バージョン管理は、バージョン管理ソフトに任せたらどうでしょうか。
• 費用面（ROI）について単純比較はできませんが、FrameMakerと比較すれば、CCMSは一般的に高額であることが多いのではないでしょうか。

まとめ

勘違いしていただきたくないのは、今までの論は、決してCMSを否定するものではないという事です。
場合によると思うのです。適材適所です。

得てしてグローバルな企業において、「すでに海外で運用されているものとフォーマットを合わせる必要がある」「今後長期にわたってドキュメントを残していくために、世界的に運用されているフォーマットを採用する」などのCCMS採用理由を聞き及んでいます。
それぞれの組織、企業様においてそれぞれの理由があるはずですから、それに対してどうこう有りません。

ただ、CMSを導入すれば自動的に業務が効率化され、費用が削減され、品質が良くなる。と、お考えであれば、それには一石を投じたい。と、思う次第です。

お互いのためにも。

このページをお読みの皆様はCMSを導入している、あるいは検討しているのではないでしょうか。CMSの魅力についてはよくご存じのはずです。
あくまで弊社の経験に基づき、皆様の参考になるように記述します。
CMSが特に大きな効果を発揮する場面があることは承知しています。しかし一般的に高額なCMSの導入は一旦立ち止まって再考してみませんか？というのが弊社の立場です。

CMSというと範囲は広いですが、マニュアル制作の現場ではCCMS（Component Content Management System）を指すことが多く、情報をコンポーネント化して統合的に管理するとされています。

• コンポーネント単位でのコンテンツ再利用
• 多言語管理
• 配信機能
• ワークフローと共同作業のサポート

上記が一般的に言われているCCMSのメリットの代表的なものではないでしょうか。実現したら便利そうです。

課題の多くは、CCMSの機能自体よりも組織の実際の運用や業務フローにどう落とし込むかだと思います。場合によっては運用体制の見直しを伴います。

以下、課題の例です。

共有コンテンツ管理の複雑性

コンポーネントの粒度が小さすぎると（例えば「段落（一文）」単位）、「コンポーネントの共有」の管理が困難になります。

システムが共有部分を一覧にしてくれるかもしれません。しかし共有部分が100ならまだしも、10,000あったら一覧からピックアップするのにも困難を伴います。

一般的には、「項」や「節」といったタイトルとその内容を共有可能な最小単位とすることが多いのではないでしょうか。

ある記述を一部変更した際に、それが多くのモデル文書すべてに自動反映されるのは効率的ですが、実際にすべての記述を一律に更新して良いのか、公開しているPDFなどのメディアとデータとの間に齟齬が生じないかといった問題があります。

例えば、50モデルはバージョンA、25モデルはバージョンB、残りはバージョンCというように、製品のバージョンによって共通コンテンツの適用範囲が異なる場合など、複雑なバージョン管理が必要となり、どの文書をどのバージョンにすべきかを誰かが把握している必要があります。

誰が把握すべきでしょうか。

システムがその情報が共有コンテンツであるかどうかを明確に教えてくれるかという疑問もあります。オペレーターが共有コンテンツであることを把握していなければ、意図しない変更が行われる可能性があります。

それを回避するために、共有コンポーネントである可能性を知りながらも新しいコンポーネントとして登録するというオペレーションが行われるというようなことも起き得ます。
結果として共有されません。

差分翻訳の課題

CCMSは変更があったコンポーネントのみを翻訳に回すことでコスト削減を謳いますが、誤字脱字のような小さな修正でも変更として捉えられ、「要翻訳」と判断される可能性があります。
それは良いとしても、特定のコンポーネントについて「この部分だけはこうする」といった翻訳の指定がある場合、翻訳文を指定する資料作成や翻訳後の修正、翻訳メモリ（TM）の修正といった煩雑な工程が必要になります。

翻訳が必要なコンポーネントが文書A、文書Bで共有されている場合、文書Aの翻訳中はロックされ、変更不可能になったりします。文書Bで急ぎの修正が必要な場合にも文書Aの翻訳終了を待つ必要があり、急な想定外の修正に対応できない場合があります。

これに対して、ロックを解除し修正を行えば、そのこと自体を誰かが記憶し管理していないと、文書Aの翻訳が終了しシステムに取り込まれたとき、修正前のコンポーネントで上書きされる可能性があり、想定外の結果を招くかもしれません。業務時期のずれによってはこれらの把握が困難になります。

既存訳の再利用は一貫性を保ちますが、例えば、日本語の「これ」が英語では具体的にモノを指す方が望まれる翻訳だったり、言語によっては前後の文脈で翻訳が異なる場合があります。

言語は文化です。正しく翻訳しようとすれば、このような「例外」も理解した上で翻訳を手配する必要があり、翻訳メモリ（TM）側での複数訳文の登録も必要になります。
それに既存訳の再利用は、翻訳支援ツール単体でも実現可能です。

運用体制と責任の所在

共有コンテンツの変更に関する意思決定や、どの文書のどこに共有部分があるのかの管理、そして望まない結果になった際の責任の所在が不明確になることがあります。

社内、一部署でCCMSを運用していれば容易かもしれませんが、複数部署が関わっている場合、作業が外注化されている場合、どこでどのような判断をするのでしょうか。

上記を踏まえれば、CCMSが提供するメリットを最大限に引き出すためには、「ドキュメント作成対象のモノを詳しく知り、CCMSの仕組みと操作方法を詳しく知り、その上責任も取れるスーパーマンが一人でデータを作成する」というオペレーションが必要ではないでしょうか。

これらの課題を解決しようとするなら、CCMSを導入する際に、ツールの機能の習得だけでなく、組織側の業務プロセスや体制をCCMSに合わせて見直し、構築する必要があるかもしれません。

（続く…）

FrameMakerとInDesignの特長は、よく次のようにまとめられます。

• FrameMakerは、大量のテキスト、頻繁な改訂、厳密なフォーマットの一貫性、再利用性が求められる技術文書の作成に非常に強力です。
• InDesignは、デザインの自由度、視覚的な魅力、柔軟なレイアウトが重視される出版物や広告物の作成に最適です。

良くまとまっていると思います。

ではなぜ組織の文書作成の際に、いまだにFrameMakerとInDesignが選択肢として挙がり、比較対象になるのでしょうか。

FrameMakerもInDesignもどちらもXMLを取り扱えるとアプリケーションの説明でしているのが原因のひとつだと思います。

他の機能もそうですが、情報を検索して記事を読んでも、具体的にどこがどのように異なるのか実感できないし、その記事は最新のバージョンにも当てはまるのか？誰か教えて！！と、お思いではないでしょうか。

InDesignでのXML

「あらかじめきちんと設定することによって」と言っているように、InDesignはレイアウトがあらかじめ決まっていて、XMLが用意されている場合（名刺、カタログ、新聞etc.）には威力を発揮します。

「XMLをドキュメントに自動的に配置できます。」いわゆる自動組版ですよね。上記では「自動化レイアウト」と呼んでいます。

それをワークフロープロセスの一部として使用すると、生産性が向上する、と。その通りだと思います。そしてその様なデザイン性を持つ、相応のアーティスティックな作業を伴う“DTP”が、ユーザーの華やかなメインストリームだと思います。

そう、FrameMakerは日陰者なのです。

でなければ、AdobeのFrameMakerへの仕打ちが説明できません。
Creative Cloudにも組み込まれていないし、Adobeのホームページに行っても、そう簡単に姿を現してはくれません（涙）

…ついでに言っちゃいますが、2025/5/21現在、FrameMakerはサブスクリプションでしか購入できません。ここから購入の手続きが行えます。

上記ページを閲覧できた方、衝撃的ではないですか？月々で支払う12ヶ月よりも、年間一括で支払う方が高額という。。。これには驚きました。そしてこれは記載ミスではないのです。（Adobeに問い合わせ済み）

…横道にそれてしまいました。

InDesignでもXMLの扱いは、XML、InDesignテンプレート、それぞれがほぼ完全に出来上がっている状態で説明がなされていることが多いです。

私の認識で言いますと、InDesignはXMLフォーマッターです。

FrameMakerでのXML

スケーラブルで強力なオーサリング機能
単一の強力なオーサリング環境で、複雑な構造化コンテンツと非構造化コンテンツの作成や更新を簡単に行うことができます。直感的なナビゲーション機能とWYSIWYGビュー、テンプレートベースの環境でリッチメディアを挿入するための各種ツールにより、魅力的なドキュメントを効率的に作成することができます。

Adobe DITAWORLD 2025 から引用

一方、FrameMakerはXMLフォーマッターであると同時に強力なXMLエディターです。まさに「直感的なナビゲーション機能とWYSIWYGビュー」を併せ持ったエディターです。

これはことのほか重要で、WYSIWYGビューを持ったXMLエディターをFrameMaker以外にほとんど見ません。そしてエディターですので、簡単に内容を追加し、削除し、変更し、更新することが可能です。

内容の量が変わっても構造が変わっても定義内なら何ら問題は無いのです。

このあたりがInDesignでのXMLと根本的に異なるところではないでしょうか。

FrameMakerはよくInDesignと比較検討されます。「何が違うのか？」と聞かれます。

ひと言でいうと、「目的が違う」ソフトと言えそうです。

確かに、段落スタイル、文字スタイル、相互参照など基本的な機能面では似ています。相互参照などはその昔InDesignには搭載されていませんでしたが、バージョンを重ねるごとに便利になり、今では基本的な機能の種類に差は無いように見えます。

印刷やデジタルパブリッシング用のプロフェッショナルページレイアウトアプリケーションである Adobe InDesign では、印刷、web およびタブレットアプリ用の幅広いコンテンツをデザイン、プリフライト、パブリッシュできます。また、テキスト編集の正確なコントロール、ビルトインのクリエイティブツール、直感的なデザイン環境が用意されており、Adobe Photoshop、Illustrator、Acrobat および Adobe Animate と密接に連携して使用できます。

InDesign／よくある質問 から引用

うーん、おっしゃるとおりです！！
日本語の扱いに関しては圧倒的にFrameMakerよりInDesignの方が優れています。そもそもFrameMakerは縦書きができませんし。
そして、「直感的なデザイン環境」。これも頷けます。グラフィック関係機能も充実していますし、参照で取り込むAdobe Illustratorファイル（.ai）の大きさを内容で認識します（FrameMakerはアートボードで認識します。こちらの方が問題！！.epsはどちらも内容で認識します）。

Creative Cloudに含まれてもおり、例えばDTP環境を整えるときに選択肢に上りやすいことは間違いありません。

InDesignが素晴らしいソフトであることは疑いようもありません。

個々の機能にも機能差はありその説明は他の資料に譲るとして、これからはXMLとの関係性において言及したいと思います。

PS:
ちなみに、FrameMakerでの参照グラフィック（インセット）には、.aiがおすすめです。.epsでは表示があまりにもぼんやりしていて、FrameMakerのグラフィック機能でキャプションを入れることすらままなりません。
しかし、.aiにするなら内容の大きさでアートボードを切るか、正確にアートボードの中心にイラストを描くしかありません。
対策としては、内容の大きさでアートボードを切るIllustratorスクリプトを作るのが良いと思います。
とはいえ、InDesignでは実現しているのですから、FrameMakerでも改善していただきたいことのひとつです。

さらにPS:
過去のコラムを見てみたら、「FrameMakerとInDesign」というタイトルで書いていますので、もともと「FrameMakerとInDesign」というこのコラムのタイトルを変更しました。

前回の記事で、「次回はやっぱりEDDに手を付けるのがよさそうでしょうか。。。」などと宣ってからはや6年が過ぎようとしています。

あまりに時間がたち過ぎてしまいましたが、弊社は元気に活動しています。

変換表とEDDは密接に関係していますが、業務フローの中に変換表を組み入れるためには、スクリプトの存在も忘れてはいけません。

前回の記事でも指摘しましたが、定義通りの完璧な非構造化文書は無いという立場です。

であればその、定義から外れた段落やオブジェクトを拾い上げる必要があり、それをスクリプトが担います。

また定義通りの完璧な文書であったとしても、同じ段落書式が同じエレメントに変換されるかは、状況によります。同じ段落書式が適用されている段落であったとしても、異なる用途を持つ場合があるからです。

その場合、異なるエレメントに変換させるために変換条件を一意にする必要があり、そのためにスクリプトが活躍するはずです。

スクリプトの力を借りないのであれば手動で行う必要があり、その作業はボリュームの大きいものになってしまう可能性が高いので、業務フローの流れの中に組み込むにはハードルが高いのではないかと思います。

ということで、FrameMakerのhelpを読む限りでは変換表を作成することによって、FM非構造化文書が簡単にFM構造化文書に変貌を遂げるように思いますが、実際の業務に耐えうるためには「変換表」「EDD」「テンプレート」「スクリプト」の開発が必須と言えると思います。

とはいえ！！この「変換表」という仕組みがあることでかなりの部分が自動化され、時間と費用、いわゆるコストの削減に寄与していると思います。さすがFrameMaker！

開発依頼は弊社まで！

当然ながらFrameMakerのヘルプトピックに変換表の記事がありますので開いてみます。

変換処理では、FrameMaker 書式コンポーネント（段落タグ、文字タグ、マーカー、相互参照、表コンポーネントなど）から、構造化エレメントを作成します。

FrameMaker (2017 release) ヘルプ から引用

その通りですね。「変換処理」とは非構造化文書を構造化文書にする処理ですから、まず非構造化文書を開きます。その非構造化文書は、

変換処理を開始するには、内容を代表するような非構造化文書を選択します。 この文書には、文書に出現しうるあらゆる書式タグの例が含まれていることが理想的です。

FrameMaker (2017 release) ヘルプ から引用

そうです。「内容を代表するような、文書に出現しうるあらゆる書式タグの例が」含まれている文書を変換前文書として選択します。

選択します、といっても「文書に出現しうるあらゆる書式タグ」が網羅されている文書ファイルが存在し且つそれをすぐ選択できる状況は稀ではないでしょうか。

ということで、出来るだけ全文書（構造化すべきブック内全コンポーネント）を通して出現しうるあらゆる書式タグのうち、全書式タグを使用していなくても最も多いであろう文書を選択します。

つまり、この時点でFrameMaker書式コンポーネント（上記参照、Adobe談）について適切に管理されていることが望ましいといえます。

しかし待ってください。そんなことってあるでしょうか？
わが組織の既存文書の書式コンポーネントはすべて適切に管理され、登録されていない段落タグ（段落書式）などなく、書式の上書き（オーバーライド）も皆無で、適切な個所に適切なタグが設定されているのは間違いない！！
という方は、問題ないです。失礼しました。

往々にして歴史のある文書には様々な理由で様々な書式が入り乱れているのが普通だと思っています。
書式は入り乱れているのに表示（見栄え）だけは統一されている場合はオーバーライドされている可能性が高いですよね。

次の画像をご覧ください。

新規作成文書にデフォルトで作成される段落書式を文書に現わしたものですが、「謎の段落」という段落書式は登録されていないことがわかると思います。

この「謎の段落」という段落書式に対する対応も「変換表」には挿入されます。ファイルは以下です。
サンプル文書

逆に

FrameMaker は、文書をスキャンして、この文書中に出現する書式コンポーネントのリストを作成します。 リストには、書式設定カタログで定義されているが、文書では使われていないタグは含まれません。

FrameMaker (2017 release) ヘルプ から引用

ということで、書式が定義されているかどうかではなく、文書で使用されているかどうかが問われます。

ただ！！

むつかしく考えなくてもオッケーです。変換表は「更新」することが可能だからです。

ということでまずは、

1. 「どちらかというと他の文書ファイルより色々な書式が使用されていそうな文書ファイル」を開きます。
   サンプル文書に EDD からエレメント定義を取り込まなくても、とりあえず今は問題ありません。
2. 構造／ユーティリティ／変換表を生成を選択し、「新しい変換テーブルを生成」を選択し、「生成」をクリックします。
   メニューコマンドに関しては、バージョンで異なるので適宜読み替えてください。

変換表が生成されました。

「Wrap this object or objects」列の元文書の内容を「In this element」列のエレメントでラップします。

「With this qualifier」列は、修飾子です。見分けるためのフラグ、グループ分け、ですね。「In this element」列のエレメントは同じでもグルーピングの種類が異なる場合に便利です。これをまた後でラップするわけです。

生成された表は3列ですが、変換表開発時に役に立つ4列目を追加しておきましょう。ヘッダは「Description」です。開発途中のメモ列として活用すると便利です。というかこの列が無いと、複雑な変換になったときにミスが起こりやすくなりますし、後から見たときにわかりやすくなります。

「In this element」列にはEDDで定義されたエレメントを記入するわけです。。。。

結局、すでにEDDが開発済みである必要がありますね。。。とはいえ、変換表の前半終了です。次回はやっぱりEDDに手を付けるのがよさそうでしょうか。。。

というわけで、構造化していきましょう。

「構造化」という言葉の定義は横によけておいて、XML化と捉えてくださっても良いと思います。（「XML化」という言葉の定義も避けておきます。実際、FrameMakerでタグ付けしても、それがXMLそのものというわけではありません。）

新規で文書を作成するにしても、既存文書を構造化するにしても、文書全体の把握は欠かせません。

パターンの把握

前々回の記事と重複しますが、まず既存文書のパターンを把握しましょう。
文書といっても多岐にわたりますので、数百ページのオーナーズマニュアルを念頭に置いて進めていきます。

大→小で攻めていきましょう。ブック構成というやつですね。

ブック構成

本全体の構成は良いでしょうか？
章の並び、情報の過不足、問題ないでしょうか。
目次は複数（総目次、目次、章目次など）必要でしょうか。索引はどうでしょう。
トラブルシューティングは？用語集は？

問題なければ、次に進みましょう。
問題が発見されれば構成を再検討してください。

この辺りは各組織によってまちまちでしょうから、軽く触れるだけにとどめます。

章構成

通常メインの文書になります。

既存の非構造化FrameMakerファイルを構造化するには「変換表」を利用すると、作業が簡素化されます。（すべての内容が自動で構造化されるわけではなく、手作業は必ず必要になります。）

。。。ここで「変換表」の詳細に入っていこうかと思いましたが、「変換表」を説明するためにはまずEDDを理解している必要があるのではないか。。。などとも思いました。

結局、追ってEDDも出来る限り解説していくつもりですので、変換表を先にやっちゃいますね。次回ですけど。

前回の続きです。

文書の今後の展開をどう見積もることができるか？が重要ですね。そしてそれはクライアント側にしかできない見積もりです。

と言ったように、今後の文書の展開に対して

1. どのように活用するか？
2. 期限は？
3. 費用は？

といったことを、大まかにでも想定することが肝要かと思います。

もちろんプロジェクトは変質していくものですし、最初からすべて把握できているわけではありません。ただプロジェクトにかかわる各個人の頭の中にあるイメージくらいは最初に吐き出しておくべきかと思います。

そして当然クライアントのお役に立てるようなものを構築していくのですから、自分勝手でもいけません。

「期限」「費用」については仕事の一般論になってしまいますね。でも一番重要なことですよね。

どのように活用するか？

情報の活用方法によって、そこにメタ情報として用意しておくものが変わります。文書の設計が変わるということです。

後々用途が変わったり想定していた状況のみでは対応できなくなったりといったことは、ままあることです。しかし、ある程度文書を作成してしまうと、その定義を後から変更するには工数が倍々で変わっていきます。プロジェクトの最初で知恵を絞って様々な状況を想定すべきかと思います。

技術的な想定はある程度外部の人間にもできますが、クライアント様の内部的な構想や都合は外部の人間には知り得ないものですので、この、「初期ミーティングで仕様を詰める」作業が、後々非常に重要な意味を持ってきます。

構造化したデータをどのように使用したいか、実際どのように使用できるか、（できれば）その効果はいかほどのものか、さらにその先は誰が（人や組織）関わり、どのように管理していくのが良いか、などです。使用方法や管理方法によっては、FrameMakerで構造化しないほうが良い場合もあります。

エディターとしてのFrameMaker

弊社は創業以来13年間（スタッフはそれ以前から）、FrameMakerを使用した業務に携わってきました。FrameMakerには長い歴史があり、それぞれの時代でエディターとして活躍してきました。

しかしFrameMaker6をシステムの中心に据えるには、解決すべき課題がありました。

1. 他フォーマットへの展開
2. ユニコード文字への対応
3. アラビア語などへの対応

などが大きなところだと考えます。

1はver.6+SGMLでSGML、ver.7で統合されXMLに対応、2はver.8で対応され、3はver.13（FrameMaker2015）で対応されました。

つまるところ、FrameMakerをマルチパブリッシングの中心（あるいはその近く）に鎮座ましますものとして採用するのも「あり」ではないかということです。

更に、FrameMakerは「エディター」として活躍してきました。
その機能をも存分に発揮してもらえるというわけです。

「強力にXMLを取り扱え、エディターとしても高度に機能する」ことこそが、FrameMakerと他者を分ける境界線だと思えます。

とはいえ不満もあるんですよ。。。
細かいことではいろいろ。。。
しかしFrameMakerはそれを補って余りあるソフトウェアだと思います。

FrameMakerの構造化についてです。

この記事での「構造化」の意味するところは、FrameMakerデータのXML化です。

eXtensible Markup Langageの名の通り、XMLはタグ付けする言語です。タグ付けは意味付けです。

テキストの意味付け

FrameMakerの非構造化データ（通常のデータ）があるとします。

FrameMakerでは、非構造化データを構造化データにする際に、とても便利な機能が備わっていますが、そのひとつが「変換表」です。

この段落書式（スタイル）は、このエレメントにするんだよー。という指示をFrameMakerに伝える表ですね。

しかし、それを使うのはエレメント定義が終わってからです。エレメント定義ができていないと、「このエレメントにするんだよー」の部分ができませんから、当然ですね。

また、「変換表」を使う際には、既存のデータにおいて段落書式は正しく適用されているか？という問題もあります。

それを保証してくれる人はほぼいません。経験上で言っているのでいるかもしれませんが、ほとんどは「正しく適用されているはずだが調べてくれ」となることが多いです。

さらにこの段落書式（スタイル）が曲者で、「8_pt」とか見た目の定義をしているのはそのままエレメントには変換できません。

技術的にできないのではなく、XMLにする目的が「他のデバイスで表示する」「HTMLにする」「部分的に抜き出して違うマニュアルを構築する」だったりすることが多いので、紙（PDF）の見栄えだけに合わせたエレメントを作っても異なる方法でデータを使用したい場合に意味が希薄になってしまいます。

「XMLにすることで達成したいタスク（目的）」が問われます。

見た目も大事です。とても理解できる主張です。そもそもデザイン（設計という意味ではなく）にもそのデザインにした重要な理由があるはずですし、外せないこだわりもあるはずです。

しかし、ここで言うテキストの「意味」は「8_pt」からは推測できません。

パターンの把握

テキストの意味付けを行うためには、既存データのテキストの意味を知る必要があります。

それが明確ではないなら、文書を解析することから始める必要があります。全てのテキストに意味付けするわけですから、「おおよそ」とか「たぶん」はいけません。「すべての」です。

分析するには、「この部分はどのような意図で文字を太くしているのか」など「どのような意図で」が重要になります。ですのでライターさんの協力が欠かせません。まずライティングの仕様の有無を確認しますが、文書にまとめられていて更に現状でそれが厳守されていることはまれです。

結局、「文書の再定義をしましょう」ということになることが殆どではないでしょうか。

で、文書に使用されているパターンを把握する必要があるのですが、「この文字サイズのパターン」「インデント量のパターン」「複数コラムのパターン」など、パターンといっても色々です。そして、既存のデータで使用されているパターンが、本当に必要なのかを、内容変更の決定権者に確認して進めていく必要があるかと思います。この「決定権者」がライターさんなのか重役さんなのかどなたなのかは組織によって異なるでしょうが、これをしないと、後でこんなはずじゃなかった論議に花が咲くことになりますので、XML化をする前によくよく話し合いをすべきだと思います。

話し合いで、パターンの種類を机上に出し、共有化できるものなのか個別のものにすべきものなのか話し合って種類を最小限にし、それぞれに定義していきます。

文書の構造化

皆さんお気づきでしょうが、既存の文書をXML化しようとしたら、まず、既存の文書が「文書の構造」を正しく持っているかどうかを検証する必要があります。

FrameMakerにはとても便利な機能が備わっていますが、既存の文書を自動で思い通りのXMLにすることはできません。地道な作業が必要（もちろんFrameMakerに限りません）なので、それを認識したうえでXMLにすることによって、今後どのような展開をし、どのようなメリット、デメリットが考えられるのかを話し合ったうえで、腰を据えて取り組むのが良いと思います。

・・・いつのまにやら具体的な話ではなくなってしまいましたが、弊社では費用と時間をかけても文書は構造化したうえで運用していくべきだと考えています。

文書の今後の展開をどう見積もることができるか？が重要ですね。そしてそれはクライアント側にしかできない見積もりです。

FrameMakerの情報を得ようとしてWeb検索しても、ヒットするのは一昔前の記事なことが多いです。

もちろんAdobeさんの最新記事はヒットしますよね。しかしこれが的を射ていないこともあります。発売元の記事ですから当然、第一級の重要な情報なのですが、では実際使用してみたらどうなのか？という視点から書かれたものではないと感じることもあります。

あと、翻訳者視点の情報も多々ありますよね。FrameMakerの場合。

このコラムは、現在（2018年）もどっぷりFrameMakerに浸かって奮闘している弊社の現場視点から書かせていただこうと思っています。

こんな方にお勧めです。

1. 社内にFrameMaker資産が存在するが、どう処理していいか検討されている方
2. 新規文書作成に当たって、ツールの選定をされている方
3. （Web系ではなくドキュメント系の）CMS導入を考えている方
4. 過去にバグの多さからFrameMakerを憎んでいる方
5. 何か新しいことやれと命令されている方
6. FrameMakerは終わったツールだと思っている方

意外といらっしゃるのが、「FrameMakerはもう開発もしていないし過去のツールだ」と思っている方ですね。

そうではないですよ。と反論してみても、「昔使っていたがバグが多すぎて使い物にならない」というご意見をいただくこともしばしば。

この辺りは、Adobeさんにも責任がありまｓゴニョゴニョ

今現在も、これってバグでは？と思うようなものは散見しますね。確かに。

今も昔もある伝統的バグは、「次頁の内容が入り込んできてしまう」というもの。

再現性が（ほぼ）無いため、画面は後日貼りますが。。。

弊社はこれをチェックするツールを作成して対応しています。
皆さん、どんな対応されているんでしょうか。

しかしこういったバグ的なものは、内容をしっかり把握し対応することは可能だと思います。

それらを踏まえたうえでも、FrameMakerをドキュメント作成ツールに採用する価値は十分にある。と、考えています。

とはいえ、何でもかんでもFrameMakerを。ということではありません。適材適所。まず、

1. 対象のドキュメントは何のためのものか？
2. ドキュメントをどうしたいのか？
3. その要件とスケジュール

をはっきりさせたうえでツールの選定を行うことが最も重要なことではないでしょうか。選定根拠の情報収集のためにも、このコラムをご活用ください。