コンテクスト変換という幻想（DITAを巡る話題）
2009年11月16日
TCシンポジウムやDESIGN IT!でDITA（Darwin Information Type Architecture）が話題になっていたようですが、反応を見る限りでは、相変わらず変な誤解が（特にWeb制作業界やSI業界に）あるようです。むしろシングルソース化という言葉に翻弄された経験のあるTC業界の方が免疫があるようで、思いっきり疑いの眼差しで眺めていたのとは対照的でした。
DITAの全貌が見えない現時点でアレではありますが、今回はDITAやシングルソース化という理想について、現時点で思うところをつらつらとまとめてみます。DITAというコンセプトそのものを批判するのではなく、以前から存在するこの種の理想が実現できない理由はどこにあるのか、そしてその前提として、コンテクスト変換という行為が極めて困難であることを明らかにすることが目的です。
「マニュアルの情報構造」にまつわる根強い誤解
技術情報の一元管理というお題目は理解できるのですが、（悪い意味でお約束とはいえ）想定用途としてマニュアルが取りざたされるのが納得いかないところです（少なくとも、ユーザータスク志向で設計された操作情報系マニュアルだけでも明示的に除外してほしいところ）。この種の問題視する理由としては、「各種仕様書を含む製品情報（を部品化したトピック）を組み替える（マッピングする）ことで、マニュアルというコンテンツも生成可能である」「マッピングにより、複数のコンテクストへ対応可能である」というナイーブな主張にあります。
悪気はないのだとは思いますが、この種の言明を受け入れてしまう時点で、マニュアルが持つ情報特有の構造がまったく理解されていないと言わざるを得ません。「マニュアルは定型構造だからXMLに向いている」という誤解を元にしたXML煽りの時もそうだったのですが、相も変わらずマニュアルという存在は理解されないもののようです。ここが改善されれば、マニュアルに関連するこの種の誤解や変な楽観論は少なくなりそうなものですが…。
もちろんマニュアルに記載する情報は全部ダメ（DITAで扱うには不適である）ということではなく、情報の種類によっては適用可能な領域もあり得ることは言うまでもありません。ただ最近のDITA煽りの場合、「ある情報を複数のコンテクストへ対応させる」ことが抱える原理的な困難をまったく認識していない人が多い、ということが気になります。特にコンテクストというものに対してもっとも敏感であることが求められるWeb屋さんが、その点に気が付かないようでは拙いだろうと思うんですよね。
要するに、「情報の内容・構造・表現はコンテクストによって制約されている」ことを意識しているかどうか？がポイントです。
情報の内容・構造・表現
ここで情報設計のプロセスを復習してみましょう。
諸説はあるかと思いますが、（プロジェクトの目的定義後に）コンテンツを設計する際にまず前提として検討する必要があるのは、提供者が提供したい情報・サービスと、特定の目的や動機を持つユーザーが接する文脈、すなわちコンテクストになります（5W1Hのような形で表現するとわかりやすいですね）。当然コンテクストは複数存在する訳ですが、それらのコンテクストを踏まえて、コンテンツに載せる情報の内容・構造・表現を設計・最適化することになります。
ここで注意すべき点が2つあります。1つは「コンテクストが変わるということは、末端の情報の内容・構造・表現にまで影響を与える」こと、もう1つは「情報の内容・構造・表現は相互を制約する」ということです。
前者はコンテキスト把握の目的から導き出される必然的帰結ですので当然意識されているとは思いますが（で・す・よ・ね？）、問題は後者です。これはつまり、情報の内容とは情報の構造や表現によって制約されると同時に、情報の構造や表現を逆に制約しているということです。以前の研究発表で「構造と表現の分離」に関連して
そもそも当研究所は、情報の内容を展開媒体と切り離すことができるという前提自体が怪しいと考えています。ある媒体で情報を提供するのであれば、その媒体に最適化した表現／配布形態が本来必要とされるはずです。複数媒体への展開を前提として情報を組む場面も存在しますが、その場合はどちらでも破綻しないことを前提とした中途半端なものになるか、展開する媒体に合わせた多重構成を採用した同一ソース（データ）から別のアウトプットを行うしかありません。
と書いたのは、こういう意味です。
従って、「コンテクストが変わると、情報の構造だけでなく内容表現にも影響を与える」「内容表現を変えずにコンテクストを変えると、構造に無理が生じる」「内容表現を変えずに構造を変えても、コンテクスト対応に破綻を生じる」ということになります。マニュアルという領域においては、DITAでいくらトピック化（部品化）＋マッピングという手法を採用したところで、個別のテキストは設定されたコンテクストを踏まえた制作方針（およびそれを体現する情報構造や表現設計）の影響下にあり、情報構造の変更は個別のテキストに影響（それも大がかりな）を与えることを意味する訳です。CMS内のデータ管理という視点で話をするならば、コンテクストが変わることにより、部品の粒度や各部品の表現手法が変わってくるということです。
一体全体、どうしたら「部品を組み替えるだけで複数コンテクストへの対応が可能」という判断が成立するのか、その判断理由をじっくりとお聞きしたい気分です。
マニュアルをDITAで生成することは現実的に困難
もっとも重要な問題は、そもそも部品の単位をどう考えるのか？ということです（部品粒度の問題）。少し具体例を挙げて考えてみましょうか。
よく語られがちなのは、外部仕様書とリファレンスマニュアルの情報を共通化する（シングルソース化する）場合の例です。確かに外部仕様書にあらかじめリファレンスマニュアルとして必要となる情報を部品として切り分けて追記しておき、社内にのみ公開する情報を削除するとともにマッピングを多少変更することで、リファレンスマニュアルは簡単に生成できそうです。というか、楽観的に見ている人は、まさに下図のようなイメージで「できそうです」と考えるのでしょう。
ところが、外部仕様書とリファレンスマニュアルという比較的相性がよいと考えられる場合ですら、粒度がバラバラでかなりの難儀が強いられます。仕様書とマニュアルでは、読者以外にも文書として要求される機能・振る舞いが異なるため、そもそも構成の基準となる「機能」の単位がまったく異なるのです。他にも、異なる表記ルール（例：常体と敬体の違い、専門用語の扱い）をどう吸収するか？仕様書として相応しい粒度で記載された情報はマニュアルに適しているのか？、仕様書的に見出し＋本文で構成された情報をマニュアル的にマッピングしたところで、違和感があるのではないか？などなど、様々な問題が出てきます。
実際にはリファレンスマニュアルで用が足りる分野はかなり限定されていますので、顧客満足度を考慮してもやはりユーザータスクを中心に構成した取扱説明書や操作説明書を提供せざるを得ません。そうなると、仕様書とマニュアルを両立させるための部品粒度やテキストの書きかたなど、相当な困難が伴うことになります（下図参照）。
シングルソースを必要に応じて切り出し・再構成するのではなく、多メディア用のソースをあらかじめ重畳して（形式的には）シングルソースとして格納しておき、展開先のメディアに合わせて切り出して「シングルソース化による出力です（えっへん）」と強弁するつもりならばそれはそれで良いのですが、何かそれはちょっと違うのではないでしょうか。少なくとも、ソリューションとして企業や現場が求めるものとは全然違いますよね。
適用領域を巡る根本的な問題
対象情報を部品化するには、分析に膨大な時間と費用がかかります。新製品が次々にリリースされる製品カテゴリでDITAのような仕組みを導入することは、現実的に困難です。また、枯れた製品カテゴリでもない限り、機能増強への対応や顧客満足度の向上を目指した制作方針の変更など、大がかりな構成・表現改善は日常茶飯事です。このような状況下でDITAで情報を蓄積することが、企業内の効率改善に繋がるとはとても思えません。
「社内でのみ流通する仕様書と社外に公開できるマニュアルやサポート資料をシングルソースから管理する」という理想はDITA以前の随分前から出ていますが、まともに実用化された話を聞いたことがありません。一部の種類の情報やB2B領域における情報など、特定の狭い業務用途においては可能かもしれませんが、B2C領域では正直無理ではないかと思われます。情報の内容・構造・表現が相互に制約されない領域においてはDITAの有効性は否定しませんが、そうすると活用できるのは情報の構造・内容に（法令的・業界的）縛りのある医薬品の製品情報など、特定領域に限定されることでしょう。
設計部門やサポート部門を巻き込んで、（社内／社外情報も書き分けた）巨大な部品集を会社として管理するという理想も否定はしませんが、重要なポイントを失念していませんか？それは、一次情報を産み出す部門の担当者が記述する情報と、社外の顧客に向けて表現を最適化された情報は、完全に別物だということです。コンテンツの世界において、一次情報生成者＝最終表現者（内容の正誤と表現の双方について責任を持つ）であるのは、ジャーナリストや自ら取材するライターなど、一部に限られます。製品開発部門という一次情報生成部門が最終表現者を兼ねる必要はありませんし、そもそも現実的に困難です。何のためにマニュアルやカタログ、Webサイトを担当する部門・会社が独立して存在するのかを考えてみれば、容易に想像が付くことです。
何とかシングルソース化にこぎ着けたとしても、再利用・共用している部品が改訂によって特定箇所のみ修正されることになった場合の処理（個々の部品が最終出力される展開先のどこに登録されているのか、理解していなければならない）など、運用上の様々な困難がのし掛かってきます。変更してはならない部分まで変更されては困りますし、この種の問題を回避するために基本的に共用部品を使用しないようにすれば、部品化とマッピングというコンセプトの意味がなくなります。このような問題への対策を検討していくと、各出力先のマッピング全体像、そして改訂経緯などの運用面まで含めた部品集合全体を把握しているスーパーマンのような人材が必要になり、運用における属人性が極めて強くなるというリスクが最終的には発生することになります。
いかがでしたか？
社内情報のシングルソース化という理想やDITAのコンセプトを実現することは、現実的に極めて厳しいという認識を共有できたのではないかと思います。マニュアルが現状ワンオフで制作されることが多いのは、（一般的な思い込みに反して）マニュアルが例外だらけで複雑な情報設計を強いられるためであり、それはつまり、エンドユーザーの利益をできる限り優先しているからなのです。これはWebサイトやカタログなど、エンドユーザーを強く意識した情報提供が求められる情報チャンネルでは、共通の問題でしょう。
以前から掲げられている理想が実現できないのは、技術的な不備以外にも、それなりの理由があるわけです。理想を否定するつもりもありませんし、現状の体制が（主にリソース浪費の面で）ベストからほど遠いことは事実ではありますが、現状の理由をしっかり分析することなく、ポッと思いついたような解決策を提案されても意味がないのです。
社内情報のシングルソース化、作成・共有の効率化を目指すのであれば、まずは情報の部品化（枠組の整理）、部品単位での一次情報生成部署の特定、テンプレートや文例集の支援による部品単位の品質向上、社内における類似文書の関係の整理（共有・流用できる部品の見える化）から始めるべきで、いきなりDITAやその種のCMSを導入することに拘るべきではないと考えますが、いかがでしょうか。
