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_holdをtrueにしたとしましょう。

この設定で、たとえばウェブフォームで「荒川」と入力すると、最初の「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_interruptをfalseにしています。

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_holdをtrueに指定したキーは、単純に上記のような挙動が抑制されます。

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

本稿の執筆時は、この挙動を抑制するためにTAPPING_FORCE_HOLDという真偽値が使われていましたが、2023年2月26日の変更で、「タップ」の繰り返しとみなされる時間をミリ秒単位で指定できるようになりました（参考）。 すべてのキーに対する設定はQUICK_TAP_TERMであり、これはデフォルトでは上述したTAPPING_TERMと同一になっています。 キーごとに制御するためには、下記のようにget_quick_tap_termという関数を使います。

uint16_t get_quick_tap_term(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case LT(3,KC_ENT):
            return 0;
        default:
            return QUICK_TAP_TERM;
    }
}

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

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キーでもほとんどストレスなく入力ができる状態になりました。

https://beta.docs.qmk.fm/using-qmk/software-featuresbeta.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』が参考本の一冊に含まれていた。

「ITエンジニア本大賞2021」のWeb投票画面から

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

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

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

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

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

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

ベスト10に選ばれた！

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

#devsumA 生々しい本のプレゼンが始まった pic.twitter.com/Cpt7HNRd3B

— keiichiro shikano λ♪ (@golden_lucky) February 18, 2021

そして大賞受賞である。

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

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

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

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

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

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

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

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

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

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

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

www.lambdanote.com

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

ラムダノート第5期の出版活動の個人的ふりかえり

設立からあっという間に5年が経過し、さらに出版で収益が出るようになってから4年が経とうとしている（最初の1年間ちょっとは何も本を出していなかったので）。 既刊の点数も10を超えた。 なんとなく、この第5期は、気づいたら出版社としてのトンネルを1つ抜けた一年だったように思う。

第5期は、2本の新刊単行本と、1本の『n月刊ラムダノート』を発行した。

• 『徹底解説 v6プラス』
• 『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』
• 『n月刊ラムダノート Vol.2, No.1(2020)』

新刊2冊は、思いがけず企業さんとのタイアップという形で実現した企画だった。 といっても、どちらも著者を見ればわかるように、技術を解説する本という点で妥協はない。 むしろ「第三者視点では外に出ることがあまりなかった情報」を書籍という形で世に出せたことが個人的には大きいお仕事だった。

もうちょっと補足する。

現在は、コンピュータ技術の解説書というと、ソースコードや論文であったり、仕様やリファレンスであったりをベースとした内容であることが多い。 これらは一般に公開されている情報だ。 インターネット時代のコンピュータで使われている技術は、このような公開の情報をベースに本を書けることが多い。

しかし、そういう公開の情報を集めるだけではなかなか理解がしにくい技術というものもある。 特定の企業によるプロプラな技術だけど社会の基盤になっているような技術がその代表だ。 とくにネットワーク関連技術は、歴史的、政治的、経済的な経緯もあって、そういう状況にある話題が多い分野だよなと個人的には感じている。 インターネットだけが通信ネットワークになってしまった現代では想像しにくけど、ほんの20年前くらい前はコンピュータ通信といったら時分割多重化されたデータを回線交換機を介してやり取りしていたわけで、そこで回線交換機がどう運用されるのかとかを知りたかったらNTTの中に入って直接聞くしかなかった。 2020年1月に発行した『徹底解説 v6プラス』は、まさにそういう時代からの影響があってはじめて理解できるような技術を、中の人の全面協力のもとで書くならこの人しかいないでしょうという唯一無二の執筆者によって形にできた本だと思っている。

そして技術には人間の営みがどうしても織り込まれてくる。 仕様策定プロセスや開発がオープンであれば、そこから当該の技術を成り立たせている論理や文化をある程度までは伺い知れるけれど、一般に「その技術を実際に支えている人たちがもっている技術」は本当に外部には伝わりにくい。 でも、その伝わらない部分もまた技術なのであり、技術書のひとつのテーマとして面白いだろう。

