プロフィール
初めまして。阿保丈晴（あぼ たけはる）です。
1982年生まれ、東京都板橋区出身、田無在住、妻有り、子無し。
職業はフリーランスのDTPオペレーターです。
好きなものはロボットアニメ、蒙古タンメン中本、TBSラジオ。

お仕事
組版、デザイン、組版用スクリプトの開発。
得意ジャンルは学習参考書関係でキャリアは15年ほどです。
2018年の末に15年ほど勤めた組版の制作会社を退職しフリーランスとなりました。
スクリプトを活用することで低コストで安全性の高い組版をご提案できればと思います。
また、組版データからWebやDBなどへの二次利用の実績もございます。
無駄にならない組版データ作成のご提案もさせていただければと思います。
使えるアプリケーション
InDesign、Illustrator、Photoshop、ExtendScriptToolkit、
Word、Excel、VBA、etc

自分が入社する以前の業界について
前職は主に学習参考書関係の制作会社でDTPオペレーターをしていました。
組版業界は僕が入社する少し前までは景気の良い業界だったそうです。
お酒の席で諸先輩方から「昔はよかった」「何日も徹夜した」「腕一本で食っていけた」みたいな話をよく聞きました。
制作では写研や手動機のオペレーターは今では信じられないくらいの収入をもらっていたそうです。
また、営業では受けた仕事を右から左へ渡すだけで結構な利益が生まれていたそうです。
ブローカーも沢山いたようです。最近はめっきり見なくなりました。
そして、フリーエディター、フリーデザイナー、フリーカメラマンなどの「フリー何とか」の人達が隆盛を極めていたそうです。
「元フリー何とか」の人に昔の話を聞くと、大層儲かっていたと聞きます。
好景気の恩恵というのは様々な業界にあったようですが、この組版業界にもあったというのは驚きです。
僕はこの手のお話を聞かせていただくのが好きでよく聞かせていただきました。

自分と業界について
さて、僕がこの業界に入った頃（2003年辺りかな）はどうかというと、
夢のような好景気はすでに終焉を迎えておりました。が、それでもまだ持ちこたえていたように思います。
僕が入社した頃はすでに仕事が減ったとは言われていたのですが、
「手付かずの原稿の山」や、「無茶な残業」や、「無茶な徹夜」や、「凄まじい人数の派遣の皆さん」など、景気が良くなければ見られない光景を見ることができました。
「今日はめずらしく10時に仕事が終わったから飲みに行こう！やったー！」みたいな感じとか、「元旦以外は終電まで働く」とか、「残業100時間とかあたりまえ」とか、僕も入社して数年はこの空気の中にいました。どうかしてましたね。まじで。
ギリギリで好景気の残り香のようなものを嗅ぐことができたのではないかと思っています。
ちなにみ、凄まじく働いた記憶はあるのですが新人だったのでお金はたいして貰っていませんでした。（涙）
そんな時代を経て、その後、徐々に徐々に、景気が悪くなっていったように思います。

現場で感じた不景気１
まず、制作する書籍の数が徐々に少なくなっていきました。
僕の勤めていた学参業界では４年に１度、大きな繁忙期を迎えます。
教科書が４年に１度、改訂を行うためです。
教科書の改訂に伴い、参考書や問題集やドリルやテストなどの教科書以外の教材も改訂を行います。
その際に大量の書籍を制作していたのですが、繁忙期は回を追うごとに制作する量が減っていったように思います。
減った理由は色々あるとは思いますが、よくわからないので詳しくお知りになりたいのであればググって下さい。
僕が現場で聞いた感じでは、「少子化で子供がいなくて〜」とか、
「Webが出てきて本が売れなる〜」とか、「いや、紙はなくならない〜」とか色々ありましたが、
どれも酔っ払ったおじさんの愚痴みたいなやつなので真に受けてもしようがない話でしたねー。
はじめにある程度きつい繁忙期を経験している僕は、繁忙期が終わる度に、
「今回は楽だったな〜」と呑気に思っていたことを思い出します。
末端のアッパラパーなDTPオペレーターだった頃は考えもしなかったのですが、今、思うと経営陣は頭を抱えた事でしょう。

