日本の（技術書の）ジレンマ
技術書というのが 「ソフトウェア/インフラエンジニアが読むフレームワークや言語についての本」 だと仮定すると、
高度な内容になればなるほど、読者とニーズが減るので、入門者向けの内容になりがち
入門者向けの内容であれば、フレームワークや言語の公式サイトにあるGetting Startedのドキュメント（英語）で必要十分
その内容は、トップレベルのエンジニア集団が自分たちの技術の普及を賭けて練り上げたもの（のはず）なので、クオリティはだいたい高い
逆に言うと、それが貧弱だったりわかりにくかったりする技術は信頼性に欠くので、あまり学ばないほうが良さそう、本気度からくる将来性が低そう
英語ドキュメントに抵抗が少ないエンジニアは最初から公式サイトの1次情報を見て学習し、足りない情報は英語のブログや動画から勝手に補完していく
1~3から、英語が苦手なエンジニアが入門時に読む感じの本が多く出版される。
日本はマーケットが大きくて本から簡単に情報が仕入れられるので、 入門者が日本語の情報に依存し、日本語の2次情報や3次情報を中心にした情報交換サイクルが生まれる。 結果、英語圏のコミュニティとの間でズレがどんどん拡がり、ガラパゴス化が発生。
また、
- 日本発の技術がスタンダードになっている例は少ない
- オープンソースプロジェクトのメインのcontributerだったり英語で議論に参加していたりするケースは少ない
という点から、「著者がそのフレームワークや言語を開発する側ではない」という仮定を置くと、本の内容は、
- 元々英語で書かれている公式ドキュメントの翻訳
- 自身が開発経験から学んだノウハウ
- お手製サンプルコード
などになりがち。
そうすると、
- 英語から日本語へ変換する労力と時間
- 誤訳リスク
- （レビューがあるとしても）入門的な内容なのに開発元から遠い人物の主観が混ざる
っていう副産物が生まれ、ここに、本というフォーマットそのものが持つ
- バージョンアップや業界の変化に追従できずにすぐ内容が古くなる
- 間違いがあったときに迅速な修正が難しい
- 手に入れるのに金がかかる
- それに関して質問したり意見を書いたり引用したりがWebに比べて難しい
などの欠点も倍率ドン。
なので、業界の技術レベルの底上げに貢献するための技術書なのに、 ニーズを勘案して内容を決めていくと、 長期的に見て全体があまり良い感じにならない、 というのがジレンマかなと思います。
名著はたくさんあるのでもちろん例外はあると思うけど、この図式に当てはまらなさそうなのは、
- コンピュータサイエンスやアルゴリズムなどの普遍的な内容を扱った本
- C言語などの枯れまくった技術についての本
- 複数の技術やアイデアを組み合わせた事案について考察している本
などですかね。
入門ドキュメントぐらい気合で読む覚悟と根性が無いと日本の開発者に明るい未来はないと思うので、 正直しんどいけどみんなでがんばっていこうねって思います。
