東大恋アス同好会合同誌 #FindOurStars Writeup（Re:VIEW編）

去る6月12日、「恋する小惑星（恋アス）」のオンリーイベント「キラキラアーカイブ」が大田区産業プラザPiOにて開催されました。私は東京大学恋する小惑星同好会の合同誌「#FindOurStars」に編集長および寄稿者として参加しておりました。

今回の合同誌は最終的に執筆6名、イラスト4名が参加し、本文80ページとなかなか厚めの同人誌になりました。文章が大半を占める本でこれだけの分量になると、なるべく校正や組版の労力を削減することが重要です。

そこで、今回は組版ソフトウェアRe:VIEWとInDesignを中心とした執筆体制を採用しました。これにより、校正やバージョン管理をテキストファイルベースで行えるRe:VIEWのメリットと、デザインや組版を柔軟に調整できるInDesignのメリットをいいとこ取りできます。

全体の構成図

本記事では、合同誌#FindOurStarsにおけるRe:VIEWとInDesignを使った合同誌の制作事例をご紹介します。

この記事の対象

・文章メインの合同誌の編集を楽にしたい人
・Re:VIEW + InDesignの同人誌制作事例を読みたい人
・大学サークルなどで円滑に合同誌を制作する体制が知りたい人

なお、Re:VIEW + InDesign制作の純粋な解説としてはこれらの記事や書籍の方が参考になると思います。あくまでいち事例としてお読みください。

・Re:VIEWで電子書籍とInDesign向けXMLを作るぞ - ただいま村
・（書籍）Re:VIEW+InDesign制作技法 - 達人出版会

登場人物

・あをもみじ氏（@awomomiji）：本書のイラスト・誌面デザイン・装丁を担当してくださいました。絵が描けてグラフィックデザインもできるつよつよ同人人間。Webもできるとか聞いたことあるような。最強か？
・kn1cht（@kn1cht）：筆者。編集長とか広報用Web制作とかやりました。技術同人誌のイベント技術書典などでRe:VIEWを使った同人誌に関わった経験あり。デザインは小さいイラスト程度ならIllustratorで作れるかな……。
・執筆陣の皆さま：恋アスに詳しい。一部の人はRe:VIEWやGitHubが使える。素晴らしい記事やイラストをありがとうございます。

参加申込みまで

当時、筆者は2021年4月に発足したばかりの東京大学きらら同好会に入会していました。4月末、恋アスオンリーイベントが6月にあるという情報を見つけ、せっかくなのでサークル内の恋アスファン数名で「恋アス同好会」を組織してサークル参加しないかという提案をしました。

その後5月初旬までに5名ほど参加してくれそうな人が現れ、十分本が出せると判断して5月9日にサークル参加を申込みました。
（あをもみじさんによる神イラストがサークルカットとして投入され、会員皆で拝んでいました）

執筆体制決め

集まった執筆陣は、同じ大学の学生ではありますが某ウイルス感染対策下&オタクサークルという特性上、面識がない人も多くいました（筆者は特に執筆陣の誰とも顔を合わせたことがなく、イベント当日にサークルの人と初めて会うという有様でした）。したがって、執筆陣が好む執筆フォーマットや技術レベルも分かりません。そこで、実際に走り出す前に、アンケートや話し合いで執筆体制を決めることにしました。

まずフォーマットについて聞いたところ、MarkdownやLaTeXで書いてもいいという人が多数でした。Microsoft Wordで大人数の原稿をフォーマットまで合わせるのは非常に困難な作業なので、テキスト形式で執筆していただいたほうが編集としては楽です。

筆者が以前に触ったことのあるRe:VIEW（.reという拡張子のファイルに文章を記述し、様々な形式で出力できる組版ソフトウェア）でPDFを出力する形式にしようかな～と考えていた矢先、あをもみじ氏から「Adobe Illustrator, InDesignでデザインしたい」との提案をいただきました。
さらに、寄稿参加のふぁぼん氏（@syobon_hinata）からの「Re:VIEWはXML経由でAdobe InDesignに内容を流し込める」との情報が決定打となり、原稿をRe:VIEWにまとめて最終的にInDesignへ放り込むことが決定しました。

進捗管理とScrapboxでの情報集約

