「DITA対応」の製品を選ぶ前に確認すべきこと – Arkanos Insights 

CMSやオーサリングツールの製品紹介で、「DITA対応」という表現を見かけることがあります。

構造化されたコンテンツを管理できる。既存のDITAデータを取り込める。DITA形式で書き出せる。

こうした説明を見ると、現在使っているDITAデータや制作環境を、そのまま新しい製品へ引き継げるように感じるかもしれません。

しかし、「DITA対応」が具体的に何を指すのかは、製品によって異なります。ファイルを取り込めること、構造を維持して編集できること、再利用や条件別出力を含む業務が成立することは、それぞれ確認が必要です。

製品を選ぶ際に重要なのは、「対応しているか」という一つの回答で判断せず、自社のデータと制作工程をどこまで扱えるのかを確かめることです。

「DITA対応」を一つの機能として考えない

DITAは、トピック単位の情報を作成・構成するための文書型と、それらを組み合わせ、拡張し、制約する仕組みを定めています。単に特定のタグ名が付いたXMLというわけではありません。(OASIS DITA仕様)

製品の対応範囲を確認する際には、例えば次のように分けて考える必要があります。

確認する対象	確認したいこと
入出力	どのDITAバージョン、要素、属性を扱えるか
編集	使用するトピック型の構造を維持して編集できるか
構成・参照	マップやトピック間の参照関係を保持できるか
再利用・条件指定	再利用の指定や条件属性を保持し、必要な処理につなげられるか
拡張	自社で使用する特殊化や制約を扱えるか
出力連携	実際の出力環境で必要な成果物を生成できるか

これは、すべての機能を備えなければ「DITA対応」と呼べない、という意味ではありません。

変換ツールと編集ツールでは担う役割が違いますし、汎用トピックだけで目的を満たす運用もあります。問題は、限定された対応範囲が、制作環境全体への対応として受け取られてしまうことです。

独自形式への変換で、何が失われるのか

特に確認したいのが、取り込んだDITAデータを製品内部でどのように保持するかです。

DITAの構造を維持して管理するのか。それとも、製品独自のスキーマへ変換し、書き出すときに再びDITAへ変換するのか。

後者の場合、取り込みと書き出しの両方で情報を保持できる必要があります。

例えば、異なる意味を持つ複数の要素を、取り込み時に一つの汎用要素へまとめたとします。元の種類を別途保持していなければ、書き出す際に、どの要素へ戻せばよいか分からなくなります。

同じことは、属性や参照関係にも起こり得ます。画面上では不要に見える情報でも、条件別出力や翻訳、独自の組版処理で使われているかもしれません。

本文と見た目が残っていることだけでは、情報が保持されたとは判断できないのです。

内部形式への変換そのものが、必ず情報欠落を起こすわけではありません。ただし、DITAを継続して運用する目的なら、独自形式との往復変換を必要としない設計を優先して検討したいところです。変換を介する製品では、保持できる情報と制約について、より具体的な説明と検証が必要になります。

100件成功しても、101件目が保証されるわけではない

サンプルデータを取り込み、正常に表示され、書き出しもできた。それだけでは、既存資産全体を扱えることの証明にはなりません。

100件のデータが正常に変換できても、101件目に未対応の特殊化要素や属性が含まれていれば、そのデータで初めて問題が発生することがあります。

普段は使わない構造が、特定製品の説明や例外的な手順にだけ使われている場合もあります。利用頻度が低いからといって、業務上の重要度まで低いとは限りません。

確認すべきなのは、成功したファイル数だけではなく、実際の運用で使用している構造と機能をどこまで網羅したかです。

さらに、未対応の情報に遭遇した際の動作も重要です。

取り込みを停止するのか。警告と対象箇所を示すのか。それとも、情報を削除・置換したまま処理を続けるのか。

「取り込み成功」と表示されても、その裏で情報が失われているのであれば、利用者は問題に気づく機会まで失ってしまいます。

「取り込める」に加えて、「編集しても壊れない」を確認する

未編集のデータが正常に往復できても、日常の編集操作を加えた後に同じように扱えるとは限りません。