こうした「とくに隠しているわけではないけど非公開になっている情報を本にする」というのは、ちょっと考えればわかるようにとても難しい。 これが、外部からの「その話、知りたい」という圧が十分に高い可能性があるような話題なら、まだコンテンツとして成立しやすい（みずほ銀行のシステム開発の本とかはその好例）。 しかし、外部からの取材をゼロから始めて本にしようと思ったら、当然それだけのコストや年月がかかるので、おいそれと企画できるものでもない。 なんだけど、やはりチャンスがあれば企画したいと常々思っていた。

そんな中で、まさにそういう本を作れる機会をもらえたのが、2020年8月に発行した『Engineers in VOYAGE』だった。 Webで事業をやっている会社の中で技術者たちが何をしているか、そういう会社で働いているソフトウェアエンジニアには当たり前かもしれないけど、そもそも外部の人間や技術者でない人間には知りえない話で、でもみんなそれなりに興味はある。 ソフトウェアエンジニア自身だって、自分が知らない他社における技術者の文化には興味があるだろう。 まさにそういう本を、やはり「この本を作るならこの人が手掛けるしかないでしょう」というインタビュワーと、そのインタビュワーでなければ汲み尽くせないであろう深い技術者文化を培ってきた会社の全面協力で実現したのが、『Engineers in VOYAGE』の企画だった。

正直、どちらの本も、これだけの座組をぼくの主導と当社の企画力だけで実現することは不可能だったと思う。 そういう意味で、こうやって企画をふりかえると、第5期はなんというか、本当に幸運に恵まれたなあというか、「いつかやりたい」と思っていることは案外とふいに実現するものなんだなあというか、そういう一年だった。 これからも「こういう本を作りたいんだよなあ」みたいな意識をぼんやり抱えてやっていこうと思います。

一方で課題もある。まずは『n月刊ラムダノート』だ。一昨年に始めた不定期刊行誌だけど、昨年は1本しか形にできなかった。 原因は完全にぼくの力不足です。 ぼく自身の企画のタコツボ化を回避したくて寄稿ベースという形をとったのだけど、無から何かが生まれて結実するはずはなく、ネタをもらっても前に進めて完成させるための動力がいずれにしても必要になるのだよな。 そして、そのための動力が去年の自分には足りなかった。

もうひとつの課題は翻訳書だ。いくつか版権を購入したまま進められていない本があるのでやっていく。どれも面白いよ。

新しい期になって、すでに新刊『Webブラウザセキュリティ』を発行した。 こちらもまた思い入れがあるので、近いうちに個人的なふりかえりを書く予定でいる。

独学でプログラミングを勉強した自分がこれは役に立ったなと思っている本

今ではプログラミングできないわけではないけど、そういえばプログラミングは完全に独学と言っていい。 いや、大学では数学をやっていたので、FortranとかLispはちょっとやった。 なので「完全に独学」といったら嘘になる。

それでも、いま仕事で使っているコンピューターの知識は、基本的にすべて書籍を通して独学したものだ。 そこで、自分が何の本を読んでプログラミングを実務で使えるくらいにはなれたのか、アフィリエイトと宣伝を込めつつちょっと振り返ってみてもいいかなと思って走り書きしてみる。

テキストフィルターを書きまくるとこから始めるといいと思う

プログラミングぜんぜんやったことない人が「プログラミング完全に理解した（ダニング・クルーガー的な意味で）」という実感の端緒を得るまでには、まず「テキストフィルタを書きまくる」のがわりと近道だと信じている。

コンピューターを使うことがインターネットを使うことと激しく重なっている現代、ブラウザで動く何かを作るところから始めたくなる気持ちはわかる。 しかし、とにかくテキストフィルタをたくさん書く、という経験には、プログラミングの独習者にとって次のようなメリットがあると思う。

• テキストデータのありがたみを思い知れ
• コンピューターとのやり取りの仕方（標準入出力）に慣れろ

