みんながんばってるんだよ

初めて大阪DTP勉強会に参加してきました。
1番ゲットの賞品もいただきました！　いやー、すみません、お手を煩わせてしまって＞えむさん
大阪以外でそれまでにお会いしていた方が多かったので、緊張しないで済みました。
翌日の大阪食い倒れツアーも、まさかあそこまで面倒みていただけるとは。
みなさん、本当にいいかたばかり。ありがとうございました。
逆に今回お世話になった方々が東京にいらした折に、果たして自分があそこまでアテンドできるかと考えると。うわー。どうしよう。23日！

ところで、懇親会で初めて同じ社のひとに会いました。
本当に嬉しかった。
それまでは「なんでウチの人間はこんなことも知らないの？　出来ないの？　なんでもっと上を目指そうとしないんだろう？」とイライラしてました。
「困ったときはRRRさんに訊けば・やらせればいいよ」てのにいい加減うんざりしてました。
でも、現場レベルではみんなちゃんとやってんじゃん。
ダメなのはウエなんだよ。
※主に私にいろいろ訊いてくるのはウエの人間たちです
と、同時にもっと現場レベルが交流しあって、ウエにもっとアピールしなければならないとも痛感しました。
そんな大きな会社でもないくせに各地域で分裂してて、それぞれが同じことで困って同じ道を通ってる。
ウエの派閥だの、ケンカだのに巻き込まれるのはもうたくさん。
"Do the RIGHT things".
一緒にがんばりましょう。今後も交流しましょうね。

洗濯

おひさしぶりです。

この２ヶ月の間に異動があったりしてちょっとごたごたしてました。
新しい部署でもいろんなことが起こる毎日なのですが、よかったことがひとつありました。
JavaScriptの勉強会があって、参加できるようになりました。
きちんと基礎からやっていなくてかなりいい加減なので、とても勉強になっています。
先日ふと思い立って先生に「人間ができなくてスクリプトでないとできないことはなにか」と訊いてみました。
この勉強会は「これからスクリプトを自分で書いてみよう」という人を対象に開かれているので、いまひとつ「スクリプトってなんになるの？」と思っている人が多いみたいに感じたのです。私は。
先生の答えは
「人間ができないことをするのではなくて人間がすると面倒なことをするもの」
でした。

それでもなんか初心者さんにはピンと来てないみたいでした。
多少なりとも自分で書いてみないとわからないのかもしれません。

今日、洗濯をしていて急に気がつきました。
「スクリプトって洗濯機かも」。
昔は手で洗濯していました。
だから洗濯機はなくてもよいのです。
でも洗濯は重労働だし、やってる間はかかりきりになってしまう。
洗濯機はセットさえしてしまえばあとは機械任せ。
その間は他のことができるわけです。しかも早い。

どうでしょう。違うかなー。

まるで食わず嫌い

大変遅まきながら、つぶやきはじめました。なんかまだまだ使いこなせてないんですけど。フォローしてくださったかたがた、ありがとうございました。

ブログとどこが違うんかい！て思ってたんですが、やはりリアルタイムに情報が伝わってくるんですね。
で、この話題を知りました。いやー、びっくり。
件のページにも書いてありますが、やっぱりハードル高いんですね。グラフィックソフト（オンリーの）ユーザーがページレイアウトソフトを使い始めるのって。特に文字組みとか、スタイルの設定とか。
でもなぁ。そうやって食わず嫌いしてるのって損してるよなぁ。
って、正規表現を未だに覚えてくれない同僚にも同じように思ってるんですけどね。

しかしこのページ、「英語を覚えなくても生きていける」とか見識の偏りすぎがもう、ねぇ。
このセミナー、誰か聴きに行って思いっきり突っ込んできてはくれまいかｗ

黒船来襲なんだって

昔々。まだレコードというものがあったころ。
私は（主に輸入の）レコード店で箱アサリしてジャケ買いするのを楽しみとしていた時期がありました。
CDになってからはぐんと減りました。

今、ジャケ買いするもの。
本。
私の中で、装丁って結構大きいんです。購買動機として。

電子書籍になったらどうなるのかなー。

