最近本を出版しました。「Webアプリ開発で学ぶ Rust言語入門」という本です。

タイトルの通り、Webアプリ開発を通じてRustを学ぼうという本です。筆者はRust界隈で名が通ってるわけでも、過去に執筆系経験があるわけでもありません。そんな筆者がこの本を書くことになったのは、Zennの記事がきっかけでした。

本稿は本を書くきっかけをくれたZennへの感謝を込めて、執筆体験について紹介する記事です。

書くことになった背景

「Typescriptの次はRustかもしれない」

2年ほど前、こんな記事を書きました。

普段はTypescriptばかり書いてた筆者が、Rustを学ぶのが楽しくて書いた記事でした。正直、RustがTypescriptを置き換えるとは当時も今もあまり思ってないですが、一方で、Typescriptユーザーの第二言語としては面白いのではないかとも感じてたし、wasmなどで部分的に置き換えていく可能性は感じていました。そんな妄想をしながら書いた記事だったし、初めてZennで書いた記事だったのですが想像以上に反響がありました。否定的な意見もいただいたし、一方で「面白かった」「Rust学んでみたくなった」「Rust面白そう」などの声もありRust楽しいって気持ちが伝わったならよかったなと思い、その後もZennで記事を書くモチベーションになりました。

出版社からの連絡

上記の記事を書いてから1年ほど経った頃、筆者の元へ出版社の編集者の方(後の担当編集)から相談のメールが来ました。相談内容としては以下のようなものでした。

Rustの注目度が上がってるように思える
入門書はいくつか存在するが、よりライトに読める超入門書を考えてる
果たして需要はあるのだろうか
この企画を営業や経営陣にどう説明するか

筆者の周りでも「Rust難しそう」という声は何度か聞いたこともあったし、Rustについての話題は時折出るけど実際に学んでいる人はまだまだ少ないという印象でした。一方で、JS界隈ではDenoやRome、会社だとGoogle,Amazon,MicrosoftのRust採用など方々でのRust採用が引き続き目立っており、Rustの注目度がより高まっているのは感じていました。RustのWeb開発の方面でも、Rustの非同期ランタイムであるtokio開発チームが作ったWebフレームワークaxumの登場やSQLライブラリsqlxの台頭など、どんどん新しいものも出てきて徐々に盛り上がりつつある印象もありました。

そういった筆者の私見をもとに何度か担当編集とやりとりするうちに、本の企画を手伝うことになりました。

企画

当時の筆者の仮説は以下です。

Rustに興味はあるがまだ学んでいない層はそれなりにいる
- これらの潜在層にはWeb開発者も多く含まれている
- Web開発者にとって、現存する入門書はシステムプログラミングよりなものやリッチなものが多く、ハードルが高い
- Web開発者がRustを学ぶなら、Web開発を通じて入門するのは普段の業務に近くより学びやすいのではないか

これらの仮説をもとに、Web開発を通じて学ぶRust入門書はどうかと担当編集に提案しました。

ここで混在させてはいけない重要なテーマとして、「RustはWeb開発に向いてる」と主張したい本というわけではなく、「Web開発者がRustを学ぶならWeb開発でやるのがいいじゃないか」という本だということです。筆者としてはもちろん、RustでやるWeb開発(というかAPI開発)は楽しいし、もっと盛り上がって欲しいなと思っています。一方で、Rustが一定の難しさを持ってることも事実だし、その難しさがWeb開発者に受け入れられていくのかもまだまだ不明な現時点で、「RustはWeb開発に向いてる」と断言するのは難しいとも思っています。なので、テーマが誤解されないように本の構成を検討する必要がありました。

これを担当編集、さらにはその先の出版社の営業担当の方々や経営陣に理解してもらうのは結構大変でした。当然担当編集の方含め出版社の方々はある程度技術的知識を持っていてもエンジニアではないので、「RustはWeb開発に向いてる」という主張をしたいものだと誤解を生んでしまいました。

