概要
技術書典４へサークル参加（か１９：Fluorite）した感想。技術書典２から数えて、薄い本の作成3回目。 自分の中での振り返りと「記録」のための言語化（頭の外に出そう）。簡単に感想を述べるなら次の３つ。
- 自分の中でのモヤモヤを言語化出来てスッキリ♪
- Re:VIEW、使い勝手良いじゃん！
- 雑感とログ（頒布数とか）
なお、頒布＆販売した本は次の2冊。
- 同人誌：テストで作ろう初めてのAzureアプリ
- 商業誌：Azure無料プランで作る！初めてのWebアプリケーション開発
公式Webページのサークルページはこちら。
頒布した同人誌「テストで作ろう初めてのAzureアプリ」のサポートページはこちら。
自分の中でのモヤモヤに「名前を付けてやる！」できた！
技術書典４への参加はギリギリまで迷ったのだが、 「Node.jsでのテストコードの入門書が欲しいけど見つからない。よし書こう！」 と結論づけて、参加を申し込んだ。
「TDD（テスト駆動開発）、、、あたりの大層な事に手を付ける前に、テストコードって素敵じゃん！を実感したいじゃないですか」 がモチベーション。 今感想を書きながら振り返って気付いたが、 「こちらメモ書き記事に肉付けした」って内容に成っているのが面白い。
『Mochaを使ったユニットテストベースのコーディングっていいよね、を伝えたいメモ』
以前からもやもやと思っていた事、今なら言語化出来ていて、この２つなんだろうなと思う。
- なんで「テストコード」を「素敵」って感じるんだろうなー？
- テストコードに初めて触れる人には「面倒」って言われるのはなんでかなー？
このもやもやに対して、今回に薄い本の新刊 「テストで作ろう初めてのAzureアプリ」 を書く中で 「テストコードは、仕様書のように書けるんですよ！が伝わらないから」 って言語化が出来た。 スッキリできて嬉しい。
非公式打ち上げで、 「テストコードは、仕様書のように書けるんですよねー。ってことが分かりにくいですよね」 という意見を頂いて、「それだ！」って思えたのも良かった。 打ち上げで、同じ考えを持った方を見つけられたの、嬉しい！
技術書典４にサークル参加を決めてよかった。 サークル参加しなかったら、言語化できなかったし、「それだ！」とも思えなかっただろうから。
Re:VIEW、使い勝手良いじゃん！
今回の薄い本作成では、前回と前々回までの「LaTex」利用から「RE:VIEW」利用に鞍替えしてみた。感想としては「見た目に拘らないなら、使い勝手良い」。
先ず「ザザーっとテキストで書いて」、後から「見た目を装飾していく（図やコード、節を参照させる）」進め方が気に入った。装飾の仕方（マークダウン）も 覚える事少ない ので苦労しないし、VSCode＋プラグインならインテリセンス効くし。 「とりあえず書ける。その時点で製本した場合のレイアウト（箇条書きとか）も、だいたい分る（コンパイルできる）」って良い。 プレーンテキストだから、差分も取りやすい。
TechBoosterさんのRe:VIEW本あたりに「技術書なんだから、見た目なんて些事ですよ。読むのに苦労しないならOKです」（だいぶ意訳） って記載があったと思うのだが、それを心の中で唱えながら書いた。 「書き切る」ってこと自体が目標になる人には（＝私）、テキストで書ける＆後から装飾できる「Re:VIEW」をお勧めしたい。
欲を言うなら、これをベースに「アドバンスドモード（もっと自由にレイアウト可能）」とか あると良いのかなー、思った。 一定以上に見た目を拘り始めると、途端に扱いが難しくなる（というか無理×_×）、とは思った。
当日のリソースの配分はミスった。
当日に関しては、リソースの時間配分をミスった。 前回、前々回とも「 15時過ぎたら空いた 」ので、それを前提にリソース配分してんだけど、完全に読みを外した（×_×）。 「あれ？まだ混雑してる・・・」の戸惑いのまま16時半を過ぎてた。そして終了の17時を迎えた。
とりあえず、頒布開始と同時に気になっていたサークルを回って買って、 後からもう一回サークルに足を運んで、作者に話を聞きたい、 15時以降の空いて来たころに買った薄い本をザザッと読んでから、、、 などと計画くしてたのだが、最初の「頒布開始と同時に」以外は全く回れず。話せず。残念。 「あとからブラブラ立ち読みして、気になった本を追加で買おう」 も全くできず。『晴れの技術書典』を甘く見てた。。。 （非公式打ち上げで、他のサークル参加者と話せたのは良かった）
前回、前々回に比べると、時間中の忙しさとピーク混雑は緩和されてて、サークルに足を運んでくれた方々と話せた率は高かったのは楽しかった♪ でも、「混雑は緩和」された割にはトータルでは疲労感が多かったかなぁ。混雑の平均値が高い＆持続時間が長かったせいかもしれない。
まだ解は見つからないんだけど、次回の参加時はもう少し他のサークルを回る時間を取れるようにしたいねぇ。
その他、雑感。
次回へ向けた検討事項などのメモ。
作成過程が〆切重なってキツかった。
インプレスR＆Dさんから、技術書典２で頒布した薄い本「初めてのAzureでNode.jsとSQL」について 「商業化しませんか？」とありがたくも声を掛けていただいていたんだけど、実は商業版では「3/1くらい書き下ろし」してる。 なので、技術書典４へ向けて ２つの締切
- 薄い本の新刊「テストで作ろう初めてのAzureアプリ」
- 商業版「Azure無料プランで作る！初めてのWebアプリケーション開発」への追加書き下ろし
が、ほぼ同時に走ったのはキツかった。 新刊２本とか書き下ろす方、尊敬するわ。。。
もうちょっと書きたいことがあったんだけど、調べてる時間を確保できずに、当初の内容からはいくつか章を削った。残念。
タイトルの検討が不足
今回の新刊のタイトルは「テストで作ろう初めてのAzureアプリ」と したのだけれど、これはもう少し分りやすい表現があったんじゃないかなー、と終えてから思った。これも未だ解は見つけてないのだけれど。
サークルに足を運んでくれた方々のうち複数の方から「あれ、初めての自動テス本は？」って言われた。サークルカットには「初めての自動テスト」って書いてたので、そことの乖離には気づかなかった。本の趣旨としては、「初めての自動テスト、、、を実際にAzureで公開できるWebアプリ作成でやってみよう！」（具体例が欲しい）だったので、こういうタイトルにしたんだけど、分りにくいかったかもしれない。
頒布数はほぼ読み通り！（※運です）
薄い本の新刊は、110部ほど頒布して30部をCOMIC ZINさんに委託。 前回は、160部ほど頒布して30部をCOMIC ZINさんに委託。薄い本頒布の経験を重ねてる方々からは「少し委託するくらいでちょうど良い部数」と聞いているので、ちょうどよい比率かな。
前回の技術書典３では200部を刷ったのだれど、
- 他のサークル参加者の被チェック数との相対値
- 他のサークル参加者の被チェック数の伸び率との相対値
が「・・・なんだか前回とは違う？」と感じたので、150部にした。結果としては正解♪
ただし、定量的に見積もった場合はさっぱり相関が見えない。 試しに、前回と前々回と合わせて当サークルの被チェック数をグラフにしてみたんだけど（自分のツイートから拾った）、被チェック数自体の途中値と最終値の相関はバラバラに見える。
ついでに、最終的な「被チェック数」と「実際の頒布数」も次の通りでバラバラに見える。なので部数を「読み切った！」のは完全に「運です」ね。
| 最終チェック数 | 実際の頒布数 | |
|---|---|---|
| 技術書典２ | 113 | 100（※１） |
| 技術書典３ | 82 | 150 |
| 技術書典４ | 181 | 110 |
※１：13時ごろに完売のため実際の需要は不明
被チェック数だけじゃなくて、実際の来場者数やその分野への関心度もパラメータな気がする。 なお、来場者数だけ取り出しても、それとの直接相関も見えないね( 3400：3100：6300 )
この辺の分析は、公式さんのレポートに期待！。
なお、商業誌（初！）の新刊「Azure無料プランで作る！初めてのWebアプリケーション開発」は29部（※２）を準備して、14時頃に29部完売御礼♪ ありがとうございました！
※２：この部数は、同人誌の新刊と合わせて200部手前、、、という辺りで決めた。
最後に
最後に、というか雑感の続き。
書くのはツラかったけど、「言語化出来た」ってのはやっぱ楽しい。 そして、当日足を運んでくれた方々とF2Fで話せるのは、楽しい♪ 「技術書」を目的とした来場者数がメッチャ多いので、「需要なんか知らん。私がココを知りたいんだ」で書いた本でもなんとか黒字に出来るのありがたい！（赤字だと継続モチベーションがキツイ）。参加のハードルが低い、って大切だと思うんだ。
来てくださった方々、本を手に取ってくださった方々、技術書典４イベントを開催してくれた方々、ありがとうございました！
