2010年代に日本のインターネットでいろんな事業をいい感じにやってきた会社から2020年代へのヒントをもらえる本を作った

半年ぶりの新刊です。『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』です。紙とPDFがセットになった直販サイトはこちら。

• Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち（紙書籍＋電子書籍） https://www.lambdanote.com/products/engineers-in-voyage

さて、今回の新刊、いろいろ疑問を呼ぶタイトルかもしれません。

• 「なぜ VOYAGE GROUP？」
• 「なぜ t_wada？」
• 「なぜ宇宙船？」

「答えは本書で！」と言って済ませることもできるのですが、ここで少し「個人的」なふりかえりをして何となく答えた気分になっておこうと思います。

なぜ VOYAGE GROUP？

もともと自分にとってVOYAGE GROUPという会社のイメージはこんな感じでした（雑な認識で本当に申し訳ありません…）。

• 勉強会とかで会場とピザとビールを提供していただく会社（「SphinxCon JP 2015」で基調講演をさせてもらった思い出深い会場）
• 社内に「ajito」という不思議なバーがある会社（『すごいErlang』の打ち上げもnishigoriさんのおかげでajitoでさせてもらえたのだった）
• そしてなによりも「あじよしさんがいる会社」

あじよしさんというのは、昔から自分が勝手にリスペクトしているソフトウェアエンジニアで、自分の中では「仙人っぽいエンジニア」カテゴリに入っている人です。 もう10年くらい昔になると思いますが、Haskellのイベントの後の懇親会で、『関数プログラミングの楽しみ』か何かの話をしたときのことをいまだに覚えています。 その前にも『プログラミングErlang』関係でどこかでお会いしたかもしれません。

そういった本を読んで自分の武器にしている強いエンジニアが長いこと務めているIT系の会社というのは、やはり何か面白いことがあるんだろうなって想像するわけです。

しかし、その会社がどんな事業をしているのかは、正直なところよく知りませんでした。 それこそあじよしさんが何年も前にErlang系の技術イベントか何かでオンライン広告の単価を決めるリアルタイムオークションの仕組みを説明したプレゼンを聞いたことくらい。 「広告配信の会社なのかな、そういえば前身にあたるECナビ（10数年前にちょっと使ったことがある）も広告いっぱいあったな」という漠然とした認識しかない状態です。

そもそも門外漢である自分は、インターネットの広告配信がどういう仕組みで成り立っているのかもよく知らず、あじよしさんの件の発表も「とにかくトラフィック多そう、やばい」という感想どまりでした。 だって、大きなウェブメディアでどれくらい膨大なトラフィックがくるのか想像もつかないけれど、 「あるウェブページをブラウザで表示したときの広告の単価がリアルタイムで毎回動的に決まっている」なんて外野には思いもよらない知らない世界です。 日々ぼーっとインターネットを眺めていると「もう広告ってGoogleとかFacebookみたいな大会社の領分になったのかな」って錯覚しそうですが、 日本の会社でそんな得体のしれない高トラフィックな仕組みをErlangで実装してビジネスをしているらしい。

そんな雑駁とした「すごい」という認識しかなかったVOYAGE GROUPのCTOである小賀さんから、ある日「tech bookを作りたいと思ってるのだけど…」という相談を受けたのがすべての始まりでした。

「VOYAGE GROUPのtech book」と聞いて自分がまっさきに無邪気に思い描いたのは、 「現代のウェブ広告配信を支える技術を解説するような本ができるのかな、それはとても面白そうだぞ」という専門書脳の企画でした。 しかし実際に小賀さんとお話をしていると、どうやらVOYAGE GROUPにおいて広告配信の事業は氷山の一角っぽい、ということがわかってきます。 実際にはもっといろんなことをやっているし、広告配信にしても単にトラフィックさばければいいわけでもないっぽい。 しかも、それぞれの事業にあじよしさん級のすごいソフトウェアエンジニアがごろごろいるらしい（冷静に考えれば当然）。 そういえば、某チャットなどでオンラインだけでは接点があったはぎーさんもVOYAGE GROUPだったのでは？（いまいち繋がっていなかった）。

小賀さんとお話しながら、「これはもうVOYAGE GROUP全体の技術者文化を伝える本のほうが面白いな」という方向へ舵を切り、 「それなら t_wada さんっていうぴったりの人がいるので彼の力を借りられれば…」という話になり、 「どうなるかわからないけど、やってみるしかないね」となったのが、ちょうど2020年を迎えようとしていた頃でした。

