ラムダノート第5期の出版活動の個人的ふりかえり
設立からあっという間に5年が経過し、さらに出版で収益が出るようになってから4年が経とうとしている（最初の1年間ちょっとは何も本を出していなかったので）。 既刊の点数も10を超えた。 なんとなく、この第5期は、気づいたら出版社としてのトンネルを1つ抜けた一年だったように思う。
第5期は、2本の新刊単行本と、1本の『n月刊ラムダノート』を発行した。
新刊2冊は、思いがけず企業さんとのタイアップという形で実現した企画だった。 といっても、どちらも著者を見ればわかるように、技術を解説する本という点で妥協はない。 むしろ「第三者視点では外に出ることがあまりなかった情報」を書籍という形で世に出せたことが個人的には大きいお仕事だった。
もうちょっと補足する。
現在は、コンピュータ技術の解説書というと、ソースコードや論文であったり、仕様やリファレンスであったりをベースとした内容であることが多い。 これらは一般に公開されている情報だ。 インターネット時代のコンピュータで使われている技術は、このような公開の情報をベースに本を書けることが多い。
しかし、そういう公開の情報を集めるだけではなかなか理解がしにくい技術というものもある。 特定の企業によるプロプラな技術だけど社会の基盤になっているような技術がその代表だ。 とくにネットワーク関連技術は、歴史的、政治的、経済的な経緯もあって、そういう状況にある話題が多い分野だよなと個人的には感じている。 インターネットだけが通信ネットワークになってしまった現代では想像しにくけど、ほんの20年前くらい前はコンピュータ通信といったら時分割多重化されたデータを回線交換機を介してやり取りしていたわけで、そこで回線交換機がどう運用されるのかとかを知りたかったらNTTの中に入って直接聞くしかなかった。 2020年1月に発行した『徹底解説 v6プラス』は、まさにそういう時代からの影響があってはじめて理解できるような技術を、中の人の全面協力のもとで書くならこの人しかいないでしょうという唯一無二の執筆者によって形にできた本だと思っている。
そして技術には人間の営みがどうしても織り込まれてくる。 仕様策定プロセスや開発がオープンであれば、そこから当該の技術を成り立たせている論理や文化をある程度までは伺い知れるけれど、一般に「その技術を実際に支えている人たちがもっている技術」は本当に外部には伝わりにくい。 でも、その伝わらない部分もまた技術なのであり、技術書のひとつのテーマとして面白いだろう。
こうした「とくに隠しているわけではないけど非公開になっている情報を本にする」というのは、ちょっと考えればわかるようにとても難しい。 これが、外部からの「その話、知りたい」という圧が十分に高い可能性があるような話題なら、まだコンテンツとして成立しやすい（みずほ銀行のシステム開発の本とかはその好例）。 しかし、外部からの取材をゼロから始めて本にしようと思ったら、当然それだけのコストや年月がかかるので、おいそれと企画できるものでもない。 なんだけど、やはりチャンスがあれば企画したいと常々思っていた。
そんな中で、まさにそういう本を作れる機会をもらえたのが、2020年8月に発行した『Engineers in VOYAGE』だった。 Webで事業をやっている会社の中で技術者たちが何をしているか、そういう会社で働いているソフトウェアエンジニアには当たり前かもしれないけど、そもそも外部の人間や技術者でない人間には知りえない話で、でもみんなそれなりに興味はある。 ソフトウェアエンジニア自身だって、自分が知らない他社における技術者の文化には興味があるだろう。 まさにそういう本を、やはり「この本を作るならこの人が手掛けるしかないでしょう」というインタビュワーと、そのインタビュワーでなければ汲み尽くせないであろう深い技術者文化を培ってきた会社の全面協力で実現したのが、『Engineers in VOYAGE』の企画だった。
正直、どちらの本も、これだけの座組をぼくの主導と当社の企画力だけで実現することは不可能だったと思う。 そういう意味で、こうやって企画をふりかえると、第5期はなんというか、本当に幸運に恵まれたなあというか、「いつかやりたい」と思っていることは案外とふいに実現するものなんだなあというか、そういう一年だった。 これからも「こういう本を作りたいんだよなあ」みたいな意識をぼんやり抱えてやっていこうと思います。
一方で課題もある。まずは『n月刊ラムダノート』だ。一昨年に始めた不定期刊行誌だけど、昨年は1本しか形にできなかった。 原因は完全にぼくの力不足です。 ぼく自身の企画のタコツボ化を回避したくて寄稿ベースという形をとったのだけど、無から何かが生まれて結実するはずはなく、ネタをもらっても前に進めて完成させるための動力がいずれにしても必要になるのだよな。 そして、そのための動力が去年の自分には足りなかった。
もうひとつの課題は翻訳書だ。いくつか版権を購入したまま進められていない本があるのでやっていく。どれも面白いよ。
新しい期になって、すでに新刊『Webブラウザセキュリティ』を発行した。 こちらもまた思い入れがあるので、近いうちに個人的なふりかえりを書く予定でいる。
独学でプログラミングを勉強した自分がこれは役に立ったなと思っている本
今ではプログラミングできないわけではないけど、そういえばプログラミングは完全に独学と言っていい。 いや、大学では数学をやっていたので、FortranとかLispはちょっとやった。 なので「完全に独学」といったら嘘になる。
それでも、いま仕事で使っているコンピューターの知識は、基本的にすべて書籍を通して独学したものだ。 そこで、自分が何の本を読んでプログラミングを実務で使えるくらいにはなれたのか、アフィリエイトと宣伝を込めつつちょっと振り返ってみてもいいかなと思って走り書きしてみる。
テキストフィルターを書きまくるとこから始めるといいと思う
プログラミングぜんぜんやったことない人が「プログラミング完全に理解した（ダニング・クルーガー的な意味で）」という実感の端緒を得るまでには、まず「テキストフィルタを書きまくる」のがわりと近道だと信じている。
コンピューターを使うことがインターネットを使うことと激しく重なっている現代、ブラウザで動く何かを作るところから始めたくなる気持ちはわかる。 しかし、とにかくテキストフィルタをたくさん書く、という経験には、プログラミングの独習者にとって次のようなメリットがあると思う。
- テキストデータのありがたみを思い知れ
- コンピューターとのやり取りの仕方（標準入出力）に慣れろ
これほどブラウザで動く何かが全盛でなかったころのプログラミング初心者本にも、「デスクトップのアイコンをクリックして実行できる何かを作れると初学者のモチベーションにつながるよね」みたいな空気があった（要出典）。 これは現代においてはブラウザ上で動くプログラムとかスマホのアプリになるように思う。 しかし、「プログラミング未経験者にとって身近なプログラム」というのは、プログラムを書けるようになれば誰もが気づくように、コンピューターからユーザーを遠ざけるようにうまく抽象化されてるものなんだよな。 そういうのからスタートしてしまうのは、（アプリケーションを通してでなく）コンピューターを操るための手法としてのプログラミング（プログラミングスクールに行く人が知りたいのはこれだと信じている）を学ぶには、実はそれほど適さないんじゃないだろうか。
で、思い返すと、自分は 『Rubyで極める正規表現』 という本を通してテキストフィルタの書き方みたいなものを学び、そして書きまくっていた。
この本、正規表現の本というより「楽しいテキストフィルタを書けて楽しい！」というノリの本で、筆致もよく好きなんだけど、いかんせん古くて環境が合わないと思うので、あまり初心者におすすめできる感じではないのだよな…。
今でもテキストフィルタいっぱい書く本はプログラミング入門にはいいと思う。でも現代において該当する本といったら何があるだろう。いまいち面白みのない例題かつページ数が多いけど、 『退屈なことはPythonにやらせよう』 とかだろうか。
プログラミング言語そのものを勉強すると手っ取り早い
テキストフィルタを書きまくって、コンピューター上のデータをプログラミング言語でいじることが空気を吸うみたいな作業に感じられるようになったころ（誇張があります）、“Structure and Interpretation of Computer Programs” という本を読んだ。一部を除いて練習問題もほぼ全部解いた。この本に書いてあったことは、その後いろんなプログラミングの概念を知るうえでの強固な足場になっていると今でも実感している。
この本、その名前だけはあまりにもよく知られてるので、「はいはい、すごい人がよくお勧めしてる、あのSICPっていう難しい本ね」とか「Schemeとかいうマイナー言語の本」という印象を持っている人もいるかもしれない。 実際、おれはアプリを作りたいんだとかゲームを作りたいんだとかで、自分には関係ない本に思っている人も少なくないと思う。
でも自分は、この本は「読んでおくと学習をショートカットできる」たぐいのチートだと思っている。 なぜなら、「プログラミング言語でプログラムを書くというのがどういう行為なのか」をずばり（再帰という言葉を使って）説明している本だからだ。 さらにその説明がそのままプログラミング言語のインタプリターという「プログラム」にも適用される。 つまり、「プログラミング言語もまたプログラミング言語によって書かれるプログラムである」みたいなカラクリを、自分で暗中模索することなく全部きれいに教えてくれる。
こういうノリ、つまり「再帰的な発想が問題解決にとってめちゃくちゃ効くぞ」みたいなノリって、たぶん実世界ではそれほど頻出しない。 だから、それこそゼロからプログラミングを学ぼうと思っているような人であれば、それまで想像もしたことがない話だと思う。 ことわざの「屋上屋を架す」は「無駄なことをする」の意味なんだけど、にもかかわらずプログラミングでは常套手段で、そのための知見がこの本をまじめに読むだけで手に入るのだから、これほどお得なことはないと思っている。
自分は未読だけど翻訳もある。ぱっとみの印象ほどややこしいことは書いてないし、なによりコードを書いて実行すれば答え合わせもできるんだから、プログラミングを独習しようとする人なら読んでみて損はないはず。
とはいえページ数もあるし古い本だし、もっと気軽で現代的な教材がほしいという方もいるだろうから、まずは 『RubyでつくるRuby ゼロから学びなおすプログラミング言語入門』 を読むというさらなるチートを紹介します。
コンピューターのことをもう少し詳しく知る
SICPを読んだ自分は、これでもうどんなプログラムでも無限の時間と無限のやる気があれば書けるような気がした。 もちろん書けないんだけど、その理由のひとつは「コンピューターのことを知らなすぎる」からだ。 操る道具の使い方を知っていても、操る対象であるところのコンピューターがどういう仕掛けで動作しているのか知らなければ、できることは限られる。 ついでに言うと、「そのコンピューターでプログラムを動かすことによって解決したい問題をどうやってプログラミング言語で表現するか」っていうのもまた重要な話になるんだけど、それは次のセクションで触れる。
で、コンピューターである。 これについてはいろんな視点からの理解というのがあるだろうけれど、「プログラムを学ぶんだ」という視点から言うと、この 『コンピュータ・システム』 という本によって得られた理解が自分のなかで大きい。
この本は、ぶっちゃけていうと「おまえの書いたプログラムがどんなふうにメモリを使うのか」を教えてくれる。 自分はむかし原書の旧版を途中までしか読めずに挫折してたけど、いまは翻訳があるのでありがたいですね。 翻訳は事情により一通り目を通して、やっぱり名著だったと改めて思った。
ただ、一通り目は通したけれど到底身につけたというレベルでは読めていない。 それどころか、「これを全部意識せずにプログラムを書けるのありがたいな」と心底おもっている。 それでも、そういう部分も含めてとりあえずは押さえておかないと不安っていうのが独習者の心情であり、そういうニーズにこの本はぴったりな本だと思う。 だから、目を通したという経験があること自体がとても役に立っている。
一方、 『コンピュータ・システム』 だと低層すぎて、「じゃあ自分のプログラムをそういうコンピューターの上で動かすにはどういう仕掛けを使えばいいんだ」という点はいまいち見えずらい。 実際にアプリケーションをプログラムで書くときは、ファイルシステムとかシェルとかWebサーバーとかの「わかりやすい」層まで抽象化された道具を使うわけだけど、そのへんについて自分がはじめて理解した（ような気がした）のは “Understanding UNIX/LINUX Programming: A Guide to Theory and Practice ” という一冊の本を通してだった。
これも今は 翻訳 が出てるようなので、興味がある人は翻訳のほうがいいかもしれない、と思ったけど旧アスキーで今は入手困難なのかな。
で、まあ、このへんはC言語の世界なわけで、「独学でWebでアプリを作りたいんだ」という人にとっては重たすぎるという異論は認める。 そういう方には、Go言語のランタイムの世界を通じて上記のノリをすべて解説してしまったこちらの 『Goならわかるシステムプログラミング』 がおすすめです。
解決したい問題とコンピュータープログラムとの橋渡しができるようになる
このへんまできたら、どんな分野でどんな問題を解決したいかに応じて、具体的に特定の言語でプログラミングの仕方を学んでいける段階になると思う。 そのため、「ある言語のちゃんとした解説書」がありがたくなる。
自分の場合は構造化文書をごにょごにょするというのが大きな関心領域のひとつで、その分野ではパーザを書くというのが仕事のひとつになる。 そのため、その分野に対する強い仕組みが備わっていたHaskellという言語を使うことにして、教科書としては “Programming in Haskell” （の旧版）をがんばって読んだ。
改訂版も 『プログラミングHaskell 第2版』 として翻訳書が出ています。
ぼくの場合はたまたまHaskellだったけど、それぞれのプログラミング言語に定番の教科書がある。 ここまでくれば、そういう定番を読むのが最短の独習法になるはず。
他人が読んだ本をそれほど当てにするな
結局のところ相性みたいなのがあったりするし、これ一冊で十分という自明な名著があったらこんなにいろいろな本が出ていないので、図書館とかも利用しつついろいろ読んでみるのが近道だと思うんだけど、自分の独学経験を書いておくのもアフィリエイト的にいいかなと思って書いてみた。
2021年賀状（というかPostScriptのQuineの話）
もう10年間、ほぼ毎年PostScriptのプログラムを手書きして年賀状を作ってきたわけだけど、いつも年賀状を出しているのは親戚などの非コンピューターな人たちが大半なので、PostScriptでプログラマティックにデザインを生成している面白さはわからないし、もうプログラムとしてのネタ性をデザインに向けなくてもいいだろうということで、今年はデザインには一ミリも努力せずプログラムだけ工夫してみました。年賀状っぽいPDFを出力しつつPostScriptのコードとしてはQuineになっているというプログラムです。*1
<< /PageSize [420 285] >> setpagedevice /SaucerBB.ttf findfont 140 scalefont setfont 1 0 0 setrgbcolor /a (\(<< /PageSize [420 285] >> setpagedevice\) =) def /b (\(/SaucerBB.ttf findfont 140 scalefont setfont\) =) def /c (\(1 0 0 setrgbcolor\) =) def /y (2021) def /s (/a == a == \(def\) = /b == b == \(def\) = /c == c == \(def\) = /y == y == \(def\) = /s == s == \(def\) =) def /x (/x == x == \(def 20 100 moveto y show a cvx exec b cvx exec c cvx exec y cvx exec s cvx exec x cvx exec showpage\) =) def 20 100 moveto y show a cvx exec b cvx exec c cvx exec y cvx exec s cvx exec x cvx exec showpage
できるのはこんなつまらないPDFですが…、
PostScript言語としての出力結果はもとのソースコードと同一になります。
$ ps2pdf 2021.ps 2> result.ps $ diff 2021.ps result.ps $ # もとのソースと同一なので差分がない！
どうやって書いたか
Quineには標準的な書き方のようなものがあって、『あなたの知らない超絶技巧プログラミングの世界』という、21世紀の人類が到達した狂気のひとつであるような名著に詳しく書いてあります。
PostScriptのQuineとしては、この書籍でも紹介されている次のチートっぽいやつが有名です。
(dup == =) dup == =
しかし、PostScriptにも文字列を評価する方法（exec）があるので、同書においてRubyで紹介されている手法でも書けます。ポイントは == と = の違いを利用して丸括弧のエスケープをごまかすところです。
/a (/a == a == \(def a cvx exec\) =) def a cvx exec
これをベースにページ記述言語の部分を足していくことで、今年の年賀状のコードを書きました。
専門書を売る
「日本の専門書は安い、もっと高くあるべき」という意見があります。 この意見の背景には、専門書の価格はその価値で決まるかという観点と、出版社は専門書でどう利益を出せるかという観点があるような気がします。 ここでは、それぞれの観点について、個人的に「それって実際のところはどうなの」と思う点を書きだしてみます。
なお、両者の観点は本来は独立に議論できるものではないであろうこと、そもそも自分が観測できる範囲での意見を書きだすだけなので客観性のある議論でもないことに注意してください（自分は主に理工書、さらに言うとコンピューターに関する書籍で仕事をしています）。
専門書の価値で専門書の価格を決められるか
専門書の価格は、そもそも「価値」が何なのかという点に立ち返ると、わりと身もふたもないものになると思っています。 つまり、消費者がある専門書を書店で購入するとき何に価値を見出して対価を支払うのかを思い出そう、ということです。
自分は経済学をよく知らないですが、ある商品が購入されるかは消費者の効用で説明できるというふうに雑に理解しています。 ここで「効用」というのは、専門書の場合、「その本を読むことがどれくらい役に立つか」になりそうですね。
いや、本当にそうか？
多くの場合、ある専門書が実際に役に立つかを個人が判断するには、かなり時間がかかります。 なので、その専門書を読むことが自分の役に立つかどうか、消費者は購入時には判断できないと考えるのが自然です。 どんな商品にも多かれ少なかれそういう要素はあると思いますが、特に専門書を売る立場からすると、消費者がその場で価値を判断しにくいものにお金を払ってもらう、という考え方が基本になるとおもっています。
そういう前提で、他の専門書ではなく自社の本を選んでもらうには、何が決め手になるでしょうか。 本の中身自体で効用を判断できないとすると、多財の間での消費指向を説明する効用関数を決めるのは、見た目の印象（カバーの絵とか）、書名、著者、話題性や世間での評判、入手しやすさ、そして価格などだと考えるのが妥当でしょう。 本という形をとっている以上、「一般的な本の価格」を逸脱することは、他の同様な商品の中から本としては選ばれにくくなることを意味します。
一方で、「専門書の価格はもっと高くすべき」という意見は、専門書の需要が非弾力的、つまり価格が上がっても需要があまり減らないことを前提としているともいえます。 これは、ある専門書を買ってくれるであろう消費者は「その専門書しか同じ効用を得る選択肢がない」という前提と同じです。
仮にこの前提が成立したとして、それでも価格を高く設定しにくい理由は、大きく2つあると考えています。 1つは、そのような前提が成り立っている場合に価格をどこまで高くできるかは倫理的な挑戦であるという個人的な思想です。 読者の足元を見るのはつらいよね、と言い換えてもいいかもしれません。
もう1つは、日本では書籍が定価販売されている商品であるという事情によるものです。 もし「その専門書しか同じ効用を得る選択肢がない」ような唯一無二の専門書を発行したとして、そこで説明されたことは周知の事実となり、より大きな「効用」の別の本が出版される可能性があります。 ここでいう効用が、上記で説明したようなものであることが、定価販売のおそろしさです。 つまり、すでに専門書の需要がはっきりしていて、かつ執筆できる著者に困らない程度に大きな分野であれば、後発の本には「価格を安くする」という戦術も可能になります。 実際、この戦術が見事にはまり、その後の趨勢を決定した事例を知っています（かつてTCP/IPの解説書はすごく高かった）。
そんなわけで、「いい本だから高くていい」という感じには価格を決定しにくい、というのが現状だと考えています。
専門書の収益構造と価格設定
個人の消費行動はともかく、専門書は需要が少ないのだから、市場原理に従って高くあるべきではないか、という考え方もあると思います。 これに対しては、すでに触れたように書籍では価格が固定されていることから、市場原理で最適な価格がおのずと決まると想定するのはそもそも非現実的だと考えています。
とはいえ、専門書の価格をまったく売り手が恣意的に決められるかというと、もちろんそんなことはなくて、一般には原価ベースで価格が決定されていると思います。 *1
専門書の原価は、ものすごく雑に区分すると、だいたい以下のような感じの構成比になっていると考えていいでしょう。 （出版社だけ具体的な割合を書いていないのは、それ以外の配分を決めるのが出版社の仕事であり、自分たちの手元にどれくらい残すかを設計するという役目があるからです。）
- 著者（原著者や訳者を含む）：0%～20%
- 制作印刷製本：20%～50%くらい
- 流通：10%～15%くらい
- 書店：10%～15%くらい
- 出版社：残り
それぞれの割合に幅がありますが、流通と書店の割合については出版社ごとにほぼ固定されていて、現場では変えようがありません。 したがって、制作および印刷製本にかかるコストでだいたいの価格レンジが決定する感じです。 具体的には、一冊あたりのページ数や色数、一度に印刷製本する冊数、そしてデータを制作する費用などで、おおよその価格レンジが決まるということです。 それに著者へのお支払いの割合を加味したものを「原価率」と考えて、そこから本体価格を決定するというのが、わりと一般的な価格決定のプロセスだと思います。
この原価率が初刷で45%とかを超えてくるのは、個人的な印象ではかなり厳しい本です。 「それなりにヒットしてくれないと自分の給料が出ないぞ」という感じです。 単純に計算すると出版社に残るのが20%以上あるので余裕そうに見えるかもですが、そこから商売に必要なあらゆるコストと自分自身の給料を捻出することになるので、実際ギリギリになります。
もちろん、商品として競争力のある値付けというのも企画の一部なので、その線を超えるべく挑戦する場合もあります。 最終的な書籍の本体価格を引き下げるため、もっともありがちなのは、制作費を抑えたり著者の印税率を減らしてもらったりするという手です。 しかし、潜在的にその本を必要としてくれるところから買い上げの約束を取り付けたり、制作費の援助をお願いしたり、あるいは書店に営業することを前提にして多めの部数を制作することで一冊当たりの原価を引き下げたり、そういう手を模索することもよくあります。
極端な場合、単品では赤字覚悟で企画するという、戦略的な値付けをすることもあります。 たとえば、以下の2つの方針では後者のほうが堅実で理想的だと自分は考えているのですが、前者の戦略をとる出版社も少なくありません。
- 「なんとなく売れそうなネタだったので10000部つくって安く発売した本だけど1000部しか売れなかった」
- 「売れ残りが怖いので500部つくって高めで発売し、手堅く最終的に1000部まで売れた」
印刷製本では大量生産の原理が効くので、たとえば1000部の印刷製本にかかるコストの2倍で作れる本は2000部ではなく10000部だったりします。 うまいこといって売れるかもしれないから一度にできるだけ多く作って原価率を大きく引き下げ、だめでも廃棄したほうがトータルで安上がりになる、という勘定もあるのだと思います。
実際、そもそも日本全国には1000前後の書店があるので、それらに数冊ずつ配本するだけでも数千部が必要です。 仮に潜在的にその本を必要としている人が全国で1000人だったとしても、その1000人が書店の店頭で本が買えるようにしようと思ったら、廃棄を前提に数千部を作るしかないということです。 全国で1000人しか需要が見込めない本を企画するのがそもそもおかしいという考え方もありえますが、専門書を出版するとはそういうことです。 もちろん、そういう本の企画だけで事業を続けることはできないので、「企画の点数と幅を増やして大きなリターンが発生する可能性を高める。リターンが出ないとジリ貧になるが、たまにヒットが出てしのぐ」という形で商売を続けているところが多いだろうとは思っています。
幸いコンピューターの本は、専門書のなかでは「うまいこといって売れるかもしれない」の可能性がそこそこある分野でもあるので、比較的やりやすいほうな気はします。 逆に、そういう傾向があることで、特に多めの部数が期待しやすいエントリー系の本だと「原価ベースで決まる価格レンジ」よりやや低いところに競争力がある価格帯がきているなと感じることもあります。
いずれにせよ、需要が少ない専門書が「そこそこの価格」で手に入る背景には、こういう原価（率）ベースでの価格決定の習慣があるというのが、ここでの主張の要約になります。
インターネットの時代に専門書の需要はあるのか
いまは、専門家である執筆者が直接自分で情報を発信できる環境が整っています。 そんななかで、「全国で高々1000人くらいにしか需要が見込めない本」を「そこそこの価格」で販売する出版社として生きていくことができるのか、当事者としては正直めっちゃ不安です。
ただし単純に悲観しているわけではなくて、むしろ「専門家である執筆者が直接自分で情報を発信できる環境」が広がっていること、それも無償で手に入る形で広がっていることには希望も感じています。 それは、「専門家である執筆者が直接自分で発信している専門的な情報」が、専門書にとっては代替財ではなく補完財だと思っているからです。 一般にミクロ経済学では、代替財が安くなれば需要は下がるものの、補完財が安くなると需要は上がるとされています。 であれば、補完財であるところの「専門家である執筆者が直接自分で発信している専門的な情報」がインターネットに無償であふれるほど、専門書の需要もそれだけ大きくなるはずです。
よく考えるまでもなく、専門書を買ってくれる人というのは、専門家そのものだけでなく、その分野にちょっとでも興味がある人すべてなんですよね。 そして「専門分野にちょっとでも興味がある人」は、どう考えてもインターネットのおかげで増えています。 かつては大学や大学院などに入ってはじめて存在を認識するような分野のこと、そこでどんな専門書が読まれているのかという知見、そういう情報が増えるほど、その専門書を求める人も増えると考えるのは自然でしょう。
実際、すでに専門書のバラエティーはここ10年でかなり増えていると感じています。 分野によっては、もはやレッドオーシャン化しているものもあります。 そこで出版社としてどう戦っていくのかは、また別に考え続ける必要がある難問です。 とはいえ、解説のわかりやすさを上げること、著者と出版社の権利関係の在り方の見直し、補完財たる「専門家が自分で無償で発信する情報」に重なる要素の無償化、そして需要の増加に応じた価格設定のあり方などが糸口かなと思っています。 最近になって専門的な内容の新書が増えて単価も上がり、その一方で電子版をセールでばらまいているようなムーブには、こういう大きな潮流があるんじゃないかな。
*1:出版社として書籍の原価を考えるときは、売れようが売れずに返品されようが支払いが必要になる制作や印刷製本のコストと、売れた分だけを支払うことが前提の印税とはわけて考える必要があるので、以下の話は自分が企画時にざっくりと念頭において考えている感覚の話であり、決算時に計算するような原価の話ではありません。
30キー左右分離キーボードfoobarをPico Micro Cで作った
はやりの自作キーボードの記録です。 きっかけは、2年前のpyspa忘年会でこちらのキーボードの基盤を手にしたことでした。
- foobar 1.1 with plates
https://www.40percent.club/2017/09/foobar-11-with-plates.html
リンク先の写真からわかるとおり、キーが30個しかありません。HHKBのおよそ半分です。さらに分割式。 もともとフットプリントが小さいキーボードが好きで長年にわたりHHKBを使用、しかし1台を両手で使うには肩と背中に限界を感じて2台でスプリット、しかし2台だと入力できるファンクションキーが限られてしまうので最初から左右分割で設計されたキーボードとしてErgoDoxを導入、しかしErgoDoxはデカくて机が狭い…、という遍歴の自分にとって、この「foobar」という雑な名前の自作キーボードはかなり魅力的な存在でした。
とはいえ、電子工作はずいぶん昔に少しかじった程度で、PCへの入力をあつかったこともなかったので、「まずは動作の原理を理解しないとゴミができるだけだな」とおもいながら、キースイッチだけ入手してなかなか着手できていなかったのでした。
ここにきて気持ちが高まり、Arduinoのノリもちょっとだけわかった気になったので、思い切って手を付けることにしたのが一昨日のことです。 先達の記事を見ながら脳内で実装の手順などをイメージトレーニングしまくったことが功を奏したのか、そもそもキー数が少ないからか、実際にハンダ付けに要した時間は二時間ちょっとでハードウェアはあっさり完成しました。
ただ、ファームウェアにはちょっとはまりました。 もともと情報が少なかったうえに、自分の理解もあやふやなまま「とりあえずハードができてから試行錯誤でなんとかなるだろう」と甘く見てたのもあって、案の定トラブった感じです。
分割式キーボードのファームウェアはどうなっているのか
準備の最中からいまいちもやもやしていた点に、「左右2台のArduinoのどちらにどんなファームウェアを書き込めばいいのか？」というものがあります。 考えられるのは以下の三通りです。
- 両方のArduinoに、同一のファームウェアのデータを、それぞれのUSB端子から書き込む
- 両方のArduinoに、別々のファームウェアのデータを、それぞれのUSB端子から書き込む
- 片方のArduinoのUSB端子から、単一のファームウェアのデータを書き込む
このうち、Arduinoというか（AVR）でデータピンをとおして書き込みデータを転送できる気がしないので、3はないと考えられます（実は同じAVRなマイコンを使っているErgoDoxが片側からファームウェアを書き込むので、もしかしたらと思ったのだけど、単純にErgoDoxは1台のマイコンで制御する方式だった）。
公式ではTMKというファームウェアをベースとしたファームウェアが公開されていて、これは上記2の方式のようです。厳密にいうと、フラッシュメモリには同一のhexデータを書き込むものの、EEPROMには左右で別々のデータを入れておくような手順であることがドキュメントからは読み取れます。
そこで、まずは以下のようにデフォルトのキーマップを書き込んでみることにしました。
"40percentclub_foobar_default.hex" がデフォルトのキーマップ、 "eeprom-righthand.eep" が公式で用意されている右手用のEEPROMデータ（左手用は "eeprom-lefthand.eep" ）です。
$ sudo avrdude -c avr109 -p m32u4 -P <COM> -e -U flash:w:"40percentclub_foobar_default.hex":a -U eeprom:w:"eeprom-righthand.eep":a
（なお、Debian 10にインストールしたavrdudeではうまく書き込みが終わらなかったので、Windows用のavrdudeにGUIをかぶせたAVRDUDESSという便利なソフトウェアで書き込みを実行しました。（追記：ModemManagerが動いていると邪魔されて書き込みできない、ということに気づきました。その場合は sudo systemctl stop ModemManager とかでModemManagerを止めると書き込み可能になります。）
あと、書き込み先の <COM> を知るには、ボードのリセットボタンを2回（まっさらなArduinoなら1回）押してからすばやく dmesg なりGUIの操作なりを実行する必要があります。
これはもちろん書き込みのときも同様。）
両方に書き込みできたところで、左右をTRRSケーブルでつなぎ、左手用のUSBコネクタをPCに接続してみます（デフォルトのキーマップは左手につなぐことになっている）。 ところが、なぜか左手側に実装したキーしかPCに反応しません。 ひょっとしてどこか接続を間違えているか、ハンダが甘いか、マイコンが死んでいるのか。 しかし全体に導通を確認しても特にあやしいところも見つからず、右側用もUSBケーブルでPCと直接接続すれば（上下左右が逆の状態で）左側として問題なく動くので、どうやらハードウェア的な問題でもなさそうです。
そこで qmk という別のファームウェアを試してみます。
こちらは左右分離式を含むさまざまなキーボードの種類に対応していて、それぞれに書き込み方法が異なるようなのですが、foobarについては上記でいうと1の方式で、同じファームウェアを書き込むようになっているようです。
そこでqmk のGitHubディレクトリをクローンしてきて その中で次のようにデフォルトのキーマップを生成し、生成された .hex ファイルのみをやはりavrdudeで書き込みます。
$ make 40percentclub/foobar:default $ avrdude -c avr109 -p m32u4 -P <COM> -e -U flash:w:"40percentclub_foobar_default.hex":a
しかし、こんども同じ症状です。 USBでPCと接続しておらTRRSケーブルの先につながっている右手側は、Arduino上のLEDは点灯していますが、キーの押し下げにはまったく反応しません。
ただ、この時点でようやく1つの原因に思い当たりました。
USB type CのArduinoボードは、qmkの左右分離用ファームウェアのデフォルトでは動かせない
foobarをはじめ、AVRマイコンをコントローラとして利用している自作キーボードでは、一般に入手しやすいPico Microと呼ばれるArduinoボードとその互換機が利用されています。 これらPico Microたちは、（有線接続では）つい最近までUSB type Bが主流でしたが、ここ数年でtype Cの製品も手に入りやすくなりました。 type Bもtype Cもマイコンとしての動作は同じなので、自作キーボードでも問題なく使えると期待して今回の制作ではtype Cを使ったのですが、ひょっとしたらこれが「左右が連携できない」ことの原因かもしれません。
最悪はArduinoをtype Bに差し替えることも覚悟しつつ、その線に絞ってWeb検索をかけてみると、はたしてそのものずばりtype CなPico Micro互換ボードを左右分離型の自作キーボードで利用できるかどうか検討している記事が見つかりました。
- The Case of the Wayward Elite-C
https://medium.com/@keebio/the-case-of-the-wayward-elite-c-73f0fd691f88
要約すると、「ボードによってはqmkで左右のマスター/スレーブ識別に使っている方法（コネクタの近くのダイオードにおける電圧をみる）が使えないことがある」という内容です。 比較的新しいPico Microのtype Cのボードがこれに該当する可能性は、いまの症状からしてもありえそうに思えます。
幸い、qmkには、この状況をソフトウェア的に解決する手段が用意されているということも上記のブログからわかりました。 具体的には、ファームウェアのコンパイル時に以下のマクロを有効にするだけです。
#define SPLIT_USB_DETECT
あらためてこの方法で生成したキーマップの .hex を左右両方のボードに転送したところ、無事に左右が連携してキーボードとして動作するようになりました。
こうして先人たちによる苦労のおかげで、さしたる苦労もなく、個人的な理想形の最北ともいえるキーボードが実装できました。
ありがたいことです。
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に書いてあるのでネタバレにならないと思うのだけど、主人公はいろいろあって最後にはコンビニ店員として生きるという決断をする。日本語で読んでいたら、暢気な主人公を追い込む周囲の人間の描写で細かいニュアンスが読み取れすぎて、おそらく最後まで読み進められなかったような気がする。とくにバーベキューパーティーと終盤の職場の登場人物たちは、「汎用の社会性よりもプロフェッショナリズムを好む人間の日常のすぐ隣に潜むウェイ」という恐怖がにじみ出ていて、外国語で読んでいても泣きそうになった。もちろん、そういう描写があるから主人公の最後の決断がいきるとはわかっているけど、やはりきつい。