これほどブラウザで動く何かが全盛でなかったころのプログラミング初心者本にも、「デスクトップのアイコンをクリックして実行できる何かを作れると初学者のモチベーションにつながるよね」みたいな空気があった（要出典）。 これは現代においてはブラウザ上で動くプログラムとかスマホのアプリになるように思う。 しかし、「プログラミング未経験者にとって身近なプログラム」というのは、プログラムを書けるようになれば誰もが気づくように、コンピューターからユーザーを遠ざけるようにうまく抽象化されてるものなんだよな。 そういうのからスタートしてしまうのは、（アプリケーションを通してでなく）コンピューターを操るための手法としてのプログラミング（プログラミングスクールに行く人が知りたいのはこれだと信じている）を学ぶには、実はそれほど適さないんじゃないだろうか。

で、思い返すと、自分は 『Rubyで極める正規表現』 という本を通してテキストフィルタの書き方みたいなものを学び、そして書きまくっていた。

Ruby magic Rubyで極める正規表現

この本、正規表現の本というより「楽しいテキストフィルタを書けて楽しい！」というノリの本で、筆致もよく好きなんだけど、いかんせん古くて環境が合わないと思うので、あまり初心者におすすめできる感じではないのだよな…。

今でもテキストフィルタいっぱい書く本はプログラミング入門にはいいと思う。でも現代において該当する本といったら何があるだろう。いまいち面白みのない例題かつページ数が多いけど、 『退屈なことはPythonにやらせよう』 とかだろうか。

退屈なことはPythonにやらせよう 第2版 ―ノンプログラマーにもできる自動化処理プログラミング

プログラミング言語そのものを勉強すると手っ取り早い

テキストフィルタを書きまくって、コンピューター上のデータをプログラミング言語でいじることが空気を吸うみたいな作業に感じられるようになったころ（誇張があります）、“Structure and Interpretation of Computer Programs” という本を読んだ。一部を除いて練習問題もほぼ全部解いた。この本に書いてあったことは、その後いろんなプログラミングの概念を知るうえでの強固な足場になっていると今でも実感している。

Structure and Interpretation of Computer Programs, second edition (MIT Electrical Engineering and Computer Science)

この本、その名前だけはあまりにもよく知られてるので、「はいはい、すごい人がよくお勧めしてる、あのSICPっていう難しい本ね」とか「Schemeとかいうマイナー言語の本」という印象を持っている人もいるかもしれない。 実際、おれはアプリを作りたいんだとかゲームを作りたいんだとかで、自分には関係ない本に思っている人も少なくないと思う。

でも自分は、この本は「読んでおくと学習をショートカットできる」たぐいのチートだと思っている。 なぜなら、「プログラミング言語でプログラムを書くというのがどういう行為なのか」をずばり（再帰という言葉を使って）説明している本だからだ。 さらにその説明がそのままプログラミング言語のインタプリターという「プログラム」にも適用される。 つまり、「プログラミング言語もまたプログラミング言語によって書かれるプログラムである」みたいなカラクリを、自分で暗中模索することなく全部きれいに教えてくれる。

こういうノリ、つまり「再帰的な発想が問題解決にとってめちゃくちゃ効くぞ」みたいなノリって、たぶん実世界ではそれほど頻出しない。 だから、それこそゼロからプログラミングを学ぼうと思っているような人であれば、それまで想像もしたことがない話だと思う。 ことわざの「屋上屋を架す」は「無駄なことをする」の意味なんだけど、にもかかわらずプログラミングでは常套手段で、そのための知見がこの本をまじめに読むだけで手に入るのだから、これほどお得なことはないと思っている。

自分は未読だけど翻訳もある。ぱっとみの印象ほどややこしいことは書いてないし、なによりコードを書いて実行すれば答え合わせもできるんだから、プログラミングを独習しようとする人なら読んでみて損はないはず。

計算機プログラムの構造と解釈 第2版

とはいえページ数もあるし古い本だし、もっと気軽で現代的な教材がほしいという方もいるだろうから、まずは 『RubyでつくるRuby ゼロから学びなおすプログラミング言語入門』 を読むというさらなるチートを紹介します。

コンピューターのことをもう少し詳しく知る