現場で感じた不景気２
次に、技術革新により制作コストが下がったことがあります。
ある時期から印刷の主流がオフセットからCTPへ変わりました。
フィルムの出力は結構な費用になります。
出版社がこの費用をカットしたいのは当然の選択でしょう。
この費用がごっそり無くなったことは結構な打撃でした。
当時は「フィルムで確認ができないからミスが増えるに違い無い。」とか、
「ストリップが生産中止になったからスト貼り修正ができない」とか、
「フィルム出さないから修正が楽になっていい。」とか、
色々言われてたことを思い出します。
納品物がフィルムからPDFになり、制作作業は正直、楽になりました。納品はCDに焼いて終わりです。
重たいフィルムを運ぶこともありませし、朝から晩まで青焼き機にフィルムを突っ込むこともありませんし、フィルムをどこに保管したかわからなくなって大きい引き出しを端から端まで探すこともありません。
ただ、会社は大きな収入源を失いました。
これまでと同じ仕事のやり方では立ち行かない時代がやってきました。

新しい時代への対応１
新しい収入を獲得するために前職では様々なことに挑戦しました。
主に行なったのはデータベースや、アプリケーションの開発です。
クライアントに合わせた専用のツールを開発し運用することが始まりました。
当時の僕は「めんどくさいなー」くらいしか思っていなかったのですが、
今思うと経営陣は必死で会社を守ろうとしていたのだと思います。
開発系の案件は慣れるまではとても大変でした。
開発は専門の会社にお願いするのですが、開発の人とびっくりするくらい話が通じません。（笑）
通じない理由は出版印刷業界の「ジャーゴン」です。
「ノンブル」や「版面」のような我々が当たり前に使っている言葉を彼らは知りません。
なので、その言葉を１つ１つ丁寧に説明する必要がありました。
あと、加えて開発業界の「ジャーゴン」を我々が知らないということも大変でした。
クライアントと開発の間には通訳が必要なのだということを始めて知りました。
そして次にやってきたのが、運用の大変さでした。
DBへのコンテンツ登録、アプリのコンテンツ作成、アプリの機能改修、
極め付けはChromeのアップデートによる不具合とか、
他にも色々あったと思うのですが、愚痴みたいになりそうなのでやめます。
専門知識を持っていない我々が組版の合間にクライアントと開発の間を繋いだり、時には自分たちで直したりするのはとても大変でした。運用には専任の担当者が必要ですね。
そんなこんなを数年やっているうちに、自分たちでも多少の開発っぽいことができるようになってきました。
自分でアイデアを出し、資料を作成し、社内で検討し、クライアントに持って行く。
うまく行ったもの、行かなかったもの、色々ありましたが自分のアイデアが通るのは結構楽しかったです。

新しい時代への対応２
また、組版作業の効率化を上げる必要もありました。
制作費用が減少してきたことに対応するためには制作効率を上げざるを得ません。
学参の組版は一般の書籍と比べてルールが複雑なので、制作にはとにかく時間がかかります。
DTPオペレーターには仕事のできる人とそうでもない人がいて、人によって作り方が違ってたりしていました。
業界的には作り方が違っていても書籍になった時にルール通りに組版されていれば問題無しとされます。
なぜなら版元がデータの中身を確認することはありませんし。
優秀なオペレーターは複雑な指定に対し「技」を使って効率的に組版を行なったりしているのですが、
並みのオペレーターはその「技」が理解できない場合があります。
このような状況の場合、その案件は優秀なオペレーターでしか対応できないこととなります。
並みのオペレーターがデータを触った際にとんでもないミスを起こしてしまう可能性があるからです。
いわゆる「秘伝のタレ」です。
結果、仕事は優秀なオペレーターに集中します。優秀なオペレーターは人数が少ないので仕事は遅れます。
ダメですね。
古くから続いてきたこのような状況を改善しないと作業効率は上がりません。
会社的な理想は社内のどのオペレーターが組版してもクオリティが均一で迅速に組版が行えることです。
まず始めたのはマニュアル化です。超当たり前のことですね。しかし、当時は全然やってませんでした。
まず、社内の基本マニュアルをガッツリ時間をかけて作りました。
案件ごとの独自ルールはその都度マニュアルを作成し、共通の場所に格納するようにしました。
オペレーターのミスはゼロにはなりませんが、減らすことができたのではないかと思います。（多分ですが）