または。
2008年のInDesign Conferenceで、京極夏彦氏がケータイ（ネット）小説が書籍という形をとるとなぜつまらなくなるかの理由として、英語が聴覚言語であるのに対して日本語が視覚言語であるからだ、と仰っていました。
このあたりも、どうなっちゃうのかなー。

無念Booster

ただいま1/19　午後7時過ぎ。
そして私は会社にいる。

ああああああ。

あかつきさん、応援するとか言っておきながらごめんなさい・・・。

謹賀新年。

旧年中は大変お世話になりました。本年もどうぞよろしくお願いします。

いやぁ、クリスマス前にインフルエンザに罹ってしまいまして。
えらい年末でした。
面倒なことがほったらかしになっていてかなり憂鬱な年明けです。

去年はたくさんの人に出会うことができ、たくさんの収穫を得ました。
なかなか自分から情報を発信できなくて申し訳なく思っていますが、今年はみなさんに遅れないようがんばってついていきたいと思っています。

私も応援しています。

もう既にご存じのかたは多いと思いますが、「InDesignエッセンシャルハンドブック」のこと。
とてもお世話になっているかたがこのような目に遭われていることは、とてもつらいことです。
特にお世話になったのは、IDMLドキュメントの翻訳時です。無謀にもCS4をインストールしないで取り掛かってしまったがために、メニュー名、機能詳細などをいち早くたくさんレビューしていただいた勉強部屋HPがなかったら、とても不可能でした。
何もすることができなくてはがゆいですが、一日も早くよい方向に向かわれますよう。

木を見て森を見ず。

ある自動処理製品を使って組版してるんですが。
使っているのは別の部署なので名前や仕様はしらぬ
ちょっと不具合なんだか、仕様なのか、設定ミスなんだか、目次の生成をするとレイアウトが変わってページがずれてしまうことがあるんですね。ということは後でわかったのですが。
クライアントとは目次生成前に本文だけのデータで校了してるので、生成前の校了データを印刷工程にまわしていました。それに別途、目次の分を後から入れてたわけですが。
それじゃ目次、合いませんわね。本文と。ということで発覚しました。

さあ、どうしよう。
自動処理している部署いわく
「目次生成後のデータで印刷すればよい」
そうすれば確かに目次は合ってますわね。

ちょっと待った。
レイアウトのことはどうでもいいんかい。

大量ドキュメントは流れ作業・作業の分割化で確かに効率よく処理できるけど、自分の工程・都合だけを考えてちゃだめだよ。
他のひとが何してるんだか、自分が流れのどこにいるんだかも気にしようね。

暖簾に腕押し

Aさんが他業務で忙しく、ま、代打として仕事を引き継ぎました。
一応、こうやってました的作業手順書らしきものをいただいたんで見てみたら、その手数の多さと煩雑さに仰天。
いや、指示が細かいのは大変よろしい。
でもね。これを毎回繰り返すわけ？
めんどくせー！！
たとえ1回でも嫌だわ。これは自動化するしかないでしょ。
Aさんがかかっていた時間よりもかなり早く終わらせられました。ふふん。
ふと思った。Aさんは今までこれをちまちまずっとやって来たのか。凄い忍耐力だね。あ、褒めてますよ。自分にはないものだからね。
自動化に取り組むか取り組まないかの違いって、忍耐力の有無の差なのではないかと思うときがあります。
あと、自分は時間の無駄遣いと残業が大キライなので、とにかく早く作業を終わらせたい一心で自動化している部分もあります。

でもこういったことが苦でない人は、難しいスクリプトとかの勉強をするよりはひたすらもくもく手を動かすほうを選ぶのではないかな、と。
InDesignやる人はせめて正規表現わかってたほうがよいんじゃないかなー、といくら言っても余計なお世話だったりするのでした。
糠に釘。

自動化する理由

今日はひさしぶりにIDのJavascriptを書きました。
今まで私が書いた他のもそうだけど、
「メニューからできるものをスクリプトで処理する」
という類のものです。
なんでわざわざ？とお思いになるかたもおられるでしょう。
【理由1】
勉強のため。スクリプティングそのものもですが、データの構造を理解するのによいと思います。
まあ、これはプライベートな理由です。

