本稿は、過去にわたしがWeb上で発表した、編集の仕事の紹介記事を再編集したものです。

Copyright Alice Rimon, 2020-2022

1 ITを活用した本作り

編集者にとって、印刷所から出てくる青校¹を戻すことが、その本の編集作業の終わりを意味します。2021年のある時、とりあえず青校を戻したところで、最近の仕事のやり方を振り返ってみることにしました。

1.1 出版分野のDX状況

出版にいたる複雑な工程は、専門的であるがゆえに、むしろ特化した電子化が進んでいる領域です。

著者や翻訳はクラウドプラットフォーム上で脱稿し、編集はリビジョン管理システムでレビューし、制作はTeXやAdobeCS上で完版させ、印刷所はCTS²で刷ります。また、それら全体を統合する出版プラットフォームのようなシステムもあります。

電子化が進んだ本の編集進行は、リモートワークとの相性も良く、今回の新型コロナ渦中の進行では、1度も人と会わずに、宅配便を2回使っただけで、青校まで戻せました。その進行を支えている環境をまとめます。

• エディタ、メール、チャット、クラウドストレージなど汎用的なテキストコミュニケーションツール。
• GitやSVNのようなリビジョン管理システム。
• Re:VIEWという出版プラットフォーム、または記法。
• 内部的にTeXを使った組版エンジン。またはInDesignなどのDTP制作システム。
• python, ruby, pandoc, markdown, pdf, sed, perl, jenkinsなど、テキスト処理に強い処理系や形式。
• 図版処理のためのillustratorとphotoshop。
• ハードウェアとしてプリンタとドキュメントスキャナ。

というわけで、青校を戻してテンションが高まっているうちに、わたしが実践している電子化された編集ワークフローを、紹介したいと思います。

　　青校はこんな感じで出てくる。最近は「白焼きプルーフ」と呼ぶそうだ

2 電子化された編集作業の実践

著者や翻訳者から原稿を受け取り、編集作業を行い、印刷所に印刷入稿し、青校を戻すところまでが、編集者の実務となる仕事です。最近は、この作業の大部分が電子化されています。今ふうに言うなら、DX化されています。

その実践を解説していきます。

2.1 マークアップによる原稿整理

あなたが小学生であった経験があるなら、国語の授業で原稿用紙の書き方を学んだと思います。縦書きなら、最右行の真ん中にタイトルを書き、その次の行の下には名前を、箇条書きには・（ナカグロ）を、本文は1文字字下げして書き始めます。

もしその原稿を活字にして文集として印刷するなら、活版所の受付がそれぞれの箇所に、［タイトル］、［著者］、［箇条書き］、［字下げ］などと赤字で指示を入れ、植字工のジョバンニ³に渡します。

2.1.1 原稿整理とは何を整理するのか？

赤字で指定した小学生の原稿の例を挙げます。

　　伝統的な原稿用紙の使い方

原稿整理とは、伝統的には、編集が赤字であれこれ指定する作業のことです。赤字を入れた指定済み原稿を印刷所に持ち込むと、そこから先は、印刷所が原稿と赤字という情報に切り分けてから、各工程の印刷作業が進んでいたのです。

• 原稿の意味としての内容＝テキスト
• 赤字にしたがい、その原稿を植字工が拾って組版する作業＝デザイン

なんというすばらしい分業体制なのでしょう。Webコンテンツ作成の基本としてもよく言われるように、コンテンツ（html）とデザイン（CSS）の分離は、印刷機が開発された600年前から、すでに存在していたことになります。

ここで重要なのは、原稿本文（テキスト）に対して、それ以外の指示や指定（デザイン）を、すべて赤字で書き込んでいることです。

つまり、原稿整理とは、

• テキストという意味の本質を分離抽出してから、そのデザイン表現については、別途、指定によるメタ情報として指し示す作業。

と、まとめることができます。

2.1.2 原稿整理を電子化するには？

原稿とその扱い方法を切り分けて処理することを、情報処理的には、「テキストを構造化する」とか、「メタタグで修飾（マークアップ）する」と呼んでいます。

• 本文＝テキストのこと
• 赤字による指定＝マークアップのこと

では、電子化された編集作業では、具体的に何をどうするのでしょう。

2.1.3 原稿にマークアップ（メタタグ）を付けてみる

電子化された原稿整理の作業を見てみます。

編集者は原稿を受け取ったら、ひとまずプレーンテキスト形式に変換してからエディタで開き、原稿を眺めてみます。そして、タイトルらしいところ、著者と思われるところ、太字にしたいところには、それぞれ、

• % みんなといっしょ
• ＜author＞愛だ誠＜/author＞
• いつも**みんなといっしょ！**と参加してしまいます

といった具合に、印（しるし）をつけていきます。印の書き方（記法）は、今は気にしないでください。

それがつまり、マークアップを使った、電子化された原稿整理の具体例です。さきほどの原稿を例にすると、エディタを使って次のようなテキストファイルを作成します。

%みんなといっしょ

<div style="text-align: right;">
愛だ誠
</div>

ぼくは、みんなといっしょに悪いことをするのが好きです。
そのとき、

- SAMEという同調圧力や
- WITHのようなポリコレ感

を持ちますが、気が小さいのでいつも
**みんなといっしょ！**と参加してしまいます。

2.1.4 マークアップされた原稿を処理すると……

上の例では、＜div＞～＜/div＞のような突然ガチなhtml記法が登場しますが、これも今は気にしないでください⁴。その結果、

上のテキストを処理すると、次のようなhtmlドキュメントが生成されました。

　　みんなといっしょ

つまり、テキストにマークアップする、というアイデアによって、今まで赤ペンでやっていたことを電子化することができるのです。

プログラムコードを書くように、一定のルール（記法）でテキストをマークアップしておけば、あとは機械まかせで何とかなるだろうと考えて、適当にマークを付ければよいのです。

マークアップは自分で定義してもよい

マークアップの記法は何百種類も開発されていますが、自分で定義すれば、それが自分の記法になります。

たとえば、★~☆で囲んだテキストは、自分で太字にするつもりでさえあれば良いのです。実際にどうするかは、あとで考えます。

上の例での記法は、markdownと呼ばれる記法です⁵。

マークアップのしかたに一定の秩序や法則があれば、自分が定義したものをマークアップ言語と呼んでかまいません。

htmlもxmlもTeXもmarkdownもはてなの記法も、テキストを修飾している印は、すべてマークアップ言語です。そして編集者が原稿を整理することの本質とは、テキストをマークアップして構造化することにほかなりません。

2.1.5 テキスト以外の原稿

多くの本では、情報の大部分をテキストが占めます。画像などグラフィック要素はどう扱えばよいのでしょうか。それらは図版原稿として別途整理し、DTPオペレータが画像を調整し、原稿中には、

![伝統的な原稿用紙の使い方](images_mkbook01/20200929184551.jpg)

　　上記で紹介した小学生の作文を画像データとして取り込みたい場合

などとマークアップしておきます。

編集者ができる原稿整理は、テキスト原稿のマークアップまでです。画像データの処理は専門外です。

通常は、デザイナーやDTPオペレーターが作業します。この分野は、編集としての方針を示すだけにして、細部はエディトリアルデザイナーのような肩書を持つ、デザイン領域の専門家にまかせましょう。

2.2 なぜエディタでテキストを扱うべきなのか

エディタには、テキスト文字例を挿入、削除、コピペ、検索、置換をする機能しかありません。Wordのように文書を書式として整えたり、図を取り込んだり、画面でプレビューした通りに印刷する機能もないです。

そのような単純なツールを使って、なぜテキスト処理をするのかについてを、ちゃんと説明すると長くなるので、手短かに圧縮して説明します。

