がみぶろ

#がみぶろ

@jumpei_ikegami

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

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 IllustratorPhotoshopが自分では使えない場合は、 表紙と裏表紙のデザインを誰かに依頼します。 僕は偶然にも婚約者さんがデザインできる人だったので助かりました。

日光企画で印刷する場合は、最終的には以下の「表紙用トンボテンプレート(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個
    • 紙全体を包むタイプの方が、ペラペラの紙でもそれっぽく見える

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

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

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

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

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で以下のような新しいシンタックスがかなり追加されましたが、サイ本にはそれに関する以下のような記載はありません。

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

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

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

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

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

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

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

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

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

特にブラウザ互換性についての話題で言及されやすいInternet ExplorerIE)については、本書でも「非互換性の多くは、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年当時、jQueryJavaScriptライブラリとしてデファクトスタンダードであったことがわかります。

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

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

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

jQueryAPIを覚えるだけで、ブラウザ互換性に配慮した動的な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 DocsJavaScriptの最新仕様やブラウザ互換性についてよくまとまっているので、そちらの方が使い勝手としては良いでしょう。

「サイ本がこれだけ分厚いなら、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 E4XECMAScript 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
  • 索引

DevRel Meetup in Tokyo #31 〜初級者向け〜に参加してきました!

f:id:jumpei_ikegami:20180607202756j:plain

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

今後のキャリアの選択肢の1つとして、DevRel(開発者向けPR)活動関わることに興味があるので、DevRel Meetup in Tokyo #31に参加しました!

devrel.connpass.com

若干ビジネスイベント感があって、最初に全員のテンション高めの自己紹介から始まるのに戸惑いましたw でも、エンジニア向けの勉強会とは雰囲気が違って面白かったです。

DevRelの基本とマーケティング戦略 by MOONGIFT 中津川篤司

speakerdeck.com

自己紹介

DevRelとは?

  • Developer Relation
  • PR(Public Relation)の開発者版

DevRel活動

  • セールスをするのではない
  • 認知度やマインドシェアを上げることで、土俵にあげてもらう活動

なぜ開発者?

  • 開発者は広告を一切見ない
  • 高ITリテラシー
  • ソーシャル、ブログでの拡散率が高い
    • 三者が公平に書いたブログは、CVRへの寄与度が高い
  • 穴を売るな、ドリルを売れ
    • 体験を売るべき
  • 自社製品の新しい魅力を生み出す

製品採用のステップ

  1. その技術を調べる
  2. 課題解決できる製品を並べる
    • Googleの検索結果に出てくることが重要
  3. 各製品の情報を調べる
  4. 検証する
  5. 購入する

注意点

  • 中長期的な戦略として実施する
    • 外資系の企業は、すぐに方針転換するw
  • すぐに効果は出ないので、続けることが重要
  • KGI/KPIをきちんと定めておく
    • 数字を出せないと、上を説得できない

DevRelのマーケティング戦略

  • SWOT分析をしてみる
    • 強みを生かし、弱みをなくしていく
    • 外部要因の弱みは啓蒙によって世間の目を変える

開発者主体で考えた分析軸

  • 1つ目
  • 2つ目
    • マーケットリーダー
    • チャレンジャー
    • ニッチプレイヤー
    • シューティングスター
      • 金に物を言わせて市場をぶん取ろうとするプレイヤー

ペルソナ決め

  • どんなに便利でも使ってくれない
  • 属性をラベリングしていく

ペルソナを決めると?

  • 本当に必要な機能がわかる

井の中の蛙になる

  • 小さな市場でトップシェアになることが重要
    • そこから、市場を拡大する

AARRR分析

  • DevRel的には、最初にAwarenessを、最後にProductを付ける

フォーカスを決める

  • 新規獲得?Churn Rate?
  • 収益?利用者拡大?
  • 認知度向上?
  • 非アクティブユーザーの活性化?

アクション評価シート

施策判断

  • 2軸の組み合わせで考える
  • マトリクスを作ってみて、施策の幅出しをする

施策の決定

  • ローリスク、ハイリターンの追求をする
    • 効果がすぐに出るものではないので、低予算で長く続ける
  • 基本は、ユーザー単価で判断する
    • PVは水増しできる
    • 「登録したらプレゼント」をしても、変なユーザーしか増えない

DevRelのABCDE

  • A: アドボケイト
  • B: ブログ
  • C: コミュニティ
  • D: ドキュメント
  • E: イベント

ブログ

  • 誰に何を読んで、どうなって欲しいのか?
  • ペルソナの課題解決がベスト

ドキュメント

  • 過不足ない
  • 検索フレンドリー

まとめ

  • 技術より情熱、お金より行動
    • LTをするだけなら、今日からでもできる!

小さく始めろ、評価は期待するな、理解ある上司を探せ、プロダクト愛を持て! by NTTコミュニケーションズ 仲さん

