golden-luckyの日記

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

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

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

誰もが自分の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でつぶやいてもらえれば、全力で反応いたします。

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

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

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

第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ですが…、

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

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:出版社として書籍の原価を考えるときは、売れようが売れずに返品されようが支払いが必要になる制作や印刷製本のコストと、売れた分だけを支払うことが前提の印税とはわけて考える必要があるので、以下の話は自分が企画時にざっくりと念頭において考えている感覚の話であり、決算時に計算するような原価の話ではありません。