ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

トップ > 書籍

読んだ : Clean Architecture 達人に学ぶソフトウェアの構造と設計 (Robert C. Martin 著)

書籍 書評 感想

Robert Cecil Martin 氏、いわゆるアンクル・ボブ (ボブおじさん; Uncle Bob) による Clean Architecture についての書籍。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

アンクル・ボブの Clean Architecture といえば、下記記事を読んだことがある人も多いだろう。

ここ数年の Android アプリ開発界隈でも Clean Architecture はよく話題に上がっているように思う。 私自身も web 上で Clean Architecture について調べて学んだりしてきた。

しかし、web 上の情報を追いかけるだけだと、レイヤ分けや依存関係のルールはわかっても、より本質的な思想の部分まではなかなか理解できなかった。 例えば、「クリーンアーキテクチャにおいてサーバーとクライアントの構成にする場合にどういう扱いにするのが妥当なのか？」 というのは長年考えてきてなかなか自分の中で納得した答えは出せなかったもののひとつである。

本書を読むことで、Clean Architecture の本質的な思想についても深く理解できた。 また、そもそもの 「アーキテクチャとは何か？」 といった部分まで考えることができた。 ソフトウェアアーキテクチャについてより深い洞察を得たい人におすすめの一冊である。

本書の流れ

本書は、「設計とアーキテクチャは地続きのものであり、本質的な違いはない」 というところから始まる。 そして、構造化プログラミングや関数型プログラミングといったコーディングのパラダイムが説明される。 その後に設計の原則 (SOLID 原則)、コンポーネントの原則 (REP、CCP、CRP) についての説明がある。 ここまでが本書の前半である。

本書の後半では、前半の話を踏まえて、アーキテクチャの説明に入っていく。 アーキテクチャの話だけ読みたい人もいるだろうが、個人的には SOLID 原則や REP、CCP、CRP といった部分についても改めて学ぶことができて非常に良かった。

学びや感想

設計とアーキテクチャ、その目的について

1 章で、「設計とアーキテクチャについて、本質的には違いはない」 ということが言われる。 通常、アーキテクチャは下位レベルの詳細とは切り離された文脈で使用され、設計は下位レベルの構造や意思決定を意味しているが、実際のところ下位レベルの詳細と上位レベルの構造が全体の設計の一部になる。 そうした連続した構造がシステムの形状を定義するので、設計とアーキテクチャを明確に区別することはできない。 上位レベルから下位レベルまで決定の連続であり、その目的は下記の通りである。

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

ソフトウェアの振る舞いが正しいものであることを重視し、アーキテクチャを軽視すると、開発を続けていくうちに生産性がどんどん低くなっていく。 「振る舞いが正しいこと」 と 「変更しやすいこと (良いアーキテクチャ・設計であること)」 のどちらが重要であるかという質問に対して、ビジネスマネージャは、「振る舞いが正しいこと」 であると答えることが多く、開発者もそれに賛同することが多い。 しかし、下記のように考えると、より重要なものは 「アーキテクチャ」 である。

  • 振る舞いが正しく、変更しづらい (アーキテクチャ・設計が良くない) プログラムは、今は正しくとも将来的な要件の変更に追従できなくなり、やがて役に立たなくなる。
  • 振る舞いが誤っており、変更しやすい (アーキテクチャ・設計が良い) プログラムは、今の正しくない振る舞いを正しく修正することも容易であり、将来的な要件の変更にも追従しやすく、長く価値を保つ。

開発者以外に対してアーキテクチャ・設計の重要性を説明することは非常に難しいと思っていたが、上記の観点で説明すると結構説明しやすい気がした。

優れたソフトウェア開発チームは、真正面から闘争に立ち向かう。 ステークホルダーたちと対等に、ひるむことなく口論する。 ソフトウェア開発者もステークホルダーであることは忘れてはいけない。 保護すべきソフトウェアに対する責任がある。 それが、あなたの役割であり、義務である。 それが、あなたが雇われている大きな理由だ。


テストと反証可能性について

Dijkstra は 「テストはバグが存在しないことではなく、バグが存在することを示すものである」 と述べた。 つまり、テストによってプログラムが正しくないことは証明できるが、プログラムが正しいことは証明できないのである。 テストに十分な労力をかけていれば、そのプログラムは目的のために十分に真であるとみなせる。