SICPを読んだ自分は、これでもうどんなプログラムでも無限の時間と無限のやる気があれば書けるような気がした。 もちろん書けないんだけど、その理由のひとつは「コンピューターのことを知らなすぎる」からだ。 操る道具の使い方を知っていても、操る対象であるところのコンピューターがどういう仕掛けで動作しているのか知らなければ、できることは限られる。 ついでに言うと、「そのコンピューターでプログラムを動かすことによって解決したい問題をどうやってプログラミング言語で表現するか」っていうのもまた重要な話になるんだけど、それは次のセクションで触れる。

で、コンピューターである。 これについてはいろんな視点からの理解というのがあるだろうけれど、「プログラムを学ぶんだ」という視点から言うと、この 『コンピュータ・システム』 という本によって得られた理解が自分のなかで大きい。

コンピュータ・システム

この本は、ぶっちゃけていうと「おまえの書いたプログラムがどんなふうにメモリを使うのか」を教えてくれる。 自分はむかし原書の旧版を途中までしか読めずに挫折してたけど、いまは翻訳があるのでありがたいですね。 翻訳は事情により一通り目を通して、やっぱり名著だったと改めて思った。

ただ、一通り目は通したけれど到底身につけたというレベルでは読めていない。 それどころか、「これを全部意識せずにプログラムを書けるのありがたいな」と心底おもっている。 それでも、そういう部分も含めてとりあえずは押さえておかないと不安っていうのが独習者の心情であり、そういうニーズにこの本はぴったりな本だと思う。 だから、目を通したという経験があること自体がとても役に立っている。

一方、 『コンピュータ・システム』 だと低層すぎて、「じゃあ自分のプログラムをそういうコンピューターの上で動かすにはどういう仕掛けを使えばいいんだ」という点はいまいち見えずらい。 実際にアプリケーションをプログラムで書くときは、ファイルシステムとかシェルとかWebサーバーとかの「わかりやすい」層まで抽象化された道具を使うわけだけど、そのへんについて自分がはじめて理解した（ような気がした）のは “Understanding UNIX/LINUX Programming: A Guide to Theory and Practice ” という一冊の本を通してだった。

Understanding UNIX/LINUX Programming: A Guide to Theory and Practice

これも今は 翻訳 が出てるようなので、興味がある人は翻訳のほうがいいかもしれない、と思ったけど旧アスキーで今は入手困難なのかな。

Unix/Linuxプログラミング理論と実践

で、まあ、このへんはC言語の世界なわけで、「独学でWebでアプリを作りたいんだ」という人にとっては重たすぎるという異論は認める。 そういう方には、Go言語のランタイムの世界を通じて上記のノリをすべて解説してしまったこちらの 『Goならわかるシステムプログラミング』 がおすすめです。

解決したい問題とコンピュータープログラムとの橋渡しができるようになる

このへんまできたら、どんな分野でどんな問題を解決したいかに応じて、具体的に特定の言語でプログラミングの仕方を学んでいける段階になると思う。 そのため、「ある言語のちゃんとした解説書」がありがたくなる。

自分の場合は構造化文書をごにょごにょするというのが大きな関心領域のひとつで、その分野ではパーザを書くというのが仕事のひとつになる。 そのため、その分野に対する強い仕組みが備わっていたHaskellという言語を使うことにして、教科書としては “Programming in 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

これをベースにページ記述言語の部分を足していくことで、今年の年賀状のコードを書きました。

*1:本当はデザインのネタが思いつかなかった、かつ、アスキーアートにしたかったけどPostScriptに標準出力と文字列操作の機能がなさすぎて手に余った。

専門書を売る

「日本の専門書は安い、もっと高くあるべき」という意見があります。 この意見の背景には、専門書の価格はその価値で決まるかという観点と、出版社は専門書でどう利益を出せるかという観点があるような気がします。 ここでは、それぞれの観点について、個人的に「それって実際のところはどうなの」と思う点を書きだしてみます。

なお、両者の観点は本来は独立に議論できるものではないであろうこと、そもそも自分が観測できる範囲での意見を書きだすだけなので客観性のある議論でもないことに注意してください（自分は主に理工書、さらに言うとコンピューターに関する書籍で仕事をしています）。

