ダイナミックリチーミング 第2版

推薦のことば
ジョン・カトラーによるまえがき
ダイアナ・ラーセンによるまえがき
はじめに

第I部　ダイナミックリチーミングとは何か？

1章　チームの進化
    1.1　パナーキー

2章　チームを理解する
    2.1　チームとは何か？
    2.2　ダイナミックリチーミング
        2.2.1　ダイナミックリチーミングはいつでもうまくいくのか？
    2.3　チームのソーシャルダイナミクス
        2.3.1　時間とともにチームは変化する

3章　チーム配属の威力
    3.1　「上の」誰かがチームに押し付ける
    3.2　マネージャーがチームメンバーを決める
    3.3　チームを変えたい意思を尋ねるアンケート調査を行う
    3.4　マネージャーがチームへの自発的な参加を促す
    3.5　マネージャーやリーダーが自己選択の機会を用意する
        3.5.1　自己選択で組織再編をした会社の話
    3.6　チームが戦略を立て独自のチーム構造を形成する
        3.6.1　チームが解決すべき問題としてのリチーミング
        3.6.2　チームメンバーが自主的に配置換えしてマネージャーに伝える

4章　リスクを減らし持続可能性を高める
    4.1　リチーミングは知識のサイロ化を減らす
    4.2　リチーミングはキャリアの成長機会を提供し、チームメンバーの離職率を減らす
    4.3　リチーミングはチーム間の競争を減らし、チームの全体感を醸成する
    4.4　リチーミングはチームの硬直化を防ぎ、新しいメンバーを迎えやすくする
    4.5　リチーミングは起こるべくして起こる

第II部　ダイナミックリチーミングパターン

5章　ワンバイワンパターン
    5.1　新しい人を既存のチームに追加するか？ それとも新しいチームを作るか？
        5.1.1　チームに種をまく
        5.1.2　組織設計の活動にメンバーを含める
        5.1.3　文化と開発プラクティスを維持する採用
        5.1.4　新しいチームメンバーの参加を計画し、コミュニケーションする
        5.1.5　新しい人がオフィスに来るまでに準備しておくこと
        5.1.6　新しい人に注意を払い、影響を与えるようマネージャーに促す
        5.1.7　新しい人だけでなく、周りにいる人たちもサポートする
        5.1.8　新しい人にメンターを割り当てる
        5.1.9　新しい開発者のオンボーディングにペアプログラミングを使う
        5.1.10　シャドーイングを推奨する
        5.1.11　新しい人に自身のことを共有してもらう
        5.1.12　ブートキャンプで新しい人がネットワークを作るのを手伝う
    5.2　人が去ったらチームは新しくなる
        5.2.1　人を解雇する―メンバーを外してリチーミングする
        5.2.2　自発的退職
        5.2.3　さよならを言う―退職をアナウンスするか？
        5.2.4　人がチームを去った事実と向き合う
        5.2.5　チームの人たちの進化
    5.3　ワンバイワンパターンの落とし穴
        5.3.1　シニアとジュニアのバランスが取れていないことに気がつく
        5.3.2　メンター疲れ
        5.3.3　キャリアパスを最初から考えない

6章　グロウアンドスプリットパターン
    6.1　チームを分割したくなるときのサイン
        6.1.1　ミーティングが長引いているか？
        6.1.2　意思決定がより難しくなっているか？
        6.1.3　チームの作業の関連性が失われているか？
        6.1.4　分散チームに誰がいるのか忘れているか？
    6.2　分割することを決めたら、どのように進めていくか
        6.2.1　決定にチームを巻き込む
        6.2.2　チームを分割する理由を明確にする
        6.2.3　新しいチームのミッションを明確にする
        6.2.4　誰がチームに残るのか決定する
        6.2.5　新しいチームのための座席配置計画を立てる
        6.2.6　チーム名を決める
        6.2.7　チーム配属を他の人に知らせる
        6.2.8　新しいチームの正式なキックオフをする
    6.3　グロウアンドスプリットパターンの落とし穴
        6.3.1　チーム間で人を共有する
        6.3.2　分割後のチーム間の依存に対処する
        6.3.3　分割を先延ばしにする
        6.3.4　設備部門やIT部門の巻き込みが遅い
        6.3.5　チーム分割の感情的な課題
    6.4　大規模な分割
        6.4.1　トライブレベルの成長と分割
    6.5　コードのオーナーシップを促進するための成長と分割
    6.6　「私たちの文化をどのように維持すればよいですか？」と尋ねられることの意味

7章　アイソレーションパターン
    7.1　会社が失敗からピボットするためのアイソレーション
    7.2　新プロダクト開発のためのアイソレーション
    7.3　会社で新たなイノベーションを起こすためのアイソレーション
    7.4　技術的な緊急事態を解決するためのアイソレーション
    7.5　アイソレーションパターンのスケーリング
    7.6　アイソレーションパターンの一般的な推奨事項
        7.6.1　起業家精神を持つ人をチームに招き入れる
        7.6.2　チームに働き方は自由であることを伝える
        7.6.3　チームを自分たち専用のスペースに移動する
        7.6.4　他のチームに邪魔しないように伝える
        7.6.5　チームを継続するか、他のチームに戻すかを決定する
    7.7　アイソレーションパターンの落とし穴
        7.7.1　エリート主義
        7.7.2　コードのメンテナンスをどうするか？
        7.7.3　刺激的な旅もいつかは終わる