この事実は、驚くべきことを示している。ソフトウェア開発は、数学的な構成要素を操作しているかのように思えるかもしれないが、実際には数学的な試みではない。 むしろソフトウェア開発は科学のようなものである。 どれだけ最善を尽くしても正しくないことを証明できないことによって、その正しさを明らかにしているのである。

数学的なアプローチか科学的なアプローチか、という観点は持っていなかったので、「なるほどー」 と思った。

最小の機能から最大のコンポーネントまで、あらゆるレベルにおいて、ソフトウェアは科学のように、反証可能性によって動かされている。ソフトウェアアーキテクトは、簡単に反証できる（テスト可能な）モジュール、コンポーネント、サービスを定義しようとする。そのために、さらに上位のレベルにおいて、構造化プログラミングのような制限を課している。


単一責任の原則

SOLID 原則の一つである単一責任の原則 (SRP) について、「たった一つのことだけ行うべき」 だと思っていたけど、正しくは 「モジュールが責務を負うべきアクター (ソフトウェアの変更を望む人たちのグループ) がひとつだけになるようにすべき」 ということだった。 アクターをどう定義するかが難しい気もするけど、アクターの定義をどうするかを含めてしっかり考えていく必要があるんだろうなぁと思う。


コンポーネントの原則


アーキテクチャについて

アーキテクチャについては、下記の内容が非常に刺さったり共感するものだった。

  • アーキテクチャはユースケースを叫ぶものでなければならない。 どういう技術を採用するかということに意識がいきがちだけど、重要なのはユースケースであって、どういう技術を採用するかではない。
  • アーキテクトとしては詳細の決定はできるだけ遅らせるようにすること。 DB に何を採用するのかとか、通信プロトコルに何を採用するのかなど、そういったものは技術的な実装詳細であり、優れたアーキテクチャはそれらの決定を遅らせられるものである。
  • 入出力はテストしづらい部分なので、依存関係の一番外側に持ってくること。
  • フレームワークへの依存は避けるべき。 フレームワークは実装詳細であり、アーキテクチャとして重要なものではない。

つまり、冒頭で述べた私のこれまでの疑問の話で言うと、(クライアントとサーバーの両方で一つのソフトウェアなのであれば) クライアント・サーバー間の通信なども詳細であり、アーキテクチャとしてはクライアントもサーバーも含めてユースケースを考える、というのが優れたアーキテクトとしての姿勢なのだと感じた。

ツイートメモ

読んだ : 入門 Kubernetes

Kubernetes 書籍 書評

Kubernetes に興味を持ちつつ何も手を付けていなかったのだけど、会社に置かれてたのでまずは本を読んだ。

入門 Kubernetes

入門 Kubernetes

Kubernetes を何故使うのか、というところから始まり、Kubernetes における各種オブジェクトの大まかな概念の説明から使い方まで一通り解説されている。

読書メモ

Kubernetes を何故使うのか、という導入では以下のような内容が書かれている。

  • ベロシティ : 宣言的設定でイミュータブルなコンテナを扱うことで自己回復しやすくスケールもしやすくなっている。
  • サービスとチームのスケール : マイクロサービス化による開発チームのスケールや、アプリケーションやクラスタのスケールをしやすくする、など。
  • インフラの抽象化・アプリケーション実行のためのプラットフォーム : 『プロダクションレディマイクロサービス』 で言われていた 4 層モデルの 「アプリケーションプラットフォーム」 に該当する。 アプリケーションプラットフォーム側がアプリケーション開発側に対して API を提供することで、アプリケーションプラットフォーム側とアプリケーション側の責務を切り離す。
  • インフラの効率性。 アプリケーションのコンテナを同じ物理マシン (または仮想マシン) 上に同居させることができる。

便利。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

それから、「Pod」 や 「ReplicaSet」、「DaemonSet」、「Deployment」、「Job」、「Service」、「Namespace」 といった概念について、本を通して解説される。 下記に今のところの自分の理解を書いておく。

  • Pod : コンテナの集まり。 Web サービスのアプリケーションの 1 インスタンスなどが Pod になる。
  • ReplicaSet : 特定種類の Pod の集まり。 Web サービスを複数インスタンスで動かす際などには ReplicaSet で複数 Pod を動かす、という形になる。
  • Deployment : ReplicaSet の履歴を保持したオブジェクト。 Web サービスに変更を加える際には、新バージョンに対応する ReplicaSet を Deployment に追加してアップデートを行う、という形。
  • Service : Kubernetes クラスタ上のアプリケーション同士の通信や、外部への公開のために使われる。

