見出し画像

[技術書典]初めてサークル参加する前に知っておきたかったこと

はじめに

この記事は技術書典 7に参加した筆者のやらかし・調べたことを煮詰めた何かです。ワンオペかつサークル初参加という条件で参加したため、実際のところかなり疲弊し、常に何かのトラブルと戦っていました。しかし蓋を開けてみれば、技術書典は次も参加しようと思えるほどの最高のイベントで、参加できたことを心から喜んでいます。

こんなに楽しいなら『もっと参加サークル数が増えてほしい』『もっと技術書執筆コミュニティが盛り上がってほしい』と思っています。この記事がこれから『サークル出展しようかな』と考えている人の不安を和らげたり、背中を後押しできれば幸いです。

これから、環境構築 → 執筆 → 印刷 → 当日までの準備 → 当日 → その後 でどういうことを経験し、学んだかをまとめていきます。表紙を逆に印刷するやらかし話から、環境構築といった真面目な話までいろいろ詰め込みました。どうぞ、お楽しみください。

[環境構築編] 執筆環境はRe:View

そもそも同人誌作成が初めてなので、本を書く方法を調べるところからスタートしました。当初は、自分が一番精通している道具を使いたかったので Markdown + CSS の組み合わせを考えていました。しかし、どうも技術書典の参加者は Re:VIEW というものを使っているようでしたので、Re:VIEW の技術検証を始めました。

はじめは自分に馴染みのない技術を使った挙句に時間を溶かすことを危惧していましたが、調べてみるとRe:VIEWは簡単に環境構築できそうなことがわかりました。技術検証をしてみて、Docker で執筆環境を作れること、textlint のサポートがあること、テキストの差分を git で管理できることを確認し採用しました。

公式の言葉を借りれば、Re:VIEWは "技術(書|者)のための電子・紙書籍制作ツール" です。内部では 論文の作成にもよく使われるLaTeXが使われています。LaTeX の環境構築は大変と噂に聞いていたので、その環境ごと配布されている Docker イメージを使います。

vvakame さんという方が、Docker イメージを公開しているので、それを利用しました。

まずプロジェクトを作成します。

docker run \
--rm \
-v $(pwd):/work \
vvakame/review:3.2 /bin/sh -c "cd /work && review-init tmp"

project ができたら、次のコマンドでビルドできるようになります。

docker run \
--rm \
-v $(pwd):/work \
-v $(pwd)/.texmf-var:/root/.texmf-var \
vvakame/review:3.2 /bin/sh -c "cd /work && review-pdfmaker ./config.yml"

これで book.pdf が生成されます。あとは `**.re` といった形式のファイルを作り、`config.yml` で設定し、CSS でデザインを変えることで本が書けます。

環境構築に関してはこちらの記事を参考にしました。

https://hub.docker.com/r/vvakame/review
https://www.konosumi.net/entry/2018/08/06/003542

[環境構築編] CI/CD 環境があれば便利

執筆においては CI/CD 環境も構築しました。CI/CD サーバーとして CircleCI を採用し、textlintで校閲を行い、Artifacts として pdf を吐くフローを構築しました。

CI/CD を構築した理由はいつでも執筆できるようにしたかったからです。
手元に Docker 環境がなくても、Github で直接編集して pdf を発行できるので、会社帰りに iPad だけもって執筆なんてこともできます。

私は CI/CD を回していただけなのですが、周りの方はビルド成果物を Dropbox にアップロード、さらに slack にファイルのリンクを通知なんてことまでやられている方もいらっしゃいました。

技術書典 8 ではそのような環境で私も挑もうと考えています。

[環境構築編] textlint で校閲できる

textlintはテキストファイルや Markdown ファイルの自然言語に対して lint をかけられるツールです。

いまこの文章の執筆にも使われています。

画像1

textlint は公式の言葉を借りるなら "テキスト版 ESLint" です。

そのため、eslint のように設定ファイルを通して自由にルールを追加・編集できます。それらのルールを特定の用途でまとめた preset なんかもあり、私は技術書執筆用の preset を採用して執筆を行いました。

