技術系同人誌の企画の作り方とイベント駆動で立てるスケジュール ～業務のスキルを同人誌作りで発揮しよう

DevLOVE Pubの技術書定期刊行・出版技術 第2回

　こんにちは、DevLOVE Pubです。前回は「自分たちで自分たちの技術書を作ろう」と題して、自分たちで技術系同人誌を作ることの価値について書きました。今回から、実際に技術系同人誌を出版・頒布するためのノウハウを紹介していきます。

はじめに

　今回は「技術系同人誌の企画の作り方とイベント駆動のスケジュールの立て方」と題して、どのように技術系同人誌の企画を考えていくか、どのようにして技術書を作るためのスケジュールを立てるのかについて紹介します。

　普段の業務だと「要件定義」や「マネジメント」といった言葉が似合いそうな領域ですが、同人誌を作るならば避けては通れない話です。前回の記事を読んで「技術系同人誌を作ってみよう」と思った方、また、技術系同人誌を作成しながら業務に応用できるスキルを身につけたい方は、読んでいただけると嬉しいです。

技術系同人誌の企画の作り方

　技術系同人誌とひとくくりにしていますが、実際は多種多様な技術要素を扱う同人誌が頒布されています。

　その多くは、扱う技術要素を決めて作成されています。しかし、中には扱う技術要素を決めず、執筆者それぞれが興味のあるネタを持ち寄って作っているものもあります。

　ここでは、扱う技術要素を決める場合と決めない場合、それぞれの特性について紹介します。

扱う技術要素を決めた同人誌

　本全体を通して扱う技術要素を決め、そこに合わせて執筆者を募り、原稿を書いていってもらう作成方式です。

　DevLOVE Pubでは『ライトニングトークス 驚異のプレゼン ～さあ、プレゼンに目覚めよう～』というライト二ングトークを扱った同人誌を過去に作成しました。

　技術系同人誌では、この方式で作成する場合が多いです。他のサークルがこの方式で作成している同人誌としては、以下のようなものがあります。

『Ultimate Aglie Stories』（UAS編集部）

• Ultimate Aglie Stories

　日本のアジャイルをリードする面々が、普段の勉強会では語らない、アジャイルに対する想いや知見が綴られた同人誌です。

『Software Testing ManiaX』（さーくるWACATE）

• さーくるWACATE

　ソフトウェアテストを扱うコミュニティ「WACATE」の面々が、コミュニティからスピンオフしてソフトウェアテストの同人誌を出しています。

Android同人誌シリーズ（TechBooster）

• TechBooster

　Android開発のコミュニティ、TechBoosterがリリースしているAndroidの同人誌。そのなかでも、『Effective Android』は、同人誌で頒布したものが商業出版されるまでに至りました。

　この方式は、扱う技術要素を決めない場合に比べ、執筆しやすいというメリットがあります。一方、ネタが枯渇しやすいというデメリットもあります。

扱う技術要素を決めた同人誌をつくる場合のメリット・デメリット

メリット	デメリット
執筆を依頼しやすい →「◯◯について書いてもらえますか？」とお願いできる 執筆しやすい →書くテーマが決まっているので、ネタを考えやすい	テーマ設定が難しい →毎回テーマを変える場合、テーマのネタ出しが大変 ネタが枯渇してくる →回が進むほどに、ネタに困ってくる

　特定の技術を扱うコミュニティから有志を募って、そのコミュニティで扱うテーマについて同人誌を出そうという場合は、こちらの方式がおすすめです。

　DevLOVE Pubでは、テーマや扱う技術要素を毎回変えようとして苦しみました。その結果、この方式を取らないことにしました。

扱う技術要素を決めない同人誌

　執筆者それぞれが興味ある技術要素を取り上げ、それを持ち寄ってひとつの同人誌に仕立てる作成方式です。

　DevLOVE Pubでは、初期の作品である『DevLOVE HangarFlight Experiences』や、現在作成している『Far East Developer Review』が該当します。

　この方式で同人誌を作っているサークルはあまり見かけませんが、例としては以下があります。

『ななかInside Press』（第7開発セクション）

• 第7開発セクション

　「Webサービス屋がよってたかってつくる技術マガジン」を称して、これまでRailsやHadoop、Chef、Immutable Infrastructureなど様々な技術要素が扱われています。毎回Web業界注目の技術トピックを取り上げているところがポイントです。

　この方式は、扱う技術要素を決めないため、好きな技術要素、トレンドの技術要素を扱いやすいというメリットがあります。

　一方、執筆者は毎回扱う技術要素を考えないといけないデメリットもあります。

扱う技術要素を決めない同人誌をつくる場合のメリット・デメリット

メリット	デメリット
トレンドの技術を扱いつづけられる →扱う技術要素を決めないので、毎回トレンドの技術を扱うことができる 好きなことを書ける →テーマに縛りを設けないため、執筆者それぞれが好きなことを書ける・ネタが枯渇する心配がない→毎回興味があることについて書けるので、ネタに困らない	執筆を依頼しにくい →「なんでもあり」と言ってお願いするハードルは高い（こちらから「このテーマで書いてください」と言ってお願いすると、ハードルが下がる可能性あり） 執筆が大変 →執筆者それぞれが何について書くかから考えないといけない（当初考えていたテーマとは別のテーマの原稿が出てくることもしばしばある）

　DevLOVE Pubの場合、コアメンバー各自の興味範囲が違っています。そのため、こちらの方式を採用することで、継続的にリリースできるようになりました。

　業界内の仲間同士で集まって、本を書いていく場合はこちらの方式が向いているでしょう。

　どちらの方式も一長一短あります。自分が書きたいテーマ、一緒に書きたい人たちを考慮して、どちらの方式を取ればよいかを考えてみるといいでしょう。