2018年12月19日

同人誌を書く理由〜2年間を振り返り〜

これは、「技術同人誌 その2 Advent Calendar 2018」の19日目の記事です。

概要

ノリとイキオイで始めた同人活動が、気づけば初執筆から2年弱が経った。 最近は「なんのために同人誌を書いてるんだろう?執筆して、だから何だというんだろう?」と思うことが増えてきた。 でも、「やーめた」って思うわけではなくて、なんとなく「続けたい」かつ「続けたほうがハッピーになれる気がする」とも思っている。 その辺のもやもやの解消を目的に、この2年を振り返ってみる。



2年間の活動を振り返り

先ずはじめに、簡単に自分の活動を振り返る。

初めての寄稿が2016年の12月の冬コミ。ちょうどこの12月で2年か。

  • [C91] 初めてのAzure〜無料で始めるSQL Server とNode.js〜

    ※「Simple BLE〜素人がBLE モジュールを搭載した基板設計・ファームウエア開発・クライアント開発するのに必要だったことの全て〜」本へ寄稿。


そのあと、技術書典2〜5にてそれぞれ新刊頒布。

  • [tbf2] 初めてのAzureでNode.jsとSQL〜素人がSQL データベースへのRESTful API でのI/O を、Web 上で公開するまで〜
  • [tbf3] 初めてのWebアプリをAzureとNode.jsで〜素人がスマホ向けアプリを、ブラウザベースでWeb 上で簡単に公開するまで〜
  • [tbf4] テストで作ろう、初めてのAzureアプリ
  • [tbf5] ファイル処理スクリプトをJavaScript/TypeScript でTDD する〜Sinon.js でAPI のスタブ作成〜

それから、縁あって同人誌を底本にして2冊ほど商業出版。

  • Azure無料プランで作る!初めてのWebアプリケー ション開発
  • テスト駆動で作る!初めてのAzureアプリ

ほんの少しだけど、こちらにも書かせていただいた。

  • 技術同人誌を書こう! アウトプットのススメ

薄い本を2年で4冊。寄稿、製本版、コピー本、合同誌、即売会へサークル参加して頒布、他サークルにて委託頒布、増刷、ショップ委託販売、ネット通販委託、と振り返ってみれば一通りやってた。うん、同人誌作成は完全に理解した^1

1: 完全に理解した=チュートリアルを終えた。




同人誌を書く理由として聞えてくるもの。

一般に、「同人誌を書く/描く理由」として聞こえてくるのは次の3つだろうか^2

  1. 本を書きたいんじゃー!描きたいんじゃー!
  2. この技術(or この推し)を布教したい!
  3. 即売会のイベントに出るの、楽しい!

上記の3つは、「ふむ。確かにそれはある」とある程度は同意する。 でも、全力で肯定出来るわけじゃない^3。 一つずつ見てみる。

2: 他に「商業出版したい!売れたい!金儲けたい!」ってのもあるだろうけど、それは当方とはベクトルが異なるので、またの機会に。

3: もちろん、主となる理由は人それぞれ。Aに全力同意する人も居れば、Bに頷きまくりの人も居るだろう。私にはどれもクリティカルヒットはしないから、そのズレを検証しよう、ってのがこの記事の目的。




本を書きたいんじゃー!

表現したいものが身体の内から溢れて止まらないタイプの方の「書く理由」がコレかな。 自分の頭の中にだけあるものを、世の中に具現化したく仕方ない、そういう欲求が源泉になる方。本を書くことそのものが目的。

「山に登る理由?そこに山があるからだ」ってヤツ。

その情熱は素敵だなー、って思うけど、たぶん私の動機から一番遠い。 「山登り?んー、悪くは無いけど、私はあまり興味ないや」って思うので。




この推し技術を布教したい!

私はこの技術が好きなんだ、この技術を世の中に広めたい、仲間を増やしたい!って方の「書く理由」がコレかな。推しを布教する「手段」の1つとしての、薄い本の執筆。 同人誌を書く理由としては、一番多いのがこれじゃないだろうか?

