概要
現代のソフトウェア開発では顧客への価値を迅速に創出し、継続的に提供することが重要とされています。本書ではコンウェイの法則を基底として、それを実現するためのチーム設計思想を解説します。また、適したチーム構造やチーム間の連携方法を4つのチームタイプと3つインタラクションタイプを用いて解説します。これらのモデルを理解することで自組織との差分や課題を理解し、改善する上でのヒントを得ることができます。
批評
価値を素早く継続的に生み出すためのチーム設計が多くの根拠とともに構造的に解説されており、納得しながら理解ができる良い書籍でした。4つのチームタイプや3つのインタラクションタイプ（チームごとの関わり方）もとても良い粒度で汎化されており、自組織との比較や課題抽出に役立つと思います。組織設計をする立場の方には特におすすめです。
私はこの本を読むことで、開発組織がどうあるべきかという1つの軸を持てたのが良かったと感じています。そのあるべき姿に対して自分がどう貢献していけるかや、こうしたら良いかもを仮説として考えられたのも今後の糧になると思います。特にSREのような各組織やフェーズで役割が変わるポジションの方は、自身の役割を整理することができるのでおすすめです。また、自身がどのように役割を変化していくと良さそうかなどの気づきも得られるでしょう。では、いくつか面白かった点をピックアップしてみます。
チームがオーナーシップを持てるようにする
最終的なゴールは、顧客のニーズに合うソフトウェアをチームがより簡単に構築、実行し、オーナーシップを持てるようにすることである。
この文は私の考えるチームのあるべき姿になりました。近年の様々プラクティス（DevOps, SRE, マイクロサービス...etc）は上記を実現するためのものだと考えています。
本書で上記を実現するために説明されているチームタイプを簡単に紹介します。
- ストリームアラインドチーム
- 職能横断型で価値を生み出す活動を全て実施する。例えば初期の要求探索から本番運用までの能力を一式備えている。
- 他の3つのチームタイプはストリームアラインドチームの負荷を減らすことが目的である。
- イネイブリングチーム
- ストリームアラインドチームがその時点で持っていない必要な能力を獲得することを助ける。
- コンプリケイテッド・サブシステムチーム
- 職能横断型であるストリームアラインドチームが対応しきれない専門性を補うチーム。
- 例えば高度なDB関連のチューニングなどを行う。
- プラットフォームチーム
- 内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。
- インフラの運用保守をする専門部隊ではない。
まとめてみましたが、深い理解にはぜひ本書を読んでいただきたいです。
SREはストリームアラインドチームの一種
本書ではSREはストリームアラインドチームの一種であると述べています。まあ当然、それも一つの正解ですね笑 日本のSREは以下４つ役割を複数担う印象です。
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- プラットフォームチーム
- 本書では作らないべきとされる運用保守チーム
例えばマネーフォワード さんだとSREと名の付いたチームはイネイブリングチームに相当しそうですが、freeeさんだとイネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームに該当しそうです。
私のSREチームはどの役割を担うのかはまだメンバと語り合えていません。1つ言えることは運用保守チームではないことです。本書における最低ラインはクリアできそうですね。今後語る上でも本書のチームタイプのモデルはとても有用だと感じています。
