【しがないラジオお便りコーナー】フィードバック紹介 & コメント 2018年7月分

この記事は、#しがないラジオ Advent Calendar 2018 2の25日目ラストの記事です。

adventar.org

ラジオはお便り紹介が一番楽しいと思っています。zuckeyです笑 しがないラジオのパーソナリティをしています。

最近はゲスト回が多めでフィードバック紹介ができてなかったのです。そこでこのアドベントカレンダーを使って紹介しようと思います。

あまりにも多くなってしまったのでこれから6日間、6月25日を起点に半年分を1ヶ月区切りで紹介しようと思います。

ぜひ見て、気になるエピソードがあれば聞いてみてください！

7月編スタート！！！

SIerから転職することや今の会社で合わなければ転職を考えるのも一つの選択肢だ、ということをよく話しています。 piroさんは逆でずっと1社でやってこられた方、そういう方をゲストに招いて、逆の意見を聞けているのもしがないラジオの良いところかなと思います。

やはり長く業界におられるといろいろな経歴、職種も違えば携わっている業界も違う、絵も描く。 面白いお話を聞けました。

技術系の職種で入社からの総務への社内異動、はじめは戸惑いながらもエンジニアリング観点で業務改善をされた話は僕もよく自分の周りの人との間で話題に上げてしまいます。

僕も最近またポモドーロを会社でやっているのですが、止められること前提でいると、本当に止めないと行けないものとそうでないものを判断しよう、という気持ちになってくるので、より良い感じに進捗できるようになった気がします！ あと、その場で適当に人に振れる力もついた気がします！

ちょっと何言ってるかわからないです。

ちょっと何（ry

はやみねかおるです！！ 最高ですよね！（急にテンションを上げる）

まず目的から述べている本、というだけでは漫画技術書に限った話ではなかったのですが、そこに主人公の立場も付け加えると、動機づけまでされて良いですよね。

日経Linuxデビューした記念すべきTweetです笑

しがないラジオの特徴として、ゲストで一番多いのが僕らと同世代（僕は1991年生まれ）、というのがありその世代が聞くとエモが爆発する、と言われています笑

Podcastは脱線が命だと思ってます。 脱線するからこそ深い話が聞ける。 長くなるのは許してください 🙏

あとのエピソードでもでてきますが、日本人は英語をちゃんと使いたい欲求が強いんですよね... ただ、最近気づいたのは、英語力が大学入学時からどんどん下がっているので、そろそろもうちょっと頑張らないといけないです。 とはいえ、OSSにバリバリ貢献されている方がこういう発言をしてくださるのはすごく後押しになると思います！

清水さん！ありがとうございました！ 来年はまたWe Are JavaScripters!に行きます！

wajs.connpass.com

今年はあえてあまり勉強会に参加しなかったのですが、勉強会中にメモをとって終わり次第即ブログにするのは、主催者にとってもいいですし、ビュー数が伸びるという意味で自分にとってもすごくメリットがあると思います。

ぽやぽやしたい。 ひらがなですよね笑

さすがOJTでしがないラジオを紹介される会社らしいです笑 参考 しがないラジオmeetup2

sp33 sp44 にも出演されています！！

言語を軽く触る意識してフィボナッチとかを書いて見るようになりました！ その後、電卓を言われてましたが難しいんですよね... その間がないものか...

投資、なるほどもっと引いて見ないといけないですよね〜。 楽しそうだな！っていうところに飛びついて、それでたのしかった〜ってなっていることが多いので、まだまだこれからですが、考えさせられます。

いつもはあまり出さないですが、gamiさんはブラックなのです（ゲス顔）

おっしゃる通りで先人の功績に感謝しつつ、それにおんぶにだっこで良いものを作っていきたい所存です！！ そして、自分でもいろいろなOSSに貢献されている桑原さん、尊敬します。何か僕もやらねば、同世代で焦ります。

「しがあるラジオ」ゲスト出演希望待ってます笑

現時点（2018-12-25）最新回でRedhatのサポートエンジニア、ひよこ大佐さんの話を聞いていますが、世間でのサポートエンジニアの認識と現実にギャップがあるようです。 もっとたくさんの方の働き方を聞いていきたいと思いました。

