chap_gather_article.re

= 原稿の集め方

この章では、合同誌を主催するために必要な原稿の集め方について実例を交えて解説していきます。

合同誌は個人誌のときとは違い多くの人が協力して作り上げていくものです。一人あたりの仕事量は少なくなりますが、主催は参加者の原稿をまとめたり、締切などのスケジュールを設定したりと、原稿を書く以外の仕事が大量にあります。特に参加者の原稿を集めるのは大変です。まずどのように原稿を書いてもらうか、原稿のテーマはどのように決めていくのか、原稿はどのように提出してもらうかを主催者自ら決めて、実際に参加者に動いてもらう必要があるのです。

そこで、今まで合同誌を主催した筆者たちがどのように考えて参加者に原稿を書いてもらったかを参加人数やどのような状況だったのかを踏まえて解説していきます。これを読んで、合同誌を主催するにあたって何かしらのヒントやアドバイスになれば幸いです。

== はじめに

こんにちは。「すべてが(M)icroになる」というサークルを主催しているota42yと「Gravity Pianist」というサークルを主催しているひゃたです。技術書典やコミックマーケットでマイクロサービスに関する本やAmazon Web Servicesでのサーバーレスアーキテクチャに関する本などの技術系の合同誌を頒布しています。

私たちはこれまでいくつかの合同誌を作ってきましたが、その度に規模や書く人の経験量など状況が違いました。そうなると、そもそもの作り方やどのように多くの執筆者から原稿を集めてくるかが変わってきます。主催者は執筆者にどのように原稿を頼むべきなのか、執筆者に対してどのように接するべきなのか、考えることは山のようにあります。もちろん、執筆者が締め切りになっても原稿を上げてこないなんてトラブルは当然のようにあります。（笑）

ここまで書くと、「主催って大変そうだな……やめようかな……」と思われるかもしれませんが、それほど難しく考える必要はないです。これから紹介するノウハウや事例はあくまで一例です。商業誌ではなく同人誌なんですから、好きなテーマで好きなように書けば良いのです。細かく考えるよりもまずは衝動に任せて動く方が重要です。しかし、ここにある事例を知っていると、原稿を集める作業などがスムーズに進む確率が上がるかもしれません。主催として動きたい方やどこかの合同誌に執筆者として参加される方は、作業を始める前にまずこれを読んで作業が快適に進められるようにしましょう。

== 下準備

いきなり主催が「合同誌作るぞ！」と宣言しても、いきなり本ができるわけではありません。何事も下準備というものが必要になってきます。特に合同誌では執筆者が複数人いるのですから、ある程度の情報共有やルール作りが重要です。ここでは、まず主催者は何を決め何を準備するべきなのかを詳しく解説します。

合同誌を作る上で、主催がまずやるべきことは本のテーマを決めることです。本のテーマは原稿を書く人にとっては「何を書くのか」の指標となりますし、読む人にとっては「この本には何について書かれているのか」を知るキッカケとなります。「テーマは自由」として特に何もテーマは決めずに原稿を集めるのは難しいでしょう。執筆者からすれば、小学校の頃にやった夏休みの自由研究のようになってしまい「そもそも何書けばいいんだっけ？」と混乱してしまいます。

では、まずはテーマを決めていきましょう。よく技術書でテーマになるのは以下のような事柄になります。

 * 特定の技術・プラットフォームに関すること
 ** ex. React、マイクロサービス、AWS、自作キーボード
 * 特定の分野に関すること
 ** ex. 完全食、本の作り方、マネージメント、肉
 * 特定の会社に関すること
 ** ex. 会社で使われている技術

これから作るのはあくまで同人誌です。「このテーマでどれくらい売れるかな？」とか「このテーマだったら話題になるかな？」とかそんなに考える必要はありません。「うるせぇ！俺はこれに興味があって、これについて書きたいんだよ！文句あっか！」くらいでちょうどいいです（笑）。

ただ、「テーマをどこまで狭めるか」は考える必要があるかもしれません。テーマによっては広すぎて、何を書いたらいいのか、何が書かれているのか、がわかりにくくなってしまうこともあります。例えば、「Amazon Web Services」がテーマだと範囲が広すぎるかもしれません。もう少し狭めて「Amazon Web ServicesでDockerをうまく使う方法」や「Amazon Web Services扱うデータベース」といったように少しテーマを狭めた方がいい場合もあります。

テーマを決めてもそれは本全体のテーマであって、執筆者のテーマはまた違う場合があります。特に会社で使われている技術を紹介するといったテーマの場合は、何を書いたらいいかわからないと感じる執筆者も現れるでしょう。そういうときは主催がテーマを考えて提案することも重要です。例えば、「○○さんがこないだ使っていたあの技術を紹介しましょう」とか「あのブログ記事を本のためにリライトするのはどうでしょう」といった提案があると、それが指標となって執筆者が何を書きたいかが明確になることがあります。

