golden-luckyの日記

ツイッターより長くなるやつ

プログラミングにおける「納得」と『Goならわかるシステムプログラミング 第2版』

「納得」欲

パソコンやブラウザ、あるいはスマホで使うアプリケーションを作っているとき、自分がやっている「プログラミング」という行為にどこまで「納得」できているでしょうか?

「プログラミングという行為への納得」、ちょっと耳慣れない概念ですよね。実をいうと、さっきこの記事を書き始めたときに思いつきました。プログラムを書いていると、エラーみたいな露骨な躓きがない場合でも、なんかもやもやすることがあります。このもやもや、少なくとも自分は、以下のような側面で一定の「納得」に至っていないことが原因であるような気がしています。

  1. アプリケーションの仕組みをデータ構造やアルゴリズムの言葉で説明しきれるぞ、という側面での「納得
  2. 意図通りの挙動になることに設計レビューやユニットテストや動作検証を通じて確信が持てるぞ、という側面での「納得
  3. コードがコンピュータやネットワークという物理的な装置の上でどう処理されるのか想像できるぞ、という側面での「納得

アプリケーションを書くために、プログラマー個人がこれらすべての「納得」を満たす必要はありませんプログラマー個人が「納得」できていなくても、コンピューターと計算機科学の圧倒的な力によって、多くの課題は解決できてしまうからです。

というかむしろ、課題解決にとって必要なのは上記のような意味での「納得」である必要はない、と言うほうが適切かもしれません。「あるAPIに従ってコードを書けば解決する」ような課題なら、「APIリファレンスどおりにコードが書けている」ことが「納得」になるでしょう。フレームワークの規約や設定も同様です。そうやってアプリケーションを書くプログラマーが「納得」しやすい側面を課題に合わせてうまく再定義してあげられるのが、プログラミングという行為のすごいところだとも言えます。

そうはいっても、やはり上記に挙げた3つの側面に対する「納得」はちょっと別格に思えます。特に3つめの「納得」が曲者です。自分が書いたアプリケーションと、CPUと、その間でなにかしているっぽいOSとの関係について考えると、あまりにもギャップが大きすぎて、ちょっとどこから「納得」すればいいのかさえわかりません。そういうとき人は、OSを作ってみればわかるかもと期待してそういう本を買ったり、CPUを作ってみればわかるかもと期待してそういう本を買ったりするのだと思います(ぼくも買いました)。

ここで厳しいのは、「納得」したいという欲求は「原理から知りたい」という欲求とはやや違っているので、すべてを自分で作ってみるとなると往々にして「重い」ことです。もちろん、自分でも作ってみたいという気持ちは富士山並に高いんですが、いかんせん重い。これが富士山であれば、Googleマップで山頂までの登山道が見られて「こんな道を歩いてくのかー」と納得できます。コンピューターについてはどうでしょうか。自分がふだん書くようなアプリケーションからOSやCPUの世界を手軽に納得するすべはないでしょうか?

『Goならわかるシステムプログラミング』が改訂しました

そんな「手軽な納得」を目指して書かれた本、『Goならわかるシステムプログラミング』が改訂しました。本書は、アプリケーションプログラマー「OSやらCPUやらの仕事について納得したい」という欲求に効くように書かれています。つまり、ものすごく雑にいうと、「プログラムとか書けるけど、よくよく考え始めると理解できてなくて釈然としないあれこれ」に答えてくれる本です。なんでそれが本来の意味ではシステムプログラミングできない(OSを作れない)はずのGo言語という枠組みで可能なのか、その裏にGoのどんな抽象化が潜んでいるのかについては、本書を実際に読んで確かめてください。今回の改訂で、全体にこまごまと古い情報が見直されているので、「すでに『Goならわかるシステムプログラミング』を読んで後輩に進めたいけどちょっと前の情報もあるからなあ」と思っていた方には安心して他の方に推薦してもらえるようになっています。

さらに今回の改訂版では、ひととおりの「納得」が得られた最後の最後に、さらに「デバッガーがどうしてそんな行為に使えるのか」についての解説も追加されました。本書では「OSやらCPUやらの世界」を覗くツールとして「デバッガー」を使います。富士山をGoogleマップで登るように、本書ではアプリケーションからデバッガーで下層に降りていくわけです。そうやって、ふつうのプログラムが実行されるまでの流れを見るのに、デバッガーを使うわけです。しかし、よく考えるまでもなく、そんなことができるデバッガーもそれ自体またプログラムなわけで、当然、そういうことが可能なプログラムのための仕組みもコンピュータというシステムには組み込まれています。本書を通じてふつうのプログラムの裏側を「納得」できたら、最後にそのツール自体にも「納得」できるようになったのが、今回の改訂の面白いところだと思っています。

もうひとつ大きな加筆として、そうしたプログラムの実行を陰で支える存在のひとつである「シェル」にも新たに一章が割り当てられました。もちろん、この章でコマンドシェルの使い方が説明されているわけではありません。この新しい章は、「bashの使い方を学ぶことがLinuxを学ぶことではない」といった事実に改めて「納得」するための章だと言えるでしょう。シェルをめぐる話がコンピューターシステムについて「納得」するための本に入っているのは、個人的にとてもポイントが高いバージョンアップだと思っています。

最後にもうひとこと。本書は2016年-2017年ごろにAscii.jpで連載していた記事からのスピンオフで、ほとんどの内容については当時のままそちらでも読めます。興味はあるけど本を買う気はないよという方も、ぜひAscii.jpの連載をご覧ください。きっと、「アプリケーション作ってるときのアレはこういうことだったのか!」って納得できる話が少なからず見つかるはずです。

2022年賀状(PostScript定期)

毎年のやつです。

github.com

f:id:golden-lucky:20211225211702p:plain

昨年一昨年は描画よりアルゴリズムに走ったけど、今年は初心に戻って描画系です。「2022」という文字のアウトラインに沿って「2022」という文字列を繰り返しています。flattenpath でパスを lineto の列にして pathforall するという、わりと古典的な手法なので、とくに芸はない(ソース)。本番はもうちょっとカッコいい書体を選びたい。

リンゴの話