ともあれ粘り強く付き合ってくれた担当編集のおかげで企画が形を成してきて、その流れで執筆も自分が担当させていただくことになりました。あとは無事企画が通るのを待つのみ...ではなく、「どういったマーケットで」「どういったターゲットで」「これまでの入門書との違いは何で」「書店様にはどう説明すべきか」など、企画が通るまでに必要だった説明資料の作成など、タスクは多岐に渡り、これらのタスクや課題を1つづつクリアしてなんとか企画が無事通りました。

出産・育児

ここで急にプライベートな話に飛びますが、企画が通った頃ちょうど第一子の出産時期が近い頃でした。そもそも執筆の依頼がきた時に、チャンスだと思った一方で第一子の出産時期を考えるとどう考えても被るので受けるかどうかかなり悩みました。

妻は同じくシステム開発業界にいるのでかなり理解がある方でしたが、やはり不安だったと思います。ですが相談したところ、後押ししてくれました。この時難色を示されてたら受けれなかったと思います。妻には本当に感謝です。

それでも執筆開始時期が完全に出産予定期に被ったのは流石に無理だと思い、担当編集に相談して開始は出産から3ヶ月ほど経った頃から開始とさせていただきました。実際、書き始めた頃は子育て・仕事・執筆で毎日全く余裕のない日々でした。ともかく子育てが大変で、仕事以外の時間で子育てと合間を見つけては本を書き、こんなんで間に合うだろうかというプレッシャーもあって本当に大変でした。

余談ですが、執筆中本当に大変だったけど子供は本当かわいいです。Rustより好きです。

実装・執筆

閑話休題、ここで執筆全体の流れを見てみます。

開始時期	終了時期	内容
2021/09	-	相談を受ける
2021/10	2021/12	企画(1)
2022/12	2022/03	出産・子育て初期
2022/03	2022/03	企画(2)
2022/04	2022/07頭	執筆
2022/07末	2022/09頭	校正・校閲
2022/09末	-	発売

脱稿(執筆の完了・提出)は当初6末予定だったのですが、書いてるうちにどうしても間に合わず2週間ほど予定をずらさせていただきました。実は企画が通る前から少し書いてたのですが、それでもどうしても子育て・仕事・執筆の3つを成り立たせ続けるのは至難の業で、結果遅れてしまいました。

企画後、実際の執筆の流れもみてみましょう。

1. 調査・構成の検討

企画時点である程度方針や構成概要は検討済みでしたが、一番はWebアプリ開発を通じてRustを学ぶ本なので「何をどこまでどうやって作るか」を検討しました。

Rustの文法についてはどこまで解説するのか、マルチスレッドやメモリ周りに触れすぎると読者は離れてしまわないか
RustのWebフレームワークはいくつもあり、どれを使うのか
SQL周りのライブラリは何を使うのか
フロントエンドはどうするのか。Rustのフレームワークではテンプレートエンジンを使うパターンもあるが、昨今のフロントエンドからするとAPI開発に終始した方がいいのではないか
その場合、ReactとVueどちらにするか、フロントのフレームワークやライブラリは何をどこまで使うのか

これらを自分に問い、一つづつ自分なりの仮説と解を持って構成の検討を進めました。上記の問いに対する自分の答えは、書籍でぜひ読んで確認してみてください(本当は宣伝したいというより、細々書くのが面倒なだけです...)。

2. 執筆環境の構築

構成がある程度固まったら早速執筆...ではなく、まずは執筆環境の構築を行いました。当初はvivliostyleを利用していましたが、途中からシンプルにマークダウンの表示だけ見たくなってmdbookを利用しました。mdbookは早いし使い勝手も良くて、何よりRust製なので(？)とてもよかったです。

あとは各ページ・各章・全章の文字数を算出して記録するコミットフック環境を作成しました。これらはsimple-git-hooksと普通にNode.jsで文字数カウントをcount.logに出力するよう実装しました。

count.log