良かった

Kubernetes に入門するには良い本だった。 著者は Kubernetes の開発者なので、どういう思想でこうなっているのか、というのもところどころに書かれていて 「なるほどねー」 と言いながら読める。 本書をざーっと読んで概念を理解したら、あとは実際に Kubernetes を触って動かしていくと良さそう。 今なら Docker for Windows で Kubernetes クラスタを簡単に用意できたりするので、軽く試すだけなら簡単にできる。

Kubernetes やっていこう。

読んだ : 最高のリーダー、マネジャーがいつも考えているたったひとつのこと

書籍 書評 マネジメント

ラインマネージャに任用されたのでマネジメント系の本を読んだりしてる。 これは社長おすすめの一冊。

最高のリーダー、マネジャーがいつも考えているたったひとつのこと

最高のリーダー、マネジャーがいつも考えているたったひとつのこと

本書では、「マネジメント」、「リーダーシップ」、「個人の継続的な成功」 の 3 つの主題について、それぞれ最も重要なことは何かということが述べられる。 実際にマネージャとして仕事をしていくうえでは学ぶべきこと、知っておくべきことはいろいろあるけれど、根幹となる考え方として本書の内容は非常に明確でわかりやすく、実際に有用であると感じた。

読書メモ

組織の成功について

本書の第 1 部では、組織の継続的な成功について、マネージャとリーダーの違いと、それぞれで大切なたったひとつのことが述べられる。

マネージャについては以下のようなことである。

  • 部下の才能を業績に結びつけるいちばんの方法を見つけ出すことが、優れたマネージャの仕事。
    • ひとりひとりの強みや弱み、特色を見いだし、有効に活用すること。 ときには仕事の方をメンバーに合わせて変更する。
  • 部下のために働く。 部下にとっての目標を出発点にして、そこから企業の目標に結びつけることを考える。
  • 成長を手助けすること。 自社でのキャリアだけでなく、本人にとって最も良い道を探す手助けをする。
  • ひとりひとりの特色を見いだす。 そのための質問例。
    • 強みや弱み : 最近仕事が楽しかったのや辛かったのはいつか。 何をしていたときで、それは何故か。
    • 引き金 (動機づけ？) について : これまで一番うまくいったマネージャとの関係は？ なぜ？ いままでに承認を得た中で一番心に残っているのは？ それはなぜ？
    • 独自の学習スタイル : これまでの仕事で一番多くを学んでいると思ったのはいつか？ なぜ？ 一番の学習スタイルはどういうもの？

ひとりひとりの 「人」 を見る、ということをすごく重要視している。 個人的にはあまり得意ではない部分なので、意識してやっていきたい。

会社のミッションと個人のミッションをすり合わせるという話については 『ALLIANCE』 が非常に参考になる。

ALLIANCE　アライアンス―――人と企業が信頼で結ばれる新しい雇用

ALLIANCE　アライアンス―――人と企業が信頼で結ばれる新しい雇用

リーダーについては以下。

  • すぐれたリーダーは、よりよい未来に向けて人々を一致団結させる。
  • そのためにたった一つの大事なことは、普遍的なことを発見して、それを活用すること。
  • 未来を明確に示し、不安を取り除く。
  • リーダーシップの 3 つの規律。
    • 考える時間を作る : 未来を明確に示すためには熟考して結論を出す必要がある。 多忙な中でも時間を割いて熟考する。
    • ヒーローを慎重に選ぶ : 未来に向けてとるべき行動を示すために、ヒーローを選ぶ。 (この人のこういう行動が未来に向けて良い、ということを示す。)
    • 練習する : 伝えるための言葉やイメージ、ストーリーを練習する。 同じ言葉を何度繰り返しても繰り返しすぎだと思わないこと。 自分が繰り返しに飽き始めるころにやっと相手の心に届く。

目指す先を明確にするというのは非常に大事だと思う。 事業のビジョンを明確に打ち出すというのも、そのひとつなのだと思う。

意識はしていてもなかなか難しいことではあるが、マネージャとしては最初にこの 2 つの 「たったひとつのこと」 を大事にしていくと良さそう。

個人の成功について