専門書の価値で専門書の価格を決められるか

専門書の価格は、そもそも「価値」が何なのかという点に立ち返ると、わりと身もふたもないものになると思っています。 つまり、消費者がある専門書を書店で購入するとき何に価値を見出して対価を支払うのかを思い出そう、ということです。

自分は経済学をよく知らないですが、ある商品が購入されるかは消費者の効用で説明できるというふうに雑に理解しています。 ここで「効用」というのは、専門書の場合、「その本を読むことがどれくらい役に立つか」になりそうですね。

いや、本当にそうか？

多くの場合、ある専門書が実際に役に立つかを個人が判断するには、かなり時間がかかります。 なので、その専門書を読むことが自分の役に立つかどうか、消費者は購入時には判断できないと考えるのが自然です。 どんな商品にも多かれ少なかれそういう要素はあると思いますが、特に専門書を売る立場からすると、消費者がその場で価値を判断しにくいものにお金を払ってもらう、という考え方が基本になるとおもっています。

そういう前提で、他の専門書ではなく自社の本を選んでもらうには、何が決め手になるでしょうか。 本の中身自体で効用を判断できないとすると、多財の間での消費指向を説明する効用関数を決めるのは、見た目の印象（カバーの絵とか）、書名、著者、話題性や世間での評判、入手しやすさ、そして価格などだと考えるのが妥当でしょう。 本という形をとっている以上、「一般的な本の価格」を逸脱することは、他の同様な商品の中から本としては選ばれにくくなることを意味します。

一方で、「専門書の価格はもっと高くすべき」という意見は、専門書の需要が非弾力的、つまり価格が上がっても需要があまり減らないことを前提としているともいえます。 これは、ある専門書を買ってくれるであろう消費者は「その専門書しか同じ効用を得る選択肢がない」という前提と同じです。

仮にこの前提が成立したとして、それでも価格を高く設定しにくい理由は、大きく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をPro 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のどちらにどんなファームウェアを書き込めばいいのか？」というものがあります。 考えられるのは以下の三通りです。

1. 両方のArduinoに、同一のファームウェアのデータを、それぞれのUSB端子から書き込む
2. 両方のArduinoに、別々のファームウェアのデータを、それぞれのUSB端子から書き込む
3. 片方の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マイコンをコントローラとして利用している自作キーボードでは、一般に入手しやすいPro Microと呼ばれるArduinoボードとその互換機が利用されています。 これらPro Microたちは、（有線接続では）つい最近までUSB type Bが主流でしたが、ここ数年でtype Cの製品も手に入りやすくなりました。 type Bもtype Cもマイコンとしての動作は同じなので、自作キーボードでも問題なく使えると期待して今回の制作ではtype Cを使ったのですが、ひょっとしたらこれが「左右が連携できない」ことの原因かもしれません。

最悪はArduinoをtype Bに差し替えることも覚悟しつつ、その線に絞ってWeb検索をかけてみると、はたしてそのものずばりtype CなPro Micro互換ボードを左右分離型の自作キーボードで利用できるかどうか検討している記事が見つかりました。

• The Case of the Wayward Elite-C
  https://medium.com/@keebio/the-case-of-the-wayward-elite-c-73f0fd691f88

要約すると、「ボードによってはqmkで左右のマスター/スレーブ識別に使っている方法（コネクタの近くのダイオードにおける電圧をみる）が使えないことがある」という内容です。 比較的新しいPro Microのtype Cのボードがこれに該当する可能性は、いまの症状からしてもありえそうに思えます。

幸い、qmkには、この状況をソフトウェア的に解決する手段が用意されているということも上記のブログからわかりました。 具体的には、ファームウェアのコンパイル時に以下のマクロを有効にするだけです。

#define SPLIT_USB_DETECT

あらためてこの方法で生成したキーマップの .hex を左右両方のボードに転送したところ、無事に左右が連携してキーボードとして動作するようになりました。 こうして先人たちによる苦労のおかげで、さしたる苦労もなく、個人的な理想形の最北ともいえるキーボードが実装できました。 ありがたいことです。