この記事はCloudTech カレンダーの 25 日目です。
概要
2021年5月、元記事クラウドエンジニア(AWS)ロードマップ2021を書籍化するにあたり、「チームで共同執筆する」をテーマに、出版社を巻き込んで出版するまでの工程をまとめた記事です。
もしあなたがコミュニティのオーナーで、
チームを巻き込んでKindle本を出したりするときに役立つかもしれません。
振り返ると、思ったよりも「ウォーターフォール開発」っぽい感じでした。
本ができるまでの流れ
| フェーズ | ウォーターフォールで言うと |
|---|---|
| なにを書くか決める | 要件定義 |
| 目次を作る | 基本設計、詳細設計 |
| 担当を決める | 担当アサイン |
| 原稿を書く | 開発 |
| 原稿チェック | 単体テスト |
| 仮印刷チェック | ステージング環境で結合テスト |
| 最終チェック | 総合テスト |
| 印刷所に持ち込み | 本番環境デプロイ |
体制
| 担当 | 役割 | 人数 |
|---|---|---|
| オーナー | 言い出しっぺで全責任を負う | 1名 |
| PMチーム | プロジェクトの主体となるサブリーダー集団 | 8名 |
| 執筆者 | 実際に原稿を書く人 | 24名 |
| テクニカルレビュワー | 技術的なチェックを担当 | 3名 |
| 編集者 | マネージャー的にいろいろ | 1名 |
編集者の役割は大切なので、細かい調整が得意そうな人を専任にすべきです。 原稿のどの部分を削るか、目立たせるか、引用チェック、表紙の案、デザイナーとの調整、目次や索引の作成、プロジェクト推進などなどを担当します。
使用ツール（ほぼ無料。Notionのみ月5ドルくらい）
Googleドキュメント
Googleスプレッドシート
Notion
Google Meet
Slack
Adobe Acrobat Reader
はじめに
コミュニティのSlackで「書籍を出したいからプロジェクトキックオフメンバー募集します！」と発言。
手を上げてくれたのは7名*。1人ずつオンラインミーティングでキャラクターなどを把握。
* 後に8人に
7名は「PMチーム」として各章のマネジメントを担当してもらう。
簡単なスライドを作って概要を説明。
当初はKindle出版（無料配布）の予定でしたが、後に技術評論社から商業出版のお誘いがあったので全力で乗っかります。
なにを書くか決める - 要件定義
ここが一番大変。
PMチーム7名 + 編集者とタスク整理やコンセプトの再確認をする。
・この本を読むことで得られるメリットは何か？
・技術レベルはどの程度に設定するか？
・届けたい読者像はどんなものか？（ペルソナの設定）
・文章はどのような記載ルールとするか？
決定事項はNotionにまとめること。Slackだと流れてしまうので。
■実際のNotionのトップ画面
ペルソナ分析を元に、それがどの成果物に影響するのかマッピングをする。
チームで意識を合わせるため、可能な限り具体的にする。
数回会議を行い、「中級者向けのAWS技術書や記事を読めるようになり、自走できるようになるまでを手助けする書籍」にコンセプトを決定。
目次を作る - 基本設計、詳細設計
Googleスプレッドシートに目次構成を作成します。
- 執筆者 - 原稿を執筆する
- 担当PM - 執筆者の進捗や記載ルールに沿っているかをチェックする（2名体制）
- テクニカルレビュアー - 技術的なジャッジを行います
注意* 構成を手直ししたので実際の書籍の目次とは異なります
担当を決める - 担当アサイン
各項目の執筆者を再びSlackで募集します。
募集の際に執筆ルールなどをまとめたドキュメントを執筆者に連携します。
■実際の執筆にあたっての依頼ドキュメント（一部）
「ですます調」などライターズガイドを用意しましたが、実際にはあまりルールを気にせず筆を進めてもらい、後から手直しする方が進捗が良かったです。
なお、改めて目的意識共有のために「なぜこの本を作るのか？」というスライドを作成し、執筆依頼時に連携しました。
意思疎通のためには何か目に見えるものを作成するのが大切です。
原稿を書く - 開発
執筆はGoogleドキュメントを使い、出来上がった原稿や図表は章ごとのGoogleドライブのフォルダに格納してもらいます。
（なお、図表は出版社側で後工程で全て作り直すので、この段階では仮作成レベルで良いとのことでした。）
各章ごとにSlackチャンネルを作成し、執筆者と担当PMをアサインして各自で進めてもらうようにしました。
方針やトラブルがあればオーナーも議論に参加します。
■実際のSlack画面
余談ですが、この時に感じたチーム運営の方法論を簡単なスライドにまとめてみました。
原稿チェック - 単体テスト
原稿の指摘はGoogleドキュメントのコメントで行い、議論が発展しそうであればSlackのスレッドでやり取りするルールを設けました。
■実際の原稿
編集者から「経験上、原稿を事前公開しても売り上げはそれほど変わらなかったよ」の声を受け、SNSで一般レビュワーを募集し、仮完成の原稿公開を決定します。
ある程度チェックの目処がついた段階で募集を開始し、
100名以上の参加者が集まり各原稿に同じ流れでコメントを入れてもらいました。
仮印刷チェック - ステージング環境で結合テスト
編集者がPDFで仮印刷版を作成する。
Googoleドライブにアップし、コメント機能で指摘。
図表なども配置されレイアウトが整っているので、文字だけの段階より格段に誤字脱字等の指摘が目につくようになります。
仮印刷チェックはコミュニティメンバー1000名を巻き込みました。
最終チェック - 総合テスト
表紙や帯、奥付、目次など、印刷してOKの状態まで持っていく。
最終的な指摘があれば取り込み、編集者がPDFで印刷版を作成する。
ここでコードの記号が全角になっているミスに気づきました。電子版をコピペしたら動かなくなるところでした…危ない危ない。最後まで油断なりません。
印刷所に持ち込み - 本番環境デプロイ
無事に納期通りに完了しました。
気づき
パレートの法則がほぼ当てはまった
10名集めたら、必ず1〜2名はすごくやる気のある人が出てくる。
逆もまた然り。例外なく、とても不思議でした。
そのため、コミュニティ規模が大きいとやる気のある人も多くなるため、有利に進めるかと思われます。
イラストレーターは偉大
初学者向けの本なのでキャッチーなイラストが欲しい＆技術書典にあるような萌え絵の方が目を引くのではないか？との意見もあり、Twitterで2年くらい相互フォローの「AWSサービス擬人化イラストレーター」zeroさんにお願いすることに。
AWS愛を持ってイラスト制作をしていただきました。いい感じです。
ページ数制限により泣く泣くカット
AWSとは別にGitやVScodeなど各種ツールを紹介する項目もありましたが、ページ数の関係で泣く泣くカットが決定しました。
元々書籍と連動する特設Webサイト（確認テスト、動画解説を提供）を用意していたので、そちらのコンテンツとして提供する方針としました。
執筆にご尽力いただいた方には大変申し訳なかった…。
最後に
早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け。
If you want to go fast, go alone. If you want to go far, go together.
どれだけ知識を深めてもゴールが無いように、ITインフラ・クラウドの世界も学習に終わりはありません。
特にコンピューター界隈は、少し分野が違うだけで専門家の知識に到底及ばないものです。
私一人では達成できなかったことを「チーム執筆」は実現してくれました。
今回の書籍は、各参加者の得意分野が発揮され、苦手分野をカバーでき、クオリティの高いものになったと振り返ります。
この記事を通じてチーム執筆を目指す方の助けとなり、最終的にはIT業界のレベルアップに貢献できれば幸いです。