golden-luckyの日記

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

ラムダノート第8期を迎えました

2015年12月に自分で出版社を立ち上げたとき、うっすらと決めていた覚悟は、「ひとまず10年は続ける」でした。

それまで15年くらい、技術系版元として歴史も規模もそこそこある出版社で企画編集をやっていたので、「だいたい何部くらい売れれば一人なら食っていける」といった程度の雑な算段はあったものの、かっちりした事業計画があったわけでもなく、「まあ、しばらくは前職の退職金を食いつぶしながら最初の何冊かを作ればいいかな」などと気軽に考えながら、むかし作った本の読者だったり有識者レビュアーだったりでお世話になっていた時雨堂という会社に遊びにいき、そんな浮ついた起業計画を雑談のつもりでしたら、社長の @voluntus に「お金出すよ」と言われ、「えっ」って戸惑っているうちに税理士さんを紹介してもらい、定款ができて、気づいたら ラムダノートという出版社 ができていました。

あれから満7年。2022年12月にラムダノートは第8期を迎えることになりました。会社をスタートできたのは時雨堂のおかげ、本を出せたのは著者や訳者のおかげ、なによりもこうして「本を売ってやっていく」ができているのは本を買ってくれる読者のおかげです。

10年という当初のぼんやりした目標まではもうひと頑張りありますが、よく考えたらコンピューターとネットワークの出版社なんだから節目の基数は2であるべきだし、1000_2周年をむかえるこのタイミングで感謝祭として大セールをやっています。協賛は再び時雨堂です。クーポンコード「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」を入力すると電子書籍がほぼすべて半額。ほんとうにありがとうございます。

余談ですが、この「クーポンコードによる宣伝」という協賛の企画を思いついたのも時雨堂社長の @voluntus です。天才かと思った。

このクーポンコードの文字列「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」は、お買い物で使ってもらうたびに当社のバックヤードに流れるので、みなさんにお祝いしてもらっている感も半端ありません。ほんとうにほんとうにありがとうございます。

さて、今回の大セールは12月19日まで引き続き開催中なので、ふりかえりにはちょっと気が早いのですが、今日までの段階で個人的に感じたいろいろをいったんダンプしておこうと思います。

セールの効果1：売り上げがすごい

ある程度は期待していた部分ではあるのですが、すでに直販サイトの平均的な売り上げの数か月分に達しています。おかげで、おそらく創業以来はじめて、期初の現金にやや余裕がある状態を迎えることができそうです。だいたい毎年、年末から年初にかけて現金が枯渇するのですよね…。当社の支払いサイクルの事情ではあるのですが、1月～2月と8月～9月にまとまった現金が必要で、メンタルがつらい。今年は例年になく穏やかな気持ちで正月を迎えられそうです。キーボードつくろうかな。

セールの効果2：潜在需要がすごい

売り上げについては、実は怖い気持ちもあって、「これ、来月からみんな本買ってくれないんじゃないかな…」という。アパレル系は年2回のセールで年間の売り上げを稼ぎ出すというし、電子書籍の世界でも半額セールや無料セールを定期的にやっているし、これはもうそういうものと考えるべきなのかもしれないけれど、セールをやるとわかっているショップではどうしたってセールを待ってしまいますよね…。当社の直販サイトでこれからセールを定期的にやるつもりはまったくないのですが、これだけ長期間のセールをやっていると、潜在的にラムダノートの本に興味があった人がすべて本を手にしてしまうかもしれない。

しかし、これは逆に考えると、「潜在的にラムダノートの本に興味があった人」がこんなにいたのかという素朴な驚きでもありました。専門書の編集者みたいな仕事を長年していると、「需要は限られている」という意識が骨の髄までしみついていて、ついつい実売部数についても「こんなものだろう」で思考停止してしまうんですが、そんなことなかったんだなあと。いつもよりお得っていう効果はあるにせよ、そもそも興味がないものに払えるお金はゼロ円なわけで、需要がしっかりあるという事実を目の当たりにさせてもらいました。

セールの効果3：知ってもらえた、思い出してもらえた

潜在需要が見えた背景には2つの要因があると考えています。1つは、当社が本として販売している情報に対価を払う意思はあったけど、それを当社で買えるという事実にそもそも気づいていなかった人がいたということ。もう1つは、当社で売ってる本のことは知っていたけど、買う機会を逃していた人がいたということ。いずれも、セールをやる前から「そういう人もいるだろうなあ」とぼんやりは想像していたわけですが、実際にセールを開始した後のツイッターなどの反響や、いわゆる直販サイトへのセッション流入数やコンバージョン率の上昇、まったく新規のお客様の割合などから類推するに、ぜんぜん想像以上でした。今回のセールは、短期での売り上げや、協賛の時雨堂を知ってもらう機会になったのみならず、「ラムダノート」という出版社の名前を知る人を中長期でかなり増やしてくれたのだろうなと実感しています。忘れないでね！

