AWS/Google Cloud技術書籍の執筆経験から - どのようにして自分の本を出すか 怒りがモチベーション

これまで何冊かの本を共著で出しています。このブログでは出版社と共に行う執筆の機会づくりやプロセスについて解説したいと思います。現在、パブリッククラウドに関する書籍ではAWSが2冊出版済みで、Google Cloudは1冊を企画・執筆中です。いずれも認定資格に関するものです。

独学合格 AWS認定クラウドプラクティショナー テキスト&問題集
この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集

執筆の機会づくり

最初のきっかけはブログです。1年ほどAWSやGoogle Cloudの人材育成についてその内容を詳細に紹介していたところ、認定試験本の執筆に関してKADOKAWAの方からお声がげ頂きました。理由は、次のようなものです。

・ブログを書けるくらいなので文章を書けるはず。
・技術的な質問を口頭試問形式で行っているので、問題がすでにあるのではないか。
・この仕組みで100名単位で資格者が増加している。

おそらくブログを書いてその分野に詳しい人は、すでに出版社から声がかかっているのではないでしょうか。

実は怒りがモチベーション

上の節ではまともなことを書いていますが、実は怒りがモチベーションでした。7年前に今の会社のクラウド専門部署に入った際、自分はAWSから転職してきたばかりなので、確実に社内でもクラウドの第一人者であるという自負がありました。しかし、社内の序列はそうではありませんでした。また、それゆえに社内にナレッジを提供するCOE的な立場に追いやられてしまい、私のAWS時代の経験が、他人の口から講演で話されたり各プロジェクトで使われるという悔しい思いをしました。もし私が自分のナレッジを社内で提供せずに自分のリードするプロジェクトだけで使えたらよかったのですが、さすがに上の人も頭がよく、そんなことは許しません。ほぼ1年、プロジェクトに入れてもらえずに社内COEみたいな形で働かざるを得なかったです。

ここで腐るか？当時、クラウド人材の育成が課題になっていてそれに従事していました。私は人に教えるよりも自分が高度なことを学びたいのでかなり嫌気がさしていたのですが、せっかくなのでやってみました。このノウハウを外に出してみよう、それであれば私の社外の認知度も上がるはずだ、と考えたのです。社内ではプロジェクトに入れないので社内でネットワークを築いて自分こそがクラウドに詳しいという認知度を気付くのは難しく、会社のブログが唯一の脱出口でした。それでブログに育成の記事をいくつも書き始めました。

当時、社外向けのブログを書いたことがなかったのですが、怒りをもって書きました。実際に育成の過程を詳しく書いていたのでアクセス数は当時はそのサイト内では1番だったと思います。1年ほど書いたら出版社から声がかかったり、後年、そのノウハウをJagu'e'rで公開して私の認知度も社外で上がったと思います。

なお、部署異動や転職の際に、書き溜めたブログがあると有利だと思います。書いたブログの内容は語れるし、たいていは相手は自分をネットで検索してどういう人か調べるからです。

なんとこの育成の概要は、ダイヤモンドオンラインでも紹介されるレベルになりました。

アクセンチュアのコンサル300人以上が参加！DXの知識＆資格獲得を目指す特別組織の正体

左記のJaguer Award最優秀賞やAWS Top EngineersやGoogle Cloud Partner Top Engineers授賞にもつながっています。

日々の修練

文章を書くスキルを鍛えるには、執筆あるのみです。気分に関係なく、1週間に１つはブログを書くと決めて機械的にやります。これが軌道に乗ってくると筆が載るようになります。生まれて初めて技術ブログを公開した日は遠い昔ですが、その最初の一歩である短いブログが、短いLT5分が、将来のJagu'e'r Award最優秀賞や基調講演の実績を生むのです(私のことですが)。書いたことがない人と書いたことがある人の経験の差は、小さくて大きいものです。一度書いてしまえば、あとは楽です。まあ、これも上記の怒りがモチベーションです。

