home‎ > ‎

DITAが目指すビジネス文書革命

発表機会:2006年8月31日 書きおろし

シングルソース化の要請

ソフトウェアのマニュアルには、従来から「(いわゆる)マニュアル」(たとえばユーザーズガイドという名称でフォーマットはPDF)と「オンラインヘルプ」の2つの形態があり、その内容は重複が多いので、「ドキュメントのシングルソース化」はオンラインヘルプ登場の最初のころからずっと熱心に取り組まれてきた。そして現在では、アドビのFrameMakerがこの市場で広く支持されており、コンディショナルテキスト機能を活用した複数ドキュメントのシングルソース化、また連携製品であるQuadralay社のWebWorks ePublisherを組み合わせてオンラインヘルプを生成することによるマニュアルとヘルプのシングルソース化、あるいはRoboHelpによるマニュアルとヘルプのシングルソース化、などいくつかのシングルソース化のスキルも定着している。

ところが近年になって、パブリッシュ先のメディアが急速に増加・多様化する可能性が生まれた。言うまでもなくWebコンテンツへの展開がそれであり、従来マニュアルまたはヘルプとして提供してきた情報とある程度重複する情報を Web上のコンテンツとして、あるいは携帯機器への配信コンテンツとして提供することが技術的に可能になってきた。逆に、Webや携帯機器向けに提供しているコンテンツを、構成や表現を変更して、しかしある程度の情報は共通化させて、印刷媒体イメージの資料(カタログ、パンフレット、マニュアル、データシート、ハンズアウト、プレスリリース、講習会テキストなど)として印刷物もしくはPDFとして提供することが技術的に可能になってきた。

このようなトレンドの結果として、ソフトウェアのドキュメンテーションにおいては現在、できるだけシングルソース化された情報を、大別して3種類のメディア-印刷物(PDF)、オンラインヘルプ(WinHelpなど)、Web(メールの提供およびモバイル機器への提供を含む)-に対してできる限り時間とお金をかけずに(=できるだけ自動的に)展開する手順が求められるようになってきた。

もちろんある製品に関する情報と、その展開先メディアの使い分けを考えれば、すべての情報のフォーマットだけを変換して多様なメディア向けにそれぞれ保存すればよいというわけもなく、メディアごとに、製品の情報全体のうちの何と何を取捨選択して、どういうフォーマットで、またどのような頻度で提供するか、またその情報はいつまで有効であり、有効期限を過ぎた後はどのように修正するのか、あるいは人の目にふれないように公開領域から外すのか、そのような、製品のライフサイクル全体を視野に入れた上でのドキュメント情報の検討、設計、実装、管理が必要となる状況が生まれてきた。

非常に広範な製品やサービスに対してWebの台頭が大なり小なり影響を及ぼしつつある現状を考えると、上に述べたような「ある製品/サービスに関する情報を一元的に管理し、多種多様なメディアに対して可能な限りムダを省いて情報展開すること」というシングルソース化の要請は、ソフトウェアに限ったことではないと考えられる。

コンテンツの重要性

次に、視点を変えて企業のWebにおいてどのようにコンテンツが取り扱われてきたかを考えてみる。 企業が提供するWebは少なくともこれまではマーケティングあるいは企業PRを目的とするものであり、その制作発注元も各企業のマーケティング担当部門であるケースが多いようである。そこで提供される製品情報は、一言で言えば広告としての情報であり、ソフトウェアの場合はこれにサポートとしての情報が加わるという性格のものであった。

そういうマーケティング(PR)目的のWebの制作で主役となるのはデザイナーであり、ネットバンキングのようなWeb経由でのサービス提供がある場合は主役となるのはプログラマ(エンジニア)であった。そこでは言葉は「コピー」であり、言葉を扱う専門家としてその業界にかかわるのはコピーライターである。マニュアル制作やマスコミ(出版)の現場にいる言葉の専門家はライターであったりエディターであったりするが、ライターやエディターが企業Webの制作において主役となるようなケースは考えられないと思われる。