pyspa Advent Calendar 2021 17日めの記事です。昨日は@aodagによる「swayでwayland」でした。swayよさそうと思ってapt installしたらbusterにはなかったので、bullseyeに上げている間に書いています)

大学を出てニートをしていた時分には、リンゴ1個で昼ご飯を済ませることがあった。 そこだけ切り取るとアメリカの小学生っぽいけど、父方の実家である弘前の叔母がリンゴを箱で送ってくれて、でもすでに家族の団欒でリンゴを食べるような機会もなく、悪くなる前にがんばって毎日1個ずつでも食べていた、というのが実態に近い。 バイト先で昼休みにリンゴを丸かじりするのは、片手で済ませられるし、一人で過ごしたい自分の性にも合っていた。

未希ライフ、とき、グラニースミス

就職して自分の家族をもってからは、わざわざ自分でリンゴを買って食べることもあまりなくなった。 20代までに一生分のリンゴを食べたつもりでいたし、リンゴジュースは好きだけど、それはどちらかというと香料産業のパワーだ。 リンゴはまあリンゴだし、わざわざ買って食べることもないな、という温度感。 余談だけど、台湾に行くと当地でのリンゴの人気がすごくて、「リンゴを食べに札幌に行くツアー」とか見かける。 なんでリンゴのために日本に行きたいのか、素で疑問だった。 そもそも札幌はリンゴの産地じゃないし。 まあ、こっちもマンゴーを食べに玉井まで行ったりしているので、どっちもどっちではあるのだけれど。

DSC_0102

一年前までの自分のリンゴ観はこんな感じ。 そんな中、2020年の晩秋に近所のスーパーでたまたま「ぐんま名月」という銘柄のリンゴを見かける。 それまで群馬をリンゴの産地として意識したことがなかったし、なにより群馬だし、その名前を冠する心意気がおもしろくてつい買ってみた。 つまり、とくにリンゴが食べたかったわけではなく、いわばジャケ買いした。

そしたら、これがびっくりするほどうまいでやんの。

とくにすごいのは香り。 すごくリンゴ。 リンゴそのもの。 リンゴなんだからリンゴなのは当然なんだけど、香料に慣らされた自分の感覚さえ裏切るリンゴらしい華やかな香りがある。

しばらくは、そのスーパーでぐんま名月を見かけるたびに買って帰り、夕飯後に家族で食べるのが楽しかった。 ぼくがリンゴをなかば無視していた20年のあいだにリンゴ業界は確実に進化していたという再発見の興奮みたいな高揚感もあった。

もっとも、あとで調べたところ、ぐんま名月は実際には1991年にはすでに品種登録されている。 だから、この20年で進化したのはむしろ流通なのかもしれない。 実際、ぐんま名月ショックを経て町で売られているリンゴに自分の意識が向くようになると、現在ではわりといろいろな種類のリンゴが流通していることに気が付いた。 12月になると、ぐんま名月はあまり店頭に出回らなくなるが、「シナノゴールド」や「王林」のようなリンゴはまだまだ買える。 これらがまたうまい。 うまいし、いろいろな種類を食べていると味や触感のバラエティが見えてきて楽しい。

そうやって自分の感度が上がってくると、ごくふつうのありきたりなリンゴ、つまり「サンふじ」の完成度の高さを知ることになる。 サンふじ、見た目はぱっとしないけど、甘味と酸味のバランスに安定感があって、じわじわおいしい。 それでも固体や産地による差があって、これがまた楽しめる。さらに12月になると「蜜入り」と銘打った完熟のサンふじも出回る。 情報量があがって解像度が高くなることで、ありきたりと思っていた食べ物がこうも楽しくなるのだな。

年が明けると、さらにいろいろな品種のリンゴが出てくる。 そのころから、それまで放置気味だったInstagramのアカウントをリンゴ記録帳として運用するようになった。 そして珍しいリンゴに出会ったら必ず買う。これは「なかのきらめき」という2018年に品種登録されたばかりのリンゴで、柑橘類的な酸味がうまい。 今年も流通し始めている。インターネットによると「なかののきらめき」らしいんだけど、近所のスーパーでは「なかのきらめき」で、いろいろ謎が多い。

ほどなくして、小学館から出ている『りんご だんめん図鑑』という本を知り、リンゴへの関心がさらに高まった。 この本には固さと甘味-酸味の2軸四象限でリンゴを分類した図がついており、それをみながら「今年リンゴを再発見する前にシーズンが終わってしまった「秋映」とかを来年は食べてみたいね」という感じで夢が膨らむ。

www.shogakukan.co.jp

そして待ちに待った2021年のリンゴシーズン到来である。

10月末には複数の入稿&締め切りを控えながらも我慢できずリンゴ狩りに行った。

SDIM1098

これは「陽光」という希少品種で、もちろん甘いし、酸味もはっきりしているし、見た目の赤も鮮やかだしで、トータルな迫力がある。生で食べられる紅玉という趣き。

SDIM1094

そして、もぎたては本当にうまいな。 来年はぜったい、ぐんま名月を狩りに行くぞ。

2021年のリンゴシーズンはまだまだ続くので、この記事をみてリンゴが気になった方は、いまからでもいろいろ楽しめます。 ちなみに食べ方だけど、皮ごと8分の一にカットする(以下のインスタの写真の2枚めみたいな感じ)のが風味がもっとも楽しめる気がするのでおすすめ。

やっぱり書籍でもプロマネは必要だった

期せずしてプロマネ募集みたくなってしまった前回のブログ、ありがたいことに何人か声をかけて頂き、かといって当社には本格的に人を雇うような余裕もなく(今期も役員貸付(会社の現金が足りないので社長(ぼく)とかからお金を出すやつ)の話が出ている)、それでも条件が合う方がいて、秋から外部スタッフとしてお手伝いをしてもらっています。@niwaken です。出版ではなくガチでソフトウェア開発のプロジェクトマネージャーです。

どんなことをしてもらっているかというと、ひとことで言えば「すぐにでたらめなルバートで進行してしまう鹿野に対するメトロノーム」。

