共著「AWS運用入門」が2024年「技術書部門ベスト10」に選出されるまで

記事タイトルとURLをコピーする

マネージドサービス部 佐竹です。
めでたいことに、共著「AWS運用入門 押さえておきたいAWSの基本と運用ノウハウ」が2024年「技術書部門ベスト10」に選出されましたので、発売に至るまでを振り返ってみたいと思います。

事の発端

事の発端は、2021年8月4日に出版元である「SBクリエイティブ株式会社」様から私の個人メールアドレス宛にご連絡を頂いたことでした。

【ご執筆のお願い】というご連絡を頂く

私の個人メールアドレスは某ビジネス向け SNS のプロフィール欄に記載していることから、稀にスカウトのメールが来ることがありましたが、本の執筆依頼は初めてでした。

メール本文からも真剣さが感じられる内容でしたので、「何かできることはないか」と考えて連絡を取ってみることにしました。

最初は会社で受けるつもりが…

一旦会社に連絡して欲しいとレス

当時私はマネージドサービス部ではなく、運用監視の専門家でもありませんので「サーバーワークスのマネージドサービス部で本を執筆してみたい人がいたら、誰かが受けるかもな~」と思って上記のようなレスをしました。

上司との Slack 上での会話(原文ママ)

私の上司に「個人で受ける余裕はマジでない…」というひっ迫した負荷と共に会社で受けるような方向で考えていたのですが。

経営陣を含めてちょいと意見を貰った結果として、個人宛に来た話ということもあり、以下の通りになりました。

  • 私個人が副業として受けて対応するのは OK
  • その時に「サーバーワークス」の名前を出すのも OK。むしろありがたい

また、作業のために社内のツールをある程度そのまま使っても良いことになりました。

具体的には会社のメールアドレスを使っての出版社とのやり取り、資料アップロードのための Box の利用、Meet での会議あたりです。ツールを自前で準備するのは少々手間だなと思っていたので、使い慣れているツールがそのまま利用できたのはありがたかったです。

余談ですが、弊社には「執筆活動に関するガイドライン」という社内コンテンツがまとまっており、今回のような執筆活動を行う前には本情報が参考になります。

プロジェクトとしてメンバーを募集する

副業的に本を執筆しても良いことになったのですが、問題は2つ。

  1. 一緒に執筆してくれる人を自分で探さないといけない
  2. 私の業務の負荷が高いため、オフで本を執筆する余裕がない

一緒に執筆してくれる人を探す

まずこれは「興味ある人いますか」と社内 Slack でざっくり聞いてみたところ、そこそこの人が「本を出せる」ということに興味を持ってくれたようでして、ある程度の人数の反応を得ることができました。さすが、アンテナの高い弊社社員のエンジニアです。

ただ「実際に時間を割いて文章を書く」というのは「やってみたい」というような気持ちでは到底なし得ないもので、申し訳ないのですが「本当にやってくれそうだ」という意気込みまで持っている方は極わずかそうでした。

ということで色々会話した結果、最初の1人として山﨑 翔平さんに手伝っていただけることになりました。

私の 22:55 の書き込みに 23:38 にレスする山﨑さん

山﨑さんは最初のメンバー募集の時に最速でレスをくださった方でもあります(速い)。

山﨑さんは若手ではあるのですが、当時 AWS Organizations をゼロから構築する超大型の案件を一緒に担当していたこともあり、仕事ぶりの信頼度が非常に高い方です。ですので、山﨑さんの参戦でほぼ勝ちは確定したも同然だったのですが、まだ問題は残っています。

依頼されている範囲の本を期限までに書き上げるには「到底2人だけで書き上げられるボリュームではない」のがわかっていました。そして私は業務的にあまり戦力になれそうもありませんでした。

ですので、私はさらに2名を捕まえてきました。それが小倉 大さんと、峯 侑資さんです。

小倉さんの最初の反応

小倉さんは私と同様「忙しくて手が回らないかもしれないが関わってみたい」ということをおっしゃっていました。

小倉さんは AWS における運用監視業務をメインとした業務経験も数年あり、サーバーワークスでは「講師」を務めていらっしゃることから、今回のようなプロジェクトに非常に向いていると感じていたので「是非、何とかちょっとでも助けてほしい」と思ってお願いしました。