だが、メディアとしてのWebの相対的重要性が飛躍的に増すにつれて、いわゆる「コンテンツ」を提供するメディアとしてのWebという位置づけが、このところ重要性を増してきていると思われる。その事情を反映して、CMS (Content Management System) が注目を集めるようになってきた。コンテンツ管理システムで中心にあるのはコンテンツであり、重要なのはコンテンツを執筆もしくは管理する役割、すなわちライターやエディターである。

このような構造の変化を反映して、従来はデザイナーおよびプログラマの両方もしくはどちらか一方が主役となってきたWebデザインという領域において、今後は第三のプロフェッショナルとしてエディターの相対的重要性が高まっていくものと予想する。言い換えれば、従来は関連部門がそれぞれの必要に応じて作成したドキュメントを編集する形で初期のWebコンテンツに反映させ、その後はCMSの定型フォーマットを通じてWebコンテンツの更新にかかわる、といういわば受動的なかかわり方をしてきたドキュメントが、今後は、最初から紙媒体(PDF)およびオンラインヘルプ等との連動性を最初から組み込んだ形で活かされるWebサイトを、設計の段階から参加して構築していくエディターの役割が重要になってくると考える。

言い換えれば、広告代理店の視点からはコンテンツはコピーライターが書くものだが、エンタープライズコンテンツ管理の視点からコンテンツは顧客と自社とのインターフェイスの主要な構成要素である。つまり従来はデザインのおまけとしての従属的な扱いを受けてきたドキュメントが、ECMの世界では場合によっては主役になってくる。それほどでなくても、コンテンツ(ドキュメント)を避けて通れる業界というのは少なくなっていくだろう。業界では製品が主でマニュアルは従(おまけ)の扱いだがコンテンツ業界では配信されるドキュメントが主でありWebなどのメディアはその配信媒体(手段)でしかない。マニュアルとコンテンツは従来、別の部門が制作してきた。だが、今後はその境界がだんだんあいまいになってくる。

コンテンツの再利用

以上に述べた状況を背景として、コンテンツ(マニュアルなどのドキュメントを含む)を効率よく再利用する仕組みが求められるようになった。つまり、上述した多様なメディアへのシングルソースからの展開は、言い換えれば各メディアに対するシングルソースコンテンツの再利用であるし、製品マニュアルについて言えば、製品がバージョンアップする再に旧版のコンテンツの一部を新版のコンテンツとして流用するときもコンテンツの再利用をやっているといえる。

では、どういう単位と構造で再利用すればよいか?いくつかの前提条件を考えてみる。

フォーマットについて

次に、フォーマットについてはどう考えればよいだろうか?既存の資産のほとんどがたとえばマイクロソフトのOffice Suiteのフォーマットだという場合もあれば、FrameMakerで保存されている、ということもありえるだろう。これらの例のように、特定の製品のプロプライエタリなフォーマットに自社の資産が拘束(ロックイン)された状況は、そのプロプライエタリなツールのベンダーになんらかの拘束を受ける前提条件となってしまうので、避けられるのであれば避けるほうが望ましいだろう。

その場合は、特定のベンダーのプロプライエタリなフォーマットに拘束されないフォーマットを選択する必要があるが、現在ではオープンなスタンダードに基づくXMLベースのドキュメントフォーマットがすでに利用可能になっており(DITA、DocBook、OpenDocumentなど)、これらのオープンスタンダードに準拠するフォーマットを採用するのが、もしこれから選べるのであれば望ましいと思われる。

また、フォーマットについてもうひとつ考えておくべき要素は構造と表現の分離だろう。シングルソースからPDF、Help、HTMLなど多様なフォーマットを生成できるようにする場合、プロプライエタリなツールを使うのであれば中心となるフォーマットがWordやFrameMakerのようなメジャーな製品であれば変換はもちろん不可能ではないし、構造と表現がそれらの製品においては混在しているが、今後登場するツールへの将来の互換性を考えると、構造と表現を分離するという、Webスタンダードの世界で支持されている考え方(Webの場合ではXHTMLとCSSの分離)に倣うのが妥当のように思われる。