{
 "rules": {
   "preset-ja-technical-writing": {
        "sentence-length": {                          // 1文の長さ
          "max" : 120
        },
        "max-comma": {                                // 1文中のカンマ
          "max" : 4
        },
        "max-ten": {                                  // 1文中の読点
          "max" : 4
        },
        "max-kanji-continuous-len": {                 // 連続漢字長
          "max" : 8 ,
          "allow" : ["東京特許許可局局長"]
        },
      },
   "prh": {
     "rulePaths" :["./prh/WEB+DB_PRESS.yml"]
   }
 },
 "plugins": [
   "review"
 ]
}

私が採用した preset は、 preset-ja-technical-writingという技術文書用のルールセットです。しかしルールがあまりにも厳しかったため、少しだけルールを緩めるべく上書きしています。

prhは proofread-helper と呼ばれている表記揺れチェッカーです。表記揺れチェックは textlint のルールを追加することでも可能ですが、技術書典の参加者の中では prh を使っている方が多かったので、prh を採用しました。

plugin は linter のパーサーを指定できます。linter の基本的な仕組みは、コードを AST という形式に変換し、その AST にルールスクリプトを適用することで lint を行います。textlint のデフォルト設定では markdown もしくはテキストファイルからしか AST に変換できません。そこで、Re:VIEW のファイル(*.re)から AST に変換できるようにパーサーを入れ替えたいです。その要求を満たしてくれるものがこの plugin 機構です。Re:VIEW にはtextlint-plugin-reviewという plugin があり、これを採用します。

[環境構築編] CI サーバーでの lint 結果を PR に反映させる

textlint を CI サーバーで実行したあとに、lint 結果を Github の PR に書き込む設定をします。このようにすることで、手元で linter を回さなくても lint 結果がどこからでも見れ、そしてマージ前に修正漏れを気づけるメリットがあります。

このやり方はすで解説されている記事も多いのですが、どうやら Github や外部ツールの仕様が変わっており、おそらくいま参考にしてもうまくいかないでしょう。さらに連携する CI/CD サービスが何かによっても設定方法も異なってきます。そこで 2019 年 9 月に、CircleCI にて動作を確認できた設定方法を解説します。

CircleCIから Github へ書き込むために、reviewdogというツールを使います。reviewdog は Github の token を必要とし、それはREVIEWDOG_GITHUB_API_TOKEN という名前で環境変数に登録しないといけません。この設定は Github の Developper Settingsから行いえます。

画像2

token の権限の設定では repository に対する操作を許可します。

画像3

この設定の後に払い出された token は大切に保存しましょう。

次にその token を CircleCI で該当するレポジトリの環境変数にセットします。

画像4

これで事前準備は完了しました。

次にcircle.yml を編集しましょう。