「あとで直す。」というのの他に、Issueにして放置っていうのがよくあって最近それをいかに無くすか（自分含め）というのでいろいろ悩んでいます。 なにかうまい知見あれば教えていただきたいです！

COBOLは一大コンテンツ！

最近Scrapbox使い始めて、わかばちゃんのわかりやすさに感激しました笑

しがないラジオはちゃんとコンバージョンにも貢献しています。 もし、なにか宣伝したい本やイベントなどがあれば、ぜひDM下さい笑

twitter.com

いろいろな人の紆余曲折って、あとからこじつけで話されることも多いと思っていて、そのへんFindyのCTOまさたんさんはすごく赤裸々に面白い経歴を話してくださり、最高にいい方でした！

まとめ

以上です！

明日は7月26日〜8月25日まで！

しがないラジオで2年弱パーソナリティをつとめ、53人のゲストと話をして感じた「ゲスト駆動の成長」

この記事は、#しがないラジオ Advent Calendar 2018の1日目の記事です。

shiganai.connpass.com

しがないラジオというPodcastのパーソナリティをgamiと2人でやっております。 そのオフ会兼勉強会兼忘年会みたいなものを開催しました。

お越しいただいた方々本当にありがとうございました。 リスナーが可視化されづらいと言われるPodcastで、たくさんのリスナーの方々と交流できるのは本当に嬉しいことだなと思いました。

本当に幸せな空間でした。

詳細については、この記事の最後に参加者の方々のブログへのリンクを記載するのでそちらを読むと当日の雰囲気がわかるかと思います。

ゲスト駆動の成長

当日は僕自身もLTをしたのですが、発表資料を作り込む余裕がなく、文字だけの簡素な資料になってしまったので、共有はしませんでした。
この記事では、スライド公開の代わりにそのLTの内容について書こうと思います。

これまでにないチャレンジが人を大いなる成長に導く

皆さんは普段Podcastを聞かれるでしょうか？僕は日々たくさんのPodcastを聞いているのですが、その中で以下の2つのエピソードが最近すごく心に残りました。

以下のブログには、これまでにないチャレンジを重視するような機械学習の新たな学習モデルが、既存のモデルよりも優秀な結果を残した、というような研究結果が記されています。 上記のエピソードはともに、その研究結果に人間の成長を重ねて議論を展開しています。

blog.openai.com

(日本語記事としてはこちらがありました 👉 予測ベースの報酬による強化学習でAIが高難易度の死にゲーで人間以上のハイスコアをたたき出す - GIGAZINE)

新たな学習モデル？

記事についてもう少し補足します。

スコアを競い合うような種類のゲームにおいて、機械学習を用いてそのスコアを上げるという研究があります。
どういった行動に高い報酬を与えるのか、ということを予測モデルに設定することで、学習をチューニングします。

これまでは「スコアが上がるような行動をとること」を重要視するようにしていました。
このような設定では、機械はスコアが上がるように行動しようとします。
しかしながら、その設定では人間がゲームをしたときの平均以下までしかスコアが上がらなかったということのようです。

次に、「新しいチャレンジをすること」「新しい状態になること」を重要視するようにしたようです。 すると、こちらのほうがスコアが上がり、人間のスコアを上回るようになったというのです。

人の成長にも新たなチャレンジが必要だよね

先程あげた両Podcastエピソードはマネジメントや組織論の文脈だったため、上記のような研究結果をうけて、プロジェクトや業務の過程の中でチャレンジを重視して評価したほうが、より評価の対象者は成長するのではないか、という話が展開していました。

大きなものを成し遂げるには、既存の方法だけではうまくいかないこともある。 新しいことをやることが目的になってはいけないが、既存にとらわれずゼロベースで考えられる力をつけるのが必要、ということでした。

成果物ベースよりチャレンジベースのほうが学習効率が良い、という話にもなっていました。

これはマネジメントだけでなく個人の成長にも同様のことが言えるのではないかと僕は思いました。

強いエンジニアになりたい

僕はPodcastでもそれ以外でもいろいろなところで「強いエンジニアになりたい」というようなことを言ってきました。 僕自信が後発のエンジニアで、界隈で有名だったり一目置かれたりするエンジニアに対して強く憧れを持っている、ということの現れです。