誰と誰が共有するか

次に、誰と誰が文書の再利用資産を共有すればよいのかを考えてみる。再利用は一人のライターの中に閉じていては意味がないということであり、あるライターの書いたものを、所属するチームだけでなく、組織全体で資産としてアクセスでき、利用できなければならないはずだろう。再利用がうまくできなければ、同じ情報を重複して含む文書を企業内の複数の部門で重複して作成してしまうことになるかもしれない。

しかし、ここで指摘しておく必要があるのは、情報を共有する範囲は人間に限らない、という点である。つまり、ドキュメントはいったん構造化されるとツール(ソフトウェア)による処理が可能になる。たとえばWebのコンテンツが人間のユーザーだけでなくGoogleなどの検索エンジンのクローラー(ロボット)にとっても処理対象となっており、人間のユーザーと検索エンジンのクローラーの両者に対して利用しやすい構造としてXHTMLとCSSの分離がWebコンテンツの世界で進んだのと同じようなことが、マニュアルの世界でも起きることが予想される。

粒度(granularity)について

ドキュメントを再利用しようとする場合、そのサイズ(粒度...granularity)に着目するといくつもの水準が考えられる。大きいほうから並べてみると、ドキュメント単位、セクション単位、ページ単位、パラグラフ単位、センテンス単位、文節(単語)単位、などがあり得るだろう。

再利用の媒介としてどの水準の粒度がユーザーに指示されるかは、再利用の場面や状況に左右されそうだ。たとえば翻訳の場合、既存の翻訳を「翻訳メモリ」という構造に資産化して再利用することがテクニカルな文書の翻訳においてなかば常識化しているが、翻訳メモリにおける再利用単位でもっとも一般的な粒度はセンテンス単位であり、たまにパラグラフ単位が採用されることがある。それよりも大きな単位での再利用は、翻訳メモリという媒介構造に限って言えばまず考えられないと言ってよいだろう(より小さな単位での再利用は、訳語集という別の媒介構造において利用されている)。

ここでは対象をマニュアルに絞って検討を進めることにする。マニュアルを再利用する場合に適切な粒度を検討するときの視点として、文書の提供側(ライター、エディター)の立場からいったん離れて、文書の利用側(読者、ユーザー)の立場からこのテーマを考えてみると分かりやすい。

ビジネス文書やマニュアルの読者は、いわゆる一般書籍や雑誌の読者とは(呼び方は同じでも意味が)異なる。一般書籍や雑誌の読者は読むこと自体が楽しみであったり目的であったりするが、ビジネス文書やマニュアルの読者の目的は読む楽しみでなく、情報である。

マニュアルのユーザーは目前に動かない装置(あるいはソフトウェア)と今日中に済ませなければならない仕事をかかえて困っていたりウンザリしていたりする人なのであり、そんなユーザーがマニュアルに期待しているのは、自分がいまここで必要とする情報をできるだけ短時間で的確に教えてくれることである。彼女や彼は決して本が読みたいと思っているわけではない。にもかかわらず、現実に提供されているマニュアルは多くの場合「本」の構造に準拠して構成されている。もちろん、現状のマニュアルはPDFやオンラインヘルプとして提供されておりテキスト検索もできればコンテキストセンシティブなアクセスもできるので20年前のマニュアルとは事情が異なるが、それでもまだまだ無意識的な前提条件として「本」の構造をマニュアルの作り手も使い手も引きずっており、そのことが「知りたいことを知りたいときに知りたいところだけ提供してくれる」道具としてのマニュアルの機能性をむしろそこなう結果になっている。

