こちらは『ライティングや編集にまつわるあれこれ Advent Calendar 2018』の23日目の記事です。
さっそくですが、こちらをお読みの皆さんはMarkdownをお使いでしょうか？
いや、もう「ご存知でしょうか？」なんて聞く必要はないと思ってとりあえず使ってるかどうかを聞いてしまいましたが、このMarkdown、使いやすいような、使いにくいような、なかなか評価が安定しない記法（マークアップ言語）です。
しかし個人的には、Markdownは使う場所さえ適切なら、あるいは複雑なことさえしなければ、十分に我々を助けてくれるものだと思っています。
今日はぼくが直近の編集仕事でどのようにMarkdownを活用したか、という話を書いてみたいと思います。
目次
取り組みの舞台・背景
若干唐突ながら、ぼくは今年の11月から都内のIT企業に就職したのですが、
その前に請けていた編集仕事が最大で年度末まで続くことになっていて、この秋からはかけ持ちで仕事をしています。
で、その編集仕事というのが、数年前から時々お仕事をしているYCAMさん（山口情報芸術センター）が今年の10月に開催した以下のイベントのうち、メインのトークセッション3本の採録記事を作成するというものです。
この採録記事は同サイトに来年公開予定ですが、じつはというか、ぼくが今年の春まで10年にわたって携わってきた坂本龍一さんの音楽全集企画『commmons: schola』でも、坂本さんがゲストの方々と行った座談会の原稿を毎回作っていたので、作業的には勝手知ったるというか、馴染みのある分野ということもあって、今回のその仕事もリラックスしながら楽しくやらせてもらっています。
この種の作業に複雑な処理は必要ありません。もしこれが書籍の組版で、InDesignへの流し込みなども視野に入れてやるものであれば、いろいろと気にすべき細かい要素が出てくるのかなと思いますが、今回はとりあえず最低限の構造化や、リンク・画像等の挿入ができれば十分というか、そもそもWebサイトへの反映という時点で様々な制約が生じるので、やりたくてもさほど複雑なことはできないとも言えます。
具体的に、この作業に関する記法として必要なのは、せいぜい2〜3層の見出しの階層化と、リンク、太字、画像および動画の埋め込み、といったところでしょうか。
作戦
トークセッションの採録ですから、仕上がり次第、その内容を登壇者の皆さんに確認してもらう必要があります。「こんなこと言ってないよ」とか、「たしかにそう言ったけど、本来の意図と違うからちょっと直したい」みたいなことは普通にあるので、登壇者にはそれら下原稿を確認してもらって、必要に応じて直してもらいます。
これは書き原稿で言うところの著者校正みたいなものですね。「登壇者による原稿チェック＆修正」だとちょっと長いので、今回の記事タイトルではこの作業を「著者校正」と表現しています。
話を戻すと、この作業を進める上で少し悩んだのは、その確認用の原稿をどういうファイル形式で渡すべきか、またどういう方法で修正してもらうのか、ということでした。
相手は各界の専門家ではありますが、必ずしもライティングに馴染んでいる人ばかりではありません。普段使っているコンピュータやツールも様々でしょう。
一方で、上記のリンクからイベントの概要を見て頂けたらわかると思いますが、今回の登壇者は皆さんテクノロジーに明るい人たちでもあったので、その辺りも考慮して、渡すデータのフォーマットや修正方法については以下のように考えました。
まだすべての原稿が返ってきたわけではないのですが、今のところ登壇者からの戻り原稿で一番多いのは2番のWordです。やはりある種のデファクト・スタンダードというか、超使いやすいわけでもないですが（※個人の感想です）、積極的に拒否するほど使いづらいわけでもないですし、校閲機能も付いていますから、「まあそうだろうな」という気はします。
それから、今回のイベントではYCAMのスタッフさんたちも登壇していたので、同スタッフにも確認＆修正をお願いしましたが、YCAMでは普段からチーム内でGoogleドキュメント上でやり取りすることが多いそうで、スタッフさんは皆4のGoogleドキュメントを使ってチェック＆修正をしてくれました。
さて、上ではさらっと書きましたが、今回のやり取りのポイントは、PDFを除くテキスト系のデータがすべてMarkdown記法のままだということです。
Markdown記法は非常に簡素であるとはいえ、太字は「**」で囲みますし、リンクは「[文字列](URL)」、画像に至ってはその行頭に「!」を付けたりする謎表記にも満ちているので、普段からMarkdownに親しんでいる人でもなければ「なにこれ」という感じだと思うのですが、その辺はあえて説明せずにデータを渡しました。
というのも、ここでチェック＆修正をしてほしい部分というのはただ日本語の文章が並んでいるところだけで、その部分にはMarkdown記法を混ぜ込まないようにしておいたので（後述）、よほど奇妙な見栄えになっていなければとくに混乱は生じないだろうという見込みがあり、実際今のところ大きな問題は出ていません。
上記の「Markdown記法を混ぜ込まないようにしておいた」という点について、これは今回の進行を考える上で一番工夫したところで、初めての試みでもありました。
というのも、今回の最終形はWebページなので、文中の特定の語句から外部サイトへのリンクを張りたいところがいくつかあったのですが、これを原稿の状態で、たとえばこんなふうに*2
私は[Google検索](https://www.google.co.jp/)だけは使いたくなかった。
文中にリンク記法を用いてしまうとさすがに邪魔というか、原稿チェックに集中できないので、こういうところはこんなふうに表記しました。
私はGoogle検索だけは使いたくなかった。 Inline-link 'Google検索': https://www.google.co.jp/
やや冗長にはなりますが、これによって肝心の日本語文章の部分は読み書きしやすくなりますし、どの語句にどのURLをあてるかという情報を記録しておくこともできます。また、登壇者的にも関心があれば「へえ、〈Google検索〉というところにリンクを埋めるのね」みたいに解釈することが可能になります。
画像の入り方をどう伝えるか
もう一つ、今回の仕上がりページでは登壇者がセッション時に使用したスライド画像なども挿入したかったので、これを原稿チェックのタイミングでどう示すか、少し頭を使いました。
単に文中に
私はGoogle検索だけは使いたくなかった。 ＊ここでGoogleの画像を入れます。
みたいにメモを入れておくだけでも良いといえば良いのですが、いずれにせよその後にWebデザイナーさんやオペレーションをする人（以下「Webデザイナー」*3）にデータを渡すときには画像の挿入位置と対象の画像情報を紐づけて知らせなければならないので、できればこの原稿作成の時点で対象画像の情報も入れておきたいと思い、結局ここもMarkdown記法のまま、
私はGoogle検索だけは使いたくなかった。 Slide: 
みたいに表記しました。
こうした部分も当然、普段Markdownを書かない登壇者にとっては「？」という感じだったと思いますが、ここまで作っておくことによって、これをHTML化した段階で以下のレベルまでイメージを表現できるので、
あとはこれをブラウザからPDFとして保存して、前述の3番の資料として同封しておくことで、登壇者にとっても仕上がりがイメージしやすくなったのではないかと思っています。
＊ちなみに、この方法を取る都合上、実際には資料フォルダの中には「img」という子フォルダが作られていて、登壇者は見ようと思えばその中の画像群も見ることができました。わざわざ見た人はほとんどいなかったと思いますが・・。
Previm
そのHTML化の手段ですが、ぼくがもう何年も前から使い続けているMarkdownプレビュー用のVimプラグイン「Previm」を使いました。
この際、デフォルト設定のままだとヘッダー（ファイル名や更新日時の情報）が表示されるのですが、今回は登壇者のチェック用ということで、その辺の情報は不要なので設定値をゼロにして、
let g:previm_show_header = 0
また今回のPDF（HTML）ではどうしてもフォントにこだわりたくて、あとは画像サイズもできるだけ細かく調整したかったので、PrevimのカスタムCSS機能を使って、CSSの追加要素を以下の感じで設定しておきました。
let g:previm_custom_css_path = '/path/to/additional.css' " パスとファイル名は説明用のダミー
＊CSSはデフォルトを無効にすることも可能ですが、ぼくはデフォルトは生かしつつ、必要な要素を追加する形で対応しました。
＊フォントはいろいろ試行錯誤した結果、Rictyに落ち着きました。
意図と各種の効果
これを書いている12/23現在、登壇者とのやり取りはまだ少し残っていますが、今のところはこれという混乱もなく進んでいます。前述のとおり、Wordの校閲機能を使って詳細に直してくれた方もいれば、内容的にはほぼノータッチで "Wonderful documentation" と評してくれた海外の登壇者さんもいました。（嬉しい！）
＊じつは今回初めて英文の原稿を作成して、これはこれで個人的にはかなりドラマチックな進行でしたが、長くなるのでその話は別の機会に・・。
今回のぼくのテーマは、「いかにして最小の手間で、最大の効果を生み出すか」ということで、それは仕事をかけ持ちしていたからということもありますが、それよりも「ほとんど同じはずの登壇者宛のデータとデザイナー宛のデータをわざわざ手作業で別個に作る」という思考停止的な作業をしたくなかったから、という理由が大きかったです。
実際には、デザイナーさんの方ではぼくが渡したMarkdownファイル（あるいはそこから生成したHTMLファイル）をそのまま使うわけではないのですが、それでも必要なリンク情報や画像、太字にしたい箇所などをすべてMarkdown記法で原稿内に指示しておくことで、登壇者のための原稿がそのままデザイナーさん用のデータにもなるという、ひとつの達成があったかなと思っています。
加えて言うと、それら関係者との連絡も結果的にだいぶシンプルになったと思います。
これまでだったら、すべての登壇者（今回だとゲスト登壇者6者、スタッフ登壇者7人）に、3種類あるセッションの原稿を振り分けて、個別メールまたはCcで必要なファイル群を添付して送っていたと思いますが、今回は3つのセッションそれぞれのフォルダを前述のDropboxまたはGoogleドライブに作っておいて、メールでは各フォルダへの限定リンクを送るだけで済みました。
ちなみにこの時、原稿チェックに際しての各種の留意点も伝える必要があるのですが、従来なら各メールに列記していた内容を上記の3フォルダそれぞれに「はじめにお読みください.txt」*4として置いておくことで、長文メールを読み書きせずに済ませるとともに、その記述もだいぶ余裕をもって行うことができました。*5
また、上記のとおり同フォルダには必要な画像もすべて入っているので、原稿が完成したあかつきには最終原稿と画像群だけをフォルダに残した上でデザイナーさんもフォルダにアクセスできるようにすれば、連携作業はすべてそのフォルダだけで完結することになります。
その意味でも、今までならやっていたはずの細かい手作業をだいぶ削減できたのではないか、と思っています。
同記事に関しては、今後大きなトラブルなどなければ、春頃までには以下のサイト内に掲載されることになると思います。（再掲）
どうぞお楽しみに。
本日の記事は以上です。『ライティングや編集にまつわるあれこれ Advent Calendar 2018』は昨年の狂騒に比べると幾分しずかな印象ですが、その分芯の通ったスッキリした記事が揃っているようですので、他の記事も合わせてお楽しみください。
*1:機密性が高いセッションはDropboxでパスワード付きのものを作り、そこまでではないものはGoogleドライブの限定公開フォルダ（パスワード不要）を作る。
*2:これを書いているときにリアルタイムで考えた例文で、文自体にはなんの意味もありません。あえて言えばGoogleのURLを使うのが無難かなと思ったぐらい。
*3:実際の作業ではデザイナーとオペレーター（テキストを流し込んだり仕上げたりする人）は別になるケースもあると思いますが、ここでは便宜的に「Webデザイナー」で統一しました。タイトル部分も同様。
*4:海外勢に対しては「README.txt」というファイル名にしました。というか元々READMEがネタ元だったので。
*5:メール送信後にも書き直すとか。
