最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。

・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ（などの得意だったおたく分野）はつまらん」というのと同じ現象が自分に起きているだけな気がする。

キャリアの停滞

まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわちマンネリ化にがっかりしがち。マンネリ化を打破したいならキャリアを大きく舵切りする必要があるが、それは雇用と収入を危険に晒すので困る。

キャリアの方向転換をしなくても順当な出世路線を進んでいれば新しく学ぶことはありつづけるように見える。この話を書くにあたり InfoQ の Book Review セクションを見ていたらリーダーシップや経営の話の多いこと。こうした upper management への aspiration があれば世の中の（広義の）技術書で読み物に困ることは少なそう。いわゆる「ビジネス書」は技術書に限らず人気ジャンルである。自分もビジネス書は嫌いではないけれど、根本的には他人事なので純粋な技術書ほどの熱意はない。

コンテンツ消化のサボり

自分は 10 年前くらいに技術書は英語でしか読まないと決めてから大きく読書量が減った。外資系会社員になるにあたり立てた意識高い系の目標だったが、完全に裏目に出た。純粋に読速を落としただけでなく、その副作用で意欲が削がれてしまった。この問題は数年前からようやく解決しはじめたけれど、今度は子どもができて時間の絶対量が減ってしまった。

自分のコンテンツ消化不良には２つの症状がある。1 つめはコンテンツ選びの偏食化。プログラミングというものへの自分の意見の先鋭化もあり、意見の合わない主張の本は腹が立って読めなくなる。自分の意見は（すくなくとも自分にとっては）正しいと思っているので反りが合わないこと自体に問題は感じていないが、コンテンツ消費者としては反りの合わないものも幅広く摂取して視座を広く保つ方が良いのではないか。A grumpy old reader は望ましい姿ではない。時間のなさ自体、偏食に輪をかける。本を読まない理由をがんばって探すようになる。この態度も良い読者とはいえない。

もう一つの症状は新刊感度の低下。読むべき本を探すのに時間をかけなくなった。自分の行動範囲から書店が消えたせいもあって、向こうから面白い本がやってくることがなくなった。読む本を必要に応じて探すようになった。効率という点でこれは必ずしも悪いことではない。けれど無駄の生む serendipity がないと読書という行為全体の楽しさは薄れる。

要するに「本を探す、本を読む」という行為にかける時間の絶対量が減ってケチ臭くなった。その結果見返りが少なくなり、楽しみが削がれた。

ジャンルとメディアの変遷

「綺麗なコードを書くこと」が関心の中心にある時代があった・・・と思う。「オブジェクト指向」がホットな話題だった。アジャイルの一環である TDD もリファクタリングも DI も、広義ではコードの綺麗さすなわち変更に強く保守しやすいこと、をめぐる話題だ。今は、少なくとも昔ほど「コードの書き方」それ自体が注目を集めていない気がする。

自分はコードの綺麗さを長いこと追求していた。ある時期から行き過ぎを反省し意図的に気にするのをやめて、今は割とどうでもよくなった。一方で、「オブジェクト指向」（関数型でもいいよ）や「リファクタリング」のようなコードの書き方に関する大きなブレークスルーがやってくるんじゃないかと心のどこかではいつも期待していて、それはきっと書籍という形で届くという期待もあって、でもその期待は裏切られ続けているように感じていて、失望がある。

最近までそこそこ盛り上がっていたアジャイルの思想的後継に Microservices や Devops がある。これらの話題は広く語られ、本も割と売れているようだ。けれど Microservices にしろ Devops にしろ「オブジェクト指向/関数型」のような狭義の「コードの書き方」つまりソースコードの textual representation に関する話題ではない。ソフトウェアのフレームワークやアーキテクチャやリリースプロセスの側に重点がある。

コードの世界のイノベーションは、ふつうに続いている。わかりやすいところだと Flux とかは DI に匹敵するインパクトがあると思うし、Event Sourcing や Service Mesh みたいのもデザインパターンの後継と言える。Rx から async/await の流れを数えてもいい。メインストリーム言語も格好良いのがふえた。ただこいつらは本ではなく (Redux, Kafka/Samza, Istio, Rx, Kotlin のような) 実装として世に登場している。書籍は二次情報にすぎない。そして書籍に存在感のある Microservices にしたって主要な情報源はオンラインにある。

そしてどのみちサーバサイドをやってない自分にこれらの大半は縁遠く感じる。モバイルもホットな話題は年一回の開発者会議なりオープンソースプロジェクトなりが中心で、書籍はおいてきぼり。ついでに「コードの綺麗さ」においてモバイルは出遅れがちである。（反論はご自由に。）

結果として、自分が身近に感じられるソフトウェア開発の新しくてかっこいい話題を学ぶ感動や興奮は書籍から得るのが難しくなったように感じる。

いちおう確認しておくとこれは完全に言いがかりであって出版社や著者を責めていない。ただ昔の体験が自分の期待値を決めているので勝手に失望してしまう。

キャリアの停滞も時間のなさも時代性からの乖離も自覚していたが、それが技術書体験の不満に繋がっているとは気づいていなかった。考えてみてよかった。

そこまで技術書にこだわらなくてもいいのではと思うかもしれない。でも自分はもともと本を読むのが好きで、技術書は活字というホビーとソフトウェア開発というキャリアの両方まとめて面倒をみてくれる人生のキラーコンテンツだったので、それを楽しめない失望は大きいのだよ。

自分は技術書とどう向かい合うべきなのだろうか。もっというと、キャリアが停滞し時間もなく時代遅れの自分はどうやって様々なプログラマ向けコンテンツと向かい合うべきなのか・・・は、稿をわけて考えたい。