• 意味の本質は、言語化された文字列（テキスト）にある。それ以上でも、それ以下でもない。人の知的活動とは、つまりはテキストで表現できる世界の中でのテキストの交換である。
• 文書やフォント、活字や書道などの書とは、テキストを異なる次元で視覚化したもの。文字の形や大きさ、並べ方や印刷上の装飾といったデザイン要素は、テキストの本質とは関係がない。
• テキストエディタは、テキストを操るためだけに特化したソフト。テキストを依り代にして、効率よく意味の交換を行えるよう設計されている。Wordや一太郎のように、文書として書を視覚化するためのツールとは、出発点も目的も異なっている。

ちょっと理屈くさいので、平易に言い換えてみます。

人はテキストによって、考え、行動し、コミュニケーションしているので、
その活動のために、読み書きはしっかり身に着けよう。

そのための道具として、昔は紙とペンが使われていたが、
今はPCという便利な環境があるので、エディタを使ってテキストで読み書きしよう。

というのがエディタでテキストを処理すべき理由です。

3 Markdownによるマークアップ編

前回、「原稿はテキストで書こう」、「テキストの構造は、マークアップ言語で印をつけておこう」、そうすると、内容とデザインを分けられるので、その後の工程が楽だ。と書きました。

3.1 四の五の言わずにマークアップしろ

今日はその実践です。

はじめてのMarkdown―軽量マークアップ言語の記法と使い方

3.1.1 簡単に習得できるマークアップ言語を使おう

原稿を、ただ書きなぐるなら、Markdownという軽量マークアップ言語が最適です。ここでの軽量とは、タグをキー入力する手間が少ないという意味です。誰だって、見出しを目だたせたいためだけに、

<font size="5" color="#0000ff">
悪目立ちしてるよ。
</font>

なんてgdgd書きたくないでしょう。

ホームページ作成スキルがあれば、

<h5>
htmlの5番目に大きな見出し
</h5>

と書いて、色指定はCSSで定義しようと思うはずです。

さらに手数を減らして、

# はじめに
本書は、横着して本を編集するために書かれた。美点は3つ。
1. 思いを言語化できるのが人類の可能性だ。テキストで語ろう。
1. いいたいことの意味と、それを表現する方法を分けて扱うとカッコいい。
1. wordが改善されるよりも、自分を変えたほうが早い。

みたいな記法でも、最低限の文章の構造が表現できるんじゃないか？ と、発見してしまうかもしれません。

3.1.2 Markdownは最もシンプルなマークアップ言語

そのような最も軽いマークアップ言語の代表が、Markdownです。なんだかGNU ⁶みたいな名前ですね。

実際、上のMarkdown風記法のテキストファイルを処理すると、100ms程度で、次のようなhtmlに展開してくれます。

はじめに

　本書は、横着して本を編集するために書かれた。美点は3つ。

　1. 思いを言語化できるのが人類の可能性だ。テキストで語ろう。
　2. いいたいことの意味と、それを表現する方法を分けて扱うとカッコいい。
　3. wordが改善されるよりも、自分を変えたほうが早い。

3.1.3 地味に便利を感じてみる

ここで、箇条書きの数字が付け直されていることに注目してください。

原稿の時点では、「数字付きの箇条書き」という抽象的な印だったタグが、出力されたhtmlでは、「順位のある箇条書き」という具象として表現されています。

これは、Markdown記法→htmlに変換するときに、pandocというツールを使って、「1. で始まる箇条書きは、上から順に番号をつけ直す」処理が実行されたからです。

地味ではありますが、手堅くテキストを構造化するメリットが活かされています。

3.1.4 Markdownを始めるには

テキストをMarkdown記法でマークアップしておくと、そのテキストは、Markdown対応のブラウザやメーラー、WYSIWIGエディタ、ブログ系ツールなどで、視覚的に見ることができます。

また、ツールを使えば、.html、.pdf、.word、ePub形式のファイルに変換することもできます。

Markdown記法の詳細は、ひとまず細かい話である上、習得に必要な時間は30分程度から可能です。あとは次のサイトなどを見て、会得してください。

Markdownとは―日本語Markdownユーザー会

3.1.5 しかし、Markdownの限界は低い

Markdownは、おそらく世界でもっともシンプルなマークアップ言語です。その分、表現力の幅は狭く、使いにくい部分もあります。

• 見出しや箇条書きや太字や等幅や表組くらいは修飾できるが、著者やタイトル、目次や索引のような、本（冊子体）に固有のメタ情報になっていると、機能や記法が足りない。
• この種のオープンソース文化にありがちな、方言がある。GitHubに投稿する原稿と、Qiitaに投稿する原稿では、記法を変える必要がある。

とはいっても、シンプルなので、原稿を書くときの思考をじゃまされません。また、文芸的な文章と比較したとき、より複雑なテキスト構造を持つ技術文書であっても、文の構造を表現するのに足りる、必要十分な記法が用意されています。エンジニアなら、ドキュメントを書くときの第一選択肢はMarkdownです。

わたしも、書き起こし原稿を書くときや、Webで社内マニュアルを制作する場合はMarkdownです。ブログのはてなもMarkdown記法で書けるんだった！⁷

3.1.6 Markdownをhtmlやdocxに展開させる

Markdownは記法（原稿の書き方）に過ぎないので、その構造をWebやpdfや冊子体（本）に展開するには、別途、構造を.htmlなどで視覚化して表現するための処理が必要になります。

使いやすいのは、pandocというテキスト変換フィルタです。

［ある記法のテキスト］→［別の記法のテキスト］に、コマンド1行で変換してくれます。

次のLinuxコマンドは、上記のテキスト原稿ouchaku.mdを、ouchaku.htmlに変換する場合の、コマンド例です⁸。

$ pandoc -s ouchaku.md -o ouchaku.html

3.1.7 pandocというツールが凄すぎる

pandocには、単に変換フィルタと呼ぶのが失礼だと思えるほどの、すさまじい機能が実装されています。まず、前述の例で、箇条書きの数字を付け直す処理をしたのはpandocです。

しかし、そんな地味な例を飛び越えて、pandocは、TeXの組版エンジンを通じてpdfを生成するとか、プロプライエタリな形式である.docxを生成できたりします。フィルタというよりも、ドキュメントのビルド環境と呼んだほうがふさわしいです。

pandocガイド

3.1.8 MarkdownでWord文書を書く

次に、markdownで書いた原稿を、pandocによるコマンド一発でwordの.docx形式に変換してみる例を挙げます。

2019年12月11日
総務部　有栖 りもん

表題の件、過日の新人研修の受講内容を以下の通り報告いたします。

## 研修の目的および目標
- 目的：新入社員の基本も身につける。
- 目標：当社の企業理念を理解し、社会人としてのマナーと実務で必要な
PCスキル習得する。

## 研修を通じた自己評価
1. **良かった点** 苦手としていたPCスキルについて、受講したことを習得した。
1. **悪かった点** ビジネスマナーテストは満点だったので、
知識面での習得ができた。

しかし名刺交換の実技において、相手の名前の復唱もれを指摘された。

行動計画

社会人としてのマナーについて今までばくせんとしていたが、
実務として触れることができた。
指摘事項の名刺交換時の名前の復唱もれは、着任後フォローしていただく。
今月中には正しい対応を身に付けたい。PCスキルについて、OJTを通じ、
来月中にはOfficeの使用を実務上問題ないレベルにまで身に付ける。
自身の日々の業務が当社の理念に繋がっている事を意識し、
不明点は都度先輩、上司に積極的に聴く。

以上

次の文書は、上記のテキストから、pandocを使って生成した.docx形式の文書です。

　　Wordのファイルを自動生成

この程度の構造であっても、マウスで個別のレイアウトを指定して、ちまちまやるよりは、あらかじめマークアップで全体を定義しておいたほうが楽だ、と感じる人がいるかもしれません。

4 Re:VIEW編

原稿へのマークアップは、TeX⁹のように精密にやろうとすればきりがないし、xmlのように抽象度を上げすぎると、もはや自分が書の海の中で、何に対して戦っているのかさえわからなくなります。

4.1 DTP担当の性格