all string length: 237498
chapter_1 9802
chapter_2 45950
chapter_3 53506
chapter_4 33529
chapter_5 34159
chapter_6 60552
manuscripts/chapter_1/1.md 2993
manuscripts/chapter_1/2.md 6715
manuscripts/chapter_1/index.md 94
manuscripts/chapter_2/1.md 6017
manuscripts/chapter_2/2.md 8125
manuscripts/chapter_2/3.md 3548
manuscripts/chapter_2/4.md 8470
manuscripts/chapter_2/5.md 9507
manuscripts/chapter_2/6.md 1856
manuscripts/chapter_2/7.md 2125
manuscripts/chapter_2/8.md 2915
manuscripts/chapter_2/9.md 3288
manuscripts/chapter_2/index.md 99
manuscripts/chapter_3/1.md 1564
manuscripts/chapter_3/2.md 8615
manuscripts/chapter_3/3.md 7239
manuscripts/chapter_3/4.md 18338
manuscripts/chapter_3/5.md 10089
manuscripts/chapter_3/6.md 7400
manuscripts/chapter_3/index.md 261
manuscripts/chapter_4/1.md 5515
manuscripts/chapter_4/2.md 3970
manuscripts/chapter_4/3.md 11775
manuscripts/chapter_4/4.md 7807
manuscripts/chapter_4/5.md 4178
manuscripts/chapter_4/index.md 284
manuscripts/chapter_5/1.md 2017
manuscripts/chapter_5/2.md 5903
manuscripts/chapter_5/3.md 10943
manuscripts/chapter_5/4.md 6020
manuscripts/chapter_5/5.md 9081
manuscripts/chapter_5/index.md 195
manuscripts/chapter_6/1.md 13942
manuscripts/chapter_6/2.md 26148
manuscripts/chapter_6/3.md 20061
manuscripts/chapter_6/4.md 225
manuscripts/chapter_6/index.md 176

企画段階でおおよそのページ数は決まっているものの、実際のページ数は脱稿後にしかわからなりません。そのため目標は文字数でページ数から逆算して25万字前後と設定し、進捗把握は出力された文字数をもとに判断していました。これは本当に作っといてよかったです。

3. 調査・実装・執筆のループ

本の構成と環境が整ったので、あとは実際に調査・実装・執筆のループの繰り返しです。途中で何度も構成を見直したり変更したりもしましたが、基本はただひたすらに調査と実装と執筆です。

ここで特に大変だったのは、基礎文法とフロントエンド周りです。

基礎文法

基礎文法は言語の根幹をなすところのため、誤った情報を書くわけにはいきません。時には歴史的背景や意味論に言及することもあるので解説難易度は高かったです。

わかりやすいところで言うと、Rustでは;がつくことで式を文にすることができるのですが、どこで調べても公式に近いところでこれについて言及してる記事がなかなかなく、最終的にこれを確かめるためにAST Explorerで確認しました。たった一文ですが、一度出版するとZennのように修正というわけにはいかないので、「AST Explorerで見ればいいんだ」とひらめくまでひたすら調べてしまい時間がかかりました。

こう言った、確信やエビデンスを得るまで1行が書けないということが多々あったのが基礎文法のところでした。

フロントエンド周り

Rustの本ではありますが、Web開発を通じて学ぶRustなのでフロントエンドも出てきます。Rustのテンプレートエンジンを採用し、ReactやVueは採用しないという手もありましたが、昨今のフロントエンドにおいてこれらの採用はデファクトです。今回はフロントエンドにReactを採用し、APIをRustで開発するという選択をしました。

しかしながら読者がフロントエンド経験者とは限らないので、ライブラリを多用しないこと(筆者が普段使っているNext.js/Recoil/react-hook-formなどは全て封印)・深いところまで言及しすぎないこと・UIライブラリに乗っかってCSSを極力書かないようにするなど工夫が必要でした。それでいて初心者でも理解しやすいようにシンプルな仕様と設計を心がける必要があり、フロントエンド周りの解説も大変でした。

余談