【理由2】
作業工程／結果を均一にする。
これが一番大きいです。
主に、他人（しかも大勢）が作業するときのためのものとして書くスクリプトです。
メニューからできるものをなんでわざわざスクリプト化するかというと、
・人によって処理が変わる（ex：AiでK100にプロセスを使うか、グレースケールを使うか）
・やり間違える
・作業モレ
これらを防ぐためです。
一人の人間が最初から最後まで同じデータを扱えればよいけれど、如何せん大量ドキュメントでは分業、流れ作業をすることになります。
そうなったとき、全員が同じ作業を同じように行ってもらわなければ困るのです。
全員が同じようなスキル（しかも高スキル）と経験値を持った人間ならば、こんな準備をする必要はありませんが。
テクニカルドキュメントならではの事情でしょうか。
作業者のスキルをアップするのと、どんなレベルの人でも作業できるような工程を考えるのと、どっちがよいんでしょう。悩ましい問題です。当然、両方を並行して行うべきなんでしょうが、なかなそうもいかないんです。
セミナーでのテーマや、懇親会で伺うお話なんかだと、一人で完結するような作業工程を前提としたものが多いんですよね・・・。

自動処理コワイ

やっちまったです。久しぶりに。

単純な作業なんですよ。
2つのpdfデータがあります。1つは本文、もう1つは表紙。
本文pdfの先頭に表紙pdfを挿入するだけなんです。
1セットだったら手動でやりますが、いっぱいあるんですね。
で、Acrobatのバッチ処理をしました。
何回かにわけて入稿されるので、来た分で検証。
表紙pdfになぜか白ページがついていて2ページになっていたので、本文pdfに挿入後、2ページ目を削除という処理を、付け加えました。
たった、これだけ。
このときはうまくいってたんです。
それなのに。

何日か経って、次の分が入稿されたので、何の疑問も抱かずにバッチ処理。
そしたら。
本文の1ページ目が消えた？？？
・・・。
表紙pdfの余分白ページがなくなっているじゃないかー！
勝手に仕様を変更するなよ・・・・。
まあね、こっちも勝手にバッチ処理でしているので。文句は言えません。
他人が作ったデータを処理する自動処理は怖いですぅ・・・。

ここ数日のわたし

• 久々にXMLの仕事をする。既に構造化されたFrameMakerデータの修正作業。ところが原稿作成者がまるで構造化文書を理解していない。無駄なところに労力を使って、大変疲れた。
• で、それとは関係なくFrameMakerの問い合わせ。テキストフレームをインラインのアンカーにしても構造上大丈夫かどうか、と。わからなかったので、そういえばFrameMakerでブログ書いてる人はいないのかな、と検索したら前の会社がヒットしてしまった・・・。あまり円満とはいえない退社の仕方だったので、辞めたあとどうなったのかはまるでわからない。執筆陣の名前を見ると（実名で書いていた）、知っている人ばかり、というか、あんたまだいたの？てな具合。しかし、あのころはまだ新人で、ほとんど私が教えたような人たちばかりが、まぁ、大人になったじゃないの。とまるで親戚のおばさん気分。結局、FrameMakerについては未だわからず。
• あちこちから次回セミナーの案内が届く。10月にいたっては、二週連続。（大阪、名古屋）さすがに両方は行けない。テーマ的に行きたいのは大阪。でもその日は予定が・・・。名古屋はカワココさんと鷹野さん！個人的に両名のファンなのだが、ちょっと腰が引けている。（すみません）なぜかというと、今月のシルバーウィークにちょっと散財する予定が・・・。11月にはDTP Boosterが早くもやってくる。こちらは参加予定。

何が必要？

今日はDTPの話ではありません。でも最終的に着地させてみせましょう。ふふ。

昔、翻訳会社に勤めていたことがあります。
翻訳コーディネータ兼DTPオペをしていたのですが、ちょっと翻訳の勉強もしたいな、と思ってベテラン翻訳者の方に指導してもらったことがあります。
そのときに言われた、翻訳者にとって必要な資質。