書くテーマは決まったら、次は原稿を実際に書いてもらい集める作業となります。ここで主催がやるべきことはまず原稿の記法と原稿の提出先を決めることです。
原稿の記法として技術書関連でよく使われているのは、Markdown記法やRe:VIEW記法@<fn>{re_view}です。どの記法を選ぶかは主催者であるあなたが決めて良いでしょう。最終的な製本の際にどのような状態で出力したいかによると思います。ただし、まだどの記法にもなれてない執筆者が多くいて、記法を覚えてもらうのが難しい場合もあると思います。そういうときはWordやWikiといった執筆者が慣れたツールで原稿を書いてもらい、変換作業は主催がやるというのも一つの手です。このあたりは記法の学習によって時間が取られるよりも、執筆者が慣れたツールで原稿を書いてもらい少しでも原稿を書く時間を増やしたいという場合有効でしょう。もちろん、主催の作業は増えるのでケースバイケースだとは思いますが。

//footnote[re_view][https://github.com/kmuto/review]

原稿の提出先は使い慣れたものであればなんでも良いです。DropboxやGoogleドライブなどのストレージサービス、テキストベースの記法であればGitHubなどのホスティングサービスを使うのもありでしょう。また、Wikiに提出してもらうというのも良いでしょう。個人的にはGitHubやWikiをオススメします。なぜかというと何時でも更新内容が確認できるため、各執筆者の進捗がわかるからです。

最後に締切を決めましょう。締切は重要です。多くの同人誌が生み出す原動力になっているのが締切という存在です。締切という存在がないと、人はいつまでもあーでもないこーでもないと言いながら自分の原稿を完成させません。締切という概念から来る焦りと不安と印刷所の割高料金によって創作とは成り立っているのです。

合同誌の場合、経験則ですが原稿の締切は印刷所の締切よりも2～3週間前くらいが良いと考えています。原稿をまとめて一冊の本にするのはそれなりに時間がかかります。校正や誤字脱字の修正、文字数が足りなくてほぼ白いページはないかなど原稿が集まっても、その後の修正には時間がかかるからです。

また、主催も原稿を書く場合は他の人の原稿の締切よりも早めに原稿を上げてしまうと良いです。特にまだ原稿を書くことに慣れていない執筆者がいる場合、その原稿が指標とできるからです。

これで、下準備は以上となります。主催のやるべきことは多いですが、慣れてしまうとそれほど大変なことはありません。自分たちが作りたい本のためにもしっかりと下準備をしてから原稿に望みましょう。


== ケーススタディ

この項では合同誌を作ったケースごとに、注意した点などをまとめていきます。

そのために合同誌をストーリー形式とアンソロジー形式の2つに分類します。なお、この分類方法はこの項独自であり、一般的に通用するとは限りません。

ストーリー形式とは一冊を通して一つの続き物の話になっており、前から順に読むことを想定して書くものになります。

アンソロジー形式とは個々の要素が独立しており、読者が好きな章から読めるように構成されているもので、この本の形式がまさにそれになります。

筆者がこれまで作った三種類のパターンに分けて、そのパターン毎に書いていきます。

各パターンはどれも5人前後で、ひとりひとりが10ページほどの原稿を書く場合を想定しています。

=== ケース1 経験者かつアンソロジー形式の場合

合同誌を書く人の多くが執筆経験があり、かつ個々の原稿が独立している場合です。
筆者の場合、「Microservices architecture よろず本 その二」をこの形式で進めました。

この形式の場合は前に揚げた下準備を除くとほとんどすることはありません。個々の執筆者はそれぞれある程度のレベルで文章が書けることが期待できますし、大まかな本の作り方もわかっているため、それぞれが自走して作っていけます。そのため、始めに合同誌自体のテーマを決めれば以降の介入はあまり必要なく、執筆環境を整えたり、書く内容が被らないように調整するなど、基礎部分についてのみ気をつければ良いです。

ただし、個別に書き進めていくのはハマりやすい部分があるため、テーマがうまく決められているか、原稿の進捗は良いかといった所は初期のうちに注意して見ておき、危なそうなら早めに対処しておくと安全です。初期を乗り越えてある程度着手できればだいたい大丈夫です。

このケースは各執筆者の能力に期待できるため、原稿を集める段階においては困難になる箇所は少ないです。そのため、最初にうまく回るように場を作るところや、原稿ができた後の編集作業など、原稿を書く前後の部分に労力がかかりますが、原稿を集めること自体の労力は大きくないです。

=== ケース2 未経験者かつアンソロジー形式の場合

合同誌を書く人の多くが執筆未経験であり、かつ個々の原稿が独立している場合です。

筆者の場合、「Microservices architecture よろず本」と「Amazon Web Services サーバーレスレシピ 2018.04」と「FiNC Technologies TECH BOOK」をこの形式で進めました。