なぜ t_wada？

簡単に言うと、t_wadaさん本人による「はじめに」にもあるように（ここで全文が読めます）、 t_wadaさんはVOYAGE GROUPの技術コーチをされていて中の技術者を知っているだけでなく事業に対する理解もあったからです。

個人的に言えば、「t_wadaさんと仕事ができる！」ことに望外の喜びもありました。喜びというよりも、「ならば、やらない道はない」という覚悟に近かったかもしれません。 t_wadaさんとはアジャイル開発に関係する本をいろいろ企画編集していたことから何となく知己はあり、 「『テスト駆動開発』の再刊に向けた打ち合わせ」といった形でお仕事上の関係がまったくなかったわけでもないのですが、 同書は自分の担当ではなく（出版されたのも自分が会社を辞めた後）、これまで直接お仕事をする機会には恵まれなかったのです。 小賀さんから打診してもらった結果、「執筆するのは厳しいけれどインタビュワーならぜひ」と言っていただけて、自分にとっては「棚から牡丹餅」とさえ言える座組が完成したというわけです。

にしても、t_wadaさん、本当にすごいインタビュワーだった。 文章にするため毎回のインタビュー（と後半ではshownote作成のためのランチにも）に同席していたんですが、「こんなん、t_wadaさんしか聞き出せないでしょう」という話がぽんぽん出てくるわけです。 毎回毎回、「ああ、自分はこういう話を知りたかったんだよなあ」と思っていました。

ここで「こういう話」っていうのは、具体的にいうと、「インターネットで事業にかかわる開発者たちが日々どんなふうに仕事をしているのか？」です。 自分は、ソフトウェアエンジニアが読むような本を作ったり記事を書いたりしているし、技術的なことは何となくわかりますが、 ソフトウェアエンジニアとして会社勤めをしたことはないので、その辺はふつうの会社（もっというと出版社）での経験からの類推でしかわかりません。 「技術をお金に換えること」に対する実感があまりない、とも言えます。

そんな自分が毎回のインタビューに同席していて特に面白かったのは、そういう泥臭い部分に対峙する現場の姿がインタビュイーからぽつぽつと引き出されてくる瞬間です。 そういう感覚を特に強く持っている人たちへのインタビューだったからかもしれないけど、 そうやって「別に隠されているわけではないけれど実際に最前線で事業を回している人しか体験できない話」が聞けるのは本当に貴重な時間でした。

おかげで、自分自身の「お仕事」に対する意識もだいぶ磨かれた気がします。 表面的な業種は違うけれど、出版もまたソフトウェア産業と同じく情報を扱うお仕事であり、なんならソフトウェア産業そのものという側面もないわけではないので。

とにかく、今回お仕事を一緒にさせていただいて改めて実感したのは、「t_wadaさんはテストを書かないとやってくるライオンというだけではない」ということです。 インタビュイーからはもちろんですが、そんなt_wadaさんの心構えからも「ソフトウェアという仕事に向き合うヒント」をいっぱいもらった気がします。 そして、うまくいっているといいんですが、それが本書の内容にも反映されていればうれしいです。

（ちょっと話はずれるけれど、全6回のインタビューのスケジューリングをはじめVOYAGE GROUP社内の調整を完全にお任せした丹野さんの仕事っぷりからも、自分自身の日々の仕事に対するいい加減な姿勢を大いに反省させていただきました…。本当にお世話になりました。）

なぜ宇宙船？

今回のカバーデザインは、『テスト駆動開発』などのデザインも手掛けた轟木さんです。 「この本はどういう本であるか」を早口でメールでまくし立てたしたところ、頂いた装丁案のひとつがこれでした。 かっこよさにもいろいろありますが、「この本らしいかっこよさ」があふれ出ている最高にロックな装丁になったと思っています。

で、結局のところどういう本なの？

本書を作っていて自分がいちばん強く感じたのは、「恥ずかしながら自分はインターネットで事業をするってことが全然わかってなかったんだな」という点です。 技術的にもビジネス的にも、この10年にインターネットやウェブでどういうトレンドの変化がありどういうふうにお金が生まれているのかについて、だいぶ無自覚だったなと。

逆にいうと、本書を読むとそれがわかるのではないかと思います。 「2010年代に日本のインターネットでいろんな事業をいい感じにやってきた会社から2020年代へのヒントをもらえる本」と言っていいかもしれない。 実際、インターネットで働いている人であれば、この「補足解説一覧」を眺めるだけでも何かしら心に引っかかるトピックがあるでしょう。

