All Articles

チームトポロジー part.1

所感

ソフトウェア製品を提供する企業としてアウトカムをあげていくためには組織の構造をうまく変えていく必要があるということがわかり、自分が勉強してきたソフトウェアアーキテクチャをよくしていくのはこの下のレイヤにあることがわかった。

要は、あるチームのソフトウェアアーキテクチャがよくても全体としてみたときに他のチームの負荷になっていたり、また別のチームが孤立していたりすると企業としてはリスクになる。

組織構造に関する狙いとしては、チームが なるべく 独立して設計からデプロイまで作業を行えるようにし素早く顧客に価値を届けられるようにすることがある。
これを実行するためには、チームの役割を明確にし、チームを適切な範囲で構成する作業を行う必要がある。そして、チーム間のコミュニケーション方法も定める。
もちろん、一度でうまくいくことはないと思うのでチーム間でのコミュニケーションは最初に多くなるだろう。このコミュニケーションのやり取りでの負荷や頻度を見て再度適切な境界をみていけばよい。

チームが独立して動くためには依存はなるべくないほうがいい。そのため、ライブラリの依存はできるだけ断ちたい。共通の資産をもたせないためにも新しいチームは全く別の技術スタックを使ってしまうのもあり。そうすることで、既存の資産は全く使えなくなりチーム間のコミュニケーションは発生しない。お互いのことを知っていなくてもよい。それぞれのチームで責任をもってシステムを進化させていけるから。

また、逆コンウェイの法則を利用しソフトウェアが完成する前にチーム間のコミュニケーションを再構成するのもありだとされている。逆コンウェイの法則とは、その名の通りコンウェイの法則を逆手にとったもの。
コンウェイの法則が組織の構造がソフトウェアの構造に現れるということを逆手に取って、理想のソフトウェア構造から逆算して組織構造を構築してしまうこと。
コンウェイの法則でわかりやすかった例は、コンパイラを4チームで作ると4段階のコンパイルが必要になってしまうということ。(それぞれのチームが構文解析器を作ってビルドするため。)極端な例かもしれないが想像しやすくてよかった。
このような成果物のパイプが多ければ多いほど、目的物のデリバリは遅れてしまう。(各段階でQAや結合が必要になるので)そのため、本書では特定ドメインを解決するためのチームを組み、そのソリューション実行までを一貫して行えるようにチームを組むとよいとしている。(後述のストリームアラインドチームである。)

こういったことは、小さな会社でこれから大きくなるときの組織変更に大いに役立つ。大きな会社のチームの一員だとしても普段のコミュニケーションや自分たちの作業が何かにブロックされていることに違和感を感じて本書のような構成にすることを提案することに役立つかもしれない。

組織のデザインをするのは、役員クラスやチームより上位の役職についている人たちがやることだとは思うが、ボトムアップで意見を言えたり、次期チーム編成案に意見を言えるようにするのは大事だと思う。なぜなら、間違ったチーム編成が進むと組織全体で苦労することになるから。

チームの一員からみたときの現況から次のチーム構成になったときをシミュレーションして、こういう負荷が増える、こういうところが解決されるというのを理解してはおきたい。また、こういうチーム編成にするならば、こういったコミュニケーションを減らすためにこのアーキテクチャにする必要があるという提案もしたい。それは、チーム編成をするだけでは意味がなくて、そのチームにあうような構成を進められないのであればチーム編成によるメリットを享受できないはずだからだ。

チームの種別

4種類。4種類と決めて大別することで、組織内のあいまいさを減らせる。

  • ストリームアラインドチーム(以降SA)

    • ストリーム → ある領域の E2E のこと
    • 運用もサポートもやる
    • E2E が担当範囲なので運用の近くにもいるため
    • 組織には複数のストリームがある
    • 顧客向け
    • 社内向け

    • ユーザペルソナ

      • デバイスなど

  • プラットフォームチーム(P)

    • SA が使う内部的なサービスを提供

    • ある領域から下位は意識せず開発できるようになる。例えば、k8s が提供されていれば定義ファイルを書くだけでデプロイが可能になる

      • 使用が強制されるような内部プロダクト
      • 価格を決めるとそれぞれのチームが無理難題を言わなくなる。(ここまでいけたらすごいと思うけど策定するのがコストになりそう)

  • コンプリケイテッド・サブシステムチーム(C)

    • スペシャリストの知識が必要となるパーツを開発・保守する。
    • 動画処理。数理モデル。機械学習モデル。
    • サブシステムの認知負荷が大きい場合に必要
    • インターフェースが適切でないと利用する側に負担がかかるので設計は重要

  • イネイブリングチーム(E)

    • スペシャリストで構成され、SAなどの能力ギャップを埋めるのを助ける。
    • SA は多大な労力をかけずに能力を獲得できる

基本的に複数 SA のスループットを向上させるために他のチームが存在し、素早くデプロイすることでアウトカムを最大化していく方針になっている。

チームのコミュニケーション

コミュニケーションも大別して定義することで、それ以外のコミュニケーションは意味がなく、チームの責任境界などの設計がよくないという目印になる。
チームの役割に応じて、どういったコミュニケーションをとるのが正解か判断できる。例えば、SA同士でコラボレーションを選んで協業し素早い問題解決を目指す。

  • X-as-a-service

    • 最小限のコラボレーションで何かを利用。または提供。
    • ex. SA が k8s の api を使ってデプロイする
    • 提供するサービスは使いやすくなってないと意味がない

  • コラボレーション

    • 他のチームと密接に協力して作業すし、問題の早期解決や学習を行う
    • SA があるサブシステムを作るコンプリケイティッドチームと協業する
    • デメリットはチーム間で広く共有される責任

  • ファシリテーション

    • 障害を取り除くために他のチームを支援したり、支援を受けたりすること
    • イネイブリングチームの主な仕事
    • 学習支援など

Published 25 Dec 2021

Software engineer at Tokyo. smith-30 on Twitter