4 Team Type詳解、バリューの示し方：DevOps/SRE/Kube WeeklyUpdate (24/01/06-12)
以下の３つの記事から気になったもの & 個人的に気になったものを毎週紹介しています。
今週はKube Weeklyお休みでした。
DevOps Weekly（ https://devopsweeklyarchive.com/ ）
SRE Weekly（ https://sreweekly.com/ ）
KubeWeekly（ https://www.cncf.io/kubeweekly/ ）
DevOps Weekly
Four Team Types
チームトポロジーに記載のある内容がコンパクトにまとまっていました。
目的を持ってチームを構築し、組織する方法についてが書かれています。
チームのタイプ
チームトポロジーの書籍にも記載はありますが、最新のソフトウェアシステムを構築して実行するために必要なチームは以下の4つになる。
- Stream-Aligned Team
- Enabling Team
- Complicated-Subsystem Team
- Platform Team
Stream-Aligned Team
ストリームとは、あるビジネスドメインや組織能力に合わせた継続的な作業と定義しています。
このチームは、単一のプロダクト、一連の機能、UI/UXの開発などを含めた作業を継続的に行います。
そのため、価値を迅速かつ安全に、独立して構築から提供まで行える権限が与えられています。言い換えると、作業の一部を完了するために他のチームに引き継ぎを行うべきではなく、最初から最後までオーナーシップを持って作業を行います。
そして、このチームは組織において最も主要なチームタイプである必要があります。後述する他のチームはこのStream-Aligned Teamの負担を軽減するために存在しています。
このチームは顧客に最も近く、顧客からのフィードバックを迅速に取り入れるために、必要に応じて変化に適応する必要があります。
Enabling Team
このチームは、特定の知識領域における専門家で構成されます。知識領域は、より技術的である場合や、よりプロダクトに重点が置かれている場合があります。
複数のStream-Aligned Teamに横断的に対応し、先行検証などを行う時間を確保しています。この知見をそれぞれのStream-Aligned Teamに持ち帰り、各チームの能力のギャップを埋める活動を行います。
そのため、Straem-Aligned Teamが抱えている課題を理解し、適切な指導を提供する必要があります。
事例として、LayerXでは、イネーブルメント専門チームが設立しています。
Complicated-Subsystem Team
このチームは、高度な専門知識を必要とするシステムの構築と保守を担当します。そのため、チームメンバーはその分野の専門家であり、サブシステムに変更を加えることができる権限を持つ必要があります。
このチームのゴールは、Stream-Aligned Teamの認知負荷を軽減することです。Stream-Aligned Teamの本来の目的である、ユーザーに価値を届けることから気をそらされることを避けるように支援します。
例として、MLなどのような複雑で高い専門性を要求されるサブシステムの開発とメンテナンスを行うようなMLチームが該当する。
Platform Team
このチームは、認知負荷を軽減する内部サービスを提供することで、Stream-Aligned Teamが自律して、より早いサイクルでプロダクト開発などの作業を実行できるようにします。
近年では、Kubernetes周りの技術領域が拡大していることから、Stream-Aligned Teamがそのキャッチアップに時間を取られ、本来の作業に取れる時間が少なくなってしまっている課題があります。その課題を解決し、より素早く、Stream-aligned teamがオーナーシップを持って自律的にプロダクトの立ち上げや開発を行えることを目的としています。
近年では、ガートナーが２０２４年のトップトレンドにPlatform Engineeringを挙げているように、ホットな分野であることがわかります。
続きの記事では、インタラクションモードについて書かれているので興味のある方は是非。（というか、チームトポロジーを読んだ方がいいかもしれません）
SRE Weekly
How to show your value in DevOps/SRE
DevOps/SREというロールにおいては、問題が発生するまでは経営者にとって具体的な成果が見えづらいという点に課題があり、その中でどのようにバリューを発揮していくかが書かれています。
まずは「影響力」に焦点を当てる必要があります。すなわち、その分野に対する投資対効果がなければいけなく、自分たちの活動が有意義にビジネスに利益をもたらすことを証明する必要があります。
では、DevOps/SREにおける「影響力」とは何でしょうか。
通常、ビジネスの目標は「在庫と運用経費を同時に削減しながらスループットを向上させて利益を上げること」とイーライ・ゴールドラットの著書「The Goal」に書かれています。
ソフトウェア企業に置き換えてみると、これは「販売/サブスクリプション収入を増やし、同時に未リリースのコードの量と製品の運用とサポートの費用を削減して収益を上げること」になります。
それぞれを紐解いてみると以下のようになり、全てお金と時間の観点から表現することができます。(以下、記事から引用)
- 販売／サブスクリプション収入
- これは、顧客が望む機能を提供することで可能になる。しかし、このプロセスの摩擦を減らす活動は価値がある。
- 未発表コード
- 開発／テスト／デプロイのパイプラインにあるコードは、まだビジネス価値を生み出していないと考える。それに加えて、エンジニアがそのコードを書くのに費やした時間の代償がある。これは従来、DevOpsの専門家がCI/CDを通じて重点的に取り組んできた問題だ。
- 運用／サポートコスト
- これは、インフラストラクチャの運用に関わるコスト、製品を運用するチームがオンコールで対応するために費やす時間、観測可能プラットフォームなどのサポートサービス、情報セキュリティやコンプライアンスに費やす時間と費用、製品のサポートを提供するカスタマーサクセスチームなどで構成される。これは一般的に SRE が取り組む問題領域である。
すなわち、DevOps/SREにおける目標は「支払われている給料よりも遥かに大きな割合で、お金や時間を節約・稼いでいること」になります。
例えば、CI/CDの効率・最適化、アーキテクチャのコスト最適化、最適な監視環境の整備、開発生産性の向上によるリリース速度の向上などによって、時間やお金の節約、並びにプロダクトとしての機会創出に寄与するようなことが挙げられると思います。
一見地味ではありますが、こういった活動が事業を支える大きな力となることを組織全体へ周知し、ひいては組織文化の醸成を推進していくためにも、いわゆる「営業力」も必要となります。
その他
Kube Weeklyが更新なかったので、その他に気になったものを紹介します。
Github New Organization List
昨年10月あたりにリリースされたCustom Properties （https://github.blog/changelog/2023-10-12-github-repository-custom-properties-beta/） の値や、リポジトリにおけるストレージ使用量などでフィルタリングができるようになったようです。
これにより、Custom Propertiesの活用性が広がり、リポジトリの管理に本格的に導入できそうになりました。
まだAPIは用意されていなさそうなので、Github CLIでシュッとフィルタリングした一覧を取れれば、シェル芸などにも活用できて、より便利になりそうですね。
おわりに
今年もよろしくお願いいたします！
Discussion