• アドテクノロジーの変遷
• オンプレミスかクラウドか
• VOYAGE GROUPの「グレード」と「技術力評価会」
• インプレッションとそのカウント方式
• SREに対する考え方
• リファクタリングと作り直しの違い
• オブザーバビリティ
• 広告におけるプライバシーの課題
• アドテクノロジー業界でよく使われる用語
• MVP（Minimum Viable Product）
• フルサイクル開発者とは
• Zucksのシステム構成
• XPとケント・ベック
• 2025年の崖
• リバースエンジニアリングが「お花畑」に
• 技術的負債とレガシーシステム
• IaC（Infrastructure as Code）
• PHP OPcacheによる葬り無双
• 葬り無双の効果
• SEO（Search Engine Optimization、検索エンジン最適化）
• 静的サイトジェネレータによる構成
• CMSと静的サイトジェネレータ
• AWS CodeBuild による記事の並列ビルド
• 静的サイトジェネレータで動的なコンテンツをどう実現するか
• BtoB であると同時にBtoC なサービスを支えるシステムを作る
• データベース設計の意図をたどれるようにする
• 実装から距離をとってテストを書くことで独立性を保つ
• 統計的機械学習と予測
• ファーストプライスオークションで入札額を決めるアルゴリズムの概要

絶対おもしろそうでしょ？

気合い入ってます

というわけで、2020年1月からたくさんの方々と協力してコツコツ作ってきた本がついに形になりました。 いろいろな思いがあります。でも要約すると、大芝浜祭で自分のアニメを両親にぶつける水崎ツバメと同じ気持ちかもしれないなと思います。

気合い入ってます！ 読んでください！

本書の制作にあたってはVOYAGEさんからの金銭的な支援も多分に受けました。 その分、ふつうの出版社だったら実現が難しかったであろう濃い本が作れたと確信しています。 やはり水崎ツバメの言葉を借りるならば、「インディーズ出版社が生きるってことは、こういう本をつくるってことなんだ！」という気持ちです。

■

昨晩、『コンビニ人間』という原作の存在を知らずになぜか買って積読していた“Convenience Store Woman”を一気に読んだ。英訳されたほうを読んでよかった。たぶん日本語だったら中盤でつらくなって、短い小説だけどきっと挫折していた。

この小説で主人公は、コンビニ店員として生きていることに不満がない、というかむしろコンビニ店員に生きがいを感じているんだけど、同時にそのマインドは周囲からは決定的な社会性の欠如であり欠陥だと見なされている。主人公のマインドは、任意の専門職における「一生現場で働きたい」とまったく同じだ。それが「コンビニ店員」という非正規雇用しか選択肢がない業界であるばかりに、どんなにプロフェッショナルであっても、社会的弱者と同義にされ、それに甘んじているダメな人間という扱いしか受けない。もちろん、勤務先のコンビニでは圧倒的な戦力なので評価はされているんだけど、ある事件をきっかけに、その勤務先にも社会性による評価軸が持ち込まれてしまう。

あらすじはWikipediaに書いてあるのでネタバレにならないと思うのだけど、主人公はいろいろあって最後にはコンビニ店員として生きるという決断をする。日本語で読んでいたら、暢気な主人公を追い込む周囲の人間の描写で細かいニュアンスが読み取れすぎて、おそらく最後まで読み進められなかったような気がする。とくにバーベキューパーティーと終盤の職場の登場人物たちは、「汎用の社会性よりもプロフェッショナリズムを好む人間の日常のすぐ隣に潜むウェイ」という恐怖がにじみ出ていて、外国語で読んでいても泣きそうになった。もちろん、そういう描写があるから主人公の最後の決断がいきるとはわかっているけど、やはりきつい。

gitで2つのリポジトリを混ぜる戦略を考える

「2つのgitリポジトリがあって、その片方をもう一方に取り込みたい」という状況を考えます。依存ライブラリのソースを自分のプロジェクトで保持したい、といった状況が典型的でしょう。

この場合、通常は git submodule を使うと思います。 git submodule であれば、他のプロジェクトを履歴ごと自分のソースの一部として管理できて、かつ双方の履歴をきれいに分離できます。

• Git - Submodules

ただ、双方の履歴が分離できるということは、双方の履歴を混ぜられないということでもあります。そのため、 git submodule は、他のプロジェクトのソースに自プロジェクト独自の変更を加えて管理するといった用途には向かないように思います。ではどうすればいいだろうか、という試行錯誤の記録です。

