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に合わせて見直し、構築する必要があるかもしれません。

（続く…）