「山に登る理由?私は××が見たいんだ、それには山登りが適してるんだ!」ってヤツ。

私の動機もコレ、、、だと思ってた。 でも1年ほどが過ぎたあたりから、なんか違うって思い始めた。 「なんか違う」は具体的には、そこまでソレ自体を私は推してるか?と疑問に思えてきたから。 熱が醒めてきた。「推し」ってのは、そんなに簡単に醒めるものではない、と思う。 だから「推しを布教したい!」は、少なくとも私の主な動機ではない、と思うようになった。 「○○を見に行かないかって? ○○は好きだけど、、、山に登ってまでは、遠慮するよ」って今はなってる。




即売会のイベントに出るの、楽しい!

同志たちと交流するのが楽しいんだ!皆で一緒に何かをするのは楽しいぞ!が「書く理由」の方も居るようだ。 仲間とコミュニケーションする場への「参加料」としての薄い本の執筆。

「山に登る理由?山頂で皆で『登ったね!』ってワイワイ打ち上げたいんだ!」ってヤツかな。

実は、この視点は次の記事を読んで気づいた。 「楽しむための通行料」(=参加料、と捉えた)という表現は面白い。

あまり自覚してなかったんだけど、「こういう本を書いたよ〜!」を 互いに持ち寄ってワイワイ交流するのは、確かに楽しい。 先日に、とある合同誌に参加して再認識にしたが、 「皆で書き上げる」という行為も、確かにワクワクした。

でも、それを原動力として書き続けられるかと言うと、、、たぶん足りない。 オマケとしてついてくるのは大歓迎。でもそれを主目的にするかと言うとNo。 「山頂で宴会? 楽しそうだけど、、、登るの大変だから遠慮するよ」って状況。

ちょいと、C95向け宣伝が通りますよ、と。

C95にて頒布予定の合同誌「ワンストップ見積もり本」に参加して、少しだけど書きました〜。 頒布場所は次です!




強くてニューゲーム、を仕掛けたいんだ!

3つの理由のどれも被る部分はあれど、「ソレだ!」って一致は見つからない。 でも振り返ってくる中で、とある欲求があったことに気づいた。 それは、 「ここが道かよ!だったら最初から示せ!つか、俺が示してやる!」 という欲求。 「こんにゃろー、こっちの道なら楽だったんじゃねーか!あの苦労はなんだったんだ。  二の舞を演じさせてたまるか!舗装して案内板を立ててやる!」 が、私が「このネタを書こう!」って思ったときの理由に一番近いと思う。

  • AzureのWeb Appの設定方法が(当時)どこにも書いてない!
  • 細けぇーことはいいから、Azure SQLの設定方法の必要最小限が知りたいんだよ!
  • 細けぇーことはいいから、お手軽にデータ記録できるWebアプリを作って公開したい!
  • テストフレームワークとモックの組み合わせ、よく分からん。とりあえず動かす方法を教えろ!

どれもこれも、当時に「記事が見当たらん^4。分厚い本はあるけど、チュートリアルはどこだ?」で困ったヤツ。だから、道案内の目的に薄い本を書いた。

もちろん自分自身が「強くてニューゲーム」出来たら一番良いけど、それは一般に叶わない。。その代わりに、自分が苦労した敵を他の人たちが楽々倒すのを見て(妄想して)、 自分が強くてニューゲームをした錯覚に陥る、、、ことが目的な気がした。

実際に、しばらくその「ネタ」をしばらく離れた後に自分の書いた薄い本を読んで、 「あー、そうそう、○○は××すると楽だったんだ」って用途に使えた。 なので、「当時にこういう本があればよかったのに!」は達成出来てたと思う。