文章で書くだけでは状況がよく見えないので、本稿では主に図で状況を示します。 なお、2つのリポジトリにおけるコミットの状況を図示していきますが、実際の作業はこれらをローカルへcloneして行うことになるので、適宜読み替えてください。

git submodule で取り込む

いま、自プロジェクトをgitリポジトリAで管理しており、そこにgitリポジトリBで管理されている他プロジェクトを取り込みたいとします。ここで、セオリー通りに git submodule を使い、AにBを取り込むとします。

$ git clone [AのURL]
$ git submodule add [BのURL] [取り込み先のディレクトリ]

このときの状況を図示するとこんな感じです。

以降、図中の色と記号はこう読んでください。

• gitリポジトリAでのコミット：白（ギリシア文字）
• gitリポジトリBでのコミット：緑（英小文字）
• もともとAで管理していたファイルへの変更：〇
• もともとBで管理していたファイルへの変更：□

「Aのcloneにおけるsubmoruleへの変更をAのリモートのみに push 」はできない

ここで、submoduleとしたディレクトリ内で何かを変更してコミットし、その変更をリモートで共有したいとします。 submoduleへの変更を含めてpushする必要があるので、そのディレクトリ内で git push するか、 git push --recurse-submodules=on-demand を実行することになります。

このとき、このpushはAのみならずBにも適用されます。これをAのみに適用する方法はなさそうです。

この挙動は、「双方の履歴が独立している」というsubmoduleの意図には合致していますが、Bに伝播させたくないA独自の変更をB由来のファイルに施したい場合には困ります。 そうしたケースに対する対策としては以下のような方法が考えられそうです。

• Bで「A専用」のブランチを切ってそれをsubmoduleで取り込む
• Bをフォークして「A専用B」のリポジトリを作る

ただ、Aがプライべートだったり、専用にカスタマイズしたBを使いたいAのようなプロジェクトのgitリポジトリが増えたりすると、これらの対策ではあまりうれしくありません。

「B由来のソースをAの内部で独自に管理する」とBの上流の変更が取り込めない

では、AではBの履歴管理とは完全に独立してB由来のソースを使うのはどうでしょうか？ たとえば、先ほどの状況でBへのpushが起こってほしくないので、submoduleについては「ローカルにcloneしたリポジトリ」での履歴管理だけで我慢する、という手はありそうです。

しかし、これだと、当然のことながら「submoduleの内容に依存するAの変更」をリモートで共有できません。 また、下図のように、Bの変更をあとで取り込むこともできません。

git subtree で履歴を完全に混ぜる

結局、やりたかったことに一番近い解決策は、「A内でのB由来のファイルに対する履歴をAの履歴と完全に混ぜる」になりそうです。 それを実現する方法はいくつか考えられます。

• git subtree を使う
• Bを取り込む専用のブランチを作り、その変更を主たるブランチに随時マージして使う（その際、混乱を避けるために git worktree を使うとよさそう）

やりたいことを図にするとこうなります。

ここでは、上記を git subtree で実現する手順をメモしておきます。 git subtree については下記の記事を参考にしました。

• Git Submodule の代替: Git Subtree - Atlassian Japan 公式ブログ | アトラシアン株式会社

まず、Aをcloneしたディレクトリ内で、Bをリモートとして追加します。 そのBを git subtree で指定のディレクトリにとってくる、というのが基本的な流れです。 gitコマンドとしては以下の2つを入力すればOK。

$ git remote add -f [B用のリモートの名前] [BのURL]
$ git subtree add --prefix [Bを取り込むディレクトリ] [B用のリモートの名前] [Bのブランチ] --squash

# あとはふつうにgit pushすればAのリモートのみに変更が反映される

もし仮に、ここで「Bにも変更を戻したい」場合には、 git subtree push というコマンドを使って「そのための差分」を作り、それをGitHubのPull Requestなどで上流に送ればいいようです。 しかし、Aの履歴が混ざっているので、うまくやらないとうまくいかなそう（やってないのでわかりません）。

一方、Bの上流の変更をA内のB由来のファイルに適用するのは簡単です。簡単といっても、もちろん衝突は覚悟しないといけませんが…。

$ git fetch [B用のリモートの名前] [Bのブランチ]
$ git subtree pull --prefix [Bを取り込んだディレクトリ] [B用のリモートの名前] [Bのブランチ] --squash

