読了: 約 6 分

この記事を書く背景

  • CTO、VPoE、EMは読んでいる方が多いと思うが、検索したり聞いてみたところあまりPMで読んでいる人がいなかった
  • 価値あるソフトウェアを素早く届ける上で、「ソフトウェアの開発プロセス×チーム」が大事だと考えている
  • 開発プロセスはエンジニア組織が多くを担うことになる（現実はスクラムなどを実施してる場合KPTなどのフレームを用いてソフトウェア開発に関わるメンバーで実施する）が、ソフトウェア全体のチームマネジメント・チームづくりに関連する人は必読だと考えている

Offersの新規事業は、チームトポロジーに関連するようなソフトウェア開発組織のマネジメント領域で作っており、参考になる部分が多かった。

アーキテクチャ、プロセス、組織は濃く関わり合っていることを理解して、前に進めていくことが大切だと伝えたい。

誰向けの記事か

  • PM
  • 経営者
  • ソフトウェア開発組織のマネージャー

こんな方におすすめ

  • 開発生産性の向上について考え始めている方
  • 10名以上のソフトウェア開発組織がある企業のソフトウェア開発に関連するマネジメントの方
  • ソフトウェア開発チームが何を考えてチームを作っていくのか知りたい方

PMに関する職でも必読である理由

マクロ・ミクロでの組織構造や組織づくりの理解を深められる

  1. ソフトウェア設計と組織の基本構造を理解できる（マクロ）
    1. ソフトウェア設計、チームづくり、プロダクトの機能リリースは紐づいている
      1. 因果関係・開発組織の作り方の解像度が高まる
    2. エンジニア・PM・デザイナーなどの採用／アサインまで担当する場合、どのフェーズの事業・プロダクトでどういうチームを作るべきかが一定理解できる
  2. 生産性の高いソフトウェアチームづくりを理解できる（ミクロ）
    1. 認知負荷が高いことによる課題を回避し、生産性の高いチームづくりを意識できる

フェーズに関係ないPMとしての強さを身につける

究極の話、事業やビジネスやプロダクトの0−１の立ち上げは誰でもできる。ただ、事業・プロダクトを伸ばしていけるかが重要であり、チーム・組織を作れなければ大きくしていくことは難しい。どんな事業であっても規模が大きくなってくると組織化は必須だ。

コミュニケーション・人を動かす役割

PMは1ストリーム（ドメインやアプリケーション）のコミュニケーション・スケジュールマネジメント・一部チームマネジメントなど人に関わることがメイン業務である。PMが業務プロセスの設計・チームメンバーの状況を把握・確認・皆でのフィードバックをできてなければ、そのチームの生産性は下がる可能性が高い。

チーム・組織化について「何を、どのようにやっていけばいいのか」その一つの参考材料になるからである。

チームトポロジーとは何か

  • 偶発的なチーム編成するのではなく、継続的な設計によるチーム構造を作る組織設計のモデルのこと
  • チームの責任範囲を明確にしながら、組織内にチームを意図的に配置する

なぜこれが必要か

  • 早く継続的なデリバリー
    • ＝望むアウトカムを手に入れること≒事業・ソフトウェアの成長と成功
  • ＝早いフローを実現できる長続きする自律的なチームの上に成立する
    • ＝チームファースト

ソフトウェアの設計と組織の構造

チームトポロジーに出てくる組織構造などのワード

  • 組織構造の話
    • コンウェイ
    • 逆コンウェイ
  • 人月の神話
    • 人が増えたら、線形的に人月（リソース）が同じ分だけ増える
  • タックマンモデル
    • 1965年に心理学者のブルース・W・タックマンが提唱した、チームビルディングにおける発達段階を表したモデル
チームビルディングでファシリテーターである私が初めに話すこと｜タックマンモデル | 今が最高のプレゼント Present is the best gift
出典：https://blog.office-root.com/facilitation/tackman-model/

チームトポロジーでのチーム構成

  • ストリームアラインドチーム
    • １つのアプリケーションチームなどの単位で、ストリームアラインドチームは複数あるのが普通
    • 一例
      • ユーザージャーニー、ペルソナに基づいたものであること（弊社例：Offers toC、toBなど）
    • 求められること（特にPMに関与するもの）
      • 最新の変更に対するフィードバックに基づいて素早く軌道修正
      • フィーチャーデリバリーの安定したフロー作成
      • プロダクトの進化に実験的なアプローチを用い、常に学んで適応
      • 他のチームへの引き継ぎを最小限にする
      • 実現した変更フローの安定性と、技術面及びチームの健全性の観点での補助的なメトリクスで評価される
      • メンバーは、「自律」・「熟達」・「目的」を達成しようとしているか・達成していると感じる。モチベーションの高い知識労働者の3つの重要な要素
  • イネイブリングチーム
    • 役割
      • CI/CD
      • インフラ
    • 求められること
      • 定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意
      • イネイブリングチーム内の学習だけでなく、ストリームアラインドチームを横断した学習も促進するため、組織内の適切な情報共有を促すキュレーターとして活動する（トム・デマルコとティモシー・リスターが「キー学習機能」と呼んだ機能をサポートする
  • コンプリケイテッド・サブシステムチーム
    • 個別具体なチーム
      • 動画処理コーデック、数理モデル、リアルタイム最低アルゴリズム、金融サービスのトランザクションレポート、顔認識エンジン
      • このチームはそこまで多くならない
    • 役割
      • スペシャリストの知識が必要となるパーツを開発、保守する責任を持つ
      • サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位をつけて変更をデリバリーする
  • プラットフォームチーム
    • データ含む基盤
    • 役割
      • ストリームアラインドチームが自律的に仕事を届けられるようにすること
    • 目的
      • 内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる

チームづくり

  • チームづくりの要点
    • コミュニケーションパス
    • 適切なチームサイズ
      • 単一チームが取り扱える認知負荷には限界がある
      • 単一のチームが取り扱えるソフトウェアシステムとドメインの複雑度にも制限がある
    • チームファーストのマインド
  • サイロ化を避ける
    • テスト、QA、UX、データ処理
    • 安全で速い変更フローに最適化された組織では、多能工型または職能横断型チームを変更のフローに沿って配置することが多い
  • 職能横断型チームで物事をシンプルに保つ
    • 一番シンプルでユーザーフレンドリーなソリューションを見つけ出そうとする強い力が働く
  • 理想のチームとアーキテクチャ
    • 設計からデプロイまでコミュニケーションを用いなくても完遂する能力を促進するアーキテクチャを生み出すこと
    • チームのことを考慮に入れないで進めると、モノリスを間違った形で分割したり、サービス同士の依存性が高い複雑なシステムを作り出したりするリスクがある。＝「分散モノリス」
      • すべての変更で他のサービスの更新が必要となり、サービスの自律性を欠く

ソフトウェア組織の認知負荷軽減

認知負荷とは

  • ワーキングメモリに対してかかる負荷のこと
  • ワーキングメモリとは、作業や動作に必要な情報を一時的に記憶・処理する能力

認知負荷が高いことによるデメリット

  • 集中力が下がる
  • モチベーションが下がる
  • 結果、生産性が下がる。チームとして継続がしづらくなる

認知負荷の構成要素

  • 認知負荷を制限するための施策
    • ツールを限定する
      • 量＝コミュニケーションパス
      • 学習コストが上がる→生産性が下がる
    • 役割を定義する
      • 広い役割を継続して持たせない
        • 人のケイパビリティによる
      • コンテキストスイッチを減らすことが大事
      • コンテキストスイッチが多い＝切り替える時間が増えるので生産性が下がる
    • 関わり方
    • レスの速度、品質
      • それを求めない、それが負荷と比例するため。
      • 業務の進め方の設計で解決策を考える

開発組織の生産性向上のためにやろうと思ったこと

Four Keysなどの指標を用いてチームの現状を把握

こちらは既にやっていることではあるが、Four Keysとは別の指標を用いてはかる予定。Four Keysでは「マッチョなエンジニア組織」は作れると思うが、「PMやデザイナーも含めた良いソフトウェア開発組織」を作るための参考にはなりづらい指標であるからだ。

  • 正常なデプロイ１回あたりにかかる時間
  • １日あたりの正常デプロイの絶対数
  • 失敗したデプロイの修正にかかる時間
  • コードコミットからデプロイまでの時間（サイクルタイム）

Product Ops

開発生産性はいくつかの定義がある。
プロダクトが生み出すアウトカムを最大化する＝生産性と捉えるならば、開発生産性に間接的に関わるものである。

  • 目的
    • プロダクト開発に必要な項目をチーム間でシェアし、1対1ではなくチームでの強化を図ること
    • コミュニケーションを活性化させ、自律駆動的なチームを作ることによって全体の生産性を向上させる
  • 役割
    • 必要な情報を必要なタイミングで継続的にチームにデリバリーすること
  • Ops項目
    • KPI
    • 顧客の課題や求められていること
    • その他の情報の一例
      • デリバリーの速度
      • デリバリーの内容
      • Product KPI・事業KPIと関係のありそうな機能と数値

チームトポロジーに登場する書籍

チームトポロジーで紹介されている書籍も関連書籍として一部を紹介する。

  • チームオブチームズ
  • 強いチームはオフィスを捨てる
  • ScalingAgile@Spotify（Spotifyのスケーリングアジャイル
  • LeanとDevOpsの科学

最後に

「チームトポロジー」はエンジニア組織のマネジメントだけでなく、ソフトウェア開発組織マネジメントPM、デザイナー、データ系職種の方々も読んでおくと学びがあると思う。

良いチームを作る最初の一歩は、組織構造やコミュニケーション設計に関わる条件や内容を理解、言語化し、共有し、皆で理解を深めることであると考えている。