8章　マージパターン
    8.1　チームをマージしてペアプログラミングにバリエーションを持たせる
    8.2　トライブをマージしてアライアンスを形成する
    8.3　会社レベルでのマージ
    8.4　チームレベルでのマージパターンの落とし穴
        8.4.1　大きくなった新チームをキャリブレーションしない場合
        8.4.2　大きくなった新チームをリセットまたはファシリテーションしない場合
        8.4.3　大きくなったチームでの意思決定方法を決めない場合
    8.5　会社レベルでのマージパターンの落とし穴
        8.5.1　人員整理を長引かせる
        8.5.2　人員整理を巡る曖昧さ
        8.5.3　大混乱の買収

9章　スイッチングパターン
    9.1　チーム内でペアを交代する
    9.2　問題解決のためにペアを丸ごと交代する
    9.3　知識の共有と機能の支援のためにチームを移動する
    9.4　知識を共有するために定期的にスイッチングする
    9.5　友情とペアリングのために開発者をローテーションする
    9.6　個人の成長や学習のためにスイッチングする
    9.7　スイッチングパターンの落とし穴
        9.7.1　優秀なチームメンバーを囲い込みたいという欲求
        9.7.2　他のチームにメンバーを「貸し出す」ときが課題となる
        9.7.3　単独の専門家で構成されたチームはスイッチングが制限される

10章　アンチパターン
    10.1　「ハイパフォーマンス」を広げる
    10.2　兼任アンチパターン
    10.3　生産的なチームを標準もしくはベストプラクティス準拠で破壊する
    10.4　ひどいコミュニケーションと抽象化によるリチーミング
    10.5　有害なチームメンバーのインパクト
    10.6　有害なチームを維持する

第III部　ダイナミックリチーミングをマスターするための戦術

11章　組織をダイナミックリチーミングに適応させる
    11.1　ダイナミックリチーミングのエコサイクルにおける自分の現在地を探る
    11.2　リチーミングに関する組織的な制約と促進要因
        11.2.1　リチーミングを制約および促進するコラボレーションダイナミクス
        11.2.2　ダイナミックリチーミングに影響を与える変数
    11.3　ダイナミックリチーミングに向けて備えさせる
        11.3.1　ダイナミックリチーミングを採用プロセスに組み込む
        11.3.2　コミュニティを育てる
        11.3.3　チームをまたいで役割を調整する

12章　ダイナミックリチーミングの取り組みを計画する
    12.1　ダイナミックリチーミングのFAQを作る
        12.1.1　リチーミングによって解決したい問題は何ですか？
        12.1.2　どのようにしてチームに人が配属されますか？
        12.1.3　新しいチームへの配属があるのかをどのように知りますか？
        12.1.4　特に既存のチームはどのような影響を受けますか？
        12.1.5　既存の仕事はどのように影響を受けますか？
        12.1.6　新しいチームはどのような構成ですか？
        12.1.7　リチーミングの前後で組織はどのように変わりますか？
        12.1.8　リチーミングの取り組みで、どのような技術システムや機器の更新または導入が必要でしょうか？
        12.1.9　リチーミングに伴い、どのような座席配置やオフィスの変更が必要ですか？
        12.1.10　リチーミングに伴い、どのようなトレーニングや教育が必要ですか？
        12.1.11　リチーミングの取り組みに向けたコミュニケーション計画はどのようなものですか？
        12.1.12　リチーミングの取り組みのスケジュールはどうなっていますか？
        12.1.13　リチーミングの取り組みへのフィードバック計画はどうなっていますか？

13章　ダイナミックリチーミングのあと：移行とチームキャリブレーション
    13.1　予期しないダイナミックリチーミングに対処する
        13.1.1　トリガーに気づいたら注意を向ける
        13.1.2　変化についてリーダーと1on1で話す
        13.1.3　物理的もしくは精神的に距離を置く
        13.1.4　ダイナミックリチーミングを進めるときは共感が必須
    13.2　移行―ダイナミックリチーミングでのコーチング
        13.2.1　終わりについて話す
        13.2.2　儀式で終わりを示す
        13.2.3　何を受け継ぐか提案する
    13.3　チームキャリブレーションセッション
        13.3.1　歴史のキャリブレーション
        13.3.2　人と役割のキャリブレーション
        13.3.3　仕事のキャリブレーション
        13.3.4　ワークフローのキャリブレーション
    13.4　チームの規模が2倍になったあと
        13.4.1　組織の成長を「見える」ようにし、お互いの名前を知る
        13.4.2　共通の目的を見つけギルドを形成するのを助ける
        13.4.3　歴史の共通理解を助ける
        13.4.4　文化の変化について直接話す

14章　過去をふりかえり、今後の方向性を決める
    14.1　チームでのレトロスペクティブ
    14.2　複数チームでのレトロスペクティブ
    14.3　取り組みについてのレトロスペクティブ
        14.3.1　レトロスペクティブの参考資料
    14.4　1on1
    14.5　調査ツール
    14.6　メトリクス

15章　まとめ

付録A　オープンなダイナミックリチーミングを可能にするホワイトボード
    A.1　必要な備品と作成物
    A.2　やり方

付録B　チーム選択マーケットプレイス
    B.1　備品と作成物
    B.2　場所
    B.3　実施方法
    B.4　応用
    B.5　リソース

付録C　調査テンプレート

参考文献
訳者あとがき
謝辞
索引

コラム目次
    意思決定の5本指
    エコサイクルによる状況把握活動
    コンテキスト分析の活動
    TRIBE ROLE ALIGNMENTの活動
    あなたのインパクトを明らかにする活動
    チーム移行の活動
    私たちのチームのストーリー
    スキルマーケットの活動
    ピーク体験の活動
    ワークアラインメントの活動
    OWN YOUR WORKFLOWの活動
    リチーミングの調査