イベント駆動のスケジュールの立て方
技術系同人誌を作るときも、普段の業務と同じように「納期」が存在します。
技術系同人誌では、頒布するイベント、特に年2回のコミックマーケットの開催日が、納期となります。この納期に向けて、頒布物を確実に作りあげるためにどのようなスケジュールを立てるのか。そのために、何を優先すればよいのかを紹介していきます。
スコープをできるだけ可変にする
技術系同人誌を作っていく上で必要な要素は何があるのでしょう。アジャイル開発の実践的な解説書『アジャイルサムライ』のなかで紹介されている「トレードオフ・スライダー」を使って整理してみました。
| 時間 | MAX ←■―――――――→ MIN | コミケの日がリリース日です。リスケはできません。コミケのサークル参加に申し込んだ瞬間から、納期順守が求められます。 |
|---|---|---|
| スコープ | MAX ←――■―――――→ MIN | コミケの日までに、頒布物を用意する必要があります。ですが、原稿の本数やページ数は自由に調整できます。この調整の仕方を以降で紹介していきます。 |
| 品質 | MAX ←――――■―――→ MIN | 頂いた原稿が読みにくい場合は調整する必要があると考えます。ですが、それよりもコンテンツの量と質を確保したいですね。 |
| 予算 | MAX ←――――――■―→ MIN | 同人誌はあくまで趣味の領域といえますので、自分たちが持ち出しでできる範囲で納めればいいと思います。ほとんど気にする必要はないでしょう。 |
コミックマーケットは年2回。毎年お盆の時期と年末に開催されます。
このコミックマーケット開催日に「リリースできませんでした」となるのが最悪の展開です。DevLOVE Pubでは、この最悪の事態を回避するために、可能な限りスコープを可変にしていきました。
最大の関心事は「初稿書き上げ」
同人誌をリリースするまでには、以下のような作業が必要になります。
- 参加申し込み
- 全体計画
- スケジューリング
- 初稿書き上げ
- 修正・体裁整え
- 納品物作成
このなかで、リリースするために必要で、一番時間がかかるのは初稿書き上げです。
DevLOVE Pubも、これから同人誌を書こうという皆さんも、普段の業務に追われていることと思います。そうした中で、いつまでなら初稿書き上げを引き伸ばせるか。初稿書き上げまでにかかる負荷をどれだけ落とせるかが、最大の関心事となります。
この関心事に対し、DevLOVE Pubでは以下のような仕組みを作りました。
納品物を落とさないアーキテクチャ
DevLOVE Pubでは、下記の3つに取り組むことで、継続的なリリースを実現してきました。
- 原稿を上げやすくする
- 執筆者をSPOF（単一障害点）にしない
- 初稿書き上げ後の工程省力化
原稿を上げやすくする
これを実現するため、DevLOVE Pubでは以下のような自由な設計にしています。
記事ボリュームを自由にした
DevLOVE Pubでは執筆者ひとりひとりに対し、目標となるページ数を設定していません。各コンテンツのページ量は2ページから30ページ超まであります。
総ページ数を変動可能にした
電子書籍の同人誌の場合、ページ数に対するかかるコストの影響がありません。そのためDevLOVE Pubでは総ページ数を気にする必要がなくなりました。
スケーラブルな画像サイズ
電子書籍の場合、ビューワの画面サイズがまちまちです。ですが、この問題は原稿を電子書籍化する段階で自動調整できてしまいます。
執筆者をSPOF（単一障害点）にしない
執筆者が4～5人を超えると、1人が原稿を落としたとしても、残りの原稿量が十分であれば、リリースできます。そのため、各自のパートが抜けたとしても、全体としてはリリースに影響がない執筆体制を組むことで継続的なリリースが実現できます。
DevLOVE Pubでは、これまで以下のような執筆体制で同人誌制作に取り組んできました。
- 毎回5～7名程度の執筆体制を組んでいました。そのなかで1～2人は原稿を落としていたものの、無事リリースできています。
- 毎回の構成は10ページを超える大規模記事1～2本＋コラム程度の小規模記事2～3本になっています。総ページ数は30ページ以上を確保してきました。
- 毎回2～3名程度の執筆者が、新技術のチュートリアルや検証記事といった大規模記事に取り組んできました。そのうちの1人は大規模記事の執筆を断念して、小規模記事に切り替えるということもよく起きます。それでも、小規模記事に切り替えることで、原稿を落とさずに済んでいます。
こうした執筆体制を組むことで、DevLOVE Pubでは納品物を落とさずに同人誌制作を続けることができました。
初稿書き上げ後の工程省力化
DevLOVE Pubは昨年夏のコミックマーケットに参加した際、執筆者全員の初稿書き上げが開催日の4日前となりました。残りの3日間で修正・体裁整え～納品物作成という後工程を行う必要があります。
DevLOVE Pubではこの工程で「誤字脱字等の訂正」「レイアウトの修正」のみを行っています。また、納品物もディスクなどの物理媒体を用意していません。実データをクラウド上に配置し、買っていただいた方のみにダウンロードして頂くようにしています。
こうした、後工程の省力化を行うことで、初稿書き上げまでに待てる時間を最大限に引き伸ばしてきました。
まとめ
同人誌執筆は不確定に対してどう向き合うかの世界です。そのため、書きたい内容に合わせたチームをいかにして作っていくかが大事だと考えます。
今回の記事では、技術系同人誌の企画の作り方とイベント駆動のスケジュールの立て方について取り上げました。
前半では「技術系同人誌の企画の作り方」として、扱う技術要素を決める場合と決めない場合のメリット・デメリットについて解説しました。まとめると、以下の表のようになります。
| メリット | デメリット | |
|---|---|---|
| 扱う技術要素を決める | 扱う技術要素が決まっているため執筆しやすい | ネタが枯渇しやすい |
| 扱う技術要素を決めない | 好きな技術要素、トレンドの技術要素を扱いやすい | 毎回扱う技術要素を考える必要があるため執筆しにくい |
後半では「イベント駆動のスケジュールの立て方」として、執筆者それぞれの初稿書き上げ時期を引き伸ばすために、DevLOVE Pubでは以下の3つの手段を使っていることを紹介しました。
初稿書き上げを引き伸ばすための3つの手段
- 原稿を上げやすくする
- 執筆者をSPOF（単一障害点）にしない
- 初稿書き上げ後の工程省力化
同人誌を出すと言っても、ただ原稿を書くだけではだめで、企画作りやスケジューリングといった作業も必要になります。一見難しそうに思えますが、実際は普段の業務でやっている「要件定義」や「チームビルディング」、「マネジメント」といったいくつもの技術を、趣味の領域で楽しく発揮すればいいと思っています。
また、初回から全てうまくいくこともないでしょう。繰り返し同人誌制作を行う中で、チームもプロセスも洗練されていくものです。執筆する楽しさに集中するために、その他の苦労の芽を先に取り除いてしまいましょう。
次回は、「電子書籍出版に必要な技術」と題し、執筆者から頂いた原稿を電子書籍に仕上げるための方法を紹介します。企画作りやスケジューリングといった話題ではなく、より手を動かせる領域の話ができるといいなと思っています。
