📚

技術書典17で276部頒布できた、「コードレビューのループ図」を技術同人誌にした話

2024/12/02に公開

本記事は株式会社ココナラ Advent Calendar 2024 2日目の記事です。

こんにちは。
株式会社ココナラでバックエンド開発に従事するかわむーと申します。

私は趣味で技術同人誌を執筆しており、技術書典や技術書同人誌博覧会などの技術同人誌イベントへサークル参加しています。
直近でも2024年11月2日から11月17日まで開催されていた「技術書典17」にサークル参加しました。

そこで、「鍛錬するとコードレビューがループする 〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜」(以降、「コードレビューループ本」と記載)という本を頒布していました。
最終的な頒布部数は、オフライン/オンライン含めて276部となりました。

表紙

本記事では、この「コードレビューループ本」についての裏側を記載します。

この本を執筆しようとしたきっかけ

前述の通り、私は技術同人誌の執筆を趣味にしています。ですので、執筆のネタを日々探しています。
ある日、会社のSlackにて「これは広く広めていきたい!」と思うようなネタが投稿されました。
それが、「コードレビューのループ図」でした。

ループ図誕生

作成者はもちろん、書籍のタイトルにもなっている通り、弊社の技術戦略室長の神エンジニアです。

ループ図が投稿されたあと、ぞれぞれを構成する要素について記載がされていました。
この一連の投稿には弊社の独自の内容ではなく、汎用的な内容で書かれていました。
すなわち、ほとんどの文章を変更せずにそのまま採用できそうな文章でした。

ループ図内の要素の説明

「これらの内容、本にして頒布したらどんな反応されるんだろう」

見た瞬間に、そういった考えがよぎりました。

  • 会社のSlackで投稿された内容だしなー
  • とはいえ、投稿された内容は汎用的だしなー
  • 自社の恥を晒す?
  • いやいや、コードレビューで困るなんて、割と共通的な困り事だし
  • 社名を出していいの?
  • 社名を出さなきゃなんとかなるんでは?

そんな想いがぐるぐるとしてたのですが、気がつけばその時は「10月30日の17時」。

技術書典17のオンラインの開催は、11/2(土)の10-11時あたり。
正直なところ、日数が足りない。
でも、このコードレビューのループ図はもっと広まっても良いんじゃないか。

そう思うと、指が動いて以下の文章を書いていました。

本にしていいかの依頼

「まぁ、許可が降りなかったらコンセプトだけ参考にさせてもらって、別の機会に本のネタにするか。」
そんなダメ元でお願いしてみたところ、スタンプで「ぜひ!」と承諾をいただけました。

こうなったら、是が非でも本にしなければ。

そう考えた、退勤1時間前の出来事でした。

執筆時間/頒布用意

退勤後、家事などを済ませて執筆の時間がやってきました。
この時、時計の針は21時を回っていました。

さて、どのような構成にして執筆するか。

正直あまり時間はありません。
技術書典オフラインに持っていく気満々でしたので、早々に"技術書典側の審査"を通過する必要があります。

ここは、以下のシンプルな構成でいくことに決めました。

  • はじめに
  • 本文1章のみ
  • あとがき

このようにすることで「最小構成にして考えることを減らす」「ページ数を減らして頒布物を作りやすくする」ことを意識しました。

つづいて、肝心の本文です。
本文内の構成については、図を先に示して、それらを構成する各要素の説明を入れる形に決めました。

図のインパクトを最初に見せて、まずは最小限の説明。そして、その後に詳しい説明をする。
図を見て興味を持ってくれた人にとっては、こちらの構成の方が頭に入りやすいかな、と考えました。

VSCodeで執筆中

少しだけオリジナリティを出した点としては、コードレビューのループ図の見せ方の順番を「影響が小さい場合(チェックリストに頼る運用)」と「影響が大きい場合(遠回りでも鍛錬に注力した運用)」としたことです。
問題の提起→解決方法の提示の表現ですね。
また、「チェックリスト」による運用は、比較的多くの組織で運用されて、そして何かしらの課題を抱えている状況という認識でいました。ですので、チェックリストの運用が先に来る方が興味を持ってもらえると考えました。

「はじめに」/「あとがき」について

ここについては、文字数を抑えつつ、かつ本文に見劣りしないような文章を書かなければいけませんでした。
せっかく本文がすごくいい事を書いてあるのに、それを台無しにする文章では許可をしてくださった方に申し訳なくなります。