去年は1冊しか出せず今年も夏にNo.1が出た時点で「生きてたのか」と思った方もいるであろう『n月刊ラムダノート』のNo.2を皮切りに、7月に出たばかりの原書をいちはやくβ版として発行した『研鑽Rubyプログラミングβ版』、そして章構成の見直しと図の全面書き換えを含む『プロフェッショナルIPv6 第2版』という具合にいきなり進捗を出していく系の出版社になったのは、@niwaken にきちんとスケジュールを見てもらったおかげです。もちろん根本的には著者のみなさんの原稿あってのことなんですが、それを本にするまでの段階でボトルネックとなっていた鹿野の作業に @niwaken がリズムを与えてくれたおかげで、正直タイトな日程だけどここまでなんとか破綻なくやれています。とくに『研鑽Rubyプログラミングβ版』では、ぼくがまったくできなかった「原稿を見つつ翻訳者である角谷さんの進捗に目を配る」までやってもらえて本当に助かっています(βなので現在進行形なのです)。

いや、「原稿を見つつ著者の進捗に目を配る、ってのはふつうの編集者の仕事なわけだが、それを任せてしまっておまえは一体なにをやってるんだ?」という疑問もあるでしょう。もっともです。ぼくも自分がそれをできずになんで編集者できているのかよくわからない。できていないのかもしれない。まあ、そのへんの話は前回のブログで書いたとおりなので、そちらを見てください。逆にいうと、@niwaken は編集者ではなく本業はソフトウェア開発者なわけだけど、そういう「編集者っぽいこと」をやってもらえているので、これも別のブログで書いたとおり、やはり今ますますソフトウェアみが増している書籍という商品を作るうえではプロダクトマネージャーとプロジェクトマネージャーを切り離して考えるというのが一手なんだろうな、という思いを新たにしています。

@niwaken には、ラムダノートのもう一人の社員である高尾が鹿野の適当さに呆れている様子をライブで見ていただきながら、来年も引き続き助けてもらうつもりです。しばらくはいい感じに新刊情報をお届けできるんじゃないかなと思います。

出版社の編集者は何をする人なのか

かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう仕事をしていました。

誰もが自分のSNSを持ち、ブログのプラットフォームで記事を公開し、中には自分で印刷製本して本の形にして売買している現代、「自分で文章を書いて世間に出す」のに出版社は不要です。いわんや編集者をや。

自分は出版社を作り、そこで編集者をやっているので、この「出版社も編集者も不要」という世界で何をすべきかという問題についてよく考えます。毎度たどり着くのは「必須ではないけど不要というほどでもない」という答えなんだけど、特に「不要というほどでもない」に対する根拠をあまり明確にしてきていない気がするので、少し言葉にしてみようと思います。

出版社には「ノウハウやフロー」があった

まず、「こんな時代になってもなお編集者が出版社において連綿とやっている仕事」を明確にしておきます。

前提として、出版社における伝統的な編集者のゴールは「販売するための本や冊子を発行すること」だとします。まったく違うゴールが設定される場合もないわけではないと思いますが、このゴールの達成を以降の話の前提とすることには、それほど大きな異論は出ないでしょう。

ただ「このゴールに向かって編集者はどんな役割を担うべきか」については、当の編集者たちの間でさえ、はっきりしたコンセンサスがない気がします。 記事の冒頭で「出版社において伝統的な編集者がやっているような印象がある仕事」をいくつか列挙しましたが、それら個々の業務について「実務経験で習得したノウハウや会社で定められたフローをなぞること」をもって毎回の本づくりを実践しているのが実態だと思います。

なお、これは皮肉ではないことに注意してください。 そういうノウハウやフローが確立していること自体は、「本を書きたい」「本が欲しい」という執筆者や読者にとって、出版社の編集者が提供できるサービスの一つです。

いや、「一つでした」というべきですね。 今は、このサービスを不可欠だと感じない執筆者や読者が少なからずいます。 むしろ、そういうノウハウやフローを利用しなくても自分の作品を公開したり、そうやった公開された出版社の編集者を経ない作品を楽しんだりする場が日常にあるので、そういうサービスの存在をそもそも知らない人が多いとさえ言えるかもしれません。

「ノウハウやフロー」を別の言葉で

出版社の編集者が「おれたちにはノウハウやフローがある!」みたいに吠えるのは、残念ながら沈んでいく船からの雄たけびにしか見えませんね。 実際、本当に「ノウハウやフロー」がある出版社やその編集者は、この時代にあっても淡々と実績を出しています。 そして、「ノウハウやフロー」みたいなふわふわした言葉でウリを主張することもありません。

とはいえ、実績を出している出版社やその編集者がそれぞれにノウハウやフローを確立しているのはやっぱり事実です。 だから自分としては、このふわふわをなんとかもうちょっとかっちりした概念にして、出版社と編集者の仕事の実体を明らかにしたい。 それが多少でも明らかにできれば、出版社と編集者を使って本を出してみたいとか、出版社から出ている本だから安心して買えるとか、そういう人がちょっとでも増えるので、これは自分にとっては長期的な生存戦略でもあります。 あと、これは最後にちょっと触れるつもりだけど、「編集者ってこういう仕事なんだ」という輪郭をなるべくはっきり伝えることができれば、そういう仕事をしてみたいという人へも役に立つかなっていう思いもあります。

出版社の編集者がやってること

とっかかりとして、出版社の編集者が何をやっているか、ここであらためて整理してみます。 といっても「原稿から文法の不具合をなくす」みたいなミクロな作業の話ではありません(そういうのは別に記事があります)。 出版社の編集者がやってることは、言葉を選ばずに言うと、こうです。

  1. どんな本を出せば売れそうかを常に考える
  2. 売れそうな本の原稿を書けそうな人を探す、もしくは、売れそうな本になる原稿を判断する
  3. 原稿を売ってよい形にする
  4. できた本を売る
  5. 上記を工程として管理する

要するに出版社の編集者の仕事は、売れる本を作って売ることです。 売れるか売れないか、みたいなことばかり言うのは下衆に聞こえるかもですが、不特定多数に「売る」ことを意識していない編集者はたぶんいないというのがポイントです。

