TSKaigi 2026 に技術書を出した話 ── 編集長として見た、Wantedly の書く文化

2026 年、TSKaigi に合わせてチームで技術書（Techbook）を出しました。

参加報告はこちら👇

私はこの本で、章を書く「執筆者」ではなく、本全体を組み立てる 編集長 として制作に関わりました。

この記事では、本の「作り方（How）」を細かく解説するのではなく、なぜ私たちは書くのか／書いて何が残ったのか を、編集長の視点でふりかえります。

Wantedly の「書く文化」

Wantedly には、知見を社外に発信する文化が根付いています。エンジニア有志の「Wantedly執筆部」が技術書典で Techbook を出し続けていて、シリーズはすでに 10 冊以上。今回の本も、その流れの中で TSKaigi 2026 に合わせて作った、TypeScript・フロントエンドにフォーカスした特別版です。

そもそもの始まりは 2016 年。最初の WANTEDLY TECH BOOK を出したときの記事では、なぜ自分たちで書くのかが、こう語られています。

それらの技術をプロダクトに適用し、どのように運用しているかは、実際にプロダクトを開発し運用している私達でなければ書けないと思いました。

Wantedlyを支える技術をギュッと１冊の本にして技術書典に出展しました（2016 年）

いまは AI に聞けば、大抵のことは返ってきます。しかし、その AI が学ぶ元ネタも、もとをたどれば誰かが書いたもの。実際に運用して初めてわかることを書き残しておくのは、そういう意味でも案外価値があるのかもしれません。

なぜ Techbook を出すのか

アウトプットの形はいろいろありますが、それでも私たちが Techbook を出す理由を、3 つ挙げてみます。

1. 暗黙知が、形式知になる

日々の開発で身についた知識の多くは、頭の中にあるだけの「暗黙知」です。なんとなくこうしている、経験的にこちらを選ぶ ── 言葉にしないまま溜まっていく。書くという作業は、その暗黙知を引きずり出して「形式知」に変える行為です。自分の中だけにあったものが、人に渡せる形になる。書いていて一番おもしろいのは、この変換が起きる瞬間だと思っています。

2. 「認知をとる」という目的

認知をとるためでもあります。今回は TSKaigi に合わせた TypeScript・フロントエンド特化版。来場者の関心にまっすぐ届く形で、「Wantedly はこういうフロントエンドをやっている」と示せます。

3. 「物理本」であること

そして、これがデジタルではなく物理本だということ。カンファレンスのお土産として、また「参加した成果」として、物理本はとてもわかりやすい形です。ブースで手渡せて、持ち帰ってもらえる。AI がいくらでもテキストを生み出す時代に、あえてモノとして残すことには、不思議な手応えがあります。一方で、ページ数やレイアウトといった、紙ならではの制約もあります。

エンジニアらしい本の作り方

本づくりの進め方は、ふだんのソフトウェア開発とほとんど同じです。本を作るためのテンプレートが用意されていて、原稿は書けたところから PR を出してマージする。重い承認フローはありません。この「書けたらどんどんマージする」感覚は、コードを継続的にデプロイしていくのに近いものがあります。

技術スタックも軽く紹介しておきます。

• 執筆: Markdown（書いたものを Re:VIEW に変換）
• 組版: Re:VIEW ＋ LaTeX で PDF 化、EPUB も生成
• ビルド: Ruby / Rake で統括し、Docker で環境ごと再現
• 校正: prh による表記ゆれチェック
• CI: GitHub Actions

そして今回は、AI も取り入れました。

Claude Code: 記事の取り込みを自作コマンドで

原稿の中には、すでに公開している記事に追記や最新の状況を反映し、加筆・修正したものがあります。その元記事を取り込む作業を、Claude Code のカスタムコマンドにまとめました。URL を渡すと、本文を抜き出し、Techbook 用のフォーマットに整え、目次への登録まで一気にやってくれます。

Devin AI: 仕上げの校正に

書き上がった原稿の校正は、Devin AI に任せました。表記揺れや冗長な言い回しの修正、文字化けの解消といった、地道だけれど時間のかかる仕事を担当してくれて助かりました。

リポジトリが語る、制作の 6 週間

締切は 4/24。そこに向けてどう動いたかが、git のログにそのまま残っています。立ち上げから約 6 週間、コミットは 132 件、マージした PR は 33 件。本文は 5 章＋まえがき・あとがき・著者紹介という構成でした。

コミットを時系列で追うと、こうなります。

• 3/12 〜 13: リポジトリ立ち上げ。テンプレートを自分たちの Techbook に書き換える初期設定。
• そのあと 2 週間以上の空白。 ……全員そっと見ないふりをしていた時期です。
• 4 月入り: 始動。Chapter Leader が先陣を切り tips を共有。
• 4/13 の週: 一気に 59 コミット。執筆のピーク。
• 4/21 〜 24: 仕上げで 51 コミット。

記事は締切より前に書き上がり、仕上げにも時間を取れました。スロースタートだったわりに、終わってみれば優秀な流れです。── 最後の最後に、ひとつ事件が起きたのですが。

おわりに

最後に、その事件の話を。

制作自体は順調でした。問題が起きたのは、印刷を発注する直前です。ページの判型が、想定と違っていることに気づきました。仕上げるべきは A5、しかしデータは B5。判型が変われば、レイアウトもページ数も、載せられる文章量も変わります。原因はシンプルで、提出するものの条件を整理してチェックできていなかったこと。入稿前に PDF のサイズを確認していれば、それだけで防げたミスでした。

それでも、刷り上がった本を手にできたのは、作者として素直に嬉しいものでした。TSKaigi のブースでは、当初の見込みより多く配ることができました。全て配れるとは思っていなかったので、嬉しい誤算でした。