セールの効果4：刺激

当社としては、今回のセールを機に当社を新しく知ってもらった人や思い出してくれた人は、これから「当社が出す本」に期待していただいている状態だと考えています。正直なところ、丸7年間走りっぱなしだったので個人的にはちょっとお疲れ気味ではあるのですが、ここでめげずに新しい企画をやっていくぞという気持ちをセールへの反響や「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」というクーポンの文字列に支えてもらっている自覚があります。まだセール期間が1週間あるので、引き続きどんどんご利用ください！ あと、これからまたべらぼうに面白い新刊も出していくので、セール終了後も引き続き新刊情報をお見逃しなく！ 今年は結局新刊を出せなかったn月刊ラムダノートもやるよ！ 新刊情報については、メールとかはしていないので、 公式Twitter もしくは 直販サイトのお知らせページ をRSS購読してね。

本の原稿のバージョン管理を始めて20年たちました

「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。

目次です。

前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。

なんで「テキスト原稿のバージョン管理」の話をしなくなったか

いまからちょうど10年くらい前までは、「このスタイルでの書籍制作を自分以外にも広めるべきだ」という考えがうっすらありました。 当時在籍していた出版社の中でほかの編集者に勧めたり、外で発表したりすることも何度かありました。

www.slideshare.net

しかし、今はもうこのスタイルでの編集をあんまり内外で特別に喧伝することはなくなっています。理由は3つ。

  1. 自分の中では当たり前になってしまったので
  2. テキスト原稿のバージョン管理を個人ではじめる編集者がぽつぽつ増えてきたから
  3. その一方で、出版業界という粒度で見ると、ちっとも変わる気配がないし…

1つめの理由は、ようするに、自分が外向けに積極的に情報発信するくらい強い関心をもつ対象がもっと別のところにいった、ということです。飽きたともいう。

2つめの理由は、いい話です。中には、自分が過去にした情報発信を見てくれているような人もいて、ふつうにうれしい。そういう人たちが自分よりうまいことやってくれたら、それを真似できるので、さらにうれしい。

3つめの理由は、かっこよくいえば、諦観です。いくら情報発信しても変わらないなら、その人たちには不要ということです。 現状のまま、つまり「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルでの編集でうまく回っているなら、自分がしゃしゃり出て「テキスト原稿のバージョン管理のノウハウとか共有します」って言っても迷惑なだけだろうなって。

「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理…

なんか最近になって再び、文芸系の著者サイドから「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルについての恨みつらみが漏れ聞こえてくるようになりました。 編集者との赤字の共有が大変とか、手元ではテキスト原稿をバージョン管理しているけれど編集部には使ってもらえないとか、組版されるともうバージョン管理できないとか、そういう声です。

「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集のスタイルには、編集者や著者による濫用で、組版をお仕事にしている人たちが泣き寝入りすることになるという問題もあります。 これは組版業界では昔ながらの恨みつらみなので、SNSで顕在化されやすくなっただけではありますが、むしろ課題としては根深いやつだと言えます。

同じような恨みつらみは、著者や組版担当者だけでなく、編集者サイドの目線でももちろん存在しています。

  • 初校に対する著者の赤字を転記しそこねて、再校出しで平謝りすることになった
  • 組んだ状態で読んで文章構成から直したくなった著者が全面に赤を入れ、ほぼ組み直しになってしまった
  • 赤字が意図通りに反映されていなかったので、指示をやり直すことになった
  • 校了後にはじめて編集による修正に気づいた著者とトラブルになった
  • 全体に同じパターンの修正指示が必要だが、数百カ所すべてに赤書きするのも、その赤字引き合わせをするのもつらい…

従来、これらのありがちな事態を防ぐために取られてきたのは、「著者との円滑なコミュニケーション」や「組版担当者との責任境界の明確化」、あるいは「余裕をもった入稿スケジュール」といった「人間の心がけ」ベースでの対策でした。 紙への赤字をスキャンしてやり取りできるようになったり、PDFのコメント機能の導入でテキストのコピペができるようになったり、パソコンやDTPソフトの機能向上で作業が効率的になったり、そういう意味では「コンピューターを活用」することで緩和している面もありますが、問題そのものの氷解には程遠いのが現状です。

