これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。
原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。
「記法はなんでもいいけど、できればテキスト形式で」
今日は、この答えの背景を話します。
まずは「なんでもいい」の部分から。
記法はなんでもいい
出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。
原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるということです。 脳内にあるものを他者に見せるための形を決めるわけではありません。
しかし、書き手が脳内を吐き出すという行為には、「どう見せたいか」という書き手自身の気持ちがどうしても混ざります。 この、「どう見せたいか」っていうのは、書く内容に合わせて思いつくものだったり、文章化が難しいから逃げるという側面もあったりするので、書く前から全パターンを網羅しきれるものでもありません。
で、脳内にあるものを吐き出した原稿と呼ばれる何かを、読者向けの見せ方を意識しながら整理する、そんな専門職があります。 編集者っていうんですけど、編集者によっては「あるドメインの読者にとってうれしい見せ方」から「適切な吐き出し記法」を逆算し、それを自分のキャリアのどこかの時点できちんと整備して、知見として執筆者と共有できている人がいます。 ぼくはそれをサボってきたので、そういう知見をとくに提供できず、「なんでもいいです」という頼りない返事になってしまうというわけでした。
ただし、ここからが重要なんですが、考えなしに「なんでもいいです」といっているわけでもありません。 言い訳っぽいですが、吐き出し記法に付随する見え方のほうを意識して見え方に頼った書き方をしてしまったり、汎用のブロック要素を利用した見せ方に依存する書き方が生み出されたり、そういうのを繰り返した結果として、「原稿の記法はあらかじめ決定しないほうがうまくいく」となって現在に至っています。 適切な吐き出し記法をいろいろ考えた結果、適切な吐き出し記法を汎用化すると（少なくともぼくには）うまくいかない、というジレンマに陥ったわけです。 ポジティブにいうと、好きな記法で吐き出してもらうのが執筆者とぼくにとって楽なケースが多いと判断したということです。
できればテキスト形式で
すでに結論めいたものを書いてしまってますが、どう見せるかの検討に移ってよいのは、脳内にある概念をとりあえず文字列として吐き出し、それを文章にして、さらに段落としてしっかり構成したあとです。 もうちょっと正確にいうと、段落の構成を試行錯誤するのと並行して、ようやく見せ方を考えられるようになります。
こんなふうに言うと、「はじめに構成をかっちり固めてから書くんじゃ」という声が聞こえてきそうですが、怒られを恐れずにいえば、それは幻想です。 文章を書く前から段落の構成をかっちり固めるには、相当の訓練とあきらめが必要です。 むしろ、文字列をダンプしたものから段落を試行錯誤して練り上げることこそが、文章作成の王道だといえるでしょう。
原稿がテキストであることが重要なのは、これが主な理由です。 文字列、文章、段落を行ったり来たりするイテレーションを、コンピュータを使って回しまくるには、テキストデータがいちばん好都合なのです。 だから、テキストで書いてください。
さらに、テキストとして吐き出されていれば、編集者が文章や段落をつくる手伝いができます。 テキストであればどの環境でもエディタで編集できるから、という面もありますが、もっと大きいのは、テキストであれば差分をとったりバージョン管理システムを利用したりすることで、編集者の作業を執筆者から見て透明にできるからです。
脳内にある情報を原稿として吐き出すのは、たいへんです。それをさらに文章や段落にするのも、けっこうたいへんです。 だから、後者のほうを手伝う職業として、編集がいるわけです。 しかし、原稿から文章や段落にする過程で、原稿のポイントが失われたり、もともとの執筆者が意図していない情報が紛れ込んだりするのは問題です。 この過程では、「編集者がやったこと」がつまびらかになっている必要があります。 つまり、編集者の作業が執筆者にとって透明である必要があります。 それがコンピュータで不自由なくできるのも、いまのところテキスト形式だけなので、その点でも原稿はテキストにしたいという結論になります。
原稿はソースコード、組版結果はバイナリコード
前述したように、原稿をテキスト形式で書き出し、テキスト形式のまま編集することは、編集者の作業の透明性を高めます。 編集者の作業が透明であるということは、作業結果がすべて執筆者の手元で再現できるということでもあります。 しかも、バージョン管理システムを使えば、元の原稿に対する差分（の積み重ね）という形で再現できます。
これは、執筆者が自身の吐き出した原稿をソースコードとして保持し、そのゆくすえを終始自分の管理下におけるという意味でもあります。 わりと見逃されてる点だと感じてるんですが、「原稿を人に見せる形にまで加工するプロセスが、原稿に責任がある本人にとってアンタッチャブルな状態」って、書き手にとっても編集する側にとっても、けっこう怖くないですか？ データとしてアクセスできなければ、どこがどう変わったかをgrepしたり、あとで気づいた用語の間違いを全体にわたって機械的に変換したり、そういう作業が死ぬほどめんどくさくなります。 気に喰わない文章や段落を試行錯誤して手直しすることも、気軽にできなくなってしまいます。 少なくとも、あとは版面に情報を適切に固定するだけという状態になるまでは、編集者はいうまでもなく執筆者自身も原稿にアクセスできるほうがいいはずです。
原稿に責任がある人が、原稿への計算機によるアクセスを奪われないためには、そもそも原稿がそれにかなった形式である必要があります。 その形式として妥当なのは、テキストでしょう。 執筆者にもDTPアプリケーションを執筆に使ってもらう、もしくは、執筆者が利用できるワープロソフトで組版もするという可能性もありえなくはないですが、こうした方法は先に言及した「適切な吐き出し形式」に似たジレンマに陥ります。 「こう見えてほしい」という気持ちを前提にして吐き出しをすると、しっかりした文章や段落を構成するのが困難になるのです。 書いている最中に見せ方を工夫したくなってしまうのは、早すぎる最適化の罠だといってもいいでしょう。 まして、WYSIWYG環境で書くのは、バイナリコードを直接いじっているようなものです。 （そもそも、見た目の先にある組版という専門性が要求されるプロセスに、非専門家が手軽に介入できる状態はどうなのかという問題もあります。 原稿がどう見えてほしいかと、その要求をどう実装するかには、さらに一段階ギャップがあるのです。）
なんだか、ドキュメントにおける構造とスタイルの分離という、よくある話に収斂しているような気もしますね。 実際、気のせいじゃありません。 この記事で言いたかったことを、構造とスタイルの分離という話に翻訳すると、次のように要約できます。
- ドキュメントの構造となる部分の試行錯誤では、テキスト形式を使うのが作業面でもっとも理にかなっている
- ドキュメントの構造となる部分は、原稿に責任がある人から最後までアクセスを取り上げるべきでない部分でもあり、それに都合がいいのはテキスト形式である
なお、この記事の趣旨は「執筆や編集にはテキストエディタが最高」ではないので、べつにWordとかGoogle Docs、あるいはIDEなどを執筆や編集に使ってもぜんぜん問題ないです。 ただし注意が必要なのは、それらツールにネイティブな形式（.docとか）をソースにしてしまうと、ここに挙げたようなテキストであることの利点が生かせないということです。 なので、どんなツールで書くにしろ、どこかの時点ではテキスト形式にして、それを最終的なソース原稿とするのが無難だとおもいます。
記法が決まらないと前に進めないならMarkdown的なやつで
というわけで、文章を書くときは、「とにかく脳内をダンプし、試行錯誤して段落を組み立てる」のが基本です。 繰り返しになりますが、脳内を吐き出すときの記法は、どう見えてほしいかという気持ちに無意識に依存してしまいます。 その依存を断ち切り、どう見えてほしいかはいったん忘れて文と段落の構成に集中するというのが、一次脱稿でいい状態にもっていくコツ（はやく脱稿するコツではない）です。 「段落だけを書く」という覚悟で望みましょう。 どんな本にも適用できる決定版の見せ方はないけど、万能の書き方というのは実はあるので、パラグラフライティングをしっかりやってください。
とはいえ、そうはいっても脳内を吐き出すときの記法に何かしら制約があるほうがいいっていう人も少なくないと思います。 段落だけとかストイックすぎて無理、見出しの指定方法やインラインの強調方法とか決まってないと書けない、とくに技術書ではコードブロックや図も入れたい、という要求は当然ありますよね。
そんなときは、とりあえず、Markdownふうの記法を使っておきましょう。 ここで、CommonMarkか、それともGitHubFlavoredか、といったことを気にする必要はありません。 見ためを確認したり、そこからワンパスでHTMLやPDFを生成することが目的ではないからです。 ちょっとしたブログ記事ならともかく、どんなMarkdown方言であれ、どのみちMarkdownだけをソースにして本は作れません。 Markdownだけで本が作れたら、XMLとかLaTeXとかとっくに滅んでますね。
まとめ
この記事では、なぜ自由な記法のテキスト形式が原稿の執筆と編集で優位性があるかについて、下記の2点に注目して主張しました。
- どう見せるかは考えず、段落の書き込みに集中するためには、見せ方と表裏一体な記法には惑わされないほうがよい
- 内容に責任をもつ著者や編集者が、自分たちには手が出せない状態になる直前まで計算機を使って原稿を操作するには、データ形式としてテキストが好都合
そのうえで、これらの要求を満足するならツールはテキストエディタでなくてもよいこと、シンプルな段落以外の要素として脳内をダンプする手法としてのMarkdownふう記法の可能性について考えました。
Markdownについては、また明日なにか書くかもしれません。
0 件のコメント:
コメントを投稿