第 2 部では、個人の継続的な成功について語られる。 本書では、個人の継続的な成功を 「可能な限り大きな影響を最も長い期間与えること」 とおいている。

  • 個人が継続的に成功するために大切なたったひとつのことは、自分がしたくないことを見つけ出し、それをやめること。
  • 正しい戦術を見つけ、それを活用するだけではありきたりな存在になる。 自分の個性をいかすこと。
  • 弱みを克服することは重要ではない。 人が最も多くを学び、やりがいを感じるのは強みの分野。
  • 強みを見つけ、それを伸ばすことは、必要ではあるがそれが最も重要なことではない。 強みを活かしつつも他のやりたくない仕事が多量にあると継続的な成功は難しい。
  • 自分がしたくないことをやめるための戦術 : 役割をやめる、役割を微調整する、正しいパートナーを探す、役割の中で自身の力を引き出す側面を見いだす
  • チームに対して、そして未来に対して最高の貢献ができるように軌道修正を行うのは、常に自身の責任である。

感想

組織で仕事をしていくうえで、本書に書かれている内容はいずれも重要であると感じた。 マネジメント研修でも、「仕事の側面に注目しがちだけど、人の側面も大事」 ということや 「仕事のサイクルの中で一番大事なのは計画で、目的を明確にしてそれを伝える必要がある」 というようなことを言われたのだけど、本書に書かれてる内容を踏まえてそういう話を聞くと納得感も高かった。

個人の成功についての話も大事な話で、「強みを伸ばす」 というのも一つの大事なことではあるけれど、強みとやりたいことが違う場合もあるし、強みを伸ばしながらも他の作業に忙殺される状況もあるし、そういったもろもろを避けるために 「やらないことを決めて、それをしないようにする」 というのをやっていこう。

読んだ : エンジニアリング組織論への招待

書籍 書評

広木大地さんの 『エンジニアリング組織論への招待』。 良い本だと話題になってましたね。 うちのチームでも皆で読んでます。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

本書の 「はじめに」 には、以下のように書かれています。

本書は、「不確実性に向き合う」 というたった 1 つの原則から、エンジニアリング問題の解決方法を体系的に捉える組織論です。 わからないものを避ける本能を、どのように理解し、克服し、導くのか。 テクノロジーを力に変えたい経営者やエンジニアリーダー、そして、今、かつての私と同じように悩んでいる人へのチャレンジのきっかけとなればうれしいです。

エンジニアリングとは 「何か役に立つものを」 「実現していく」 ことであり、そこで重要なことが 「不確実性を小さくしていくこと」 である、というのが本書の根幹にある考え方です。 役に立つものを実現していく流れの中には、「役に立つものとは何か」、「どうやって実現するのか」、「いつ実現するのか」 といった不確実さが多くあります。

不確実性を大別すると未来に対する不確実性 (環境不確実性) と他人に対する不確実性 (通信不確実性) に分けられます。 それらへの対処として、認知と意思疎通、組織論やアジャイルといった考え方について説明されます。

認知の話や組織論の話、アジャイルなどについて様々な本が世の中には存在していますが、「エンジニアリング」 という観点で一冊にまとめあげられた書籍は本書しかないのではないでしょうか？ エンジニアリング組織における組織論についての、ある種の教科書的な書籍であると感じました。 エンジニアリングについての組織論の入り口としてはオススメの一冊です。

個人的に気になったこと

本書を読んでいて自分が感じたことや新たに発見したことを紹介しておきます。

リアルオプション戦略 (遅延した意思決定)

早期に大きな投資をして大きなリスクを取るのではなく、最初は小さな投資を行って不確実性を小さくしてから (成功する見込みが大きくなってから) 大きな投資をする、というようなものがリアルオプション戦略。

システム思考

ロジックツリーを作るような単純な依存関係の要素分解をするのではなく、様々な要素が複雑な依存関係を持っているとみなして全体を捉えるのがシステム思考。 同僚に聞いたら 10 年前ぐらいに流行ったらしい。 下記の書籍をおすすめしてもらったので今度読んでみる。

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方

ジョハリの窓

自己について、自己が認識しているかどうかと他者に認識されているかどうかの 2 軸で四象限に分けたもの。

  • 自己が認識しており、他者からも認識されているもの : 開放の窓
  • 自己は認識しているが、他者からは認識されていないもの : 秘密の窓
  • 自己が認識しておらず、他者からは認識されているもの : 盲点の窓
  • 自己が認識しておらず、他者からも認識されていないもの : 未知の窓

