目次
オライリー初見ですよろしくお願いします
今回はこの前読んだ本の記録と感想を書きたいと思います。
読んだのは「Infrastructure as Code」という本です。
ついに私もオライリーデビュー…！
まず、この表紙のハゲワシがとても可愛いですよね！
鳥好きとしては大変テンションが上がります。
夜読んだまま寝落ちしてしまったとき、朝起きた時にハゲワシくんと目が合ってキュンとしたのをよく覚えています。
え、どうでもいい？
少し私自身の話をすると、今年7月頭に一念発起して「GitHub？なにそれおいしいの？」状態からモダンな Web アプリケーション開発の勉強を爆速（当社比）でし始めて約2か月半です。
その間は GitHub、Docker、Cloud を中心に勉強してきて、これから Terraform に挑戦しようとしていたところでした。
そのため個人的にはいいタイミングで読めたと思っておりますが、オライリーデビューには少し早すぎる気も…？
ということで、これから書いていく感想が頓珍漢な可能性が高いのですが、そこは温かい目で見て頂ければと思います。
読むときの条件
正直今の私のレベルではとても難しい本だったので、以下のような条件で読みました。
- 1週間で1冊全部読み切る
- 分からない箇所があっても読み進めることを優先する
完全に理解するのは今の段階では膨大な時間を要するので、毎度分からないところを調べていたらきりがないというのが正直なところです。
（仕事が終わってからプライベートの時間に勉強しているので、時間が思うように取れず…悔しい。）
もちろん1回読んで完全理解！がベストだと思うのですが、本はいつでも読み返すことができるので、大筋を把握することに重きを置きました。
結果的に 6日で読み通すことができたのですが、「分からなくても止まるな！」と自分を急かしてやっとという感じでしたね…。
この本はオライリー本の中でもまだページ数が少ないほうらしいので、他の分厚いオライリー本ではこの条件では私の場合は厳しいかもしれません。
もっと分厚いオライリー本をたくさん読破しているつよつよエンジニアの皆さんすごい…。
知識が増えてこういった本に読み慣れてくればもっと効率的に読めるのでしょうかね。
IT業界は時代の流れがはやいですから、いつか日本語訳される前の原本（英語）のまま読めるくらいになりたいです…！
感想
まず第一に読むのがとても難しかった！
知らない専門用語が多いのはもちろん、原文が英語のためか「自動テストやパイプラインをトリガリングするアクショナビリティが～」のような横文字も多く、そういった文章に慣れていない私はここに苦労しました。
途中から「ルー〇柴さん系の話し方をする人なんだ」と考えを切り替えたことで何とか読み切ることができましたが…。
技術ドキュメントに慣れるためにも、こういった文章をたくさん読んで練習しないとダメですね。
あと英語の勉強も…頑張ります。
文章自体の読みにくさはあったものの、著者の主張している内容は理解できるものでしたし、目から鱗な考えがたくさんあってとても勉強になりました。
まず、Infrastructure as Code を実現させる上で重要なキーワードは『統一性』『再現性』『反復可能性』のようです。
一貫して『人間の介在を最小限に抑え、無駄や不確かなものを減らす』という考えがベースにあると受け取りました。
当書で「鉄（物理ハードウェア）の時代とクラウドの時代」というコラムがあったのですが、 その鉄の時代に近い考え方の人が多い環境の中で働いている自分には上記の考え方がとても魅力的でした。
仕事をしていて「この作業無駄が多いなぁ」「もっと効率的な方法ないのかな」といった自分のモヤモヤへの一種の回答集のようでしたし、この本のような環境にできたら働き方が大きく変わって本来注力すべきことに集中できるよなぁと感じました。
VCS（バージョン管理システム）や Docker、CI/CD、Cloud などを勉強してきたタイミングで読んで、なぜモダンな開発をしている企業がこれらを採用しているのか、少し全体像が見えたように思います。
色々語りたいことはあるのですが、どうも支離滅裂な文章を生成してしまうので、最後に読んだ中で１番お気に入りの11章について触れて終わろうと思います。
（英語の前に日本語の勉強ですね…お恥ずかしい…）
11章はテスト（特に自動テスト）について書かれている章となります。
これまで仕事でテストを任されることが多かったので、身近に感じられる題材でした。
エクセルに書かれたチェック項目に沿って手動で試験をして、エビデンスとして画面のスクショを撮りまくる、というような昔ながらのテスト方法を教え込まれた身として、どれだけ乖離があるのか読む前から楽しみでした。
読んだ結果、もちろん私の予想を裏切らず、非常に画期的な方法を提案されていて目から鱗がポロポロでした。
（モダンな環境にいらっしゃる方はきっと共感しながら読めるのでしょう。早くそちら側に行きたい！）
まずテストを単独のフェーズとして扱わず、実装と一緒に行うこと。
私もまさにテストだけの作業を指示される経験が多いのですが、実装した人がテストまでやるほうが明らかに早いですし間違いが少ないです。
コードを理解して、どういったテストが必要か考える時間が省けますからね。
さらにこの実装・テストのプロセスをこまめにやること、システムの変更の度にテストを書くことでさらに問題の解決が早くなって good です。
そしてこれらのテストを低水準・中水準・高水準と 3層に分類して考え、低水準テストが 1番多いピラミッドのようなバランスにすることで、より素早い実行を可能にするようです。
（ここで言う水準はテストの範囲であり、低水準はテスト範囲の狭く単純なもの）
テストをこのように分類するという考えを初めて知った（今までは画面ごとに分けるのみでした）ので驚きましたし、 これなら最低限の時間でテスト可能で、エラーの特定もしやすくなるだろうと感じました。
最後に、ベスト目から鱗賞のアイデアは TDD（テスト駆動開発）です。
「言われてみればそうだよな～～でも思いつかなかったな～～！！」な面白い手法です。
それと同時に自動テストだからできる方法でもあります。
やり方はシンプルで「テスト→実装→コードの改良」というサイクルで行うというもの。
テストを先に書いてからコードを書くという逆の考え方なんですね。
調べてみると、工数が増えるなどのデメリットもあるようで賛否両論のようですが、 テストをしながら実装するのでエラーの発見が早くなったり、 コードの品質が上がるなどメリットも多くあります。
状況によって最善の方法とは言えないかもしれませんが、 1つのやり方として知っておくことはとても有用であると思いました。
11章について感想を書いていきましたが、この章で書かれていることはこれだけではないですし、 他の章もたくさんのアイデアがモリモリです。
いい本に出会えてよかった。
今後勉強を進めていって、より深く理解していけたらと思います。
特に 7、8章のサーバーのパターンが難しくてわけわからん状態になってしまったので、
知識を付けて読めるようになっていきたいです。
（未来の自分よ頼んだぜ）
まとめ
O’Reilly の「Infrastructure as Code」という本を読みました、というご報告と感想でした。
初心者がオライリー本に挑戦して失敗した的な記事もそこそこ見るのですが、私の場合は挑戦してよかったと思っています。
（本のレベルや内容、どの程度の初心者なのかにもよるのかもしれませんね。）
モダンな開発を勉強し始めた段階で Infrastructure as Code の考え方を知ることができ、とてもいい経験になりました。
2017年発行と今から 5年ほど前の本ではありますが、今でも役に立つ考え方がたくさん詰まっていておすすめです。
とは言え、内容は恥ずかしながら 4割くらいしか理解できなかったので、1～2年後には 9割くらい理解できるエンジニアに成長していたいです！
最後に、この本を進めてくださった先輩兼師匠に心からの感謝を込めて。
こちらのブログは初心者エンジニアが勉強の記録やアウトプットの一環として執筆しております。
内容に誤りがある可能性が多大にありますのでご了承ください。