新しい時代への対応３
次に組版にスクリプトを取り入れはじめました。
書籍作成にスクリプトはとても有効でした。
まず、同じ作業を何回も繰り返す必要が無くなります。
そして、誰が作業しても同じクオリティーの組版が上がります。
スクリプトを有効に活用し運用にとりいれることで、それまで跋扈していた「繁忙期を超えなきゃ一人前になれん」とか、「残業できる時間と社内評価が比例する」みたいな、根性論めいた言説を一気に払拭できたような気がしました。
このタイプの言説で人は育たないです。むしろ逆効果なのに特定の方々は仰います。
また、アイデア次第では、組版を自動化したり、組版したデータから必要なデータを抽出し、
他のコンテンツ用に二次利用を行うなど様々な使い方があります。
クライアントに対しても組版関連で新しい提案を行うことも可能となりました。
スクリプトは覚えるのが大変ですが、覚えておいて損は無かったと思いました。今だに勉強中です。

スクリプト運用の今後について
組版会社でスクリプトを運用するにはスクリプトを書ける人を育てる事が重要となります。
ただ、これがとても難しいことだと感じます。
ある程度の基本を覚えればスクリプトで「付け焼き刃」的な処理を書くことは容易でしょう。
ただ、書いていて思うのは、スクリプトは設計がとても大事だということです。
アプリについて、組版について、使う人について、出来上がった組版のその後について（修正とか変更とか）など、考えなければならない事が沢山あります。
それらを踏まえて書くとなると、様々なことを理解し、まとめ上げる能力が必要となります。
皆んながそれをできるか？というと、そうではないような気がします。
組版にオペレーターの性格が出るように、スクリプトにも書いた人の性格が出るということが、書いてみて解りました。
組版用スクリプトを書ける人間を育成するにはどうすればいいのかは今後の課題です。

今後の業界について思うこと
出版社の方に話を聞くと、現在の教育の現場はとても大変だと仰います。
教師の負担は年々増加している一方、生徒と保護者への手厚いケアも求められているそうです。
教室に対して教師は１人しかいません、そして１人の教師が出来ることには限界があると思います。
日々の煩雑な業務をシステムに置き換えていければ、彼らが生徒と向き合う時間を増やすことになると思います。
業界では教師が抱えるの業務のソリューションが求められているようです。
僕のような教材制作の末端の人間に何ができるのか？といわれれば大したことはできませんが、何か組版で手助けが出来ればいいなとは思っています。

会社員としての業務
この業界は離職率が高めだと思います。実感として。
有能な先輩はどんどん退職していき、入社して数年後には僕はベテランになっていました。
ベテランになると伸し掛かる案件が増え、管理っぽいことをすることになります。
クライアントから僕に展開された案件は一度自分で確認し、社内の人間に展開し、上がりを確認してクライアントに納めます。これが通常の流れでしょうか。
新しい案件であれば、調査を行い、費用やスケジュールの調整を行い、GOであれば自分で見本組を作成し、必要とあらばマニュアルを用意し、場合によってはスクリプトやSwithの自動処理なんかを作成し、社内に展開します。
社内の人間は１人１人性格が違います。まじめな人、ずるい人、クズい人、逃げる人、口だけの人、様々です。
彼らの性格を考え、表情を見て、彼らに合ったやり方で仕事を展開することが必要です。
初めは全然できなかったのですが、いつのまにかできるようになっていました。
今思うと、こういうことを教えてくれる先輩が欲しかったです。
僕の場合トライ＆エラーでやるしか方法がありませんでした。
なので嫌な思いをした方もいたと思います。
当時の未熟でバカだった僕を許してほしいです。（みんなごめんね。）
また、クライアントに専門的な説明が必要な場合は、調査を行い、説明資料や見積もりを用意し、クライアントの元に行って説明します。そして、費用やスケジュールを決めてスタートとなります。
僕の基本的な業務はだいたいこんな感じでした。
社員の中では残業がかなり多い方だと思います。

なぜ退職したか１
ある時、開発関係の営業担当が退職することとなりました。
となると、誰かが業務の引き継ぎをしなければなりません。
そこで僕に白羽の矢が立ちました。
僕は断りました。そして人員の補充を提案しました。
会社は引き継ぎ担当を僕に決定しました。（なぜ？）
押し付けられてしましました。
この時点でどうかしているとは思うのですが、僕は引き継ぐことにしました。（僕もどうかしてますね）
まともに考えて１人ではこなすことができません、社内の協力が必要不可欠でした。
なので、社内の人間に協力を仰いだのですが、１人も協力してくれませんでした。
僕が引き継いだ業務は開発関連の営業です。クライアントや開発会社との窓口と、アプリの運用や管理業務です。
DTPオペレーターはクライアント対応を極端に嫌う人が多いのは解ってはいたのですが、１人も協力者がいないとは思いませんでした。
業務の移管をお願いした数人からは、長文のお断りのメールをいただき、大変ショックを受けました。
また、営業にも協力を仰ぎましたが全員断られました。
組版の営業は開発関係の案件へのアレルギーを持っています。理解できないことには拒絶反応が出るようです。
それはある程度理解しているつもりでしたが、部分的な業務の移管ですら断られてしましました。
というわけで、前からも後ろからも押し切られる形で業務を引き継ぐことになりました。

