合成の誤謬 (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を導入すれば自動的に業務が効率化され、費用が削減され、品質が良くなる。と、お考えであれば、それには一石を投じたい。と、思う次第です。

お互いのためにも。