Posts

はじめに 2026年 6/16にCKSに合格してKubernetes認定資格(KCNA, KCSA, CKAD, CKA, CKS)を全冠し、Kubestronautになりました。 Credly リンクを開く www.credly.com 全冠のhow toはすでにたくさんの方が書いていらっしゃるかと思うのでモチベーションなどを書いてみようと思います。 モチベーション 「Kubernetesなんかかっこいい！」くらいのノリでCKADを取得しようとしたのが始まりでした。 元々少し興味もあり、実務は基本ECSなのでCKADの受験をしていた頃は新しいツールを使えて面白いなくらいの気持ちでいました。 Kubernetesの試験勉強をしている時期に、SREやPlatform Engineerを自分のキャリアに選びたいと思うようになりました。 また、AIの進化に圧倒される日々の中でエンジニアとしての自分のアイデンティティを確立する必要に少し焦り始めていた記憶があります。 AIを用いたサービスを展開する会社さんも増えてきているように思っていて、ここからAIモデルをチューニングするみたいなところへシフトするのは流石に厳しいと思っている中で、AIプラットフォームとしてのKubernetesという側面を知りました。 Kubernetes Established as the De Facto ‘Operating System’ … New CNCF Annual Cloud Native Survey reveals near-universal adoption of Kubernetes Key highlights: SAN FRANCISCO, CA, … ...

はじめに 最近ストリームアラインドチームやイネイブリングチームなどを聞くことがよくあり、きちんと整理しようと思い「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読みました。 備忘録として印象に残ったことや感想を書いてみようと思います。 基本的に個人的な解釈・感想です、間違っていたらすみません 🙇‍♂️ Part1 - デリバリーの手段としてのチーム 最初のパートではコンウェイの法則1に基づいて展開されていきます。 ここで初めて ストリームアラインドチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム プラットフォームチーム が出てきます。 初めに知的労働組織の成功の鍵は、非公式構造と価値創造構造のインタラクションにあるとされます。 公式な構造、非公式な構造、価値創造構造は本書2の中では以下のように説明されていました。 公式な構造（組織図）: コンプライアンス遵守を円滑にする 非公式な構造: 個人間の「影響力の領域」 価値創造構造: 個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか 実際、公式な構造というのは何らかをエスカレーションするなど業務上役に立つことは多くありますが、ことソフトウェアのデリバリーにおけるコミュニケーションの構造とは確かに一致しません。 非公式な構造と価値創造構造のインタラクションとはすなわち人とチームのインタラクションと説明されていました。 影響力を持つ個人がチームに対して良い影響をもたらす場面には何度も立ち会ってきた実感がありますし、本書におけるチームの構造も相まってチーム内外の信頼関係を育むことは納得感があります。 組織的な編成などの決定がソフトウェアに対して力学を働かせるということ、逆にそれを利用してコミュニケーションパスを設計するということがこれから展開されていきます。 認知負荷を制限し、チームファーストのアプローチを適用し、組織が必要に応じたチーム間のインタラクションを誘発し、オーバーヘッドを見つけられるようにするというのがチームトポロジーのゴールとされました。 特にチームファーストのアプローチという点が興味深かったです。 人間が安定した人間関係を維持できる認知的上限の人数としてダンバー数に言及し、チーム内の信頼関係を最大化するためにチームメンバーの数を制限するとされていました。 特にダンバー数に関しては知らない概念でしたが、たくさんのメンバーと信頼関係を築くのは時間がかかるというのは当然であり、チームを構成した上で早くチームのパフォーマンスを最大化するためには、人数を抑えることが最も適切であるというのは理解できます。 どの程度の人数が信頼関係を維持できる閾値なのかの根拠があるのは組織を編成する上で説得力があります。 チーム内の信頼関係というのがとても重要視されていて、個人ではなくチームに報いること、メンバーはチームファーストのマインドセットを持つ必要があることについて言及されています。 印象に残っているのはチームの安定とメンバーの固定は別だということです。 直感には反する気がしますが、チームメンバー全員がチームファーストでチームのケイパビリティを高め続けるのであれば、属人化せずチームメンバーが変わったとしても新規メンバーへの投資というのは行われ続けるでしょう。 責任や能力に偏りのあるチームだと、メンバーの異動で不安定になってしまうのはあるあるだと思います。 自分もそうですが、チームを構成したとしても何らかのプロダクトの成功へ個人として意識が依ってしまうと思います。 チームファーストでチームとして足並みを揃えてプロダクトの成功へ向き合うことが、チームの安定、そしてプロダクトの成功を引き出すのだろうと理解しました。 最小単位としてのチームが確立できると、次はチーム間をどのようにコラボレーションさせていくのかということについて言及されます。 チームの認知容量に合わせて責任範囲を制限し、チーム間でのインタラクションの形を定義するということです。 ここでもチームの認知容量とソフトウェアのサブセットの境界を合わせるとされていて、一貫してコンウェイの法則を意識させられます。 チームファーストでソフトウェアを設計する（=チームの認知負荷を制限にあった形で設計する）ことはかなり難易度が高いなと感じました。 しかし、ソフトウェア設計の引き出しを増やしていくと自然と組織設計の選択肢も増えるというのは、マネジメント側へのキャリア形成も可能なのではないかと考えていて、技術とマネジメントは分断されていないことにある種の安心感を覚えています。 Part2 - フローを機能させるチームトポロジー 次は、Part1で紹介程度に出てきていた ストリームアラインドチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム プラットフォームチーム について詳細に説明されるパートです。 まずストリームについて定義する必要があります。 本書の中では、「ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのことだ」3とされています。 ストリームアラインドチームとはこのストリームにそって稼働するチームのことです。 つまりは、ストリームアラインドチームがプロダクトの根幹となるチームだと理解しました。 他のチームは適切なタイミングで、適切な方法でサポートすることでストリームアラインドチームの認知負荷が増えないように働きかけます。 イネイブリングチームは特定のドメインのスペシャリストで構成されるチームで、ストリームアラインドチームが多大な労力をかけずに新たな能力を獲得するのを助けるように振る舞います。 Enabling SREと言われたりするチームもこのイネイブリングチームのひとつでストリームアラインドチームがSREのプラクティスや信頼性にコミットできるように動くチームですね。 コンプリケイテッド・サブシステムチームは、「システムの中でもスペシャリストの知識が必要となるパーツを開発・保守する責任を持つ」4と説明されています。 これだけ読んだ時はイネイブリングチームとは違わないのではないかと感じたのですが、ストリームアラインドチームと関わる目的が異なります。 イネイブリングチームはストリームアラインドチームが新たな能力を獲得するために短期間にやりとりを行います。 ストリームアラインドチームの問題を解決するためではなく、チームの進化に寄与するためコラボレーションを行うということです。 対して、コンプリケイテッド・サブシステムチームはストリームアラインドチーム単体で開発した場合よりも認知負荷を抑えてデリバリーを加速させることが目的です。 そのため密接にコラボレーションを行うのは開発中やまだサブシステムが安定していない期間です。 ただ、保守も行うためストリームアラインドチームのニーズに合わせて適切なものをデリバリーする必要があります。 プラットフォームチームは、ストリームアラインドチームが下位のサービスを開発する必要をなくし認知負荷を下げるためのチームです。 ここで言われているのはプラットフォームはプロダクトであり、プラットフォームを利用するストリームアラインドチームはプラットフォームチームにとって顧客であるということです。 これはプラットフォームエンジニアリングを推進する文脈でもよく聞く考え方ですね。 ...