苦労すること自体に価値は無くて、「現状では、苦労せざるを得ない」だけ、と私は思っている。 「こうやると、苦労せずに手にできますよ」って知見がどんどん増えてほしい。広まってほしい。 自分が手にしたいけど叶わないから、誰かが手にすることで代替して 「この社会の苦労を1つ潰してやったぜ!ざまーみろ!」って 満足感を得ている気がする。

4: 本当に無かったか、は分からない。でも私は辿り着けなかった。




薄い本じゃなくても良いんじゃない?

私が薄い本を書く理由が「同じ苦労の繰り返しを打破したい!知見を共有したい」 であるなら、「薄い本で無くてもよいのでは?ブログでも良いのでは?Twitterでも良いのでは?」 という疑問が湧いてくる。

それはその通り。 この「薄い本でなくても、かまわないのでは?」は、「推しを布教したい」に対しても 同じ問い掛けができると思う。 この問い掛けに対する答えとしては、高橋さんの次のツイートが「ソレだ!」って腑に落ちた。

同人誌を書かななくとも、ブログで十分なことも多いと思う。 でも「ブログだと上手くまとめられんのだ」と感じるネタもある。 そういうときに「太い帯域と高い解像度」を確保できる同人誌が選択肢になる。 そういうネタを偶々ここ2年は手にしたので、同人誌の執筆に縁があった。

ところで、そういうネタが継続する必然性は無い。 あれ?ってことは、今後に同人活動をする理由って、実は私には無い?




同人誌即売会は知見のアトラクター

そもそも論として、 「苦労の打破に至るとは限らない。なんとか辿り着いたけど、楽な道は見つからなかった」 ってことだって多い。 つまり、「書こう!」ってネタの供給は不安定。

けれども。 どこか「書き続けたいなぁ」と思っている自分が居る、気がする。 それは何を欲しているんだろう? 考えているんだけど、実はまだ結論が出ていない。

今の時点で「これかな?」と思っているのは、 「同人誌即売会では、自分が気になっている知見に触れる事が出来る、集まってくる」 こと。 これは、途切れた過去の活動(フリーソフトを作ったり、ブログを書いたり、勉強会に参加したり)と 大きく違う点に感じている。

もちろん、ブログや本屋でも「知見に触れる」こと、それを手に入れることはできる。だけど、「自分から取りに行く」必要がある。 リアルの周囲で、同じ物事について困っていて「打開しよう!」って仲間がいれば素敵だけど、 居るとは限らない。 自分一人で探し回って手に入る量と質には、たかが知れている^5。 手が届かない。リソースが足りない。間に合わない。

でも同人誌即売会では、「知見の方から集まってくる」。 リアルで薄い本を通して、著者と会話して手に入れたほうが、帯域が太いし解像度が高い。 そして、同人誌を頒布することは「こういう部分に、私は興味がある!欲している!」を 分り易く明確に広く示すこと、に等しい。 同人誌を書くなかで、自然と起承転結にまとまる。他の人からみて「求めているもの」が分かり易くなる。 すると、同じように「探している」人たちが「私の場合は、こういう方法を見つけたよ!」 って寄ってきてくれる。そこが「楽しい」のかな、と思う。

5: もちろん、一人で十分な量を見つけ出せる創り出せる方々も居るけど。




小さな内容でもイイから、薄い本を書いていこう

そうだった。「知見が集まってくる」ってのは、好きだったんだ。 大学生時代の楽しさの本質って、これだったのかもしれない。 「書こう!」ってネタに出会えるかは運次第だけど、書いてないと書き方を忘れそう。何が「楽しい」のか忘れそう(実際、忘れた、気がする)。 内容を小さくすれば、出会える確率は上がるんじゃないかな。 薄いー本だって、いい。合同誌への参加だってアリだ。

「小さくても、書く。書けば、即売会に出れる。すると、知見が集まってきてくれる。きっと楽しいよ」

せっかく「即売会」が定期開催されてるんだ、小さくても書き続けていこう。




P.S. 「薄い本」と「同人誌」の揺れを残しているはわざと。薄い本が好きなんだ。