speakerdeck.com

自己紹介

  • @Tukimikage
  • SkyWay Teamのテクニカルソリューションズやサポートエンジニア

テーマ

SkyWayとは?

  • Enterprise Cloud WebRTCプラットフォーム SkyWay
  • 2013〜トライアル
  • 2017〜 正式リリース
  • RareJobなどで使われている

SkyWayのミッション

  • WebRTCを身近な技術に変える
    • 使いこなすためには、幅広い技術領域の知識が必要

SkyWayが提供する価値

  • WebRTCを使ったサービス開発のハードルを下げたい
  • サービス自体の価値向上に集中して欲しい

開発者に価値提供し続けるためには?

  • デベロッパーファーストであり続けることが重要
  • DevRelに力を入れている

実践していること

情報発信

  • FAQやサポートコミュニティの運営
    • 無償の場合、コミュニティで解決してもらう
  • SNSでの情報発信
  • GitHubやQiitaでの情報提供
  • 開発者向け公式イベント
    • 「いいオフィス」を借りて、100名規模で実施

ユーザーグループ立ち上げ

  • コミュニティマネージャーとして、開発者と共にUG立ち上げ
  • 東京、関西、福岡で実施

開発者と開発チームとをつなぐ

  • 開発者から受けたフィードバックをプロダクトに反映する営み
    • BackLogに追加していく
  • サポートコミュニティには開発チームからは書き込みをあまりしない

エヴァンジェリスト活動

  • WebRTCに関する啓蒙活動
  • 業界発展に向けた取り組み
    • WebRTC Conference Japan

NTTコミュニケーションズとは?

  • 従業員数が6,350人
  • ザ・エンタープライズ企業!
  • 単体でうるのではなく、ソリューションとして価値を提供することで、収益を拡大する

DevRel活動の課題

  • すぐに売り上げには結びつかない
    • そもそも、部署の目標と合っていない
    • 社内で評価されにくい
    • 仲間がなかなか増えない
  • 大企業特有の縦割り型環境だとやりづらい

小さく始めた

  • ユニット単位でかなりの裁量が認められていた
  • 数人で企画、開発、PR、運用まで全てやったので、DevRelの重要性も認知された
  • 結果を出したことで、他部署からも評価された

社内での評価は気にしない

  • 事業部では、売り上げに直結しないDevRel活動は評価されづらいので、気にしないw
  • 可能なら、指標化する

プロダクトに愛情を注ぐ

  • まずは自分がファン第一号であるべき
  • 誰よりも中身に詳しくあるべき
    • エンジニア畑出身者がやる方が良い

テクニカルエバンジェリストに求められる5つの基本スキル by 職業「戸倉彩」

www.slideshare.net

自己紹介

  • 職業「戸倉彩」

テクニカルエバンジェリストとは?

  • 誰のために、何をする人か?
    • 開発者向けに、技術を啓蒙し、エンゲージする

職種名いろいろ

企業内での課題

人間的な課題

  • 本名 or ニックネーム
  • 活動時間
  • 活動場所
  • 活動内容
  • 得意/不得意分野

経験者は語る

1. エンジニアであれ

  • 技術を信じ、情熱を注ぐ
  • IT業界のトレンドを理解する
  • 手を動かす

2. 正しい情報を伝える

  • 開発者の言葉
  • タイミングと情報の鮮度
  • 公式見解か個人の意見かを明確に

3. コミュニケーション

  • 開発者文化やスタイル
  • オンラインとオフライン

4. ビジネスセンス

  • 社会性をもつ

5. 人間力

  • IT業界での立ち位置
    • ただ可愛い、かっこいいではなく、「テクニカルに何ができる人なのか?」が重要
  • セルフブランディング

テクニカルエバンジェリスト2.0

  • 開発者向けに、技術を啓蒙し、エンゲージする + 「売り上げに貢献する」
  • DevRelの対象とは?
    • 開発者 + 開発者のお客様 + 次工程

1. 上昇志向のエンジニアであれ

  • フルスタックエンジニア
    • どんな技術にもチャレンジする

2. エンゲージメント

  • 技術と人間と会社との関係

3. コミュニケーション

  • グローバルに活動
    • 日本に限定しない活動をすべき
    • 英語でのアウトプット大事!

4. インパクトの出せるビジネスセンス

  • マネタイズ

5. ITヒーローを育てる

  • 次世代(後継ぎ)を考える

意識している3つのこと

  • 自分を恐れない
    • 自分の限界を決めない
  • 周りを恐れない
    • 周りの評価を気にせず、チャレンジする
  • 時代を恐れない
    • いまの主流と違うことであっても、変えるために啓蒙していく

課外活動で勉強会を主催していたら会社の事業になった話 by のびすけさん

liginc.co.jp