もちろん、その意識の仕方は編集者個人によって違うでしょう。 「売れる=出版社として儲ける」という意識の人もいれば、「買う人が増える=その本で伝えたいことがより広がる」という意識の人もいます。 ちなみに自分は、「その情報を必要として購入してくれた数少ない人を失望させない」に割と全力を傾けています。 このように、「売れる」の基準は一通りではなく、そこには内容の潜在需要の大きさはもちろん、編集者個人の価値観が大きく影響しているので、最終的に世に出る本の出来不出来は実に多様です。

ただ、形はいろいろでも「出版物」という括りでは共通の要素もかなりあります。 そのため、売りモノの形にもっていくプロセスとして見ると、割とどこも同じようなやり方でやっているようです。 上記の「5」の部分は本の種類や内容によらず、そこそこ共通のスキルセットで編集者としての価値を提供できる面だともいえるでしょう。

プロジェクトマネージャとプロダクトマネージャ

プロセス管理については、昨今ではソフトウェア開発のツールや考え方を取り込んで、いろいろ工夫してるとこが増えてます。

当社を例にすると、工程管理はGitHubを活用したフローとしており、これによってプロセス管理の手数をかなり削減できています。 とはいえ、ツールだけで第三者とのやり取りを伴うプロセスが管理できるわけもなく、そこはSlackを利用して緩く著者との進捗共有をしている格好です。

こうした仕事は、ソフトウェアの業界では「プロジェクトマネージャ」という職能で呼ばれています。 一冊一冊の本はきわめて小粒とはいえ独立した一個のプロジェクトであり、その企画、執筆、編集、組版、印刷製本を滞りなく進めるためにはプロジェクトマネージャとしての仕事が必要です。 つまり、出版社の編集者はプロジェクトマネージャとしての役割を担っています

一方、出版社の編集者は単にプロジェクトマネジメントをするだけではありません。 前節で挙げた「編集者が売りモノの本を作るためにやっていること」のうち、「1」から「4」はプロジェクトマネージャとしての仕事には見えません。 これらは、本を「売りモノ」の製品にするために必要な工程であり、いうなればプロダクトマネージャの仕事です。 つまり、出版社の編集者はプロダクトマネージャとしての役割も担っているといえます。

このように考えてみると、出版社の編集者の「ノウハウやフロー」というふわふわは、実は何のことはない「プロジェクトマネージャとプロダクトマネージャのスキル」だったのだと言えそうですね。

編集者はプロジェクトマネージャ兼プロダクトマネージャであるべきか

一般に、プロジェクトマネージャとプロダクトマネージャはぜんぜん違うことを考える仕事です。 両方をきちんとこなすスキルがあれば言うことはありませんが、すべての編集者がそうであるべきというのは、正直なところなかなか難しい気がしています。

もちろん、両方こなしている(ように見える)超人的な編集者もいるにはいます。 が、わりと多いのは、プロジェクトマネージャとしてきっちり仕事している人のように見えます。 出版社である以上、ある程度の頻度で本を形にしていかないといけないので、プロジェクトマネージャ寄りの編集者の活躍が目に入りやすいのは当然だともいえます。

ひるがえって、ぼく自身は、書籍制作のためのプロセス管理能力がまったくありません。 「著者が書き終わったときが脱稿、編集が終わったときが印刷所入稿」くらいの粒度でしか工程を管理できない体たらくです。 gitのコミットベースで著者と進捗の話ができる分野の本でなかったら、きっと今以上に新刊のペースが落ちるでしょう。

書籍のプロジェクトマネジメントをやってやるという人がどこかにいないかな

最後に、ちょっと泣き言をいいます。

ぼくの編集者としての生存戦略はプロダクトマネージャに全振りすることですが、それだけでは回らないので、一緒に会社をやってる高尾さんにプロジェクトマネジメントのかなりの部分を依存しているのが現状です。 しかし、高尾さんは高尾さんでほかにいろいろな仕事もやっているので、当社ではプロジェクトマネジメントの面で著者にあまりよい体験を提供できていないのではないか、その結果として本をなかなか読者に届けられていないのではないか、という危惧があります。

そんなわけで、どこかにプロジェクトマネージャ、具体的には著者への進捗確認やぼく自身の編集作業の進捗をかっちり見られるという人がいないかな、というのをぼんやりと考え始めました。 いまや絶滅しつつあるかもしれない出版社の編集者という仕事に興味があって、プロダクトマネージャとして本を作る経験はないけれどプロジェクトマネージャとしてならビシバシとケツを叩ける、もしくは著者とコミュニケーションをとって段取りをしっかり組むから本が自然に出るようにできるぞという『デッドライン』のトムキンス氏みたいな人がいたらうれしいなあ、と。

そういう方向で、またそういう方向じゃなくても、ここで述べたような出版社の編集者という仕事に興味がある人がいたらとりあえず相談もらえたらなと思っているところです。(もとよりモロビア共和国のような待遇どころか並の正社員としての待遇も約束できない現状なので、「もうちょっと詳しく編集者について話をきかせろ」くらいの温度感でいてもらえたら気楽です…)

追記

「編集者の仕事として〇〇が抜けている」「むしろ〇〇である」といったコメントが散見されるので追記します。

この記事で言いたいのは、そういう〇〇を抽象化(数学的な意味で)すると(ソフトウェア業界の)プロジェクトマネージャとプロダクトマネージャがそれぞれ担うとされている役割に区分されるのではないか、ということです。

編集者がやってることなんて個人によってかなり違うし、だからこそ文字通り「ノウハウ」なんだけど、それだと各自でノウハウを見出すまで仕事にならないんですよ。大手であれば、未経験からノウハウを手に入れるまで、経験者が傍らでフォローしてあげられるし、その間は戦力にならなくても平気なんだろうけど、リモートのみで資金力もないとこだと「ノウハウ」のままでは継承ができない。

ふんわりと「本ができるまでの執筆以外のすべて」とみなされている職能に、プロジェクトマネージャとプロダクトマネージャという輪郭を与えれば、とくに前者はドメイン知識がない段階でもプロフェッショナルを発揮できることが可能なので(ソフトウェア業界から伺い知る限りでは)、そこができますよという人がいたら手伝ってもらえるかもしれない、という話です。