git worktree を使った方法もそのうち試してみようと思います。

謝辞

この状況を考えることになったきっかけは、下記のなにげないツイートでした。

gitで管理しているプロジェクトAの内部で、やはりgitで管理されている他のプロジェクトBを利用したい場合、いつもはsubmoduleにしているのだけど、これだと利用されるほうのプロジェクトBをA専用に改造してその履歴をgitで管理することはできない（と理解している）。どうすればいいんだろう。

— keiichiro shikano λ♪ (@golden_lucky) May 3, 2020

このツイートにコメントをいただいた @anohana さん、@ymotongpoo さん（と某チャットで付き合っていただいたみなさん）、@soranoba さん、@YukiharuYABUKI さん、ありがとうございます。おかげで自分が本当は何をしたかったのか整理できました。とくに @soranoba さんには git subtree の存在を教えていただき本当に助かりました。

みんなが出版社になれるのか

「本の編集者は何をしているのか」を書こうとしていて、もう何か月もまとまらなので、とりあえず「出版社が何をしているのか」を書いておきます。

素朴な出版社のイメージ＝中間搾取者

とくに出版業界に興味がない人からみた出版社のイメージって、おおむね「著者と読者の間にいるやつ」という感じだと思います。 絵にするとこんな感じ。 著者の立場からすると「本を出すときにお世話になる会社」で、読者の立場からすると「著者が書いた本を書店で買えるようにしてる会社」ですね。

この絵のイメージで出版社を捉えると、「原稿から本を作るコストはかかるだろうけど、中間にいるだけで本の売り上げの大部分が懐に入るのか。やはり既得権益は強いな」という印象を抱くのではないでしょうか。 そんな中間者はインターネットの力で取り除いてしまうべきなのでは？

とはいえ、個人で個人の読者にモノを売るのはインターネットだけではやはり面倒です。 そこで、「著者が原稿を個人の読者に売るためのサービス」がいくつも登場して広範囲に利用されています。 AmazonのKindle ダイレクト・パブリッシングとかBooth、あるいは日本ではまだなじみが薄いLuluやLeanpubなどです。

以降、本記事では、これらをまとめて「個人出版支援サービス」と呼ぶことにしましょう。 これら個人出版支援サービスの多くでは、電子書籍であれば著者の取り分が80%とか90%とかに設定されているので、従来の出版社はほんとに中間搾取者だったんだなあという思いをあらためてかみしめられますね。

「個人出版サービスなら90%の取り分が出版社経由だと10%程度にしかならない」というのは、著者から見ると紛れもない現実です。 が、この差はほんとうに出版社による中間搾取の結果なんでしょうか？

出版社そのものは販売網ではない

ここでちょっと立ち止まって、個人出版支援サービスが著者に対して何を提供しているかを考えてみると、それは販売網としての機能だろうと思います。 著者が原稿を個人の読者に売りたいが、それは大変なので、そのプラットフォームを一手に引き受けるサービスというわけです。 原稿を本の整形してくれる機能がついていたりもしますが、それはおまけみたいなものでしょう。

従来の出版業界でこれと同じ機能を担っていたのは、出版社ではなく、取次と書店です。 その意味で、個人出版支援サービスが著者に提供するのは出版社の機能ではなく、取次や書店のそれです*1。

ただし、従来の出版業界の販売網には「出版社だけしか利用できない」という事実上の制限があります。 逆にいうと出版社には、従来の出版業界の販売網を利用できる唯一の存在としての価値があります。 そこに、個人でも容易に使える新しい本の販売網として登場したのが個人出版支援サービスだといえるでしょう。 おかげで「著者の原稿を読者に届ける」ためだけに出版社を使う必要はなくなった、ともいえます。

販売網への窓口は出版社の機能のごく一部

著者が個人でも利用できる販売網がある状況で、わざわざ出版社から本を出すのは、一見するとバカげているようにも思えます。 確かに、「自分が書いたそのままを読者に届ける」ことが目的なら、そのために出版社を使う必要はべつにないかもしれません。 そういう人にとって出版社を使うのは割高です。

しかし出版社は、従来の販売網への窓口として読者と著者の間を取り持っているわけではありません。 出版社が「読者と著者の間を取り持っている」のは間違いないんですが、それは「著者」→「読者」という一本のラインの上で両者を仲介しているという意味ではなく、最終的な本のための原稿を著者と一緒になって作っているという意味です。 著者、出版社、読者のリアルな位置づけを絵にするとこんな感じです。