メンタリングにおいては、メンターとメンティ互いの開放の窓を大きくしていくことが、対人リスクを下げて生産的な関係を構築していくことにつながる。

能力は習慣の積分、習慣は行動の積分

能力や、それによって生み出される成果についてはコントロールできないが、行動やその積み重ねである習慣についてはコントロールしやすい。 という話。

プロダクトマネジメントとプロジェクトマネジメント

プロダクトマネジメントはマーケット不安を抱えて、目的不確実性を扱う。 プロジェクトマネジメントはスケジュール不安を抱えて、方法不確実性を扱う。 プロダクトマネジメントはプロダクトを続けること (価値を提供し続けること) が目的で、プロジェクトマネジメントはプロジェクトを完了させることが目的。

アジャイル

アジャイルというのは開発方式を表しているのではなく、状態を表す。 アジャイルな状態まさに自己組織化された状態で、下記のような状態を指す。

  • 情報の非対称性が小さい
  • 認知の歪みが少ない
  • チームより小さい限定合理性が働かない
  • 対人リスクを取れていて心理的安全性が高い
  • 課題・不安に向き合い不確実性の削減が効率よくできている
  • チーム全体のゴール認識レベルが高い

アジャイルに関してはこれまでもいろいろ読んできたけど、本書では歴史なども踏まえて説明してくれていて、特に思想的な部分がわかりやすくて良かった。

暗黙知と形式知についての SECI モデルや、リフレーミングに関わるダブル・ループ学習の話なども (これまでも見たことがあったけど) 紹介されていた。

プリンシパル・エージェント理論やエージェンシースラック

経済における人間関係を、依頼者 (プリンシパル) と代理人 (エージェント) の契約の束としてとらえる考え方をプリンシパル・エージェント理論というらしい。

そして、代理人が依頼者に対して嘘をついた方が利益を得られる状況の場合に、その利益分をエージェンシースラックというらしい。 (例えば、代理人が実際よりも多くコストを算出して依頼者に請求する場合とか。) エージェンシースラックを解消するために依頼者が払う監視やインセンティブなどのコストを、コントロールコストという。 また、代理人側がエージェンシースラックを解消するために払うコストをシグナリングコストという。

こういうの、いたるところで発生するはずだから意識していきたい。

多点見積もり

工数見積もりにおいて、平均的な場合の工数だけでなく、最悪の場合の工数 (もうちょっとちゃんとした言葉で説明されてる) なども見積もって見積もりに幅を持たせる手法が紹介されてた。

確かに見積もりには幅があるはずだけど、普段チームで会話するときには見積もりの幅を意識してないなーと思った。

権限移譲

権限移譲のレベルについて、デリゲーションポーカーで測るという方法や、その後に権限の可視化をしっかりしておくことが大事。 (チームが自発的、自律的に動きやすいように。)

技術的負債

マーティン・ファウラーの 「技術的負債の四象限」 やフィリップ・クルーシュテンの四象限、クラウス・シュミットによる数学的定義が紹介されてた。

本書では 「技術的負債の問題とは、経営者とエンジニアの間に存在する 「認識の差」 の問題」 って書かれてて、確かにそういう部分が問題になることも多いと思うのだけど、結構エンジニア側のチーム内でも認識の差があることも多いよなぁ、ということを思ったりした。 (個人的には、チーム内で認識を統一できていれば経営者側への説明もしやすいのではないか、って気がしている。)

取引コストと技術組織

プロダクト開発を内部のリソースで行うべきか、外部のリソースで行うべきか、ということを考えるために取引コスト理論が紹介されていた。

経済取引には取引コストが発生し、それは次の 3 つに大別できる。

  • 探索のコスト : 取引相手を見つけるために支払うコスト
  • 交渉のコスト : 取引相手と交渉を行うために発生するコスト
  • 監督のコスト : 取引相手が契約した取引を履行するように監督と矯正を行うコスト

外注して取引を続けた場合、システムについてその外注先しか把握できない状態になり、ホールドアップ問題 (取引コストが上がる) が発生したりもする、とのこと。

あと、社内でも IT 部門を P/L 独立させた場合などは、部門間で取引コストがかかることになって、外注するのと変わらない状況が発生しうる、みたいな話も。 耳の痛い話だ。

関連書籍の紹介