実をいうと、このような編集者の役割の分離が、特に出版業界では共感されないだろうなという自覚はあって、というのも、ぼくが既存の出版社をやめた理由のひとつに、まさにこのあたりの感覚がまったく理解されない人に納得いかない人事をされたからというのがあるから。出版には出版のプロジェクトマネジメントがあり、それは編集者ならできるべきである、というのはもっともなんですが、プロジェクトマネジメントであるには違いないので、そこだけ切り出すこともできるはずなんですよね。

QMKの「タップ」と「ホールド」を極める

自作キーボードを始めるとお世話になるQMKというファームウェアがあります。 キーボードは要するにスイッチなので、「どのスイッチが押されたときにどのキーの情報としてPCに伝えるか」を制御する必要があるのだけど、これはキーマップと呼ばれる情報をATmegaやARMのマイコン向けにコンパイルすることで開発します。そのための開発環境を提供してくれるのがQMKという感じ。

で、自作キーボードといってもたいていはキットを使うわけで、そういうキットの多くにはデフォルトのキーマップがあるから、そのデフォルトのキーマップをターゲットのマイコン向けにコンパイルしてそれをインストールすれば事足ります。 QMKには、代表的な自作キーボードのキット向けのデフォルトのキーマップもあらかじめほとんど用意されているので、そのキーマップに手を加えることで自分の好きな設定のキーボードに調整することも可能です。

調整というと、やりたい人がやればいい作業に聞こえるかもしれませんが、40%キーボードとか30%キーボードのように極端に物理キーが少なくなると、デフォルトでそのまま使える人はむしろ少なく、たいていは自分の癖や好みに応じたキーマップのカスタマイズが必須になると思います。 CtrlとかShiftとかAltといったモディファイヤキーはもちろん、数字キーすら足りなくなるので、1つの物理キーに4つとか5つとかのキーを割り当てることになるからです。

「どの物理キーを叩いたら何を入力できるようにするか」という基本がおおむね整ったら、その次にカスタマイズ攻略にとって重要になるのは「タップ」と「ホールド」を自分の運指の癖に合わせて設定することでしょう。 QMKでは調整可能な項目がけっこう多く、そのわりにケーススタディ的な解説が少なくてわりと試行錯誤したので、その記録を整理することにしました。

「タップ」と「ホールド」とは

1つの物理キーに複数の挙動を割り当てる際に、もっとも手頃なのは、「長押ししたときには別の役割を与える」という仕掛けでしょう。 たとえば、ある物理キーにこんなふうな設定を与えることで、[Ctrl]キーが物理的には存在しないキーボードが作れます。

  • 「タップ」すると、PCに[A]が送出される
  • 「ホールド」すると、PCには[A]ではなく[Ctrl]が送られる

この場合、このキーを「ホールド」しながら[S]のキーを押すことで[Ctrl-S]を入力できるので、[Ctrl-S]に関する操作性は[Ctrl]キーが物理的に存在しているキーボードとさほど変わりません。 これだけだと[Ctrl-A]を入力したいときにちょっと困ってしまいますが、同様の仕掛けを他のキー、たとえば「タップ」すると[Z]になるキーに設定しておけば、その[Z]のキーを「ホールド」してから[A]を「タップ」することで[Ctrl-A]を作れます。

30%キーボードとかになると、物理キーが30個くらいしかないので、この「ホールド」と「タップ」の設定をたくさんの物理キーに仕込むことになります。 しかし、そういうキーボードで高速にテキストを入力していると、「ホールド+タップ」のつもりの動作が「タップ+タップ」とみなされてイライラしたり、逆に「タップ+タップ」のつもりが「ホールド+タップ」になってびっくりしたりするといった症状にとても悩まされることになります。

物理キーが少ないと、キーマップを忘れて困るということはほとんどなくなりますが(単純に覚えることが少ないので)、この「タップ」と「ホールド」の細かな違いでフラストレーションがたまることがよくあります。 そこでQMKでは、この「タップ」と「ホールド」の挙動を細かく制御できる仕組みがいろいろ用意されています。

用意されているんですが、この「タップ」と「ホールド」の挙動の制御、リファレンスの説明では「どういうときにどんな設定をすればいいか」というのがわかりにくくて、「機能の説明」と「これは高速なタイピングをする人むけの設定です」みたいな雑な情報しかありません。 それでも試行錯誤の結果、現在は実用的に30キー(タップのみではアルファベット26文字とカンマ、ピリオド、リターン、バックスペースのみ)で生活できているので、ここまでに自分が読み取ったQMKにおける「タップ」と「ホールド」調整の勘所みたいなものをまとめたのが以下の記事です。 そのままコピペして使える情報ではないので、必ずQMKのリファレンスも参照してください。

「ホールド+タップ」のつもりが「タップ+タップ」になってイライラする場合

QMKでは、ホールドとみなされる時間をTAPPING_TERMという変数で管理しています。 この変数を小さくするほど、キーの押下がホールドとして認識されやすくなります。

TAPPING_TERMは、一般には200ミリ秒くらいが妥当とされていますが、タイピングが高速になると、この時間をもっと短くしないと打鍵のテンポが狂います。 これは、QMKでは2つのキーを同時に押すだけでは「片方がホールドされて同時に押された状態」とはみなされず、TAPPING_TERM以上ホールドを維持してはじめて同時に押された状態とみなされるからです。 「ホールド+タップ」をしたつもりでも、この期間内に指を離してしまったら、「タップ+タップ」になってしまうわけです。 先の例だと、[Ctrl-S]を入力したつもりが[A][S]という入力になってイラっとすることになります。

原因が「TAPPING_TERM以内に「ホールド+タップ」を完了してしまって最初の打鍵が「ホールド」とみなされないこと」にあるので、自分が「ホールド+タップ」の打鍵を完了する時間より短い値を最初のキーのTAPPING_TERMとして設定する、というのが解決策になります。 このために利用できるのがget_tapping_termという関数で、こんな感じにキーごとの設定をかなり細かく指定できます。

uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LCTL_T(KC_A):
            return 150;
        case LT(2,KC_B):
            return 100;
        case LT(1,KC_N):
            return 200;
        default:
            return TAPPING_TERM;
    }
}

