新入社員エンジニアリングマネージャーの入社1ヶ月の仕事

出戻りとして入社して1ヶ月が経ち、試用期間の1/3が終わろうとしています。

前回のエントリにも書きましたが、「技術グループ」というチームを横断した横串のエンジニア組織の専任エンジニアリングマネージャとして仕事を開始しました。

入社前に最初の1ヶ月でここまではやりたい、と思っていたことがおおよそできたような、少し届いていないような、そういう感覚です。

具体的になにをやったのかを、簡単に書いておこうと思います。

観察と情報収集

daiksy.hatenablog.jp

↑上記エントリでも書いたように、基本的には情報収集に最も時間を使いました。

毎朝30分CTOと1on1をし、目についた端からドキュメントを読みあさり、疑問があればまたCTOとの1on1で掘り下げる。主だったMTGを見学し、ひたすら観察する。こんな感じです。

エンジニア全員1on1

エンジニア組織専任のエンジニアリングマネージャとして仕事をするので、社内に会話をしたことがないエンジニアがいる、という状況で仕事をすべきではありません。

そこで、エンジニア全員との1on1を開始しました。

具体的な人数はここでは書きませんが、はてなでは従業員のおよそ半数がエンジニアです。全員1on1と言ってもかなりの人数と話をする必要があり、このエントリを書いている時点で4割ほどとの対話が終わりました。

来月中には終わってるといいな〜。というイメージで引き続き取り組みます。

これだけ大勢の人と対話をしていると、それぞれの開発チームに対して複数の視点から話を聞くことができるので、組織像がかなり立体的に浮かび上がります。

エンジニアリングマネージャとして、組織全体のおおよその地図を頭の中に描くためにも、これはやって良かったと今の時点ですでに思える活動です。

もう一つの目的としては、技術組織のエンジニアリングマネージャは、現場のエンジニアから見るとなんの仕事をするのかよくわからない人であろうと思います。そのため、一人ひとりに自分の仕事を説明して回りたい、という意図もあります。

バックログづくり

今後の技術グループの取り組みの手がかりとなる、バックログづくりに着手しました。

まずは、主だったメンバーで合宿を開催し、現状の課題や将来の展望などを話し合いました。

最終的にできあがったバックログのオーナーは自分です。合宿の内容を咀嚼しつつ、スクラムにおけるプロダクトオーナーがプロダクトバックログをつくる要領で、バックログアイテムを作成しました。

そのバックログアイテムに対して、重要度と困難さという2軸で重み付けをし、これに基づいて取り組む順番を決めていきます。重要で、すぐにできることは素早く取り掛かる、という具合にです。

このバックログの進捗状況をある程度オープンにしながら取り組んでいくことで、技術組織の業務を現場メンバーに理解してもらい、組織が進歩しているという実感を持ってもらいたいと思っています。

まもなくこのバックログがひととおり完成する予定なので、いよいよこれを手がかりにさまざまな問題や課題に取り組んでいこうと思っています。

入社直後の新任マネージャーの暮らし

今の会社に入社してから10営業日目を迎えました。

前回の転職のときにも書きましたが、マネージャーとしての転職は、他の職種とは違った難しさがあるのを実感する日々です。

マネージャーの仕事は、社内の人々からさまざまな期待をされる役割ですが、リモートワークということもあっていまいち何をしているのかみんなには伝わりづらい仕事です。そこで、毎日日報を書いたり、社内チャットの分報チャンネルにこまめに雑談も含めて吐き出したり、グループウェアに文章を書いたりしています。

このような入社直後のマネージャーの様子を、社内向けにグループウェアに投稿した文章をアレンジして書いておこうと思います。世の中の新任マネージャーの参考に少しでもなりますように。

どういう役割として入社したか

はてなでは、組織・基盤開発本部エンジニアリングマネージャーという役割をもって入社しました。

はてなは、はてなブログやMackerelなど複数のプロダクトを運用しており、それぞれに専門のチームがあります。各チームにはエンジニアやデザイナー、セールスなど、プロダクトを運用するために必要なさまざまな役割の人が所属します。

それとは別に、エンジニアやデザイナーといった専門職の場合、その職種の人々が横断的に所属する専門職グループがあります。いわゆるマトリクス型の組織です。

https://speakerdeck.com/hatena/engineers-recruitment

ぼくは、はてなのエンジニア全員が所属する技術グループの専任のエンジニアリングマネージャー(以下EM)として採用されました。はてなでは初めて設置されたポジションです。