一方、Markdownで原稿整理したファイルを、そのまま制作担当にDTP入稿するのは、編集のプロとしては、虫が良すぎる話です。その程度の仕事を渡されたって、DTPオペレータからは、「なんですかこれ。原稿ですか？ 指定ですか？ 何語で組めばいいんスか？」みたいなメッセージが返ってくるだけでしょう。

プロ／プロ間の暗黙の了解というのは、けっこう容赦がありません。

どうしたら、DTP担当の怒りを買わないところまで、原稿を整理すれば良いのでしょうか？

4.2 DTP入稿の要件水準

DTP担当とは、あなたが整理した原稿を、初校に組版してくれる人のことです。一般に、DTP担当が作業に着手してくれるDTP入稿原稿には、次のような暗黙の了解があります。

• 一貫したプレーンテキスト、文字コード、改行コード。
• 完全に整合性の取れたタグの付いたマークアップ。マークアップ言語はxml、LaTeX、後述のRe:view等である。WordやExcelであってはならない。
• 書籍を構成する本文以外の指定。図表番号や見出し番号のつけ方、目次、索引、小組、柱、ノンブル、アイキャッチ、ツメ、裁ち落としなど多数ある。
• 万一、数式が含まれる場合は、TeX記法などのエレガントな記法。もしくは著者自身が作成したベクター画像形式¹⁰の数式イメージ。
• 図版などベクター画像形式のイメージ原稿と、イメージへのレイアウト指定、図版ファイルとの合番がわかる一覧。
• 別途、デザイナーさんなどが作成した版面（はんづら）設計書。

これらの条件を満たしたDTP原稿の入稿先は、かなり昔であれば、活版所になります。DTP作業とは、入稿された原稿を見ながら金属活字を1つづつ拾い、文選箱に組んでいった植字工の仕事に相当します。

一般に職人気質というのは、前の人の仕事が悪いとへそを曲げ、仕事を引き受けてくれないものです。そこに気をつけながら、編集はどのようなマークアップ状態で、次の工程であるDTP担当に原稿を渡したらよいのでしょうか。

4.3 本の定義に必要なマークアップ

Markdownに足りないのは、書誌情報など、本（冊子体）を構成する要素を十分に定義できないことです。

4.3.1 誰がLaTeXのコードを書くのか？

そこで、本の形態を想定したタグが豊富に用意されているLaTeX¹¹のjbookstyle等を使って、本をDTP制作すればいいんじゃないか？ と理系の人は思うかもしれません。

それは筋の良い考え方です。

LaTex2ε美文書作成入門

で、誰が次のような、これでも最小限のLaTeXコードで、原稿整理に取りかかれるのでしょうか。

 \begin{document}
ここから本の原稿の本文が始まる。
...
今回の832頁の本文（約60万文字）＋LaTeXコード（約15万字）入る
...
\end{document}

本文60万字に対して、LaTeXコードが15万字って、普通に着手する手前の段階で挫折するでしょこれ。

確かに、LaTeXのマークアップ記法は、始まりと終わりの宣言を見ただけでも、明確でエラーを起こす余地がなく、美しいことがわかります。しかしプログラムコードのように荘厳すぎて、Markdownのような気易さがありません。

でも、Markdownでは物足りない。

そこで、本の構成要素くらいはすべてを反映できる、LaTeXとMarkdownの中間くらいの粗度のマークアップ言語はないでしょうか？ それが、Re:VIEWです。

Re:VIEWの解説本

4.4 本の原稿ならRe:VIEW入稿がベスト

Re:VIEWは、正確には、Kenshi Muto氏が開発したオープンソースの書籍制作支援環境のことです。Re:VIEWの全容の説明と、詳細は、GitHubで公開されています。

Re:VIEW開発者のページ

Re:VIEWの、マークアップ記法の部分にだけ着目すると、次に仕様があります。

Re:VIEWの仕様

4.4.1 Re:VIEWをTeXやInDesignにつなげば商業出版物を制作できる

Re:VIEWでマークアップした原稿を、次のDTP工程に引き継ぐと、DTP担当はTeXやInDesign¹²を使って、印刷所入稿までをアレコレ制作進行してくれます。

ひとまず、原稿をRe:VIEWタグでマークアップしてDTP担当に渡せば、次の段階としては、サンプルのようなpdf形式トンボ付の初校ゲラを、手元でプリントアウトできます。

★後送（初校サンプル）公開できるものがあれば

ここまでの実践を振り返ってみると、編集は一度もリアルな人や紙に触れることなく編集作業を進め、初校校正紙をゲットできたことがわかります。

4.4.2 わたしの主流のやり方

わたしが本をつくる手法も、ほぼRe:VIEWタグを付ける方法で統一されています。コンピューティング環境もそれに合わせて最適化してあるので、いつでも、どこでも、本を作りつづけることができます¹³。

DTP入稿後のことですが、DTP担当がどの手法で組版するかについては、本の内容によります。

数式が多い本だとTeXを使い、図版が多いときはInDesignを使用する場合が多いです。版元さんの意向によって、DTP作業の工数やコスト、品質や印刷入稿仕様などが検討され、DTP手法が決まります。

4.4.3 技術同人誌にはRe:VIEWファンが多い

商業出版物とは異なりますが、Re:VIEWを使って、技術系同人誌を制作することもできます。技術同人とは、コミケで流通しているような薄い本の、テクノロジー分野における同人誌です。具体的には、次のような冊子体です。

電子レンジのようなもの（仮）を使って重力波を作ろう

技術同人誌は、ISBN¹⁴が付いていて書店流通可能なものもあれば、通常は書店売りされずに、コミケに似た技術書典などのマーケットで流通するものもあります。

これらの本の著者は、技術書を書きたいというパッションは強いものの、そのための具体的なDTP手法を持ち合わせていない場合が多いです。

4.4.4 薄い本なら10分で作成可能

そのような場合、kauplanという方が公開している、Web上で動作するRe:VIEW Staterという技術同人向けの出版プラットフォームが使えます。

kauplanによるRe:VIEWプラットフォーム

あなたがエンジニアなら、Re:VIEW Staterを10分で理解し、30分以内にDTP作業を終わらせて、冊子の印刷入稿データを作成できることでしょう。

その分、表現できる仕様は限定的です¹⁵。しかし、誰でも気軽に出版物を制作できる点においては、いらすとやにも似たオープンソース感が今ふうで、好感度が高いです。

5 原稿をどこまで直すか編

この記事では、「編集はどこまで著作物である元原稿を直していいのか？」といった、微妙な問題を扱います。

5.1 編集者の仕事を整理してみる

編集がやっている仕事というのは、だいたいこんな感じです。

1. 版元さんと話しをつけ、どんな本を出したら何部ぐらい売れて儲かるか算段してから、誰に書いて（翻訳して）もらうか決める。話がまとまったらキックオフミーティングを開く。そこまで意識高くない場合は、なんとなくスケジュールを切り、関係者にメールであいさつする。
2. 著者／翻訳者はひたすら執筆＆翻訳。編集はちらちら原稿を見て、できるだけ下手に出ながら、著者らが鬱にならないような感想を述べる。酷い原稿が上がってきたときは、むしろなんにも言えない¹⁶。
3. 脱稿したら、まずはこれまでに解説したマークアップをして、原稿整理する（構造化する）。そうしておくと、Re:VIEWならブラウザベースのビューアで、本の仕上がりに近い見た目で確認することができる。
   ★後送　ブラウザでも見え方入れられたら。
4. 編集の裁量で、脱稿した原稿を直し、上の3.のとの間でイテレーション（繰り返し）を行う。
5. 編集が自らの仕事を、「原稿内容も、マークアップも、付属する図版などの要素も完璧だ！」と思ったら、DTP担当に原稿一式を渡す。この時点を「DTP入稿」と呼んでマイルストーンにすることがある。
6. DTP作業が進行し、文字原稿は組版され、図版原稿はレイアウトされ、見出しやコラムや脚注などが、版面設計どおりにビシッとした体裁で制作されていく。
7. DTP工程でも初校→再校→三校→念校とイテレーションが行われ、各校正段階で編集は、赤字（修正指定）をフィードバックしていく。編集／DTPともに「これで完璧だ！」と思ったら、それを完版として¹⁷、印刷所入稿する。
8. 印刷所は、さらに、製版に限りなく近い校正紙（青焼き校正）を出してくれる。ここで万一ミスが発見されれば、修正できる最後のチャンスなので修正する。青校を戻せば¹⁸、編集の仕事は完了する。
9. それ以降の工程では、印刷し、製本し、取次に納入され、書店に配本されて読者の手に渡る。