例えば、手順を追加する、表をコピーする、参照先を変更する、条件を設定するといった操作です。その過程で、必要な構造や属性が失われないかを確認する必要があります。

ここには、製品の設計思想も関わります。

入力の自由度を広く取り、多様な内容を出力テンプレート側で受け止める方式もあれば、スキーマに沿って入力を制御する方式もあります。

自由な編集は使いやすさにつながりますが、DITAとしての構造を維持するには、編集時や保存時などに制約を扱う仕組みが必要です。出力時の変換に頼る場合は、自由に編集された内容を、どのような規則でDITAへ組み直すのかが問われます。

製品のデモでは、インポート直後の画面だけでなく、実際の執筆者が行う編集操作まで確認したいところです。

情報の使われ方は、出力して初めて分かることがある

DITAの実務では、トピックに含まれる情報が、出力側の設定や処理と組み合わさって働くことがあります。

例えば、条件属性はDITAVALによるフィルタリングに使われます。DITA-OTでは、マップで指定したDITAVALを使用する処理も提供されています。(DITA-OTの条件処理)

また、企業固有の出力環境では、特定の要素や属性値を手掛かりに、専用の処理を行うことがあります。

• 特殊化した要素を、専用のレイアウトで出力する
• 属性値に応じて、表や画像の配置を切り替える
• 条件属性によって、製品別の掲載内容を切り替える
• マップや参照情報から、必要な構成やリンクを生成する

こうした使われ方は、トピックを画面上で見るだけでは分かりません。データを保存・編集する製品が、その情報を「表示には不要」と判断してしまうと、出力側の処理が期待どおりに動かなくなる可能性があります。

XMLとして妥当であることと、期待した成果物が生成されることも別です。スキーマによる検証を通過していても、必要な条件指定や出力用の情報が失われていれば、業務上は正しくありません。

検証は、トピックの入出力だけで終わらせず、実際のDITAVALやプラグインを使った最終成果物までつなげる必要があります。

実データで、制作から出力まで確かめる

製品選定時のPoCでは、標準的なサンプルだけでなく、自社の制作環境を代表するデータを用意します。

通常の本文や表に加えて、特殊化した要素、条件属性、再利用、複雑な参照など、運用上欠かせないケースを含めることが重要です。

検証は、次の流れで考えると整理しやすくなります。

1. 取り込み前のデータと、現行環境での成果物を基準として残す
2. 新しい製品へ取り込み、情報の保持状況を確認する
3. 実務を想定した編集操作を行う
4. 書き出したデータの構造・属性・参照関係を確認する
5. 実際の出力条件と処理環境で成果物を生成する
6. 想定した編集差分以外に、欠落や意図しない変更がないか確認する

DITA-OTは、DITAコンテンツを処理して他の形式へ変換する出力エンジンです。既存業務で使用している場合は、バージョンやプラグイン、設定も検証条件として揃える必要があります。(DITA Open Toolkit)

ここで求めるのは、XMLファイルの文字列が完全に一致することではありません。保持すべき意味、構造、参照関係が残り、必要な成果物が生成できることです。

検証で確認できた範囲と、まだ確認できていない範囲も分けて記録します。その区別が、導入判断や追加対応の見積もりにつながります。

「対応」の範囲を、自社の業務に置き換える

詳しい人ほど、「DITA対応」という言葉の後に、条件や範囲を確認したくなります。

どのデータを扱うのか。どの構造を維持するのか。どの編集操作を行うのか。どの条件で、何を出力するのか。

それらによって、必要な対応は変わるからです。

すべての企業に、すべてのDITA機能が必要なわけではありません。対象を限定することで、使いやすさや費用の面で適した製品を選べる場合もあります。

ただし、限定する範囲は、導入後に初めて分かるものでは困ります。既存資産を継続して利用するなら、何を維持でき、何に変更が必要なのかを、選定時に明らかにしておく必要があります。

製品比較表の「DITA対応：○」を、そのまま自社要件への回答にしないこと。

自社のデータを取り込み、編集し、必要な条件で出力したときに、制作業務が成立するか。その確認まで含めて、DITA対応製品の選定を考えることが大切です。