がみぶろ

#がみぶろ

@jumpei_ikegami

エンジニア勉強会で間違った情報を発表してもいいのか？WeJSで考えるコミュニティの価値と運営

f:id:jumpei_ikegami:20181219070822p:plain

こんにちは、gamiです。

この記事は『We Are JavaScripters!【執筆初心者歓迎】 Advent Calendar 2018』の18日目の記事です。

adventar.org

今年は僕が書いたサイ本についてのブログ記事がバズったりしました。

jumpei-ikegami.hatenablog.com

なのでJavaScript自体のことを書いてもよいのですが、せっかくWe Are JavaScripters!（以下、WeJS）も2周年を迎えたことなので、WeJSから考えるコミュニティの在り方みたいなことを書きたいと思います。

僕とWeJS

最初に自分語りをします。

たみー in セブ

僕は「新卒のときに就活で都庁の公務員採用試験しか受けずに爆死する」という若気の至りによって、大学卒業後に1年間フリーター生活をしていました。

その人生最後？のモラトリアム期間で、「留学というものをしてみよう」と思い立ち、セブ島に英語留学に行きました。

選んだのは、NexSeedという「エンジニア留学と英語留学が一緒にできる」という触れ込みの語学学校でした。 nexseed.net

そこにはフィリピン人講師だけではなく学校運営メンバーもいて、学校を運営しているギークス株式会社からもインターンが何人か来ていました。 geechs.com

その中の1人が、WeJSの創始者であるたみー(@ta__miyan)でした。

学校に通う日本人生徒は基本的に同じ寮に住むのですが、寮と学校との間は「ジプニー」という乗合タクシーで移動します。

ジープニー - Wikipedia

たみーはジプニー担当で、毎日学校にジプニーが到着する度に「ジプニー！ジプニー！」と生徒に呼びかけていました。 5時のジプニーが来た時は、「5時プニー！5時プニー！」とも言っていたような気がします。

超ドメスティック思考だった当時の僕は、「海外まで来てインターンをする凄い人がいるもんだ」と感動していました。

初めてのWeJS

フリーター生活の末に富士通という会社に入社しCOBOLを書いていた僕は、なんと1.5年で会社を辞めてWebエンジニアとしてベンチャーに転職しました。 （最近、その経緯を書いたブログが「1.5年で何がわかんの？」とプチ炎上しました） jumpei-ikegami.hatenablog.com

転職先はNode.jsとVue.jsをメインで使っているPLAIDという会社で、転職当初は必死にJavaScriptを勉強していました。

また、しがないラジオというポッドキャストを富士通同期の@zuckey_17と一緒に始めることになり、そのネタ作りや宣伝のために、「勉強会というものに行ってみよう」という気運が高まっていました。

そんなとき、Twitterか何かでWeJSの情報が流れてきて、「初心者向けのJS勉強会とか最高かよ」と思って詳しく調べました。 主催者をよく見てみると「これ、ジプニー使いのたみーさんでは？」と気付き、その偶然に驚きながら、気づくとconnpassの参加申し込みボタンを押していました。

最初に参加したのは、今から1年半以上前、2017/3/11の休日もくもく会でした。 ポッドキャストの相方である@zuckey_17も一緒で、なんならしがないラジオep.1の収録をした、まさにその日の午後でした。

wajs.connpass.com

今思うと、いきなりもくもく会から参加するのも変な感じですが、変な内輪ノリとかも無くとても居心地よく作業できました。 すでに主催者に加わっていたふかみん@fukamiiiiinmin)さんが、@zuckey_17にReact.jsについて質問をしにきて、「説明マジでわかりやすいっすね！お金取れますよ！！！」とハイテンションで言っていたのが印象的でした。端的に言って、「コミュ力おばけ」でした。

今思い返すと、初参加の私たちに気を使って話をしにきてくれたのかもしれません。

WeJSとの1.5年間

そこからは、「毎回参加するわけでもないが暇だったら行く」くらいのゆるーい参加者として、3ヶ月に一回以上は参加していたような気がします。

登壇も、WeJS@10thで1回だけしました。

speakerdeck.com

継続的に参加している勉強会はWeJSしかなかったのですが、 「勉強会に何度も参加していると主催者や常連と顔見知りになってさらに楽しくなる」という気づきを得られました。

また、最近では僕が窓口になって弊社PLAIDのオフィス@GINZA SIXを会場としてWeJSに提供することもあります。 wajs.connpass.com

WeJSでエンジニアコミュニティについて学べたと思っているので、少しでもその恩返しができていれば嬉しいなあと思います。

WeJSで考えるコミュニティ運営

WeJSを外から見ていたり主催者のみなさんから話を聞いて、コミュニティ運営について考えたことを書きます。 完全に外部の立場から勝手に言ってるだけなので、私見です。

「マルサン・コミュニティの法則」とWeJS

コミュニティ・アクセラレーターの河原あずさんという方がいるのですが、その人がブログに「マルサン・コミュニティの法則」というコミュニティ運営の法則を書いています。

azkawahara.hatenablog.com

要約すると、「コミュニティ・ベースからイベントに動員する人数比を、『コア:常連:新人』で1:1:1にすると、コミュニティが育ちやすい」ということらしいです。 特にWeJSでは「初心者歓迎LT大会」を標榜しているので、一定割合を「新人」に保つというのが重要な気がします。

ここはWeJS主催者側でも意識しているようで、2018年1月からは「ビギナー登壇枠」を設けて、登壇3回未満の人が優先的に登壇しやすいように参加枠の設計をしています。

2年もコミュニティが続き、常連さんもかなり増えている印象ですが、同時に新しい人の登壇も良く見るので、この辺りのバランスは流石だなといつも思っています。

WeJSの裏にある思想

WeJSの歴代主催者4人にはしがないラジオというポッドキャストにゲスト出演していただいているのですが、清水(@chikoski)さんが出演回で話されていたことがすごく印象的でした。

勝手にまとめると以下です。

  • コミュニティは書籍と違って、正確で体系的な知識を与えてくれるわけではない
  • コミュニティの存在意義を、「安定した状態のモノに対して外部から刺激を与えること」に置きたい
  • 「何を言ってもいい状況」を維持することで、コミュニティの中で様々な刺激が得られる

WeJSでは「マサカリ」（登壇者に対して技術的な指摘を強めにすること）を禁止し、「安心して発信できる環境」を大切にしているそうです。 この点は、WeJSの「アンチハラスメントポリシー」にも明記されています。

極端な話をすると、コミュニティでは「間違った情報を登壇者が話す」ということがあっても、その現象自体が刺激になれば許容されるべきとも言えます。 もちろん、参加者の今後の学習のために軽く指摘した方がいいことはあるでしょう。 しかし、「なぜ間違った情報を信じてしまったのか？」ということを題材にして、議論が深まったり、新しい課題が見つかったりすれば、それは1つのコミュニティにとっての価値でしょう。

こうした「様々な刺激が得られる」環境を維持するためには、先ほどの「マルサン・コミュニティの法則」で言った「一定割合を新人に保つ」ということも重要に思えます。 常に同じ人が参加し続けていると、似た考え方や知識量の人が増えていき、一参加者が得られる刺激としては減っていきます。 そこに全く新しい視点を持ち込むためには、コミュニティにとって異質な「新人」を温かく迎え入れ、内部に取り込んでいく必要があります。

「WeJSというコミュニティはどんな価値を提供すべきか？」という思想が背景にあって、それを実現するための運営ポリシーがあるからこそ、WeJSはみんなに長く愛されるコミュニティになっているのだなあと、強く感じます。

宣伝

散々WeJSを持ち上げたところで、宣伝です。

前述のように、WeJSの歴代主催者4人には、僕がパーソナリティの1人をしている「しがないラジオ」というポッドキャストにゲスト出演していただいています！ コミュニティ運営の裏話なども聴けるので、ぜひ各種ポッドキャストアプリで聴いてみてください。

富士通SEを1.5年務めて辞めた結果、得られた3つの手札

こんにちは、gamiです。 この記事は、楽しかった職場　みんなのF2 Advent Calendar 2018 - Adventarの9日目の記事です。

僕は文系卒で2015年4月に富士通に入社してから公共系SEになり、2016年11月に退職して当時40人規模のベンチャーにWebエンジニアとして飛び込みました。 今は楽しくて仕方がない仕事生活をしています。

また、その経験を活かして「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という燃えそうなタイトルのポッドキャストをやっています。 略して「しがないラジオ」といいます。

テーマ

以下を書きます。

富士通に入った理由

富士通に入った理由は、主に以下の2つです。

  • もともと公務員志望で、公共系システムの開発に関わりたかった
  • ITスキルという自分の専門性を獲得したかった

いま思うと、その両方は富士通で満たすことができたので、感謝しかありません。

富士通を辞めた理由

富士通を辞めた理由は、主に以下の2つです。

  • 本音で生きられない環境だった

「社長-本部長-事業部長-部長-マネージャー-平社員-パートナー」という身分制度がしっかりしている会社だったので、「平社員」の身分を超えた発言や活躍ができないのが今思うと辛かったです。 特に仕事のでき不出来が身分と完全に相関している訳ではなかったので、「仕事もできないのに出世してる人」への不満みたいなものが社内に見え隠れしている感じはありました。 もちろん尊敬する先輩や上司もいましたが、彼らもまた完全に本音では生きられないように見えたので、それもまた辛かったです。

  • 開発手法や技術が古すぎて、エンジニアとしての価値が上がらないと感じた

とあるきっかけでRebuildという神Tech系ポッドキャストを聴き始めたのですが、そこで話されている技術的なトピックが全然わからずに衝撃を受けました。 エンジニアインターンなどはしたことがなかったので、「COBOLとJavaアプレットとか結構古そうだけど、業務での開発なんてこんなもんなのかな」と思っていましたが、全然そんなことは無かった。 プロジェクトとしても、もっと生産性の高い開発を目指すべきだと思ったし、個人としてもそういった開発に触れていないと転職できなくなると感じたので、早めに転職しました。

以上です。 もちろん、富士通は超巨大企業なので、部署によって全く別の会社のように文化が違ったりします。 そのため、たまたま僕がいた部署と僕が合わなかったというだけの話でしかありません。

なお、転職活動の経緯は、以下の記事にも書きました。

jumpei-ikegami.hatenablog.com

また、「しがないラジオ」の最初の方の回でも経緯について話していると思います。 聞いていない人は、ぜひ各種ポッドキャストアプリから聞いてください。

転職前後の違い

結果的には、富士通に1.5年だけ在籍して、当時40人のベンチャーに転職しました。 その中で働く個人として、両者の違いを考えます。

信じて任せる範囲

富士通にいた頃は、良くも悪くも「新卒1年目」として扱われ、「全てのアウトプットに誰かしらの事前・事後の承認が必要」な状態でした。 制度や風土としても、「優秀な人には信じて任せる」というより、「どんな人が来ても最低限の仕事ができる」ことを目指した組織だったと思います。

現職は当時40人の会社だったので、純粋に「会社の一員」として迎えてもらった気がします。 また、「事前に承認を得るより、勝手にやって迷惑かけたら後から謝る方がいい」という失敗を奨励する文化だったので、「自分で勝手にissueを立てて自分で勝手に解く」みたいなことをガンガンやることができました。 これが、少なくとも僕には性に合っていたようで、とにかく仕事が楽しく、月曜日に会社に行くのが辛くなくなったのが衝撃でした。