5.2 技術書の文章スタイル

専門書には、「同じことは同じ言葉で表現する。比喩はしない」という鉄則があります。文芸書のように、言い回しを変えて行間に何かを含めたり、暗喩を用いて真の意味を伝えるといったことはしません。

文章に関しては、中学生の作文のように、シンプルに同じ言葉と表現を統一して使い、読者に解釈の余地を含ませないことが、良しとされます。

ぼくは夏休みの工作で, テルミンを製作しました. テルミンとは電子楽器の1つです. 低周波発振回路で得られた信号に対して, ヒトの動作（おもに手）と誘電コイルの間の静電容量の変化によって得られた電位差をもとに変調し, その信号を, 後段の増幅回路によってスピーカから発生させます.

上記の文章は、中学生が書いたとは思えないほど難しく見えますが、国語的には、「今日、ぼくは〇〇をしました」以上の文体は持っていません。それでも技術書の文章として読めるのは、次に挙げる技術書特有の表現のスタイルが守られているからです。

技術書の編集者としては、どうのようにして、こうした文章に整えていけばよいのでしょうか。

5.3 用字用語なら問答無用で直す

というわけで、編集は受け取った原稿に技術書としてふさわしくない表記や用語、用字、記法があったら即、直します。また、次のように、直すことに一般的なコンセンサスが得られている事項も、すべて直します。

• 誤字、脱字。
• 送りの統一。例：行う／行なう→どちらかに統一する。
• カナオンビキ／語尾の統一。クエリー→クエリ、エンジニヤ→エンジニア、コンテナー→コンテナなど。
• 漢字の開く／閉じる。辿る→たどる／ひろがる→拡がる、など適度な漢字／ひらがな比率に。
• 再現性のない文字コード。①、㈱、Ⅲなど環境依存文字は別途指定する。
• 差別語リスクのある表現（障害者→障碍者、「記者ハンドブック」（三省堂）による）。

これらの用字用語統一に関して、編集は本ごとに用字用語統一表を作り、その表を随時改訂しながら、用字用語の統一に臨むものです。わたしが作成した用字用語統一表の例を紹介します。

【用字用語統一】（一部）
　現状　　　　　　　統一
—————————————————–
　一次元／二次元　　1次元／2次元/n次元
　あやめ　　　　　　アヤメ
　当たる　　　　　（ママ）
　後は／後の　　　　あとは／あとの
　後ろ　　　　　　　うしろ
　あらゆる　　　　 （ママ）
　いっしょ　　　　　一緒
　一切　　　　　　　いっさい

【表記統一】
　?、!（文中）　　　　　？、！
　％　　　　　　　　　　%
　：、“、；など役物　　　多用せず半角スペースなどで関係がわかればOK
　「　」　　　　　　　　（「〜」〜）等、外せるところは外す
　(　)半角　　　　　　　　本文内は（　）全角
　［　］全角　　　　　　メニューやボタン名

【句読点、役物】
　〜。）　　　　　　　　　〜）。
　「（〜(〜)）」　　　　　カッコネスト「〜（〜）」くらいに
　「」内直接話法／引用　「〜『〜』〜」
　固有名詞の『 』　　　　「 」に。書名、作品名であっても基本『 』禁止

【並列表現】
　年、月（並列）　　　年／月
　共有・統合　　　　　共有／統合（並列表現）

【数詞関係】
　１〜０（全角）　　　半角に
　一、二、三　　　　　数値なら1, 2, 3に
　一つ／1つ　　　　　 使い分け・言葉なら一つ、数値なら1つ
　…
　二次元　　　　　　　2次元（以下、3次元、n次元）
　二乗　　　　　　　　二乗ママで
　二項定理　　　　　　二項ママ、ほかに二項分類器などあり
　第1四分位数　　　　 ママ
　…
　一年、一ヶ月、一日　　　1年、1ヵ月
　数箇月、数か月、数ヶ月　数ヵ月
　十、百、千、万　　　　　10, 100, 1,000, 万（文体表現ならママ）
　一度、二度　　　　　　　1度、3度（回数）、1度ずつ（×づつ）
　　　　　　　　　　　　　一度に、二度と（文体表現）

この作業では、エディタの機能をフル活用します。インタラクティブに検索し、確認してから置換するのが基本です。

しかし、1,000頁くらいの本を手作業で統一していては、はかがいかないので、一部の確信の持てる統一に関しては、Pythonやperlでフィルタを書いて、バッチで一括置換処理します。

このような作業について、近々に機械学習の成果が応用できるのではないかと期待しています。

5.4 少し迷ってから直す場合

専門用語の使い方について、微妙に違っている気がするとき、調べてみると意味の芯を少し外していることは多々あります。編集としては、「この語はこんな表現でどうでしょうか？」と疑問出しをして著者に戻します。

先端技術の翻訳書の場合は、まだ日本語の定訳が定まっておらず、あて訳のような語を選ばざるを得ないときもあります。そのような場合、厳密な本であれば、訳注として、「xxxxという語は○○という日本語に訳した」と記したり、巻末に対訳表をつけることもあります。

しかし、もっとも困るのは、原稿がへたくそで、似たような冗長な表現が続いたり、「てにをは」がおかしくて文意が通じなかったり、チャラい陳腐な表現が多く閉口してしまう場合です。

そのような場合、わたしはガンガン文章の通りが良くなるように、直して（リライトして）しまいます。しかし、それはそれで大変な手間がかかる上、著者らと対立して剣呑とした雰囲気になることもあります。

そこで最近では、「技術書の作文文体」のような指針を、あらかじめ著者らに示しておいてから、上がってきた原稿が逸脱している場合には、その指針にしたがって、文体や表現に対しても、切り込みながら直すようにしています。

【リライト方針】 （一部）
であるということ　　である（冗長表現へらす）
というふうに　　　　のように（冗長表現へらす）
〜留意のこと。　　　体言止めが命令にならない表現に（ex.留意してください）
～されたし。　　　　期待語が命令にならない表現に（ex.してください）
絶対に～　　　　　　使わない（文体表現）
非常に〜　　　　　　1ページに1つ以下
～ですが、～です。　「～が」の接続は減らす
「あっ」と驚く　　　強調表現の「」トル。直接話法の「」なら残す
　　　　　　　　　　どうしても強調したいときは、初出のみにする
Aについて（Bでも）　追補表現の（）はできるだけ減らす

それでも、著者や翻訳さんによっては、一字一句でも直されるのが嫌な人がいて、最終的に和解できないこともあります。でもそこは、読者の方を向いて、編集が譲ってはいけない部分です。

5.5 最終的に出版者が判断すべきこと

技術書ではあまりない事例ですが、出版物には書いてある内容に差別表現があったり、思想、信条など社会的に偏った主張を繰り返すものがあります。フィクションという設定で、誰なのかわかる範囲の特定の個人をネタにした、人格権を侵害する内容の本もあります¹⁹。

であっても、そのつもりで出版するのであれば、その責は出版者に帰するものなので、表現の自由の範囲のことでしょう²⁰。

5.5.1 ジェンダー表現／盗用の管理

以上の杞憂について、わたしが編集する本においては、それらは厳密に管理されています。

米国のような差別表現にはやたら厳しい国での出版物にも、技術書の中には露骨なジェンダーバイアス／性差別の表現がけっこう見つかります。一般書ではないから気を許しているのかもしれません。

