はじめに
今回は「技術系同人誌の企画の作り方とイベント駆動のスケジュールの立て方」と題して、どのように技術系同人誌の企画を考えていくか、どのようにして技術書を作るためのスケジュールを立てるのかについて紹介します。
普段の業務だと「要件定義」や「マネジメント」といった言葉が似合いそうな領域ですが、同人誌を作るならば避けては通れない話です。前回の記事を読んで「技術系同人誌を作ってみよう」と思った方、また、技術系同人誌を作成しながら業務に応用できるスキルを身につけたい方は、読んでいただけると嬉しいです。
技術系同人誌の企画の作り方
技術系同人誌とひとくくりにしていますが、実際は多種多様な技術要素を扱う同人誌が頒布されています。
その多くは、扱う技術要素を決めて作成されています。しかし、中には扱う技術要素を決めず、執筆者それぞれが興味のあるネタを持ち寄って作っているものもあります。
ここでは、扱う技術要素を決める場合と決めない場合、それぞれの特性について紹介します。
扱う技術要素を決めた同人誌
本全体を通して扱う技術要素を決め、そこに合わせて執筆者を募り、原稿を書いていってもらう作成方式です。
DevLOVE Pubでは『ライトニングトークス 驚異のプレゼン ~さあ、プレゼンに目覚めよう~』というライト二ングトークを扱った同人誌を過去に作成しました。
技術系同人誌では、この方式で作成する場合が多いです。他のサークルがこの方式で作成している同人誌としては、以下のようなものがあります。
『Ultimate Aglie Stories』(UAS編集部)
日本のアジャイルをリードする面々が、普段の勉強会では語らない、アジャイルに対する想いや知見が綴られた同人誌です。
『Software Testing ManiaX』(さーくるWACATE)
ソフトウェアテストを扱うコミュニティ「WACATE」の面々が、コミュニティからスピンオフしてソフトウェアテストの同人誌を出しています。
Android同人誌シリーズ(TechBooster)
Android開発のコミュニティ、TechBoosterがリリースしているAndroidの同人誌。そのなかでも、『Effective Android』は、同人誌で頒布したものが商業出版されるまでに至りました。
この方式は、扱う技術要素を決めない場合に比べ、執筆しやすいというメリットがあります。一方、ネタが枯渇しやすいというデメリットもあります。
メリット | デメリット |
---|---|
→「◯◯について書いてもらえますか?」とお願いできる
→書くテーマが決まっているので、ネタを考えやすい |
→毎回テーマを変える場合、テーマのネタ出しが大変
→回が進むほどに、ネタに困ってくる |
特定の技術を扱うコミュニティから有志を募って、そのコミュニティで扱うテーマについて同人誌を出そうという場合は、こちらの方式がおすすめです。
DevLOVE Pubでは、テーマや扱う技術要素を毎回変えようとして苦しみました。その結果、この方式を取らないことにしました。
扱う技術要素を決めない同人誌
執筆者それぞれが興味ある技術要素を取り上げ、それを持ち寄ってひとつの同人誌に仕立てる作成方式です。
DevLOVE Pubでは、初期の作品である『DevLOVE HangarFlight Experiences』や、現在作成している『Far East Developer Review』が該当します。
この方式で同人誌を作っているサークルはあまり見かけませんが、例としては以下があります。
『ななかInside Press』(第7開発セクション)
「Webサービス屋がよってたかってつくる技術マガジン」を称して、これまでRailsやHadoop、Chef、Immutable Infrastructureなど様々な技術要素が扱われています。毎回Web業界注目の技術トピックを取り上げているところがポイントです。
この方式は、扱う技術要素を決めないため、好きな技術要素、トレンドの技術要素を扱いやすいというメリットがあります。
一方、執筆者は毎回扱う技術要素を考えないといけないデメリットもあります。
メリット | デメリット |
---|---|
→扱う技術要素を決めないので、毎回トレンドの技術を扱うことができる
→テーマに縛りを設けないため、執筆者それぞれが好きなことを書ける・ネタが枯渇する心配がない→毎回興味があることについて書けるので、ネタに困らない |
→「なんでもあり」と言ってお願いするハードルは高い(こちらから「このテーマで書いてください」と言ってお願いすると、ハードルが下がる可能性あり)
→執筆者それぞれが何について書くかから考えないといけない(当初考えていたテーマとは別のテーマの原稿が出てくることもしばしばある) |
DevLOVE Pubの場合、コアメンバー各自の興味範囲が違っています。そのため、こちらの方式を採用することで、継続的にリリースできるようになりました。
業界内の仲間同士で集まって、本を書いていく場合はこちらの方式が向いているでしょう。
どちらの方式も一長一短あります。自分が書きたいテーマ、一緒に書きたい人たちを考慮して、どちらの方式を取ればよいかを考えてみるといいでしょう。