posted by ほしまど at 23:39| Comment(0) | 日記

2018年11月08日

技術書典5へ委託&売り子で参加しましたレポート(感想とログ)

概要

技術書典5へ、サークル「Clear-mint:き24」さんの売り子として参加&委託頒布させていただいた感想。

技術書典5_頒布本とサークル参加証.jpg

技術書典2から数えて、薄い本の作成4回目。自分の中での振り返りと「記録」のための言語化(頭の外に出そう!)。 簡単に感想を述べるなら、次の3つ。

  • こういう本が当時に欲しかった!を書けたので満足♪
  • Re:VIEW環境+キンコーズ利用で、初めてのコピー本も困ることなく作成できた。
  • 頒布数は盛大に爆死した。委託頒布はサークル参加しての頒布とは別物と心得よ。

ちなみに前回の技術書典4では「頒布数、ほぼ読み通り!」とかほざいてましたね、私。ハッハー。 http://fluorite2.sblo.jp/category/4409735-1.html

なお、頒布した新刊本は次の1冊。

こういう本が当時に欲しかった!を書けたので満足♪

技術書典5への参加日程を確保した頃と前後して、 Node.js上でユニットテストするときのスタブ関数の作成周りについて、 Sinon.jsライブラリを利用して最短距離で使い方を覚える道はコレなんじゃない?って経験を偶々ゲットした。なのでそれをベースに書いてみた。

テストコード側のスタブ作成に悩んだり、そもそも何が嬉しいのだテスト駆動開発は?って疑問に思っていた過去の自分が読んだ時に 「必要最低限のテスト駆動開発をやってみる具体例はコレだ!」、 「このくらいの具体例と粒度と分量の本が読みたかった!」 って思える薄い本に仕上げられたと思う。 当時に「このライブラリって何?目的は?」など疑問を思ったところも含めて書けたので、満足♪

後半の「TypeScriptをやってみよう!」はオマケ的な位置づけ、、、 の割にはページ数を食われたけど、気になりつつも手を出せてなかった TypeScriptをやってみれたので、手を出して良かった。 初めてやるときは、このくらいの「ついで」で取り組むのも良いと思う。

Re:VIEW+キンコーズで、執筆以外へのコストは最低限に

今回がサークル参加ではなくて委託参加となった理由は「1ヶ月前を切るまで日程が確保できなかった」から。 実際、参加を決めたのは3週間前で、薄い本を書き始めたのは2週間前。 そんなギリギリの日程だったこともあって、製本版だと締め切りが間に合いそうになかったので、「せっかくなら」ってことで初めて『コピー本』を作成してみた。

そんな余裕のない日程だったけれど、「Re:VIEWで書いてキンコーズで刷る」の組み合わせで48Pコピー本、なんとかなった。「執筆以外のこと」へ割くリソースは大分少なくて済んだかなー、と感じた。出力形式や印刷時の配置、ホチキスの仕方、などを考えなくて済んだ。もちろんこれは、「過去にRe:VIEWで一度薄い本を書いた(環境がある)」という前提があるので、一般には当てはまらないかもだが。

Re:VIEWの良いところって、前回の感想でも書いたけど「見た目に拘らないなら、使い勝手良い」ってところだと思う。 今回も、先ずは文章もコードも区別なくテキストエディタでダーッと書いた。テキストだから端末を問わずに入力できるし。半分くらい?できた時点から、Re:VIEWの記法に乗っ取って章タイトルをマーキングして、引用コードをマーキングして、装飾しながら残りの文章を書いていった。

原稿が書きあがったのはイベントの前々日で、その日にキンコーズさんへ行って刷った。キンコーズさんの「セルフ製本」機能、初めての私でもあっという間にコピー本に仕上げられた。凄い! ・・・ただし、「ギリギリまで執筆でOK」はもう止めましょう(理由は後述)

頒布数は盛大に爆死した。

頒布数に関しては、今回は盛大に爆死した。