ただし、get_tapping_termで短すぎる値を設定すると、今度は単発の「タップ」が難しくなります。現実的に自分は100ミリ秒くらいがストレスなくタップを実現できる下限でした。そのため、これより短い時間のうちに「ホールド+タップ」を完遂してしまうと、依然として「タップ+タップ」になってしまいます。

そこでQMKにはPERMISSIVE_HOLDという設定が用意されています。 この設定を有効にすると、TAPPING_TERMより短に時間内に「ホールド+タップ」を完遂しても「タップ+タップ」にならず、あくまでも「ホールド+タップ」として扱われるようになります。

PERMISSIVE_HOLDは案外と使えない

ただし、PERMISSIVE_HOLDは別種のイライラを引き起こします。 高速に連続して押した場合に「ホールド+タップ」とみなされては困るパターンがけっこうあるからです。

たとえば、QWERTY配列の最上段を数字キーと兼用していて、切り替えを[N]キーの「ホールド」にしているというケースを考えてみてください。 このとき、[N]キーを「ホールド」しながら[I]を「タップ」すると、「8」が入力されます。 この状況で、[N]キーにPERMISSIVE_HOLDを設定していると、高速なタイピングで「ni」と入力したつもりが毎回「8」とみなされるようになります。 これはうざい。

なので、PERMISSIVE_HOLDは実はあまり使えません。

幸い、get_permissive_holdという関数を使うことで、この設定を特定のキーのみで有効にできます。 次のキーに指をかけてしまうのを待てず、ほぼ同時に2つのキーを押してしまうようなパターン(自分の場合は「親指+人差指」とか)について、「ホールド」に倒すという設定が可能です。 自分の場合は、[B]キーと[F]キーの同時押しでIME起動をやっていて、これが日本語を高速に入力しているときに「bf」になることが多くてうっとうしいので、[B]キーに対してのみget_permissive_holdを使うことにしました。

bool get_permissive_hold(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LT(2,KC_B):
            return true;
        default:
            return false;
    }
}

「タップ+タップ」のつもりが「ホールド+タップ」になってびっくりする場合

PERMISSIVE_HOLDには、ゆるい打鍵がだいたい「ホールド」になるので、「タップ」のつもりの打鍵が思わず「ホールド」になってしまってびっくりするという弊害もあります。 たとえば、[A]キーに「ホールド」で[Ctrl]を割り当てているとしましょう。 そして、「ホールド」として多用したいのでget_tapping_termを短く、かつget_permissive_holdtrueにしたとしましょう。

この設定で、たとえばウェブフォームで「荒川」と入力すると、最初の「ar」で[Ctrl-r]というショートカットが発動してリロードが走り、それまでフォームに入力していた情報が消滅するといった状況がわりとよく起こります。

このようなびっくりを防ぐのに有効なのが、IGNORE_MOD_TAP_INTERRUPTという設定です。 この設定を有効にすると、TAPPING_TERMの時間だけしっかり同時に押されていた場合にのみ「ホールド」とみなされるようになります。 get_tapping_termが短いキーが「ホールド」になって次のキーとの組み合わせで予期しない入力になるという事態を防いでくれるわけです。

もちろん、get_permissive_holdを設定しているようなことがなければ、TAPPING_TERMの間に同時押しを完遂した打鍵は無事に「タップ+タップ」とみなされるので、「あるキーを「ホールド」とみなされにくくする」という目的に対しては「get_tapping_termを長めに設定する」のがセオリーです。 しかし、あまり長くすると「ホールド」になるまでの待ち時間で打鍵のリズムが狂うので、せいぜい225ミリ秒くらいが限界でしょう。 get_tapping_termはこの程度の長さにとどめておいて、IGNORE_MOD_TAP_INTERRUPTを有効にしておけば、うっかりホールドになってイライラするケースはかなり潰せると思います。

IGNORE_MOD_TAP_INTERRUPTは、「タップ+タップ」のつもりが「ホールド+タップ」になってびっくりするという症状に対して万能に思えますが、どうしても「ホールド」に倒したいというキーもあります。 その場合はget_ignore_mod_tap_interruptという関数で特定のキーをfalseにできます。

自分の場合は、左手の親指をわりとはやく上げてしまう癖があるようで、IGNORE_MOD_TAP_INTERRUPTが有効だと「ホールド+タップ」のつもりが「タップ+タップ」になってイライラするという症状に悩まされました。 なので、[B]キーだけはget_ignore_mod_tap_interruptfalseにしています。

bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LT(2,KC_B):
            return false;
        default:
            return true;
    }
}

「ホールド」のつもりが「タップ」の繰り返しになってしまってイライラする場合

これは実際にはタイプミスで、最初にしっかり「ホールド」ができていなくて一瞬指が浮いてしまったような場合に起こります。 ふつうのキーボードに期待されるような長押しによる連続入力を実現できるように、QMKでは「タップ」して「ホールド」するとこういう挙動を示すようになっているからです。

しかし、たとえば[Enter]キーに「ホールド」の挙動を付加するような場合、この挙動を抑制するほうが心穏やかな入力が可能です。 そこでQMKで用意されているのがTAPPING_FORCE_HOLDという設定です。 get_tapping_force_holdtrueに指定したキーは、単純に上記のような挙動が抑制されます。

bool get_tapping_force_hold(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LT(3,KC_ENT):
            return true;
        default:
            return false;
    }
}

「タップ」したつもりが「ホールド」になっていて、指を離しても何も入力されない場合

TAPPING_TERMを短くしていると、細かい動作が苦手な薬指で押すキーなどで、すばやい「タップ」をしそこなって「ホールド」とみなされてしまうというケースが起こりえます。 そういう場合、そのキーにretro_typingを設定おくと、仮に「ホールド」になってしまっても何も別のキーを押さずに指を離せば「タップ」になります。

bool get_retro_tapping(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LCTL_T(KC_S):
            return true;
        default:
            return false;
    }
}

「ダブルタップ」という裏技