　「一に日本語（orターゲット言語）、二にその分野の知識。三、四がなくて五に英語（orソース言語）」

いくら英語ができても、最終的な表現方法となる日本語のチカラがなくては、文章（作品）として成立しない。
逆に英語ができなくても、その分野の知識と正しい日本語の使い手であれば、読み手にとって意味の通じるものを作ることができる。
極端に言えば、英語力だけあってもダメ。伝えたいという気持ちと、それに見合う表現力が備わっていなければダメ。
さて、何で今日こんなことを書いたかというと、とある案件の、クライアントの翻訳に対するある指摘がきっかけです。
どうやら、「High」「Low」の訳し分けの問題のようです。
何から何まで全部「高い」「低い」とやってしまってはだめなんですよ。ものによっては「大きい」「小さい」という表現にしなければならない。
※例：電圧→高い、低い　電圧降下→大きい、小さい
英語が不得手でも、電気関係に明るかったら訳し分けられるでしょう。
英語、電気関係が不得手でも、日本語能力が高ければ、降下を表すときに『高い』という表現はおかしい、と気づくでしょう。
英語しかできない人、言葉ヅラでしか仕事をしていない人には、その違いはわかりません。
翻訳って深いですよね。そう思って、その道は諦めました。

さて、DTPに戻ってきましょうか。
DTPって、何ができればヨシ、となるんでしょう。
っていうか、DTPって何？
そう思ってつけたタイトルが「What' in DTP」なんです。
「What's DTP」じゃないですよ。
DTPって何？じゃなくて、DTPには何があるの？（何が必要なの？）という気持ちなんです。
最近、セミナーやセミナー後の懇親会でいろんな方々とお会いして、ほんとーに！自分はまだまだだと痛感しております。
着地できたかな？（＾＾；）

発想次第で。

思わず「おおぅ・・・」とため息をもらしてしまいました。
いや、ここに出ているガンプラにではなく。

「どうしたらそんな風に（工程が）さくさく考えつくの？」と訊かれることがあります。
実際、現在の自分の業務の大半は（効率化を含む）作業フローの策定がメインです。
でもね。そんな特別なことじゃないと思うんだけどな。

例えば。
遊びの予定。楽しいことを決めるときは詳細に渡って考えられるのに、どうして「仕事」だとツメが甘くなるのでしょう。
自分の趣味。私もプラモデルを作ったことはないんですけど、無計画に手当たり次第にやるもんじゃないんですよねぇ？

話は少し変わって。
名古屋から帰ってきて、翌日美容院に行ったんですよ。
美容院に行くと、いつも人間観察しちゃうんです。客じゃなくてスタッフの。
「私」という「案件」を、どのように回していくのか？どうやって平行作業を可能にしているのか？（私が行くところは1人の美容師さんが同時に複数担当しています）
私自身はなかなか楽しいし、飽きないんですけど、やっぱヘンですかねぇ。

用語は正しく

こんな事故があったそうです。

これに関してあるかたが書かれておりました。
「これは『乱丁』ではない。『面付けミス』ではないか？」

確かに。
「乱丁」だったら、こんなページ単位での乱れは発生しませんよね。
で、問題となるのは、
「乱丁」と書かれてしまうと製本のミスに
「面付けミス」と書かれてしまうとオペレータのミスに
と、どこに問題があったのかがまるで違ってしまうことです。
印刷関係者でなければ気づかないといえばそれまでですが、濡れ衣をかぶせられてしまった製本担当者はお気の毒です。
たぶん、工程のわからないひとが書いた文章だとは思いますが、会社名で出している以上は正式な文書なのです。
まあ、あまりあってはならないことですが、事故報告書などを作成しなければならなくなったときには十分気をつけなければいけませんね。

give and give

せうぞーさんがブログでドネーションへの協力を呼びかけている。
自分も今まで散々お世話になってきたし、毎日チェックしているし、紹介もしてきた。
かといって、Adobeソフトは買わないし、マカーじゃないし。できることといったら、次からはここからAmazonを利用するくらいだ。

せうぞーさんでも、疲れちゃうんだな。
何か他のことがあったのかもしれないけど。