執筆体制が決まった時点でイベントまで残り約5週間を切っていました。1人で作るならともかく、大人数が関わる合同誌で、原稿提出・校正・組版までを順番に進めると考えればかなりタイトなスケジュールです。しかも、コピー本ではなく印刷所にきちんと発注する方針に切り替えたので、発注から納品までを引くと制作にあてられる時間は3.5週間しかありませんでした。

そこで、次のようなスケジュールを組み、執筆者に周知しました。
・誌面デザイン：2週間
・文章寄稿：執筆に2週間（ここが提出〆切） + 校正に1週間
・イラスト寄稿：制作に3週間
・InDesignへの流し込みと最終チェック：最後の3～4日

文章の方が寄稿者が多く、それぞれ学業や他のサークル活動を抱えていることを考えると、全員が〆切をきっちり守れるとは考えにくいです。そこで、早めに締切を設定して校正期間を長めに取り、遅れて出てくる原稿を校正期間で受け止めるようにしました。
とはいえ、〆切に間に合うことのメリットは必要なので、「もし作業が間に合わなくなったら〆切通りに出た原稿を優先する」旨の周知をしました。

また、参加決定直後に情報集約ツールとしてScrapboxプロジェクトを作成しました。Scrapboxは、チームで使える手軽なWikiサービスです。連絡に使っていたDiscordだけでは多量の情報を繰り返し参照したり書き換えたりする使い方に耐えられないため、リンク集やページ割、ToDoの管理に活用しました。

Scrapboxでの情報管理の例

Re:VIEWへのフォーマット統一

今回の合同誌で文章を寄稿した6名のうち、フォーマットは次のような内訳でした。

①1名がRe:VIEWで直接提出
②2名がMarkdownなどテキスト形式で提出
③3名がGoogleドキュメントで提出

Googleドキュメントはテキスト形式との親和性は高くないものの、コメントや提案機能が使いやすいため選ばれがちでした。

②に関しては、まず汎用ドキュメント変換ソフトpandocによりMarkdownに統一したのち、さらにmd2reviewによりRe:VIEWへ変換しました。
③のGoogleドキュメントに対しては、いろいろ試した結果、Word（.docx）形式でダウンロードしてからフォントサイズの揺れや余計な書式を取り除き、pandocでMarkdown変換→md2reviewでRe:VIEW変換という手順を取りました。

変換ソフトウェアの活用によって、太字や下線などの書式を手動で入れる必要はあまりなく、編集の労力が削減できました。一方で、Googleドキュメントに挿入された図や脚注、数式などは手動でRe:VIEWに入れていくしかありませんでした。今後、さらに合同誌の編集を省力化したい場合、寄稿者全員にRe:VIEW形式またはMarkdown形式で提出してもらうことが考えられます。

GitHub・Google Drive・textlintを使った文章校正

Re:VIEWへの統一が進んできたので、GitHubにリポジトリを作成してバージョン管理を開始しました。技術同人界隈ではGitHub管理することも多いのですが、東大恋アス同好会は技術サークルではないので当然全員がGitを使えるわけではありません。しかし、せっかくテキスト形式でバージョン管理や修正が容易なRe:VIEWを使っていることですし、少なくとも筆者はGitに慣れていたので迷わずGit管理を選択しました。

（とはいえ、東大のコンピュータサークルTSGに所属していたり趣味でコンピュータを触っていたりするメンバーも多いため、普通の合同誌制作現場に比べてもともとGit管理を導入しやすい環境だったとも言えます）

ありがたいことに一部の執筆者は直接リポジトリにコミットして原稿提出や修正をしてくださり、編集の負担が大いに軽減されました。

Pull Requestで修正してくれる執筆者も

GitHubに慣れていないメンバーに対しては、Re:VIEWのPDF出力機能で生成したPDFファイルをGoogle Driveに設置して著者本人や著者同士によるレビューを依頼しました。Google DriveのPDFビューワにはコメント機能があり、共有設定で許可すれば自由にコメントを入れてもらえます。ここで出たコメントに関しては著者本人が対応するかどうかを返信で宣言し、編集長（筆者）あるいは著者がGitHubリポジトリに反映するようにしていました。