また、あやしい原稿部分をGoogleで検索してみたら、同一の文章が過去に書かれていたこともあります。編集していると、その一文が本当に本人によって書かれたものかどうかは、なんとなくわかるものです。

こうした事案の解決は、編集というよりも出版者（≒出版社）が判断することなので、いち編集者としては、出版者に事象を報告して判断を仰ぎます。

とくに翻訳書の場合は、著作人格権が原著者にあり、その権利は和訳に対しても有効なので、邦書の場合だけ特定の表現を削るとなると²¹、たいへん面倒な許諾が必要になります。

まあこの種のことにはきなきなせずに、平和にいきたいですね。

6 本稿の手法による実際の出版物

最近の事例として、わたしが編集協力した本を挙げてみます。

scikit-learn、Keras、TensorFlowによる実践機械学習 第2版（オライリー・ジャパン）

内容は難解ですが、現在の機械学習に関する先端部分の要素を網羅しており、かつ実践もできる大著です。

機械学習をはじめたばかりで、わけがわからなくても、ひと通り書いてあるとおりに手を動かしていけば、半年後くらいには、自分の専門分野で応用が効くかもしれません。

この本の優秀さは、機械学習のためのライブラリTensorFlow2と、Kerasについての記述が豊富にあることです。この2つの手法は、即、ニューラルネット²²の訓練のための実装に使えます。

本書と、次に挙げる機械学習のための前処理²³の本があれば、とりあえず「ネットでランダムに拾ってきた『いかがでしたか』ブログを、村上春樹風に変換する」とか、「こどもが転んで泣いたらロボットを近づけてあやす」くらいのことが、具体的に実現できそうです。

機械学習のための特徴量エンジニアリング（オライリー・ジャパン）

6.1 組版エンジンにTeXを使用する例

これらの本のDTP工程では、組版エンジンとしてTeXを使用しました。

TEXブック―コンピュータによる組版システム

また編集／DTPプラットフォームとしてRe:VIEWを使い、リビジョニングやビルドにSVN、CIツールにJenkinsを使いました。

DTP工程とは、翻訳→編集→DTP→印刷という工程の中で、編集の次と、印刷の手前に位置するものです²⁴。

内容に数式が多いとき、DTP工程の組版エンジンにTeXを使うことは、理工学書出版では一般的です。また、TeXを使った仕事である点で、現場的には、ある程度の整然とした工程で進捗するのだろうなあ、という期待ができるので、士気が高まります。

6.1.1 TeXによる数式表現

次は、わたしには内容までは理解できない二重シグマの数式です。数式部分をTeXのコードで記述することにより、.pdf, .html, .png等で表現することができます。

変わったメディアとしては、はてなブログでも、次のコードをそのままコピペすることで、本の誌面と同一の表現を表示させることができます。はてなを使っている方は、ぜひ試してみてください。

交差エントロピー損失関数

　　上の式のTeXコーディング例

{J\left( \mathbf{\Theta} \right)} =
{- \frac{1}{m}\sum\limits_{i = 1}^{m}\sum\limits_{k = 1}^{K}y_{k}^{(i)}
\log\left( {\hat{p}}_{k}^{(i)} \right)}

数式をTeXコードで表現すると、それなりに複雑になります。上の数式も、記述するのに5分ほどかかりました。

しかし！ 同じことをWordや他の組版システムで、マウスでちまちま位置合わせなどやりながら組んでいたら、DTPのプロでも1時間はかかります。テキストをマークアップすることの強さが、如実にあらわれている例と言えるでしょう。

7 Adobeシステムからの解放

本屋で売ってる本の99%以上は、DTP作業のためにAdobeのツールを使っています。DTP三種の神器と呼ばれているIllustrator、Photoshop、InDesignを使い²⁵、macの大型モニタ上で制作作業を進めるのが、DTPオペレータのイメージです。

しかしそれは、まったく面白くないし、まったく面白くありません。

7.1 Adobeのサブスクがエグすぎる

DTP分野でのAdobeの優位さと、その寡占をフルに利用したマーケティング戦略が、えげつなさすぎて嫌なのです。これが、MS嫌いというのならAppleがあるし、Appleも嫌いなら、Linuxのようなオープンソース文化という選択肢もあります。

しかし、DTPに関しては、Adobeがベストチョイスなのは間違いないうえに、それで正しいのです。ああ面白くない。では、制作物の残り1%の人は、どうやって本を作っているのでしょうか。

7.2 そこでTeXで出版するという選択

わたしの個人的な実感では、商業出版の制作ツールとしてシェア0.5%以下の中に、TeXという組版システムを中心にして、本を作る人たちがいます。前回、紹介した本もそのようにして作られました。

TeXについて説明すると長くなるので、手短に説明します。

TeXは、ドナルド・E・クヌースという数学者が、活版屋の組版の汚さに閉口して、自分の数学論文を発表するために自作した組版システムです。それが、全世界の理系の論文での清書システムとしてデファクトになり、さらにはマイナーな出版物の制作にも利用されるようになりました。

LaTeX超入門 ゼロからはじめる理系の文書作成術

7.2.1 壮大にしなくてもレポート印刷だけでも使える

今のわたしの職場では、文書中に数式が登場することが多いので、文書（articleやreportレベルのもの）はTeXで書きます。レポート集などの制作のために、最後に印刷所に入稿する必要があれば、TeX→PDFに変換することで、とりあえずは高品位の印刷が可能になるのです。

DTPにおいて、Adobeという囲い込みから解放されたいのであれば、それ以外の選択肢も、ないわけではないのです。

もちろん、本当にそれを実現するのは、いばらの道です。

すべてのツールを、方言やフォークの多いオープンソース文化に求めることになるし、日本語フォントの複雑怪奇な使用権の問題もクリアしなくてはなりません。それ以上に、そもそもテキストをTeX記法で書くこと自体が、「4.3.1 誰がLaTeXのコードを書くのか？」で挙げたとおり、尋常なスタイルではないのです。

7.2.2 中学の数学の先生がTeXで問題を作成している

そのレベルをクリアできるかどうかは、高校の数Iレベルのテストで、70点以上取れる程度が目安です。実際、中学／高校の先生が、数学テストをTeXで作成している話はよく聞きます。自分がテストされる側なら、解答と一緒に、出題の数式のTeXコードを添えておけば、100分の101点以上の点がつくでしょう。わたしが数学教師ならそうします。

めちゃ簡単挫折知らずのLaTeX: 中学・高校数学教材作成用レシピ集

7.2.3 二次方程式の解法が書ければOK

出版物制作のプラットフォームとして、以前Re:VIEWを紹介しましたが、このプラットフォームでは、内部的な組版エンジンとしてTeXを使用することができます。したがって、編集作業でRe:VIEWを使いこなすことができれば、商業出版物の編集者としての仕事はこなせることになります。

TeXに比べると、Re:VIEWを使いこなすための数理力の目安は、中学2年数学程度と、ぐっと低くなります。つまり、次のような二次方程式の解の公式を、自分では導出できないくせに、丸暗記しているから問題が解けるレベルです。

二次方程式の解の公式

　　上のTeXコード

x = \frac{-b\pm\sqrt{b^2-4ac}}{2a}

じっさい、わたしのレベルもその程度です。

7.3 やればできるTeXによる本作り

というわけで、文系の編集者が本を作るとき！ 少し数理的なものの見方ができて、オープンソースなどのIT関係に明かるければ、Adobe抜きで商業クオリティの本をつくることは、無理ではないというのが、わたしの見解です。

プロであっても、DTPに一切お金を使わずに²⁶本を出版できている、このような手法が存在することを、知ってもらえたらうれしい、かな。

8 やってはいけないデザイン編

2020年頃の話ですが、ふだんあまり行かない田舎のローソン店舗に、食べきりサイズの歌舞伎揚を買いに行ったら、なかなか見つかりません。これが「商品が見つからない かつ 中身がわからない」という、悪評デザインのPBブランドなのね。

　　誰がこれをふだん食べてる歌舞伎揚だと認識できるのか？