そして峯さんはサーバーワークスに2017年4月に新卒入社したメンバーです。2021年の当時は入社5年目でした。

4人の中で最も若いメンバーになりますが、私と一緒に長らく働いていたので信頼のおけるメンバーでした。非常に優秀だったので、ヘルプとしてレンタルしていた課から引き抜いて私の課に異動させたこともあったくらいです(実話)。

私がいろんなツテでメンバーを集めているときの呼びかけ

そんな峯さんは私の上記書き込みに対して以下のレスをくださりました。

まさかの73秒後にレスを投稿する峯さん

「印税」…。その響きにやられた峯さんが揃い、これで4名になりました。

ということで、著者4名が揃ったのが2021年の12月末でした。

私の業務の負荷が高い

どうしようもない話ですが、私は複数の顧客を担当しながら、社内のプロジェクトでも主担当のものがあり工数は常にひっ迫していました。

そのため、「SBクリエイティブ」さんにも最初から「負荷が高いので対応が難しい」旨を伝えてありました。

そう、私はプロジェクトマネージャーとして管理だけをして「一切の執筆をしない(レビューはする)」ことで乗り切ろうとしたのです。

といってもこの見積もりは甘かったのですが・・・

プロジェクトが開始してから

印税の配分について

お金の話は4人全員が集まった2021年12月21日に最初に記載した

お金のことで不公平感が出ないように「出来高払い」みたいな形にしました。これについては特に揉めることもありませんでした。

私個人で話を頂いたため、私がいなかったらそもそも本プロジェクトもありませんでした。ということで、ここは私が決めさせてもらいました。

最後はある程度この法則に則って山﨑さんに計算していただき、その数字で確定させました。

ドラフト版を書くだけで大変だと気付く

「一切の執筆をしない(レビューはする)」ことで乗り切ろうと考えていたのですが、最初に本の「ドラフト版」を全員で2022年1月末までに記載することになったので参加しました。

他の3名に分担を決めてもらった結果、私の範囲はかなり狭かったのですが、それでも業務負荷と相まってだいぶ無理が極まっておりました。

というのと、私は本を書くのは性格的に向いてなさそうだと何となく感じたりしました。こういう風にブログを気楽に書くことや、卒業論文みたいなものを書くのは嫌いではないのですが、本という媒体のクオリティで記載しようとするとかなり大変で、精神的にも辛い部分が出てしまい「執筆作業は想定以上に厳しい作業だ」ことが理解できました。慣れたらもうちょっと気楽にできるようになるかもしれませんが、当時は厳しさを目の当たりにした気分でした。

これと同時期、年末年始には毎年のように AWS 資格試験の期限がいくつか来てしまうので、全冠エンジニアとしてこれを失効させずに更新するのも大変でした。

峯先生がやたらと積極的で助かる

お互いの範囲をカバーし合いながら進めていることが伺えますが、本執筆プロジェクトは結果的に山﨑さんと峯さんの2名が完全に主力でした。

章題が確定しない

頂いたお話から「どういう本にしたいか」を全員で決めるのにも一苦労があったのですが、もっと大変だったのが「章題」です。

章題は「本の流れ」そのものであり、書き始める前にはある程度決めなければなりません。これは納品物のドキュメンテーションでもそうです。

内部で章のあり方について会話する

「AWS 運用」という本筋は変わらないものの、このように順番は途中で何度も前後しました。

PM を山﨑さんにお任せする

忙しさを理由に、SB クリエイティブさんとの定例にすら出られなくなった私に代わり、(想定通り)山﨑さんが自主的に PM をやってくださりました。

そして当時一番時間が取れた峯さんが執筆作業を主体的にこなすことで、執筆作業は進んでいきました。

私はこういう感じのフォローをしたりしていました

途中で峯さんが退職する

2021年12月から本格的に始まった執筆作業の途中で、峯さんが転職されサーバーワークスを去られました。

このため、峯さんはサーバーワークスのドメインが利用できなくなってしまい、結果的に個人のメールアドレスでやり取りすることになりました。

