最近、自分で文字を書いていて、ふと思った。
「自動組版」と「自動作成」って違うよなと。
どっちかというと、完全に印刷用データ（今ならPDF）を作ってしまうのを「自動作成」、DTPアプリに依存度を残すことができるものを「自動組版」と言った方がいいんじゃないかな。
ま、自分のことなので、どうでも良いかもしれないですが。
えー、本題。まだ草稿です。ご意見いただきたいな。
毎回言いますが、ヤワな生き物なので、優しくお願いします。
「はじめに」
DTPの効率化を、「コスト削減」という入り口から入ってきた場合、要は、かかる時間を削減する、ということなので、じゃあ、組版するところを、自動でやればいいじゃん！なんてところがゴールだと考える。入稿（In）も出稿（Out）もパターンが一定ならOKです。言われれば100％完全自動「作成」システム作ります。入力してボタン押したら、PDFが数秒で出てくるの作れます。でも、今までかかってる「コスト」ってそこじゃない。そんなところなら、みんなが真剣に考えて、統一してしまえば終わりです。
※InOut理論はTyamaリスペクトです。
「つまり要求はない、ってことになる。」
でも、みんなが望んでいることは、そうじゃないのが現実。
入稿もいろいろ、出稿もいろいろ。InもOutもバラバラということです。
つまり、Inするものがバラバラである限り、Outもバラバラです。
「コスト」がどこにかかっているかというと、この「バラバラ」部分です。
この部分を、解決することを考えなければ、「コスト」はいつまでたっても削減できません。
そしてもうひとつの重大な過失「使い回しができない、つぶしの効かない（将来性のないという意味で）データにしかならない」ことです。
そうそう、こういうシステム構築で、要件定義をまともにやろうと思うのは、そもそも間違いです。システム開発の世界で、要件がその時点の要求でしかないことで、意味がないことであることもさることながら、どんなものをInするか、どんなものをOutするかさえ、使ってみないと決まらないということだからです。ここを追求すると、ガチガチなシステム構築か、全部手動か、というゴールにしかたどり着きません。
「InとOutを統一しなきゃコスト削減のための自動化って無理ってこと？」
んー、そうなんだけどちょっと違う。
DTPの効率化は、基盤となる環境の整備、作業ルールの整備、技術の整備を確立して、実行できれば必ず実現できる。
そこを補完するのがシステムなんじゃないかなと。
ここでいうシステムってのは仕組みであって、大仰な物ではない。
普段使っているテキストエディタだって、十分な力を持っている。
ただ、それが、自分のものだけになっていては意味がない。
入稿、出稿、校正、印刷などをスムーズに流すには、使い方が統一されていなければならない。
「でも、人がカムと事故が起きる…」
そう思うなら、システム化する。ただし、人を排除するということは、人の感覚による命令ってできなくなる。例えば、「したい（希望）」というニュアンスは無理。「する（命令）」でなければならない。「する」と言った時点で、他は排除されるということになる。（この中に分岐を書くのはアリだが）ここを「割り切れます」というハンコが無い限り、システム化は失敗する。
「じゃあやっぱり制約がありすぎて、使えない」
キタ！これがこの業界で必要な仕組みなのに導入されない理由。
かみ砕いて言うと、「いろんな物を投げるから、ちゃんと組版してね」ということです。
どうどう巡り開始です。コスト削減とかデータベース化とかしたいのに、したくない、と言っていることになります。
「DTPの効率化でコスト削減できないのは、システム化以前の問題」
コスト削減命令によるDTP効率化のためのシステム化は、前述から無理なこと、ということが分かるでしょうか。要は、したいのに、したくない、っていってる事になるということです。
で、その解決がどこに落ち着くかというと、ま、オペレータが頑張ればいいんじゃね？ですか。
「困るのは誰？」
そんな「適当さ」が目立つ業界ですが、そもそも不景気なんて言うとる前に、そこをちゃんと解決することが、今後に繋がるんじゃないですか。価格競争は、資本主義社会として仕方ないかもしれないけど、その制作作業、現場の問題・課題を置き去りにして、価格を下げたところで、モノがなければ印刷できないのでは？あぁ、海外でやりますか。勝手にやってくれ。物作りにおける重要なポイントを放棄するなら、ホントにこの業界終わりです。いか〜ん、盛り上がってきた。落ち着こう。この話になるといつもムキになる。分かるんですよ、僕も現場だから。そう簡単にはいかんぜよと。でも、そこをハナッから「できん！」じゃなくて、解決を導くために「やってみる！」と、敢えて挑戦すべきじゃないでしょうか。多分そう思う人の考えは正しいのです。でも正しい道を阻む何かが潜んでいるんです。それは人を殺してしまうような宇宙から来た未確認生物なのでしょうか？せいぜいビフィズス菌でやっつけられる悪玉菌じゃないかと。（結構手強いか）
うんまあいいや。そう。つまり困るのは自分だゼ、ということです。
「DTPからクリエイティブ的な要素は外せない」
ここでいうクリエイティブは、モノを作るときの基本である「センス」という要素が大きい。
モノを作るには、「センス」が必要です。
そして、そのセンスは、レイアウト、デザインのセンスもさることながら、めんどくさいことをしたくない、と思えるかどうか、そのポイントを発掘してアピールして解決できるかどうかのセンスだと思う。
システム開発で言われている「Don't Repeat Yourself!(DRY)」と同じ。
だから、システム開発だって、クリエイティブだと思う。プログラマはエンターテイナーであるべきだ。これは長くなるのでまた今度にします。
クリエイティブとコスト削減は、相反しているようで、実は、クリエイティブの先にコスト削減がある、とも言える。そして、コスト削減の先に、クリエイティブはない。
「コスト削減という入り口がウマくない」
つまり、DTPの効率化を考えたときの最初の入り口が「コスト削減」というのがよくないということだ。「めんどくせぇ」を時にはエレガントに、エンターテイメントに、クリエイティブにこなした先に、コスト削減がある。ここでそうじゃないと思ったら、もう一回上述を読んで欲しいです。つまり、DTPにまつわる仕組み作りで、クリエイティブさを外したら、何も成り立たんということです。「効率化」は、「コスト削減」のためのものではなく、「DRY」になるためのもんだと思うわけです。ここで目指すクリエイティブさは、無駄なく結果を出せる技術ということです。じゃなきゃずっとイラッとしっぱなしです。
「でも解決しなきゃいけない、解決してやるゼ、という気合いはどこに持って行けば。。。」
作業している人で、真剣にやっている人であれば、こんなくだらんことを何度もやりたくない、と思ってる人だけが、この行にたどり着いてるんじゃないかと。勝手に想像しつつ。。。
すでに世の中には、数多くのソフトウェアやシステムが販売されていますが、「お、なんだか、これでできそうだ！」と思ったとしても、実際上手く使えなかったりします。
ここまで言って、そんな都合のよい仕組みはないので、手作業でお願いします、というと殺されそうなので、下記あくまで指針です。
では、何を解決できるシステムならいいのか。。。
前述の「いろんな物を投げるから、ちゃんと組版してね」という要求に応えられるシステムが必要ということですね。
「システムに頼りたい部分をちょっとまとめてみる」
・登録した人は誰なのか？
・登録した日はいつなのか？
・更新出来る人、した人はだれなのか？
・削除出来る人、した人はだれなのか？
・ステータスによって状態を変えたい。例えばロックするとか。
・データの閲覧・編集に人の制限をつけたい。
・テンプレートを共有したい。
・WEB（ブラウザ）から入稿させたい。
・入稿されたものは、指定されたテンプレートでPDFを自動作成したい。
または、入稿されたデータをダウンロードしたい。（CSV,XMLとかTextとか）
・入稿フォームを登録、編集したい。
・テンプレートを登録、編集したい。
・画像をアップロードしたい。
・データを検索したい。
・過去のデータを複製して使いたい。
これ以外あるのかな？
「ちょっと欲張りになってみる。」
・アップロードされた画像を管理したい。
・権限や制限を編集したい。
・校正紙を出したい。
・データをページに配置してページアップしたい。
・別マスタデータを用意して関連付けたい。（企業マスタから住所を抜くとか）
「そして人はもっと欲張りになる。」
・テンプレートを簡単に作成したい。
・入稿フォームを簡単に作成したい。
・画像のトリミングをしたい。
・入力する文字に字数制限をつけたい。
・WEBサイトのコンテンツと連携したい。
「このへんで思うこと」
あれ？こんだけだっけ？まだある気がするが。。。
上記がすべて網羅されたら満足、解決できるのか？
そうじゃない気がしませんか？
要は、本当の満足、解決というのは、システム化によって、「いろんな物を投げるから、ちゃんと組版してね」という「、」の間に、「いろんな物を投げるから、あとは設定されているシステムのルールにのっとって、ちゃんと組版してね」の「システムの設定部分」だと思う。ここを思うように設定できればよいということだ。しかも、制約なしに。だから柔軟な仕組みが必要だということで、そして、その仕組みは、変わり続ける要求に対応していけるものである必要がある、ということです。
「ということでPA^nが出来たと」
WPSは今もお客さんから絶大なる人気を誇ってますが、なぜ使い続けられているかということを考えると、ユーザもうちもモノを作ると言う点において、真剣だということです。最初からコスト削減しか頭に無いなら、モノを作らなければ良いと思う。その方がよっぽどエコだ。
でも、WPSは、いわゆる決め打ちシステム。変更は加えられるとしても、こちらの手がいる。それは完全に、安全に出版されないといけないからです。とは言っても、これには、お互いにストレスが溜まる。変更するには、人の手がいる。そこにはコストが発生する。これは仕方ないことです。うちも「ぐへへ」ってよだれを垂らして待ってるわけではないのです。そこを排除しようとしたのが、「PA^n」。これは、仕組みを準備するので、後は使う人で決めて作ってというもの。
勘違いしてはいけないのは、「WPS」で、こちらが決めた仕様を、自分たちで作れるということだが、その裏には、自分たちでルールを確立しなければいけない、ということです。そのリスクを背負えるところには、オススメします。
決して「あんまりうるさいから勝手にやってや」ではないです。クリエイティブさを必要とするDTPのシステムでは、ここに行き着くしかない、という頂上（今のところ）なのです。
「PA^nの開発コンセプトは、何でも入れられて、何でも出せること」
つまり「バラバラ」を許容した上で成り立っている仕組みということです。入稿フォームも自由に作れる、テンプレートも自由に登録できる。組版エンジンも自由に選べる。簡単に使うこともできるし、スクリプトを覚えれば、もっとやりたいことができる。やりたいと思うことは、やりたいと思った人が試して、実現させるべきだと思うんです。いちいち仕様がどうのこうのってやりとりはイヤですよね。ただ、リスクを背負うことを忘れないように。
「まだ途中ですけど、土台はほぼできた感」
PA^nになって失敗もあったけど、稼働2社目、ともにタウン情報誌です。不可能を可能にするウチならでは。モノを作るシステムを作ることも、モノ作りです。そして、結局は人が作り、人が使うわけなので、そこには将来に描く方向性を見失わない、課題を常に解決へ導ける強いチームが必要です。
従来のシステムは、仕様ありきだから、限界が先に見えてきます（比較的早い段階で）が、ウチのシステムは、限界を見るよりは将来を見るシステム。だって色々と変わるから。そういうコンセプトを理解してもらうには、時間がかかるのが課題。でもそれはどれだけ信頼してもらえるか、信頼してもらえるような対応や結果を出すか、だと思ってます。
半年運用で調整に調整を重ねて、軌道に乗りました。次のステップに入るところです。
「来年2009年2月に行われるPAGE2009でババンと」
行こうかなと。
ただ、従来のようなシステムですよ、アプリですよ、ではないアプローチで。
賛同する方募集中です。
ふぅ〜疲れた。。。PAGEまでにはまとめていこう。
