キャリアの中で本を作る / Making a Book During Your Career

Agile Testing Night#29 ~スクラムフェス新潟ファンミ Vol.1~
https://wingarc1st-spqi.connpass.com/event/394449/

技術同人誌を作ったのでその話をします。

作った本: 『ソフトウェアテストと哲学を同時に学ぶ』
https://techbookfest.org/product/pDFpdT1p2ysNLXS2zSuRH2

Transcript

1. キャリアの中で本を作る 2026-07-10 Agile Testing Night#29 スクラムフェス新潟ファンミ vol1 サイボウズ株式会社 小山 晃久（@akihisa1210）
2. 目次 ⚫ 本を作るまで ⚫ 本を作る ⚫ 本を作ってから ⚫ 付録: 技術書典20サークル参加のためにやったこと
3. 自己紹介 ⚫ 小山 晃久（@akihisa1210） ⚫ ～2016 大学・大学院で西洋政治思想史を研究 ⚫ 2016～ サイボウズ株式会社 ⚫ 2016～2017 不具合・仕様の調査 ⚫ 2017～2019 スクラムチームの中のQA ⚫ 2019～2023 CI/CD・リリース改善 ⚫ 2024～ QAマネージャー、プロダクト視点での品 質保証戦略 ⚫ 2026～ AI前提の開発の探究 ⚫ 2022 スクラムフェス新潟で登壇 ⚫ 2026 技術書典20で『ソフトウェアテストと哲学を同時 に学ぶ』頒布
4. スクラムフェス新潟！ https://speakerdeck.com/ak1210/preconceptions-and-what-happened-with-e2e-testing
5. 『ソフトウェアテストと哲学を同時に学ぶ』 ⚫ Bottleneck Press / akihisa1210著 ⚫ B5、本体104ページ ⚫ 著者のキャリアから生まれた技術同人誌 ⚫ 「あらかじめ与えられた答えのない判断」をめぐって ソフトウェアテストと哲学をつなぐ ⚫ テストと哲学の並列 & 対話 ⚫ 一部では「ソフ哲」と呼ばれているらしい
6. 今日お話しすること ⚫ なぜ本を作ったのか、どうやって作ったのか、作ってどうなったのか ⚫ QAエンジニアとしてのキャリアの話は懇親会で！
7. 本を作るまで
8. なぜ本（技術同人誌）？ ⚫ 会社でよく聞かれること（ソフトウェアテストのことと哲学のこと）をどこかにまとめておきたい ⚫ 執筆だけではなく企画、組版、印刷手配、値付け、宣伝、頒布まで経験できる ⚫ やるのは「書く」ことだけではない ⚫ 事業のミニチュア ⚫ 2025年に別のイベントに向けて本を作っていた
9. 着想 ⚫ 色々な時期に仕事の中でなんとなく思っていたことが本書のコアとなった ⚫ ワインバーグの「品質とは誰かにとっての価値である」「それゆえ、全員の希望を100%満たすことはできない」 と、ウェーバーの「神々の戦い」って似てるな ⚫ 「探索的テストが難しい、テンプレートが欲しい」という話をたまに聞くけど、テンプレートがあったら探索的テス トではなくなる気がする ⚫ インプロセスQAは重要だが、それだけではカバーできない領域もある ⚫ 「品質保証システム」重要（『現代品質管理総論』） ⚫ 「テストしてますか？」に対して、人によって「やってます」「書いてます」など答え方が違う
10. 直接的なきっかけ ⚫ 技術書典という技術同人誌の即売会が年に2回（4月、11月）開催されている ⚫ もともと2026年11月の回に申し込もうと思っていたが、相談した人の後押しもあり2026年4月の回に申し込み （2026-02-13） ⚫ これにより締め切りが発生した ⚫ 結果としては良かった。「準備ができてからやる」だと、いつまでもやらない
11. 申し込み時点での構想（提出したものから抜粋） ▪サークルの説明 QAエンジニアであるakihisa1210（https://x.com/akihisa1210）による個人サークルです。 品質保証やソフトウェアテストをはじめとするソフトウェアエンジニアリングの経験と、個人的に興味関 心があり大学でも学んでいた人文学・哲学・思想を合わせた読み物を作りたいと思っています。 技術書典20では、「ソフトウェアテストと哲学を同時に学ぶ」というテーマの書籍を出したいと考えていま す。ソフトウェアテスト技術の中には、ソフトウェアという極めて複雑な存在に対する検証方法の知見が 蓄積されていますが、これと哲学における「私とあなたが見ている世界は同じか」「真理とは何か、それが 正しいとどうやって確認できるのか」といった種の問いの間には重なる部分があると感じています。ソフト ウェアテストと哲学の内の一方を他方に還元してしまうのではなく、両者を並列させつつ一方に他方の 視点を取り入れることでそれぞれを楽しむことを目指します。 対象読者は、ソフトウェアテストと哲学のいずれかもしくは両方に興味のある方です。
12. 本を作る
13. やること（ざっくり） ⚫ 内容を決める ⚫ 本文を書く ⚫ 表紙を作る ⚫ 入稿データを作る ⚫ レビューしてもらう ⚫ 入稿する ⚫ 価格を決める ⚫ 技術書典オンラインマーケットに本を登録する ⚫ 宣伝する ⚫ オフラインイベントのブースを設営する ⚫ オフラインイベントで本を頒布する ⚫ 事後処理
14. やること（ざっくり） 内容を決める 本文を書く レビューを受ける 入稿データを作る 入稿する オンラインマーケットに本を登録する オフラインイベントで本を頒布する 表紙を作る 価格を決める 宣伝する サークル参加を申し込む 指摘を反映する 印刷所を選ぶ
15. 大変だったこと ⚫ 技術書の文体を手に入れる ⚫ AIはどこまで使えるか ⚫ 締め切りとの闘い
16. 技術書の文体1 ⚫ 章立てを決めて執筆を始めたが、技術書らしくならない（以下例文） ソフトウェア開発におけるテストと聞いてまず思い浮かぶのは、「テストで不具合が見つかった」や「テ ストをしたのに不具合に気づけなかった」といった会話かもしれません。ソフトウェアテストは、ソフト ウェアやソフトウェアからなるシステムの中に潜む不具合を発見する活動です（ただし、これが一つ の側面にすぎない、ということは本章で追って説明します）。 あなたが作ったソフトウェアが、あなたの意図通りに動作することはどうすればわかるでしょうか。「実 際に動かしてみて、その動きが意図どおりであることを確認すれば良い」というのも一つの回答です。 <テストケース例> これは一見当たり前のように思われるかもしれません。しかし、「意図通りに動くか確認する」のではな く「問題を見つけようとする」場合は、試すことが変わりそうです。 <テストケース例> このように、「もしこのソフトウェアに不具合があるとしたら」と考えながらソフトウェアを動かしている とき、あなたはテストをしているといえます。
17. 技術書の文体2 ⚫ なぜしっくりこない？ ⚫ 一直線に進んでいない感じ ⚫ 本当に言いたいことが後半にある
18. 技術書の文体3 ⚫ 思考の順番になっている。自分にはわかりやすいが、読者がそれに付き合ってくれるかは別問題 ソフトウェア開発におけるテストと聞いてまず思い浮かぶのは、「テストで不具合が見つかった」や「テ ストをしたのに不具合に気づけなかった」といった会話かもしれません。ソフトウェアテストは、ソフト ウェアやソフトウェアからなるシステムの中に潜む不具合を発見する活動です（ただし、これが一つ の側面にすぎない、ということは本章で追って説明します）。 あなたが作ったソフトウェアが、あなたの意図通りに動作することはどうすればわかるでしょうか。「実 際に動かしてみて、その動きが意図どおりであることを確認すれば良い」というのも一つの回答です。 <テストケース例> これは一見当たり前のように思われるかもしれません。しかし、「意図通りに動くか確認する」のではな く「問題を見つけようとする」場合は、試すことが変わりそうです。 <テストケース例> このように、「もしこのソフトウェアに不具合があるとしたら」と考えながらソフトウェアを動かしている とき、あなたはテストをしているといえます。
19. 技術書の文体4 ⚫ 思考の順番になっている。自分にはわかりやすいが、読者がそれに付き合ってくれるかは別問題 ソフトウェア開発におけるテストと聞いてまず思い浮かぶのは、「テストで不具合が見つかった」や「テ ストをしたのに不具合に気づけなかった」といった会話かもしれません。ソフトウェアテストは、ソフト ウェアやソフトウェアからなるシステムの中に潜む不具合を発見する活動です（ただし、これが一つ の側面にすぎない、ということは本章で追って説明します）。 あなたが作ったソフトウェアが、あなたの意図通りに動作することはどうすればわかるでしょうか。「実 際に動かしてみて、その動きが意図どおりであることを確認すれば良い」というのも一つの回答です。 <テストケース例> これは一見当たり前のように思われるかもしれません。しかし、「意図通りに動くか確認する」のではな く「問題を見つけようとする」場合は、試すことが変わりそうです。 <テストケース例> このように、「もしこのソフトウェアに不具合があるとしたら」と考えながらソフトウェアを動かしている とき、あなたはテストをしているといえます。 こう思うよね、 というフリ でも、実は…… というオチ
20. 技術書の文体5 ⚫ 何が問題か ⚫ プレゼンなら聞き手が途中離脱しづらいのでオチまで聞いてくれる可能性が高いが、本はそうではない ⚫ フリの部分で離脱されると誤解が残る ⚫ 途中で読むのをやめても得られるものがあるようにする ⚫ 具体 → 構造 → 概念、の順で書いてみる ⚫ 具体: 読者が見てわかるもの ⚫ 構造: 具体の中から抜き出された抽象的なもの（因果関係とか） ⚫ 概念: 構造に名前を付けたもの
21. 技術書の文体6 ⚫ 具体 → 構造 → 概念の順で書きなおしてみる テストで不具合を見つけるというのは当たり前のようにも思えます。しかし、「不具合を見つけよう」と思ってテストをすることには、 ある効果があります。 具体例で考えてみましょう。あるWebサービスのログイン画面のテストで何を確認するかを考えてみます。まずは、「意図通りに動く か確認する」という視点でテストを考えてみます。 <テストケース例> このようなケースが思い浮かんだのではないでしょうか。次に、同じログイン画面に対して、「不具合を見つける」という視点でテス トを考えてみます。 <テストケース例> 両者を並べてみると、「不具合を見つける」というスタンスで作られたテストは、「意図通りに動くか確認する」というスタンスで作ら れたテストよりも広い観点のテストが含まれていることに気が付きます。「意図通りに動くか確認する」というスタンスでは、そのソ フトウェアが問題なく動いていることを前提とした確認がメインとなりがちです。これに対して、「不具合を見つける」というスタンス は、問題を発見することに注目しています。 「テストで不具合を見つける」という表現は、特に意識せずに使われる場合でも、テストに問題発見という側面が含まれていること を示しています。ソフトウェアテストに関するある書籍に「テストとは、エラーをみつけるつもりでプログラムを実行する過程である （注）」という一節がありますが、これはソフトウェアテストのこの側面を踏まえた定義です。 （注）マイヤーズ, J.、バジェット, T.、トーマス, M.、サンドラー, C. 著、長尾真監訳、松尾正信訳『ソフトウェア・テストの技法 第 2 版』近代科学社、2006 年、pp.8~9
22. 技術書の文体7 ⚫ 具体 → 構造 → 概念の順で書きなおしてみる テストで不具合を見つけるというのは当たり前のようにも思えます。しかし、「不具合を見つけよう」と思ってテストをすることには、 ある効果があります。 具体例で考えてみましょう。あるWebサービスのログイン画面のテストで何を確認するかを考えてみます。まずは、「意図通りに動く か確認する」という視点でテストを考えてみます。 <テストケース例> このようなケースが思い浮かんだのではないでしょうか。次に、同じログイン画面に対して、「不具合を見つける」という視点でテス トを考えてみます。 <テストケース例> 両者を並べてみると、「不具合を見つける」というスタンスで作られたテストは、「意図通りに動くか確認する」というスタンスで作ら れたテストよりも広い観点のテストが含まれていることに気が付きます。「意図通りに動くか確認する」というスタンスでは、そのソ フトウェアが問題なく動いていることを前提とした確認がメインとなりがちです。これに対して、「不具合を見つける」というスタンス は、問題を発見することに注目しています。 「テストで不具合を見つける」という表現は、特に意識せずに使われる場合でも、テストに問題発見という側面が含まれていること を示しています。ソフトウェアテストに関するある書籍に「テストとは、エラーをみつけるつもりでプログラムを実行する過程である （注）」という一節がありますが、これはソフトウェアテストのこの側面を踏まえた定義です。 （注）マイヤーズ, J.、バジェット, T.、トーマス, M.、サンドラー, C. 著、長尾真監訳、松尾正信訳『ソフトウェア・テストの技法 第 2 版』近代科学社、2006 年、pp.8~9 いきなり具体 例から入る 構造を示す （二者の対比） 概念（定義）の 導入
23. AI活用1 ⚫ Claude Max x5プランを契約し、Claude Codeをメインで利用していた ⚫ 上手くいったこと（1） 本文執筆の支援 ⚫ 例の生成（テストケース例、命題の例、……） ⚫ 様々な壁打ち ⚫ 対話の生成 ⚫ エンジニアエージェントと人文学徒エージェントにそれぞれ本文を読ませてから対話させ、感想やツッコ ミを出力させる ⚫ もともとはレビューのために使うつもりだったが、面白かったので本文にも入れた
24. AI活用2 ⚫ 上手くいったこと（2） 情報収集・整理の支援 ⚫ 誤字脱字のチェック ⚫ Re:VIEW（組版ツール。入稿のためのデータを作る手段の一つ）の記法理解 ⚫ Deep research ⚫ 頒布数や売り上げの管理
25. AI活用3 ⚫ 上手くいかなかったこと ⚫ 最終的にリリースする文章を作る ⚫ 70点くらいのものは出してくれるが、100点に近づけるためには相当な推敲が必要 ⚫ 自分の名前を付けてそれを出せるか、出して良いか ⚫ そして、この推敲が（私にとっては）真のボトルネックだった ⚫ 事実確認 ⚫ AIでもできるのかもしれないが、本にするならファクトチェックや自分で確認した引用元の明示は必須 ⚫ AIで仕組みを作ると満足感があるが、本当に重要なことが進んでいるか
26. 締め切りとの闘い1 ⚫ 2/13 技術書典20参加申し込み ⚫ 2/20 Claude Codeでの執筆環境整備 ⚫ 2/23 章立てv1作成（6章構成） ⚫ 2/26 技術書典20当選発表 ⚫ 3/1～3/6 ネタ出し ⚫ 3/7 本文執筆開始 ⚫ 3/8 章立てv2作成（8章構成） ⚫ 3/12 Re:VIEW用リポジトリ作成 ⚫ 3/15～3/21 ドラフト作成 ⚫ 4/1 レビュー依頼（4名） ⚫ 4/1～4/7 推敲 ⚫ 4/8 入稿 ⚫ 4/9 サイズ間違いにより再入稿 ⚫ 4/11 オンラインマーケット開始 ⚫ 4/12 オフラインイベント当日 ⚫ 4/26 イベント最終日
27. 締め切りとの闘い2 ⚫ 執筆がクリティカルパスとなるため、そこに影響を及ぼす要因は可能な限り除去したい ⚫ 時間をかけざるを得なかったもの ⚫ 強めの制約による書き方の難しさ ⚫ 制約1: 哲学でテストを説明することと、テストで哲学を説明することは避ける ⚫ 制約2: テストの章だけを独立して順番に読んでも意味が分かる ⚫ これは本書でのこだわりポイントなので維持する（時間をかけるべき場所だと判断） ⚫ 引用元の再読 ⚫ 推敲
28. 締め切りとの闘い3 ⚫ 対策できたかもしれないこと ⚫ 当選連絡まで作業開始を待ってしまった ⚫ AIが書いたたたき台を進捗だと勘違いし油断した
29. 締め切りとの闘い4 ⚫ キャッチアップが必要だったこと ⚫ 組版ツール（Re:VIEW）への慣れ ⚫ Re:VIEWでビルドされたRe:VIEWの入門書があるので参考にした ⚫ リポジトリも公開されている https://github.com/TechBooster/FirstStepReVIEW-v3 ⚫ 入稿方法 ⚫ 印刷会社のHPから条件を追加し、見積もりを取る（入稿日、ページ数、紙の種類、印刷の種類など） ⚫ 本文も表紙もA5で作っていたつもりだったが、本文がB5になっていたことに入稿後に気付いた
30. 本を作ってから
31. 技術書典20に出展！ ⚫ オンラインの会期があり、その中の一日にオフラインイベントが開催される ⚫ オンラインの会期中は、紙書籍もWebから購入できる（配送は会期終了後）。電子書籍はいつでも購入できる
32. 反響 ⚫ 用意していた紙書籍30部は午前で売り切れ。思っていたよりも多くの人に興味を持ってもらえた！ ⚫ ブースに来てくれた方は、テストに興味がある人が70%、哲学に興味がある人が10%、両方に興味がある人が 20%くらい ⚫ 「どういうことですか？」 → 説明する ⚫ 「会社の本棚に置きたい」「この本のために技術書典に来た」など嬉しい声も！ ⚫ スクラムフェス新潟2026でも本の話ができました
33. ふりかえり・次回に向けて ⚫ 変化 ⚫ 本で扱った領域に対して、明確な意見を持てるようになった ⚫ 仕事の軸とは別に、継続して活動していきたい軸が生まれた ⚫ 次回も申し込み済み！ ⚫ スケジュールの反省を踏まえて、この登壇が終わったら準備開始したい ⚫ AIを使うべきところと使うべきではないところ（進捗が出ていると錯覚させるところ）を見極めたい ⚫ あなたもキャリアの中で本を作ってみませんか？
34. 付録: 技術書典20サークル参加のためにやったこと
35. おことわり ⚫ 以下の記述は2026年4月に開催された技術書典20時点の情報です
36. サークル参加申し込み ⚫ 申し込み期間内に申し込む ⚫ 規約や要項を読む ⚫ オンライン + オフライン出展かオンライン出展かを決める（技術書典ではオンライン出展、つまり電子版の頒 布が必須） ⚫ 会場で紙の本を買うと、電子版も付いてくる ⚫ サークル名を決める。アカウント名や本名と同じでもいい ⚫ どういう書籍を作ろうとしているのかの説明文を書く（運営の審査・配置検討用なので公開されない） ⚫ 当落発表を待つ ⚫ 待っている間に書き始めてしまうことを推奨
37. 入稿1 ⚫ 「物理書籍も作る」かつ「印刷会社を利用する」場合は、印刷会社に入稿する期限が締め切りとなる ⚫ 印刷会社が指定する形式でデータを作る必要がある ⚫ 印刷会社を選ぶ ⚫ 技術書典では「前から印刷」「後から印刷」という印刷費補助の仕組みがある（利用条件・印刷所指定あり） ⚫ 前から印刷: オフライン会場に直接搬入された書籍の印刷費用の一部がキャッシュバックされる（印刷会社 への入稿は自分でやる必要あり） ⚫ 後から印刷: オフライン会場で手渡しした以外の物理書籍を、イベント終了後に事務局が増刷・送付してくれ る（事務局にデータを渡す。入稿データ仕様に制限あり） ⚫ 私の場合: これらの印刷費補助に対応している日光企画を利用した
38. 入稿2 ⚫ 日光企画での印刷仕様 ⚫ オンデマンド・フルカラーセット ⚫ 表紙込みページ数: 108ページ ⚫ 左綴じ ⚫ 表紙: NPホワイト200kg + クリアPP ⚫ 本文: 上質90g ⚫ 本文印刷: オンデマンドスミ刷り ⚫ 多くの印刷会社で、納品日より一定日数前を入稿日に指定すると割引が効く「早割り」がある
39. 執筆 ⚫ 本文執筆は頑張るしかない！ ⚫ 印刷会社の仕様に合わせてデータを作成する ⚫ 組版ツールにはRe:VIEWを利用した（定番のツールで情報が多そうだったので） ⚫ テンプレートリポジトリ https://github.com/TechBooster/ReVIEW-Template ⚫ 入門書もある https://github.com/TechBooster/FirstStepReVIEW-v3 ⚫ 日光企画さんにそのまま入稿できる本文データや、電子書籍版データを出力できる ⚫ 表紙も作る ⚫ 3Dモデルを使う表紙にしたかったので、Blender + Claudeでモデル作成 ⚫ Photoshopを単月で契約し、日光企画が用意した入稿用のテンプレートに画像添付、文字入れ
40. オフライン会場の設営 ⚫ 1サークルにつき三人まで参加可能 ⚫ 二人で参加した ⚫ 1サークルにつき長机一つ、パイプ椅子二つが用意されている ⚫ 「完全手ぶらセット」に申し込んでおくと、油性ペン、テープ、値札、テーブルクロスなどももらえる ⚫ テーブルクロスは他ブースと被りそうだったので自前で用意した。180cm×100cmくらいの黒い布を手芸用 品店で購入したが、本が目立ってよかった ⚫ 頒布物を紹介するポスターとブース名を記載したポスターを作成した。いずれもコンビニでカラー印刷した紙 を100均の硬質カードケースに挟み、ブックエンドに貼り付けた簡易的なもの
41. 決済・頒布1 ⚫ オフライン ⚫ サークルごとに決済用のQRコードが用意されている ⚫ 物理書籍が売り切れたら、その後は受注生産で販売することもできる ⚫ 技術書典のアプリ経由で購入できる（イベント終了後、まとめて後払い）
42. 決済・頒布2 ⚫ オンライン ⚫ 技術書典のWebサイトから書籍を購入できる ⚫ 物理書籍は後日まとめて送られる ⚫ イベント終了後、売れた分だけ物理書籍を指定場所に送る必要がある ⚫ 「後から印刷」を使ったので、事務局に申し込むだけで増刷・送付までやってもらえた ⚫ オンライン・オフラインの利益によっては、所得税や住民税の申告漏れに注意（売り上げではなく利益ベースで申 告するので、印刷費などの経費は記録しておく）