ここまでで「ホールド」と「タップ」に関する勘所はだいたい抑えたと思うんですが、実際のところ30キーだと「ホールド」と「タップ」だけでは機能が足りません。 たとえば自分は、[q]を二回素早く押すと[Esc]になるというトリックを混ぜていて、これはとても便利に使えています。 これはQMKのTap Danceという機能でプログラム可能で、ほかにもいろいろ応用できます。

enum {
      TD_Q_ESC,
};

void dance_q_finished(qk_tap_dance_state_t *state, void *user_data) {
    if (state->count == 1) {
        register_code16(KC_Q);
    } else {
        register_code(KC_ESCAPE);
    }
}

void dance_q_reset(qk_tap_dance_state_t *state, void *user_data) {
    if (state->count == 1) {
        unregister_code16(KC_Q);
    } else {
        unregister_code(KC_ESCAPE);
    }
}

qk_tap_dance_action_t tap_dance_actions[] = {
    [TD_Q_ESC] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, dance_q_finished, dance_q_reset),
};

まとめ的な

一時期は仕事で疲れるとQMKのSoftware Featuresのリファレンスを眺めるという感じで、今では30キーでもほとんどストレスなく入力ができる状態になりました。

beta.docs.qmk.fm

これからも便利そうな設定が見つかったら追記していこうと思います。

『Engineers in VOYAGE』の「ITエンジニア本大賞」受賞に寄せて

本って「紙に情報を印字して束ねたもの」っていう点ではどれも見た目が似ていて、そのため「本」という単一の群が存在するかのように扱われがちな傾向があると思う。 でも、とくに商品として見ると、本はジャンルごとにぜんぜん別物だ。 ジャンルごとに「購入しよう」という意思をもって本を見る人、つまり「潜在読者」が違うから、作り方も売り方もまったく変わってくる。

それでも「紙に情報を印字して束ねたもの」が一つの市場で扱われているのは、やはり「流通させやすいから」っていう側面が大きいんだろうな。 というか、流通のために「紙に情報を印字して束ねる」という形に情報を押し込めているといっても過言ではない。 まあ、もちろんこれは過言であって、情報を人間が扱いやすい形にしたものを基準にして流通を考えた結果が現在だから、現在はそういうものに適した流通になっているだけなんだろうけれど。

自分たちが「紙に情報を印字して束ねたもの」を都合よく同一視して商売しているのだという意識は大切だと思う。 どんなに便利であっても、流通のために「紙に情報を印字して束ねたもの」を単一の商品として扱うのが「雑」であることには、お仕事として本を扱っている立場としては自覚的でありたいということだ。 でも、実際にはこの点を曖昧にしたまま、本や出版について語られていることがけっこう多い気がする。 もっとも、とくにプロの編集者みたいな人が「本」を語るときって、それはだいたいエンタメや文芸というジャンルであり、その意味では曖昧さはないって言ってもいいのかもしれない。

IT系の本が評価を受ける機会としてのITエンジニア本大賞

さて、ITエンジニア本大賞の話である。 日本語圏において、情報通信技術に携わっている人を主な対象とした「紙に情報を印字して束ねたもの」は、対象が情報通信技術ということもあって、ブログとかSNSでの書評や紹介という形での評価を受けることが多い。 そんななかで、このITエンジニア本賞は評価の場としてユニークな存在だと思う。

これは余談だけど、英語圏では同ジャンルを対象とした賞としてJolt Awardsというのがある。いや、あった。2014年まで存在した月刊誌 "Dr. Dobb's Journal" の企画だったんだけど、そのオンライン化と更新停止とともにJolt Awards 2015をもって終了してしまっていた。

また、賞とは異なるものの、ジュンク堂池袋本店では毎年1月に「新春座談会 このコンピュータ書がすごい!」というトークセッションが開催されていた。同店における前年の年間実売数ランキングをベースとして、達人出版会の高橋さんが書籍の紹介をするというイベントで、こちらも今はなくなってしまったけれど、ちょっとしたお祭りとして楽しかったし、同店のランキングと合わせてこのジャンルの本の評価の場として機能していたと思う。

もうひとつ、このジャンルの本を対象とした有名な賞としては、大川出版賞があるか。 財団的なところが制定している賞はどの界隈にもある。 前の会社で他部署の本がときどき受賞してたので、存在は知っているんだけど、過去の受賞をみても方向性がよくわからなかったので特にコメントはありません。

その他、商業的な本の評価としては、口コミや賞よりも「何部売れた」とか「何刷した」とか「オンライン書店でランキングがいくつになった」といった基準のほうがわかりやすいという話もある。 だが、これらは見かけほどにわかりやすくはない。 情報通信技術というジャンルに絞ってさえ、その内部には技術分野としてだけでなく読み手の達成度などに応じた複雑なセクターが無数にあり、それぞれに対象読者の傾向は違う。 「何かのきっかけて売れた本だけがますます売れる」という単純だが揺るがない現実もある。 そもそも、うちみたいな大きな取次との直接取引がなくて店頭で気軽に手にとれない出版社の本と、新刊はどんな内容であれいったんは全国の書店に行くという出版社の本とでは、刷数の考え方もぜんぜん異なる。

そのような中にあって、ITエンジニア本大賞という存在は、このジャンルの「紙に情報を印字して束ねたもの」を評価する場としてわりと唯一無二であり、それゆえに貴重なイベントだと個人的には思う。 前述した「ジャンル内における無数のセクター」がすべて対象なので粒度が荒いとか、投票により大賞を決定することで未読の人からの期待感が反映されてしまうとか、そういう難点はあるけれど、そういうアンバランスさがあるのはどんな賞でも似たり寄ったりでしょう。

ITエンジニア本大賞はインディーズ出版社には無理っぽかった

とはいえ、自分はITエンジニア本大賞には縁のない編集者なんだろうなあと勝手に思っていた。 過去に一回、『新装版リファクタリング』で審査員特別賞をいただいたことがあるものの、このときはそこそこまあまあな大きさの出版社にいたからで、もう本賞にかかわれる機会はこないだろうなと思っていた。

そんなふうに思っていたのは、ITエンジニア本大賞の選考プロセスに理由がある。