執筆未経験と言っても、ブログ記事といったある程度の長さの文章は書いたことがあり、あくまでも同人誌での執筆が未経験の人達を想定します@<fn>{long_no_text}。

//footnote[long_no_text][私は長い文章を書いたことが全くない人と合同誌を作ったことがありませんが、そのような方の場合はより原稿を書いてもらう部分を厚くサポートする必要があると思います]

このケースの場合も大きな流れは経験者かつアンソロジー形式と同じく、最初に合同誌のテーマを決めます。その後個々の執筆者が書きたいテーマを考え原稿を書き進めていくのですが、執筆未経験の人に対してはテーマを決めるところからサポートした方が良いです。

書き慣れてないとテーマ決めが難しかったり、徐々にテーマからずれた原稿になってしまう場合や内容が最終的にかぶってしまうといった、想定外のことが起きやすいです。そのため、執筆者がテーマを決めきれない場合、書くのに良さそうなテーマを主催から提示するというようなサポートをする必要があります。

例えば、執筆者がブログなどの別の媒体で書いた記事の中で人気の高かったものや主催が気に入った記事を加筆修正して原稿にしてもらうのも良いですし、他の執筆者が書きたかったり読みたかったりしたテーマをいくつか提示して選んでもらうのも良いでしょう。

執筆未経験の人が多い場合はなるべく使い慣れたツールで書いてもらう方が良いこともあります。
記法を覚えてもらうよりも、先に使い慣れたツールで原稿を書き進めてもらい最終的に主催側がRe:VIEW記法などの記法に修正するという手法です。「FiNC Technologies TECH BOOK」ではこの手法を用いています。この本の場合はScrapboxというドキュメントツールを使って全員が執筆しました。Scrapbox自体は社内で使われているもので、全員が不自由なく使えるツールだったためです。これにより執筆や編集をスムーズに行うことができました。更に会社本ということで広報チェックが入ったのですが、広報スタッフもScrapboxが使えたのでチェック作業も滞りなく行えました。

また、本人も文章を書くスピードがわからない場合が多いため、進捗が思った以上に出なくて締め切りを過ぎてしまうといった場合もあります。実際、締め切りをかなりすぎてしまい、バッファ込みで取っておいた編集作業がかなり圧迫されるという問題が起きたことがありました。この形式の場合は個々の執筆者の自由度が高いため、ある程度原稿を書いているときも介入するとお互いにとって安心して進められると思います。

=== ケース3 未経験かつストーリー形式の場合

合同誌を書く人の多くが執筆未経験であり、かつ全体を通して1つの話になっている形式です。
著者の場合、「How to Develop Flutter Apps」をこの形式で進めました。

この形式の場合も他と同じく最初に合同誌のテーマを決めます。
その後テーマをさらに分解していき、各章で何を書くかを細かく決めていきます。
全体として一つのストーリーになるので、それぞれの人が独立して動けるようになるまで細かく分解していく必要があります。
ここで何を書くかほぼ全員が大枠でわかるぐらいまで詳細に決めておくことで、経験がない人でも安心して執筆を行えます。

より具体的に説明していきます。
この形式で書いた本はFlutterというモバイルアプリケーションのフレームワークの入門書で、一冊を通して全く知らない状態からアプリを一つ作り、その過程でFlutterについて理解を深めていく構成の本になっています。
この本を書くにあたっては、最初に著者達で具体的にどのようなアプリにするかを決め、さらにそのアプリを作る過程をどういった章立てで書いていくかについてざっくりと決めました。

//image[gather_article/gather_article][最初に決めた内容]

上記のホワイトボードの画像が一番最初に決めた内容になります。
ここから更に各章ごとにどういった内容を書いていくかを箇条書きで分解していき、個人ごとの作業を行っていきました。
また、文章の比重が大きい章については執筆経験者が担当し、実装がメインで比較的書きやすい部分を書きなれていない人が書くなど、
分担も適切に行えました@<fn>{long_no_text}。

//footnote[divide][ただし、意図してそういう割り振りになったわけではなく、あとからそうなっていることに気が付きました]

事前の準備をしっかりしておけば、あとはオムニバス形式とだいたい同じ流れで進められます。
ただし、全体を通して一つのものになるので書き始めるまでにやることが多く、スケジュールには気をつける必要があります。

== 終わりに

本章では筆者達の経験を元に、原稿を集めるために力を入れたことについて述べました。

原稿を集めるためにはまず原稿を書き上げてもらう必要があります。
そのため、テーマ決めから原稿を完成させるまでのバックアップをどうやるかが重要で、参加者全員が書きやすい状態を作れればおのずと原稿が集められます。
どういった準備が効果的かはその時の状態に凄く左右されるため、本章を参考にその場に応じてアレンジしてもらえれば幸いです。