Google Driveでのコメント例

編集サイドでは、自動的に文章校正ができるソフトウェアtextlintにより、記号の使い方や誤字脱字について指摘・修正しました。プラグインtextlint-plugin-reviewを導入すればRe:VIEWファイルをそのまま読み込めます。

textlintはルールと呼ばれる判定プログラムを自由に組み合わせられるのも特徴です。日本語の基本ルールをまとめたpreset-japanese、技術文書のルールをまとめたpreset-ja-technical-writing、JTF日本語標準スタイルガイドをもとにしたpreset-jtf-styleを主に使いました。ただ、技術同人誌ではないためくだけた文章スタイルや小説の寄稿も許容する必要があり、preset-ja-technical-writingに関しては最終的に多くのルールを無効化しました。

textlintの指摘は筆者が確認し、一括置換で直るものに関しては編集側でまとめて修正、著者の確認を要するものはDiscordなどで個別に提案する対応を取りました。特に記号のルールについては各人の好みもあるので慎重に同意を取ったり、時には修正しない判断をしたりしていました。こちらも、今後はGitHub ActionsなどCIの仕組みを使ってtextlintを自動実行し、著者に各自エラーメッセージを見てもらうようにすれば編集の手間がさらに減らせそうです。

textlintの実行例

Re:VIEWからのInDesign用XML出力

文章寄稿の〆切が来るころ、あをもみじさん側のInDesignでの誌面デザインが完成し、いよいよXML出力の作業が始まりました。この点に関してはすでに解説ドキュメントやブログがあるので、参考にさせていただいたリンクを示しておきます。

・FAQ - Re:VIEW の使い方について（InDesign） — Re:VIEW knowledge ドキュメント
　公式ドキュメント。rake idgxmlコマンドでXMLが生成できることなどが書かれています。
・Re:VIEWで電子書籍とInDesign向けXMLを作るぞ - ただいま村
　ツールの導入からTipsまで充実した記事。リンクも役に立ちます。
・ReVIEWの生成したXMLをInDesignに取り込む時のXSL例 - 名もないテクノ手に
　xsltprocというコマンドによりInDesignで使いやすいようにXMLを整形する方法の解説。2021年の記事ですが、記事中の.xslファイルはコピペで動きます。
・MarkdownをXMLに変換してInDesignに読み込む - arinoth's memo
　XMLをInDesign側でスタイルと対応させる操作の説明。今回の合同誌でInDesignを触ったのはあをもみじ氏だけなので、この記事のURLを送り参考にしてもらいました。

XMLの生成を楽にするため、npm（textlintのために導入したJavaScriptのパッケージ管理ソフトウェア。設定ファイルpackage.jsonに独自コマンドを定義できる）のコマンドを用意しました。"npm run xml"を実行すると、XML生成とXSLによる整形が実施され、"{プロジェクト名}-idgxml"以下に章ごとのXMLファイルが作られます。

// (package.jsonより抜粋)
  "scripts": {
   "test": "npm run textlint",
   "textlint": "find . -type f -name '*.re' -print | xargs textlint -f pretty-error",
   "pdf": "rake pdf",
   "xml": "rake idgxml && npm run preparexml",
   "preparexml": "find . -maxdepth 2 -type f -name '*idg.xml' -prune -o -type f -name '*.xml' -print |  sed 's/\\.xml//' | xargs -i@ sh -c 'xsltproc style-for-indesign.xsl \"@.xml\" > \"@-idg.xml\"'"
 },

XSLは、.xslという拡張子で設定ファイルを置いておき、"xsltproc {XSLファイル名.xsl} {変換前.xml} > {変換後.xml}"のように使えます。xsltprocはUbuntu等Debian系なら"sudo apt install xsltproc"で入り、macOSなら標準で入っています。

あをもみじ氏側からは「XMLタグの切れ目に改行を入れてほしい」という要望があったので、「ReVIEWの生成したXMLをInDesignに取り込む時のXSL例」のXSLにアレンジを加えて対応しました。具体的には、出力に改行を入れる$myReturnという変数がもともと定義されているので、各タグの最後に<xsl:value-of select="$myReturn" />を入れていけばタグごとに改行した出力となりました。