今何を考えて仕事をしているか

入社して最初の仕事として、エンジニア全員との1on1を開始しましたが、まだまだはじまったばかり。

今は毎日CTOと1on1をして、いろいろなことを教わったり、まずは小さい仕事を受け取ったりしています。 技術グループのような組織横断的な集まりを支援するマネージャーの仕事は、人事や採用が重要です。前職でもそこは多く経験したところなので、こういった自分にとってやりやすいところから仕事をやりはじめています。

新しく就任したマネージャーは最初の100日間がとても重要だとよく言われます。アメリカ大統領は、最初の100日間でまずは短期的な成果を出して国民の信頼を得ることを意識するそうです。

ヤフーの元社長で、東京都の副知事である宮坂さんが次のような文を書いています。

note.com

ぼくが前職でマネージャーとして採用された最初の生活の様子を思い出すと、とても共感します。

daiksy.hatenablog.jp

要するに、自分が所属する組織のカルチャーを何も知らないうちから、戦略だのビジョンだのぶち上げるな。まずは観察に徹して文化を学べ、ということです。

新任マネージャーは基本的に自分が仕事をする環境について何も知りません。宮坂さんも「組織内で最も無能なのに最も期待される」状態だと書かれていますが、まさにそのとおりです。この状態のマネージャーは、仕事の手がかりを外にしか持っていません。何かしらの本に書かれていた一般的にベストプラクティスとされるもの。過去の組織での経験。などです。

これらを手がかりに、最初から大きなビジョンや戦略を描くとたぶんあまりうまくいきません。実際にそれでうまくいかなかった人を何人か知っています。

既存の組織の文化を知らずにビジョンを語っても、ただの現実と乖離した空虚な理想論にしかなりません。既存の組織を一度全部破壊して、ゼロから再構築するのだ、というミッションが自分にある場合のみ、それをやればよいのですが、それは自分がはてなでやりたいことではありません。

幸いぼくは出戻りなので、完全に新規に入社した人と比べると多少ははてなに対する理解を持っています。とはいえ3年のブランクをあまくみてはいけないと思っています。

このような考えから、最初の100日間。わかりやすく、試用期間の3ヶ月間と自分で定めているのですが、この期間はできるかぎり観察に徹しようと思っています。とはいえ、その間なにもしないというわけではなく、小さな成果を積み上げられるような仕事を中心に取り組んでいきたいです。

エンジニア全員1on1をやりはじめて、自分の技術グループに対する理解が少しずつ立体的になっているのを実感しています。 5月の末には、合宿を予定しており、そこで技術グループとしてのバックログをつくり、技術グループ専任EMとしてぼくがバックログのオーナーとなるつもりです。

このあたりが進み始めると、少しずつ技術グループEMとしてやるべきことが浮かび上がってくるかなと思っています。そうするとようやく所信表明などを展開できるようになりそうです。

短期的な小さな成果を積み上げながら、大きな成果は今の学習期間が落ち着いてからの、長距離走の中で出していきたいと思います。

アルムナイ採用体験記 (株式会社はてなに2回目の入社をしました)

2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。

2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。

一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。

最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。

基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。

戻ろうと思ったきっかけ

もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会があればまたはてなで働きたいな」というのはほんのり思っていました。

その後、具体的にはてなの選考を受けることになる最初のきっかけは、とある転職支援サイトでのスカウトでした。

前職での仕事が一区切りついて、転職を検討しはじめた最初に、いくつかの転職支援サイトの転職意向ステータスを変更しました。そのうちの1つで、ステータスを変更して1時間も経たないくらいのタイミングで、はてなからのスカウトを受けました。

スカウトをくれた人は、もちろん自分が過去にはてなで働いていることをご存知でしたし、自分もその方とは面識がありました。ただ、この時点ではまだ迷いのほうが大きく、具体的な話を聞くかどうかは迷っていました。

もともと働いていたことがある、とはいえ、戻りたいと表明して無条件に戻れるわけではありません。自分が活躍できるポジションが空いているか、その期の採用計画はどうなっているか、など通常の中途入社と同様のハードルが当然存在します。出戻りの場合は、それに加えてさらに変数が増えるのではないかと思います。端的に言えば、喧嘩別れした人を快く迎えられるかということ。もちろんそんなことはないでしょう。

自分は、円満に退職をしたつもりではいますが、実のところどうであるかはわかりません。

