Bookathonで技術書を書いてわかったこと

2026-02-09

*この記事は微調整にAIを使った。

3日間で技術書を書くハッカソン「Bookathon」に参加した。 初めて本を書くことにチャレンジしてみて、たくさん学びがあった。 例えば、技術書のタイトル・副題や「はじめに」はいろんなことを計算して作られているということ。当たり前のことと思うかもしれないが、参加してみて解像度が少し上がった。書くことは、読むことの質も上げる!

Bookathonとは

Bookathonは、3日間で技術書を書き上げる執筆ハッカソンだ。2026年2月6〜8日、メルカリ六本木ヒルズオフィスで開催された。(イベントページ

普通のハッカソンと違うのは、アプリではなく本を書くこと。そして、技術書編集者や、商業誌・同人誌の著者がメンターとして会場にいること。書きながらプロに相談できる環境はチャンスすぎると思って参加した。

Day 1: チーム結成

初日の夜、参加者が集まってキックオフ。「何を書きたいか」を自分から宣言できるタイミングがあった。任意で、言いたい人が手を挙げるスタイルだ。

自分はテーマが決まっていたので、イベント申し込み当初は1人で書くつもりだった。でも、せっかくの場なので「バイブコーディングで作ったアプリのセキュリティについて書きたい」と声を上げてみた。すると興味がある人が集まって、4人チームが結成された。

勇気を出して宣言してよかった。声を上げなければチームは生まれなかった。

次回参加したい方へ: このタイミングで声を上げるのはいいムーブ。宣言によって1対nのコミュニケーションが済むので、その後は聞き役に回れる。

Day 2-3: 執筆

書いた本

テーマは 「コーディングエージェントで作ったアプリの脆弱性診断」

この2軸で、過去にハッカソンで入賞したアプリを実際に診断してみた。

CursorやClaude Codeで「チャットボットを作って」と指示すれば動くものはできる。でもそのコード、セキュリティは大丈夫なのか? 本書を読めばその疑問を自分たちの手で検証できるようになる。

執筆の進め方

構成は「はじめに → 解説 → おわりに」のシンプルな形。解説部分は統一フォーマットを決めた。

  1. OWASPカテゴリの解説
  2. どう検査したか
  3. 何が起きたか
  4. なぜ起きたのか
  5. どんな被害が想定されるか
  6. 対策

このフォーマットが決まった時点で、あとは各自が担当するOWASPカテゴリを分担して並行執筆できた。

合同誌でうまくいくコツは、早い段階でフォーマットを固めること。

会場の雰囲気

会場は広く、お菓子やドリンクが用意されていて助かった。Day 2で執筆疲れが出てきたタイミングで、唐突にラジオ体操が始まったのは笑った。何年ぶりにやっただろう。全体的にゆるくてたすかります。

Day 3: 発表会

最終日の午後、各チームが書いた本の内容をプレゼンした。アドバイザリーボード(編集者、商業誌の著者、同人誌の著者)から建設的なフィードバックがもらえる。「この本のどこが魅力か」「市場性を踏まえるとどうすべきか」といったもの。とても参考になる。

懇親会ではピザが振舞われた。アドバイザリーボードの方もそのままいるので、普段は絶対に聞けない話が聞ける。

参加者は3日で本を書き上げた直後。エクストリームな体験の後で頭がぼーっとしており、最後のエントランスでは別れが惜しかったぜBro。


学び1: 「書くハッカソン」という形式の力

「いつか本を書きたい」と思っている人は多い。でも実際に書き始める人は少ない。

Bookathonには 「いつか」を「いま」に変える強制力 がある。1人では絶対に挫折するタイミングでも書き続けられる。合同誌スタイルなら各自のテーマで書き始められるので、スタートも早い。「何について書くか」さえ決まれば、あとはフォーマットを揃えて書くだけだ。

学び2: 技術書は内容だけの勝負ではない

メンター(編集者)からもらった最大の気づきがこれだった。

内容やコンセプトは悪くなかった。しかし 「本として届ける力」が足りなかった。具体的にはこういうことだ。

要素 指摘
タイトル・副題 「どんな本なのか」が伝わっていない
表紙 ビジュアルコミュニケーションが不足
「はじめに」 誰向けで、誰向けでないかを明示すべき

着眼点が良くても、手に取ってもらえなければ始まらない。パッケージング(タイトル、表紙、導入)が本を届ける力を左右する。

学び3: 書く側に回ったら、読み方が変わった

これが一番伝えたいこと。

自分で本を書いてみて、これまで読んできた技術書の見え方がまるで変わった。

タイトル、副題、「はじめに」。今まで無意識に流していたこれらが、実はとても計算されて構成されていたことに気づいた。なぜあのタイトルなのか。なぜ「はじめに」であの順番で書かれているのか。書く側に立って初めて見える意図がある。

個人的な改善点は「タイトルが伝わらない」「はじめにが弱い」というフィードバックだったが、プロの著者・編集者の仕事の解像度が上がったのはよかった。

読む → 書く のサイクルは、理解の解像度を上げる。読むのが好きな人にこそおすすめ。

学び4: エンジニアと編集者の接点

普段エンジニアとして働いていると、編集者と話す機会はほぼない。Bookathonには技術書の編集者や著者がメンターとしているので、テックカンファレンスやハッカソンとは違った学びがある。

技術の話ではなく、伝え方の話。 「書く」という行為のプロから直接フィードバックをもらえる場は貴重だ。この接点がBookathonの大きな価値だと思う。


まとめ

Bookathonで書いた本は、技術書典20に向けてブラッシュアップして出す予定だ。タイトル、副題、表紙、「はじめに」。メンターから指摘されたポイントを見直す。

技術書が好きな人こそ、次回Bookathonがあれば「えいや!」で飛び込んでみてほしい。書いてみると、次に技術書を読むときの体験が変わる。 これは参加者が確実に得られる体験だと思う。


Bookathon運営、メンターの方々、そしてチームメンバーに感謝。

𝕏でシェア