そのような、製品ユーザーとしての読者(マニュアルの読者)に対して余計な情報のの山の中から必要な情報を探させるような時間を無駄にさせないためには、彼女/彼が必要とする情報を、必要とするときに、必要最小限の単位で(ピンポイントに)提供する構造が望ましいことが分かる。 このように視点で考えると、粒度としてドキュメント単位やセクション単位は大きすぎるが、センテンス単位やパラグラフ単位は小さすぎる。結果的に再利用単位として、「あるひとつの操作を完了させるのに必要な情報を必要最小限にまとめたサイズ」、すなわち「トピック単位」が粒度として望ましい、という見解がここから見えてくる。ここにいたって、マニュアルが提供する情報は、従来の「本」という前提構造から解放される。

以上に検討したなかで提示してきた見解、すなわちフォーマットとしてはオープンスタンダード、粒度としてはトピックを採用して登場したのがDITAと呼ばれる技術標準である。

DITAとは何か?

DITAは2005年6月にOASISの標準として認定された「パブリッシュ」のためのXMLアーキテクチャであり、仕様の策定にはArbortext, BMC Software, IBM, Idiom, Innodata Isogen, Intel, Nokia, Oracle, Sun Microsystems, 米国防総省などの組織が参加している。

DITA仕様では第一にトピックベースの情報を作成する「ドキュメントタイプ」が定義され、第二にドキュメントタイプの複合と拡張を行う仕様としての「スペシャリゼーション」が定義され、前者が後者の基礎(構成要素)となる。

DITAにあらかじめ用意されているトピックの種類は非常にシンプルで「コンセプト」「タスク」「リファレンス」の三種類しかない。コンセプトはある操作を行うのに必要な知識を解説するトピック(”What is...”の問いに答えるトピック)、タスクは操作そのものを説明するトピック(”How do I?”の問いに答えるトピック)、リファレンスは別のトピックや文書などへの参照を記述したトピックである。

いずれのトピックも1トピックで1テーマ(サブジェクト)だけしか執筆しないのが原則で、この原則を守って文書を執筆していくと、結果的に1個のドキュメントファイルの代わりにたくさんのトピックの束ができあがる。

トピックは文書を構成する基本構成要素であるが、その上の階層構造としてDITAが定義しているのは「ドメイン」である。ドメインはトピックの種類よりも上の次元で、特定の分野の文書に共通して見られる要素の集合を定義するもので、DITAが最初に提供したドメインにはタイポグラフィック、プログラミング、ソフトウェア、ユーザーインターフェイス、ユーティリティの5種類がある。それぞれの分野に特有のトピック構成をあらかじめテンプレート的にまとめて提供してくれるプロトタイプ構造がドメインであり、DITAではこれらのドメインについてDTDとスキーマを提供している。

この5種類の内訳を見れば分かるようにDITAは最初からマニュアルの分野に的を絞って構想されたアーキテクチャであり、パブリッシュのためのアーキテクチャであるといってもすべてのテキストを対象とするものではない。

ところで上記の3種類のトピックと5種類のドメインはかなりおおまかな分類であるが、実務に従事するDITAのユーザーは多くの場合、特定の企業や特定の製品カテゴリなどを専門分化して担当しているはずだから、もっと詳細なレベルで文書構造の共有化が可能になることが予想される。そのような、より詳細な水準での文書構造の定型を定義する手段としてDITAが定義しているのがスペシャリゼーションであり、あらかじめ用意されたトピックやドメインをより個別の領域に特化させることができる。この場合ユーザーが作成する独自のトピックやドメインは既存の構造のサブクラスになる。たとえばタスクトピックから独自タスクを導出したり、ユーザーインターフェイスドメインから独自ドメインを導出したりすることになる。