概要・事前知識 2026年2月15日にProfessional Cloud Architectを受験して合格したので、勉強方法や感想をまとめてみようと思います。 実務ではAWSを主に利用していて、個人的にCloud RunやGKEをちょっと触るくらいの知識量から受験に向けて勉強しました。 ベンダー資格は初めての受験です。 勉強期間 大体１ヶ月弱くらいだと思います。 休日や隙間時間を使って後述するUdemyのコンテンツに取り組みました。 教材 Google Cloud認定 Professional Cloud Architect（PCA） トレーニング まずは一通りのGoogle Cloudのサービスや概念を理解するために以下の教材を購入しました。 少し情報が古そうでしたが、キーワードとサービスを関連付けるために利用したので特に気になりませんでした。 www.udemy.com リンクを開く www.udemy.com 【最短攻略】Google Cloud 認定 Professional Cloud Architect 模擬問題集 ある程度サービスを理解してから以下の問題集を解きました。 これをすべて9割程度取れるようになるまで繰り返し解いて、理解すれば自信を持って試験へ臨めると思います。 こちらも少し情報が古そうなので、自分で調べる必要がありますがそこまで問題にはならなかったです。 www.udemy.com リンクを開く www.udemy.com 感想 Google Cloudの上位資格の位置付けだと思うのですが、他のGoogle CloudのProfessionalの資格とは異なり広く浅くというような感じなのかな？という印象を受けました。 実務でなんらかのパブリッククラウドに触れていれば特に問題なく合格できるのではないかと思います。

思ったことをつらつらと書いていきます