さらに個人出版支援サービスの存在も考慮すると、こんな感じになります。

出版社＝売り物の本の専門家

先の絵を見てもらうと、「出版社は販売網としての役割をそもそも担っていない」という先の主張がよりクリアになると思います。 そして、「出版社は最終的な本のための原稿を著者と一緒になって作っている」という主張も、なんとなく伝わるのではないかと思います。 ほとんどのまともな出版社は、著者が書いた原稿の「てにをは」を直して組版して販売網に流すだけでありません。 「売り物の本」の専門家として、企画段階から著者との間でかなりのインタラクションを繰り返しながら、最終的な本の原稿を一緒に作り上げています。

この「売り物の本の専門家が本を作るのを手伝ってくれる」という機能は、私見では、出版社がもっとも価値を発揮できる部分です。と同時に、もっともコストがかかる部分でもあります。 しかし、「売り物の本」って、なんかふんわりした表現ですよね。 そんなふんわりした表現でしか説明できない微妙さがあるので、出版社の最大の武器として俎上に載せにくいなあと常々もどかしく思っていたりもします。 ぶっちゃけ、販売網の独占的利用という点に価値を示せなくなったいま、出版社の将来を左右するようなポイントであるとさえ思っているんですよね。 なのでもうちょっとうまく言語化したい。

まとめのようなもの

個人出版支援サービスのようなものとの対比で「従来の出版社は…」と感じるときがあったら、それはきっと出版社の使い方を間違っているかもしれません。 あるいは、売り物の本にするのを手伝う専門家として機能できていない出版社と付き合っているのかもしれません。

*1:念のため補足しておくと、これは取次や書店が中間搾取者だったという話ではありません。それぞれ、本という商品のディストリビューターとして、個人出版支援サービスと同じ10%～20％程度の取り分でずっとやってきているはずです。このへんが本というコンテンツのディストリビューターとしてビジネスをやっていくための妥当なラインなのかもしれません。

2020年 年賀状

2年ぶりにPostScriptしました。

github.com

コードを見てもわかりにくいかもだけど、「2と0をランダムに並べた配列を作り、 2020 という文字列が完成した場合にだけ色をつける」というロジックとしては単純なプログラムをPostScriptで手書きしています。

スタックに対する操作でプログラムを書くことで名高いPostScriptですが、データの格納にはarrayも使えて、これの操作にはわりとコツがいる、ということがわかりました（具体的には、put 操作をしても結果の配列がスタックに載らないので、 dupなどしておかないといけない）。

出版社を作って4年が経ちました

ラムダノートという出版社を作って4年が経ちました。

www.lambdanote.com

去年に引き続き、今年もちょっとふりかえりをしてみます。 この記事はラムダノートの技術 Advent Calendar 2019の25日めのエントリーです。

第4期（2018年12月～2019年11月）のふりかえり

『n月刊ラムダノート』はじめました

今年は『n月刊ラムダノート』という不定期刊行誌を3月に発行し始めました。 去年のふりかえりで第4期の目標として掲げていた「単発の本じゃない形で濃い技術情報をお届けする新企画」は、これのことです。

ぶっちゃけ、技術書、読むの大変じゃないですか？ 正直なところ、作るほうもかなり大変です。 技術書に限らず、いま出版社が次々に新刊を出しているのは、半ば商売を維持するためという構造的な側面があります（それだけが理由ではないです）。 読む人も作る人もさまざまな無理感を抱いているなかで、それに飲まれるのはつらい。

そもそも、技術書を読んだり作ったりするというのは、そんな悲壮感が漂う行為ではなかったはずです。 実際、同じように読む人も作る人も大変という状況にあっても、その限界な状況をお互いが楽しめる場もあるのだと知りました。 いわゆる技術書典というやつです。 そこで感じた「こういうのでいいんだよこういうので」に対する技術書を作ってきた側としての試みが『n月刊ラムダノート』だとも言えます。

そもそも執筆してくれる人を募るところから不安でいっぱいでしたが、ありがたいことにエッジな方々から記事を寄せていただけて、1年めのVol.1は「No.3」まで出すことができました！ こうやって一覧するだけでどれも読みたくなりますね。

Vol.1, No.3（ワインレッド）

1. 代数的データ型とパターンマッチの基礎（κeen）
2. パターンマッチ in Ruby（辻本和樹）

Vol.1, No.2（ミカンオレンジ）

