2017年12月08日
_ [life] 皆さまからいただいた原稿はこう加工されますというお話
昔からお世話になっているモーリさんから編集とライティングにまつわるアレコレAdvent Calendar 2017に書け、という有形無形のプレッシャーが……昨日のアドベントカレンダーご担当はmktredwellさんでした。
本日は某制作プロダクション会社の編集者が、著者さまや訳者さまからいただいた原稿をどう加工して紙面化しているのかを記してみます。編集者の方々や、執筆・翻訳をして出版社から出版しよう、という方にも参考になれば幸いです。
背景として、私自身は基本的に企画やライティングはせず、クライアントである版元さま（＝出版社。ほぼ技術書系）が企画して著者さま・訳者さまが執筆された原稿を、版元さまとともに編集・校正し、紙面化して確認をいただき、最終的に印刷所にお渡しする、という編集のお仕事をしています（企画やライティングのお仕事のほうが多い同僚もいます）。
また、OSS開発者兼技術書執筆者でもあり、自分の執筆と仕事に欠かせない環境としてRe:VIEWというマークアップドキュメント変換システムの開発保守をずっと続けています（Re:VIEWのオリジナルは青木峰郎さんが作成されました）。このRe:VIEWと商業組版ソフトInDesignやフリーの組版ソフトLaTeXと組み合わせた「自動組版」を使って、紙面化の作業も兼務しています。
よって、最初にエクスキューズしておくと、ここからの内容はあくまでも某制作プロダクション会社の中の私のチームが採用している手順というだけで、弊社ですべての書籍をこうしているとか世間一般にこうである、というわけではないことにご注意ください。
イテレーション、イテレーション、イテレーション
世の中にはMicrosoft Word（以下Word）をはじめ、一太郎、Excel、PowerPoint、LaTeX、HTML、XML、Markdown、Sphinx、Re:VIEW、AsciiDocなど、たくさんのドキュメント形式があります。
著者さまや訳者さまがどのようなファイル形式で書かれるかは、ある程度版元さまから指示があるのが普通ですが、「なんでも書きやすいものでいいですよ」と放任になっていることもあります（実際それを加工しないといけないのは当方なんですけどね……）。
ともあれ、どのようなデータであろうと、最終的に紙（≒印刷所入稿用PDF）にする、というゴールには変わりありません。
原稿→編集・校正→組版（紙面化）→紙面に編集・校正→組版反映（紙面化）→……→印刷所入稿
しかし、現ラムダノートの鹿野さんが「どんな原稿形式でもそれをマスターデータとしてがんばる」といったことを書かれていたかおっしゃっていた気がしますが、もし原稿がせっかくマークアップテキスト形式で書かれているのならば、私もなるべくそれを生かしてできるだけ制作終盤ギリギリまでそれを使っていきたいと常々考えています（Wordや一太郎のようなバイナリデータ原稿の場合はノーチャンスです）。つまり、
原稿→編集・校正→組版（紙面化）→原稿修正→編集・校正→組版（紙面化）→……
のように、元原稿をあたかもソースコードのように捉え、編集・校正でコード修正、組版というコンパイルを経て紙面を生成するのを繰り返す（ここではイテレーションと呼びます）ことをしたいわけです。
実際のところそのようなイテレーション型の作り方ができるかどうかは、妥当な費用・時間、紙面デザイン、版元さまや著者さま・訳者さまの意向、といった要素に依存します。
まず、イテレーションを実現するには、一般的な「DTPオペレータが手作業で原稿を見ながらDTPソフトInDesign上で紙面要素に割り当てていき（手組み）、その後は紙（ゲラ）上で赤入れしたものを目視で反映していく＝InDesign DTPデータが最新データで、原稿ファイルは乖離した遺物」というやり方ではなく、何らかの「自動組版」の仕組みが必要です。そのために、Re:VIEWあるいはXMLとInDesignを組み合わせたり、LaTeXを採用したりといった自動組版を設計し運用しています。しかし、これには紙面デザインやツールを調整する費用・時間のコストがかかります。ともかく初校を早く安く！ という案件の場合には向きません。
また、Re:VIEW+InDesignにせよLaTeXにせよ、自動組版の場合はInDesignの手組みほどのレイアウトの自由度は提供できません（正確には、できなくはないけれども妥当なコストで実現しづらく、イテレーションもやりづらいものになります）。流し込み、ある程度の白スペース許容、紙面の後からの見た目の調整は最小限、といった制約がかかってきます。LaTeXを使った組版であれば完全な無人オペレーションのためいくらでもイテレーションはかけられるのですが、InDesignの自動組版の場合はどうしても人手が介在するので、コスト的に多くても3、4回以内のイテレーションとなるのが普通です。
そしてこれらを踏まえた上で、あとはどれだけこのようなやり方を採用したいかどうかの問題となります。結局著者さま・訳者さまなり、版元編集者さまなりが「原稿ソースで」文章校正を管理したいという欲求がないと、なかなかうまくは運びません。もちろん、そういった要望がなくても、イテレーション作業が妥当と社内で判断したときには、対外的には従来どおりゲラを出しつつ内部ではイテレーションを採用していることもあります（特にLaTeX採用の場合）。なお、初校以降から要素のデザイン調整が全面的に入る、制作終盤に本格的な編集を始める、といった傾向の著者さま・版元さまとは完全に相性が悪い仕組みなので、その場合は当初からこの方法は除外しています。
コウカンサレルモノ—テキストマークアップ形式
前述のとおり、ドキュメント形式は多種多様ですが、いただく原稿は概して次のいずれかの記法のどれかになろうかと思います。順序はおおむね私の業務範囲での案件数に沿っています。
- Markdown（実際はGitHub Flavor）
- Re:VIEW
- Word
- LaTeX
- プレインテキスト＋独自マーク記号
- HTML
- XML（DocBookまたは独自スキーマ）
- AsciiDoc
- Sphinx（reStructuredText）
いずれにせよ、手組みの場合は最終的に社内タグを付けたプレインテキスト、自動組版の場合はXMLまたはLaTeXに帰結する必要があります。社内タグは次のような感じです（Re:VIEWのtopbuilderで吐き出したものがほぼそれです）。
■H1■第4章 InDesignで自動DTP ◆→開始:リード←◆ この章ではいよいよ、IDGXMLドキュメントをレイアウトに割り付け、… ◆→終了:リード←◆ ■H2■4.1 作業方針 前章で作成したXMLドキュメントをInDesignのレイアウトに割り付けるにあたり、… 1 レイアウトテンプレートの△master.indd☆ファイルをInDesignで開き、…
変換の流れについて言葉で説明すると長くなるので、ドキュメント形式ごとにどうしているかを図示しましょう。
（クリックで拡大）
実際には変換したあとに変換漏れ対処や細かなカスタマイズのためのフィルタ（Rubyコードあるいはシェルスクリプト）を通すこともありますが、大きな流れとしてはこのようになっている、とお考えください。
登場しているツールのリンクも示しておきます。
- md2review（Markdown→Re:VIEW）
- sphinxcontrib-reviewbuilder（Sphinx→Re:VIEW）
- REXML（XMLパーサ）
- Nokogiri（XMLパーサ）
- AsciiDoctor（AsciiDoc→XHTML）
- Pandoc（MarkdownやWord docx→プレインテキスト・LaTeXなど）
Markdownは紙面表現には絶望的に機能が不足しているのですが、どうしてもこの形式を保持して自動組版と組み合わせたいという場合は、Re:VIEWタグがところどころに埋め込まれた原稿を作っていくことになります（以下は『サイバーセキュリティプログラミング』（オライリージャパン、2015）より）。
パッケージがインストールされたら、7章で作成する@<hidx>{GitHub}GitHubを使ったトロ
イの木馬をビルドするために使うモジュールをインストールできるか試してみよう。ター
ミナルに次のコマンドを入力する。
```
root@kali:~#: @<ttb>{pip install github3.py}
```
なお、Wordについては当初大いにこの記事に書き連ねたのですが、呪詛の言葉しか並ばずまったくクリスマスにそぐわないため、ばっさり削除しました。1つ申し上げておくと、いくらWordで見た目を綺麗に作っていただいても、（原稿の内容ではなく）Wordドキュメント形式に起因する諸々の問題で信頼性に疑義があるため、図にあるとおりまずプレインテキストにしてから編集します。Wordのスタイルを活用してツールによる初校作成を実装したのは、長大・要素膨大・多数の編集者が関与という条件のあった『できる大事典Excel VBA』（インプレス、2017）ほか数冊のシリーズくらいです。
最近はWord数式の含まれたものについてはPandoc、あるいはdocx2texの変換も試したりしていますが、まだ全幅の信頼を置くには至っていないため、たいていは手でLaTeX数式に置き換えています。
食ったパンの枚数だって数えられる—バージョン管理
手組みにせよ、イテレーションの自動組版にせよ、必ずバージョン管理サービスは利用します。ローカルマシンのストレージほど信用ならないものはないですし、私の勤務体系はだいぶフリーダムなので、オフィスでも自宅でも外出先でもデータに容易にアクセスし、履歴をたどれる必要があります。
著者さま・訳者さま・版元さまが供与されているならGitHub・GitLab・Backlog・GitBucketなど基本的にはどのサービスでもそれを使うようにしています。こちらから提供するときにはGitHubか自前で運用しているSubversionあるいはGitBucketです。
実際のところ、InDesignデータや図版データなどはバイナリで数十MB〜数百MBと大きく、リポジトリを圧迫する上に、そんな生データはDTPの担当者以外にとって無用の長物なため、gitとは相性がよくない傾向です。gitを使うプロジェクトでも、それらのデータのほうはSubversionで管理しています。Subversionは内部的にはディレクトリベースの管理構造なので、1つのリポジトリで編集側・DTP側のデータを完全に分割管理できます。
プログラムソースコードと違って原稿の場合は変更によって「壊れる」ことはなく、むしろ並行作業を長く続けると「競合の発生」と「マージの負担」のコストが大きくなるので、「1章を終えた」という大きな単位ではなく、たとえば「今日はここまでやった」といった小さな単位でコミットしています。GitHubでもブランチを切ってマージして……は省略してmasterに直接入れることもよくありますし、rebaseもほぼ使いません。
人の目、機械の目—編集作業
さて、原稿が揃い、バージョン管理にひとまずいろいろとつっこんで方針の策定ができたら原稿の編集加工作業に入ります。本編から逸れて長くなりそうなので手短かにしますが、おおむね以下のような作業が挙げられます。
- 用字用語の統一（版元さまごとのルールあり）
- 誤字・脱字の訂正
- 読みにくい・意味がわかりづらい箇所の改変あるいは提案
- 見出しレベルや採番の確認（Re:VIEWの場合はおおむね自動任せ）
- 必要に応じて数式箇所のLaTeX記法化
- 使用図版の整理、場合によってはラフ描き
- 引用出典元の確認
- （料金や時間次第ですが）動作検証
章立てや節・項にまたがって全面的に書き直すというタイプの編集者も世に多くいますが、私は文章というのは著者さまが責任を持つべき範囲であると考えます。段落を壊さない範囲での読みやすさ改善は積極的に施しますが、文章をごっそり入れ替えたり作文したりすることはあまりせず、「ここが不足しているのでは」「この説明順序だと変では」という提案をする程度に留めています。いずれにせよ、編集着手前に「どの程度直してよいか」を著者さまに確認することが重要です（「たとえ誤脱字であってもすべからくお伺いを立てるべし」というケースもあります！）。
エディタはDebian GNU/Linux＋Emacs＋SKK＋編集作業専用モードを利用し続けています。モードとしてはjaspace.elをマイナーモードで取り込み、Re:VIEWの場合は自作のreview-mode.el、LaTeXの場合はauctex、それ以外のテキストの場合はhensyu-mode.el（自作）を使います。これらのモードを使う主な目的は、タグのショートカット入力とカラーリング（タグや、全角半角スペース/タブ、多種存在して混同しやすい二重引用符やハイフン/マイナスの記号を見分ける）です。フォントには等幅かつ可読性に優れたVLGothicを愛用しています。
（クリックで拡大）
単文節変換の日本語入力機構であるSKKを使っているのは1993年以来常用して慣れているからというのもありますし、版元さまごとに送り仮名や漢字の開きなどが異なるルールの下、常時3〜4冊の編集を抱える中で一般的な連文節変換型の日本語入力ではルールの違いに耐え得ないことに依ります。たとえば午前には「組込み」「例えば」を使うA社案件、午後には「組み込み」「たとえば」を使うB社案件、という具合です。
表記統一にはEmacs上でgrepやquery-replaceを多用するのは当然として、ある程度原稿整理の済んだところで日本語の表記揺れ発見に優れたJustRight!（ジャストシステム社、Windows版）での検査も行います。最近はRedPenに同種の機能が実装されつつあるので楽しみに見ています。
誤脱字についてはいちおうJustRight!、RedPen、あるいはtextlintなどの検査ツールはありますが、技術書に対してはキーワードなどに対するfalse alarmが多く、私はあまり使用していません。目視とありがちミスに対するgrep（1つ誤字を発見したら全体をgrepするなど）を使うことがほとんどです。
「読みにくさ」というのは極めて主観的な事柄なものの、私は文のリズムからそれを判断します。読点はブレス、句点はふーと息をつき、段落の終わりはそこで一旦休んで次の段落に備えるところです。リズムが崩れている、テンポが悪いと感じた箇所にはたいてい、誤脱字があったり、文が日本語としてそもそも破綻していたり、段落内の文が長すぎたり短すぎたり、他者の文章の借用であったりが潜んでいます。共著・共訳の場合は全体のタームやトーンをなるべく整える必要もあります。
「意味のわかりづらさ」もまた主観的判断ですが、本には想定読者というものを必ず立てるわけで、一度自分の持つ知識をリセットして、そのペルソナを被って読んでみます。すると、読者にとって「唐突にわけのわからない内容が出てきた」、あるいは「当たり前のことを長々と書くよりこっちを説明してほしい」といったことが見えてきます（とはいえ、自身の知識レベル以上には変身できませんが）。単著の場合は思い込みに過ぎるところはないか、共著の場合は互いで矛盾していたり同じことを繰り返したりしていないかも注意します。
レベル、採番確認は、マークアップシステムを利用するものなら変換結果をおおむね信頼できるのですが、プレインテキストやWordから変換したテキストのように、リテラルで番号が振られたものについては、grepやwcを使って検査するシェルスクリプトを作って確認しています。1行内で複数回登場するパターンへのチェックなど、より重厚な確認が必要な場合はRubyで書くこともあります。
#!/bin/sh # check.sh: 見出しを一覧し、図・表・リストの一覧とそれぞれの総数をカウントする例 # （番号と総数がずれていたら途中が抜けている可能性がある） egrep "■H" $* echo egrep "^図[1-9]" $* egrep "^図[1-9]" $* | wc -l echo egrep "^表[1-9]" $* egrep "^表[1-9]" $* | wc -l echo egrep "^リスト[1-9]" $* egrep "^リスト[1-9]" $* | wc -l
図版については書くとまた長くなるので割愛します。なお、「キャプチャに矢印や囲みを入れた結果の画像しかない」という原稿ですと、
◆→著者様:お手数ですが加工前の原図をご支給ください -編集者←◆
というコメントを初校で目にすることになるでしょう。
初校作成までにおおむね2〜3回程度見直した上で、組版に進みます。
組版周りについても、とても長くなるので割愛します（自動組版の詳細は『Re:VIEW+InDesign制作技法』電子版をご参照ください）。組んだPDFが正しくできているかを照合する（内校）のも編集の仕事の1つですが、本来この時点で文章はすでにほぼ完成している「はず」なので、紙面要素が正しく適用されているか、作図に間違いがないかといった箇所を重点的に確認します。
そうしてできあがったものがついに著者さま・訳者さま、版元さまに届き、晴れて校正を受けるときがやってきます。マークアップ原稿によるイテレーションを採用しているなら文字校正は直接元原稿の修正を、そうでなく手組みならゲラなりPDFなりに赤入れを、進めていくことになるでしょう。
まとめに代えて
いろいろと書き連ねてはみましたが、どのような原稿であろうとも、紙面化は可能です。ただし、標準的なテキストマークアップ形式で書いていただき、版元さまを通じてご要望を出していただければ、原稿をソースとしたイテレーションを導入できる見込みは高いです。特にRe:VIEW形式で書いていただけるといろいろと捗るので、ぜひ検討してみてください！ ご質問にはTwitter @kmuto でお答えできることもあります。
以上、12月8日、こんな感じで私はいただいた原稿を編集加工して紙面化しています、というお話でした。良い週末を。明日のご担当は51_arayaさんです。
編集とライティングにまつわるアレコレAdvent Calendar 2017