なお、DITAが提供するトピック構造とドメイン構成ですべてのマニュアルの定型がカバーされているわけではもちろんない。あらかじめ提供されたトピックやドメインの中に自分がこれから作成したいマニュアルになじむ構造が存在しない場合は新たに独自のトピックやドメインを作ることができるが、その場合はDITAの基本タイプから外れたドキュメントタイプの文書となり、DITAの仕様に準拠して提供されているツールなどのフレームワークが利用できなくなる。言い換えれば、DITAのメリットを活かすにはDITAが提供するトピックとドメインの構造に沿って自分の伝えたい情報を構成する必要がある。

トピックのマッピングによる文書構成

DITAをベースにした文書はトピックをベースとするが、たくさんのトピックを全体としてどのように文書として成立させるか、文書構成を定義する仕組みが必要である。それが「DITAマップ」である。同じトピックを利用してもマップを差し替えることによって別の文書が作成できる。これがDITAの利用範囲を(従来型の技術表示を大きく超えて)拡げる可能性を開いている。

マップとトピックの関係はぶどうの芯と粒の関係にたとえられる。実際に食べられるところ(=読めるところ)はトピックなのだが、一粒ずつのトピックをつないで全体としてぶどうの房を構成しているのは芯である。もしも、「ぶどうの粒」をリポジトリに貯めておき、「芯」の形をいろいろと差し替えることによって、コンパクトな房や見栄えのよい房や大粒ばかりの房などをいろいろ構成できるとすると、これは文書を提供する側からみると便利である。

すなわち、ある製品(自動車でもいいしパッケージソフトでもいいが)に関する情報をすべてDITAの枠組みで保存していくと仮定しよう。その製品のマニュアルとカタログとプレスリリース資料において、共通してその製品の基礎データが必要となったりするし、解説文書が必要となったりする。それら必要となる要素が上手にトピック単位でリポジトリの中に保存されていれば、マップを差し替えることによってその製品のマニュアルでもカタログでもプレスリリースでも、自在に文書生成が可能になる可能性が開ける。

これは、採算性の視点からはかなり意味のある展開である。従来はマニュアル、カタログ、プレスリリースで別々に予算を計上してそのつど文書作成していたものを、同じリポジトリから基本的にはマップの差し替えで生成できるとなると、同じ予算でより多様な文書を展開できるということになるとも言えるし、同じ文書を展開するのにコストを節約できるとも言える。採算性を確保しながらアクセス対象のユーザーの範囲を広げることができるわけである。

情報構造としてのドキュメント

このような、トピックベース+マップによる構成という文書生成技法は、文書を提供する側(ライターやエディター)に対しては、ごく自然に、情報構造としてのドキュメントを意識することを要請するようになるであろう。文書の構造、というものをかなり意識的に考えて文書を設計する、という視点が明白になるわけだ。

従来のドキュメントでは全体(ぶどうで言えば一房の単位)で作成、配布、利用が行われていた。だが、ヘルプ情報としてユーザーが必要なのはある一粒だったりする。そこでそのニーズにこたえられるようにDITAでは房単位で文書を構成せず、粒単位で文書を構成する視点から構造が設計されている。

だが、DITAはあくまでも房の構造を構築できる枠組みを提供しているだけで、DITAを使えばだれでもおいしいぶどうが提供できるわけではない。まず、情報を提供する側で考えると、提供しようとする情報をある程度独立性のあるトピック単位(粒単位)に構成する思考が求められるが、これは従来のマニュアル(という本=房)を執筆するときの思考とはおそらくかなり異なるので、執筆側のライターやエディターに視点の切り替えを要請するだろう。つまり、書く前にドキュメントを設計する段階から、思考を切り替える必要があるということである。この思考の切り替えを「ドキュメントの構造化」と呼ぶ。

ドキュメント構造を意識して書く

だが、このドキュメントの構造化には、抵抗を感じるライターやエディターがおそらく多数でてくるだろう。DITAをインフラとして導入すること自体の困難よりも、コンテンツを執筆する側の人間の意識を変えることへの抵抗のほうが、DITA導入にあたってははるかに強い抵抗となることが予想される。ちなみにこれはマニュアル翻訳者からみると10年前に通過儀礼した世界で、翻訳メモリの導入以前と比べて翻訳メモリ導入以後の翻訳者はさまざまな制約にしばられながら翻訳している。翻訳者によっては表現の自由をうばわれたと思っている。それと同じことがライターの世界にも登場した、という見方もできる。

