入稿システムが必要とされる背景
WEB入稿システムが必要とされるのは、複数メーカーから原稿を受け付けるタイプがほとんどで、その理由は、「とりまとめるのが大変だから」がダントツです。
確かに、とりまとめ＝原稿整理、進捗管理は、非常に大変です。
原稿がなかなか出てこなかったり、画像がこなかったり、逆に一旦もらって進んでいる途中に差し替えが来たりと、、、下版日が刻々と迫る中、気が狂う人が出るのも頷けます。
それでも、カタログに手を出すのは何故でしょうか。
いわゆる厚物で、印刷会社としては金額もそこそこでしょうし、そういう大変なものが出来るというステータスもあるのかもしれません。自分にはこぞって獲りたがっているように見えます。
一方で、客側は、紙カタログの部数を減らして、WEB用にPDFで展開したり、検索サイトにしてしまったりということもしているので、紙が無くなるわけではないですが、そこへ向ける力のいれ具合は、違うように思います。
また、自社の基幹システムのデータなど、基本となるデータはあるのだから、これを上手く使えばDTPなんて楽にできるんじゃないの？と思われているかもしれません。
そういう中で、客側の手は煩わせず、データを渡すから上手く使ってね、最後にはデータを使いたいので返してね、印刷（制作も含む）が安ければ出すよ、と難題を受け入れざるを得ない状況ではないでしょうか。
相談を受けるカタログの特徴を挙げると、
- 頁ボリュームが多い
- 年1回、2回など定期もの
- 複数メーカーからの原稿回収、やりとりが大変
- メーカーから受け付けた後、掲載情報として精査、追加編集する
- 客先から何かしらの商品データがくる
- 商品スペック部分はある程度パターン化されている
- 商品の流用画像や新規撮影画像など画像の取り回しを考慮する必要がある
- 索引がある
- 完全自動組版にできない理由がある（デザイン調整が必要など）
そして、どの工程の人たちも一様に大変だ、というのが現状です。
この現状を打破するために、入稿システムが欲しい、となるわけです。
カタログ制作でやりたいことは？
やりたいことは、単純に書くとこうなります。
つまり「データを上手く使って本を作りたい」となります。
本やWEB、その他メディアに向けたコンテンツ制作における効率の良いサイクルを確立したい、ということです。
しかし、現実はなかなか難しい状況のようです。
今までに相談をしてくれた人たちの状況をみてみると、以下のようになります。
- 客先からきたエクセル（CSV,XMLなど）を使って手動DTP
- FileMakerからツールを経由して半自動DTP
- WEB入稿システムまでは作ったが、DTPは完全非同期
- 最後に返すデータはDTPから書き出すか、直接エクセルを手作業で作成
どうみても、それぞれの工程でデータが切り離されていて、本来やりたいことにはほど遠い状況で混沌としています。
「データがあれば本ができる」というのは難しいかもしれませんが、それでもこれを理想論で留めるのではなく、目指さなければいつまでたっても同じ悩みで停滞してしまいます。
入稿システムの範囲
一括りに入稿システムといっても、どこまでやりたいか、予算によってその範囲を決める必要があります。コストがかからない順にいくと、以下のようになります。
- メーカーがログインして自社商品情報をエントリーするだけ（メーカー側の機能）
- エントリーした商品情報を精査、管理するところまで（編集側の機能）
- 自動組版または半自動組版データの生成（DTP側の機能）
- データ活用のためのデータ出力（客先のシステム部などのための機能）
※3,4は手法によってコスト順位が変わります。
これらは、１だけ、２までなどでも可能ではありますが、本来の目的を達成するためには、3、4まで考えなければ中途半端になってしまいます。
入稿システムを使った制作サイクルの具体例
数年前から、色々なタイプのWPS.3をカスタマイズしたカタログ制作向けの入稿システムを稼働させていますが、事例をもとに前述の要望をもう少し具体化すると、以下のような制作サイクルになります。
これは、入稿システム上でデータ校了になったことを前提にDTP作業に入り、その後は一般的な印刷物制作の流れを組むものです。システム上からDTPへのデータの引き込みは、スクリプトやCSVなどいくつかの手法があります。
完全自動組版と半自動組版
1と2は、業務フローが確定すれば、それほど大変ではないので、3と4について、現実的な問題はさておき、考えてみます。
データ活用のために入稿システムが存在するとき、PDFを作る系統は２つあります。
上段の流れは、入稿システムから直接PDFを出力する流れ「完全自動組版」の例です。これはWPS.3（自動組版エンジンはAH Formatter）で実現しています。
下段の流れは、入稿システムからIDMLをダウンロードしてDTP作業（InDesign）によってPDFを作る流れ「半自動組版」の例です。IDML Binderが例となります。
※IDML Binderに関する記事は以下を参考にしてください。
完全自動組版の場合の新規・修正の流れ
完全自動組版では、入稿システムから直接PDF（印刷仕上がり）を確認できるので、修正がある場合は、原稿を作成する本人がシステム上で修正をして再度PDFを生成すれば、入稿システム上で完全校了になります。DTP作業が介在する必要はなく、大きな業務効率化が可能です。
半自動組版の場合（入稿システムからの自動生成は初校時のみ活用）
半自動組版では、入稿システムで生成されたIDMLをダウンロードして、DTP側で開き、デザイン調整を行います。校正者から戻ってきた朱字をDTP作業で修正、調整します。
新規作成では、IDMLによって半自動で組版できるメリットはありますが、その後は通常DTPとなり、データを戻すためには、スクリプトなどを使って必要なデータを校了後のDTPデータから取り出して入稿システムへ戻します。
この戻す作業は、かなりテクニカルことが要求されたり、人の手によって無法地帯となったDTPから100%データを戻すことは不可能だと思った方がよいです。
半自動でもデータ活用を重視したい場合
半自動でもデータを戻したいということであれば、戻すことを考えるよりも、データとしてメンテナンスしなければいけないところは、入稿システムを修正し、再度IDMLをダウンロードして、変更部分だけを使う、というのでもよいのではないでしょうか。
この方法であれば、最新データは入稿システムに必ずある状態です。DTPで修正する場合も、最新のIDMLを使う（部分的にでも）ようにすれば正しいデータが反映されることになります。この考えは、カタログでよくある在版流用でも生きてくると思います。
完全自動と半自動のハイブリッド
もうひとつは、完全自動と半自動のハイブリッドです。
これは、データ部分は、自動組版によって、印刷仕上がりも確認しつつそれでOKならそこで完結し、それをラフデザイン原稿レベルとして、DTP用のデザイン原稿として使うというのもアリです。このあたりは組み合わせによって色々パターンがあると思います。
最後に
システムで楽になるか？というと、「楽になる」というポイントは、人によって違います。とにかく自分の手を煩わせたくない、丸投げタイプの人にとっては、システムによって増える工程を「手間が増えた」と考えます。
例えば、入稿システムがあれば、今まで期日通りに入れてくれなかったメーカーさんが原稿を入れてくれるかというときっと変わりません。システムはただ面倒に見えるだけです。別にそれが悪いとは思いません。どちらかというと普通だと思います。
一方で、データの活用や業務の効率化を真剣に考える人（普通ではない人）にとっては、システムによって安定したフローになったことで「無理しなくてよくなった、楽になった」と考えます。
原稿整理や進捗管理する人、メーカー担当者も、DTPもみんなの気持ちが楽になったと思えるようになればまずは成功だと思います。
システムに対する考え方が、それぞれの立場によってもこれだけ違うわけなので、目指すべきところは、何も考えなくてもいい、簡単に使える、という路線と、どんな要求にも対応できる柔軟な考え方と、データの居場所を確保する裏方の部分をしっかり構築する路線が必要なのだと思います。
また、カタログ制作が一様で、データの中身も変わらないのであれば、入稿システムは必要ありませんが、毎年更新が必要であり、内容もデザインも変わるということにシステム的に柔軟に対応し続けるためには、常にメンテナンスが必要、そこにコストがかかる、ということも内外で理解しておくことも重要です。
次の世代に繋ぐためにも、少しでも理想に近づくため、あきらめずに続けていきたいと思います。
0 件のコメント:
コメントを投稿