とはいえ、ここで文章を考え過ぎても本末転倒です。
個人で「GitHub Copilot Individual」を利用していたので、それっぽい文章を考えてもらってから校正しました。

表紙作成

また、「本(技術の同人誌)」という体裁になっているので、物理本については表紙をつけたいと考えていました。
しかし、この本に適切な表紙は何か。
ループ図というところで"螺旋階段"などがいいかと漠然と思っていましたが、ふと思いつきました。

コードレビューのループ図をそのまま表紙にしてしまえばよくないか…

表紙は本の顔です。
テーブルに並べたときに興味を持ってもらうことが大事です。
同時に、その本の特徴を表しているのが望ましいです。

となると、やはりコードレビューループ本の表紙は、コードレビューのループ図しかない、という結論に落ち着きました。
なにより、表紙側を開いた際に「コードレビューのループ図」が出てくるのはおもしろいと思いました。

というわけで、コピー本を購入された方だけが知っていた、「コードレビューのループ図」があらわれる表紙/裏表紙がこちらとなります。

表紙と裏表紙でコードレビューのループ図

電子版はFREEで頒布していたので、物理本を購入できた方への特典だったということで。

技術書典の審査依頼

本文はできました。
ここから技術書典の審査用の情報の登録です。

このときに、すでに24時半すぎ。
しかし、技術書典17の初日に間に合わせるためには、少しでも早く申請を出す必要があります。

できあがったPDFをアップロードし、紹介ページの内容をざっと書き上げ終わってから、布団に入りました。

技術書典への審査依頼

※後日談。当日(2024年10月31日の昼には承認されていました。技術書典のスタッフさんありがとうございます。)

オフライン会場での頒布

オフライン会場で頒布するならば物理本はあったほうが良いです。
何よりも、自分自身もできあがったものを見てみたかった。

しかし、時間の都合で印刷所さんには依頼できないので、コンビニに行ってコピー本を作成する方式を採用。
某コンビニの冊子形式の印刷は大変重宝します。

そして、できあがった見本誌がこちら。

見本誌爆誕

紙の本は10部用意したのですが、技術書典17の開始一時間で完売しました。

完売しました連絡

なお、完売後も見本誌を手に取る方は多かったです。
手に取られた方には、無料頒布の電子版の購入を勧めていました。
その結果、オフライン会場でも電子版の21部の頒布ができました。
そして、コードレビューについて感じられている問題や課題点などを購入者の方と情報交換もできました。
本を通じてのコミュニケーションは、即売会の醍醐味ともいえます。

オンラインで拾ったコードレビューループ本への反応

以下、実際にオンライン上で、「コードレビューループ本」にいただいた感想です。
幸い、好意的な感想を頂けています。

  • こういう神エンジニアの社内向けに語った考えを公開していただけるのありがたい
  • 読みました。概念をマップとして示されるので、理解しやすく、さすがと思いました。概念を伝えるとはそういうこと。
  • コードレビューのループ図、マジ凄い。まず、レビューがループ構造になってるという発想が無かったし図で共有するという発想も無かった。
  • コードレビュー力ってどこでみんな教えてもらったんですかね?と思ったりしてたのでこういう例欲しかったーーー!
  • 読了! これを読めばコードレビューがすぐできるようになる系ではなく、ここからはじめていくと良いレビューをできるようになれそう、そんな本。

この内容は、社内へフィードバック済みです。

まとめ

本業とは少し違った記事になりましたが、アドベントカレンダー向けの記事ということで、茶目っ気を出してみました。

もちろん、本記事は「好きなことを書いただけ」という扱いではなくて、弊社の文化のような雰囲気を感じてもらえる一環として記載しています。

なお、「コードレビューループ本」は別途ココナラ用にカスタマイズして、もっと綺麗な本の体裁にして頒布しなおそうという野望を個人的に持っています。
もしも、この計画が上手くいったら、新たなコードレビューループ本が紙媒体であなたのお手元に届く…かもしれません。


明日は@hiroki_sato_piroさんによる、オンラインDDLの検証とミスした話です。

ココナラでは積極的にエンジニアを採用しています。

採用情報はこちら。
https://coconala.co.jp/recruit/engineer/

カジュアル面談希望の方はこちら。
https://open.talentio.com/r/1/c/coconala/pages/70417

Discussion