※ここの内容は、note.muに書いた次の2つの記事とほぼ同じ。

頒布数の結果報告

新刊50部持ち込んで、頒布数が7部。これを「爆死」と呼ばずして何と呼ぶ? 技術書典4の時の既刊も若干数持って行ったんだけど、こっちも盛大に爆死。

具体的には次の結果だった。

持ち込み数 頒布数
新刊コピー本 50部 7部
既刊 10部 1部

今回得た知見は→ 「委託頒布は、サークル参加での頒布とは大分勝手が違う。ゼロベースで計画せよ」。

コピー本だったので、実際のコスト観点での爆死具合が製本版に比べれば軽かった、のが不幸中の幸い。 勉強になった。

なんで爆死したのか?

初めて経験する「委託」へのリスク検討が甘かった。 今回に初めての要素は以下。

  • 委託頒布(Notサークル参加)
  • ポスター無し
  • 製本版では無くコピー本

売り子で入らせていただいたサークルさんで委託頒布したんだけど、自分でサークルを持つ場合と比較して以下の点が違った。

  • 被チェック数が見えないので、フィードバックを得られない。
  • ジャンルが違う場所に配置されるので、人の流れが違う。
  • 告知の手段が限られる。

配置される場所は大切。人の流れがやっぱ大分違う。 ポスター無し、って要素も「ここにこんな本がありますよ」ってのを伝える観点からだいぶマイナス。 テーブルの上の展示だけど通路の両端を歩いている人からしか見えないけど、ポスターを立てておくと、通路の中央からでも見えるから。

コピー本を今回に初めて作ってみて分かったんだけど、これ「保管づらい」。 製本版と比較して、積み上げた時に安定しないし、取り出すときもだいぶ気を付けないとすぐ曲がってしまう。 したがって製本版のように「在庫になったら、別の機会(別イベント、店頭委託など)に出せば良いし」という発想は止めた方が良さそう。出来ないわけじゃないけど。コピー本の委託を引き受けてくれたCOMIC ZINさん、マジで感謝!

そんなわけで、次回にコピー本する場合の部数は絞りに絞る予定。 もし次回も池袋会場なら、近くにキンコーズがあるからその場で増刷も出来る気配だし。

過去の数字に基づいて振り返ってみる

過去の技術書典2〜4の公式発表のサークル参加数と来場者数の数値を拾ってみると以下のようになっていた。

これをもとに過去の当方の「サークル当たりの来場数に対する、頒布係数」を乱暴に求めてみると、「×4.1」だった。

技術書典5に対しては、以下のように見積もってた(んだけど、過去との比較してなかった※1)。

  • 来場者数:10,000人(±2,000人:予測値)
  • 参加サークル数:500(概算値)

したがって、「自サークル」で且つ「製本版」の場合の頒布予想数は「82部(±16)」。 あー、ちゃんと計算してみるもんだなぁ。フィーリングで「ざっくり頒布数は80部くらい?」とか決めちゃだめだ(※1)。 ・・・キンコーズで刷ってる途中で「この紙の量はアカン気がする。やっぱ頒布数は50部に抑えよう」と 考え直した俺の第六感、良い仕事した!ギリギリ致命傷で済んだぜー。

委託の場合の見積もりは?

82部予測を2種類に単純に振り分けて考えると、「委託であること」「コピー本であること」の影響度は次のように見積もればよいのかなぁ?1サンプルしかないから気休め程度だけど。

  • 自サークルではない:×0.02〜0.17
    • (既刊の製本版が1部、新刊コピー本が7部)
  • コピー本である: ⇒影響は考える必要は無い。
    • (むしろ上振れした?でも新刊としての分もあるか)

コピー本であること、は頒布数に関しては考慮する必要がなさげ。 保管のしづらさだけ考慮すれば良さそうだ。 委託頒布の場合は、「自サークルでの頒布数の0.2〜2.0割弱」程度と考えることにしよう。

頒布数の決定には余裕をもって、平常な精神状態で行おう。