なぜ退職したか２
やばいことになったと思いながらも、しょうがないので引き継いだ仕事を行いました。（バカですか？俺は）
午前中はクライアントとのやりとり、夜は遅れた作業を行うため残業、結局間に合わなくて休日出勤。
出来るだけ頑張ってはみたのですが、結果、すぐダメになりました。
何もかも立ち行かきません。あたりまえですね。
僕はもう一度、会社に人員の補充をお願いしました。
会社としてもクライアントに迷惑をかけるわけにはいきません。
会社も僕の要望を少しだけ飲んでくれました。
ここで、僕の業務の中で負担となっていたいくつかをパージすることができました。
まず、特定の業務のみを行う専属の「課」みたいなものを立ち上げました。担当は数人の外注さんです。
費用が絡む話だったので立ち上げの際の調整がすごく大変だったのですが、
これで楽になると思い、死ぬ気で頑張りました。
また、いくつかあるクライアント対応の１社分を社内の人間に移管することができました。
（そもそも、僕１人で何社やってんだよ）
この移管にも結構時間がかかりました。でもなんとか頑張りました、そして頑張ってもらいました。
移管を了承してくれた担当にはとても感謝しています。

なぜ退職したか３
この段階である程度の仕事のパージを行うことはできました。
僕の業務は少し楽にはなりました。
ただ、元々僕が担当していた仕事と、追加で引き継いだ仕事の両立をすることは不可能でした。
この時点で僕は激務と残業と休日出勤で精神的にまいっていたのだと思います。
僕は再度、会社に人員の補充をお願いしました。
断られました。
ここで心が折れました。
僕は退職させて欲しいと会社に申し出ました。

退職を申し出た後の話
退職を申し出た後、会社からは止められました。
そして、相談に乗ると言ってくれる人が数人現れました。
相談に乗ってくれる人は決まって「あいつを使え、こいつを使え」と言いました。
相談には乗ってくれましたが、助けてはくれませんでした。
他にも、「給料を多少上げるよ」とか、「もうすぐ働き方改革だから」とか、あれこれ言われたのですが、退職を取り下げる理由にはなりませんでした。
そんなこんなで僕は退職することとなりました。

退職決定後も大変でした
退職が決まってから退職まで数ヶ月あったのですが、その残された期間は死ぬほど大変でした。
まず、遅れていた積み残しの案件です。そして、業務の引き継ぎです。
ちなみに引き継ぎ担当は社内で決めた数人に決定しました。みんな嫌々でしたね。
積み残しの案件はいくつか有ったのですが急いでいたのは新規のDB開発案件でした。
この案件は普通に仕事をしていたらスケジュール通りに完了していたはずなのですが、手をつけられずにいたため大幅に遅れていました。
クライアントに謝ってリスケをしてもらい、決定したスケジュールを目指し全力で終わらせました。
次に、引き継ぎはですが、まずマニュアルや資料などの大量のドキュメントを用意しました。
膨大な引き継ぎ内容を慣れない新担当に口で説明しても絶対覚えてられないでしょう。
そして、そのドキュメントをもとに担当者と何度も打ち合わせをしました。
ドキュメントは出力したらびっくりする枚数になっていました。
退職するギリギリまでこれらの作業を行なっていました。
そして、僕の会社員生活は終わりました。
最後までバタバタしていました。最後まで逃げ出さなかった僕はエライ！と自分を褒めてあげたいです。

現在の僕
フリーランスになりました。
手続きは東村山の税務署に紙を出して終わりです。簡単でした。
うまくいくかどうかはわかりませんが、一回くらい挑戦してみてもいいかと思い、決断しました。
だめなら会社員に戻るつもりです。
まず最初の仕事は名刺を作りました。
そして、前の職場に持って行きました。
前職は最後は辛くて退職することになりましたが、
長い間、雇用していただいたことをとても感謝しています。
あれこれ書きましたが、前職には足を向けては寝れないとは思っています。
今後の予定としては、以前からやりたかったDTPについての記事を書きたいと思います。
よろしければ読者になっていただければと思います。