スカウトをいただいた、ということは少なくとも悪い印象は持たれてはいないだろうと思いましたが、それでも不安はありました。

ただ、はてなとは退職後もエンジニアコミュニティや、いろいろな企画で継続的に関わることも多く、こうしていろいろと接点を持ってくれるということは、大丈夫なのかもしれないな、という気持ちもありました。

そこで、退職後もたびたび連絡を取り合っていた親しい社内の人がいたので、応募する前にその人に相談することにしました。その方がぜひチャレンジしてみてください、と背中を押してくれたのが、最終的に選考に応募する決め手となりました。その後、その人の手引でカジュアル面談をセッティングしてもらい、そこでの会話の内容でさらに意向が高まり、通常の採用フローに入っていった、というのが一連の流れでした。

採用フローで注意したところ

いろいろな悩みを乗り越えて、いざ採用フォームから応募すると、ここからは通常の選考がはじまります。

自分としては、採用フローで特別扱いなどは決してせず、できれば通常よりも厳しめに見てほしいと伝えました。

自分の場合は2021年に退職してから、3年のブランクがあります。この3年間の成長(あるいは停滞?)が、入社後の期待値に大きく影響しており、最も入社後のギャップが生まれやすいポイントであるだろうと考えたからです。

よく知っている環境に戻り、同僚も自分のことをよく知っている。その状況でいざ仕事をはじめると、なにか思っていたのと少し違う...。この状況になってしまうことが自分にとって最も恐ろしいことでした。

特に自分の場合はマネージャとしての採用になるため、仕事の多くが目に見えづらい物事を扱う仕事となります。マネージャの採用で期待値にずれがあると、担当する組織全般に悪影響を及ぼします。通常の中途採用でも期待値を揃えることに細心の注意が必要な職種ですから、出戻りとなるとさらに慎重を期す必要があると考えました。

最終的に内定のオファーをいただいたあとも、その返事をする前に自分の入社後のイメージをドキュメントとして渡し、ギリギリまで期待値にずれがないかを確認しました。

入社後のあれこれ

いざ入社するにあたって最初に考えたことは、頭の中をいったんリセットしよう、ということでした。

3年の間に新しく入社した人も大勢いるため、出戻り感を出しすぎるとよくないことがたくさんあると思うからです。当然自分が知らないこともたくさんありますから、いったんはすべてリセットして、通常の中途入社の気持ちで仕事にあたろうと思いました。

いざ仕事をはじめてみると、自分が入社前に想像していた以上に忘れていることが多く、まったく勘も働かないため、普通にリセット状態でした。とはいえ油断せず初心の気持ちを心がけています。

他にもおもしろいエピソードとしてはこんな話も。

これは会社によってケースバイケースですが、業務に使用する各種アカウントなどが、新規作成ではなくサスペンドからの復帰、として扱えたものがいくつかありました。たとえばSlackの分報チャンネルであるtimes_daiksyはアーカイブから復帰できたので、3年前の投稿の続きから復帰できており、おもしろいです。

さいごに

自分は、今回社員としてはてなに出戻りをした第一号となりました。自分の近況を知ってくれた卒業生の皆さんの中には、「おっ」と思われた人もいらっしゃるかもしれません。

ちょっと気になるなぁという方は、自分が体験談も交えて相談相手になれるかなと思っていますので、お気軽にお声がけください。

中間管理職の仕事 - 情報伝達のアレンジ

自分がまさに中間管理職ど真ん中なので、中間管理職の仕事を可能な限り自分なりに言語化してみようと思い、ざっくばらんに思ったことを書いていく。

今回は、情報伝達について。

組織がコンパクトであれば、中間管理職など必要はない。トップの意思がダイレクトに末端までスムーズに伝わるからだ。 組織が大きくなるにつれ、情報の伝達はスムーズにいかなくなる。

帝人の元会長である安居祥策氏が、日本経済新聞に寄稿した記事で記した「√の法則」というものがある。

100人の社員に物事を理解してもらおうと思えば、√100=10 として10回同じ説明をする必要がある。 10,000人の社員が相手になれば、100回になる。

多くの人に自分の考えを理解してもらうためには、このくらい同じ説明を何度も繰り返す必要があるということだ。全社員が集まる集会で、1回説明すれば明日からすべての社員がそのように動く、ということはない。

これはあくまでも考えの目安であるが、だいたい直感とも一致する。