自己紹介

  • 元LIGエンジニア
  • dotstudioを経営
    • ものづくり教育事業

dotstud.io

今回の対象

  • 仕事は仕事で割り切って、業務時間外でやりたいことをやろうと思っている人

LIGについて

liginc.co.jp

Phase1. なんとなく始めたイベントが200人規模になった

  • IoTLTという勉強会を主催
  • きっかけ
    • 「リレーションズのエンジニアを外に出したい」という相談を土屋さんから受けた
    • IoTという言葉がバズりそうだったので、始めてみた
  • 第1回は、社内勉強会として始める
    • リレーションズとLIGの合同社内勉強会
  • 気付いたら、述べ1,000人を超える
  • いまは、述べ15,000人

Phase2. コミュニティ成長の一方で、目的を見失う

  • 当初の目的だった、リレーションズのエンジニアが参加できなくなってきた
  • 成長してきたコミュニティを前にして、どうすればいい?
  • 続けることで価値を見つけた
    • 毎月開催をし続けることで、「すごい楽しかった」「仕事につながった」という声が上がってきた
    • 来てくれる人がいるということは、価値があること
    • エンジニア向けにやっていたが、IoTに興味がある人なら誰でも集まるコミュニティになった

Phase3. 社内に対する承認欲求との戦い

  • 「この活動を会社が後押ししてくれればいいのに」と思うようになった
    • とはいえ、「話題になってるから勝手に会社も気付くだろう」とも思って社内共有しなかった
  • とある経営者の投稿
    • 「影の努力を気づく上司はほとんどいません」
    • 「評価をしてほしいなら、その努力を上司ないしキーマンに全力でみせましょう」
    • 見えているものでしか、評価はできない
    • 社内に対しても、アウトプットが必要
  • 社長を勉強会に呼んだ
    • 「めっちゃいい会だね」と連呼してもらう
  • 海外に行こうか迷ったタイミング
    • 海外転勤できなければ会社を辞めようと思った
    • 社長に止められた
      • 「新しくLIGの中で新規事業を立ち上げないか?」

Phase4. DevRel事業部を立ち上げた

  • 「技術障壁が高い」のはもったいない
  • 特にIoT領域で、プロモーションのお手伝いをしていく

まとめ

  • モチベーションが無くても、続けていれば価値につながる
  • 好きなことを業務に持ってくる、この為に社内へのアウトプットは重要
  • まず動いてみて、後から振り返ることで自分のやりたいことが見つかる

Phase5. おまけ: LIGから独立しました!

  • dotstudioを立ち上げ

LT: システムインテグレーターにおける"R"(序)

自己紹介

SIerにおけるリレーション

  • 既存のお客様との関係をイメージする人が多い
  • 他にももっとあるはず
    • パブリック、メディア、ガバメント、パートナー、デベロッパー...
  • 関係性から始まるRAIDMA

関係性の前に

  • そもそも、認知してもらう必要がある

取り組み

  • オンラインでリーチできる認知可能な情報の積み上げ
    • オンラインで検索できない技術は、無いのも同じ
  • Pay Forward
    • 情報収拾とアウトプットを、とにかく続けること

より詳細には...

qiita.com

最後に

以上で内容については終わりです。

DevRel界隈の常識すら知らない状態で参加したので、内容が新鮮で面白かったです!

全然知らない分野の勉強会に参加するのは、ノリや使っているワードが違うので楽しいことがわかりました。

イベントの様子は、以下のTLから感じられると思います! twitter.com

趣味で『しがないラジオ』を1年続けて、オフ会を開催したら40人も集まって驚いた話

f:id:jumpei_ikegami:20180602091313j:plain

こんにちは、しがないラジオのgamiです。

2018/5/23(水)に、しがないラジオのmeetupを開催しました! shiganai.connpass.com

ありがたいことに、40人もの方にご参加いただき、しがないラジオもよくここまで来たなあという感傷的な気持ちになりました。

当日の写真は、僕に消されるまで以下から見られます!
shiganai radio meetup - Google ドライブ

しがないラジオとは?

僕が新卒で入った富士通を1年半で辞め、株式会社プレイドというスタートアップに転職をしたのが2017年11月。

その4ヶ月後の2017年3月から、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」(略して「しがないラジオ」)というポッドキャスト富士通時代の同期のズッキーと始めました。

shiganai.org

最初は2人がたわいもないSIer批判話をしたり、趣味や気になる技術の話をするだけのポッドキャストでした。 そこから、少しずつ知り合いをゲストを呼び、そのゲストの知り合いが聞いてくれるようになり、直接知らなかった人もゲストに呼び、またそのゲストの知り合いが聞いてくれて。

そんなわらしべ長者方式で、ゲストとリスナーの輪が広がっていきました。

