実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。
Scrum@Scaleの解説書で、全編書き下ろしです。
紆余曲折があり編集者さんに本を書きませんか、と打診いただいてから2年半ほどの大仕事でした。
Scrum@Scaleについてまとまった日本語の書籍は他にはなく、複数のスクラムチームで仕事をされている現場の大きな手がかりとなるはずであると自負しています。ぜひお手にとってみてください。
書籍の内容について
本書はぼくが現職でScrum@Scaleを導入した際の知見を惜しみなく注ぎました。全7章の構成です。
第1章 スクラムのスケーリングと大規模の難しさ
アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうすればいいですか？」と尋ねると、十中八九「スケールしてはいけません」と回答が返ってくるでしょう。ぼくもそう答えます。
この章では、組織のスケールはそもそも難しいということを説明します。それでもどうしてもスケールする必要がある、という場合のみスケールに取り組んでほしいからです。
また、Scrum@Scale以外のスケーリングの手法についても簡単に触れています。
第2章 スクラムのおさらい
ここではスクラムガイドをベースにスクラムの簡単なおさらいを書きました。すでにスクラムを習熟している人は読み飛ばして問題ありません。
第3章 とあるチームのScrum@Scaleでの1スプリント
具体的な解説に入る前に、ある架空のゲーム開発チームがScrum@Scaleで仕事をしている様子をストーリー仕立てで紹介します。ここで実際の仕事の様子を把握してから、それぞれのプラクティスなどの解説をしたほうが、理解がしやすいと思ったからです。
ストーリー仕立てではありますが、本書はあくまでも解説書ですから、過度に小説のような仕立てにはならないように注意しました。ですから最低限、解説書としての読み心地は損ねていないと思っています。
第4章 スクラムマスターサイクルとプロダクトオーナーサイクル
第5章 Scrum@Scaleを形成する12のコンポーネント
ここからScrum@Scaleの解説に入ります。 4章と5章はScrum@Scaleの公式ガイドをさらに深く掘り下げる構成としています。
公式ガイドを読んだことがない人でも、この2つの章を読むことでガイドと同じ知識が身につきます。また、公式ガイドをすでに読んでいる人も、それぞれのトピックをさらに深く具体的に掘り下げていますので、実践の手がかりとしやすくなっています。
第6章 現場へどのように導入していくか
ここからは実践編です。ぼくの経験をもとに、Scrum@Scaleの現場への導入手順を探っていきます。
第7章 Scrum@Scaleで運用される現場 チャットサービスの開発現場の場合
最後の章はより具体的な実践例の紹介です。ぼくがScrum@Scaleを導入した実際の現場の様子を、その現場のコンテキストとあわせて説明しています。
直接みなさんの現場の参考にはならないでしょうが、導入背景とあわせて解説していますから、Scrum@Scaleを現場に適用する際の考え方の補助になるだろうと思っています。
出版の経緯
ここからは、出版の経緯や苦労話を書いていきます。単著の制作は想像を遥かに超えて過酷で、何度も心が折れそうになりました。その度に、他の著者の経験談が書かれたブログなどを読み、「たいへんなのは自分だけじゃないんだ」と心の支えとしていました。ですので、後の世で書籍制作で苦労している人と体験談を共有する目的で、ここからは自分の執筆の様子を残しておきます。
今回の書籍制作の最初は、2020年2月にまで遡ります。
この年のDevelopers Summit 2020での講演を技術評論社の編集者さんが見てくださっていて、ぜひこの講演をテーマにWEB+DB Press誌で特集記事を書きませんかとお声がけいただきました。
その後、この企画はいろいろとあって、最終的に2020年10月にWEB+DB Press vol.119にて、「インフラ障害対応演習」という25ページの特集記事となりました。
daiksy.hatenablog.jp
この特集記事がとても好評で、その後編集者さんから書籍化を打診してもらいました。これが企画のはじまりです。
当初はこの特集記事を膨らませることで書籍化する、ということだったのですが、翌年の2021年に、当時勤めていた会社を退職することになりました。この「障害対応演習」は当時勤めていた会社での取り組みをまとめたものでしたので、退職によってこの企画をそのまま進めることは不可能になり、編集者さんに一度お断りの連絡を入れました。
その後、2021年5月に今の会社に入社し、転職のご挨拶を編集者さんに差し上げたところ「次の会社での取り組みを書籍にしませんか？」というありがたい申し出をいただきました。
新しい会社では「アジャイルコーチとしてScrum@Scaleの導入を促進する」というミッションが自分に与えられており、これがうまく成功すれば、この体験をあわせて書籍化できるかもしれない、と考え、その旨を編集者さんに伝え、少し時期を待っていただくことになりました。
その後、会社での取り組みにある程度成果が出た時点で、編集者さんと企画書の作成に取り組みました。
手元のログでは、2021年11月15日から具体的な企画書を作り始め、その後12月27日に技術評論社さんの企画会議を通過したという連絡をもらっています。この間には何度か担当編集者さんや、企画会議からのフィードバックを受けた手直しもしています。
企画会議通過の連絡をうけて、翌年の2022年の1月から、具体的な執筆がはじまりました。
もともとWEB+DB Press誌で25ページの特集記事を書いた経験がありますから、今回もその延長でなんとかなるだろう、と当初は甘い見通しでした。
企画書時点での見積もりは、全7章で175ページ(1ページあたり800文字)でした。構成の細部は結果的には少し変更になったところもありますが、おおよそ当初見積もりどおりの構成とページ数でゴールすることになります（ページ数は若干減りましたが）。
WEB+DB Press誌は1ページあたり1,200文字の計算ですから、1,200×25ページの30,000文字。1ページ800文字の書籍の換算だと37ページほどを1ヶ月で書いたことがある、というのが執筆に着手した時点での自分の経験でした。
見積もりが175ページだから、特集記事の執筆をおよそ5回分ほど繰り返せば書き終わるから、そんなに無理な仕事ではないな、というのが当初の自分の感覚でした。
いざ蓋を開けてみると、そんなに甘いものではありませんでした。雑誌記事は締め切りも明確ですし、どんなに大変でも1ヶ月ほどで終わります。いわば、今思えば短距離走的な執筆体験でした。書籍執筆は、企画書提出の時点で7ヶ月ほどで書き上げ、その後2ヶ月レビュー期間を置く、という計画でした。7ヶ月間一定のリズムで一冊の本を書き続ける。この長距離走的な執筆体験は、想像以上に過酷でした。
ぼくは自称アジャイルコーチですし、スクラムについての書籍を書くわけですから、進捗管理は状況を常に編集者さんと共有しつつ、しっかりやろうと考えました。スクラムの三本柱の1つ透明性です。
書籍執筆の進捗をどのように測るのか、いろいろと考えましたが、今回は「文字数」を使うことにしました。
とても大雑把なものではありますが、企画書時点での見積もりは175ページでした。数字の根拠は特に無く、企画書を作成する際には目次も詳細に作るのですが、その目次の項目1つに対してだいたい何ページくらいであるか、というのを考え、それを積み上げています。実際に書き始めると、企画書時点の目次からどんどん内容は変わっていくのですが、とはいえ大筋にはこの目次が書籍全体のガードレール的な役割を果たすため、充分にこの見積もりの数字は進捗管理として使えると考えました。スクラムにおいて、プロダクトバックログアイテムにつけるストーリーポイントのようなものです。
1ページ800文字ですから、この本は最終的に175ページ×800文字で140,000文字書き終えると、制作が終わる見積もりになります。自分の進捗は、週末ごとに原稿のマークダウンファイルに対するwcコマンドの数字をプロットすることで、週ごとに何文字進捗したかという形で記録しました。書籍では、図も必要になります。図は自分で手書きで書いたものを最終的に編集部できれいにして掲載してくれます。図は1枚あたり400文字相当として雑に計算しました。
この方式で以下のようなバーンアップチャートを作成し、これを担当編集者さんと共有しました。
進捗共有のためのバーンアップチャート
当初は140,000文字の見積もりでしたが、実際はそれよりも手前ですべてのテーマを書き終えました。
理想線は毎週4,500文字ずつ書き終えた場合の推移。バッファは毎週3,700文字ずつ書いた場合の推移として置きました。これは、雑誌執筆のときに毎週5,000文字ずつ執筆することができた、という経験から出した数字です。雑誌のときは毎週5,000文字書けたのだから、それよりも少ない3,700~4,500文字くらいのペースだったら無理なく書けるだろうという見通しです。
バーンアップチャートにバッファを作ったのは結果としてうまくいきました。途中でしんどくなってサボることもあったのですが、バッファを食いつぶしそうになると焦りが出るのでそれを取り戻すモチベーションが働き、結果として当初の予定からそんなに大きく外れることなくゴールできました。
当初の見込みでは、この理想線とバッファの中間くらいを推移すれば良いな、と思っていたのですが、実際のバーンアップを見ていただくとわかるとおり、やはり人間というものはバッファがあればあるだけ食いつぶすのだな、というのを改めて実感することになりました...。
執筆日記
書籍執筆という、ひょっとしたら人生最初で最後かもしれない経験ですから、時々の自分の気持ちを残しておこうと思い、執筆日記をつけていました。進捗管理のために毎週末にその時点での文字数を記録していますから、そのタイミングで日記を書きました。
そのいくつかを抜粋して、紹介します。執筆の過酷な様子が伝わると幸いです...。
2022/01/10
「自分の知識にちょっと自信が持てない感じがして、とりあえずスクラムの本にたくさん目を通す。」
こういったアウトプットのクオリティは、そのアウトプット量の何倍ものインプットが必要になります。いざ書き始めてみると、どうも自分にはインプットが足りないのではないか、とだんだん心配になってきて、スクラムやアジャイルの蔵書を改めて読んだり、追加でたくさん購入したりしました。
その後、執筆期間中は自著のことが頭から離れず、自著に関連しない書籍はまったく頭に入ってこないため、アジャイルやスクラムに関するインプット以外は受け付けない体になりました。何を読んでいても、「これは自分の書籍の参考にはならないな。他をあたろう」という気持ちになり、執筆終盤はスクラムのことを考えるのがとても苦痛になっていました。執筆終了後、ようやく自著と関係のない書籍も気にせずに読めるようになり、精神的にも落ち着きました。
2022/01/17
「書きやすいところから書いていこう。2章から。」
前から順番に書いていこうとしたのですが、どうもうまく書けず、書きやすいと思うところから順番に書くことにしました。
2022/01/28
「スクラムのおさらい。なんかわざわざ自分が書くことか、という気持ちになってくる。いろんな本に書いてあることの焼き直しをやってるみたい。おさらいだからまぁそれでいいのか。」
2022/02/05
「独自性のある章を書いてやっと楽しくなってきた。ゲーム開発の現場を模した例示をしたいが、違和感がないかどうか専門家のアドバイスがほしい。(中略)ますだーさんに相談してみるか。」
スクラムのおさらいの章は書いていてちょっとしんどかったのですが、3章でオリジナルの内容を書き始めてようやく楽しくなりました。ここで登場するますだーさんとは@scrummasudarさんのことで、当時ゲーム会社でお仕事をされていたので相談することなり、本書のレビュワーさんのお一人となっていただきました。
2022/06/24
「ちょっとモチベが下がってたけど、冨樫義博が執筆してるのをみてがんばろうと思った」
ゴールデンウィークに頑張りすぎてしまい、6月は本当にやる気が出なくて、心が折れかけていました。まったく進捗の出ない週が続いていたのですが、HUNTERxHUNTERの連載再開の報せを見て、おれが筆を折っている場合ではないぞ！！！！ と本当にモチベーションが回復しました。
2022/08/11
「TJARの土井さんのゴールを見届けながら、ゴールした！！！！」
トランスジャパンアルプスレース(TJAR)という、日本アルプスを経由して日本を縦断する超人的なレースがあります。この年、土井さんという選手が歴史的な記録を打ち立ててゴールされたのですが、そのインスタライブを横目で見ながら、自分も執筆のゴールを迎えました。
その後
自分の執筆が終わったあと、2ヶ月間はレビュワーさんによるレビュー期間に入りました。とても多くの方に助けていただきました。
本書の謝辞の部分を引用しつつ、あらためてレビュワーの皆さんにはお礼を差し上げます。
吉羽龍太郎さん、大友聡之さん、和田圭介さん、児山直人さん、湯川正洋さん、遠藤良さん、dairappaさん、山根英次さん、中村洋さん。これらの皆さんは本書全体のレビューをしてくださいました。石毛琴恵さん、増田謙太郎さんは、第3章の架空のチームの活動に対して、ゲーム開発の現場としてよりリアリティが出るようなアドバイスをいただきました。北濱良章さん、tunemageさんは、本書の骨子として最初に書き終えた時点の第4章の感想をくださり、その後の執筆継続の励みになりました。藤井善隆さんには同僚として第7章のレビューをしていただきました。
特に吉羽さん(@ryuzee)さんには、書籍出版の先輩として内容以外にもさまざまなアドバイスをいただいたり、ノウハウを教えていただいたりしました。当初、レビューをお願いしていた人はもっと少なかったのですが、「レビュワーにも事情があり、みんなが書籍全体を見られるわけではないから、できるだけ多いほうが良い。10人は集めて」というアドバイスは本当にそのとおりで、おかげで本当に多様な視点からレビューをいただくことができました。
レビューはプロのアジャイル実践者たちに見ていただいたため、おそらく地球上でこの本のテーマに関して最も学びが深かったのは自分自身だったと思います。一人で書いていた頃に比べて相当量のインプットをいただき、このときに得た学びは書籍制作以外の実務の現場でも大いに役立っています。
書籍制作はすべてをGitHubで管理しているのですが、issueの総数は428件。このうちの大半はレビューのご指摘やアドバイスとして起票されたものです。多大なるお時間をいただき、本当にありがとうございます。
レビューとその反映が終わったのが2022年11月。ここから編集部での作業になります。編集部では自分の書籍以外にも、出版を控えている書籍がたくさんあるため、それらの出版日は編集部の事情で決まります。そういったことから、本書の制作はちょっとの間お休みの期間があり、2023年に制作が再開。このたび無事に発売となりました。
この本が皆さんのお仕事の現場に少しでもお役に立てるなら、書いた甲斐がありました。感想などぜひお聞かせください。