自分もこのブログをはじめてたった2ヶ月で、実は心が折れかけていました。
いくら"give"しても何も"take"できないじゃないか。
一方通行はつらいよね。

でももう少し、がんばってみることにしました。
それこそせうぞーさんに言われた「情けは人の為ならず」で。

Adobe Design Summitで教わったこと

• クライアントの意図（編集、企画の主旨）をきちんと理解できているか
• 時間をかければいいというものではない。良いものをつくるひとは、作業時間も短い
• 作業時間をかける、何度も校正出しをするということは、クライアントに対しあるところまでは丁寧さを伝えることができるが、度が過ぎるとクライアントの負担が増えてかえって逆効果。クライアントのニーズが読めていないと受け取られ、マイナス評価にもなる
• 作業に何らかの付加価値をつける（デザイン性、早さ、正確さ、プロセスの創意工夫）
• 製品知識があるにこしたことはない。迷ったときの判断材料にもなるし、他社・者との差別化につながる
• 作業において「こうしたい」という強い思いがあるか。道具（環境）だけ良いものを揃えても良いものができるわけではない

Adobe Design Summit参加

5/20、Adobe Design Summitに参加してきました。
Tips Day関係の詳細はDTP Transitを参照してください。
鷹野さんいたのか・・。見つけられなかった。何せ600名満席ですし。壷のKOUJIさんはお見かけいたしました。Yujiさんには挨拶できました。
個人的には、アプリケーションのTips以外の収穫が大きかったです。
とくに「こびとのくつ」の工藤さんは、そのお可愛らしいルックスとは裏腹の、仕事・会社経営に対する厳しい姿勢に身が引き締まる思いでした。
あまり期待していなかったトークセッションでも、デザイン・DTPがどうこの不況を勝ち残っていくかというお話が大変参考になりました。

去年だったか、何かのセミナーで郡司さんが
「こういうところに来るひとは大丈夫なんだよねー。問題は来ないひとなんだよな」
と仰っていました。今回600名満席の盛況ということで、「大丈夫なひと」はたくさんいるんだな、と安心したのも束の間、どうしてここにうちの社員はいないんだろう、と哀しくなりました。

来る「時間」がないんじゃない。「気持ち」がないのではないでしょうか？
馬を水辺に連れて行くことはできても、水を飲ませることはできない。
このブログもどれだけ意味があるのか、わからなくなってきました。

はじめての作業。

今まで自分がやったことのない作業を、似たような業務の経験者にやり方なりコツなりを訊いても、
「いやー、たいしたことはやってないよ」
と答えられてしまった場合。そんなに大変じゃないのかー、そうかー、と思って始めてみたら思いもよらない工程に時間がかかってしまったりして、作業時間が読めなくなってしまいます。
訊き方を工夫しましょう。

• どんな工程が一番時間がかかるのか
• 標準化できる作業はあるか（誰がやっても同じ結果になるような作業はあるか）
• どんなミスをしがちなのか。またそれを見つける／防ぐ方法は

まあ、最初から答える側がここまで教えてあげればそれで済むのですが、よほどの世話焼きでなければ無理ですね。
逆に言えば、自分が訊かれたときは極力「相手の側に立って」答えてあげられるようにしたいですね。
いろんな仕事の取っ掛かりに携わることの多い自分への戒めとして。

激しく同意。

InDesignの勉強部屋BBSにてのコメント。

はるさんは何でもかんでもすぐに聞かないで、一度冷静になって色々な原因を考える事をした方がいいですよ。少し前の「 マスター頁でフレームグリッドが1ミリずれてしまいます。」も時間があるので作り直すとのことですが、私だったら時間があれば徹底的に原因を追及します。わからない事を後に送ったり、すぐ人に聞いたりするといつまでたっても覚えませんし、すぐに他の部分でつまずきますよ。前のスレで (-_-メ)さんも書いていますが、一度徹底的に実際に使う機能かどうかわからない所までいじり倒したほうがいいです。

ちょっとこの「はるさん」というひとが困ったチャンになりつつあるのでなんだかなぁー、と思っていたら。