同人文字書き向けMarkdownによる制作資料作成のススメ
これは何？
「同人誌を作るときの資料（本文以外で情報整理のために作る文書）をMarkdownという形式で書いてみませんか」というお誘いの文書です。
「同人誌を作るときに資料文書を書こう」という話はしていません。(※1)
「Markdownの記法についての詳細な解説」の話もしていません。(※2)
※1: こんな記事を読みに来る人はみんな資料書いてると思うのでいまさらそんな話はしません。
※2: 調べれば山ほど情報が出てくるので、あえて私が中途半端にピックアップすることもないでしょう。
この記事の想定読者
同人作家
小説を書く人
（ストーリ駆動で漫画を描く人）
なんとなく役に立つんじゃないかと思ってますが、あんまり根拠はないです
言語優位思考の人
視覚優位思考の人にはそこまで有用性がないと思います
非技術者
技術者にも読んでほしいけど読者の多くは非技術者だと思うので、記事全体を通してわかりやすさを優先し厳密でない記述があります。ご了承ください
そもそもMarkdownって何よ
Markdownは読みやすさと書きやすさを重視して作られた軽量マークアップ言語です。
マークアップとは「印をつけること」であり、テキスト(※3)で書かれた文章に「ここが大見出しだよ、ここが小見出しだよ、ここは箇条書きだよ」という印をつけてやることで、かんたんに構造化された文書を記述することができます。
記事をMarkdownで投稿できるサイトも多くあります。このNoteもその一つです。(※4)
具体的な記法はこのへんを参考にしてください。
https://qiita.com/tbpgr/items/989c6badefff69377da7
この記事で紹介されているのはまさに「方言」のひとつですが、おおよそのソフトウェアはこの方言に対応していると思いますし、基本的な機能はどのバリエーションでも変わりません。
※3: Windowsの「メモ帳(Notepad)」やmacの「テキストエディット」などで作れる、文字データのみを格納したファイルのデータ形式
※4: 厳密なことを言うと、Noteで使えるのはMarkdown記法の一部です
Markdownで資料を作ることのメリット
構造化をシステムに強要される
それは利点なのか？と言いたくなる見出しですね。今回は利点として主張していきます。
Markdownには六段階の見出しがあります。
Markdownで資料を作る場合、それぞれの見出しが何段階めにあたるものなのかを検討する必要があります。
複数の話題どうしの関係が、並列なのか、入れ子なのかを決めなければなりません。
また、リストも順序ありと順序なしの二つがあります。
ですから、箇条書きのようにものごとを並べて書きたいときも、それが完全に並列なのか、それとも順序づけされているのかを考慮しなければなりません。
つまり、これらのマークアップを使って資料をまとめるする時、私たち筆者はアイデアの論理構造を整理せざるを得ないということです。「構造化できる」ではなくて、「構造化しないといけない」ことがポイントです。否応なく考えさせられることが大事なのです。
これは私の経験談ですが、脳内にあるままの思考というのは思った以上にゴチャついています。
思考のままだと、矛盾や不整合、あるいは考慮が及んでいない事項は平気で生まれます。(※5)
資料文書の構造化を通してアイデアの論理構造をクリアにすることで、将来本文執筆で課題になるであろうこれらの問題を、資料作成の段階で解決できる可能性が高くなります。
※5: 執筆中に気付くのはまだ良い方で、ひどいと頒布を開始してから読者の指摘で気付くことになります（1敗）
テキストファイルなので軽量
この図は、書きかけの本記事の原稿を保存したテキストファイル(*.md)と同じ内容をWordで作ったファイル(*.docx)をファイルエクスプローラ上で並べたものです。
Markdownファイルのほうが小さいことがわかります。
わずか12kBの差、と言えなくもないですが、ファイル数がかさめばそれだけこの差が積もることになります。
ストレージ容量の進歩著しい現代とはいえ、同じ内容であるのならばファイルサイズは小さいに越したことありません。この点、単純なテキストファイルを使用するMarkdownに分があるといえるでしょう。
バージョン管理に向いている
これは現時点では多くの読者にあんまり関係ない話だと思いますが、個人的な激推しポイントなので書いておきます。
世の中にはバージョン管理ツールというものがあります。ユーザの操作によってファイルの状態を記録しておき、その変更履歴と変更内容を確認したり、ファイルの差分を出力したり、場合によってはファイルの状態を巻き戻したりできます。
Git、SVNなどが有名です。
これらのツールの多くは、テキストファイルの変更点の表示や差分出力ができますが、Microsoft Wordなどから出力されるバイナリファイルに対しては変更点の検出ができません。
私はかねてからこれらのツールが同人誌作成にも有効だと主張しているのですが、原稿に加えて資料にもバージョン管理ツールを適用するのであれば、その資料は履歴を追いやすいテキストファイルでできている方が良いはずです。なぜなら、変更が常に正しいとは限らず、あとから変更に対する修正が入ることは考慮すべきだからです。その際、「いつどこを変更したのか」「いつまで正しい記述が残っていたか」を把握できるようにしておいた方がいいはずです。
その点、Markdown文書はただのテキストファイルですから、バージョン管理の適用には向いているといえます。
具体的なMarkdownの導入方法の例
Markdownを導入するには、大きく分けて2つの方法があります。
Markdown専用のエディタを使用する
汎用テキストエディタでMarkdownを書く機能を使う
今回はこの双方について検討します。
Markdown専用のエディタを使用する
Markdownを書くためだけに作られたエディタを使う方法です。
有名ものにBoost Note、Typolaなどがあります。
また、これらの中にもいくつか種類があり、
書いたところが自動的に書式に変換されるもの（Typora等）
コードを書く窓の隣にプレビュー窓があるもの（Boost Note等）
などに分類できます。
PCではなく、AndroidやiOS等で動作するエディタもあります。
正直好みに合わせて選べばいいのですが、個人的にはコードとプレビューの対応が見えていたほうが記法を覚えると思うのでコードが見えるエディタをお勧めします。
私はスマートフォンでMarkdownを書くときには#Typeというエディタを使用しています。この記事の大部分も#Typeで書きました。
汎用テキストエディタでMarkdownを書く機能を使う
Vim、Emacs、AtomやVisual Studio Codeなど、汎用のテキストエディタに、Markdown対応の拡張機能等を導入する方法です。
本文執筆になんらかのテキストエディタを使用している人は選択肢に入るでしょう（そのエディタにMarkdown対応機能があれば）。エディタの名前と「Markdown」で検索すればある程度の情報は出てくると思います。
私は小説本文をPC上のVisual Studio Codeで書くので、Markdown資料もVisual Studio Codeで書いています。
Markdownで記載した同人誌制作資料の例
小説執筆時のプロットを以下のようにして書いています。
# 記録：サーヴァント神使・オリジナル／機械仕掛けの神
<!-- トップレベルの見出しは概要・人物・アイテム・ストーリプロットの四項目 -->
## 概要
幻妖公演から200年ほど前、神使チヨの元になった人物が人類最後の傭兵として人類を救って死ぬ話
## 人物
### チヨ
幻妖公演に登場する神使チヨの元になった人物。
全傭兵を巻き込んだ戦いの最後の生き残り。
アマイによって鏖殺機関を破壊し得る人物と認識され、最後の依頼を受けて蒸機都市『朱鷺』へと向かう。
### アマイ
企業に対して争いを起こした人物。
24時間後に企業に対する総攻撃を予告することで各地で武力衝突を発生させた。
真の狙いは鏖殺機関を破壊することができる「最後の傭兵」を探すこと。
自身は鏖殺機関が破壊されるのを見届けることなく死んだが、死後チヨを「最後の傭兵」として依頼が遂行されたため、目的は達成した。
### ナギ
チヨのオペレータ。
チヨに生きていてほしいが、チヨが自分の生命に執着していないことを知っている。
戦後回顧録を執筆し、チヨの存在が後世に伝わるきっかけとなる。
### 『神』と呼ばれた存在
幻妖公演のヨシノ大神と同一の存在。また、巫ヨシノをもとに蒸機演算母が作った疑似人格プログラム。ナギによる回顧録を発見し、神使チヨを作成した。
## アイテム
### 蒸機人形
蒸機公演で登場した「スチーム・ユカ」の発展型のような機械。
おおむね人型のロボット。
この時代の傭兵がおもに使う兵器。
### 鏖殺機関
粉砕者の生産システム。
粉砕者の戦闘記録のフィードバックを受け、動作・装備の改善を続ける。
粉砕者と人類の戦闘が重ねられることで、人類には破壊できないシステムになることを危惧されている。
本体は地下都市『朱鷺』の中央演算母。
チヨによって破壊される。
### 粉砕者
鏖殺機関によって製造される兵器であると同時に、戦闘データを収集するための端末の機能も持っている。
データのフィードバックにより無限に強くなる。
## ストーリプロット
### 起
死んだはずのアマイから鏖殺機関破壊の依頼を受ける。
すでに武器弾薬は尽きかけており、最後の在庫を装備した状態のチヨが地下都市『朱鷺』に向かう。
### 承
地下都市内で粉砕者と激しい戦闘を繰り広げる。
死闘の結果最後の一機を仕留めることに成功するが、チヨの蒸機人形は行動不能に陥り、弾薬もカノン砲一発しか残っていない。
チヨは残された砲弾で鏖殺機関の筐体に穴を開けると、拳銃を持って機体の外に出る。
### 転
ナギは、チヨが拳銃と打撃で鏖殺機関を破壊するさまを通信で知る。
直後、地下都市『朱鷺』自体の崩壊が始まり、チヨは脱出が不可能であること、自分は生に執着しないが人類には生き延びてほしいと思っていることをナギに告げる。
### 結
『神』はチヨの回顧録を発見し、チヨの存在を知る。神と人とを繋ぐ神使の原型には彼女のような人物がふさわしいと判断し、傭兵チヨをもとに神使チヨを作り始める。幻妖公演に続く
このMarkdownをPDFにおこしたものがこちら
ちなみにこの資料は以下の作品のために作成されました。
おわりに
Markdownは、
初心者にもとっつきやすく
論理構造によって思考の整理がしやすく
ファイルの管理もしやすい
便利な言語です！
みなさま良きMarkdown同人ライフを！
おわり
余談：平野はなぜ制作資料作成にMarkdownを使い始めたのか
以下は読まなくてもどうってことはない雑談です。
そもそも仕事でMarkdownを使っていた
私が初めてMarkdownで同人活動のための資料を書いたのはソフトウェア開発会社に勤務していた2023年はじめごろです。
当時は客先企業の製品に入るソフトウェアを開発する、いわゆる開発請負を担当しており、開発規模100hから400h程度の小さい案件ごとにV字モデルで開発を行なっていました。つまり、工程の最初には「客先から伝えられた案件概要を元にヒアリングを行い、客先の要求/要件を明確にする」という作業があるわけです。この際、打ち合わせ資料兼議事録をMarkdownで作成していました。
そして自分が企画している合同誌の資料を書いている際に、「同人誌あるいは物語が一種のソフトウェアだと捉えたとき、企画書やプロットは要求/要件定義書にあたるのではないか」というアイデアを得て、それからMarkdownを同人誌制作にも使うようになりました。また、より詳細な設定資料等にもMarkdownを利用できるとわかったので、資料全体をMarkdownで作るようになりました。
Gitが使えた
上に書いた「バージョン管理ツールが使いやすい」という点も私にとっては明確な利点でした。
私は小説同人誌の組版をLaTeXで行っています。原稿データの全てがテキストファイルだったので、原稿はGitでバージョン管理していました。テキストファイルのみで構造化された文章を簡易に作成できるMarkdownはGitで管理しやすい形式でした。これによって私は、原稿と資料を同じリポジトリで管理することができるようになったので大変便利になったのでした。
いまではこれなしでは同人誌の執筆も合同誌の企画運営もできない程度には使い倒しています。サンキューMarkdown、フォーエバーMarkdown。
こんどこそおわり