強いエンジニアってなに？

じゃあ、お前のいう強いエンジニアとはなんなのか？というのは、よく質問されることです。 特に2018年、年始に目標として強いエンジニアという言葉を出してからそれについてはいろいろと考えてきました。

LT中でも、

のような指摘をうけました。

本当にそのとおりで、強いエンジニアというのはなんなのか、最近特にわからなくなってしまいました。
本を書いたらすごいのか、大きい会社にいたらすごいのか、給料をたくさんもらったらすごいのか、わからないです。

結果として、「自分がどうなれば自分に納得できるのだろう？というのを突き詰めたい」ということなのだな、と考えるようになりました。

※ 強い/弱いというな表現について、インターネット上で賛否あることは理解しています。
「強さ」というのは相対的なものになってしまう部分はあると思います。
じゃあそれによって態度をかえたり、そういうためのものさしとして利用しようとしたりしているわけではないです。
純粋に「自分がどうなれば自分に納得できるのだろう？というのを突き詰めたい」という思いがあるのだと、理解いただけると嬉しいです。

様々な刺激によるランダムなチャレンジ

さて、冒頭にも述べたとおり、僕はしがないラジオというPodcastのパーソナリティをしています。
しがないラジオではゲストを呼んでその方が日々どのように考え、どのような工夫を経て、楽しく働いているか、楽しく生活しているか、ということを伺っています。
現在、未公開の分も含めると 53 人の方々とともに収録しました。
短い人では1時間半から長い方では4時間以上にもおよぶ収録をしています。

ゲストから刺激を受け、それを試す

ゲストの方々は、僕が出会ったこともないたくさんの難しい課題に取り組んでおられます。 それらについての話は、ノウハウの塊です。

その方々の口からでた本を読んでみたり、それについてチームのメンバーと話したりもしました。 そして、自分の日々の業務のルーティンをを一気にガラッと変えてみたりもしました。

これがいわゆる新たなチャレンジで、自分自身を新しい状態にしているのではないかなと思います。

そのすべてがうまくいったわけではないです。 けれども、長い目でみるとただただ、がむしゃらに時間と労力をかけてやっているよりも、結果としてより良い方向に向いているような気持ちになっています。

それが結果として、強いエンジニアにつながる道なのではないかと思うようになりました。

なのでこれからも刺激をくださるゲストに、楽しい挑戦の話をたくさん聞いていけたらなと思います。

まとめ

ゲスト駆動の成長について考えていたことを書きました。
リスナーの方々も同じように考えてくださってるのではないかな、と勝手に思っています。
そんな思いで、しがないラジオで発信したい、という方はぜひお声がけください。

これからもよろしくお願いします！！！

#しがないラジオmeetup2の感想ブログリンク集

（2018-12-01 時点で公開されていたもの）

note.mu

blog.vtryo.me

fortegp05.hatenablog.com

mzryuka.hatenablog.jp

皆様ありがとうございました！！

GitHubのIssueテンプレートを導入する方法のメモ

f:id:zuckey_17:20181119000127p:plain

個人のプロジェクトを立ち上げるのに、少数ですが複数人でプロジェクトを進めるため、Issueでタスクや機能の詳細を管理しようということになりました。

とはいえ、あまり一緒に仕事を進めたことも多くなく、テンプレートを導入することにしました。

自分でやったことがなかったので、メモとして残しておこうと思います。

必要なことは以下でした。

  • /.github/ISSUE_TEMPLATE以下にmarkdownファイルを置く
  • nameとaboutを入れる

f:id:zuckey_17:20181119000136p:plain

追加したテンプレートは以下でした。

bag_report.md

---
name: Bug report
about: バグを知らせてね

---

## 🐛 Summary

(バグの概要)

## 👀 Steps

(バグの再現手順)

1. Do action
2. Do another action
3. Wrong Behavior !!

## 🆗 Expected

(Closed になるために必要な状態)

## 🚑 Actual

(Issue を作成した時点の状態)

## 📎 Images (optional)

(バグ発生時の画像)

feature.md

---
name: Feature request
about: ワクワクするような新機能リクエスト

---

## 🎉 Goal

