Welcome to SHOWA!!
ホーム
「技術トピックス」目次
DBPで変わる組版の位置づけ

SHOWA NEWS No.87
1999年12月15日号より

従来の印刷工程は、「組版→製版→印刷→製本」という流れでとらえられ、その中で組版は独立した位置を占めてきた。その位置が近年急速に変わりつつある。それはある意味では、「組版の比重が下がりつつある」ともいえる変わり方である。

かつての電算写植やワードプロセッサーによって組版から始まった印刷技術のコンピュータ化は、次第に後工程にその適用範囲を伸ばし、現在では、全工程をコンピュータでトータルに管理することが可能になり、そのようなシステムを採用しないまでも、トータルな管理が理想であるという認識は業界共通のものになっている。

いっぽう、組版の周辺あるいはその前工程では、情報処理一般との接点が拡大し、その結果として、組版を独立した工程として見なすことが無意味になりつつある。いわば、組版の独自性・独立性が薄まり、印刷工程全体における組版の位置が低下したのが、コンピュータ化の皮肉な帰結である。もちろんこれは、組版が不要になったというような意味ではない。しかし、作業としては質量とも比重が下がりつつあり、むしろ組版の周辺を固めることによって、組版そのものは自動化されて行く、というのが目下の流れである。

従来のDBと組版
その流れを象徴し、実際にも主導しているのがDBP（データベース・パブリッシング）である。
DBPとはむろんDB（データベース）を利用したパブリッシング。ただし、パブリッシングの意味は、必ずしも書籍や雑誌の出版ではない。パブリッシングとは、たんに配布すること。つまり、本や書籍の出版を含め、データをチラシや車内吊り広告の形にして公開することもパブリッシングなら、インターネットで流すこともパブリッシングである。

ところでDBパブリッシングは、印刷業界で今はじまったことではない。中小印刷業界でもすでに早くからDBソフトを使った組版が行われてきた。とくに日本語環境で使いやすい「桐」は広く使われ、現在も各所で重用されている。
この「桐」をはじめとする初期のパソコン用DBソフトを組版に応用した使い方が、DBパブリッシングの基本である。つまり、組版データとして組み上げる代わりに、まずDBを構築してデータを整理し、最後に一気に組版データに変換する。原理的には現在いわれているDBパブリッシングとなんら変わりはない。

10年前、15年前と現在の大きな違いは、DBの位置づけ、あるいはDBというものに対する認識である。
DBを利用した従来の組版では、あくまでも目的は組版にあり、その限りでのDBであった。そのため、DBの設計にあたって、どうしても目的（組版）に適した構造を優先し、かならずしも汎用性の高いDBは必要とされなかった。つまり、組版が主であり、DBは従である。

たとえば……
現在のDBパブリッシングでは、DBが主であり、組版は従である。これはデータというものの本来の姿でもある。
DBの具体的・技術的なあり方は置くとして、たとえば、全国に店舗を展開するファミリーレストランを仮定して考えてみよう。
このレストランが全国共通の品ぞろえを用意しているとすれば、普通は全国共通のメニュー（品書き）を作るだろう。しかし、それぞれの地域の客層の好みを見込んだメニューを作ろうとすれば、店ごとの客の動きを示すデータが必要になる。その場合、最も必要なのは品目の売り上げランキングであろう。そのデータは、当然本部のDBにあるだろう。メニュー作成のシステムが整っていれば、このDBから個別店のメニューを切り出すのは容易である。
重要なポイントは、このDBがメニュー作成のために作られたものではなく、売り上げ動向から、仕入れ、人員配置まで含めた経営全般のためのDBであろうということである。つまり、メニューの作成は、このDBの目的のごくごく小部分を占めるに過ぎない。つまりDBが主、印刷（メニューの作成）は従である。

もっと小さな応用例も考えられる。このDBからは、当然各店の売り上げの季節変動も切り出せるだろう。つまり、季節ごとのPOPなども、DBを利用して最適の時期に最適のものを作成することが可能になる。せいぜい量にして数枚から数十枚、インクジェットプリンターでも可能な仕事である。地域に配布する季節ごとのチラシなどについても、同様のことがいえる。
全店共通のメニューから、各店の季節ごとのPOPまで、必要な印刷物をDBから切り出してくるのがDBパブリッシングである。ひとつひとつの印刷物のためにデータを集めるのではなく、より大きな目的（この例では経営）のために蓄えられたデータを利用して印刷物を作るところに、しかも半ば自動生成するところに、このコンセプトのポイントがある。

DBは誰のものか
得意先のDBパブリッシングに、印刷会社としてどうかかわっていくか。
かつて、「軽印刷御殿医説」というのを唱えた経営者がいる。特別な事情がなくても殿様のもとにうかがって脈をとってくるのが御殿医。もちろん軽印刷のフットワークの軽さからこういう言い方をしたもので、すぐれた印刷営業マンなら業態を問わず、このような活動はしている。DBパブリッシングとは、この御殿医のあり方を現代化したものにすぎない。印刷物に直接かかわるデータだけを見るのではなく、殿様の顔色から、その日の天気、庭の様子まで見ながら、印刷物を掘り起こすのがすぐれた営業マンであろう。

このように得意先の懐に入り込むには、現実には多くの課題があるだろう。ひとつだけ本質的な問題をあげておく。印刷会社が得意先のDB構築に関わった場合、個々のデータなり、その集積としてのDBは、印刷会社のものか得意先のものか。これである。

結論をいえば、これは得意先のものである。版下やフィルムの所有権の問題と同じで、電子データについても純法律的には印刷会社側の権利を主張できる部分はいくらでもある。しかし、現実の得意先と印刷会社の関係は力関係であり、データの利用権を主張すれば得意先との関係が切れることもある。いっぽう、利用権を渡してしまえば、得意先がそのデータを別の印刷会社に渡して印刷物を作らせても文句は言えない。
こうした難しい問題を乗り越えるには、印刷会社が得意先のDBの運用に参画するほかはない。データなり、DBなりを、自社のサーバーに置くか、得意先のサーバーに置くかは根本的な問題ではない。DBの運用に関われるかどうかが岐路である。

結局、組版は従
SGML、XMLなどの汎用データ形式の普及や、メーカー各社が開発に力を入れているDBシステムの普及にともなって、今後、多くの組版は自動生成に移行する。結局、これまで印刷会社が培ってきた組版スキルの価値はは、相対的に低下するほかない。

組版のバッチ処理や「桐」による組版データの生成に馴染んだ会社は、このような流れにも比較的ついていきやすいであろう。しかし、DBパブリッシングの運用レベルは、組版のバッチ処理などのレベルを大きく越えている。かなり取り組み甲斐のある課題、というより相当な覚悟のいる課題といえるかもしれない。
得意先のDB構築に関われること、それにとどまらずDB運用に関われること、これができないと他社あるいは他業界に奪われる仕事がますます増えてくるのではないか。
Mail to SHOWA