Jagu'e'r Award 2021　受賞者が決定

Google Cloud CCoE Summit ’23 振り返り
(https://jaguer.jp/ccoe-google-cloud-ccoe-summit-2023-振り返り/)

一緒に執筆する仲間を集める

最初に仲間を若手含めて7人ほど集めましたが、正直これは失敗でした。若手の機会の提供という面もあったのですが、外に出す文章を常に書いてない人や、専門知識の浅い人を入れてはいけません。出来れば次のような人が望ましいです。

・まともな日本語の文章を書くのが早い人。常にブログを書いているような人や他に執筆経験がある人はよい。
・高い専門知識と経験の両方ある人。今勉強しています、と言う人や知識だけあって実装経験のない人はだめです。細かいところで誤ったことを書いてしまいます。
・仕事が忙しいことを理由に執筆を遅らせない人。コンスタントに書ける人が良い。

また、執筆者は3名までが望ましいです。多数の執筆者が入れて執筆スキルの低い人を入れてしまうと、その修正に多大な時間を使うことになってしまいます。文体のずれも出てくるので共著であれば2～3人で書くのがよいでしょう。

出版社に企画書を出す

企画書では、次の内容を出版社に提出します。Wordで2枚くらいです。以下を書けば後は出版社の方が仕上げてくれます。

・なぜこの書籍が売れるのか。
・ターゲット読者
・目次 （章と節まで）と目安となるページ数
・執筆計画。

目安となるページ数ですが、120-140Pくらいが普通のようです。認定試験の問題集もついているとページ数が増加しますが、最初に書いたAWSの書籍は、解説がネットからダウンロードされる形式でした。しかし、1冊の本に全部入れてほしいという要望もあったらしく、2冊目のAWSの書籍は1冊に解説も入っています。

どのような認定資格の書籍を出すか、というのは類似本の売れ行きを見ます。これは出版社の方で調べるのですが、ある認定資格の書籍のうりあげがわるいばあい、その認定資格の書籍は書きません。逆に、すでに類書が出ていても売り行きがいい場合は、同じ認定資格の書籍を書きます。

認定資格本の執筆は時間がかかる

技術書籍と言っても、例えば、AWSやGoogle Cloudの設計の要諦を書くようなものは比較的短時間で書けます。それはよくわかっている分野だし、それをわかりやすく書けばいいからです。一方で、認定資格本はその数倍の時間がかかります。それは、問題を考える手間が大きいからです。クラウドベンダーから試験範囲が提示されており、サンプル問題も出ています。我々はそれらの情報と、サービス単位の設計のベストプラクティスから、このサービスでは何を聞くべきか、と言うリストを作っています。そのリストの内容を見ながら問題形式にするのです。これは非常に時間がかかります。

作業分担を行う

最初に最も執筆に慣れた人、つまり経験者が1章を書くとよいでしょう。他の共著者はそれを真似て別の章を書きます。

モチベーションを維持する

仕事と同じく2週間に一度、進捗管理をします。執筆スケジュールは緩めに設定しますが、何もしないと何も進みません。

初校から脱稿までのプロセス

初稿までは2～3か月かかるのが普通です。ここが一番時間かかります。初稿とは例えばWordで書いた内容が商品のレイアウトで最初に出てくるイメージです。その後、修正が入って第二稿、さらに修正が入って第三稿と進みますが、それぞれの工程で、どんどん修正が収束していきます。初稿と第二稿の間が一番修正が大きいです。第二稿、第三稿と進むにつれて、修正期間は1か月、2週間というように短くなります。第三稿が終わり、念のため最終版を確認して脱稿となります。最終版はほぼ修正は入りません。

本屋で自分の写真を見る喜び

私のAWS書籍は顔写真が載っています。本屋に行きそれを見てにやりとするのです。以前、本屋で若い女性が私の本を手に取っていたので、これ、私の本ですと言ったところ、顔写真と見比べて、本人だと気づいてすごい驚いていました。