我々3名は Slack で過去ログ全てを追えますが、峯さんがこれを見れなくなったのは少しプロジェクトの効率を悪化させた感がありました。

ただ、Box は出版社側の Box を利用することになっていたため、大きな問題は起きなかった記憶です。

絵を大量に用意するのが大変

私が記載したサンプルの挿絵

「わかりやすさ」に「構成図(絵)」は欠かせません。「初心者」には絶対に絵が大量にあった方が良いと感じました。

今回、構成図やイラストは、SB クリエイティブさん側で綺麗にし直してくださるということでしたので、ある程度が分かるレベルの絵を記載すればよかったのですが、AWS の構成図ではそうはいきません。

文字と同じくらい、絵を用意するのも大変でした。

執筆途中で AWS アップデートの影響を受ける

執筆期間が1年にも及ぶと、その間に様々なアップデートが AWS 側で行われることになります。

これにより、執筆中の内容に大きな変更を余儀なくされる場合があります。例えば EC2 インスタンスの種類が増えるだけでも「インスタンスの種類は約何種類あります」の数が繰り上がってしまい変わってくる場合があります。

またアップデートにより画面が大幅に変わってしまうこともあります。例えば、Cost Explorer はベスト5までしか閲覧できなかったのが、ベスト9まで表示できるようになっただけでなく、色まで完全に変わってしまいました。

blog.serverworks.co.jp

これについては上記ブログで取り上げています。

画面キャプチャのマスクが大変

先に記載したようにAWS のコンソール画面は日々変更されます。

そのため書いた内容に齟齬が出る、イチから全てのコンソールの画面キャプチャを撮り直す必要が出る、のような事態が各担当箇所で発生しました。

画面キャプチャには「伏せたい情報(例:AWS アカウント ID)」も掲載されているため、それにマスクをかけるのもやり直しになります。これも大変な作業でした。

章題を変えると参照がズレて大変

仮決定した「章題」が後で変更され、その順序が前後したことで、本文にある「こちらを参照」と挿入されている数字がズレてしまうことがありました。

これを後から全部チェックして合わせるのはただの作業と言えばそうなのですが、今回は本が 500 ページにも及ぶため、その対応もハードなものとなっていました。

2022年の半ばから私個人の体調が終わる

詳細は割愛しますが、諸々の負荷と出張などが重なって睡眠サイクルが安定しなくなってしまい、執筆活動も諸々ギブアップ気味でした。

これも余談ですが、アメリカ出張についてはこちらにまとめておりますのでよろしければご覧ください。

sabawaku.serverworks.co.jp

ギブアップ気味でもなんとか最低限やれることをやった、と言いたいところですが、本プロジェクトメンバーには迷惑をかけました。

コスト最適化の章を担当した

「一切の執筆をしない」と見積もっていたのですが、最終的には私も執筆をしています。「ここは佐竹さんしか書けないので」ということになったため、筆を取ることにしました。

そんな私が担当した箇所は「コスト最適化」の章です。完成までに山﨑さんによる修正は施されているところもありますが、途中まではそのまま私の文章100%です。この章の中で山﨑さんが記載された箇所についても、私が一字一句ニュアンス含めた詳細な指摘を行って改善に改善を重ねましたので、クオリティは保証します。

この中には、私が「何年も前から伝えたかったこと」を AWS エンタープライズ企業様担当の目線から書き下ろしましたので、ここだけでも目を通してもらえたら嬉しいです*1

それでも本が全て書きあがって出版されました

最終的に、本が全て書きあがって無事出版までこぎ着けたのは、間違いなく山﨑さんと峯さんと小倉さんの頑張りのおかげです!

いや本当によく、リリースできたと今でも思います。SBクリエイティブさんにもご心配をおかけしました。

完成した本の分厚さに著者らもビビる

3月24日に献本が手元に届く

「AWS運用入門」は「分厚い」と少し話題になったのですが、約 500 ページのボリュームは著者らにとっても想像以上の厚みで、初心者が手に取るのか少々不安になっていました。

結果的にこの厚さについては杞憂であり、むしろこの厚みが好評でもあるようでした。

本屋で見かけたときに思わず写真撮影