1. LISP 1.5の風景（川合史朗）
2. 計算機科学から見たディープラーニング（今井健男）
3. Q#で始める量子プログラミング（田中孝佳）

Vol.1, No.1（セルリアンブルー）

1. TCPの再送制御機構（西田佳史）
2. 「コルーチン」とは何だったのか？（遠藤侑介）
3. MLOps の歩き方（有賀康顕）

いまは次号に向けた準備をしています。 完全にぼくがボトルネックな状態になっており、すでに原稿を頂いている皆様には本当に申し訳ありませんが、引き続きよろしくお願いいたします 🙇‍♀️

とはいえ、企画が余っているという状態ではまったくないので、すでに執筆をお願いしている方、寄稿したら面白そうなネタがあるという方、寄稿させたい人がいるから紹介するという方、次の次の号あたりの掲載を目指してぜひご連絡ください。

www.lambdanote.com

なお、『n月刊ラムダノート』は現在のところ自社サイト直販のみ送料無料という販売方法をとっており、書店での販売はしていません。 が、これはテクニカルな問題によるもので、この販売方法にこだわっているというわけでもなく、もし取り扱いたいという書店さまがいたらご相談ください。 今期はいろいろ模索していきたいと思います。

あと、いちばん重要なことですが、紙版は在庫いっぱいなのでぜひお早めにご注文ください。 宅配便ではなくポスト投函ということもあって年末年始のお届けはもう無理なのですが、「お正月には電子版で読んで紙は年始に届いたのを会社にもっていく」とかどうでしょう！

技術書典7に落ちた

落ちるんですね…。 その日だけ半ば思いつきで電子版半額セールをしたのですが、予想を大きく超える数の注文を頂きました。本当にありがとうございました。 この規模の割引セールをする余裕はあまりないのですが、これを機に当社の存在を知ってもらえたような気もするので、率直にうれしかったです。

個人的には、セール中に技術書典7の運営のお手伝いをしていたので、サーバ（ShopifyでなくPDFを生成配信してるほう）が落ちないかはらはらだったよ…。

現金が足りなくなりそうになった

落選セールの売り上げがなかったらまじでまずかった。 綱渡りが続きます。

新刊は『プログラミングHaskell 第2版』

いろいろあって（主に訳者の @kazu_yamamoto さんのおかげ）、当社から「第2版」を出せました！

プログラミングHaskell 第2版（紙書籍＋電子書籍）www.lambdanote.com

この本には個人的にはやはり思い入れがあり（前の会社で携わった本にはどれも思い入れがありますが）、とくに「改良したい」と思っていたところを改良できてよかったです。 完全に新しい本になっているので、旧版を持っている方にも価値があると思います（旧版の知識だけで現在のHaskellの型クラスを理解するのは厳しいと思う）。

ただ、『n月刊ラムダノート』をがんばっていたのもあり、第4期の書籍新刊はこの1タイトルのみでした。 このへんが経営的な課題としてあるのかもしれませんが、新刊をたくさん出さなくても生きのこる出版社を目指します。

第5期（2019年12月～）

そんなわけでラムダノートは第4期をなんとか生き延び、2019年12月から第5期に入りました。 年初にいきなり役員借入金（経営者から会社への資金貸し出し）が発生するらしい（白目）。 ただ、こちらのうかつなツイートに対してほんとにたくさんの応援を頂き、幸いにも必要な金額はだいぶ少額になりました。ありがとうございました！

弊社、年明けにいきなり現金がショートの見込に。みんな本買って！ できればn月刊買って！ https://t.co/ip9zCmkOIk

— keiichiro shikano λ♪ (@golden_lucky) November 22, 2019

最後に、来期は「いろいろな意味でうちでしか作れないであろう本」をいくつか発表できそうです。 お楽しみに！

直販サイトを作って書籍を売ること

昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の話で締めくくろうと思います。

現在、日本の出版事業の中心は、「版元」「取次」「書店」という3者（いわゆる業界三者）が担っています。 メーカーと小売りの間に卸しがいるという構造は特別なものではありませんが、業界三者がちょっとだけ他と違うところがあるとしたら、書店と版元との柔軟な直接取引が少なく、取次-書店間、取次-版元間での委託取引が中心になっていることです。 この構造を支えているひとつの柱は再販価格維持制度による書籍の定価販売なんですが、この構造のおかげで、日本はかなり書店の数が多い国であり続けました。 2000年代初頭には全国で2万店くらいの本屋さんがあったようです（参考）。 米国の書店数も同じころにやはり2万店くらいだったらしいので（参考）、ほんとに本屋さんいっぱいあったんだなあ、という気持ちです。 いまは12000店を下回っているようなので、この20年で6割くらい、たぶん平成の間に1万店以上の書店が全国から消えたことになりそうです。

