golden-luckyの日記

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

本の原稿のバージョン管理を始めて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のコミットベースで著者と進捗の話ができる分野の本でなかったら、きっと今以上に新刊のペースが落ちるでしょう。

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

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

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

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

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

追記

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

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

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

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

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

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

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