それなりに仕事ができる個人の生産性を最大化するには、「個人を信じて、個人に任せる」ことが必要だと実感しました。

服装

富士通ではだいたいみんなスーツを着ていたので、僕もスーツを着ていました。 いま思うと、客先に行かないことがほとんどだったので、「誰のためにスーツを着ていたのだろうか？」という気持ちです。

いまは、だいたい赤いスニーカーにTシャツとパーカーで出社しています。 クライアントとの打ち合わせに同席することも多いですが、なんとそのままの格好で行っています。

働き方

富士通では、8:40出社、17:30退勤でした。 出勤時間は打刻管理され、遅刻が許されない雰囲気でした。 「朝に遅刻をしてはいけない」というプレッシャーが地味に辛く、寝過ごした日は朝一の打ち合わせなどがなくても走って出社していました。 なお、残業が多い部署もあったようですが、幸いにも僕はほとんど残業せずに18:00までには退勤していました。

いまは、前述のように「個人の生産性は個人が管理する」という思想の会社なので、フルフレックスで何時に来ても何時に帰ってもいいです。 一応10:00〜19:00が就業時間っぽい雰囲気はありますが、別に守る必要はありません。 また、リモートワークも自由なので、1人でできる作業をするときは家でやったりもしています。 「少し朝に洗濯してから行こうかなー」みたいなことが気軽にできるのは、生活のストレスが減ってすごくいいです。

給与

富士通の当時の年収と比べると、今の年収はだいぶ高いです。

富士通では、少なくとも入社数年は全員給料が同じ（正確にいうと、学部卒と院卒では初期の給料が違う）です。 そこからは職位とともに上がっていくと思いますが、職位自体がだいたい足並み揃えて上がる印象なので、そんなに給料の差がつきにくい会社だと思います。 僕は給与にそこまで関心が高くないのであれですが、純粋に給料だけを考えれば、「平均以上に優秀な人は損をし続ける」制度だったと思います。

富士通にいたことで得られた3つの手札

富士通に入社したことを後悔しているかというと、全くそんなことはありません。 以下の3つの手札を得られて、その先の活動の幅が広がったと感じるからです。

  • エンジニアと名乗るのに最低限必要な「ITスキル」

転職後しばらくはゴリゴリのWebアプリケーション開発をしていましたが、割とキャッチアップは早かったと思います。

  • 「大企業」の組織構造を体験したこと

まだまだ日本の経済活動の多くは「大企業」が回していると思いますが、その裏側を身をもって体験できたのはとても良かったです。 最近、学生のキャリア相談に乗ることがありましたが、「大企業とベンチャー」という比較軸で実体験を話せるのは結構ありがたがられました。

  • 「SIer出身」という属性

「SIerと自社Webサービス開発」の2つを経験しているという属性があるからこそできることがあると強く感じています。 一番有名な活動としては、冒頭に書いた「しがないラジオ」というポッドキャストを配信しています。今では初対面の人に「しがないラジオのgamiさんですよね？」と言われることがあるくらいに広まっています。 ポッドキャストではゲストの方を呼んで色々なテーマで話すのですが、キャリアの話、特に「SIer論」みたいな話が話題になることが多いです。 このようなテーマについて話せる最低限の経験ができたことは、とてもよかったと思っています。

このテーマを煮詰めて実用的に固めた、「完全SIer脱出マニュアル」という同人誌も書いたりしました。

jumpei-ikegami.hatenablog.com

仕事や趣味を問わず、個人としてのアウトプットは「いかに自分の尖った手札を増やして、それを組み合わせるか」がとても重要だと考えています。 その意味で、「エンジニアである」とか「大企業に新卒で入った」とか「SIerでCOBOLで開発をしていた」などの属性を手札として獲得できたことで、アウトプットの幅は格段に広がりました。

まとめ

富士通には、ITスキルという専門性が欲しくて入社しました。 富士通は同期も多く研修も手厚いので、新卒で入る会社としては最高でした。 ただ、たまたま僕が配属された場所は、そこから成長していこうと思ったときにスピードが出ない予感がしたのですぐに辞めてしまいました。

富士通に入る決断も辞める決断も、どちらも後悔はしていません。 逆にいうと、それを後悔しなくても済むように、その経験を自分個人のカードとしてうまく利用している節があります。 もしこの記事を読んでいる富士通の若手社員に偉そうにアドバイスを垂れ流すとしたら、「キャリアの選択肢を広げるための『カード』を今の仕事で獲得し続けられるか？」という視点で振り返ってみるといいと思います。

ちなみに、そのためには今とは違う可能性についても知る必要があるので、「転職」をするかどうかに関わらず、「転職活動」をしてみるのがおすすめです。

【保存版】 #技術書典 初出展マニュアル【表紙入稿データサンプル付き】

f:id:jumpei_ikegami:20180922182207p:plain

gami(@jumpei_ikegami)と申します。 2018年10月8日に開催された「技術書典5」で、『完全SIer脱出マニュアル』という本を頒布しました。

jumpei-ikegami.hatenablog.com

技術書典とは、技術書オンリー同人誌即売会です。

技術書典

僕が所属するサークル「しがないラジオ」は、 技術書典へのサークル参加はおろか、同人誌を作ること自体が初めてでした。 なんとか無事に入稿も終え、当日を迎えることができました。

しかし、正直に言って、同人誌作りのノウハウはインターネット上にまだまだ足りないと思います。 特に入稿作業にまつわる細かい情報について、 印刷用語や入稿の方法など重要なことはかなり調べないと出てこない印象でした。

そこで、僕たちのような「初の同人誌作りで技術書典への初出展を目指す人」に向けて、 同人誌の入稿や当日運営に必要な「ミニマムの作業」を、実際のスケジュールも含めて全て公開します。 このブログ記事を読んで、技術書典の出展に対する不安がなくなったら、 ぜひサークル申し込みをしてみましょう。

前提

基本的には僕が体験したことしか語れないので、この記事は以下の前提のもとに書かれています。

  • 印刷所は日光企画さんを利用する
  • オフセット印刷フルカラーセット（後述）で、特別な装丁は無し
  • 以下の形式で頒布する
    • 技術書典5当日
      • 物理本（B5）
      • ダウンロードカード
    • それ以降
      • PDF版のネット販売
  • 作業環境

事情が異なる人は、 適宜読み替えてください。

技術書典5までのスケジュール

技術書典4当日から技術書典5当日までの詳細スケジュールです。 細かいです。

  • 下線がある部分は、弊サークルがやった作業
  • 全て2018年の出来事
日付 n日前 出来事
04/22 169日前 技術書典4当日！
06/20 110日前 技術書典5開催決定&サークル申込受付開始
07/19 81日前 サークル申込受付終了
08/01 68日前 当落発表
08/05 64日前 「技術書をかこう！ ～はじめてのRe:VIEW～」購入
08/09 60日前 執筆環境の構築完了
08/12 57日前 表紙デザイン依頼
08/17 52日前 サークル配置決定
08/19 50日前 表紙案の完成
08/20 49日前 第1章の草稿が完成
08/24 45日前 サークルカットデザイン依頼
08/29 40日前 サークルカットデータ完成
08/30 39日前 日光企画が入稿締切日を公開
08/31 38日前 カタログ用サークルカット締切
09/04 34日前 第2章の草稿が完成
09/09 29日前 入稿プランを決定
09/10 28日前 一般参加者向けウェブサイト公開
09/16 22日前 本編全ての草稿が完成
09/17 21日前 本編の校正作業が終了 & 表紙データ仮完成
09/20 18日前 ページ数の確定 & 表紙データ完成
09/21 17日前 付録の草稿が完成
09/22 16日前 20%OFF締切 & 怒涛の入稿日！
10/01 7日前 ダウンロードカードの入稿
10/02 6日前 通常料金締切
10/03 5日前 10%UP締切
10/04 4日前 15%UP締切
10/05 3日前 20%UP締切
10/06 2日前 直前準備
10/08 0日前 技術書典5当日！

以下の作業は、もうちょっと早くやった方がよかったです。

  • 草稿の執筆（がんばるしかない）
  • サークルカットデザイン依頼（デザイナーさんすいません。。。）
  • ダウンロードカードの入稿（早ければ早いほど安心）

なお、技術書典の公式的な告知については、だいたい「技術書典公式ブログ」で公開されています。 実際の内容が見たい場合は、ぜひ技術書典公式ブログの過去記事を読んでください。

知らなかったけど実は重要だった情報

最初の時点で知っておいた方がよかった「意外な事実」について紹介します。

  • 物理本を印刷する場合、ダウンロードカードのみに比べて難易度が10倍くらいになる
    • でも、紙の本を作って売るの楽しい
  • 印刷用の本文入稿データは、ページ数を4の倍数にする必要がある
    • つまり、最後にページ数の調整が必要
  • ページ数が確定できないと、表紙データも確定できない
    • つまり、ページ数が締切ギリギリに確定すると、表紙データの修正も締切ギリギリになる
  • 初めての入稿はWebではなく店舗で直接やった方が、その場で紙や印刷方法の実物を確認できて良い

どれも物理本に関わる部分です。紙の印刷を思い通りに行うのは結構めんどくさいですが、技術書典当日に段ボールを開けるときの感動はなにものにも代え難いので、ぜひがんばってみてください。

「技術書典」初出展マニュアル

それでは、作業の詳細について弊サークルの実際の時系列で述べていきます。 たぶん長くなるので、作業フェーズに合わせて気長に読んでください。

169日前: 技術書典4当日！

技術書典4が開催されました。 僕は一般参加者として参加しました。 技術書典自体が初参加だったので、その活気に衝撃を受けました。

知り合いも何人か本を出していたので、 次回はサークル側で参加したいなあとぼんやり考えました。

110日前: 技術書典5開催決定&サークル申込受付開始

技術書典5の開催が決定され、同時にサークル申込受付が開始されました。

blog.techbookfest.org

全ての手続きは、技術書典公式サイト内で完結します。 何を書くか決まっていませんでしたが、とりあえず申し込みました。

81日前: サークル申込受付終了

開始から1ヶ月経つと、サークル申込期間が終了します。

68日前: 当落発表

出展可能サークル数に対して希望数の方が多かった場合は、抽選になります。 技術書典5では会場が広くなったこともあって、あまり落選の話は聞かなかった印象です。

64日前: 「技術書をかこう！ ～はじめてのRe:VIEW～」購入

技術同人誌の書き方を全く知らなかったので、技術書典を主催するTechBoosterさんの同人誌を買いました。 この本が無ければ、僕は同人誌をここまでトラブル無く頒布できなかったでしょう。 というわけで、ぜひ入手することをおすすめします。

techbooster.booth.pm

のちに気付きましたが、この本をビルドするためのデータは全てGitHubで公開されています。 自分でビルド環境を整えたあかつきには、普通に本のコンテンツをPDF形式で読めます。

github.com

ただし、お布施の意味でBOOTHで購入するのも良いと思います。

60日前: 執筆環境の構築完了

入稿用PDFのビルド環境を整備

最低限の執筆環境を整えます。 実施した作業としては以下です。（もしかしたら不要な作業があるかもしれませんが、まあ気にしない）

