学習効果を最大化するために有志を募って技術書典（応援祭）で出版した話
今回、技術書典（応援祭）でVue 3 解体新書という本を出したのですが、その際にいろいろと工夫やら思考錯誤をした結果、なかなかの知見になったのでまとめることにしました。
この記事を読む価値がある読者
初めて技術書典で本を出したい人にも役立つ知見がありますが、一番読んでもらって価値があるのは新しい技術を効果的に学びたい人、有志で技術書典に参加したい人になります。
どんな本を書いたかとその動機
今回、自分（達）が書いた本は、Vue 3のソースコードから内部実装を読み解き解説する「Vue ３ 解体新書」という本です。
私は普段の業務でVue.jsを使っており、「Vue.jsはどうやってあのリアクティブな動作や使い勝手の良いAPIを実現しているんだろう」と、その内部実装に興味を持ってました。しかし、Vue 2は既にかなりのソースコード量で、隙間時間ではせいぜい部分的に読んでみるぐらいが限界でした。
そんなとき、Vue 3のベースとなるvue-nextが2019年10月に公開されました。さっそくソースコードを読んでみたのですが、全てがTypeScriptで実装されており、ファイル構造やフォルダ構造もレイヤーごとに区分けされていてとても理解しやすいものでした。
また、公開されたばかりというのもあり、おそらくまだコア機能のみしか実装されていないということが伺えたので、「Vue.jsを理解するなら今がチャンス」と考え、空き時間でソースコードを読み進めていました。
ここで少し話が逸れますが、「学ぶ」という行為をする上でその学習効果を最大限にするためにはどうすれば良いでしょうか？
自分が考えたのは次の２つです。
1. 集中して学ぶ
2. インプットだけでなくアウトプットをする
ちょうどこの時期、2020年2月の技術書典が行われる予定という情報が入り、「一度は技術書典に本を出してみたいな」と思っていた自分は、
「技術書典でvue-nextの本を出せば、本を書く体験もできるし、Vue.jsのソースコードの理解の質も高まるはず」
とこれを良い機会だと考え、本を出す構想を始めました。
技術書典には入稿締め切りがあるため、強制的に自分の中での優先度が上がり、学習効果の最大化が狙えます。終わりも明確なので短期間で集中して取り組むのにも最適です。
有志を募集した理由
しかし、１つ問題がありました。それは
・Vue.jsのソースコードをガッツリ読むのは初めて
・本を出すのは初めて
・あまりブログ記事を書かないので執筆慣れしてない
というもので、これだけの不安要素がある中で締め切りに間に合わせ且つ、十分なページ数と内容の質が高い本を書けるのか？という問題です。
新しいことを学ぶ過程では、ソースコードを読んでもすぐに理解できない時が必ずきます。特に一人で考える場合は悩みの無限ループに陥り、無駄に多くの時間を浪費する可能性が高くなります。
自分に必要なのは一緒に本を書く仲間でした。
一緒に取り組む人がいれば、迷惑をかけるわけにはいかないという思いから完了させる責任意識も上がり、更にがんばれます。
また、一人でわからないことを相談したり知見共有しあえれば効率的に学習していけます。
執筆するページ数も人数で分散できるので、自分は担当する章に集中できます。書いた内容も相互レビューできるので質が高められます。
私は、一緒に本を書く仲間を募ることにしました。
どうやって有志を集めたか？
有志を集めるために、実はPRとマーケティングを意識して取り組んでいました。すなわち、「ターゲット層」と「ボリューム」です。
どんなに良いものでも、関心をもってくれそうな人に声を掛けることができなければうまくいきません。
幸いにも、日本ではvuejs-jpというslackコミュニティがありました。
募集するには、リーチするボリュームも大事です。このコミュニティには３０００〜４０００名のエンジニアが参加しており、全員Vue.jsに高い関心がある人たちなので、公募するには最適でした。
この取り組みはコミュニティへの貢献にもつながります。
このような公募をかけてみました。
また、情報というのは１回の発信でリーチするとは限らず、できるだけ多くの人に届けるには目に触れる機会を増やす必要があります。同時に事前に宣伝活動をして知ってもらい、事前準備をしてもらうことも大事です。自分の本気度をアピールすることも重要です。
既にちょっとだけソースコードリーディングを進めていた自分は2019年12月のVue.js for 2020の勉強会でLTに応募し、ここでも有志募集のPRと、「ソースコード解説本を出すよ！」というPRを合わせて行いました。
このような取り組みの結果、最終的には、自分含めて10名の参加者になりました。
執筆に使ったツール
今回の執筆で使ったツールは次のようになります。
1. scrapbox
情報共有に使いました。個人的にとても使い心地が良く、かなり便利だと感じています。
2. SlackとGithubとRe:VIEW
Re:VIEWで本を書き、本のデータはGithubで管理しました。
3. plantumlとmindmap
また図の作成にplantumlやmindmapなども使いました。このあたりは強制せず、執筆者の判断に任せておりました。
ただ、最初からこのツールを使う等決めていたのはSlackとGithubとRe:VIEWで、後は進めながら必要性に合わせて増えただけになります。例えばplantumlは、2019年12月に勉強会をする中で、有志メンバーの一人が使って説明してくれたことで「これはわかりやすい」と思ったのがきっかけです。
執筆の当たってのスケジュール
最初にたてたスケジュールは次のようにしておりました。
12月 ソースコード理解（勉強会などを開催）
1月 本を書き始める
2月頭 最終調整および入稿
これを見てすぐに「うわっ」と思った方もいるかと思いますが、超ハードスケジュールです。
何故ハードなのかというと、今回の取り組みが「知ってる事を整理して書く」ではなく「新しく学んで理解してから整理して書く」だからでした。知ってることを書く分には工数見積もりはしやすいですが、新しく学んで理解するのにかかる時間は正確に見積もれません。
実際、普段触れてない概念も多く、理解するのがかなり大変でした。
しかし困難な分、執筆完了した時には参加した全員がとても良い成長ができているだろうということも感じ取れました。
かなりハードなスケジュールなのはわかっていたため、有志を公募した時点で「参加表明者の半分が最後まで残れば良い方だろう」と考えていました。少なくとも3名以上いれば最低限買ってもらう価値のあるページ数と品質が期待できます。
Vue.jsに関心の高い3000〜4000人に有志を募る
↓
そのうち7〜10名が参加表明
↓
そのうち半分の3〜5名が執筆完了
この見込みなら、十分達成可能かなと考えたりしてました。
（3000人の1％で30人なので、10名くらいの参加表明なら大丈夫だろうという考えてました。）
結果としては、この想定通りにいきました。参加者は合計で10名になり、執筆完了したのは5名でした。
有志が集まった後の執筆前の取り組み
今回、有志が集まったあとにいきなり執筆内容の話に入らず、まずはvue-nextのソースコードを理解する時間をつくりました。
「寄稿するテーマだけ整理して、そのあとは各々書く」ということも選択肢として考えましたが、今回はVue.jsのソースコードを理解しないと書けないため、まずはオフライン・オンライン組み合わせてソースコードリーディングをするもくもく勉強会を行いました。頻度はおおよそ隔週ほどです。
日程調整をしてできるだけ参加者が多い日を選び、以下の流れで取り組みました。
自分の興味ある切り口のテーマを言う
↓
もくもくタイム
↓
途中経過報告
↓
もくもくタイム
↓
画面共有しながら理解した内容を発表
これは実際効果が高く、それぞれが今取り組んでいて悩んでいることを話し、他の人と議論することでソースコードの理解度を深める良い時間になりました。また、学習時間を確実に確保する効果もありました。
一方で、うまくいかない施策もありました。
この短期間で理解するにはその頻度では間に合わないと思い、別に自由参加形式で毎日平日の晩にもくもくcallするreminder botをつくったのですが、こちらはほぼ参加者がおらずうまくいきませんでした。
執筆開始から完了までの取り組み
学習時間の確保状況をみるに、かなり厳しそうという印象もありましたが、締め切りに間に合わせるためには執筆開始を遅らせるわけにもいかないため、予定通り1月から執筆タイムに入りました。
ここで失敗したのは、オンラインでもビデオチャットなどをして話すという行動を組み込まなかったことかもしれません。
また、やはりそもそもソースコードを読んで本を書くレベルまで理解するということの難易度がとても高かったとも思います。実質1ヶ月の空いた時間だけでVue.jsの全容を把握するというのがちょっと非現実的な話でした。
1月が終わった段階で、進捗は悪い状態でした。しかし、コロナ禍の影響で、期限が伸びます。また、オフラインでの販売からオンライン販売に切り替わったことで、入稿する締め切りもなくなり、直前まで執筆できるようになりました。実質、２週間ほど締め切りが伸びました。
結果として助けられ、無事出版に間に合わせることができました。
販売開始後の売上共有について
技術書典では売上管理にメンバーを招待することができません。そのため、今回は代表として自分のアカウントで登録し、
自分のメールアカウントに売上通知
↓
Vue.js解剖学会用につくったgmailアカウントに転送
↓
任意のヘッダがあるメール通知をGASでslackにwebhook通知
という方法で通知の仕組みを作りました。
あとは、自分が定期的にキリの良い数字で投稿していきました。都度共有する必要がなくなったため、共有の手間がかなり減り楽になりました。
値付けと収益について
値付け方法ですが、「できるだけ多くの方にとって読んでみて欲しい」という思いと「1ページ10円と言う値付け方法」の両方を考えて、約100Pだったので技術書典では1冊1000円にしました。
ただboothでの販売では、技術書典（応援祭）で買ってくれた方へのお礼の意味も込めて、少し値上げして1冊1500円にしました。
売上についてですが、技術書典（応援祭）では142冊、つまり142人の方に買っていただけました。改めてご購入頂きありがとうございました。売上は142,000円となります。初めての技術書典の参加、しかもオンライン販売だけでこの売上はまぁまぁ良いのではないでしょうか。ちなみにその後boothでも販売開始したのですが、そちらでもご購入いただけており合計売上としてはもう少し多いです。
ちなみに値付けについてですが、「内容をわかりやすくするためにページ数を減らすと、値段下がるのか？」と思われた方もいるかと思います。自分も同じように考えましたが、実際に一般書籍をみてみると1ページ10円計算でだいたいあってそうです。それも含めての値付けと考える方が良いのかもしれません。
あと、値付けするときもメンバーとの合意形成は重要ですので、都度相談した上で進めています。
収益の配分について
今回、これは最も悩ませられる問題の一つでした。
今回は収益が目的ではないので、シンプルに均等配分にしようと考えていましたが、一方で様々な事情でコミットメントの差が生まれていたのも事実だと感じていました。
とはいえ、これはもう世の常ですが言い出しっぺはあれこれ動く（動きやすい）のでコミットメントが自然と大きくなります。「コミットメントを考慮したら自分の配分が上がる」可能性はどんなに謙遜しても高めでした。
また、そもそも最初に「均等配分で考えている」と伝えていたので、後出しで変えるべきではなかったのもあり、
均等配分を提案して、あとは意見があったら再考しよう
という判断をして均等配分を最初に提案して有志メンバーに意見を聞いてみることにしました。
その結果、5人中3人が「配点制での配分案」、5人中2人が「均等配分案」という意見になったので、
・売上の半分を均等配分
・売上の残り半分を各々100点を持ち点として自分以外に配点して配分
という中間案を提案し、合意形成ができたのでこの案にしました。この案を提案した背景には、
・均等配分があるので、最低限の取り分は全員が保証される
・変動率が下がるとはいえ、コミットメントを考慮した配分になる
という面で確実な報酬が保証されることから不満の一番少ない形になるかなと思ったのと、多少でもコミットメントに応じた配分差をつくることで、今後お互いに「申し訳ない」という気持ちを持つことなく、普通に技術仲間として接しやすくなるだろうと考えたからでした。
「最後までやりきったメンバーだし、質と量の差はあれどもできるだけ均等にしたい」「確実な還元が保証される方が良い」という考えもありました。
あとは、「お金よりも取り組んで得た学び」を重視したかったので、均等配分と配点配分を組み合わせることで、報酬にはあまり差が出ないようにしつつもちょっとだけ差が出れば良いかなと考えたのもあります。
とはいえ、これがベストとは自分でも思ってないので参考程度にしてもらえればと思います。
もし、この方法を改良するとすれば、定量的な評価軸も含めると思います。
今回は使わなかったのですが、定量的な評価軸の例として「文字数やコミット数、ページ数での指標」があります。
また、「どの章がよかったか」というレビューや、どの章が何分読まれたかという情報を集計して決めるというのも良さそうです。
シンプルな配分方法は計算も楽ですが、その分誤った偏りが出やすくなります。とはいえ、売上もたっていないのに複合的な配分方法を考えるのも取り組み優先度として微妙な気がします。
そのバランスも考慮すると、今回の配分方法は「完璧ではないけれど、そこまで手間もかからないそれなりに良い方法」だったのかもしれません。
ちなみに、配分評価する際は、事前に他の人の評価を見てしまうとバイアスがかかってしまうので、以下の手順で行いました。
1. まず、代表の自分が配点をメモする
2. 他の人に、自分宛にDMで配点を送ってもらう
3. 最後にその配点結果を全体に共有し、数値間違いがないか確認して振り込む
こうすることで、「配点前に他の人の配点をみてそれに合わせて配点しまう」などのバイアスがかからないようにしました。
技術書典に参加してみての総評
収益については、これを寄稿者全員で配分するので掛けた時間に対してはとても割りに合うものではないと思います。
ですが、もともと収益目的ではなく、「技術書典に本を出すこと」「Vue.jsのソースコードを理解すること」に焦点を当てていたため、個人的には有志を募って大正解でした。
今回自分が担当したのは第４章のTemplate Compilerです。ドラフトの段階ではソースコードが長々と貼り付けており、正直我ながらとても読みやすいとは言えませんでした。本当はもっと他の章も書きたかったのですが、この状態で章を追加するよりも、少しでもわかりやすい解説になるようリファクタリングをした方がよいと判断しました。
その判断ができたのも、有志を募ってページ数を分担することで、本全体としてのボリュームを担保できたためでした。リファクタリングで品質向上に務めた分、より深く理解することもできました。
また、今回執筆は時間リソースの問題で寄稿はされませんでしたが、技術書典経験者であった参加者の方もいたため、おおよその流れや進め方も相談でき、またRe:VIEWの初期設定もしていただけたおかげで執筆に集中できました。（改めて本当にありがとうございました！）
表紙やロゴも有志メンバーの方々につくっていただいたり、執筆内容をレビューいただいたりもして文章を整えることもできました。
次の画像は、pull requestの一部です。
今回のプロジェクトで１つのpull requestに対して最も多いコメント数は93件でした。かなりの量のやりとりがあったかと思います。
それだけ執筆内容に対してお互いレビューしあうことで、不適切な表現を修正することができたのも、一緒に取り組む有志がいたおかげでした。
失敗した点もありましたが、結果よければ全てよしです。
オマケ
今回、取り組みやすいよう寄稿形式にしました。しかし、寄稿形式では１冊の本として全体構成を整えるのが難しかったです。
難しい理由は、「Aのテーマなら書けるけど、既にA以外のテーマだと何を書こうか迷う」という、Aは書きやすいけどそれ以外は書くのが難しいという場合です。今回も、ほぼ全員が０からvue-nextのソースコードを読み始めており、且つ合同勉強会でお互いの理解を共有していったため、必然的に「自分が執筆しやすいテーマ」が近くなってしまったかと思います。
別のテーマを一から調べて理解していく時間的リソースがない場合だったので、ここが難点でした。
初めて技術書を書くなら、できるだけ知ってる内容の範囲で執筆する方が確実だったと思います。
強引なスケジュールと到達目標を組んだ影響が出た箇所でした。
人数がいれば、同じテーマでも大丈夫だったんですが、今回は最終的に残った人数が５名なため、それもしづらい状況でした。また、合同で１つのテーマに取り組むと合意形成にやり取りが必要で時間がかかるため、執筆期間も短い今回ではそれも難しかったです。
ただ、「同じテーマでも、解説の切り口が違えばそれぞれ価値がでるだろう」ということで、それぞれが関心のある、書きやすいテーマを選んでもらうことにしました。結果として内容は重ならずにすみましたが、自由に書きづらい環境を産んでしまったなと反省しております。
寄稿形式の執筆では、「テーマが被っても気にせず自分の関心がある箇所について書いてもらう」ということを初めから明確に宣言しておくと良さそうです。
終わりに
今回、初めて技術書典に参加するに当たり色々と記事を調べましたが、有志で取り組むにあたっての試行錯誤について書かれた記事はあまりありませんでした。
今回の自分のやり方は、次の技術書典に参加する人に役立つ知見になるかとおもいます。
うまくいく・いかないに関わらず、複数人で一緒に取り組むことで得られる学びはたくさんあるので、興味がある方はぜひ一度取り組んでみてください。
また、新しく技術を学ぶにあたり、技術書典の入稿締め切りを学習ブーストとして利用するという事例も多分ないか少ないかと思います。
やってみた感想としては学習方法としてもとても効果的だったので、似た企画をする人が増えると嬉しいです。
自分は割と幅広く興味関心を持つタイプなので、誰かのおもしろそうな企画に自分も参加することがあるかもしれません。その時はどうぞよろしくお願いします。
ちなみに縁あって、次のプロジェクトが始まりそうです。これまた面白難しいプロジェクトになりそうですが、とても学びが多そうです。また折を見て告知していきたいと思います。
最後まで読んでいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？