とはいえ、社長がいちいち同じ話を繰り返すのも効率が悪い。そこで、我らが中間管理職の登場となる。

社長が10人のマネージャーに説明をする。10人のマネージャーはそれぞれ10人の部下に同じ話をする。これを繰り返しながら、組織全体に情報を伝播するのだ。

しかし、間に立つ中間管理職は、右から左に情報を流すだけで良いだろうか?もちろんそんなことはない。それぞれの管理職が担当する部門は、それぞれ職種はバラバラで、役割も異なる。トップの意思を、自分が担当する部門の目的に応じてアレンジをして伝える必要がある。

中間管理職は、上からの指示を、自分の担当する仕事内容に応じてカスタマイズして扱う必要があるということだ。

では、中間管理職が、自分の裁量で情報をカスタマイズするには、なにを手がかりにすればよいのか。カスタマイズの方向性をしくじると、トップの指示は歪んで伝わってしまう。

そこで重要なのが、その情報を伝達する「理由や目的」である。いわゆる「Whyからはじめよ」というやつである。

www.ted.com

少し極端な例を考えてみる。

トップから、ある目的を達成するために我が社ではA, B, Cの3つの施策を行う必要がある、という指示が出る。

エンジニアリング部門のマネージャーは、その目的を達成するためには自部門ではAとBに注力せねばならない。Cは自部門にとってそれほで重要ではないので、部下への指示は簡略化してよいと判断した。

セールス部門のマネージャーは、その目的から、Cに注力する必要があると判断し、AとBについては部下への伝達を簡略化した。

これが、情報伝達のアレンジである。

トップから、施策の目的が伝えられていない場合どうなるか。

マネージャーは、自らの裁量で情報をアレンジするてがかりを持たないため、上からの指示をそのまま現場に伝える。すると、エンジニアリング部門は本来気にする必要のないCにも力を割く必要があるし、セールス部門はAとBに余計なリソースを割くことになる。

要するに、現場としては本来やる必要のない無駄な仕事に忙殺されることになる。

現場からは当然クレームが出る。AとBをやる必要があるんですか? と。マネージャーはそれに対してメンバーに説明する術を持たない。マネージャーにできることは、まぁまぁと現場をなだめることくらいである。

この場合、マネージャーは自分の上長に「これをやる目的はなんですか?」と質問をしているかもしれない。しかし巨大な組織で、上長からも要領を得ない回答がきてしまうとお手上げである。

つまり、中間管理職が情報伝達という仕事を十分にやりとげるためには、トップの情報の中のWhyの部分が最も重要となる。それがあってはじめて、自部門になにを期待されており、自部門はどういうアウトカム、あるいはアウトプットを出せばよいのか、という期待が揃うことになる。

自分がなんのためにその仕事をしているのか、中間管理職として、これを常に説明できる状態にしておけるように振る舞いたい。

2023年のふりかえり

毎年恒例のふりかえりです。

去年はこんな感じでした。

daiksy.hatenablog.jp

今年の一番のハイライトはなんといっても単著を出せたことでした。

顛末などは以下のエントリに詳しいです。

daiksy.hatenablog.jp

著者としての制作の大半は去年のうちに終わっていましたので、あまり今年の出来事であるという感覚が薄いのですが、それでも出版当日はとても嬉しく、書店めぐりをしました。

それでは月ごとにふりかえっていきます。

1月

RSGTに登壇しました。といっても自分のプロポーザルが採択されたわけではなく、kyon_mmさんのサポートとしてDJ(?)をしました。

daiksy.hatenablog.jp

FLEXYさん主催のイベントに登壇しました。

flexy.connpass.com

2月

3月に公開される記事の取材を受けていました。

3月

スクラムフェス福岡に登壇しました。

speakerdeck.com

アジャイルリーダーシップについて、ユーザベースの皆さんと対談させていただきました。 agilejourney.uzabase.com

4月

ふりかえりカンファレンスでLTをしました。

speakerdeck.com

5月

Scrum Incさんにお声がけいただき、ある会社さんむけのScrum@Scale研修でゲスト講師としてお手伝いしました。

7月

Software Design誌の8月号に寄稿しました gihyo.jp

8月

著書が発売されました。ちょうど、夏休みの北海道旅行の最中に発売のお知らせが出て、友人が運転するレンタカーの後部座席でひたすらエゴサーチをしていました。

SD誌の寄稿記事をテーマにしたウェビナーにお招きいただきました。 www.agile-studio.jp

9月