振り返ってみると、「何故に私は、80部で行ける!と当初に考えたの?」と不思議でしかない。 思い当たるところはあって、、、「イベント数日前はテンションが変だった」から、かな。 そんな状況でイベント日の前々日に部数キメて刷った。 締め切りもイベントも一緒に迫ってくる。 そりゃー、変なテンションに飲まれても不思議じゃない。 だから「フィーリングで、ざっくり頒布数は80部くらい?」とか決めちゃうのだ(※1のところ)。 ・・・これは、印刷所への入稿でも同じかもね? いくら割り増しすればギリギリまで執筆できる、とは言え、そういうテンションで部数を決めちゃ、少なくとも素人はダメだ。 きっとたぶん。

その他の要因について

今回の考察は「同じコンセプトなら、係数は変わらん」という前提に基づいている。 実際のところはある程度は異なるし、今回の薄い本では前回までと比較して「需要は凄く狭い」という自覚があった。 自分では気に入っているけど、これを欲するエリアに居る人は少ないだろう、って思ってた(通過点だと思うので)。 なので、その分も係数に入れるべきかもしれない。今回は考慮してないけど。

他の外的要因として、「客層が変わった」というのはあると思う。 正確には 「サークル数が大きすぎて事前チェックも当日のリアルタイムチェックも、全数はしきれない。なので、買う側の行動パターンが変わった(変わらざるを得ない)」 と言うべきかもしれない。 これの影響度は不明。だれか「それっぽく」推しはかれる方、居たりしますか?

全体としての感想

頒布数の観点では爆死して悲しみ(・_;)、なのだけれど。 でもイベント参加自体には「満足感」を抱いているのが、自分でも不思議。 新刊コピー本は、自分で読み返して「私はこういう本が欲しい!」と思えるものが書けたし、 購入した本も「読むのが楽しみ」(未だ1冊も読めてないのはヒミツでw)と思えるものをGet出来た。

ただ、、、TLの戦利品報告を見ていて「え、そんな本もあったのか?!」と思う率は、前回よりも高いかなぁ。 母数が多いので絶対値が上がっただけかもしれないが。あと、 会場内での移動が大変で「見えてるんだけど辿り着けない・・・」で消耗した。。。(o - _-)o

最後に、「キンコーズでコピー本作成ならギリギリまで執筆出来るぜ!」は止めましょう。 これ重要。ダメ、絶対。

なんにせよ、イベント自体は楽しかった。 技術書典5を開催してくれた運営の方々、足を運んでくださった方々、 薄い本を手に取ってくれた方々、打ち上げ含めてF2Fで話せた方々、ありがとうございました!

技術書典5_撤収後.jpg.jpg
posted by ほしまど at 12:52| Comment(0) | 日記

2018年05月05日

技術書典4へサークル参加しましたレポート(感想とログ)

概要

技術書典4へサークル参加(か19:Fluorite)した感想。
技術書典2から数えて、薄い本の作成3回目。 自分の中での振り返りと「記録」のための言語化(頭の外に出そう)。簡単に感想を述べるなら次の3つ。
  • 自分の中でのモヤモヤを言語化出来てスッキリ♪
  • Re:VIEW、使い勝手良いじゃん!
  • 雑感とログ(頒布数とか)
tbf04_display.jpg

なお、頒布&販売した本は次の2冊。

公式Webページのサークルページはこちら。

頒布した同人誌「テストで作ろう初めてのAzureアプリ」のサポートページはこちら。

自分の中でのモヤモヤに「名前を付けてやる!」できた!

技術書典4への参加はギリギリまで迷ったのだが、 「Node.jsでのテストコードの入門書が欲しいけど見つからない。よし書こう!」 と結論づけて、参加を申し込んだ。

「TDD(テスト駆動開発)、、、あたりの大層な事に手を付ける前に、テストコードって素敵じゃん!を実感したいじゃないですか」 がモチベーション。 今感想を書きながら振り返って気付いたが、 「こちらメモ書き記事に肉付けした」って内容に成っているのが面白い。