それでも歌舞伎揚が食べたかったので、意地でも探して買って食べたら、微妙に湿気っています。9月30日の時点で、賞味期限が11月3日と短い気がします。

そこで、これ売れ残りなんじゃないかと思って、次の日、他のローソン店舗に同商品の賞味期限を調べにいきましたよ。

そしたら、12月10日くらいのものがほとんどです。あきらかに、わたしが買った歌舞伎揚は、回転しないまま棚にあった売れ残りです。

コンビニは高回転商売なのに、売れずに不良在庫とかありえない。ローソンは高名なデザイン事務所にPB商品の刷新を依頼したものの、みごとに失敗してますね。

みんながやってはいけないデザインをやりたがる謎

8.1 デザイナーがやりたがることにクギを刺そう

デザインがマーケティングを台無しにしてしまうことはよくあります。編集デザインにおいても同様です。

わたしは、写真の上に文字ノセするのがものすごく嫌い！ 毛抜き合わせで精度が出なくて写真を汚すし、下地写真のコントラストが強いと、境界でノセからヌキに変わるので、連続して読めなくなります。それ文字にも写真にも失礼だろ。

　　毛抜き合わせが必要なデザインの印刷リスク

その他にも、

• IR向け会社案内の表紙が、業務に関係のないイメージ写真であやしく見える²⁷。
• こどもや老人むけの行政案内のチラシ見出しがナール書体²⁸で、やさしさを、はき違えている。
• 見開きの真ん中に人物が配置されていて、頁を開くと寄生獣のように見えて怖い²⁹。
• メールで、どう表示されるのかわからないのに、日付や肩書部分が右揃えになることを望んで無駄なスペースを入れていて、公文書のようにダサい³⁰。
• 印刷物まで本文フォントがゴシック系³¹で醜い、読みずらい、嫌がらせのようだ。

のように、虫酸の走るデザイン制作物はいろいろあります。

編集的には「読者のほうを向いていない」ってことなんだけど、そういうクリエイティブワークでの意識の低さが、結果的にローソンのせんべいを、しけらせている、という事実。

編集はデザインのプロではないのに、出版物のデザインに対する責任は取らされるので、手綱はしっかり握っておきましょう、という話です。

9 印刷所入稿と台割

今日は少し時間を進めて、編集作業の終わりにある印刷所入稿について書いてみます。

9.1 印刷入稿してみよう

印刷所への入稿は、編集にとってもDTP担当にとっても、仕事の完了を意味するマイルストーンです。印刷所に入稿したあとでは、もう原稿に手を入れることはできません³²。

印刷所入稿は、一連の出版フローの境界点であるため、編集／DTP／印刷所ともに緊張します。

早い段階で、入稿に瑕疵があることがわかればよいのですが、後工程になって事故に気付いて、刷りを止めるような事態になると、ラインにサイレンが鳴り響き、現場は蒼白になります³³。

編集／DTPから印刷所入稿するときには、データ材料や指図書など多種類の実体（エンティティ）を渡します。昔は立ち合いましたが、今は電子入稿です。クラウド上のサーバからサーバへ、認証や暗号化を経ながら、印刷所内部のCTPシステムに実体が転送されます。

そこから先は、印刷所内部の現場の仕事になります。

9.2 印刷所の仕事

CTPであっても、印刷所の工程そのものは昔と同じです。上流工程から下流工程に向かって一方的に作業が進んでいき、それぞれの作業では、設備や資材や人手が使われて、印刷物が製造されます。

工程の流れを、上流から下流に向かって、順番に表にします。

※印刷用語が多くてすみません。関心を持った言葉は、調べてみてください。

9.3 台割とは何？ 印刷現場の仕様書だよ

さて、印刷所入稿する材料のうち、いちばん重要なのは完全版下状態にあるPDFデータそのものです。

そして、その次に重要なのが、台割という、本全体を俯瞰できる構造をあらわした表です。実物の例を次に挙げます。

9.3.1 台割の要件を知ろう

本は、印刷の都合から16頁（ページ）の倍数となることが多いです。また最小の頁単位としては、紙には表裏があることから、2頁になります。 その他、本作りにおいては、

• 第1頁を、大扉という表題紙にする
• 最終頁を奥付にする
• 章の手前に原稿がなかったら白頁にする
• 奇数と偶数ページでは、通常、版面の設計が異なり、組み方も違う

といった約束ごとが多くあります。本全体の構造をあらわす台割表があれば、これらのルールが守られているかどうかを確認でき、印刷作業の段取りも明確になるので、現場が混乱しません。

9.4 印刷所に嫌われないツボ

印刷所は、次のようなことをとても嫌がります。

• 最終頁が奇数になっている。
• 総ページ数が16か8の倍数でない。4か2の倍数で台に端数が出るなら、あらかじめ言ってほしい。
• 紙の物理的な頁番号と、ノンブルがかみ合わない。
• 白頁が明確でない（白ページを隠しノンブルにするかどうかも含めて）。

上に挙げたような事柄には、その意味が正確にわからなくても、雰囲気的に、大工や整備士や電子回路や製造業の現場など、モノを作る立場の人から嫌がられそうな、素人くささを感じませんか？

印刷というのは、平面と立体を組み合わせた物理をベースに動いています。その構造を表した台割に関して、発注者のディレクションと、物理構造のつじつまが合っていないと、イラッとしますよね。

実際、印刷所の現場においてはどの担当者も台割表しか見ていないし、台割こそが印刷作業を進める上での絶対的な根拠になっているのです。

おかしな台割は現場を混乱させ、顰蹙を買います。編集がしっかりした台割を作ってあれば、印刷所の営業は安心するし、きっと印刷所の中の職人さんたちもナメずに仕事をしてくれるでしょう。

9.5 台割フォームを公開する

編集は、自分が使いやすく、印刷所にとっても見やすい台割表を、工夫しながらExcel等で作成しているものです。

そこで、わたしが実際に使っているExcelフォームを、次からダウンロードできるようにしました。1024頁まであります。あとは魔改造するなりして、ご自由にお使いください。

ドキュメントシステム：台割フォーマット（Excelダウンロード）

この台割フォームの魅力は、次のとおりです。

• 総頁を16の倍数にしやすいよう記入できるほか、8の倍数になりそうな時でも対応しやすい印が付いている。
• 前付にギリシャ数字を使う等、紙の物理ページとノンブル表記がシフトしてしまった場合も、対応関係がすぐわかる。
• 特定の頁が奇数か偶数であるかや、章のはじまりが右か左のどちらかに来ているかの視認性も高めてある。
• 折りの連続性がわかるので、製本時の乱丁防止につながる。

「この台割表はイイ！」と思ったら、何かわたしが編集した本を買ってください。

10 今ふうの校正作業

DTP入稿後に、最初に編集が受け取るモノが「初校」というやつです。これまで編集者は、初校校正紙に、校正として、手書きで赤ペンで「直し」の指示を逐一入れていました。しかし、今は、その方法はすたれています。

10.1 最近の校正事情

校正といえば、印刷所の校正室に出張校正でカンズメになり、ゲラ刷り（校正紙）に赤ペンを入れながら、「この印刷所は、カツ丼出るのかなあ？」などと思っていたわけですが、それは6世代くらい前の仕事のやり方です。

現在は、電子プラットフォーム上で、コンピュータ支援を受けながら、校正作業を進めていくと考えるのが自然でしょう。

一方、最新のやり方は、仮想的でもあるので、作業の枠組みを意識しながらやらないと、手戻しになったり、校正がざるになったりするものです。昔からよく言われますが、ざるは何枚重ねてもざるです。そんな校正作業に意味はありません。

そこで、「校正必携」や「校正記号の使い方」で解説しているような³⁴、2世代くらい前に主流だったやり方を要約してから、最新の校正手法について解説します。

標準 校正必携

校正記号の使い方

10.2 2世代前の校正作業

2世代前（10年前を想定）の校正作業とは、次のようなものです。