(Closed になるために必要な状態)

## 💪 Motivation

(Issue を何故立てたのですか？)
(Issue を作成した背景は？)

## 📖 Reference (optional)

(参考リンクなどあれば)

## 📆 Schedule (optional)

(Closed になるまでのスケジュール)

## 📎 Tasks (optional)

- [ ] Task 1
- [ ] Task 2

task.md

---
name: Task
about: タスクの整理と内容を記す

---

## 💪 タスク

### 📄 資料
+ 

### ✅ 作業
+ [ ] 

### 🚀 完了条件
+

絵文字を入れて楽しげにすることを意識しました。 （今週は短いですが、以上です）

Pythonで駅コード調査用データベースから情報をスクレイピングした

blog.zuckey17.org

前回、 Suicaの利用履歴をパースするリポジトリ中の StationCode.csvについて、

StationCode.csvがコミュニティーの有志によって作成されたものらしく、最新のものではないのか、完全ではないようです。

と書きました。

よくよく調べると、路線・駅コード一覧・登録 というサイトがあり、

路線・駅コード一覧・登録のページに遷移すると、駅コードのデータベースのようなものにたどり着きます。 ここで随時更新されているようなので、今回はこれをスクレイピングして、真・StationCode.csvを作成してみました。

Pythonによるスクレイピング、ちゃんとするのが初めてでいろいろハマりましたが以下のようなコードになりました。

import csv
import re
import urllib2
from bs4 import BeautifulSoup

current_page = 1

html = urllib2.urlopen("http://www.denno.net/SFCardFan/index.php")
soup = BeautifulSoup(html, "html.parser")
last_page_num = int(re.findall('[\d]+', soup.find("a", title="last page").string)[0])

file = open('StationCode.csv', 'w')

for num in range(last_page_num):
    html = urllib2.urlopen("http://www.denno.net/SFCardFan/index.php?pageID=" + str(current_page))
    soup = BeautifulSoup(html, "html.parser")
    rows = soup.find_all("table")[1].find_all("tr")
    del rows[0:2]
    for row in rows:
        datas = map(lambda x: not(isinstance(x, type(None))) and not(isinstance(x.string, type(None))) and x.string.encode('utf-8'), row.find_all("td")) # エンコード変換
        writer = csv.writer(file, lineterminator='\n')
        writer.writerow(datas)
    current_page += 1

file.close()

ファイルに書き出す際に UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) と文字エンコードで怒られたので、空文字列でない場合にUTF-8にエンコードを変換する処理を書きました。

それ以外は意外とスムーズに進んだので、pythonすげーとなりました。

まとめ

周辺知識なしからSuicaの利用履歴を読み込むデモ（ macOS ）

f:id:zuckey_17:20181104184308j:plain:w200

Suicaの利用履歴を読み込み、入場駅やためていたデータの履歴を表示するところまでをとりあえずやってみたので、手順をまとめておきます。

お願い

僕はPythonをほとんど触ったことがないので、ライブラリの利用方法や読み込みなどあまり理解していないので、温かい目でみていただき、間違った部分があれば指摘していただければ嬉しいです。

用意するもの

ソニー SONY 非接触ICカードリーダー/ライター PaSoRi RC-S380

ソニー SONY 非接触ICカードリーダー/ライター PaSoRi RC-S380

PaSoRiはICカードリーダーでよく見るのでこれにしてみました。

nfcpy

今回は nfcpyというライブラリを利用します。

https://nfcpy.readthedocs.io/en/latest/index.html

NFC（Near Field Communication）で受け取った生データを読み込んで出力するためのライブラリのようです。

こちらを使います。

python3.x系への対応はまだらしく、2.x系を利用します。

python & pipの準備

僕はHomebrewにてpython2系をインストールしました。

$ brew install python@2
...(略)...

$ which python2
/usr/local/bin/python2

$ which pip2
/usr/local/bin/pip2

pip（pythonのパッケージ管理ツール）も一緒に入ります。

その他の必要な環境を準備

USB読み込み系

PaSoRiはUSBデバイスなのでそれを扱うためのライブラリをインストールしておきます。

$ brew install libusb
$ brew install libusb-compat
$ sudo pip2 install pyusb libusb1 pyserial