実はホスティング先のSoundCloudを見ると、毎回のエピソード毎の再生数がわかります。 始めた頃は1回のエピソードが100再生を超えれば大喜びしていましたが、最近のエピソードはその10倍の1,000回再生を超えて聴かれています。

これからもどんどん盛り上げていきたいですが、思えば遠くまで来たなあ、という感じです。

オフ会を開催した経緯

実は、2017/12/18(月)に「しがないラジオ忘年会」というイベントを開催したことがありました。 shiganai.connpass.com

過去のゲストさんを中心に10人くらい参加して、公開録音したりLTしたり飲み会したりしました。

そんな忘年会を無事終えた後で、今回のmeetupを公募して開催しようと思ったきっかけは、リスナーさんの1人であるいけさんに背中を押されたからでした。

会場の規模を決めるために、実際どのくらい来るのかTwitterで確認してみると、30-50人くらいは来てくれそうなことがわかりました。

めでたく開催が決定した瞬間です!ポッドキャストの相方のズッキーには、ほとんど相談せずに勝手に決めましたw

オフ会の準備

オフ会の準備は、主に以下をしました。

会場の予約

会場は、サポーターズさんのご好意で、レンタルスペースを無料で貸していただきました!

pages.supporterz.jp

会場費がかからないだけで、参加費がグッと抑えられるのですごくありがたかったです!

お酒とお菓子の注文

お酒とお菓子は、カクヤスで注文しました。 お酒は予定参加人数に対して1.5本/人くらいのお酒を注文したら、若干足りないくらいでした。

名札の購入と印刷

オフ会という性質上、ネット上のアカウントとリアルの人間の紐付けが楽な方が話が盛り上がるはずです。

ということで、てぃーびーさんに教えてもらって、@yoshiko_pgさんが公開している「参加者の名は。」というWebサービスを使いました。

yoshiko-pg.github.io

connpassのイベントページURLを入れると、予約している人のプロフィール画像と名前を見て、名札サイズのpdfを出力してくれます。 控えめに言って最高でした。

f:id:jumpei_ikegami:20180602081839j:plain

オフ会当日

オフ会当日は、富士通時代の同期でWeb系企業のデザイナーに転職したみっつんさんが写真を撮ってくれました!感謝!

当日の写真は以下から見られます!

shiganai radio meetup - Google ドライブ

オフ会当日の様子は、以下のTogetterや参加者の皆さんのブログをご覧ください!すごいたくさんブログ化されてて、本当にありがたいです!

togetter.com

ses.vtryo.me

note.mu

monry.hatenablog.com

gremito.hateblo.jp

kito0039.hatenablog.com

techblog.oscasierra.net

roo-ashi.hatenadiary.com

mascii.hatenablog.com

blog.haramishio.xyz

以下、独断と偏見で、エモいTweetだけ抜粋します!

収支

実は、今回のmeetupでは、飲食代などの経費を差し引いても、2万円ほどの黒字が出ました!

しがないラジオは、パーソナリティ2人やゲストさんの時間以外に、SoundCloudへのホスティング費用や、ドメイン代、ステッカー代などを支出していました。

2万円で足りるのかはよく知りませんが(笑)、編集・アップロード担当のズッキーに全部渡して、これらの支払いに当てさせていただきます!

初のmeetupを終えて

冒頭のTweetにも書きましたが、何者でもないSIerのSEだった僕が、転職してポッドキャストを始めて、そのオフ会に40人集まって、その40人で撮影した集合写真の真ん中に写ってるの、すごい話だと思いました。

ただ忘れてはいけないのは、僕と相方のズッキーは単なるきっかけを作っただけだということ。

本当に、毎回面白い話や役に立つ経験談を提供してくれるゲストの方々や、聞いてフィードバックをくれるリスナーさんたちが、『しがないラジオ』という2人の夢を一緒に盛り上げてくれたからこそ、今があります。

最近の盛り上がりを見ていると、『しがないラジオ』というコンテンツが、僕とズッキーの手を離れて、「コミュニティのものになっている」感がします。この感覚は、まだ『しがないラジオ』が無かったときに、しがないラジオep.1を僕の自宅で収録した頃の自分から考えると、すごく不思議な感覚です。

これから

2人よりは40人で支える方が強いと思うので、おかげさまで、これからもポッドキャスト『しがないラジオ』は続けられそうです!もし仮に少しの期間だけでもポッドキャストの更新が途絶えたら、きっと誰かがTwitterで「次の回まだー」と声をかけてくれるような気がします。「誰かが次のエピソードを待ってくれている」という状況は、ポッドキャストを続けるためにはすごく有利なものです。

ということで、これからも、「みんなの『しがないラジオ』」として、謙虚に楽しく続けていきます!

meetupの第2回以降についても、不定期で開催しようかと思っているので、ぜひ次回のmeetupもご参加お待ちしています!目指せ300人!