自分の本が並んでいると思わず写真を撮ってしまうは、あるあるだと思いますが私も撮影してしまいました。

発売当初、本屋にいくと平積みされていました

技術書部門ベスト10に選出

そして2024年にITエンジニア本大賞でまさかの「技術書部門ベスト10」に選出されるとは思ってもみませんでした。

www.shoeisha.co.jp

こちらのサイトで掲載されております。

記念の画面キャプチャ

栄えある大賞は「2月15日(木) のデブサミ 2024 内で行われるプレゼン大会にて決まる」とのことで、まだ明らかになってないですが、ベスト10に選ばれただけでめでたいことには変わりありません!

執筆者の宣伝効果もあり

山﨑さんと小倉さんは、X(Twitter)での告知等も積極的に行ってくださりました。

このあたりの活動にも感謝しかありません。

重版時の大変さ

山﨑さんの Post の通り、ありがたいことに「AWS運用入門」は重版を何度か頂くことになりました。

そして、本の重版時には著者が内容に訂正を入れることができるのですが、AWS の場合「訂正をする」というかは「アップデートで重要なものを差し込まないといけない」ということになってしまいます。

このため、特に山﨑さんは全ての AWS アップデートを常に追いかけており、さらに「AWS運用入門」の重版時の訂正(追記)に備えています*2

AWS はアップデートが多く、最新技術がすぐに様変わりする世界ではありますが、この本が可能な限り生き長らえてくれるよう著者側でもこのような取り組みをもって継続した修正に取り組んでいます。

ちなみに最近私がコスト最適化の目線で「震えた AWS アップデート」はこちらです。

blog.serverworks.co.jp

本書のカバーデザインに関して

カバーデザインは SB クリエイティブさんにお任せでした。

大野文彰さんに描いていただいていたようです。ありがとうございます。

最後にまたお金の話

諸々の事情と私の希望により、今回印税を辞退し他メンバーへ譲渡することにしたのですが、その時に「著作権を(代表として)山﨑さんに譲渡する」という契約が必要なことを知りました。

その場合に「私が契約書にハンコを押して」その後「山﨑さんがハンコを押して」最後に「出版社に返送」という流れが必要でした。

これが出版ギリギリのタイミングで連絡がきたので、速達で急いで出したのを覚えています。なかなかレアケースですが、いい勉強になりました。

〆にあたって

この本は「AWS における運用とは何か」という点にフォーカスした内容から始まっています。

これが「Chapter 1 システム運用の全体像」と「Chapter 2 AWSとクラウド」で語られます。正直、この2つの章を読むだけでもかなり価値が高い内容になっています。まずは試し読みで構いません、読んでみてください。

システムは「作って終わり」ではありません。システムの生涯は、そのほとんどが「作ってからの運用」で成り立ちます。システムでは「運用こそが本質」と言っても良いのです。いえ「運用こそが本質と言うべき」でしょう。

IT の世界では「DevOps」という概念がバズワードとなったあたりから運用にも目線が移ってきたと記憶しているのですが、それでもまだまだ意識としては十分ではないでしょう。今こそ AWS、そして今こそ「運用」です。

運用を蔑ろにしたシステムに明るい未来はありません。2010年から AWS を業務利用してきた私が言うのだから、間違いありません。

取り返しのつかない事態になる前に、運用目線を持ってください。運用目線を持った方がシステムを設計してくださるなら、全く違う世界が待っているでしょう。

この本がきっかけで何か世界が変わるとは思っていませんが、日本の IT 業界に「AWS における運用の必要性」を少しでも広められたなら嬉しく思います。

追伸

よろしければ本を買って応援してください!

自立する分厚さの「AWS運用入門」※初版

執筆時から「仕事中に辞書のように参照する」という使い方を想定しているため、紙媒体が強くおすすめです*3

では、またお会いしましょう。

*1:本に掲載されている内容は、エンジニアブログにも書いていない、オリジナルの内容になっています

*2:私は業務上コストやセキュリティのアップデートに特化して追いかけています

*3:私も自腹で買ってお客様に渡したりしています

佐竹 陽一 (Yoichi Satake) サバワクブログの記事一覧はコチラ

マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。