ワンソース・マルチユースという言葉はかなり長く使われています。テクニカルドキュメントなどでは大きなシステムを構築して実現しているケースもいろいろ報告されています[1]。しかし、書籍の出版や学術誌の出版ではワンソース・マルチユースはまだ大きな流れにはなっていません。ここではワンソース・マルチユースがなかなか普及しないのはなぜかを考えてみます。
※本ブログをもう少し加筆して次に掲載しています。この続きは下記でどうぞ：
「ワンソース・マルチユース実践の難しさを考える」
ワンソース・マルチユースの仕組み
ワンソース・マルチユースを実現するには、まずソースの形式を決める必要があります。ソースの形式としては、DocBook、DITA、JATS、HTML5などXML／HTMLによるドキュメント形式を採用するのが便利です。XMLはもともとドキュメントをデバイスやアプリケーションから独立の形式で記述するために設計されたものです。
ソースの形式をどのようにするにせよ、ワンソース・マルチユースの出版工程は二つのステップに分けられます。第一はソースとなるドキュメントを用意する工程です。第二は、それをいろいろな目的に出版する工程です。ソースの形式をどう選択するかで、ソースドキュメントの制作の方法が影響を受けます。もちろん、出版工程も影響を受けます。
第一のステップ
ソースとなるドキュメントを執筆、校正して完成する工程です。XML／HTMLではテキストにマークアップ[2]する工程が必須です。マークアップが正しくないと第二ステップの処理ができません。執筆、校正を初めとして、第一のステップは、人手で行うのが主体です。
ドキュメントを制作する工程は、まだコンピュータで処理できるようになっていません。もっとも、現在、いま問題になっているDeNAのキュレーションサイトのコンテンツの収集についての記事を読むと、文章をリライトするコンピュータ処理は、驚くほど進歩しているようです[3]ので、将来は自動的にできるようになるかもしれません。恐ろしいことです。
第二のステップ
第二ステップはソースを加工処理してWebページ、PDF、各種のHELPなどを作成する工程です。XMLはもともとドキュメントをコンピュータで処理するための技術です。ソースドキュメントをXMLで用意することができれば、プログラムで様々な成果物を用意するのは容易です。
例えば、DITAではあまりレイアウトなどに拘らなければDITA-OTを使うだけで、HTML、PDFを初めとする多種類の出力が得られます。このように、ソース文書さえXMLあるいはHTMLで作ることができれば、いまの技術を使えば多種類の出力を作成するのは比較的容易です。
問題はなにか？
ワンソース・マルチユースの難しさはソースをどのように用意するかというプロセスにあり、マルチ出力は大きな問題ではありません。
これはXMLやHTMLが技術的に難しいということではありません。上で説明しましたように、第一ステップは人手で行われます。これを担当する執筆者・制作者は、現在、すでに一定のツールを使って一定の手順により作業を行っています。その作業のワークフローをそれまで慣れ親しんできた方法から変更するように説得するのが難しいのです。
特定の企業が主体性をもって限られた数のドキュメントを制作しているテクニカルマニュアルなどの分野でさえもなかなかワークフローの転換は難しいのです。多品種少量制作の典型である商業書籍の出版や事務局が責任をもった意思決定をしにくい学会などはさらに難しくなります。
[1] SAPの大規模DITA導入事例の進展(2016年11月）
[2] マークアップ
[3] DeNA「サイト炎上」MERY、iemoの原罪とカラクリ