1. DTP作業にInDegsin等を使い、組版後は、プリンタ出力した紙に「初校」や「再校」などのスタンプを押したものを、校正紙として編集に渡す（いわゆる出し）。
2. 編集は、その校正紙（出し）に、手書きで赤ペン³⁵を入れることで校正作業を行い、DTPに戻す（いわゆる戻し）。
3. DTPは赤が入って戻された校正紙を見ながら、赤の指定どおりに、手作業で組版ソフトをオペレーションし、次のリビジョンの校正紙を出す。
4. この出し／戻しを繰り返すごとに、校正紙は初校→再校→3校→念校などとバージョンアップしていき、最終的に印刷所入稿するリビジョン（完版）が完成する。

この手法で初校に赤を入れていくと、かなりの量になります。昔ながらのやり方で、「原稿は初校で直すもの」という意識が、著者や編集に残っていたり、紙に赤ペンで校正しなければ、校正した気にならないからです。

このように、初校が真っ赤になるやり方は³⁶、努力しているように見えながらも効率は悪いものです、修正のためのDTPオペレーションにも時間がかかります。

校正が3校では収まらずに、4校や5校まで無駄に引きずられることもあります³⁷。また、全体を通して用字や表記を統一する作業には無力です³⁸。

10.3 最近主流の校正作業

これが、1世代前（5年前を想定）になると、次のようなやり方がスマートだと考えられるようになりました。

1. 校正紙は、紙でプリンタ出力しなくても、トンボ入りpdfを電子化して出せばいいんじゃないか？
2. 編集は、pdf校正紙に、注釈やメモを使って、修正指示（赤）を入れればいいんじゃないか？
3. DTPは、編集がpdfに入れた赤を拾って修正すれば、コピペもできていいんじゃないか？
4. 各種ツールがあるので、たとえば比較したいリビジョンと差分を取って違いだけを表示するとか、全体を通して用語／表記統一するとか、便利なんじゃないか？

つまり、校正紙を、紙のものからpdfベースにすることで、pdfツールが持つ機能性を使って、効率よく校正作業が進められるのではないかと、期待したのです。この方法は、そこそこ悪くなく、現在の多くの編集／DTPの現場では歓迎され、主流になっているかもしれません。

しかし、まだ多くの無駄が潜んでいます。たとえば、

• すべてモニタ画面上で作業するので、目、肩、腰にくる。モニタだと紙より解像度が低くて見ずらいし、ぱらぱらめくって全体を見ることができない。
• DTP作業では、いちいちマウスを使って当該箇所を直さなくてはならず、少し古いやり方と比較して、特に効率が良くなるわけではない。
• 校正記号を使って端的に指図できない。注釈やらコメントやらをマウスで開くと、意図のよくわからない指定が、冗長に書かれていてうんざりする。
• 特に、組版に対する指定は、pdfの注釈／コメントでは意図が伝わりにくい³⁹。
• pdfのようにプロプライエタリな形式のものを加工するのは、面倒。操作を覚えるコストやオーバーヘッドがかかる。

のように、世代が1つ進んだからと言って、ツールに振り回されてしまい、いまひとつはかどりません。

10.4 最新の校正手法の考え方

これらを、もう少しスマートにする方法はないでしょうか。わたしがいま、新世代なやり方だと考えている校正手法は、次の通りです。

• 編集が初校出し後にも、直接、テキストをいじれるようにして、DTP入稿以降の組版に関して、DTPが一貫して権限を持てるような仕組みを作る。そうすることで、組版作業をしながらもテキスト修正できるような、作業の並行化を実現する。
• pdf初校出しよりもかなり前の段階から、ブラウザベースである程度組版が確認できるようにする。そうすると、著者らや編集はhtmlでプレビューできるので、すばやく修正を繰り返すことができ、テキストも組版も精度を上げた状態でDTP入稿できる。
• DTP入稿時点での原稿精度が高いと、初校が真っ赤になることがなくなる。また、初校組版自体がどんどん自動組版化していき、DTPの負担を減らせる。

なんだかアジャイル教徒⁴⁰みたいなことを書いてますが、実践のコツは単純です。

• DTP入稿前に、テキスト内容と構造を完全にケリをつけておく。
• 初校出しまでに通常のスケジュールの倍かけても、初校精度を高くする。初校は組版の微調整を目的として、基本的にテキストの赤は入れない。
• プラットフォーム要件として、仕上がりイメージのプレビューと、そこから得られたフィードバックをすぐ反映できるイテレーション環境を整備する。

10.5 実践のためのプラットフォーム

では、そのような段取りを実践できるプラットフォーム要件とは、どのようなものでしょうか？

• 編集作業はマークアップベースで、エディタを使ったテキスト中心主義で進める。
• マークアップ済テキストを、すぐhtmlやxhtmlでブラウザなどからビューできる。
• DTP作業は、初校は自動組版と割り切り、見た目の直しは初校に入った赤を見て再校以降に持ち込む。
• GitHubのように、テキストベースのリビジョニングとレビューを中心にした、オープンで言いたいことが言える文化を身に着ける。

こうしたプラットフォームは、どこかのメーカーが「出版編集支援システム」みたいな名前で売っているわけではなく、売っていたとしても、お仕着せのやり方をそのまま使えるとは思いません。自分の手法は、仕事のやり方に合わせて自分で開発し、細部の自動化など、ブラッシュアップしていく必要があります。

参考として、わたしのテキスト編集作業の概要をまとめます。この全体がプラットフォームです。数式の有無など編集物に合わせて⁴¹、細部を調整しながら使います。

こうして要点を書き出してみると、出版というよりも、ソフトウェアの開発工程のように見えてきます。

このような自由度を後送りさせた段取りでも、初校を戻したあとは、ウォーターフォールモデルで、DTP担当による手作業の組版調整が行われるので、作業は不可逆になります。

よって、再校戻し以降は、従来どおりに紙に赤ペンで校正を入れて戻します。しかし、この手法であれば、再校以降に赤が入る頁は、数十頁に1カ所程度まで減らせているので、DTP担当の負担は軽減できます。

以上、やや難解ですが、わたしが実践している今ふうな校正作業についてまとめてみました。

11 索引作成など面倒なことはPythonにやらせよう

編集作業のうち、「索引作成がいちばん面倒で嫌だ」と多くの編集者は思っています。機械学習で、索引を半自動生成することはできないでしょうか？ 自然言語処理で、テキストマイニングして、重みづけして、ニューラル学習で生成みたいに。

もちろんうまくいかないことは、わかっています。それは索引とは、文脈の本質を点で表したものであって、全体の理解がなければ、的を射ることができないからです。

それでも、AI指向でがんばっている会社は、あります。すごいなあ。

索引という言霊に挑むメタデータ社

11.1 索引語をマークできればなんとかなるのでは？

とくに日本語の場合、形態素分析して語を切り出す必要があったり、漢字の読み方が複数あって、文脈によって変化するなど、低レベルな処理にも手を焼きます。

一方、本文原稿に対して、索引語を指定（マーク）した後であれば、組版後のノンブルに対応づけた索引原稿は自動で生成できそうです。索引語に次のようなマークアップをしておけば、組版システム内部で最終的なノンブルと索引語を紐づけすることができるからです⁴²。

@<hidx>{閾値の読み方}

11.2 それでも立ちはだかる日本語の壁

しかし、この方法は次の点でビミョーです。

1. 「閾値」を「いきち」と読むか「しきいち」と読むか、わからない。
2. それによって索引頁の語順という重要な順番が変わってくる。
3. 索引がネストする場合、マークアップの入力時点からネスト構造を意識する必要があり、入力が面倒くさい⁴³。
4. マークアップが完了してから、まとめて索引語をマークアップすると、せっかくFIXしたコードを壊しやすい⁴⁴。
5. 最初の100頁に初出の索引語が偏り、それ以降のページで重要語が再出しても、見逃す。

編集上、もっとも問題となるのは、5.の、索引語／頁のバランスが崩れやすくなるところです。これは編集という、情報を編み集める所為においては、かなり致命的な欠陥です。