OpenSSL を新しくする

macOSに標準で入っているOpenSSLはバージョンが古いらしく、下記の方法で新しくします。

$ brew install openssl
$ ln -s /usr/local/opt/openssl/bin/openssl /usr/local/bin/openssl
$ ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/libcrypto.dylib
$ ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/libssl.dylib

バージョン管理ツールBazaar

nfcpy を利用するための方法は、 Bazaarというgitのような分散型のバージョン管理ツールを利用することが公式で紹介されています。 このツールはHomebrewで入れることができます。

$ brew install bzr

nfcpyを利用する

まず、Bazaarでnfcpyを落とします。 trunkというディレクトリにnfcpyのライブラリのリポジトリが落とせます。

$ bzr branch lp:nfcpy trunk
$ cd trunk
$ tree -L 1
.
├── HISTORY.rst
├── LICENSE
├── README.rst
├── docs
├── examples
├── nfc
├── setup.py
├── tests
└── tools

examples以下にこのライブラリを用いたサンプルがあるので、実行してみます。 まず先にmacにPaSoRiを接続しておきましょう。

$ python2 examples/tagtool.py
[nfc.clf] searching for reader on path usb
[nfc.clf] using SONY RC-S380/P NFC Port-100 v1.11 at usb:020:025
** waiting for a tag ** <<< ここで入力待ちをするのでICカードをPaSoRiに近づけます
Type3Tag 'FeliCa Standard (RC-S???)' ID=**************** PMM=**************** SYS=0003

これでFeliCa対応のカードの情報を取得することができました。 ↑は

  • IDm (製造ID/Manufacture ID)
  • PMm (製造パラメータ/Manufacture Parameter)

だそうです。

Suicaの利用履歴を読み込む

さて、本題のSuicaの利用履歴です。Suicaは過去20件の利用履歴が取り出せるようになっています。 nfcpyを利用してSuicaの情報を取得し、生データをパースして見やすくしてくれているライブラリが以下です。

https://github.com/m2wasabi/nfcpy-suica-sample

中を見ていただければわかりますが、StationCode.csvというところに、生データと駅との組み合わせがあり、それによって入出場駅を出力できているようです。

clone

このリポジトリを任意の場所にcloneし、中でnfcpyを落としてきます。 その際ディレクトリ名をnfcpyにしているのを間違えないようにします。

$ git clone git@github.com:m2wasabi/nfcpy-suica-sample.git
Cloning into 'nfcpy-suica-sample'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 3), reused 13 (delta 3), pack-reused 0
Receiving objects: 100% (13/13), 65.33 KiB | 484.00 KiB/s, done.
Resolving deltas: 100% (3/3), done.

$ cd nfcpy-suica-sample
$ bzr branch lp:nfcpy nfcpy # ディレクトリ名をnfcpyに
Not checking SSL certificate for xmlrpc.launchpad.net.
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
Branched 284 revisions.

そして、直下あるsuica_read.pyを実行します。

python2 suica_read.py
Type3Tag 'FeliCa Standard (RC-S???)' ID=**************** PMM=**************** SYS=0003
=== 00 ===
端末種: None
処理: 物販
日付: 18-11-02
入線区: None-None
入駅順: None
出線区: None-None
出駅順: None
残高: 1734
BIN:
c7 46 00 00 25 62 6e a7 d0 59 c6 06 00 03 4a 00
=== 01 ===
端末種: 改札機
処理: 運賃支払
日付: 18-11-01
入線区: *********
入駅順: ***
出線区: *********
出駅順: ***
残高: 2643
BIN:
16 01 00 02 25 61 e0 09 e4 3e 53 0a 00 03 49 00

...（略）...

=== 19 ===
端末種: 改札機
処理: None
日付: 18-10-25
入線区: *******
入駅順: ***
出線区: *******
出駅順: **
残高: 3958
BIN:
16 14 02 01 25 59 ce 25 00 00 76 0f 00 03 31 00

と20件のSuica利用履歴が出力されました。 端末機: 物販などはコンビニで利用したときのもののようです。 また、 StationCode.csvがコミュニティーの有志によって作成されたものらしく、最新のものではないのか、完全ではないようです。