でも、こんな話は「あれ、どこかで聞いたぞ」という感じだろう。そうだ、プログラムコードのライブラリ化のときにも同じような話を聞いた。プログラムコードの再利用という道をいろいろと探った結果、プログラミングの世界ではオブジェクト指向、その理念に基づくクラスライブラリの充実がある。

それと同じようなことを、なぜドキュメントでもできないのだろうか、という問いが、DITAのような考え方を後ろで支えている。

情報アーキテクチャの改善は大変

そうなると個別のドキュメントが比較的自由に独立体として執筆・配布・利用されてきた状況は、もしもDITAのような全体構造が機能しはじめると終わるのではないか。そして文書単位の情報流通が終わった後に登場してくるのは、組織における情報全体の構造体、すなわちインフォメーション アーキテクチャと呼ばれるものの顕在化になるのではないだろうか。

構造を記述する書式において仮にDITAがスタンダードになったとしても、スタンダード書式の採用が自動的に情報構造を決定してくれるわけではない。それはちょうど、とにかくJavaを採用すればほうっておいてもオブジェクト指向のプログラムが上手に書けるというものではないことと相似だろう。 書式を決定しても情報アーキテクチャが一意に決定されるわけではない。情報アーキテクチャの設計のよしあしは、選択した書式とはおそらく直接関係がない独立した事象である。だからおそらく、組織の情報アーキテクチャを設計者の視点から査閲できる「情報アーキテクト」のような役割を担う人物が必要になってくる。優秀な情報アーキテクトを擁する組織はスムーズに組織内の情報を流通させることができるが、凡庸な情報アーキテクトしかいない組織はツールだけ導入しても形式的な約束事が増えるだけで何がありがたいのか分からないということになるかもしれない。そうなると、先に述べた、従来型の思考パターンの変革を余儀なくされてそうでなくても不快を感じているライターやエディターの現場での抵抗を説得することなどできないかもしれない。 再利用をすることが全体としての時間短縮に貢献するかどうか、よく検討する必要があるだろう。情報アーキテクチャの設計が下手だと再利用してもかえって時間が長くかかってしまったということになりかねない。

情報アーキテクチャの評価は簡単

このように優れた情報アーキテクチャを構想し、設計し、実装するのは並大抵の努力ではすまない大変な事業になることが予想されるが、その評価のほうは簡単だ。つまり、優れた情報アーキテクチャが機能している組織では、同じ文章を二度書くということが皆無(皆無が無理でも皆無に近い)という状況が実現しているはずだから、組織全体を精査して、ある人が以前書いた文章と似た文章をまた書いているという状況が生じていないかどうか、あるいはあるセクションで制作した文書と実質的には同じような文書を隣のセクションで重複して制作しているというような状況が発生していないかどうかを調べてみればよい。

ムダな仕事を最小限に減らしたい、重複して同じもの書くのなんてムダだ、そういう思想を「ミニマリズム」と呼ぶのであれば、DITAというのは、昔からずっとあるミニマリズムへのあくなく挑戦の、最新型のチャレンジの一つである。

DITAをいつ使うか?

どのような文書の体系でもDITAが有効ということはありそうもない。いっぱんにヘルプ系のドキュメントを作成する場合はDITAを検討する価値はあるだろう。ブック系のドキュメントが多い場合(書籍のような)は検討するまでもなさそうだ。

そう考えてみるとDITAが活躍するフィールドは翻訳メモリ(TRADOSのような)が活躍するフィールドとかなりの程度オーバーラップするのではないかとも思われる。

参考文献

Ann Rockley, “Managing Enterprise Content: A Unified Content Strategy”, New Riders Pub; 1st edition (2002/10/17)