書店が少なくなったということは、当然、本を売る場所が減っています。 その一方で、新刊の発行点数は、同じ期間に毎年最大で3%ずつくらいの増加傾向にあります（参考）。 売る場所が少なくなったのに、新しく売るものの数が増えているということで、いろいろ嫌な想像が働いてしまいますよね。 ただ、少なくともこれだけはいえると思います。 読者の立場で考えたとき、「ふらっと書店に出かけてそこでたまたま1冊の本に巡り合う」といった機会は、じりじりと得難い貴重な体験になってきているのです。

そんな中で新しい出版社を立ち上げることにした当社では、書籍の主な販売チャネルとして「自社運用の直販サイト」を前提にした事業計画を立てています。 本当は取次さん経由で書店店頭でも買ってもらいやすくしたいとは常々思っているのですが、営業の専任がいないこともあって、この直販サイトで読者の皆さんから注文を頂く、つまり「小売業」が事業の中核です。

幸い、直販サイトを自分で立ち上げて小売業をするのは本当に簡単な時代になりました。 いろいろな選択肢があると思いますが、当社はShopifyを採用しました。 直販サイトをオープンした直後の2017年3月にカナダ大使館で「日本初のShopifyミートアップ」に参加した記憶があるので、ちょうどShopifyが日本市場に本腰を入れようとしていたころでもあったみたいです。 最近は山手線の車内でもShopifyのCMを見かけるので、ちょっとどきどきしています。

Shopifyのよいところ

Shopifyを採用した最大の理由は、APIが公開されていて自分でアプリケーションサーバを作れることです。 当社では、電子書籍を売りっぱなしにするのでなくアップデート版の継続提供などもしたいと考えていたのですが、そういう仕組みを最初から持っている小売サイトのためのプラットフォームはあまりありません。 そのため、販売サイトのガワのデザインだけでなく必要なアプリまで自分たちで作れるShopifyが魅力的でした。 むしろガワのデザインをへんに凝るつもりはなかったので、デフォルトでそれなりに満足できるのがありがたかったです。

あと、これは使ってから気づいたのですが、バックオフィスのための管理画面がものすごくよくできています。 いまはぼく自身が発注作業をすることはなくて、バックオフィス業務は共同経営者にお任せなのですが、管理画面が玄人向けすぎるとそうもいかなかったはずです。

さらに、Amazon PayやGoogle Payに早期から対応してきたこと（Apple Payも利用できるけどトラブルが多いので停止中）、手数料がお値打ちなPayment Gatewayが利用可能になったこと（実質Stripeで手数料が安いのはまじでありがたい）、コンビニ振込のKOMOJUに対応していて現金指向のお客さんもサポートできること、振込サイクルが1週間なこと、クレカ詐欺の検知機能（ちょっとシビアすぎる気もするけど）など、書籍のように単価が低い商品で小売をやっている当社のような立場にとって切実な点で地味にありがたい設計になっているのも助かっています。

Shopifyにがんばってほしいところ

いろいろあるといえばあるんですが、チェックアウト画面のデザインがたまに崩壊するようなので直ってほしい（チェックアウトまわりは欧州対応のために画面構成をユーザがいじれない）。あと、APIのタイムアウトがWeb経由だと厳しい（ぼくだけが使うものはCLIでいいんだけど）。そういう細かい点くらいで、大きな不便は思いつかない気がします。

できればこのままWebの雰囲気に十分なじんでいる出店者にとって使い勝手がよいサービスであり続けてほしいです。

謝辞

これまで当社のサイトでお買い物をしていただけたすべての皆さま、物流をお願いしている明和流通システムの皆さま、本当にありがとうございます。これからもよろしくお願いします。

Shopifyがないとやっていけないので、ShopifyとShopifyを支えているRubyおよびRailsの開発者の皆さまには本当にありがとうございます。

最後に、当社の直販サイトの使い勝手やワーディングに何らかの良さがあったとしたら、立ち上げ前から今に至るまで折に触れて @miwa719 さんと @m_seki さんから有益なテストとフィードバックを頂いているおかげです。あのチームすごい。