Scrum IncさんのScrum@Scale研修にゲスト講師としてお招きいただきました。

その後、WEB+DB Press休刊のパーティに著者枠で参加予定だったのですが、台風により参加を断念しました...。

daiksy.hatenablog.jp

アジャイルラジオに出演しました。

agileradio.github.io

agileradio.github.io

agileradio.github.io

自著について、平鍋さんにインタビューしていただきました。

www.agile-studio.jp

10月

自著の読書会が開催されると聞きつけ、参加しました。

agiletechexpo.connpass.com

自著をテーマにしたウェビナーを企画していただき、出演しました。

www.agile-studio.jp

11月

CSP-SM研修を受講し、資格を取得しました。

12月

KDDIアジャイル開発センターさんの社内勉強会にお招きいただきました。

note.com

まとめ

今年はありがたいことに、自著に関するイベントに多くお声がけいただきました。 会社の仕事では、今年は採用にとても大きくパワーをつかった1年であり、採用難易度の高いポジションで多くの人に来ていただくことができました。

身の回りで少しいろいろとあり、来年のことはまだあまり考えられていないのですが、少し大きい新しいチャレンジをしたいなと思っています。

2024年もどうぞよろしくお願いします。

WEB+DB PRESSの思い出 #wdpress #wdpress_party

書くぞ!!!!!!!

WEB+DB PRESSには過去何度か記事を書かせていただき、その流れで著書まで出していただくことになり、自分の人生に大きな影響を与えてくれた雑誌でした。

22.9周年パーティにはぜひとも参加したく、申し込み開始にあわせていち早く登録に成功し、著者枠として参加予定で、前日から東京に行っていました。

ですが、運悪く台風13号の進路が怪しくなり、翌日の午前中には家に帰っておきたい事情もあり、安全をとって旅程を変更して、キャンセルすることになりました...。このときほど自分の雨男を呪ったことはありません。*1

パーティに参加することはできませんでしたが、なにか少しでもこの機会に気持ちを残しておきたいと思いましたので、思い出など書いてみようと思います。

はじめて、WEB+DB PRESSの編集部と接点を持つことになったのは、2015年でした。

当時、ScalaMatsuri 2016のスタッフをやっており、自分は広報担当として、プレスリリースやブログ記事執筆などを担当していました。そのとき、WEB+DB PRESS誌にイベントレポートを掲載したい、という打診が編集部からあり、そのプレス対応などをしたことが最初のきっかけでした。

その後、Scala関西サミット2016にスタッフとして参加した際、このイベントもレポートを掲載してもらえないかと、ScalaMatsuriを取材してくださった編集者さんに自分から企画を持ち込み、その企画が通ったのが、自分の最初のWEB+DB PRESSでの執筆デビューです。

WEB+DB PRESS vol.96に掲載されました。

gihyo.jp

そこから、Scala関西サミットやScalaMatsuriのスタッフを何年か継続し、その度にイベントレポートの企画を持ち込んでは掲載してもらう、という期間が数年ありました。

その後、デブサミ2020の登壇をきっかけに特集記事を単独で書いたり、そこからさらり単著へと繋がったりするという縁が続きました。

daiksy.hatenablog.jp

daiksy.hatenablog.jp

こうして考えてみると、ScalaMatsuri -> Scala関西サミット -> デブサミ -> 特集記事 -> 著書 の流れはまさに自分のキャリアの変遷の過程に都度WEB+DB PRESSとの接点があった、という気がします。

自分の著書が、WEB+DB PRESS PlusシリーズとしてWEB+DB PRESS休刊最後の号の翌日に発売日であったのも、偶然ではありますがなにか縁を感じます。

今後も不定期で継続の予定であるということですので、引き続き縁が続けばよいな、と思っています。

単著の執筆はとてもたいへんで、書いている最中は二度とやりたくないと思っていましたが、喉元を過ぎて今は「もう1回くらいやってみたいな」という気持ちも芽生えていますので、どうぞよろしくお願いします。

*1:高速道路の中央分離帯のこちら側だけ豪雨。ソフトボールで3打席連続にわか雨。北海道に旅行に行く度になぜか台風とチキンレース。などの経験があります。

Scrum@Scaleの日本語書籍を出版します & 執筆の様子の記録

実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。

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年に制作が再開。このたび無事に発売となりました。

この本が皆さんのお仕事の現場に少しでもお役に立てるなら、書いた甲斐がありました。感想などぜひお聞かせください。