上でも言ったように、本書では様々な内容を取り扱っているので、特定の内容について掘り下げたい場合は別の書籍を読むのも良いと思います。 また、本書の内容とはちょっと違っているが、関連する内容の書籍もいろいろあります。 自分が読んだことのある書籍をいくつか紹介します。

認知についてや、なぜ行動を起こせないのか、リフレーミングという点については、『なぜ人と組織は変われないのか』 が興味深かったです。

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

組織学習 (リフレーミングについても) については 『チームが機能するとはどういうことか』 も良かったです。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

自己組織化については 『エラスティックリーダーシップ』、自律やメンタリングについては 『人を伸ばす力』 も良かったです。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

人を伸ばす力―内発と自律のすすめ

人を伸ばす力―内発と自律のすすめ

社内でも部署間で取引コストが発生してしまうというような話については、『サイロ・エフェクト』 が参考事例として面白い書籍です。

サイロ・エフェクト 高度専門化社会の罠

サイロ・エフェクト 高度専門化社会の罠

読んだ : さわって学ぶクラウドインフラ Amazon Web Services 基礎からのネットワーク & サーバー構築

AWS インフラ 書評 書籍

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

インフラ周りちゃんと学ぶぞー！ と言いつつ時間ばかり経ってしまっているので、いい加減ちゃんとやろうと思って本書を読んだ。

易しめの内容でわかりやすく書かれているので、「インフラ周りをちゃんと学びたいと思いつつも苦手意識を持っている」 という人 *1 や、「SSH コマンドなどもろくに使ったことがないけどインフラ周りを学んでみたい」 という人におすすめの書籍だった。

感想

  • 「AWS で WordPress を動かす」 ために必要な内容を順番に説明していくという、わかりやすい内容だった。
  • AWS だけでなくネットワーク周り (TCP / IP とか) についても初心者向けの内容になっており、インフラ周りについてほぼ何も知らない状態でもとっつきやすい。
  • AWS についても リージョンやアベイラビリティゾーン (AZ) といったことから説明がある。
  • そして、Amazon Virtual Private Cloud (VPC) や Amazon Elastic Compute Cloud (EC2) といった、AWS 上で web サービスを運用する場合によく使われるであろうサービスについての知識が得られる。
  • わかっている人にとっては簡単すぎる内容だと思うが、初心者にとってはこれぐらい簡単な方がとっつきやすくてありがたい。
    • 実際に本書の内容に従って手を動かしていくと、だいぶ理解が進むと思う。
    • 自分は仕事でも AWS を使っているし、同僚の勉強会で Terraform を触りながら AWS の概念を学ぶ、ということもやってきたが、改めて本書の内容に従って学びなおすことでだいぶ定着したと思う。 (やはり一から自分で手を動かすというのが大きい。)
  • お金のことを考えるとなかなか個人で AWS を触ろうという気にならなかったりするのだけど、本書の内容は AWS のアカウント作成後に付与される無料枠の中でできることばかりなので、気軽に試していけるのも良い。

本書の内容

9 章構成になっている。

  • 1 章 : ネットワークの基礎的なところから AWS の基礎的な部分まで解説される。 また、本書で構成するシステムの全体像も描かれる。
    • 一般的な web アプリケーションに必要なアプリケーションサーバーと DB サーバーが、それぞれパブリックサブネットとプライベートサブネットに配置されているようなネットワーク。
  • 2 章 : ネットワークを作る。
    • VPC を用意し、パブリックサブネットを作る。
  • 3 章 : サーバー構築。 EC2 インスタンス起動。
  • 4 章 : Web サーバーソフトをインストール。 Apache。
  • 5 章 : HTTP の動きの確認。
  • 6 章 : プライベートサブネットを作る。
  • 7 章 : NAT を構築。
  • 8 章 : DB を用いたブログシステムの作成。
  • 9 章 : TCP/IP による通信の説明。

上記のような感じで、手順としても SSH コマンドなどについても丁寧に説明しているので、本当に初心者にもわかりやすいと思う。

さらに学ぶために

上で何度か言ったように、本書は初心者にもわかりやすいような内容になっている。 逆に、自動化などの応用的な話はあまりないので、さらに学びたい人は本書の内容を Terraform で書きながら読み進める、というようなことをしてもいいかもしれない。

私は本書を読み終わった後に Terraform の Getting Started を読んでいく、という感じで学んでいった。

*1:私です