Mochaを使ったユニットテストベースのコーディングっていいよね、を伝えたいメモ

以前からもやもやと思っていた事、今なら言語化出来ていて、この2つなんだろうなと思う。

  • なんで「テストコード」を「素敵」って感じるんだろうなー?
  • テストコードに初めて触れる人には「面倒」って言われるのはなんでかなー?

このもやもやに対して、今回に薄い本の新刊 「テストで作ろう初めてのAzureアプリ」 を書く中で 「テストコードは、仕様書のように書けるんですよ!が伝わらないから」 って言語化が出来た。 スッキリできて嬉しい。

非公式打ち上げで、 「テストコードは、仕様書のように書けるんですよねー。ってことが分かりにくいですよね」 という意見を頂いて、「それだ!」って思えたのも良かった。 打ち上げで、同じ考えを持った方を見つけられたの、嬉しい!

技術書典4にサークル参加を決めてよかった。 サークル参加しなかったら、言語化できなかったし、「それだ!」とも思えなかっただろうから。

Re:VIEW、使い勝手良いじゃん!

今回の薄い本作成では、前回と前々回までの「LaTex」利用から「RE:VIEW」利用に鞍替えしてみた。感想としては「見た目に拘らないなら、使い勝手良い」。

先ず「ザザーっとテキストで書いて」、後から「見た目を装飾していく(図やコード、節を参照させる)」進め方が気に入った。装飾の仕方(マークダウン)も 覚える事少ない ので苦労しないし、VSCode+プラグインならインテリセンス効くし。 「とりあえず書ける。その時点で製本した場合のレイアウト(箇条書きとか)も、だいたい分る(コンパイルできる)」って良い。 プレーンテキストだから、差分も取りやすい。

TechBoosterさんのRe:VIEW本あたりに「技術書なんだから、見た目なんて些事ですよ。読むのに苦労しないならOKです」(だいぶ意訳) って記載があったと思うのだが、それを心の中で唱えながら書いた。 「書き切る」ってこと自体が目標になる人には(=私)、テキストで書ける&後から装飾できる「Re:VIEW」をお勧めしたい。

欲を言うなら、これをベースに「アドバンスドモード(もっと自由にレイアウト可能)」とか あると良いのかなー、思った。 一定以上に見た目を拘り始めると、途端に扱いが難しくなる(というか無理×_×)、とは思った。

当日のリソースの配分はミスった。

当日に関しては、リソースの時間配分をミスった。 前回、前々回とも「 15時過ぎたら空いた 」ので、それを前提にリソース配分してんだけど、完全に読みを外した(×_×)。 「あれ?まだ混雑してる・・・」の戸惑いのまま16時半を過ぎてた。そして終了の17時を迎えた。

とりあえず、頒布開始と同時に気になっていたサークルを回って買って、 後からもう一回サークルに足を運んで、作者に話を聞きたい、 15時以降の空いて来たころに買った薄い本をザザッと読んでから、、、 などと計画くしてたのだが、最初の「頒布開始と同時に」以外は全く回れず。話せず。残念。 「あとからブラブラ立ち読みして、気になった本を追加で買おう」 も全くできず。『晴れの技術書典』を甘く見てた。。。 (非公式打ち上げで、他のサークル参加者と話せたのは良かった)

前回、前々回に比べると、時間中の忙しさとピーク混雑は緩和されてて、サークルに足を運んでくれた方々と話せた率は高かったのは楽しかった♪ でも、「混雑は緩和」された割にはトータルでは疲労感が多かったかなぁ。混雑の平均値が高い&持続時間が長かったせいかもしれない。

まだ解は見つからないんだけど、次回の参加時はもう少し他のサークルを回る時間を取れるようにしたいねぇ。

その他、雑感。

次回へ向けた検討事項などのメモ。

作成過程が〆切重なってキツかった。

