読んだ : 入門 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　アライアンス―――人と企業が信頼で結ばれる新しい雇用

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

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

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

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

個人の成功について

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

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

感想

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

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

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

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

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

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

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

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

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

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

個人的に気になったこと

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

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

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

システム思考

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

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

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

ジョハリの窓

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

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

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

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

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

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

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

アジャイル

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

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

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

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

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

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

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

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

多点見積もり

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

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

権限移譲

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

技術的負債

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

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

取引コストと技術組織

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

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

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

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

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

関連書籍の紹介

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

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

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

• 読んだ : なぜ人と組織は変われないのか - 一角獣は夜に啼く

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

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

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

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

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

• 読んだ: 人を伸ばす力 ― 内発と自律のすすめ - 一角獣は夜に啼く

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

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

読んだ : さわって学ぶクラウドインフラ 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 を用いたブログシステムの作成。
  • DB サーバーを用意して、アプリケーションサーバーに WordPress をインストール。
• 9 章 : TCP/IP による通信の説明。

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

さらに学ぶために

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

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

*1:私です

読んだ : .NET のエンタープライズアプリケーションアーキテクチャ 第 2 版 / Dino Esposito、Andrea Saltarello 著

ドメイン駆動開発 (DDD) 関係の読書会に参加していて、最近読んでいるのがこれです。

．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)

本書は、『再利用可能で、入手が容易な、ソフトウェアアーキテクチャの確かな知識ベースを提供』 することを考えて執筆されています。 すなわち、DDD の書籍というよりは、開発者とアーキテクトのための、ソフトウェアアーキテクチャ (その中でも特にエンタープライズアプリケーションや web アプリケーションのアーキテクチャ) の虎の巻のようなものです。 その中にドメイン駆動設計の考え方も含まれています。

内容

本書の内容を紹介します。

1 部 「基礎」 では、ソフトウェアアーキテクチャの基礎ということで、アーキテクトの役割であったり、プロジェクトを成功させるためにソフトウェアディザスタ (技術的負債だらけであること) を何故避ける必要があるのかといったこと、ソフトウェアの設計原則やテストが重要であることなどが書かれています。 ここら辺は割と他の書籍でも書かれていることなので、わりとサラッと読んでしまって良さそうです。 (ここら辺の内容をちゃんと吸収するなら 『CODE COMPLETE』 などを読むのが良いと思います。)

第 2 部 「アーキテクチャの考案」 には、プレゼンテーション層とビジネス層についてが書かれています。 目玉は 5 章の 「ドメインアーキテクチャの発見」 で、要約すると 『ドメインを深く理解することだけが適切なアーキテクチャの発見につながる』 ということと 『サブドメインの存在に気づいた場合は、それらをサブアプリケーションとしてモデリングし、最適なアーキテクチャをそれぞれに定義でき』 るということです。 ユビキタス言語と境界づけられたコンテキストが重要である、ということですね。

DDD 関係の本を読むとドメインモデルを構築するための技術的な部分に着目しがちですが、本書ではドメインモデルはあくまでサポートアーキテクチャの 1 つにすぎないと明確に述べていて、ユビキタス言語と境界づけられたコンテキストの重要性を前面に押し出しているのが特徴的です。 また、システムを設計するための手法として、ユーザーエクスペリエンスファースト (UX ファースト) と呼ばれるアプローチをとっているのも特徴ですね。 これは、システム設計の作業をプレゼンテーション層から開始して、予備的な分析を並行して行うという設計理念です。 つまり、最初にビジネスドメインと UX に関するデータを集めてユーザーとの対話モデルを設計して、その後でデータのワークフローやロジック、サービス、ストレージの定義に取り掛かるというものです。

第 3 部 「サポートアーキテクチャ」 では、ドメインモデル、CQRS、イベントソーシングの 3 つのサポートアーキテクチャについての説明がなされます。 ドメインモデルを用いた場合は、ドメインのすべての側面に適合する単一のモデルを設計する必要があり、モデルが複雑になってしまうという問題があるということが述べられ、本書ではやや CQRS 推しな感じです。 (もちろんドメインモデルが適している場面ではドメインモデルを使えば良いのですが。) 個人的にもドメインモデルをがっつり設計するのが常にいいとは思っていなかったので、「DDD の分析部分 (ユビキタス言語や境界づけられたコンテキストの発見) は常に重要だけど、戦略部分 (各境界づけられたコンテキストに最適なアーキテクチャを割り当てる) ではドメインモデルを使う以外の方法もある。 トランザクションスクリプトでもいいし、CQRS という選択肢もある」 というのを明確に示している本書は参考になりました。

第 4 部は 「インフラストラクチャ」 で、永続化レイヤーについて説明されます。

感想

DDD の 「分析部分」 と 「戦略部分」 を分けて、「戦略部分に置いてどういうアーキテクチャを選択するのが最適なのかは場合による」 というのを明確に示しているのが良いなーと思いました。 上でも書いたように、DDD というと 「ドメインモデルをいかに設計するのか」 に着目しがちなのですが、分析部分がまず重要であるというのが読んでいて伝わってきました。 (ユビキタス言語と境界づけられたコンテキストが重要であるということは DroidKaigi 2017 でのあんざいゆきさんの発表でもなされてましたね。)

戦略部分については、サポートアーキテクチャとして DDD において従来から使われているドメインモデルだけでなく、CQRS とイベントソーシングについても述べられているのが良い点だと思います。 どういうものかの紹介や思想の説明もありますし、実装の例も紹介されています。 実際に設計する際にどういう形にすればよいかがイメージしやすいようになっていて参考になります。

翻訳については、1 部の日本語が難しくなっていて読みづらいという問題はありました。 2 部以降はそれほど気にならなかったです。

全体としては、エンタープライズアプリケーションや web サービスの開発者やアーキテクトがアプリケーションのアーキテクチャについて検討する際に役立つ知識がまとまっていて、良い本だと思います。 『.NET の』 とタイトルにありますが、.NET に詳しくなくても問題なく読み進めていくことができますし、アプリケーションの全体のアーキテクチャについて考えている人は読んでみて損はないと思います。