まとめ

  • Suicaの利用履歴が読み込めました
  • Pythonのエコシステムについて詳しくなかったためハマりました
  • Raspberry Piを購入したのでこれを使って楽しめたらなというのが今後の展望です

パブリックなページのpathにidを入れるかどうか検討した

パブリックなページのpathにidを入れるかどうか検討しました。
idといっても、DBのプライマリ・キーという意味なので以降 idというのはその意味で見てほしいです。

調べてみても案外エントリがなかったので書いておいておこうと思いました。
もしかしたら、間違っていたり考慮が足りなかったりすると思うので、そのときはコメントなどで教えてほしいです。

idを使う場合と使わない場合？

idを使わない場合

ユーザー個別のリソースを作成するページ

ユーザー個別のリソースに対する編集や削除などが他のユーザーからできてはいけません。
そういった場合は認証をかけると思いますが、単純にユーザーが登録などをしていない場合にも、ユーザー個別のリソースを作成したい場合があります。
何らかの質問項目に回答をしてもらう際などがそうです。（アパレルショップなどで経験があります。）
直接やメールなどでそのURLを送信することもありますが、その際、別の人がそのページを踏んでしまうと回答が混線してしまって大変なことになるので、避けるためにハッシュのようなものをidの代わりに利用することが多いです。

SEOや見た目を重視する場合

ユーザーフレンドリーなURLにすることはSEOにプラスに働くと言われています。
また、URLがわかりやすいとそのページがどういうものなのかを想像しやすく、またイトの世界観を壊さないために数字よりも意味のある文字列にすることもあります。

そのリソースの規模やKPIを悟られたくない場合

idがインクリメントであるならばリソースの数がそのままidとなります。
そのため、サービスの規模を隠したい場合などには隠すことが有効な手段というふうに考えられます。（ブログサービスの記事数など）
また、毎日のように新しいリソースを作るようにするとサービスの成長具合もわかってしまうこともあります。
そのことによって、KPIを推測されるというリスクもあり、それを避けるためにも有効な手段です。

idを使う場合

簡単に言うと上記以外なのですが、認証などはあるものの、個々のユーザーに関係なく同様のリソースを表現している場合です。
Railsなどのフレームワークでは複数存在するリソースに対してルーティングを作成するとデフォルトでidによってアクセスできるpathを用意してくれたりします。
not availableなリソースにアクセスした場合は、どちらの場合も404を返すようにします。
そのような前提に立つならば特に理由のない場合、ハッシュ化する意味はないように思いました。

参考にしたページ

connpass

https://shiganai.connpass.com/event/82050/

eventはすべてのconnpassユーザーが参照可能。

gitHub

https://github.com/rails/rails/issues/34300

Railsはパブリックなリポジトリなのでissuesはすべての人が参照可能。

はてなブログ

https://blog.zuckey17.org/entry/2018/10/21/140909

はてなブログは見た目重視で、デフォルトでは投稿日付をエントリへのパスにしてくれます。
またユーザーが個別にエントリへのパスを指定することもできます。

note.mu

https://note.mu/ruiu/n/n76729d8930c9

詳しく使ったことがないのでわからないですが、noteでは記事に投げ銭ができたり、購入機能があるためidをハッシュ化しているのだと思いました。 また、ブログサービスということで全体の記事数を隠したいという意図もあるのかもしれません。

まとめ

  • これまで深く考えたことがなかったのですが、仕事で必要になり少し意識的に詳しく調べてみました
  • 調査の際、相談にのってもらった方々ありがとうございました

冒頭にも書きましたが、間違っていたり考慮漏れたりしている可能性もあると思うので、コメントなどで指摘いただけると嬉しいです！！

技術書典5に「しがないラジオ」としてサークル参加参加してきました

f:id:zuckey_17:20181021141145p:plain:w300

技術書典5に「しがないラジオ」としてサークル参加参加してきました。
出した本は「完全SIer脱出マニュアル」という本です。
技術書典は技術にまつわる同人誌の即売会で、技術系コミケ *1というとわかりやすいかと思います。
半年に1回のペースで開催されており、第4回の前回は一般参加者として書籍を買う側として参加しましたが、今回第5回はサークル参加ということで書籍を出す側で参加しました。