$ git clone git@github.com:TechBooster/C89-FirstStepReVIEW-v2.git
$ mv C89-FirstStepReVIEW-v2/ REPO_NAME/ # REPO_NAMEは適宜変える
$ cd REPO_NAME
$ rm -rf .git/
$ git init
  • vvakame/docker-reviewでビルドできるように、プロジェクト直下に以下のRakefileを保存する
    • 別にコマンド実行できればpackage.jsonのscriptsでもなんでもいい
$ touch Rakefile

desc 'build pdf'
task :pdf do
  sh <<~"EOF"
    docker run \
    --rm \
    -v `pwd`:/work \
    vvakame/review:latest /bin/sh -c "cd /work/articles && review-pdfmaker config.yml"
  EOF
end
  • 以下を実行し、PDFがビルドできることを確認
    • うまくいくと、/articles直下にPDFが生成される
$ rake pdf
  • 以下を全て削除する
    • /articles/*.re
      • 章別のコンテンツファイル
    • /articles/images/*
      • コンテンツ内に挿入する画像
  • /articles/catalog.ymlから、削除した*.reファイルの指定を削除する
    • あとで実際のコンテンツを追加していく
  • /articles/config.ymlを書き換える
    • 書き換える箇所は、たぶん以下（内容は適宜変えてください）
bookname: escape_from_sier
booktitle: 完全SIer脱出マニュアル〜『しがないラジオ』と学ぶ、転職して楽しく働くための7つのステップ〜
aut: ["jumpei_ikegami","zuckey_17"]
edt: ["jumpei_ikegami"]
pbl: しがないラジオ プロジェクト
date: 2018-10-8
history: [["2018-10-8 技術書典5版 v1.0.0"]]
rights: (C) 2018 しがないラジオ プロジェクト

  • 気になるようであれば、不要なファイルを削除する

    • PDFの生成だけなら、以下は要らないはず
      • /Gruntfile.js
      • /articles/*.scss、/articles/*.css

  • commit & push

$ git add -A
$ git commit -m 'initial commit'
$ git remote add origin git@github.com:ACCOUNT_NAME/REPO_NAME.git # ACCOUNT_NAMEとREPO_NAMEは適宜変える
$ git push -u origin master
  • CI環境とかは、まあ無くても何とかなる

執筆フロー

上記作業が完了したら、とりあえず執筆作業を始められます。

まずは、Re:VIEW記法をなんとなく覚えます。

github.com

見出し、箇条書き（ol、ul）、リンク、画像辺りを覚えれば最初は十分です。

執筆フローは、大まかに以下です。

  • 新しい章を書き始めるときには、ブランチを切って/articles/xxx.reファイルを新規作成する
  • 章のコンテンツをそのreファイルにRe:VIEW記法で記述する
  • /articles/catalog.ymlに、その章に対応するreファイル名を追加する
  • rake pdfでビルドして、出力を確かめる
  • 必要なら、PR作ってレビューを依頼する

編集作業は最後にやるので、まずはコンテンツの量を稼ぐことを考えます。

ちなみに、/articles/config.ymlでいじった記憶がある設定値は、以下の2項目です。

# 目次として抽出する見出しレベル
toclevel: 2
# 本文でセクション番号を表示する見出しレベル
secnolevel: 3

57日前: 表紙デザイン依頼

Adobe IllustratorやPhotoshopが自分では使えない場合は、 表紙と裏表紙のデザインを誰かに依頼します。 僕は偶然にも婚約者さんがデザインできる人だったので助かりました。

日光企画で印刷する場合は、最終的には以下の「表紙用トンボテンプレート（B5判・PSD形式）」を使って作成することになります。

【トンボダウンロード】オフセット用

ちなみに、デザイナーさんにお願いする可能性のある制作物は、全体を通して以下です。 僕はPOPや値札だけ自分で作りました。

デザイナーさんにお願いする可能性のある制作物

  • 物理本の表紙+裏表紙データ（.psdなど）
  • PDF版の表紙/裏表紙データ（.jpgなど）
    • 物理本と違って、表紙と裏表紙を別ファイルにする
    • 背表紙は無し
  • ダウンロードカードの印刷データ（.aiなど）
  • サークルカット（.png）
  • 当日設営に必要な印刷物（.pdfなど）
    • ポスター
    • POPや値札

52日前: サークル配置決定

サークルの配置が決定します。 特にこの時点で配置を意識することは無いです。

気が向いたら、Twitterの表示名に配置番号を入れましょう。 僕は技術書典期間中はgami お27『完全SIer脱出マニュアル』@技術書典5さんになりました。

50日前: 表紙案の完成

表紙案がデザイナーからいくつか上がってきたので、良さそうなやつを選んで軽く幅出ししてもらいます。

49日前: 第1章の草稿が完成

時間を見つけて、原稿も進めます。

45日前: サークルカットデザイン依頼

「サークルカット」のデザインを依頼します。 サークルカットとは、技術書典のサークルリストやカタログに掲載されるサムネイル的な画像です。 普通にPNGファイルなので、自分で作ってもいいです。

f:id:jumpei_ikegami:20181007200612p:plain

docs.circle.ms

  • 画像をダウンロードして、サイズを変えずに上書きする
  • 左上の枠は配置番号、右上はサークル名を書く（たぶん）
  • Web用（カラー）、カタログ印刷用（グレースケール）の2種類用意

40日前: サークルカットデータ完成

サークルカットの画像データが完成したら、技術書典のマイページで2種類とも登録します。

ついでに、書く内容も固まった頃だと思うので、「頒布情報」も埋めておきます。 頒布情報には、同人誌に関する以下のような情報を登録します。

  • 書名
  • 概要（1,000文字まで）
  • ページ数
  • 頒布価格
  • 頒布予定数
  • 関連URL（最大4つ）
  • 頒布物について説明する画像（最大4枚）

いつでも編集できるので、未定の項目は決まり次第登録します。

39日前: 日光企画が入稿締切日を公開

これも同人誌文化らしいですが、印刷所毎に、「このイベント向けに同人誌を印刷するなら、いつまでに入稿してくださいねー」という締切が設定されます。 印刷のプランによって違いますが、通常締切はだいたいイベントの1週間前くらいです。

なお、通常締切より早く入稿すると割引になったり、遅く入稿すると割増になったりします。 早く入稿できれば部数によっては数万円単位で安くなるので、できれば早割りを狙っていきましょう。

38日前: カタログサークルカット締切

カタログ用のサークルカット（グレースケールの方）が締め切られます。 つまり、この時点のサークルカットでカタログが印刷されます。 間に合わなかった場合はデフォルト画像になるので、頑張りましょう。

なお、Web版のサークルリストはこれ以降も編集できます。

34日前: 第2章の草稿が完成

全体の1/3くらいの草稿が書き上がりました。

29日前: 入稿プランを確定

日光企画のWebサイトとにらめっこしながら、入稿プランを確定しました。 サイトには色々書いてありますが、オフセットなら「スタンダードフルカラーセットB5」というやつにすればいいです。 名前的に本文もカラーかと誤解しがちですが、表紙がフルカラーなだけで本文はグレースケールです。

プランが決定したら、目指す入稿締切日を決めます。 僕らはイベント16日前入稿の「20%OFF」を目指すことを宣言しました。

なお、日光企画さんが「にこぷり」というサービスでWeb見積もりができます。

日光企画 にこぷり.com

入稿自体は店舗で実施するのでここでの手続きは不要ですが、何となくどんな設定値があるのかを見ておくと良いでしょう。 入稿時には、ざっくりと下記項目を決めることになります。

  • オフセット/オンデマンド
  • プラン（スタンダードフルカラー）
  • 表紙の用紙、印刷方法、PP貼り（表面の加工方法みたいなやつ）
  • 本文の用紙、印刷方法
  • トジ方法、トジ方向
    • オフセットで横書きなら、普通は「平トジ/左トジ」
  • ページ数、発行部数

用紙などは店舗で実物を確かめながら選べるので、ここで決める必要は無いです。

ちなみにこの日は「本編の草稿を完成させるぞ」という意気込みで1日中カフェに籠りました。 実際の草稿完成はその7日後のことでした。 えてして、自分の作業見積もりは甘くなりがちです。

28日前: 一般参加者向けウェブサイト公開

一般参加者向けに、ウェブサイトが公開されます。

特に重要なのは、「サークルリストが一般公開される」ということです。 参加者はサークルリストを眺めて、どのサークルの本を買おうか吟味します。 つまり、この一般参加者向けウェブサイト公開までにサークルカットや頒布情報などを充実させておくことで、より広い人に興味をもってもらえるようになります。

この日までには、自サークルの情報をちゃんと技術書典のサイトに登録しましょう。

22日前: 本編全ての草稿が完成

本編の草稿が書き終わりました。 めっちゃ疲れた。

21日前: 本編の校正作業が終了

以下を無くすために、校正作業をしました。

  • 誤字・脱字
  • 表記揺れ
  • 不適切な表現やわかりにくい表現

また最初から読み直して、「全体を通じた表現や論旨の一貫性」を向上するための修正をガシガシ加えていきます。

PCで作業をしてもいいですが、なぜか人間は紙に印刷した文章の方が校正能力が上がる気がします。 アナログですが、印刷した草稿に赤ペンを入れていくのがおすすめです。

21日前: 表紙データ仮完成

表紙データが仮完成しました。 「仮」と言っているのは、ページ数が確定するまでは背表紙の幅が決まらないからです。

「表紙データ」とは、正確に言うと「表紙+背表紙+裏表紙」が合わさったPSD形式のデータです。 そして考えれば当たり前ですが、「背表紙」は本の厚さに応じてその幅が変わります。 つまり、本文のページ数が決まらない限りは、表紙データを確定させることができないのです（！）

f:id:jumpei_ikegami:20181007205715p:plain

18日前: ページ数の確定 & 表紙データ完成

締切2日前にして、まだ付録原稿ができていませんでした。 しかし、デザイナーの作業可能時間を考えると、ページ数を確定させて表紙データをfixさせる必要がありました。 ページ数自体は後で調整が聞くので、「えいや」で表紙込み100ページに確定させました。

背表紙の幅（背幅）の計算方法は、以下です。

  • 表紙込みページ数 * 本文用紙の厚さ

「表紙込みページ数」とは、紙の枚数ではなく、言葉通り「ページ数」です。 たとえば『完全SIer脱出マニュアル』は本文のページ番号が96までありましたが、そのときの表紙込みページ数は「表紙+表紙裏+裏表紙+裏表紙裏」の4ページを足して、100ページです。

「本文用紙の厚さ」は紙の種類に依ります。こだわらなければ日光企画さんの「上質90kg」になるので、0.063mmです。 各紙の厚さは、日光企画さんのトンボテンプレートのページに記載があります。

つまり、表紙込み100ページの場合、背幅は6.3mmです。 これをデザイナーに伝えて、表紙データをfixしました。 「レイヤーの統合」や「文字のアウトライン化」を忘れずにしてもらいましょう。

実際に日光企画で入稿実績のあるPSDファイルを公開するので、参考にしてください。

「完全SIer脱出マニュアル」表紙データ

17日前: 付録の草稿が完成

入稿〆切前日に付録の草稿が完成しました。 あとは付録の校正と、全体の編集作業を完了して、入稿するだけです。

16日前: 20%OFF締切 & 怒涛の入稿日！

いよいよ、自分たちで設定した入稿締切日です。 本日の18:00までに日光企画お茶の水店に原稿を持ち込めば、20%OFFを勝ち取れます。

最後の編集作業

入稿前に、最終校正を実施します。 全体を通じた表記揺れをエディタで一括置換したりしました。

参考までに、僕が置換した表記揺れは以下でした。

最も重要な作業は、ページ数の調整です。 印刷の都合上、ページ数を4の倍数に調整する必要があります。

僕たちは本文ページ数を96ページに設定したのですが、この時点ではページ数が足りませんでした。 読みやすさの観点も踏まえて、以下の方法で水増ししました。

  • コラムの挿入
  • 改ページの挿入

コラムを挿入するには、以下を記述します。

====[column] コラムのタイトル

コラムの本文

====[/column]

改ページを挿入するには、以下を記述します。

//embed[latex]{
\clearpage
//}

PDFをビルドし、ページ数が問題なくなれば、以下を実施します。

  • フォントの埋め込み
  • PDF/X形式への変換

PDF/X形式への変換については、「技術書をかこう！ ～はじめてのRe:VIEW～」に詳しく書いてあるのでそちらをご覧ください。 この本にあるように、PDF/Xの出力にはAdobe Acrobat Pro DCが必要です。 無料体験版でも特に問題ありません。

「フォントの埋め込み」についても書かれていますが、vvakame/docker-reviewがデフォルトでやってくれていました。神。

入稿

本文データ（PDF/X）と表紙データ（PSD）をUSBメモリに入れて、日光企画お茶の水店さんに行きました。

店舗に行く

日光企画お茶の水店さんは同人グッズの工房も提供していて、同人誌入稿窓口と同じ場所にあります。 わいわい同人グッズを作っている人達の横で、「同人誌の入稿に来ました」と告げましょう。

  • 予約は不要です
    • 唐突に来店しても、優しく対応してくれます
    • 営業日や営業時間は結構変則的なので、必ず公式ホームページで確認しましょう
  • 所要時間は約30分間でした
    • 僕は14:15に行って、14:40には手続きを終えて外に出ました
  • その間に同人誌入稿の手続きをしていた人は僕だけでした。割と空いてる

印刷申込書の記入

作成する同人誌について、店員さんがヒアリングしながらテキパキと「印刷申込書」を埋めてくれます。 連絡先とイベント情報だけは、店員さんがデータチェックをしている間にこちらで記入しました。

印刷申込書に記載される内容は、以下でした。

  • 全般
    • 書籍タイトル: 完全SIer脱出マニュアル
    • サイズ: B5
    • 表紙込みページ数: 100ページ
    • 印刷部数: 200冊
    • トジ方向: 左トジ
    • トジ種類: 平トジ（固定）
  • 表紙
    • 用紙: NPホワイト200kg
    • PP加工: マット加工
    • 作成環境（表紙）: MacでIllustrator→PSD出力
    • 作成環境（本文）: PDF/X
  • 本文
    • 用紙: 上質90kg
    • 作成環境: MacでPDF/X出力
  • 搬入
    • イベント名: 技術書典5
    • 会場名: 池袋サンシャインシティ2F展示ホールD
    • スペースNo: お27
    • サークル名: しがないラジオ
    • 全部搬入？: 200冊全部搬入
  • 連絡先
    • 氏名
    • 電話番号
    • メールアドレス
    • 住所
  • その他

だいたいは即答できましたが、 表紙データと本文データの作成環境については、訊かれると思っていなかったので曖昧になってしまいました。 特に深くは訊かれませんでしたが、念のためAdobe Photoshopのバージョン番号などを控えておきましょう。

窓口には紙や印刷のサンプルが置いてあり、その場で触らせてくれました。それをふまえて用紙やPP加工について決めていきます。

PP加工というのは「ポリプロピレン加工」のことで、表紙の表面をコーティングする加工方法です。 一番安いものでいいかと思っていましたが、 マット加工の艶消し感が好みだったので、その場で心変わりしました。 マット加工への変更は+5円/冊だったので、200部でも1,000円しか変わりませんでした。

表紙データは、特に何も言われず問題なし。

本文データについては、以下を指摘されました。

  • 目次や本文のリンク部分の色が、もともと赤いのをグレースケールにしたので、色が薄い
  • 目次直後のページだけ、ノンブル（ページ番号）が無い
    • 「隠しノンブルにしておきますね」と言われた。製本すると隠れる部分にページ番号を振るという意味っぽい

通常料金は8.7万円くらいでしたが、以下の割引が効いて6.3万円くらいになりました。

2.4万円の割引は破格なので、確実に利用しましょう。

なおpixivプレミアム会員特典割引は、スマホでpixivのマイページを開いてみせればOKです。 URLパスの末尾に表示されるIDを控えられます。

最後にお金を現金で払って、印刷申込書の控えと領収証を受け取って終了です。 「お客様の名前で領収証を切って大丈夫ですか？」と言われたので、会社名で発行する人もいるのかも。 最後に飴をくれました。さすが優しいと評判の日光企画さん。

なお、日光企画の技術書典5新刊では、特典でポストカード（本の発行部数と同じ枚数） or A2ポスター（1枚）が無料で印刷できたようです。 僕は当日知ったのですが、A2ポスターもお願いすればよかったと後悔しました。

f:id:jumpei_ikegami:20181008073001p:plain

7日前: ダウンロードカードの入稿

QRコードの生成

ダウンロードカードの作成にはPDF版書籍データをダウンロードできるQRコードが必要です。 僕たちはPDFに加えてポッドキャストの限定エピソードも配布したので、そっちのQRコードも生成&印刷しました。

複数ダウンロードを防ぐならシリアルコードを生成してごにょごにょやった方がいいですが、 めんどくさいので僕はGoogle Driveにアップロードして共有URLを生成しました。

URLをQRコードに変換するWebサービスはたくさんあるので、適当にQRコード画像化します。

なお、Google Drive内のデータを後から更新する場合は、必ず「同名のファイルをアップロードし、既存ファイルを上書き」します。 既存ファイルを削除してからアップロードすると、共有URLが別のものになってしまうので、QRコードがリンク切れします。 これも本来は自分が持っているドメインでDNS設定をちゃんとやった方がいいですが、まあ気にしない。

ちなみに、Google Driveは大量のリクエストが来ると一時的にダウンロード禁止になったりするので注意です。僕たちもイベント直後は一時的にダウンロード制限されたようです。

「AWSをはじめよう」のmochikoさんは、BOOTHでパスワード付きzipを無料配布し、パスワードをダウンロードカードに印刷して配布しているようです。アクセスが集中するようなら、この方法が良さそう。

mochikoastech.booth.pm

ダウンロードカードの印刷依頼

ダウンロードカード用の画像データを入稿します。 基本的には事前に自宅で受け取るので、イベント当日までに宅配を受け取れないと涙目です。なるべく早めに入稿しましょう。 もっと早くてもよかった。

ダウンロードカードを印刷する印刷所はどこでもOKです。 僕はザッと調べた限り一番安そうだった東京カラー印刷さんの名刺・ショップカード印刷を利用しました。

サイトにIllustrator形式のテンプレートがあるのでそれを利用して入稿データを作成しWeb入稿します。 文字のアウトライン化を忘れて一度差し戻しになったので、注意しましょう。

名刺サイズで1,000枚両面印刷すると、2円/枚くらいで印刷してくれて、1週間くらいで宅配されます。 100枚しか刷らないと10円/枚くらいするので、できるだけたくさん刷りましょう。

紙質は値段相応といった感じでしたが、いい感じに印刷できました。

6日前: 通常料金締切

本文データの入稿締め切りです。 なお、表紙データの通常締切は1日早かったみたいなので、注意してください。

ここから、入稿が1日遅れる毎に大幅な料金アップが始まります。 ご利用は計画的に。

  • 5日前: 10%UP締切
  • 4日前: 15%UP締切
  • 3日前: 20%UP締切

2日前: 直前準備

イベント直前の休日を使って、イベント当日の準備をしました。

電子書籍版PDFの生成

ダウンロードカードやBOOTHへの登録に使う、電子書籍版のPDFを生成します。 こんなにギリギリである必要は無いですが、逆にいえば当日までは電子書籍版であれば直せます。

「技術書をかこう！ ～はじめてのRe:VIEW～」に書いてある通り、電子書籍版の生成作業をします。 電子書籍版のブランチを作って作業するのが良さげ。

  • /articles/config.ymlを編集します。
# LaTeX用のスタイルファイル(styディレクトリ以下に置くこと)
# texstyle: reviewmacro
# tatsumacroは、電子書籍版の制作に利用する
texstyle: tatsumacro
# texstyle: techbooster-doujin

#
# LaTeX用のdocumentclassを指定する
# tatsumacro利用の場合はこちら
texdocumentclass: ["jsbook", "oneside,14pt,uplatex"]
# TechBoosterの指定は次の通り
# texdocumentclass: ["jsbook", "b5j,twoside,openany,uplatex"]
  • /articles/layout.tex.erbをリネームして無効化します

こうすると書籍入稿用PDFに特有の余白が減り、1ページあたりの文字数が増えます。

あとは以下の作業をします。

  • 改ページなど紙版特有の記述を削除
    • ページ数の制約は無いので、入稿用に追加した改ページなどを適宜消します
  • PDF出力したファイルをAdobe AcrobatのPDF編集モードで開き、空ページを最初と最後に足す
  • 表紙と裏表紙のpngデータを、その空ページに貼り付ける
    • config.yml内で表紙画像を指定できますが、裏表紙がtexでややこしかったので、PDFを直接編集しました。PDFは作れる！

以上で、それっぽいPDFが生成できます。

なお、「技術書をかこう！ ～はじめてのRe:VIEW～」に書いてないけどハマったポイントも、いくつかありました。

  • 電子書籍版で出力すると、なぜかフォントが太くなる
    • 詳しい状況やとりあえずの解決方法は以下のtweetをご覧ください

  • config.ymlのtoclevelの指定が、入稿版と電子書籍版で1段変わる気がする
    • マジで謎
  • 電子書籍版で出力すると、B5ではなくA4になる
    • 仕様かもしれないですが、表紙データのサイズを間違えて作り直してもらった

以上です。TeXつらい。

POPやポスターの準備

当日の設営に使うPOPやポスターを用意しました。 本の内容がどんなによくてもブースの見栄えが悪いと目立たないので、「それっぽさ」を演出しましょう。

買うもの

  • カード立て ×10個
    • 紙全体を包むタイプの方が、ペラペラの紙でもそれっぽく見える

タカ印 ポップ スタンド カード立 L型 34-3220 透明 58×86mm表示 10個

タカ印 ポップ スタンド カード立 L型 34-3220 透明 58×86mm表示 10個

  • ポスタースタンド ×1個
    • 折りたたむとめっちゃコンパクトで素晴らしい
    • クリップタイプのPOPスタンドとセットで買った

【INSIGHT WORKS】 POPスタンド（フロアスタンド） 長さの調節が便利なスライド式／持ち運びに便利な分解可能タイプ（ドライバー不要） (本体のみ)

【INSIGHT WORKS】 POPスタンド（フロアスタンド） 長さの調節が便利なスライド式／持ち運びに便利な分解可能タイプ（ドライバー不要） (本体のみ)

  • テーブルクロス ×1枚
    • ブースの机サイズを要確認
    • だいたい1m * 1mあれば大丈夫

布人倶楽部 ハーフ(50cm)サイズ 綿100% 無地オックス 黒 108cm 幅x50cmカットクロス

布人倶楽部 ハーフ(50cm)サイズ 綿100% 無地オックス 黒 108cm 幅x50cmカットクロス

  • 集金袋 ×10個
    • お札を10万円セットにして数えるために、多めに買いました
    • 700円など端数がある場合は、コインケースも買いましょう

ジッパー式ファイル袋 ファイルケース ファイルバック 收納袋 クリアホルダー A5判 PVC製 撥水 網目 ファスナ付き 旅行収納バッグ オフィス用品 10個セット

ジッパー式ファイル袋 ファイルケース ファイルバック 收納袋 クリアホルダー A5判 PVC製 撥水 網目 ファスナ付き 旅行収納バッグ オフィス用品 10個セット

  • 見本誌用ブックスタンド
    • 僕は自宅で使っていたものを持っていきました

actto BST-02 ブックスタンド(OEM品番:EDH-004)

actto BST-02 ブックスタンド(OEM品番:EDH-004)

他には、アカウント情報を印刷したネームカードを入れるネックストラップなどを準備しました。別に無くてもいい。

印刷したもの

こだわらなければ、コンビニ印刷で大丈夫です。 紙を選んだり大量に印刷したりする場合は、kinko'sなどを使いましょう。

www.kinkos.co.jp

僕が刷ったのは以下です。

  • A3ポスター ×3枚
    • 前述のように、日光企画さんでA2ポスターを1枚刷ってもらってもよかった
    • 2枚は机の前に、1枚はポスタースタンドに設置
  • 値札系（カード立てに入れるやつ）
    • 物理本の値札
    • ダウンロードカードの値札
    • 「写真OK！ハッシュタグでツイートしてね」
    • 「ご自由にお持ちください」
      • 無料で配る名刺とかシールとかがある場合
  • POP系（クリップで挟むやつ）
    • 「見本誌：お気軽にお読みください」
    • ブース番号表示

コンビニ印刷のデフォルト設定だと、データ上のサイズより少し小さく印刷されるという問題がありました。 詳しくは以下の記事を参照。

yarnyarnyarn.hatenadiary.com

設営リハーサル

当日の設営で慌てなくてもいいように、余裕があれば自宅の机で設営リハーサルをしてみましょう。

ブログ&ツイートで宣伝する

自分のブログがある場合は、本の内容や執筆裏話などを記事にまとめて公開しましょう。

jumpei-ikegami.hatenablog.com

技術書典に来る一般参加者の目にとまるように、#技術書典でツイートするとよいです。

0日前: 技術書典5当日！

あとは当日を楽しむだけです！お疲れ様でした！ 余裕があればTwitterで本の宣伝をしたり売れ行きを実況したりすると楽しいです。

やること概要

  • サークル入場時間中に会場入りする
    • 運営の準備が早く終わると、早く入場できることがある
  • 自分のブースを探す
  • 本が届いていること&印刷に問題ないことを確認する
  • ブースの設営をする
  • 開場後は、がんばって売る
    • 売り子は自分含めて2人以上いないとトイレも行けなくて死ぬ
  • 閉場後、ブースの撤去をする
    • 段ボールは運営さんが回収してくれた
  • 非公式打ち上げがあったりするので、気が向いたら参加する

当日の詳細は、以下のブログ記事をご覧ください。

jumpei-ikegami.hatenablog.com

反省点

今から振り返って、「こうしておけばよかった」という反省点を列挙します。

印刷について

  • 「目次直後のページにノンブルが無い問題」を解消できなかった
    • まあ隠しノンブル入れてくれたので大丈夫
  • 「PDF内のリンクが赤い問題」を解消できなかった
    • 以下のリンクに詳しい

qiita.com

イベント当日について

  • オンライン決済に対応すればよかった
    • めっちゃ簡単に対応できるもよう

blog.techbookfest.org

  • 見本誌を多めに用意すればよかった
    • 混んでくると、1冊じゃ足りなかった

まとめ

以上、技術書典にサークル参加するまでにやった作業の全貌でした。

この記事でサークル参加のハードルが下がったと思うので、気軽にサークル参加しましょう〜。

また、いろんな参考記事があった方がいいので、ぜひ本記事のような作業振り返りブログを書いてみてください。

#完全SIer脱出マニュアル が #技術書典 5から1週間で800部も売れて心底驚いている

f:id:jumpei_ikegami:20180922182207p:plain

こんにちは、gamiと申します。

2018年10月8日(月)に開催された技術書典5に軽い気持ちで初サークル参加しました。

techbookfest.org

結果、オンライン購入も含めて1週間で800部も売れたので、驚いてブログを書いてます。 別に売れた本が良い本という訳でも無いですが、「こんなに需要があったのか！」という感じです。

頒布した本は、『完全SIer脱出マニュアル』という、なんとも燃えそうなタイトルの本です。今でもPDF版はダウンロード購入できます。

booth.pm

本の内容や本を出すまでの経緯は、以下のブログに書いたのでぜひご覧ください。

jumpei-ikegami.hatenablog.com

事前の準備

紙の本は200部刷った

技術書典では、Webサイト上でサークルを「チェック」することができます。 さらにサークル側は、自サークルの被チェック数を見ることができ、どのくらい本が売れそうかを事前に知ることができます。

紙の本を入稿したのは、技術書典の約2週間前でした。 この時点の被チェック数は86だったので、直前の伸びも勘案すると200部は売れるやろという感じで部数を決めます。

もともと僕たちのサークルは「しがないラジオ」というポッドキャストをやっていて、1エピソードあたりの再生回数は1,500くらいあるので、その点では認知度的にけっこう有利だったと思います。 ポッドキャストでもこの本の宣伝をしました。

ep.32 楽しいVue.js入門と完全SIer脱出マニュアル | しがないラジオ

ダウンロードカードは1,000部印刷

技術書典では、紙の本が売り切れた場合に備えて、ダウンロードカードを用意するのが一般的です。 QRコードが印刷された紙で、そのURLからPDFをダウンロードできます。

前回の技術書典4では、知っているサークルの人が「ダウンロードカードが足りなくなってコンビニで印刷した」と言っていたので、絶対に無くならない数を刷ろうと1,000部印刷しました。

印刷費用でいうと一枚2円くらいなので、余ったら捨てればいいかーくらいの気持ちで刷れました。

技術書典5当日以降

被チェック数

技術書典前日には、被チェック数が更新する度に爆上がりしていました。 僕がTweetした値を振り返ると、以下のような上がり方です。やばい。

  • 前日
    • 09:44 → 247
    • 22:02 → 306
  • 当日
    • 05:03 → 388

この時点で、「紙の本は確実に売り切れるな」と確信します。

ちなみに当日は、楽しみすぎて朝5時に起きて池袋に向かいました。遠足の日の小学生か。

ブース設営

当日のサークル入場は10:00からの予定でしたが、運営の準備が早く終わったらしく、9:31には入場開始してました。

ブースの設営は、事前に自宅で一人リハーサルをしていたので、バッチリでした。

特に机に敷く黒い布が、怪しい高級感を演出してた気がします。買って良かった。

開場！

予定通り、11:00に一般参加者の入場が始まりました。

開場を告げるアナウンスが流れ、サークル参加者が立ち上がって拍手をします。 「これ、げんしけんで読んだやつだ！」と、一人で感動してました。 あの拍手するやつ、すごい楽しいのでぜひサークル参加しましょう。

開始1時間で紙版200部が完売

開場して少しすると、人がすごい勢いで歩いてきました。 事前にチェックしてくれていた人が、口々に「1冊ください」と告げてきます。 僕と相方のzuckeyは、本を売るマシーンと化しました。

結果、12:00直前には紙の本200部が完売します。

最初の1時間は、20秒に1冊以上のペースで売れたことになります。 流石にこんなに早く売り切れるとは思わなかった。

この1時間は、本の執筆やこれまでの「しがないラジオ」の配信で苦労したことがすべて報われていくような、ものすごい多幸感に包まれていました。 脳内物質がドバドバ出てきて、正直泣きそうでした。 生きてて良かった。

ダウンロードカード版の販売に切り替え

紙の本を置いていたスペースに「紙版は完売しました」と走り書きした紙をおいて、ダウンロードカード版を売り始めました。 この時点では、コンテンツが重要とはいえこんなペラッペラな紙を買ってくれる人が本当にいるんだろうか、と不安でした。

蓋を開けてみると、時間帯もあって勢いは落ちてきましたが、コンスタントに売れていきました。

売り子2人体制だったので、14:00頃まではほとんど休めず、やっと昼食にありつけました。 COMPはいいぞ。

お客さんとの会話を楽しむ余裕がでてきた

14:00以降は人の波もだいぶ落ちついてきました。

ブースに置いてある見本誌を目の前で立ち読みしてくれる人もたくさんいて、「もしこの人がSIerの偉い人で、急に殴りかかってきたらどうしよう」とビクビクしながら見守っていました。 もちろんそんなことはなかったです。

中には「自分と状況が近すぎて泣きそうです」とか、「僕はもう脱出しました」とか、「友人にお土産として買って帰ります」とか、話しかけてくれる人もいました。 実際に交流ができるのが、技術書典のようなリアルイベントの醍醐味だなあと感じました。

ポッドキャストのリスナーさんもたくさん来てくれたので、ホクホクでした。

また、タイトルがタイトルなだけに、弊サークルのポスターを見ながらクスクス話している通りがかりの人がとても多かったです。 ネタとしての話題性の高さを感じました。

当日は、合計500部を売上！

最終的には、ダウンロードカードもなんと紙の本の部数を超える約300枚を売り上げました。 12:00-17:00の5時間で、1枚/分のペースで売れたことになります。 1,000枚刷ったので枚数としては余裕でしたが、本気でびっくりでした。

紙版と合わせると、約500部を売り上げたことになります。

BOOTHでオンライン販売を開始

17:00-18:00の撤去作業中に、BOOTHでPDF版のオンライン販売を開始しました。 事前にショップ設定はしておいたので、公開設定をするだけでした。

当日夜は知り合いのサークル参加者のみなさんと非公式打ち上げに参加したのですが、 その最中もBOOTHからの「商品が購入されました」というメール通知がバシバシ届きました。

だんだんと、「これはすごい本を生み出してしまったかもしれない」という実感が湧いてきます。

技術書典5から1週間経って

技術書典5から1週間たった2018年10月15日8:36現在で、BOOTHでの売上部数は298冊です。 当日の売上と合わせると、合計で800部を売り上げたことになります。冷静にやばい。

また、Twitterのハッシュタグ"#完全SIer脱出マニュアル"で感想をつぶやいてくれる人も多く、そのTweetがきっかけで他の人が買ってくれたりしているみたいです。 中にはブログまで書いてくれる人もいて、執筆者冥利に尽きます。

感想Tweetは、togetterにまとめたのでぜひご覧ください。 「本に書いてあるアクションを、実際にやってみました！」というTweetも多く、仕事で悩んでいる人の背中を押せたことが、ただただ嬉しいです。

togetter.com

まとめ

技術書典へのサークル参加は初めてでしたが、自分が苦労して書いた本が目の前で売れていく光景は、思っていたよりずっとずっと素晴らしい体験でした。 サークル参加できる人は、ぜひ体験してみた方がいいです。

加えて、オンライン販売の部数が伸びていることが、とても嬉しいです。 この本の一番の対象読者は、「SIerやSES企業でSEや開発をしていて、毎週⽉曜⽇の朝に仕事に⾏くのがつらい⼈」です。 ただし、本のあとがきにも書いた通り、「この本を⼼から必要としているような⼈は、技術書典などというリア充エンジニアたちが集まるイベントには来ない」と思っていました。 なので、当日の売上に匹敵するくらいの部数が「イベントに来なかった人」に届いたという事実が、この本を書いた思いからすると僕にとっては一番重要です。

まだ『完全SIer脱出マニュアル』を読んでない人がいたら、お近くの人に借りるか、よければ買ってください。 そして、この本を読んだ方がいいような知り合いがいたら、ぜひ貸してあげてください。 私的利用の範疇で一般公開しないのであれば、PDF版であっても送信していただいて構いません。 「楽しく働くエンジニア」を増やすために、ぜひよろしくお願いします。

booth.pm

技術書典5で、『完全SIer脱出マニュアル』という本を出します

f:id:jumpei_ikegami:20180922182207p:plain

こんにちは。 明日、2018/10/8(月)に開催される技術書典5「お27」ブースで、『完全SIer脱出マニュアル』という本を頒布します。

techbookfest.org

何でこの本書いたの？

技術書典4に一般参加して、知り合いが本を出しているのを見て「楽しそうだなー」と思ったのがきっかけでした。 さっそく技術書典5のサークル登録をしてから「自分にしか書けないことって何だろう？」と考えた結果、思い至ったのが「レガシーな環境からモダンな開発現場に転職して楽しく働くためのノウハウ」でした。

果たしてそれは「技術書」なのかという葛藤はありましたが、 技術書典公式のFAQにも、技術書の定義について「ITや機械工作とその周辺領域について書いた本」と結構広く書かれているし、「情熱プログラマー」みたいなライフスタイル系の本も技術書的な扱いを受けているので、この本も「情熱プログラマー」枠だと自分に信じ込ませて書きました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

で、お前誰よ？

gami(@jumpei_ikegami)と申します。 新卒で某大手SIerにSEとして入社したあとで、SaaSスタートアップにエンジニアとして転職しました。 転職後は、開発とかクライアントワークとかもしつつ、エンジニアの中途採用に関わって主に書類選考や一次面接をガシガシ担当しています。

また、趣味で「しがないラジオ」というTech系ポッドキャストを運営しています。 様々なゲストの方をポッドキャストに呼んでそのキャリアについて話を聞いているので、 特に若手エンジニアのキャリア選択に関する知見がバシバシ溜まっています。

ちなみに、この『完全SIer脱出マニュアル』はポッドキャストの相方であるzuckey(@zuckey_17)と共同執筆しています。

こんな人にオススメ

本の中にも書いている想定読者は、以下のような人です。

  • SIerやSES企業でSEや開発をしていて、毎週⽉曜⽇の朝に仕事に⾏くのがつらい⼈
  • いまよりもっと楽しく働きたいエンジニア

特に、「仕事が楽しいとか言ってる人のことが信じられない」とか、「我慢してつまらない仕事を続けなきゃいけないのは自分に技術やスキルが無いからだ」と思っているかつての僕みたいな人に読んでもらいたいです。

この本で伝えたいこと

この本で伝えたいことは、主に3つです。

  • 「楽しい仕事」というのは本当に実在する
  • 少しの努力や考え方のシフトで、「楽しい仕事」にも意外と手が届く
  • あなたの人生は、あなたの決断次第で良い方向に変えられる

ともすると意識高い系みたいな話になりがちであれですが、「自分に全く自信なかったけど、転職して楽しく働いてます」みたいなエンジニアと少なくとも10人以上はリアルで出会った上で書いてるので、けっこう実態に即していると思います。

タイトル燃えそうだけど大丈夫？

『完全SIer脱出マニュアル』というタイトルをSIerで楽しく働いている人が見たら、確かに悲しみや怒りが湧いてくるかもしれません。 しかし、それ以上にメリットが大きいと考えて、あえて燃えそうなタイトルにしました。

  • 「エンジニア労働市場への誤解や自身への過小評価によって能力を最大限発揮できていない人」が、あまりにも多い印象がある
  • しかし、この本を本当に届けたい人のほとんどは、技術書典を知らない
  • この本が炎上でも何でもしてインターネットで話題になれば、そんな人にも届くかもしれない

僕は楽しく働く人を増やしたいと考えています。 みんな楽しく働いた方が面白いモノが生まれやすいし、巡り巡って僕の人生にとってもプラスだと思うからです。 そんな訳で、話題になるための炎上なら、どんとこいです。

推しポイント

この本の推しポイントは、以下です。

  • 初めてのエンジニア転職でよくある疑問に答えています
    • 楽しい仕事とか、本当にあるの？
    • 若いうちに転職するのって、デメリットあるの？
    • ベンチャー企業って怖いの？即戦力しか要らないの？
    • いま技術力が無い人は、エンジニアとして雇ってもらえないの？
    • 「成長」って必要？
  • モダンな開発が未経験な状態からエンジニアとして転職をするための具体的なアクションを、7つのステップに分けて細かく解説しています
  • 一般論で終わらないために、各ステップについて実際に経験したエンジニアが話している「しがないラジオ」のエピソードを逆引き形式で紹介しています

詳しくは目次をご覧ください。

f:id:jumpei_ikegami:20181007093956p:plain

f:id:jumpei_ikegami:20181007094016p:plain

また、執筆裏話については「しがないラジオのep.32」でも話しています。

まとめ

僕も技術書典5の「お27」で売り子しているので、ぜひお会いしましょう！

以下、ワクワクが止まらない僕のTweetで締めくくります。

「人を知ること」が重要になったいま、なぜ「普通の個人」が輝く時代になったか？ #CXDIVE

f:id:jumpei_ikegami:20180904230146p:plain gamiと申します。PLAIDという会社で、「CX(顧客体験)プラットフォーム KARTE」の開発や提供にまつわる仕事をしています。 プライベートでは、「楽しく働く人を増やす」ことを目指したポッドキャスト『しがないラジオ』のパーソナリティをしています。

今日は「CX DIVE」という最高なイベントに参加してきました。 cxdive.com

PLAIDが主催のイベントなので僕は完全に関係者なのですが、普通に参加者として行ってきて普通に得るものが大きかったので、個人のブログで感想を書きます。

CX DIVEは、CX(顧客体験)の今とこれからを考えるイベントで、セッション形式で12名の登壇者がテーマに沿ったトークをします。

僕はミーハー心でゆうこすさんやハヤカワ五味さんのセッションを聴いたのですが、その話の内容や2名の生き方から得られる気付きが多かったので、そこを中心に書いていきます。

女性の「モテたい」気持ちを全力で応援する24歳

ゆうこすこと菅本裕子さんは、HKT48脱退後に大きな挫折を味わい、そこからSNSをフル活用してフォロワーを増やしたクリエイター。 「モテクリエイター」を名乗り、各種SNSや動画配信サービスで女性がなりたい自分になるための情報発信をしています。

CX DIVEのセッションでは、自分のファンを分類してそれぞれに向けた発信方法を考える、新規流入向けとコアなファン向けでメディアを意図的に使い分ける、など、ファンを増やすための非常に具体的な方法論を語っていました。

twitter.com

元々は男性ファンが多いアイドルだったところから、今では圧倒的多数の女性ファンを抱え、累計フォロワー数150万人を突破したとのことで、個人とはいえ完全にマーケティングのプロという感じです。

また、「インスタ世代は『ググる』のではなく『タグる』（タグで情報を手繰り寄せる）」という話から、インスタのview数を増やすためのタグの重要性についてつなげていて、納得感がすごかったです。

僕はギリギリ20代ですでに若者文化から取り残されているので、ものすごく勉強になりました。

ゆうこすさんについては、僕も大好きなmilieuというメディアのインタビュー記事がとてもわかりやすいです。

milieu.ink

コンプレックスのある女性のためのファッションブランドを経営する23歳

ハヤカワ五味さんは、19歳で株式会社ウツワを設立した経営者。

胸が小さいことを「貧乳」と呼ぶのは間違っているという思いから「シンデレラバスト」というポジティブな呼び方を提唱し、シンデレラバスト専門の下着ブランドを運営しています。

ハヤカワさん自身もコンプレックスを抱いていたことから、同じような悩みを抱えた女性に届けたいプロダクトを作って販売しています。

CX DIVEのセッションでは、地域や世代で異なる「色眼鏡」をテーマに、マーケティングの文脈でも「事実より、知覚されたものが重要」であることを、具体的な事例を交えて話していました。

例えば、日本人の多くは「欧米人への憧れ」を抱いておりアパレル系のメディアに欧米人モデルが多いですが、中国では全くそんな「色眼鏡」は無いので日本と同じ感覚だと爆沈する、という話をされてました。 そこまで違うのか、という例が多く、学びが大きいです。

特に面白かったのは、「好景気眼鏡」として紹介していたバイアスでした。 好景気の時代を生きてきたおじさん達は無邪気に「最近の若者は欲がなくて、車も買わない」とか言いますが、普通に収入は減って支出は増えてるので、よっぽど好きじゃ無いと買わねえよ（意訳）、とバッサリ切り捨てていました。

ついつい、日本や自分が「普通」だという前提でモノを売ろうとしてしまうけれども、同じものを見ても意外とみんな全然違う感じ方をするんですよ、という話でした。

「バイアスなんて無い」という認知そのものがそもそもバイアスである、というメタ的な構造もまた面白かったです。

ハヤカワ五味さんについては、少し古いですが以下のインタビュー記事がよくまとまっていました。

news.yahoo.co.jp

なぜ中年たちはこぞって彼女達の講演を聞きに来るのか？

とても優秀だとはいえ、ゆうこすさんは24歳、ハヤカワ五味さんは23歳です。 でもそんな2人のセッションは、狭い会場なら立ち見が出るほどの大盛況でした。 40代と思われる「おじさん」とかも、真面目な顔でメモを取りながら、彼女らの話を聞いていました。

きっと10年以上前であれば、こうしたカンファレンスで呼ばれる登壇者は大企業でたくさんの経験を積んだ中堅以上の社員だったでしょう。 それが、個人としての活動の延長線上で活躍している若いクリエイターの話をこぞって聴くようになったのです。 これは、何かのゲームのルールが変わったとしか思えません。

僕は、「人を知ること」の重要性が増したことがそのゲームチェンジの大きな原因かもしれないなあと、漠然とセッションを聞いていて思いました。 ハヤカワ五味さんの話にあるように、地域や世代などの環境によって、「色眼鏡」は大きく異なります。 今では、こうした「人の違い」に寄り添ったニッチなプロダクトの提供も、事業として可能になってきました。 逆に言えば、「人の違い」を無視した画一的なプロダクトは、どんどん売れなくなっています。 こうしたルールの中では、サービスやプロダクトを届けたい相手を深く知ることが、とても重要になります。

特に情報が爆発的に増えたここ10年の環境変化は目まぐるしく、ギリギリ20代の僕でも、5歳年下の若者たちのモノの見方や商品の買い方については全くわかりません。 また、インターネットによって多様な価値観が許容され、クラスタ毎に情報の受信や発信ができるようになりました。 インターネット上に露出した多様な人間像の全てを正しく理解することは不可能であり、その翻訳者としての「個人」が求められているのではないでしょうか？

ゆうこすさんや、ハヤカワ五味さんは、「若者」、「モテたい女性」、「身体にコンプレックスのある女性」などのクラスタの声を翻訳する代弁者として、圧倒的な価値があるように見えます。 若者の「眼鏡」を「おじさん」がダイレクトかつ身体的に理解することは、到底不可能だからです。

「普通の個人」としての輝き方

ゆうこすさんや、ハヤカワ五味さんのような、昔の価値観で評価すれば「普通の個人」であったような人が、ビジネス的な場所でも輝ける時代になっています。 それは、個人として輝きたい人にとっては素晴らしい時代であり、試される時代でもあります。

お2人の活動から、個人としての輝き方のヒントを得るならどこでしょうか？

「人を知ること」の重要性に照らして考えると、「自分はどんな人の『眼鏡』を知っているか」ということを問い直すことから始めればいいと思います。

例えば、何者でもない僕の例で考えましょう。

僕が持っている属性は、大小散りばめると、例えば以下のような感じです。

ここから、レアリティの高さとニッチさのバランスを考えて、「どんな人の『眼鏡』を知っている」と見せていくかを決めていくのが良さそうです。 例えば、「男性」というのは広すぎますが、「元『東大卒フリーター』」というのは狭すぎる気がします。

「レガシーなSIerからベンチャーに転職」という要素から、「SIerからベンチャーにエンジニアとして転職する人」の気持ちはわかるかもしれません。 実はそんな人向けにすでにポッドキャストで情報発信をしています。

他には、「マーケティング界隈で働くエンジニア」という要素を活かして、「プログラミングを学びたいマーケター向け」に上手く情報発信ができるかもしれません。

こんな風に、「自分はどんな人の『眼鏡』を知っているか」という軸で自分が持っているカードを整理することで、個人として輝くための方向性が見えてくる気がしました。

「ボーダーレス」と「コミュニティ」

今回のCX DIVEのキーワードに、「ボーダーレス」という言葉がありました。 この言葉は、最初のKey Sessionでも最後のClosing Sessionでも、示し合わせたように登場しています。 この「ボーダーレス」と絡めてこれまでの話を解釈してみるのも面白そうです。

ゆうこすさんもハヤカワ五味さんも、自分が欲しい情報やプロダクトを発信しているように見えます。 そこには「企業と消費者」のような境界はありません。 また、例えばゆうこすさんのインスタグラム投稿にはフォロワーからのコメントが100以上付き、そのコメントも含めて全てがコンテンツとして機能しています。 そこに「発信者と受信者」のような明確な境界はなく、誰もが発信者であり受信者であるような世界で、個人として自分のフォロワーたちの間に溶け込んでいます。

「企業と消費者」というレガシーな境界が溶けていった先にある「消費活動」は、もはや「コミュニティ」的な様相を呈してきます。 ライブ配信中に商品を販売するライブコマースなどは、その象徴的な例にです。

一歩踏み出した個人が、特定クラスタの内側から発信をし、その発信を核にコミュニティが形成されていく。 ある個人は複数のコミュニティに緩やかに所属し、そのコミュニティの中で情報の受発信や商品の売買を行う。 もしも、そんなコミュニティベースの有機的な経済活動が全ての世代で当たり前に行われる時代が来たら、ビジネスも今までとは全く違うルールで動くことになり、かなり面白い世界なんじゃないでしょうか？

そんな世界の「CX」とは何なのかを考えていくのは、面白そうじゃないですか？

サイ本こと『JavaScript 第6版』全800ページを読破し、1万行のesaにまとめてわかった5つのこと

しがないラジオのgamiです。

JavaScript界隈では有名な、オライリーのサイ本こと『JavaScript 第6版』という鈍器、もとい書籍を読みました。

JavaScript 第6版

JavaScript 第6版

2012年に発行された、約800ページもある、かなり内容の多い本です。 僕は本を読むときにesaに要約しながら読み進めるのですが、サイ本のまとめesaは全体で「約1万行」という修行みたいな分量になっていました。

サイ本を要約しながらじっくりJavaScriptを学んだ人はこの世界にあまりいないと思うので、わかったことをまとめます。

読み始めたきっかけ

僕は約2年前に、富士通から、今働いているプレイドという会社に転職しました。 富士通ではCOBOL(！)とJavaしか書いていなかったので、Node.js+Vue.jsの会社に転職するための準備として、『JavaScript 第6版』を買った記憶があります。

今思えば、もっと軽い入門書もあったと思います。中二病だったのでしょう。

『JavaScript 第6版』を読んでわかった5つのこと

サイ本を読んで、JavaScriptのプログラミング言語としての立ち位置や面白さがわかりました。

「JavaScriptを学ぶ」ことの多くは、「ブラウザの仕様を学ぶ」こと

サイ本は、大きく「コアJavaScript」と「クライアントサイドJavaScript」の2部に分かれています。「コアJavaScript」では、主にJavaScriptの文法について説明しています。型、演算子、文、関数、正規表現など、他のプログラミング言語の入門書でも必ず説明されるような内容です。

特徴的なのは、「コアJavaScript」よりも「クライアントサイドJavaScript」の方により多くの紙幅を割いている点です。他のプログラミング言語の入門書であれば、簡単にライブラリを紹介する章はあっても、言語自体の文法に関する説明よりも短く掲載される場合がほとんどでしょう。JavaScriptの場合は、「Webブラウザ」という切っても切り離せない巨大アプリケーション群があり、ほとんどの場合はその実行環境を前提として記述されます。そのため、「JavaScriptを学ぶ」ということの多くは、「ブラウザの仕様」や「DOMを含むWeb API群の標準仕様」を学ぶということなのだなあ、ということをサイ本を読んで実感しました。

例えば、ただJavaScriptで計算をしたいだけなら、別にWebページのHTMLをどのように操作できるかなど知らなくても何も困りません。ただし、JavaScriptを書きたい、学びたい、というモチベーションの多くは、Webのクライアントサイドに関わる以下のようなことです。

  • 動的にHTMLやCSSを変化させたい（DOMやCSSOMの制御）
  • ユーザーの操作に応じて処理を変えたい（イベント処理）
  • 外部サーバーと非同期で通信したい（Ajax）
  • ブラウザ側にデータを保持して、IDやセッションを管理したい（Cookie、localStorage）

逆にクライアントサイドJavaScriptは、それを学ぶ過程で、HTMLやCSSの仕様に依存したAPIを学ぶことになります。なので、Webのクライアントサイドの技術について深く学びたい場合は、JavaScriptの学習をすることで、HTMLやCSSも含めたブラウザの仕様について深く理解できるようになると思います。

ちなみに、2007年に発行された一つ前の版である『JavaScript 第5版』の目次を『JavaScript 第6版』のものと比べると、ブラウザの機能の変遷がわかって非常に面白いです。

www.oreilly.co.jp

www.oreilly.co.jp

2007年の第5版では「Javaアプレット」、「Flash」、「XML」などの章がありますが、2012年の第6版ではそれらがすべて削除され、代わりに後述する「jQuery」や「HTML5 API」の章が追加されています。

クライアントサイドJavaScriptの爆発的変化

『JavaScript 第6版』が出版されたのは、2012年の8月です。今が2018年の7月なので、たった6年前になります。ただし、この本に書かれている内容ですら、すでに一部の仕様が廃止されていました。

例えば、windowオブジェクトのメソッドとして本書で紹介されているshowModalDialog()は、MDNで調べると「この機能は削除されました。ウェブサイトやアプリケーションを修正してください。」と書かれています。

「ブラウザは後方互換性を大事にするので機能を削除できない」とよく耳にしますが、仕様の議論が不十分なままブラウザに実装された過去の機能については、廃止されているものもあるようです。

サイ本を読むとき、あまり聞いたことのない機能については、実際にブラウザのコンソールで本当に使えるのか試したり、MDNに記載があるかを調べたりしていました。少し古めのJavaScript本を読むときは、機能が廃止されている可能性を考慮しながら読んだ方が良さそうです。

なお、JavaScriptはES2015で以下のような新しいシンタックスがかなり追加されましたが、サイ本にはそれに関する以下のような記載はありません。

  • let、constによる変数宣言
  • アロー関数
  • class構文
  • 分割代入
  • importとexport

さらに、現代のクライアントサイドJavaScriptとは切っても切り離せない以下のような技術スタックには特に触れられていません。

フロントエンドの開発に求められるものの多様化とWeb技術の変化の速さを揶揄して「フロントエンド地獄」と呼ばれますが、サイ本もまた（少なくとも第6版の時点では）その地獄に囚われ古臭い本になりつつありました。

そのためサイ本は、「最新のJavaScript」ではなく、「時代を経ても変わらないJavaScriptのエッセンスや、すでに安定したWeb API」について学ぶための本として読んだ方がよいです。

「最新のJavaScript」については、出版されるかわからない『JavaScript 第7版』に期待しましょう。

ブラウザ間の差異から来る闇

JavaScriptという言語の特殊性として、その実装はブラウザベンダーに委ねられており、独自の方言が認められている点があります。もちろん、Webページを実装する開発者としては、1つのJavaScriptファイルが複数のブラウザで意図通りに動作することを期待します。ただし、歴史的経緯から来るブラウザ間の仕様の差異によって、その期待はしばしば裏切られてきたことが、サイ本を読むとわかります。

特に、Web標準の策定プロセスが今ほど洗練されていなかった時代に実装された機能については、多くの闇を生み出しているようです。例えば、window.onerrorというエラー時に呼び出される関数内では、エラー処理完了時に通常はfalseを返します。ただし、歴史的経緯から、Firefoxだけはtrueを返さなければいけないそうです。

このような問題に対処するには、本来の処理に加えて、どのブラウザで実行されているのかをチェックする「ブラウザテスト」を実施しなければいけません。 （なお現在では、window.onerrorはtry-catchによって代替され、ほとんど使われていません。）

特にブラウザ互換性についての話題で言及されやすいInternet Explorer（IE）については、本書でも「非互換性の多くは、IEに関連したものです」と、名指しで批判されています。

古いIEでは、Web標準として勧告されたメソッドを実装せず、同様の機能を持った別名のメソッドを使っていたりします。 例えば、IE8以前ではイベントハンドラを登録するaddEventListener()が実装されていなかったため、代わりにattatchEvent()というメソッドを使う必要があったそうです。

if (window.addEventListener)
    window.addEventListener("load", f, false);
else if (window.attachEvent) // IE8以前
    window.attachEvent("onload", f);

IEが天下を取っていた時代は、大半のWebページはIEで動けば問題なかったのでしょう。そんなIEに対抗するブラウザが登場し、健全な競争や議論の中でWebの標準化が進んだことは、非常に喜ばしいことだと思います。

また、Web標準の策定プロセスが整備されたことに加えて、Microsoft Edgeの登場、ブラウザ間の差異を埋めるPolyfillなどのライブラリの存在によって、ブラウザ間の差異を前ほど意識せずにJavaScriptを書くことができる環境になりつつあります。

かつてのjQueryがもたらした価値

サイ本では、第19章の約70ページ全てを、丸々jQueryの紹介に割いています。JavaScriptの1ライブラリとしては、破格の待遇です。

2012年当時、jQueryがJavaScriptライブラリとしてデファクトスタンダードであったことがわかります。

今でこそ目の敵にされているjQueryですが、当時これほど流行った理由がサイ本を読んでいてわかりました。

前述のように、当時のフロントエンドの開発者はブラウザ間の差異から来る闇に苦しんでいました。生のJavaScriptではなくjQueryを使うことで、ブラウザ間の差異を吸収してくれ、どのブラウザでも同じように動作するJavaScriptを生成することができました。

また、JavaScriptやブラウザ自体の機能がまだ脆弱だった頃、jQueryは強力なAPIをどんどん追加していき、JavaScriptができることを広げていったようです。

jQueryのAPIを覚えるだけで、ブラウザ互換性に配慮した動的なWebページを開発することができるとなれば、これほど使われるようになるのも必然でしょう。

ただし、現在では前述のようにブラウザ間の差異を前ほど意識せずにフロントエンド開発ができる環境が訪れつつあり、jQueryが果たした本質的な役割の意義が薄れつつあります。

また、jQueryのようなDOMへの要素挿入を中心としたアプローチではなく、宣言的なViewの管理によって要件を実現するVue.jsなどのJavaScriptフレームワークが、保守性などの観点から流行しています。一般にVue.jsなどが管理しているDOMを後からjQueryで書き換えるとアプリケーションがぶっ壊れるので、脱jQueryを進めるWebページやWebアプリケーションが増えている印象です。

もしも『JavaScript 第7版』が出版されたら、きっと『第19章 jQueryライブラリ』は無くなっているでしょう。

ブラウザにはワクワクする機能がたくさん追加されている！

サイ本の最終章である『22章 HTML5 API』では、以下のように当時では比較的新しかったAPIの仕様に関して言及されています。

  • 履歴管理
  • クロスオリジンメッセージング
  • Web Workers
  • Geolocation
  • IndexedDB

この本では「未来のAPI」のように語られているこれらのAPIですが、例えば「履歴管理」はSPAで戻るボタンを押せば当たり前のように機能しますし、Web Workersの1つであるService WorkersもついにiOS Safariで対応され、主要ブラウザ全てでPWAのキャッシュやプッシュ通知に使われ始めています。

ブラウザの仕様が目まぐるしく変わることで、そのキャッチアップが大変であったり、多くの負債が生まれたことは、前述の通りです。しかし、逆に新しい仕様が次々と登場することで、ブラウザで実現可能な範囲は毎年広がっています。例えば、「ブラウザ経由で位置情報を特定してその場所に応じたコンテンツを出す」みたいなことも、ブラウザの標準機能で実現できるようになっています。

また、この本に書かれた後に登場してきた新しい仕様によって、以下のような世界が当たり前になっていくかもしれません。

  • WebAssemblyで、C言語で書かれた世界中の資産がブラウザ上から使える
  • Payment Request APIで、ブラウザに登録しておいた支払方法や配送先を選ぶだけでブラウザ経由で決済できる
  • Web Publicationsで、HTMLで書かれた文書をそのまま電子書籍として閲覧、出版できる

JavaScriptを取り巻くエコシステムについて学び続けていると、そんなワクワクする話題がたくさん登場して、とても楽しい毎日を送れます。

この本について

ここまでサイ本を比較的ボジティブに解説してきましたが、正直に言って、JavaScriptを勉強したい多くの人には、この本はあまりおすすめではありません。『JavaScript 第6版』自体がかなり古くなっていて、最新のJavaScript事情を反映できてないからです。また、リファレンス的に利用するならまだしも、全章を読破するには、JavaScriptを記述する上では不要な内容が多い印象があります。

僕もJavaScriptを学び始めた当初は、サイ本より先に、『開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質』という本を読みました。

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

こちらの本の方が、JavaScriptのハマりポイントである以下のような点について、たくさんの例を交えて簡潔に記述されています。

  • プリミティブ型とオブジェクト
  • this
  • スコープとクロージャ
  • プロトタイプ継承

JavaScript初心者が中級者に上がるための本としては、こちらの『開眼! JavaScript』の方をおすすめします。

また、リファレンス的に利用するにしても、MDN Web DocsにJavaScriptの最新仕様やブラウザ互換性についてよくまとまっているので、そちらの方が使い勝手としては良いでしょう。

「サイ本がこれだけ分厚いなら、JavaScriptのより低レイヤな領域についても記載があるだろう」と思う人もいるかもしれないですが、特にメモリ管理の話とかも出てこないです。

なので、仮に『JavaScript 第6版』を勧めるとしたら、「ある時点でのJavaScriptの仕様を、その歴史も交えて体系的に知りたい」人に対してのみになるかと思います。もしそのような奇特な人がいたら、ぜひ挑戦してみてください。

最後に、改めてサイ本こと『JavaScript 第6版』の目次を掲載します。

第I部　コアJavaScript

  • 2章　字句構造

  • 3章　型、値、変数

    • 3.1　数値
    • 3.2　テキスト
    • 3.3　論理値
    • 3.4　nullとundefined
    • 3.5　グローバルオブジェクト
    • 3.6　ラッパーオブジェクト
    • 3.7　不変な基本型値と可変なオブジェクト参照
    • 3.8　型の変換
    • 3.9　変数の宣言
    • 3.10　変数のスコープ

  • 4章　式と演算子

    • 4.1　単項式
    • 4.2　オブジェクトと配列の初期化子
    • 4.3　関数定義式
    • 4.4　プロパティアクセス式
    • 4.5　呼び出し式
    • 4.6　オブジェクト生成式
    • 4.7　演算子の概要
    • 4.8　算術演算子
    • 4.9　関係演算子
    • 4.10　論理演算子
    • 4.11　代入演算子
    • 4.12　評価式
    • 4.13　そのほかの演算子

  • 5章　文

    • 5.1　式文
    • 5.2　複合文と空文
    • 5.3　宣言文
    • 5.4　条件文
    • 5.5　ループ文
    • 5.6　ジャンプ文
    • 5.7　そのほかの文
    • 5.8　JavaScript文のまとめ

  • 6章　オブジェクト

    • 6.1　オブジェクトの生成
    • 6.2　プロパティの読み出しと書き込み
    • 6.3　プロパティの削除
    • 6.4　プロパティのテスト
    • 6.5　オブジェクトプロパティの調査
    • 6.6　プロパティのゲッターメソッドとセッターメソッド
    • 6.7　プロパティ属性
    • 6.8　オブジェクト属性
    • 6.9　オブジェクトのシリアライズ
    • 6.10　オブジェクトのメソッド

  • 7章　配列

    • 7.1　配列の生成
    • 7.2　配列の要素の読み書き
    • 7.3　疎な配列
    • 7.4　配列の長さ
    • 7.5　配列の要素の追加と削除
    • 7.6　配列の要素の巡回
    • 7.7　多次元配列
    • 7.8　配列のメソッド
    • 7.9　ECMAScript 5の配列メソッド
    • 7.10　配列の種類
    • 7.11　配列のようなオブジェクト
    • 7.12　配列としての文字列

  • 8章　関数

  • 9章　クラスとモジュール

    • 9.1　クラスとプロトタイプ
    • 9.2　クラスとコンストラクタ
    • 9.3　JavaScriptでのJavaスタイルのクラス
    • 9.4　クラスの拡張
    • 9.5　クラスと型
    • 9.6　JavaScriptでのオブジェクト指向的な技術
    • 9.7　サブクラス
    • 9.8　ECMAScript 5のクラス
    • 9.9　モジュール

  • 10章　正規表現パターンマッチング

    • 10.1　正規表現の定義
    • 10.2　パターンマッチング用の文字列メソッド
    • 10.3　RegExpオブジェクト

  • 11章　JavaScriptのサブセットと拡張

    • 11.1　JavaScriptのサブセット
    • 11.2　定数とスコープ付きの変数
    • 11.3　分割代入
    • 11.4　反復機構
    • 11.5　簡易表記関数
    • 11.6　複数のcatch節
    • 11.7　E4X：ECMAScript for XML

  • 12章　サーバサイドJavaScript

第II部　クライアントサイドJavaScript

  • 13章　Webブラウザに組み込まれたJavaScript

    • 13.1　クライアントサイドJavaScript
    • 13.2　HTMLドキュメントへのJavaScriptコードの埋め込み
    • 13.3　JavaScriptプログラムの実行方法
    • 13.4　互換性と相互運用性
    • 13.5　アクセサビリティ
    • 13.6　セキュリティ
    • 13.7　クライアントサイドフレームワーク

  • 14章　Windowオブジェクト

    • 14.1　タイマー
    • 14.2　ブラウザのLocationオブジェクトと移動
    • 14.3　閲覧の履歴
    • 14.4　ブラウザと画面情報
    • 14.5　ダイアログボックス
    • 14.6　エラー処理
    • 14.7　Windowプロパティとしてのドキュメント要素
    • 14.8　複数のウィンドウとフレーム

  • 15章　ドキュメントの制御

    • 15.1　DOMの概要
    • 15.2　ドキュメント要素の選択
    • 15.3　ドキュメント構造と探索
    • 15.4　属性
    • 15.5　要素のコンテンツ
    • 15.6　ノードの作成、挿入、削除
    • 15.7　例：目次の作成
    • 15.8　ドキュメントと要素位置とスクロール
    • 15.9　HTMLフォーム
    • 15.10　ドキュメントのそのほかの機能

  • 16章　CSSの制御

    • 16.1　CSSの概要
    • 16.2　重要なCSSプロパティ
    • 16.3　インラインスタイルの制御
    • 16.4　算出スタイルの取得
    • 16.5　CSSクラスの制御
    • 16.6　スタイルシートの制御

  • 17章　イベント処理

    • 17.1　イベントタイプ
    • 17.2　イベントハンドラの登録
    • 17.3　イベントハンドラ呼び出し
    • 17.4　ドキュメントのloadイベント
    • 17.5　マウスイベント
    • 17.6　マウスホイールイベント
    • 17.7　ドラッグ＆ドロップイベント
    • 17.8　テキストイベント
    • 17.9　キーボードイベント

  • 18章　HTTPの制御

    • 18.1　XMLHttpRequestの利用方法
    • 18.2　<script>によるHTTP制御：JSONP
    • 18.3　Server-Sent Eventsを使ったComet

  • 19章　jQueryライブラリ

    • 19.1　jQueryの基本
    • 19.2　jQueryのゲッターとセッター
    • 19.3　ドキュメント構造の変更
    • 19.4　jQueryでのイベント処理
    • 19.5　アニメーション効果
    • 19.6　jQueryによるAjax
    • 19.7　ユーティリティ関数
    • 19.8　jQueryセレクタと選択メソッド
    • 19.9　プラグインによるjQueryの拡張
    • 19.10　jQuery UIライブラリ

  • 20章　クライアントサイドストレージ

    • 20.1　localStorageとsessionStorage
    • 20.2　クッキー
    • 20.3　IEのuserData永続化機構
    • 20.4　アプリケーションストレージとオフラインWebアプリケーション

  • 21章　メディアとグラフィックの制御

  • 22章　HTML5 API

    • 22.1　Geolocation
    • 22.2　履歴管理
    • 22.3　クロスオリジンメッセージング
    • 22.4　Web Workers
    • 22.5　型付き配列とArrayBuffer
    • 22.6　Blob
    • 22.7　Filesystem API
    • 22.8　クライアントサイドデータベース
    • 22.9　WebSocket

  • 索引