version: 2
jobs:
 build:
   docker:
     - image: vvakame/review
   steps:
     - checkout
     - run:
         name: install reviewdog
         command: "curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh| sh -s"
     - run:
         name: Build PDF
         command: rake clean pdf
         working_directory: ./
     - store_artifacts:
         path: ./book.pdf
         destination: book.pdf
     - run:
         name: Setup
         command: npm install
     - run:
         name: text lint
         command: |
           $(npm bin)/textlint -f checkstyle ./**.re \
             | ./bin/reviewdog -f=checkstyle -name=textlint -reporter=github-pr-check

ここで注意しないといけないことは 3 つあります。

まず1つ目に、CIサーバー上での reviewdog のインストール方法についてです。

"curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh| sh -s"

これを実行すると ./bin/reviewdog というバイナリファイルができます。
既存の資料によると昔は bin フォルダを作る・実行権限を割り当てるといった作業を必要としていたようですが、2019 年 9 月現在は不要でそのスクリプトを実行するだけで済みます。

2つ目に textlint の実行方法についてです。textlint は `-f checkstyle` をつけて実行します。reviewdog が解析する形式は XML 形式です。textlint のこのオプションは lint 結果を XML で吐き出してくれるものです。オプションを忘れないようにしましょう。

最後に reporter オプションについてです。reporter オプションには github-pr-check を付けましょう。付け忘れると動かないうえに、CI 上ではエラーログが見えないので、デバッグで苦労します。また公式に近しいドキュメント含め一部の解説では ci オプションを付けている例がありますが、そのオプジョンは deprecated になっており現在は使えません。(2019 年 9 月現在)

[執筆編] Re:VIEW 記法の調べ方

ドキュメントを読みましょう。公式以外も参考になります。あと困ったことがあれば、Re:VIEW ナレッジベース、もしくは Re:VIEW 本体の Issue を覗けば大体のことは解消するでしょう。

- Re:VIEW フォーマットガイド
- Re:VIEW ナレッジベース
- ReVIEW 記法 基本文法最速マスター

[執筆編] 本文を折り返せる

実際に執筆をはじめると、URL などの長い英数小文字を書くと、ページからつきぬけてしまう事象に出会うでしょう。

画像5

これは改行を入れたい箇所に、@<embed>{|latex|\allowbreak} と書くことで解決できます。

[執筆編] 画像の挿入

review の設定によりますが、デフォルトだと画像は /images フォルダに追加しなければいけません。もちろん Re:VIEW の config を設定すれば画像用フォルダも変えられます。しかしフォルダの中に新しくフォルダを作ることはできないようで、私は画像ファイル名に 章ごとにprefix をつけて整理していました。

(この対応で自分が困らなかったから深くは調べていませんが、おそらく解決する方法はあるはずです。)

[印刷編] 印刷は持ち込んだ方が良い

オンライン入稿もできますが、印刷の知識がないのであれば直接印刷所へ持ち込んだ方が良いです。スタッフの方が印刷技術の用語などを説明しながら教えてくれます。私は日光企画の御茶ノ水店でお世話になりました。平日であれば並ぶこともないでしょう。

待合室にも印刷や出版に関する本が並んでおり、退屈することはありません。

画像6

[印刷編] トンボとノンブルは必要

印刷屋に持ち込む際は、成果物にトンボとノンブルをつけないといけません。トンボとは、仕上がりサイズに断裁するために、四隅などに付ける目印のことです。ノンブルは、落丁などを検知するためにつける本のページを表す数字であり、目次やあとがきも含め全ページに対してつけられます。

画像7

トンボは Re:VIEW を使っている以上は標準で付くので心配する必要はありません。しかしノンブルは設定を加えないといけません。

おそらくそのやり方を調べると、PDF の編集ツールなどを駆使してノンブルをつけないといけないといった解説に出会うでしょうが、Re:VIEW3.2 ではその問題は解決されています。しかしこの Issue が閉じられたのも最近の話で、調べた時に出てくる情報が現環境に適しているとは限らないので注意してください。

方法はナレッジベース にもまとめられており、config.yml に 次の設定をしてください。

texdocumentclass: [ "review-jsbook", "media=print,paper=a5, hiddenfolio=nikko-pc, serial_pagination=true"]

また、各印刷屋の規格に合わせるように注意しましょう。位置調整のやり方もナレッジベースにまとめられています。

[印刷編] オフセット印刷・オンデマンド印刷とはなにか

これは印刷業界における一般的な用語で、さまざまなサイトで解説されています。
FYI: https://www.designmeishi.net/meishidatabase/difference/

端的に説明すると、オフセット印刷・オンデマンド印刷は印刷方式です。オフセット印刷は大量に印刷する場合に向いており、オンデマンド印刷は少量を短納期で印刷する場合に向いています。

私は 60 ページを 200 部印刷する予定でしたので、オフセット印刷を選びました。

[印刷編] ページ数は 4 の倍数、すくなくとも偶数にすること

製本は表裏に左右ページずつ印刷されるので 4 枚単位で印刷されます。そのためページ数が 4 の倍数でなければ、無理やり 4 の倍数とするために空白のページができてしまいます。

[印刷編] 前ペラをつけるべきか

前ペラとは表紙と本文との間に入れる、何も印刷をしない紙です。普通の紙ではなく特殊な紙が使われ、これがあると高級感が出ます。

画像8

料金を調べるときに前ペラ有無といったオプションに出会うでしょう。あまり値段は変わらないので、つけることを推奨します。仕上がりを見ると、とても嬉しい気持ちになります。

[印刷編] 白黒で印刷を行う

カラー印刷は高くつくため、白黒で印刷しました。注意しないといけないことは図も白黒になるということです。もしそのことを考えずに図を作っていれば、図の中で図形を重ねた場合に見えづらくなる可能性があります。製本後になって気づくことを避けるために、執筆の時点で一度、プリンタなどで印刷して確認しましょう。

ちなみに私はプリンタを持っていなかったため、Powerpoint の編集機能で白黒にして見ていました。

白黒にする方法はこのようなものがあります。

- CSS のフィルターを使う
- Sketch のブレンドモードを使う
- Powerpoint で図を編集する

[印刷編] 表紙と本文は別で入稿する

執筆当初、文章を Re:VIEW で書き、表紙は Sketch で書いていました。本文の先頭に表紙 PDF を貼れば良いと思っていたのですが、そのようなやり方ではできませんでした。本文 PDF とは別の形式で入稿し、表紙は別フォーマットで必要ということがわかりました。日光企画には表紙専用のフォーマットがあるのでそれを使いましょう。

FYI: 各種トンボテンプレート ダウンロード(オフセット用)

[印刷編] 表紙作成で .psd の編集 が必要になる

表紙のフォーマットは.psd 形式でした。

画像9

そのため、.psd を編集するソフトが必要になります。私はたまたま Photoshop を持っていたので、そちらで作成しました。持っていない場合は GIMPなどの free software を活用しましょう。

[印刷編] 表紙の作成範囲は印刷部数による

表紙の印刷範囲はページ数に応じて変動します。どれくらいのページ数で、印刷範囲がどれくらいになるかはフォーマットの上の方に目安がついているので確認しておきましょう。そのため表紙を作成する場合は、どれくらいのページ数になるかを先に見積もっておく必要があります。

[印刷編] 表紙には裏があり、表は右側である

まず本の表紙には裏側もあることを忘れており、入稿方法を調べる直前まで裏の表紙は何も作っていませんでした。入稿フォーマットを確認した時点で裏表紙も作りましたが、右開きと左開きを何も意識していなかったため、本の裏に表表紙がくるようなデータを入稿してしまいました。

画像10

正しくはこちらです。

画像11

ただ直接店舗に持ち込んで入稿したのでその場で指摘いただけたこと、表紙だけ後日入稿で差し替えられたため助かりました

[印刷編] チェック数から印刷数を見積もる

印刷数が多すぎると在庫を抱え損失も発生するため、当日捌ける数だけ印刷したかったです。

技術書典の公式サービスにはサークルチェックという機能があり、事前に来場者数を見積もることができます。そして印刷段階でこれくらいのチェックがあればこれくらいの人数がくるといった予想を算出するデータもあります。

#被チェック数予想で検索すると、その情報が集まります。サークルページが公開されたら、なるべく記録しておくようにしておきましょう。

また、この手の情報を公開するとその予測式の精度もあがるため、 「#被チェック数」 をタグにつけてツイートしてくれるといろんな人が助かります。

私もツイートしていました。

ちなみに私は最終チェック数が 230 で、販売冊数は 150 冊という結果でした。ブースの直帰率も計測したら面白そうです。

[印刷編] チェック数だけをあてにしてはいけない

最終チェック数を見積もれたからといって、印刷数は見積もれません。
チェック数はあくまでも 当日、ブースにくる可能性がある人の数でしかありません。実際の購入に繋がるかはその本の魅力と費用対効果によります。
気合いを入れて書きましょう。

私はチェック数以下の本しか売れていないので、本の魅力が足りなかったのだと悔やんでいます。購入された方にいまどう思われているのか少し不安な気持ちでもあります。

[印刷編] 本の原価は高いので割引を活用する

日光企画の HP を確認すると分かりますが、印刷費用は結構高いです。
私は 200 冊印刷しているのでそれだけで 50000 円近く価格がかかっています。1 冊の原価は 250 円です。

しかしこれは A5 で 50P の話であり、もっと大きいサイズ、多いページ数だともっと高くなります。近くのブースの方は原価が 700 円かかっていたとのことでした。

しかし印刷屋には入稿を早めに済ませることで割引を得られるプランがあります。それを活用しない手はないでしょう。さらに日光企画は現金で払うと 5%割引されます。私は現金を店舗に持ち込んで支払いました。

また製本には結構なお金がかかりますが、それ相応のバックアップがあるため良い買い物にはなっています。多少高くは付きますが、同人誌は紙で刷った方が良いと私は考えます。

[印刷編] DL 版を駆使した印刷をする

本の原価は高いので、数を捌きたいのであれば DL 版販売も駆使しましょう。原価 5 円で DL カードは作れます。しかし、せっかくの同人誌即売会なので、私はなるべく紙で売りたいです。また売れ行きも紙の方が良いらしいので(正確な情報かどうかは確かめていない)、私はこれからも紙をメインに売り続けます。

[当日までの準備編] 本の搬入

新刊印刷の場合は、印刷所がイベント会場まで搬送してくれます。既刊の場合は私が未経験なのでよくわからないのですが、販売委託している場合は委託先が会場まで届けてくれるサービスがあるようです。(詳しくはこちら
もし自宅に在庫を置いているのであれば、宅急便で会場まで送りましょう。技術書典ではヤマトを使って、宅配搬入できるとのことです。(詳しくは こちら

[当日までの準備編] HP の準備

本は発刊後は修正できません。そのため印刷後に誤字などを見つけたときに修正できるように正誤表をHP上に作りました。

私は GatsbyJSを使ってサクッと立ち上げました。

- パイン缶

Gatsby には remark(Markdown processor)の plugin があるため、markdown で情報を追加・編集ができ、とてもラクでした。

[当日までの準備編] DL 版の準備

私は紙で売ることを前提に参加していましたが、DL 版も販売することにしました。本をあまり刷れないので DL カードで安く済ませようという魂胆と、電子書籍派がいることを知っていたからです。DL 版は、DL カードという形で当日販売しました。

DL カードは ラクスルで作成しました。ラクスルでは、600 枚 3000 円で一枚 5 円、500 円で売れば原価率 1%というとんでもない利益率で売ることができる素晴らしいツールです。カードのデザインは Illustrator のファイルをアップロードして作れますが、オンラインにエディタがあるのでそれで完結させられます。テキストの入力、画像の貼り付け、サイズの変更といった基本的なことができるので、DL カード作成には十分な機能が揃っています。

DL カードには、表面に本の表紙、裏面に DL リンク、パスワード、サポートページの URL、連絡先を書きました。

画像12

DL URL は Booth にしました。Booth に 鍵付きのzipファイルを0 円出品し、それを DL カードに記載されたパスワードで解凍させるようにしました。しかし、この方法は検索結果の汚染になるので、快く思わない方もいらっしゃるようです。私は気づかずにやってしまいました。申し訳なかったです。

その代わりに Booth には シークレット公開機能があり、これを利用すればよいとのことでした。

[当日までの準備編] パスワードの強度は問題がないか

Booth を使わない場合でも、zip に鍵をつけて DL させる方式を採用する場合の話です。例えば他のサークルでは Google Drive にロックされた zip を上げている方もいらっしゃいました。

私はセキュリティに疎く、zip のパスワードは本当に突破されないかという心配をしていました。セキュリティ調査レポート Vol.3/パスワードの最大解読時間測定 【暗号強度別】 | サービス | ディアイティなどで調べると、実際に突破するツールはあるようです。その手法は総当たりでのパスワード解析なので、6 桁未満で英小文字しか使っていないパスワードだと 1 日もかからずに突破されます。そのため 10 文字程度で英数字と記号を混ぜると良いでしょう。パスワードは openssl コマンドで生成できます。

$ openssl rand -base64 10
QbPy+bItT0t25k=

[当日までの準備編] 設営に使うものを準備する

技術書典 開催前に準備しておくといいものという記事を参考にして以下のものを購入しました。

硬いアクリルファイル: 中にポスターを入れておける。たてかければ当日のお品書きとして飾れる。

画像13

たてかけるやつ: 上のアクリルファイルをたてかけるために利用します。

画像14

スタンド: 本をたてかけるために利用します。

画像15

価格表: 価格やメッセージを書いて飾れます。

画像16

ホワイトボード: 価格やメッセージを書いて飾れます。

画像17

コインケース: お釣りのやりとりが楽です。

画像18

これらは全部ダイソーで手に入ります。

これらを設営するとこんな感じになります。

画像19

[当日までの準備編] テーブルクロスが必要

上の写真をみればお気づきでしょうが、設営にテーブルクロスが必要でした。黒のテーブルクロスを使っているサークルの見栄えはとてもよかったです。

[当日までの準備編] 小銭の準備

私は物理本 700 円、電子版 500 円で販売したので、1000 円札で払われた場合の準備が必要でした。私は小銭の準備を忘れていて、前日深夜に貯金箱を割りました。

[当日までの準備編] 売り上げや利益の話

本の原価ですが、私は A5・50 ページほどの本を 200 冊刷って 50,000 円かかりました。それが 2 種類なので計 100,000 円分印刷しています。単純計算で原価は約 1 冊 250 円ほどです。

当日の価格設定は最後まで悩み、500 円、700 円、1000 円と悩みました。
赤字を出さないことを当日の目標とし、原価率が 25%-30%になる 700 円で挑みました。1/3 売れれば赤字を回避でき、700 円であれば お札を払うという心理的ハードルもないだろうと踏んだからです。

結果、合計 150 冊売れ、本の販売では利益を出すことができました。しかしサークル出展料や郵送料、設営備品料を考えると、実はトントンくらいで、次回の印刷費をまかなえるほどの利益は出ませんでした。ちなみに時給換算すると10円くらいです。

[当日までの準備編] 簡単お支払い準備の重要性

技術書典では かんたん後払いシステム があります。いわゆる QR コード決済です。このシステム、どうせ使われないだろうと思って何も登録していなかったのですが、友人の薦めで登録だけしていました。

実は、当日は 1/3 くらいがこの支払い方法でした。支払う側・受け取る側ともに楽だったので、体験としてよかったです。

支払うとこういう感じで明細が表示されます。

画像20

サークルマイページで簡単に登録できるので絶対にやっておきましょう。

画像21

[当日までの準備編] 委託手続き準備

当日の在庫は、とらのあなへ入荷申込を行えます。そこでは余った頒布物の委託販売ができます。このサービスを受けるためには事前に、とらのあなでのサークル登録が必要です。また事前申し込みフォームがサークル情報編集ページにもあるので、こちらのチェックを入れておきましょう。

画像22

[当日までの準備編] デモアプリは不要だった

実は前日まで気合いを入れてデモを作っていました。

しかし、当日は見せる場もなく、充電も難しかったのでデモはやっていません。

[当日までの準備編] 宣伝する

Twitter での宣伝が主な告知方法になるでしょう。やりすぎた宣伝はしたくなかったので、3 日 1 日のペースで進捗報告という形で宣伝をしていました。売るためには宣伝しないといけないことはわかっていたのですが、Twitter でミュートされたりすると辛いので、あまりしないようにしていました。

執筆期間中、勉強会での登壇もしましたが技術書典に関しては何も触れていません。Twitter の名前にブース番号だけ書いて、しょうもない親父ギャクでファボを稼いで露出するという戦略を取っていました。

[当日編] 拘束時間は 11:00 - 17:00、トイレとご飯は我慢

被チェック数はあったものの途中で抜けられると思い、売り子の依頼もせずに当日を迎えました。しかし、5 分に 1 回くらいはブースに立ち寄られ、立ち読みされる方もいらっしゃったので席を離れることはできませんでした。

そのためワンオペされる方は事前にご飯は買っておいた方が良いでしょう。また、トイレにも行けないので水分補給はそこそこにしておいた方が良いでしょう。私はポカリスエット 1 本だけ飲みましたが、なんとかトイレには行かずに済みました。

[当日編] 挨拶する

隣のサークルの人たちはお客さんに快く挨拶していました。私は真顔で椅子に座っていましたが、後に立ってにこやかに挨拶するようにしました。

ちょっと売れ行きが良くなった気はします。

[当日編] ちゃんと自己紹介する

当日いらしゃった方の中には 「Twitter で私のことを見たことあるよ」という方が何人かいらっしゃいました。オフラインでコミュニケーションするのが初めてなので、新鮮な話を楽しみました。当日初めましてとなる方が来ることも考慮しておいて、名札などに Twitter のアカウントを書いておいた方が良さそうでした。

[閉会後編] 台車が必要

搬入は業者が行ってくれるのですが、搬出は自身でやる必要があります。
ワンオペかつ在庫がある状態だったので、搬出には苦労しました。運営が台車を貸し出してくれますが、順番待ちが長かかったので辛かったです。
そのため台車をを自分で用意するのもありだと思いました。Amazonで 3000 円くらいで売られています。

[閉会後編] 同人誌の委託販売

イベント後には在庫本の整理をします。当日の会場には Booth、とらのあなの出張受付があり、ここから委託販売を申し込めます。

Booth は毎月 1000 円の保管料がかかります。一方でとらのあなの場合、半年は保管料がかからないので、とらのあなで委託販売を申し込みました。

このとき知った概念ですが、同人誌販売は専売か併売かというものがあります。専売かどうかで手数料が変わります。専売にして手数料率を低く抑えるか、いろんなところに出展し販路を広げるかは考えようでしょう。

私は在庫を 1 箇所に固めておきたかったのでとらのあなで専売にしました。またとらのあなは半年後に発送もしてくれるようで、ここから次の技術書典の会場に送ると良さそうです。

FYI: https://www.toranoana.jp/dojin/faq/faq_d.html

[閉会後編] 同人誌のオンライン販売

電子版に関しては Boothで出品しています。pdf をそのまま販売できるのでとても楽です。個人的には電子版の販売は Booth 一択だと思っています。
毎日 500 円ずつ買われているようで、しばらくお昼ご飯に困らないので嬉しいです。

しかし私は 1種類しかオンラインで売らず、しかもあまり宣伝しないようにしています。正直なところ、イベント後に自分の本を読み直すと、完成形じゃない気がしてきて、この状態でお金を頂くことがよくないことのように思えてきたからです。そこで技術書典 8 で完成形として売ることを心に決め、今は本当に欲しい方にしか売らないようにしています。もちろん今回購入された方には 技術書典 8 で完全版を販売する際に 700 円引きで提供する予定です。

[次回参加に向けて] ワンオペはやめる

技術書執筆の全行程をひとりでやるのは正直疲れました。執筆だけに集中できないため、本当に疲れます。

次に参加するときは、本をレビューしてくださる方・表紙をデザインしてくださる方・当日の販売を手伝ってくださる方を募集するかもしれません。

また、サークルを超えたコミュニケーションが面白そうなので、別サークルに混ぜてもらえないかなということも考えてたりもします。

どちらにせよ一人で参加するのは今回が最後です。一人で文化祭前夜の作業をするみたいな気分は結構辛いです。(といっても楽しさが優っています。)

[次回参加に向けて] 執筆者コミュニティを覗いてみる

今回の技術書典は表紙を逆に印刷しようとしたり、環境構築で詰まったり、本を執筆するにあたっての知識がなくて時間を浪費してしまった反省があります。

他の人はどうやって書いているかを聞いて回ると、サークルのメンバーには同人誌執筆を慣れている人がいたり、またそうでないサークルの方は執筆者コミュニティで学んだとのことでした。

たしかに調べてみると執筆者コミュニティなるものはあり、技術書典当日もお疲れ様会を開催したり、事前に 勉強会 を開催したり、執筆の進捗を出す会を開催しているようでした。

他にも、各サークルを紹介するというポッドキャストがあったり、技術書執筆コミュニティを盛り上げようとしている方もいらっしゃるようです。ちなみにこのポッドキャストでは、私のサークルのこともしっかりと紹介されていて嬉しかったです。

次に参加するときは、執筆者コミュニティのイベントにも参加することを検討しています。今回の技術書典で初心者が踏む過ちは踏み尽くした気もするのですが、まだまだ犯しうる過ちがありそうなので引き続き学び続けていきたいです。

技術書典、とても楽しかったので次も絶対に参加します!

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

もし支援いただけるなら、この文章に自由に価格をつけてほしいです。 次の技術書典では、「価格をつけずに顧客の希望価格で販売しよう」と目論んでいます。この運用が通用するかこの場で実験したいです。

46
Chotto Technology Ojisan
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。