もともと出たいなと思ってはいましたが具体的には何もなく、Podcastでともにパーソナリティをしているgamiさんが勢いで申し込んでくれ、参加が決定しました。

完全SIer脱出マニュアル

BOOTHで買えます 👇

booth.pm

しがないラジオというのは技術系のポッドキャストで、僕とgamiさんがパーソナリティをつとめており、最近では楽しく働いているエンジニアのキャリアなどを話しています。
タイトルどおりの本で、SIer（=楽しくない職場。といってもいいと思います）から脱出したい人のためにノウハウや考え方を、しがないラジオでこれまで聞いてきたエピソードトークから抽象化して書いた本です。

目次なんかは、BOOTHのリンクからも見れますし、読んだ方々の感想は、togertterにもまとまっているので良ければ見てみてください。

togetter.com

担当

ノウハウや考え方を書いてある本編を僕自身は書いておらず、ディスカッションの場にいたりチェックくらいで、僕はこれらの本編を読んだあとにそのもととなったしがないラジオのエピソードをピックアップして紹介する付録を担当しました。
また、もう1つ付録の特典エピソードについてはいつものごとく編集作業などを担当しました。

売れたのか

結論から言うと、想像以上に売れました。

売れた要因？

gamiさんの煽りタイトルをつける能力が炸裂し、お願いしたデザイナーさんの表紙 *2がわかりやすくマッチしていました。
やはり人の流れの早いイベントだったので、ポッドキャストのリスナーさん以外にも購入していただけたり立ち読みしていただけていたのは、そのパッと目に入るわかりやすい煽りが良かったのだと思いました。

同人誌即売イベントで多い立ち読みですが、そこで読んでいただいたかたに買ってくださったのは大きいと思います。
タイトルに反してすごく客観的に、適切なエクスキューズをしつつ書かれた本だったのでそのへんがギャップとして刺さった部分なのかなと思いました。
ディスカッションの中でもかなり意識していたところでもあったし、そのへんもgamiさんの良さなのかなと思います。

リスナー層の一部にお買い上げいただくための特典エピソードをとれたというのが僕の唯一の売上への貢献だったかなと思います。

焦りと後悔

とそんなふうに結果としてはよかったのですが、とあるポッドキャストも聞いてくださっているかたのブログにこのように書かれていました。

リスナー勢としてあえて欠点を上げるならばずっきー色が薄いことでしょうか(笑)

iwasiman.hatenablog.com

また、他のブログの方もこのようなことを書かれていました。

今回、私と同じく初のサークル参加でかなりバズっていたのが gami さんの『完全 SIer 脱出マニュアル』。

note.mu

確かにgamiさんが申し込んでくれたところもありますし、あまり熱が盛り上がらなかったというのは実際にPodcastでも話しましたが *3 、本当にそのとおりでしたし、他エピソードの編集もあり意外と忙しく乗れなかったというところでした。
そういうあれこれで、終わってみると僕らの *4 本がすごく好評なのをみてすごく悔しいなり焦るなりをしました。

  • 自分が書いたのではこのようなことにはならないのだろう
  • 同人誌なのに自分の子供感がなくて即売会にちょっと居づらい

そんな思いをもって帰路についたので、おそらく次回も僕らは何かしら頒布するつもりではいますが *5、次は僕も本を書こうと思います。
なので何を書くかもまだきまっていないですが、とりあえずリポジトリは作り、gamiさんの手順を参考にして、なにもないPDFを出力できるようにしました。

そういえば今朝公開されたgamiさんのブログに技術書典サークル参加へのいろいろなノウハウが乗っていたので参考にしたいと思います。笑

jumpei-ikegami.hatenablog.com

最後に

技術書典5で「完全SIer脱出マニュアル」でかってくださった皆様本当にありがとうございました。
あまり制作には多く関わっていませんでしたが、しがないラジオというのが愛されていることもわかったので非常に嬉しかったです。

また、次自分も出すという宣言をここでしたのでしっかり頑張ります。

*1:コミケでも技術書はうられているようですが。

*2:ありがとうございます

*3:記事公開時点ではリリースされておりませんが

*4:あえてそれでも僕らのといいますが

*5:あまり決まってはいないですが