1. kkeethのエンジニア雑談チャンネル
  2. No.374 「技術書執筆の裏側的..
2024-02-17 15:34

No.374 「技術書執筆の裏側的な話」

はい!第374回は,以前も一度配信したかもしれませんが,技術書(商業誌)執筆の裏側のお話を改めてしてみました💁


もし機会がある方は是非チャレンジしてみてください!


ではでは(=゚ω゚)ノ


ーーーーー

🔗 LINKS

技術書典

https://techbookfest.org/

技術書同人誌博覧会

https://gishohaku.dev/


♫ BGM

騒音のない世界「ブルースター」

https://soundcloud.com/baron1_3/bluestar

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:10
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
今日は、技術書出版の、出版といっても、同人誌とか、技術書店とか、技術書博覧会ではなく、
本当に商業史としての出版の大変さと、まあ面白さみたいなところを喋っていけたらなと思ってます。
僕は、しかも短著で書籍を書かせていただいたので、かなり大変だったのではあるんですけど。
でも、最も大変だったのは何かっていうと、ライブラリーの書籍を僕は出させていただいたので、
ソースコードもたくさん出てきますし、デモアプリも作りましたと。
まあ、デモアプリどういうアプリしようかっていうのは、本書きながら実は作ってて、これは失敗しないと思ってます。
先にアプリ作りきった方が良かったなって、僕は反省してますね。
で、なぜかというと、書きながらアプリ作って、で、どうたらこうたらをやって、また文言修正してとか、
アプリを修正して、デバッグしてとか、直してとかをやっていくと、
だいたい語字脱字とか、書籍に書いたコード自体がミスってることがあるんですよね。
僕の書籍も、そういう語字脱字とか、ソースコードの誤植のページを別途用意したんですけど、
結構な量になってしまいまして、本当に先に全部ちゃんと作って動くところまで見てから、
そのソースコードを書籍に書き落とすっていう方が絶対良いなと思いました。
走りながら書き落とすのは、本当僕は大失敗しましたし、だいぶバグと誤植を埋め込んでしまった書籍になってしまって、
本当大反省ですね。
もともと今回のネタがRiot.jsなので、そもそもそんなにユーザーのニーズが多くなかったっていうのもあるかもしれないですけど、
びっくりするぐらい反響はなかったっていうのは正直、その辺の誤植とかだったり、
レビュー少ないのも本のクオリティ自体が高くなかったんだろうなっていう反省は正直あります。
ちゃんとデモアプリを作ったり、サンプルコードを載せるんであれば、
その辺は作るものがあるなら作りきってから書籍に落とすっていうのが僕の一つの反省点です。
2つ目は、書籍って出るまで結構時間がかかるんですよ。
ライブラリーとかを対象にした書籍だと、ライブラリーのアップデートが下手したら走るじゃないですか。
それがメジャーバージョンアップとかになった日にはもう書いた書籍が実は出る頃にはもう古くなっている。
そもそもニーズがなくなり始めている書籍を出すみたいなことになりかねないので、
何の技術に関する書籍を出すかっていうのは、結構タイミングがすごく難しいんですよね。
僕の書籍も企画書を出版社に出して、契約書を巻いて、いざ執筆スタートしたんですけど、
03:03
ライオット・ジェスという書籍を出したんですけど、メジャーバージョンの4が当時出るか出ないかギリギリのタイミングで、
そこはかなり編集者とか担当の方と、いつ出すかっていうのは割と協議してました。
とはいえ内容自体は大筋変えることはなかったので、
執筆自体は進めておきながら、メジャーバージョンがちゃんと出たタイミングで出すっていうところを加味しながら、
いつ脱稿で、いつ印刷に回すかみたいなところは割と議論をしてましたね。
メジャーバージョンが出たらそのタイミングで出せばいいっていうと単純な話ではなくて、
出たばっかりだと大体何かバグったり落とし穴があったり、
バージョンアップに応じた破壊的変更を巻き取って書籍に落とし込まなきゃいけないので、
これがまた結構大変だったんですよね。
特にRiotっていうライブラリーはJavaScriptのライブラリーで、
JavaScript系のライブラリーで大体出た瞬間落とし穴って結構あるんですよね。
それも加味して書かなきゃいけないので、
真っ先に自分が地雷を踏み倒しにいかなきゃいけないっていう苦しさはありましたね。
よりプレゼンテーショナルなところの領域の技術に関して触ると、
そういう落とし穴にはまらなきゃいけないっていう苦しみがあったので、
ここは自分で選んだので仕方ないんですけど、その大変さも確かにあったなって感じです。
それも確かに誤植とか誤字脱字ページにも載せましたね。
バージョンアップに応じてここは使えませんよとか、
逆にここはこういう内容になりましたっていうのは、
定期的に更新実は未だに書き続けてます。
というか、未だにですね、
僕の印税の入るタイミングって半年間に1回出版社から
数値だったり、何冊売れました?って数値くるんですけど、
ちょこちょこで未だに買っていただいてるんですよね。
ライオットジェニスのバージョン4なんて使ってる人誰もおらんやろって思いながら、
今メジャーバージョン9ですからね。
それでも買っていただいてるのはありがたいので、
そういう人がいればさすがにメンテナンスページは更新し続けなきゃいけないので、
未だに更新はしてるんですけど、
とにかくバージョンですね。
ライブラリとか対象の技術のバージョンアップっていうのがすごく大変で、
書籍っていうのはラグがあるのでそこの加味しなきゃいけない内容っていう、
すごく単純ではないなっていうのがあって、
ここが難しかったので2つ目のポイントですね。
で、3つ目大変だったのは、
皆さんご多分に漏れず、ちゃんと納期に間に合わせて計画的に書き続けるってとこですね。
いやこれは本当僕もあれですけど、
締め切り駆動の書き方をするあのバカ野郎だったので、
後半の4ヶ月はもうほぼほぼ睡眠時間を削りながらバリバリ書いてました。
そういう書き方をすると基本的にはもう五字脱字のオンパレードなので、
後から死ぬほど読み直しましたね。
何人かレビュアーの人とも何度も何度も読み直したんですけど、
読み直しても読み直してもやっぱ自分では書いた身ですし、
何度も読み返すとやっぱり脳にキャッシュ的なものが残っちゃうので、
やっぱ読み飛ばしてしまったりとか、
06:00
この辺は知ってる内容だからって読んでるように見えて脳は実は勝利しなかったりする時があって、
まあそれも含めて五字がかなりあったなっていうのはすごくあります。
なので五字脱字チェックは1日寝て次の日に読み直すのが絶対いいなと思いましたね。
その日中にやるとか疲れた日にやるのは絶対よろしくなって、
何回もやることが本当はいいかもしれないですけど、
僕はそれ逆だなと思って、
今日は絶対にレビューというか五字脱字チェックしかしない日を作って、
それ日まではもう書き続けるだけの方が、
結果的には五字脱字の見つけ方はもっとクオリティ高く見つけられたんじゃないかなって気はしてます。
まあこれは人により出るですね。
あとレビューの数がかなり多かったりとか、
テクニカルレビューとちゃんと構成的なレビューできる人がいるんだったら、
もうその人にお任せをしてっていう分担ができたかもしれないですけど。
そういう意味でいくとレビューをちゃんと揃えきれなかったっていうのが大変でしたね。
僕の場合結局3,4人でレビューして、
僕も含めて3,4人でやってたんですよね。
いやこれがね、もっと数いたら本当は助かったし、
ありがたかったなと思います。
でも基本的には無償でやるし、
技術書ってそんなにペイしないんですよね。
少なくとも儲けられるものではないので、
ほぼほぼもう事前活動に近い、
一回なんか手伝ってくださいと頭を下げて、
お願いしてレビューしていただいたって感じにはなるので。
どうやってインセンティブというか、
お返しをするかっていうのもすごく内容は考えましたけど、
心よく受け入れていただいた方が何名かいらっしゃって、
一緒にやったんですけど、
それでもあれだけの後者たちがやっぱり出るので、
レビューってすげえ大変というか、
構成役の人がちゃんと揃えるっていう、
この交渉力の方がむしろ大事だったなっていうのは、
振り返って思ったりはしますね。
同心誌であれば別に全然良いし、
ネットに公開する?
例えば禅のブックスとかもあったりするので、
ああいうものに関しては一瞬で直せるんでいいんですけど、
書籍って紙媒体とか、
Kindleもそうですけど、
一度出てしまうと直せないものではあるので、
死ぬほどやった方がいいように見えますけど、
やるタイミングはちゃんと区切った方が良い、
っていうか頭をクリアにしてやった方がいいなっていうのは、
もう本当に大反省でしたね。
はい。
技術がわかる人で、
全然やったことがない人とかをレビューアリに含めると、
よりクオリティが高くなったのかなって気がします。
JavaScriptのライブラリーの書籍を書いたけど、
例えばライオンと本当に触ったことがない、
リアクトとかViewが触ったことあるよみたいな人がいたら、
本当は良かったのかもしれないですね。
はい。っていうのが大変さ、3つ目と4つ目ですね。
ただでも面白さで言うと、
そのライブラリーに関して少なくとも深みが出たのがすごくありがたいなと。
自分の知見の中で、
持っているもの持っていないものの頼もろしが一斉にできたっていうのがすごくありがたくて、
これが大きかったかなと思います。
意外と知っているものがたくさんあったなっていうのとか、
逆に自分がこの辺すごく曖昧にしてたり、
雑に理解してたなってことを、
でも書籍書く時にはこれやっぱり理解しなきゃいけないし、
裏取らなきゃいけないなというので、
割と調べながら書いたりしてたので、
今まで思い越し上げなかったものが全部上がったっていうのは
09:02
すごく助かったとは思いますし、
自分でもチャレンジした効果は良かったなと思いますね。
裏取ってる時間も本当は書きたいんですよね。
本当に締め切りがやばいというので。
だいたい書籍って薄っぺらすぎると出版社としてはやっぱり
体裁が悪いので、
なるべくは書いてほしいので、
何万文字でしたっけ?
10万か20万か?
何万文字かの基準が一応出版社の中にあって、
そこまでは書いてくださいというのがあって、
僕みたいなライオット・ジェイスより軽いライブラリー、
ライトなライブラリーの書籍を書こうとすると、
ぶっちゃけると公式サイト見て、
手を動かせば書けるはずなんで、
どういう内容を書き込むかっていうのがめちゃくちゃ悩みましたね。
効果不効果、ライオット・ジェイスの公式サイトは
説明がそんなに強くないのと、
ほぼリファレンス的な公式サイトにしかなってないので、
チュートリアルページないんですよね。
っていうのもあったので、
じゃあそのステップバイステップの書き方にしていこうっていう風な
コンセプトはできたんですけど、
それでも内容が薄くなりかねないなっていうので、
すげー悩みましたね。
1章か2章は全くライオットと関係ない話とかしてました。
周辺ライブラリーとかエコシステムの話だったり、
CSSのフレームワーク周りの話をバーッと積み込みまくった感じがしますね。
こんなことをしないといけないのかっていう大変さはありますけど。
まあでもその辺も含めて、
改めて自分でフロントエンド界隈のライブラリーもそうですし、
エコシステムとかどうやって皆さん開発環境揃えてるのかみたいな
調査をするタイミングにもなったので、
どっちにしろ良かったなって思いますね。
あと面白さというよりもやはりメリットとしては、
セルフブランディングになるかというと
めちゃくちゃなるなっていうのをつくづく感じましたね。
ギルシー賞1本出しただけだっていう、
それだけでも他者評価っていうのがガラッと変わったなっていうのは正直にあります。
採用とかの文脈でもやっぱ武器になるなって思ったので、
大変ではありますけど自分の武器を作るって意味でギルシー賞の出版っていうのは、
今後の製造戦略的に一つ、
やれるんだったらやってみていただいた方がいいかなっていう気はしますね。
ただ短著より強著の方が、
負荷分散はできて良いと思いますが、
リスクは上がるので、
そこはどうしようというのと、
あと書き方というか、
言葉深いもそうですけどそこを揃えるのが大変そうだなっていう気はしますね。
強著の場合は。
最初からこの章はこの人、この章はこの人で、
書き方の口ぶりが変わりますよみたいなのが書いてあるんだったら別に、
それはそれでいいかもしれないですけど、
書籍を読む側としてはできれば揃えていただいた方がいいなって思ったりしますのでね。
執筆者が増えれば増えるほどそのリスクは上がるので、
そこのバランス取り方は難しそうだなって感触がありました。
その意味で頑張れるんだったら短著で書くのが良いのかなっていうところですね。
あとですね、面白さというか、
まあ書かないと絶対使わないだろうなみたいなものとして、
何のツールで書籍を書くかっていうのが一つ面白かったですね。
で、私はですね、GitBookを使ってました。
今はGitBookってSaaS的なオンラインサービスになってしまって、
12:02
昔はそのNPMで公開されてたんですけど、それがなくなったんです。
で、それをフォークして新しく作ったAZさんって方が
HonKitっていうライブラリーで作り直していただいたんですね。
今もなんかドキュメント書くときはたまに僕はHonKit使って書いたりします。
いわゆるマークダウンですね。
で、書いてそれを簡単なウェブページに自動的に起こしてくれるようなやつですね。
いろんなライブラリーの公式サイトで使われているような提材に自動でやってくれるんで、
その辺がありがたかったなって思います。今も使ってます。
めちゃくちゃ便利なのでオススメですね。
PDFで出力もしてくれたりしますし、
結局はウェブで出力されるんで多少のCSSのスタイリングもできますし、
プラグインもたくさんあったりするので、
割とやりたいことは結構できるなっていうので、
一からどうやって何かツール使ってやろうかとか、
環境揃えるの大変だなっていう方はHonKitを選択肢に入れていただいてもよいかなって気はします。
はい。
面白さで言うと結局は自分が初めて書籍を出すっていうこと、
ワクワクはたまらんですよね。
出した後もでもすごく楽しいですね。
出して実際にこの日から書店に並びますっていう日は僕もやっぱり有給取って、
都内の何店舗か書店やっぱ回っちゃいましたもんね。
手に取ってくれてるシーンは見れなかったけど、
それでも並んでるっていうのを自分で目の当たりにするのはすごく楽しいなっていうのはありましたね。
ワクワクするし、
次の日とかある程度日付が経ってから行くとやっぱり多少は本が減ってくれているので、
ああいうのを見るって自分でやるっていう感触は初めてだったので、
そのワクワクはこれ絶対やらないと味わえないなっていうところで、
同人誌ではまた違う味わい方だと思いますのでね。
はい。
あと、もし出版して書店に並ぶんであれば、
書く書店に自分で手書きで書いたポップを置かせてもらうっていうのがまた一つ面白いですね。
僕も今回やりましたけど、やっぱりポップってプロが書くとすごい上手いなって改めて実感しました。
特にビレージバンガードとか、お店行ったら当たり前に並んでますけど、
ああいうのをちゃんと見てみると、
ここってこういう書き方したりとか、フォントを選んだりとか、
こういう強調の仕方があるんだとかですね、めちゃくちゃ学びになるんですよね。
普段何も気にしてなかったんですけど、自分でいざ書こうとなると、
全然ポップ書けないし下手くそだなーってすごく感じましたね。
という意味もあって。
いや大変なんですけど、でもその下手くそさで書店に並ばして、
でもそれを見てもらうっていうドキドキと緊張もありますし、
ちょっと恥ずかしい面もあるっちゃあるんですけど、
でも一生これやれないでしょう。
このタイミングしかないでしょうっていうのはあるので、
もし皆さんが書籍を書くんだったら、
ポップも書いて書店に置かせてくださいとお願いして、
回るのは一ついいと思います。
全然心よく受け入れてくれますよ。
お話聞いてみたら、いろんな出版社さん割とやられてるらしいですよね。
そういうお願いはちょいちょいきますよっていうのがあるので、
執筆者の方がポップを書いて持ってきてくださるのはすごくありがたいみたいな話も聞いたりしたのでね。
この辺の楽しさっていうのはすごくありました。
とにかく大変ではあることに間違いないし、
お金になるわけでは全然ないですね。
その即物的な意味でお金にはならないですけど、
15:02
将来的に自分のブランディングから自分の価値を上げて、
お仕事する時の単価を上げたりとかに使えたりするので、
いろんな意味のメリットはあるのでお勧めはしてみますが、
大変さと生活、私生活のポールバランスを取りながら書いていただければと思います。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
15:34

コメント

スクロール