ちなみに、実は当初書こうと思ってた内容から実際の執筆途中で何度か大幅な軌道修正をしました。途中までは比較的学習コストが低いとよく主張されるVueで書いてましたが、Rust学んでると方向性が近いのはReactだと思い直して全てReactで書き直しました。APIも簡易ログインの実装を削除するなど、大幅な軌道変更をしています。元々のコンセプトの1つである、「超入門書」を目指す上でページ数は企画段階で提示されたものを大幅に超えてはならず、実際に書いてみたら100ページ以上超えそうだったので断腸の思いで諦めました。一度頑張って書いたものを捨てなきゃならないのも、Zennとの大きな違いでした。

4. 見直し・提出

実装と執筆を繰り返して一通り書き終えてから、全体の見直しを3周ほどしました。書いてる途中気になりすぎるとなかなか進まない部分もあり、「まずは書き上げよう」という精神でがんばったので、1週目の見直しでかなり修正を要する結果となりました。2週目では誤字や1週目の適用による影響考慮漏れの対応が中心でした。3週目になるとほとんど誤字修正のみでした。

自分で見直しが完了したら、担当編集に提出して実際の本の形にレイアウトする初稿の作成に当たってもらいました。

校正・校閲

初稿が完成したら校正・校閲が始まります。校閲には第三者目線の技術校閲が必要だったので、Rustにとても詳しく企画段階でも何度か相談に乗っていただいた会社の先輩にご協力いただきました。

初稿

初稿では、担当編集によってニュアンスや構成が変更されます。この変更によって意味が変わってしまった部分などないかなど、多くの観点でのチェックが必要になります。また、この時点でページ数が想定より多くなってしまったことが判明し、内容を一部削減するなどの調整も発生しました。一度書いた内容を成り立たせたまま削るのもなかなか大変で、当時はいっそページ数が足りないところから付け足す方が簡単だったかもなぁ...とも思いましたが、後の祭りでした。

2校

初稿でも2週読み直したので、2校の時点で既に読み直しは5週目です。2校でも2週したので、終了時点では6週読みました。誤字・ニュアンス・間違い修正が主なので作業自体は軽くなりましたが、忙しい日々とプレッシャーで今更「こんな本需要あるんだろうか」「自分なんかが書いていいんだろうか」という病み期に突入します。

毎日5回くらい、妻に上記内容を相談しては励まされていました。

3校(最終稿)

最終稿では最後の誤字脱字チェックです。こんだけ読んだんだしほぼ完璧、という気持ちで終わることができました。

(が、出版から数日時点で既に誤植・誤表記が数ヶ所ほど報告されてしまいました。悔やまれます。。。)

出版

最終稿も終わったらあとは表紙のチェックやECに載せる説明文の検討などをしていました。これらが完了して、最終稿からおよそ3週間後に無事出版されました。

感想

具体的な数字はまだ知らないのですが、無事本は順調に買っていただけているようです。知人・会社の同僚や先輩方など多くの方が宣伝してくれた効果が大きいと感じています。今時点でポジティブな意見も結構あって、ひとまずは書いてよかったなという気持ちです。

また、実際に書店に自分で書いた本が並んでいるのを見るのは感慨深いものがありました。

store

お金をいただいて読んでもらうもの、誤りを後から訂正できないというプレッシャーの元で技術的な文章を書くのは、自分の解説に疑いをもたらし、「この解説は本当にあってるんだっけ？」「これエビデンスあったっけ？」という気持ちが普段以上に強くなり、普段以上に念入りな調査と理解を要しましたし、本当にいい経験ができたと思います。

Zennで記事を書く意味は人によって様々だと思います。筆者の場合、自分が興味あるものを何かしらアウトプットとして残すとより記憶に残るというのが最初は強かったのですが、最近だと自分自身や仕事のチームメンバーへの共有・備忘録をかねてる部分も大きいです。また、反響や反応をもらえることで次の記事を書くモチベーションにもなります。そういった自分の狙いとは別の思いがけない方向で今回は本の執筆というチャンスに繋がったので、やはりアウトプットは大事なんだなと思うばかりです。今回のチャンスをもらえるきっかけになったZennには今後も自分なりに投稿頑張っていこうと思います。

Discussion