インプレスR&Dさんから、技術書典2で頒布した薄い本「初めてのAzureでNode.jsとSQL」について 「商業化しませんか?」とありがたくも声を掛けていただいていたんだけど、実は商業版では「3/1くらい書き下ろし」してる。 なので、技術書典4へ向けて 2つの締切

  • 薄い本の新刊「テストで作ろう初めてのAzureアプリ」
  • 商業版「Azure無料プランで作る!初めてのWebアプリケーション開発」への追加書き下ろし

が、ほぼ同時に走ったのはキツかった。 新刊2本とか書き下ろす方、尊敬するわ。。。

もうちょっと書きたいことがあったんだけど、調べてる時間を確保できずに、当初の内容からはいくつか章を削った。残念。

タイトルの検討が不足

今回の新刊のタイトルは「テストで作ろう初めてのAzureアプリ」と したのだけれど、これはもう少し分りやすい表現があったんじゃないかなー、と終えてから思った。これも未だ解は見つけてないのだけれど。

サークルに足を運んでくれた方々のうち複数の方から「あれ、初めての自動テス本は?」って言われた。サークルカットには「初めての自動テスト」って書いてたので、そことの乖離には気づかなかった。本の趣旨としては、「初めての自動テスト、、、を実際にAzureで公開できるWebアプリ作成でやってみよう!」(具体例が欲しい)だったので、こういうタイトルにしたんだけど、分りにくいかったかもしれない。

頒布数はほぼ読み通り!(※運です)

薄い本の新刊は、110部ほど頒布して30部をCOMIC ZINさんに委託。 前回は、160部ほど頒布して30部をCOMIC ZINさんに委託。薄い本頒布の経験を重ねてる方々からは「少し委託するくらいでちょうど良い部数」と聞いているので、ちょうどよい比率かな。

前回の技術書典3では200部を刷ったのだれど、

  • 他のサークル参加者の被チェック数との相対値
  • 他のサークル参加者の被チェック数の伸び率との相対値

が「・・・なんだか前回とは違う?」と感じたので、150部にした。結果としては正解♪

ただし、定量的に見積もった場合はさっぱり相関が見えない。 試しに、前回と前々回と合わせて当サークルの被チェック数をグラフにしてみたんだけど(自分のツイートから拾った)、被チェック数自体の途中値と最終値の相関はバラバラに見える。

被チェック数20180422.png

ついでに、最終的な「被チェック数」と「実際の頒布数」も次の通りでバラバラに見える。なので部数を「読み切った!」のは完全に「運です」ね。

最終チェック数 実際の頒布数
技術書典2 113     100(※1)
技術書典3 82 150
技術書典4 181 110

※1:13時ごろに完売のため実際の需要は不明

被チェック数だけじゃなくて、実際の来場者数やその分野への関心度もパラメータな気がする。 なお、来場者数だけ取り出しても、それとの直接相関も見えないね( 3400:3100:6300 )

この辺の分析は、公式さんのレポートに期待!。

なお、商業誌(初!)の新刊「Azure無料プランで作る!初めてのWebアプリケーション開発」は29部(※2)を準備して、14時頃に29部完売御礼♪ ありがとうございました!

※2:この部数は、同人誌の新刊と合わせて200部手前、、、という辺りで決めた。

最後に

最後に、というか雑感の続き。

書くのはツラかったけど、「言語化出来た」ってのはやっぱ楽しい。 そして、当日足を運んでくれた方々とF2Fで話せるのは、楽しい♪ 「技術書」を目的とした来場者数がメッチャ多いので、「需要なんか知らん。私がココを知りたいんだ」で書いた本でもなんとか黒字に出来るのありがたい!(赤字だと継続モチベーションがキツイ)。参加のハードルが低い、って大切だと思うんだ。

来てくださった方々、本を手に取ってくださった方々、技術書典4イベントを開催してくれた方々、ありがとうございました!

posted by ほしまど at 14:57| Comment(0) | 日記