そこでテキスト原稿のバージョン管理

上記に挙げたような各種の問題を根本的に消滅させるには、「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集の進め方を捨てるのが手っ取り早そうです。 なので、ぼくは20年くらい前に「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集スタイルを本づくりから段階的に廃止しました。 その代わりとして採用したのが、「テキスト原稿のバージョン管理」という編集スタイルです*1。

テキスト原稿のバージョン管理による編集の最大の強みは、「一連の編集フローにおいて徹頭徹尾コンピューターを活用できること」です。 おかげで、上記のような辛い事態が原理的に起こりにくくなります。

ただし、編集スタイルが従来とはまったく違うので、書籍に携わるステークホルダー全員がその変化を抱擁する必要があります。 実際、自分もいきなり従来の編集スタイルからこの編集スタイルに切り替えたわけではなく、最初の数年間は自分が直接関与する部分だけで小さく始めました。 そこから徐々に「自分が直接関与する部分」を増やしていって、完全に切り替えできるまでにはおそらく数年かかっています。

具体的にどうすればいいのさ

こういう話をすると、往々にして、「そうはいってもGitのようなバージョン管理システムは本の編集には向かないのでは？」という方向に議論が進みがちです。 実際、「Gitでテキスト原稿を共有してみたけど、著者とのコラボレーションがうまくできてる気がしない。どうすれば…」と感じたことのある編集者は少なくない気がしています。 これまでの自分の経験でも、バージョン管理システムをそれまでの編集フローに導入しても、新たなフラストレーションを生むだけに終わることが多々あります。

しかしこれは「Gitのようなバージョン管理システムは本とかの編集には向かない」ことは意味していません。 あくまでも、「従来の編集フローをサポートしてくれるツールではない」というだけです。 というか、前節で触れたように、ぼくがテキスト原稿のバージョン管理を採用しているのは、もともと「誌面レイアウトしたPDFとか紙に赤字を入れる」という従来の編集のやり方を捨てるためです。 従来のやり方を捨てる勢いがなければ、テキスト原稿のバージョン管理も、そのためのツールであるGitのようなシステムも、本領を発揮できないというだけです。

従来のやり方を捨てるといっても、具体的にはどうすればいいんでしょうか？

ここで、編集という仕事がそもそも何をする仕事だったかに立ち返りましょう。

私見では、編集とは「原稿のありうべき形」をいろいろ検討し、そのなかで最適な姿を著者と選択していくという仕事です。 原稿→脱稿→初校→再校→…という進行をこなしていると、どうしても「原稿を段階的に改善していく」という発想になりがちですが、実際にそのフローの各段階でやっているのは、原稿を修正しうる無数の可能性を吟味し、それを赤字やコメントという形にして著者や組版担当者と共有しつつ適用する、という作業なはずです。

バージョン管理システムが有効なのは、この作業、つまり「原稿にありうる無数の可能性を追求する」という部分です。 無数の可能性は、Gitのようなバージョン管理システム上では「ファイル間の差分」という形をとります。 「原稿にありうる無数の可能性」を、コメントや赤字のようなコンピューターで管理しにくい形でなく、ファイル間の差分として見ることが、テキスト原稿のバージョン管理という編集スタイルの勘所です。 言ってみれば、「修正案を作りまくっても、Gitが勝手にうまいこと管理してくれてるんだから、なにも気にしなくていいぞ、ひゃっはー」という感覚です。

まとめます。

  • 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する
  • そのために、「原稿はコンピューターで差分を自動取得可能な状態でなければならない」という感覚に慣れる
  • それらの「差分」をうまいこと管理してくれるのがGitのようなバージョン管理システムだと理解する
  • 著者と編集者が互いにこの感覚を持てるようになれば、「テキスト原稿に対する書き換え案を出しまくる」ことで編集ができるようになる

最後に宣伝です。もし「自社で積極的にテキスト原稿のバージョン管理を検討したいから、このへんのノウハウを聞かせてほしい」という出版社がありましたら、info@lambdanote.com にぜひお声がけください。

*1:実際にはこれに加えて「自動組版」という技術も重要なんですが、今日はこの話はなし。

プログラミングにおける「納得」と『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のコミットベースで著者と進捗の話ができる分野の本でなかったら、きっと今以上に新刊のペースが落ちるでしょう。

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

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

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

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

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

追記

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

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

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

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

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