いよいよ明日、1/20（土）に「Amazon Web Services 業務システム設計・移行ガイド」が発売されます。先日、見本誌が届きました。元々、ピンクベースの表紙だったのですが、最終的には水色になったようです。（フロンターレ初タイトルの翌月に水色の本を出せるなんて！）
「技術書を書くこと」はエンジニアとしての夢のひとつだったので、見本誌を手にしたときは感慨深かったです。抑えておきたいAWSの基本から、業務で使えるアドバンストな内容まで、よりどりみどりな内容になっています。ぜひ読んでいただき、ご感想を頂けると嬉しいです。
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
- 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/01/20
- メディア: 単行本
- この商品を含むブログを見る
同時に、この感動を味わうためにも？２冊目、３冊目と技術書を継続して出せるようになりたい！と強く思いました。この記事では、
- 技術書の執筆を通して感じたこと
- 今後、技術書を書くために普段から心がけたいと思ったこと
を整理していきたいと思います。初めての技術書を書きたいと思っている方と、次に繋げていきたい未来の私向けのメモとなります。
反省点：技術書の執筆を通して感じたこと
技術のインプット＆アウトプットがまだまだ甘い
執筆者陣の得意な分野でパートを割り振ったこともあり、基本的には既に知っている内容を文章にしています。それでも文章にすると、細かい仕様や考え方が曖昧だな、と感じるシーンが多かったです。
執筆初期に、リーダーの佐々木さんから「30分で2,000文字で書けるはず！」と言われていたのですが、私は1時間で1,000文字も書けなかったと記憶しています。この原因として、AWSのドキュメントを読み直し、実環境で検証した上で文章にしていたことが挙げられます。もちろん実際の仕様・動きを確認することは重要なのですが、日頃のインプット＆アウトプットの質を挙げていればもっと効率的に進められたと感じました。（AWSさんのアップデートが早すぎる！のもあると思いますがｗ素晴らしいです。）
言語化することの難しさ
もうひとつペースが上がらなかった理由として、「読みやすい」＆「技術書向けの」文章を書くことの難しさが挙げられます。こちらの記事（ 【読書メモ】理科系の作文技術 - log4ketancho ）でも書きましたが、10くらいのポイントを抑えるだけで「読みやすい」＆「技術書向けの」文章にすることができました。実は、この本を読んで（＆佐々木さんの初回レビューをもらったあとに）、ほぼほぼ全部の文章を書き直しています（笑）次はそうならないようにしたいものです。
継続して書くことの難しさ
年明けから企画を始め、3~4月くらいから書き始めたのですが、なかなか上手く書くことができませんでした。個人コミットログを見ても分かるとおり、6-8月に集中していることが分かります。
この3ヶ月間は、休みの前の日は23時〜4時まで執筆していたので月80時間程度、夏休みのある8月は100時間以上は執筆に時間をかけていたと思います。次は、バランスよく継続して書いていきたいです。
7月頃からポモドーロ・テクニックを導入したのですがこれが非常に良かったです。有名な手法ではありますが、25分書いて、5分休んでを繰り返すというもので、私にはとても合っていました。仕事でも取り入れてます。1日1~2サイクルでいいので、毎日書くことを心がけたいと思いました。
改善点：普段から心がけようと思ったこと
日々、得た技術を言語化する
この執筆が、技術ブログを始めようと（再開しようと）思ったきっかけになりました。自分のインプット＆アウトプットを言語化することで、「なんとなく分かったつもりでいた」部分が見つかり、「え？こんな曖昧な状況で世の中に晒していいの？恥ずかしくない？」という想いが、自分の腹落ちに繋がると感じました。
そして、「読みやすい」＆「技術書向けの」文章を書く訓練にもなっているはずです。ブログに日頃まとめた内容を本にできる（オファーがくる？）と理想だと感じています。継続していきます。
「分からないこと」をそのままにしない
一部、上にも重複する内容＆2017年の振り返り（ 2017年ふりかえりとKPT - log4ketancho ）にも書いたのですが、「技術の徹底的な腹落ち」を心がけようと思います。業務やプライベートの開発で使った技術について、理解が及ばない部分を少しでも削れるような過ごし方をしていきます。
良い技術文章をたくさん読む
はてブで読みやすい文章の方をフォローして読むようにしています。特に技術ブログについては、言い回しを真似たりできないかなーと思いながら読むと、非常に学びが多いです。
技術書では、インフラエンジニアの教科書2 スキルアップに効く技術と知識 がとても読みやすいです。物理層の話など難しい内容も分かりやすく書かれています。文章の書き方を参考にさせていただこうと思っています。（最近、読み直してるので、こちらもまとめていきたいと思います。）また、毛色は違いますが、3分間DNS基礎講座 も、難しい内容を楽しく＆分かりやすく解説するという意味でためになる本です。（私のDNS周りの知識はこの本が全てと言っても過言ではありませんｗ）
（おまけ）「Amazon Web Services 業務システム設計・移行ガイド」で私の好きな章
と、反省点・改善点が多々ありましたが、私以外の優秀な執筆陣のレビュー、技術にも文章にも明るい編集者の方のおかげで、とても良い内容にできたと思います。本当に感謝しています。
最後に、宣伝も兼ねて、今回私が執筆させて頂いたパートで個人的に気に入っている章を紹介します。インフラの自動構築パターンについて書いた章で、CloudFormation の説明とベストプラクティスの紹介、OpsWorks と Beanstalk についても簡単に説明しています。
AWSを使うからには、APIで構築を自動化していくべきです。この章は、その触りとしてはもってこいだと思います。なかなか０を１にするのが大変だと思うので（私も最初はキツかったです。。）、そのご支援ができるようにサンプルコードを多めに紹介しています。最近、CloudFormation を使う機会が（プライベートで）多いのですが、実はこの章を頻繁に参照していますｗ
まとめ
「技術書を書く」という同じ夢を持つエンジニアの方に少しでも役に立つ記事になると幸いです。この本は、1/20(土)発売なので、Amazon は当日着？、書店さんにも遅くとも週明けには並べていただけるかと思います。ぜひお手に取っていただければ嬉しいです。
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
- 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/01/20
- メディア: 単行本
- この商品を含むブログを見る
先日、この本を「どんな人に」「どのように」読んでいただきたいかについても記事にしてみました。こちらも合わせて読んでいただければと思います。