中途半端な機械化は、ときに手作業の足かせになるものです。

11.3 現実的な手法

そこで、わたしは索引作成に関しては、あえてTeXのindexコマンドのようなマークアップを使わない手法を選びました。

概要は次のとおりです。

• マークアップ済の原稿に、さらに索引語のマークアップをするのはやめた。
• 索引原稿は、紙の校正紙を見ながらマーカーペンで印をつけ、そこから新たに、索引語とノンブルがペアになったテキストファイルを作成する。
• そのテキストファイルをPythonで処理し、ソートやネストされた索引頁のテキスト原稿を作る。
• 出来上がった索引頁原稿をDTP入稿して、組んでもらう。

面倒なことはPythonやらせる、というのが最近のトレンドなので、そうしましょう。

退屈なことはPythonにやらせよう

この手法を自画自賛しておくと、「最後まで索引語の選定に関する手作業を手放さないことによって、完成度の高い索引を編集できる」です。

11.4 pythonで書いた索引作成ツール、公開してます

この手法による索引原稿作成ツールを、GitHubで公開しています。「おかしな国のアリス」（有栖りもん）という、フォトジェニックな見本をまねすれば、このやり方で索引原稿が作れます。

どうぞご活用ください。

ドキュメントシステム：索引の作り方

ドキュメントシステム：索引作成ツール（ダウンロード）

12 原稿の履歴管理（リビジョニング）

「本の作り方」の最終回です。

原稿は、読者が考える以上に何度も書き直されるし、そのつど、「2日前の欲望のおもむくまま書いた原稿のほうが、賢者の今、書き直したものよりも面白かった」と、昔のほうがよかった幻想にとらわれるものです。

エディタを開いているうちなら、無限Undoで逐次手戻しできますが、一度保存して確定してしまったら、それより以前の履歴には戻れません。では、それほど細部まで再現できなくてもよいから、保存するごとにその版を体系的に管理して、過去に戻れる方法はないでしょうか。さらに、過去の多数の版を比較し、誰がどこをどう変えたのかが、一目瞭然となるような原稿の管理方法はないでしょうか。

12.1 ソフトウェア開発で使われるテクニックの流用

ソフトウェア開発では、コンピュータの支援機能を駆使して、アジャイルでイテレーションな顧客ドリブンの開発するのが流行です。つまり、ソースコードの履歴管理に基づいた、手戻しやマージ、修正の繰り返しが簡単にできる手法を取り入れています。

LEAN：リーン顧客開発―「売れないリスク」を極小化する技術

アジャイルサムライ―達人開発者への道―

LEANやアジャイルの言うことはよくわからないけど、かなめとなるのは「小さなリリースを短いターンで繰り返して、結果的に大きな成果を得る」です。それ、本作りにおける原稿推敲と同じじゃないですか？

12.2 原稿は変化する。だから変化に対応できる管理方法がある

現代のソフトウェア開発においては、過去の履歴（リビジョン）を体系的に管理できるGitやSVNを使い⁴⁵、何か得心がいったら「結果をコミット」のようなボタンを押して、リビジョンを進め、開発を進捗させています。

サルでもわかるGit入門

ソフトウェア開発におけるリビジョン管理ツールのGitやSVNを、ただちに編集業務に役立てるのは、一見難しそうな気がします。しかし、プログラムのソースコードも、原稿も、「テキスト」という普遍性のもとで成り立つ情報単位です。まったく同じ取り扱い方法で、Git上でもSVN上でも、そのまま原稿のリビジョン管理に使えてしまうのです。

12.3 意外にもデザイナーがGit上でデザイン管理している

GitやSVNは、ちょっと前までコマンドで使うのが当たり前のような風潮がありました。いまは、TortoiseGitやTortoiseSVNのような、使いやすいGUIがあります。それらでは、リビジョンのブランチやマージが一目瞭然なので、複数の人が書き込んでカオスとなった原稿でも、視覚的に整理することができます。

原稿の過去も現在も、一目瞭然に可視化してくれるTortoiseGit

意外なことに、デザイナーが、GitHubを使いこなしている例が多くあります。なぜなら、それはクライアントから「2日前に出してもらった3案だけど、やっぱりB案にして、それをC案みたいに一部変えたヤツにできない？」とか言われているんだろうなあ。

仕事に履歴管理の概念を導入することは、理系の論文執筆などにおいては自明の手法です。いまのところ、出版業界ではあまり知られていません。しかし、現場に導入すれば、作業が効率化する上、いちいちの精度が高まり、編集成果物の品質も向上します。

GitやSVNを使った無料や低額なクラウドサービスもあるので、まずは何も考えずに使ってみることをお勧めします。

デザイナーからプログラマーまで 絶対わかるGitバージョン管理

いかがでしたか？ ではまた、何かの本でお会いしましょう。

13 付録：テキスト処理環境の作り方

わたしは、IT先端分野の書籍を編集することが多いので、この編集作業に関して、現状でベターと考える、電子化された編集環境を構築しています。その環境を紹介します。

13.1 プレーンテキスト処理に特化した環境整備

執筆開始から、編集作業を経て、DTP担当⁴⁶に渡すまで、文字原稿はすべてテキストで流通させます。そのためにはエディタを使いこなし、テキストツール（sedやdiff, pandoc等）を使います。

編集作業のコアとなるエディタは、人によって好き嫌いのわかれる重要なツールです。わたしは、ずっとemacsを使ってます⁴⁷。

一般事務作業のように、テキスト原稿をWordやExcelで開くことはありません。それらは、プロプライエタリ⁴⁸な形式な上、テキストの構造と装飾要素がごちゃまぜなので、複数の人が関与する現場で使用すると、他の人から「まるで仕事が標準化されていない」という批判が出ます。

13.1.1 端末のスペックは低くてよい

最初に向き合うのは、何らかのハードウェアです。私見で簡単に良し悪しを。

PC本体は、仮想端末、またはWebブラウザとしてしか使わないので、スペック低くてOKです。キーボードは、PC本体よりも値が張ったとしても、フィットするものを選びましょう⁴⁹。モニタは厳選して、目が疲れないもの（EIZOの医療向けのとか）を探し出します。マウスはあまり使いません。それでもコードレスを選び、肉抜き加工して軽量化しておくに越したことはないです⁵⁰。

13.1.2 重要なのはテキスト処理環境

編集作業の大部分は、エディタ上でのテキスト操作を中心としたテキスト処理です。テキスト処理は、macOSやWindowsのローカルPCでもできますが、Linux環境があると効率的です。家に置いたPCをLinuxサーバとして動かしておいて、作業するときには世界のどこからでも、そこにログインして作業すればノマドっぽくなります⁵¹。そのような目的を実現させるために、多くのオープンソース系⁵²のソフトウェアを利用します。

テキスト処理はLinux上で行うのが標準。世界のコンテキストの英知が詰まっている

13.1.3 サーバを建てるよりもAWSを使ったほうが安い

構築した環境を安定して運用していくテクニックも重要です。原稿を失わないためには、ファイルのバックアップ手法や、共有方法を理解し、障害が発生しそうな部分を冗長化しておきましょう。いわゆるハイアベイラビリティ（高可用）運用というやつですね⁵³。

それをオンプレでやろうとすると⁵⁴、「腰をかがめて配線とか、やってられるか！」となるので、可能ならクラウド上に構築できないかを検討しましょう。

直接的な作業のためには、PC本体2台とバックアップ用に1台、モニタは3面あれば十分です。重要なのは、そのフロントエンドUIを通じて処理を進めるバックエンドのほうです。

もともと、テキスト処理はリソースを消費する量が小さいです。低スペック／高可用の構成をレンタルサーバで組めば、AWSなら10ドル／月くらいで快適な環境を得られます。GUIのリッチな編集作業環境をSaaSで組むこともできます。

オンプレサーバの電気代を気にするくらいならAWSを使ったほうが安い

コンテンツ終了。2022/6/05 日 06:44:16 JST