ITエンジニア本大賞では、まず賞のウェブサイトから本のISBNをフォームに指定することで自分の推し本をなんでも投稿できるんだけど、ふつうISBNなんて覚えていませんよね。 そこで、実際の投稿の大部分は、この投票ページにあらかじめ一例として掲載されている50冊程度の「参考本」のなかから選ばれているものと推測できる。 まずこの50冊程度の参考本の一冊に選ばれないと、その後の受賞プロセスに残れる可能性はとても低い。 つまり、「技術的には任意の本に対して投票可能だけど、事実上は投票ページの本が選考対象」という実態がある。

ここで当社にとって難関なのは、この参考本が審査員や事務局の推薦と年間の書店での実売データに基づいて決まることだ。 うちのような「書店であまり流通していない」ような出版社の本だと、書店での実売がないから、そもそも選定されるチャンスが限りなく低い。 まずスタートラインに立つのが原理的に難しいのである。

にもかかわらず、2021年のITエンジニア本大賞の告知ページでは、ラムダノートの『Engineers in VOYAGE』が参考本の一冊に含まれていた。

f:id:golden-lucky:20210303180433p:plain
「ITエンジニア本大賞2021」のWeb投票画面から

このときの喜びをわかっていただけるでしょうか?

まさかのエントリー、そしてノミネート、そして大賞受賞

実をいうと、『Engineers in VOYAGE』の監修であるVOYAGEの小賀さんから、「デブサミで毎年やってる技術書大賞をとりたい!」というお話をされたことがあった。 そのときは上記のような事情から、「あの賞は従来型の営業や流通にパワーをさけない出版社だとノミネートにすら手が届かないのが実情なんですよ」と苦しい気持ちでお返事した。 それが、まさかの第一関門突破である。

だが、これはスタートラインに過ぎない。 ここから投票数でベスト10に残り、さらにその上位3冊がデブサミで開催されるプレゼン大会を経て、はじめて大賞が選ばれる。

Web投票のページを見た人のITエンジニアのなかには、「ほかの本は書店で見たことあるけど、これは見たことないな」という人も少なからずいたはずだ。 実際、投票した人によるツイートを検索しても、本書の名前はそれほど目立っている印象がない。 正直なところ、編者の和田さんから「過去に自分の本は二回までベスト10に残ったけど、プレゼン大会に勝ち進んだことがないので、三度目の正直で残りたい」という思いをお聞きしたときも、「今回は弊社の力が及ばずたぶんベスト10もギリギリです、すみません」という心境だった。

ところが、なんとベスト10に入り、さらにプレゼン大会への進出も決まってしまう(オンラインで投票していただいた皆様、本当にありがとうございます!)。 当初ツイートが少なく見えたのは、この本だけISBNから名前を解決する実装がおかしかったからかもしれない。 個人的には、ベスト10に残ったことのうれしさもさることながら、「プレゼン大会に出る」という和田さんの夢がかなったことによる安堵が大きかった。

f:id:golden-lucky:20210303181133p:plain
ベスト10に選ばれた!

しかし、和田さんは「プレゼン大会に出る」で夢を終わらせるような人ではなかった。 自分もプレゼンを生で聞いていたわけだけれども、この本の読みどころを伝える圧倒的なオンラインプレゼン。 端的にいって「お、面白そう、読んでみたい」と思わせる生々しさ。

そして大賞受賞である

エンジニアだからこそ楽しめるエンタメの本

今回の受賞は、ちょっと素直に喜んでいいのかわからないというレベルで個人的にうれしい。 単純に評価されてうれしいという以上に、受賞を契機にした露出によって、あきらめていた層にまでリーチできるかもしれないのがうれしい。

この本は、当社の他の本と違い、特定の要素技術を体系的に解説する本ではない。 ソフトウェアを利用した事業を営む人と、そのためのソフトウェアを作る人とを結ぶ生々しい物語を、主に後者の視点から描いた本だ。 エンジニアだからこそ楽しめるという意味で、デマルコのある種の本のように、エンタメとしての魅力がある(フィクションではなくノンフィクションという違いはあるけれど)。

問題は、エンタメの本は業務上ののっぴきならない必要性にアピールするわけではないので、「露出してなんぼ」が現実であるという点にある。 実店舗で大量に流通して露出しなければ、本書のようなエンタメ要素を持つ本を読んでくれる人に届きにくい。 しかし、露出させて売るのは、どう考えても小さな出版社の営業力では無理だ。

そもそも小さな出版社には「露出」が難しい。 「書店にいつも自社の本が置いてある」という状態は、出版社から本を出すアドバンテージのひとつである。 小さな出版社にはそれがないから、通常はその状態を作るところからのスタートになるんだけど、うちはそういう戦略はとらなかった(とれなかった)。 だから、こういう本には弱いと思っていた。

それでも、いろんな人の力でそういう本を発行し、たくさんの幸運と応援によって賞という形で評価をいただけた。

  • 「面白い本だがうちで出してちゃんと評価されるんだろうか」という不安まじりで発行した本が賞という形で評価されたことの単純なうれしさ
  • メジャーレーベルじゃないからってなかば諦めていた場での評価が得られたことのうれしさ

これが今回の受賞で個人的にうれしかったポイントだと思う。 本書をここまでもってきていただいたみなさん、本当にありがとうございます。

もっとたくさんの人に手に取ってほしい

この本は、ITエンジニア本大賞を受賞してうれしい、で終わってほしくない。 受賞はしたものの、当社の流通経路が増えたわけではないから、とつぜん書店に山積みされるようなことにはなっていない(はず)。 だって、ぼくが書店をやっていたら、インディーズ出版社の本をITエンジニア本大賞だからっていきなり大量に仕入れるようなリスクはとらないだろうから。

でも、コンピュータの専門棚がそれなりに動くような書店であれば、本書に限らず、うちの本はそれなりに回転すると思います。 ぜひ下記のページを見ていただき、可能そうなら仕入れを検討してみてください。 比較的すぐに売れると思うのは、2021年1月の新刊『Webブラウザセキュリティ』と、それとよく似たカバーの『Goならわかるシステムプログラミング』および『みんなのデータ構造』あたりです。

www.lambdanote.com

そして一言、「ラムダノートの本、売ってるよ」とTwitterでつぶやいてもらえれば、全力で反応いたします。