また、インライン書式の入れ子（下線+太字、取り消し線+太字）にはRe:VIEWが標準では対応していないうえ、InDesign側としても入れ子ではなく別のタグであった方がよいということなので、Re:VIEWの書式を拡張するreview-ext.rbを使って<underlinestrong>や<delstrong>のようなタグが出てくるようにしました。

# (review-ext.rbより抜粋)
module ReVIEW
 module IDGXMLBuilderOverride
   Compiler.definline :ustrong
   Compiler.definline :delstrong

   def inline_ustrong(s)
     return %Q(<underlinestrong>#{s}</underlinestrong>)
   end

   def inline_delstrong(s)
     return %Q(<delstrong>#{s}</delstrong>)
   end
 end

 class IDGXMLBuilder
   prepend IDGXMLBuilderOverride
 end
end

InDesign側での流し込み作業

5月30日にRe:VIEW側では校了とし、InDesign用XMLを画像と共にあをもみじ氏にお渡ししました。InDesign側での作業は筆者も横から見ていただけなので詳しくは書けません。手順としては、まずPDFを皆が確認して問題点を指摘し、Discordで著者を交えて通話しながらレイアウトの最終チェックを行いました。自動で文章が紙面に流し込まれるRe:VIEWやLaTeXと違い、「ここは文章の切れ目だから改ページしよう」「ここは図を少し小さくして収めよう」といった柔軟な調整が随所で行われ、WYSIWYGなツールで最終調整することの利点を感じられました。

完全には自動化できなかった書式もあり、例えばLaTeX数式はInDesignに持っていっても数式としての表示にはなりません。今回は数式が本全体で2箇所と少なかったため手動で上付き・下付き文字を付ける対応としました。

これとは別に、PSDやPNGファイルの形式で提出されたイラストも紙面にレイアウトされ、6月1日に無事入稿できました。

出来上がった誌面

おわりに（やってよかったこと）

こうして振り返るとたくさんのツールを使って合同誌を編集していました。Re:VIEW / Git / textlintあたりは論文執筆や技術同人の制作で慣れていた筆者が経験でゴリ押してしまった面もあるのですが、こういうやり方もあるという参考になれば幸いです。最後に、合同誌を編集する上でやってよかったことをまとめます。

① Re:VIEWが使えた
InDesignと連携できることが早期に判明し、編集側として安心して採用できました。Re:VIEWを使うことに参加者も協力的でしたし、Gitやtextlintといった周辺ツールをいくらでも導入できるメリットを活かせました。

② 初めに執筆フォーマットを定めてから執筆した
「Re:VIEWを使いますよ」と宣言していたので、一部の執筆者はRe:VIEWで初稿を書いたりGitリポジトリのRe:VIEWファイルを修正したりしてくれて大助かりでした。
なお、一般的に合同誌を制作する際にはページ数や掲載順も決める場合が多いようですが、東大恋アス同好会合同誌は文章の寄稿が多いため、特に決めずに募集しました。イラスト主体であったり印刷費が先に決まっている場合には、ページ数や掲載順を決めて周知しておくことも必要だと思われます。

③ DiscordでのコミュニケーションやScrapboxでの情報集約を活用した
我々は大学サークルではあるものの、参加者同士が直接会わずに制作を進めました。参加者の意欲が途切れないよう、編集長として定期的にリマインドを行ったり、Discordのボイスチャンネルでもくもく会（通話を繋いで同時に作業する会）を毎週企画したりと工夫しました。
また、Scrapboxにも積極的に情報を書き込み、進捗管理やページ割の検討などに活用できました。Scrapboxでなくとも、なにかプロジェクトを行う際には情報をストックする手段がいずれ必要になります。立ち上げ後早期に情報を貯める場を用意しておくと、全員で情報を整理する雰囲気を作れると思います。

---

最後に宣伝です。東大恋アス同好会の合同誌 #FindOurStars はイベント会場で好評をいただいたほか、boothでの通販も受付中です！　各執筆者気合の入った記事やイラストが収録されています。ご興味があればぜひご注文ください。

また、東大恋アス同好会の母体となっている東京大学きらら同好会は、きららを愛する東京大学の学生をお待ちしております。簡単な入会フォームを送信していただければ入会いただけます。