前書き
2023年9月にLeSSの講演で有名なバス氏のイベントに参加してきた際、
コンポーネントチームとフィーチャーチームの違いについて説明されるイベントであったので、
その内容をここに残す。
LeSSイベントでバス氏からの内容とチームトポロジーの内容が深く関連付けられた。
前提知識
ストリームアイランドチーム
チームトポロジーで扱われる、主なチーム形状のことであり、
ちょうど１つのドメインサービスを担当するチームである。
サービスの規模が小さい場合には、運用コンポーネントの方の責務も担う。
LeSSの背景
多くのチームにとっては、チーム間の結合度合いは疎結合であるべき
という既存の常識を真っ向から否定した発想がこのLeSSである。
①経営サイドからのトップダウンと、業務に詳しい現場からのボトムアップ
その両方をチェックして組織の方向性(経営方針)を全員揃えるとなると、
どうしてもゆっくりになってしまう。
②かといって、素早さを追求し過ぎるとその方向性が揃わない。
人が多かったり、組織構造が深い階層だと、なおのこと方向性を揃えるのは困難になる。
LeSSでは、デリバリーの早さよりも正しい方向に進むことによりイノベーションを活性化することを重要視している思想である。
そのため、①に該当するので、当然デリバリー速度は②に比べたら落ちる。
丁度チームトポロジーで言う、インタラクションの中の
【コラボレーション連携】を組織全体で行うイメージである。
コンポーネントチームとフィーチャーチームの概要
２つの概要図は上の図の通りである。
多くの不確実性の高いプロジェクトでうまく行かない理由は、ここにまず集約されると思っている。
というのも、大規模エンタープライズ系でいきなりチームがいくつかに分断されているのだ。
実際に皆さんもあると思うが、分断されたチームの境界が時には組織の壁であったりする。
すると、お客さんの資料待ちが発生したりし、その間にも納期までの制限時間は
刻一刻と迫っていて、なんてことが起きてしまう。
そもそも顧客組織とコラボレーションするのにもかかわらず、
自社と相手組織っていう風に最初から分断したチーム境界の定義の仕方がおかしい。
だってよく考えてみてほしい。
プロセス面において、自社で考えているビジネスフローと相手組織で扱っている
ビジネスフロー、この一連の連携からコラボ案件で実現したいさらに上位目的があるわけだから。
だからドメインサービスの境界の位置だって、下図のようになりうるはず。
すると、どんな現象が起きるかっていうと、
自社の組織内の他の人との連絡のやり取りよりも、コラボ先の組織の人との連絡の頻度の方が密になっているということ。
ドメインごとのコンテキスト境界の大切さ
分散モノリス化されたチーム構造
他の組織とコラボして、さらに上位の目的を達成指定という時に、
不確実性の高いビジネスにおいては、そもそも最初からサービスのコンテキスト境界が
明らかになっている箇所の方が少ないように感じる。
この境界の定義の仕方が、最初から他の選択肢と比較されずに、
ありきたりな自社フロントエンドチーム、自社バックエンドチーム、
自社ビジネスサイドチーム、相手先フロントエンドチーム、相手バックエンドチーム、
みたいな職能別な切り方をされていると、
「そちらにあるこんな情報をこっちにください」と連絡
→相手側も大忙しであったりして、その間待ちが発生。時にはこちらから何度も催促するなんて現象が起きる。
しかも連絡に気づいていなかったとかいうケースもあれば、
情報を所有している部門に「受託先にこんな情報を返さないといけないから、
情報へのアクセス権限を付与してください」
→またここで、価値を生んでいないどころか、足かせになっている承認プロセスが走るなど、
適切にコンテキスト境界が定義されていない縦わり分断と、
情報の所有権の割当が、なんとなくで組織が運用されていることによって、
全体的なパフォーマンスが非常に悪いという現象を自分はあるDX案件で体験した。
これは同じ組織内での分断ならまだかわいい方で、組織の壁という分断となると、
さらにビックスケールな分断になってしまうので、遅延時間は組織内の分断よりも
めちゃくちゃ長くついてしまっていた。
状況に応じたチーム形状の変化
境界付けられたドメインのコンテキスト境界もあるシーンに応じた戦略を
満たすためのサービスコンテキストでしかなく、
その置かれた外部環境などの前提が変われば、当然最適なチーム構造も変わる。
このVUCAの時代においては、置かれた前提条件なんて目まぐるしく変わるので、
当然さっきまでの前提条件において適切なコンテキスト境界の位置が、
新しく更新された前提条件においても適切な切り分け境界の位置とは断言できない。
なので、置かれた外部環境などの前提条件が変われば、
チーム内においてもっともバリューを生み出しているコアドメインの部分も
当然変わってしまうということを表している。
組織構造は、一か所にフィーチャーチームのように集結したり、
各ドメインごとの分散されたマイクロサービス型のチーム体制を取るなど、
ころころその形状を変えられるのが望ましいのは、チームトポロジーを読んでいても感じたことである。
職能横断な越境活動
ストリームアイランドチームでは、職能横断な動きが求められる。
たとえば、専門分野はバックエンドの人がフロントやセキュリティなども浅く広くやること。
ただ、１人がマルチにやるには限界があるので、
スクラムチームに様々な観点を持った人材が集まるようにチーム全体で、
ストリームアイランドチームの能力を発揮できるようにチーム設計を行う。
ただし、せっかく考えた境界付けられたコンテキスト、チームの境界も
前提条件となる置かれた想定シーンが変わってしまうと、それに適した境界の位置は変わってしまう。
事前に代表的な想定シーンでの組織構造は考えた上で、
突然の災害など予想だにしなかった想定シーンにおいては、
無理に職能別に分断された体制のままにするのではなく、
一度フィーチャーチームのように組織全体が１つの泥団子状にあえてなることで、
その状況に応じて自分たちで連携のとりやすい境界を見出していくのがベターと考えられる。
その際に、浅くでもいいから他の専門分野のことを知っておくことで、より最適な連携が実現できる。