読書メモ。2025年32冊目。
『ダイナミックリチーミング 第2版―5つのパターンによる効果的なチーム編成』を読んでの感想となります。（2025/5/17記載）
本の概要
企業の急成長や買収などによりチームは常に変化するものです。本書は効果的にチームを再編成する方法を解説します。チームに変化を促し、不測のリスクを回避し、学習やキャリアの停滞、サイロ化を防ぐためのチームの再編を学びます。
チーム変更の5つのパターンを紹介し、新入社員を既存のチームに入れたり、集中的なイノベーションのためにチームを分けたりする方法、知識を共有するためにチームメンバーをローテーションする方法、チーム変更後にすばやくチーム内の理解をそろえる方法、組織内で広がる無関心や無気力を乗り越え、変革や改善を推進する方法を事例を使ってわかりやすく説明します。
引用：
動機
- 『Effective DevOps』、『チームトポロジー』でチームの構造が開発に与える影響を痛感した。
- 先日のデブサミでの吉羽さんの講演に大きな刺激を頂いた。
- チームを活性化させていくために何ができるかを考えたい。
感想
好むと好まざるとにかかわらずチームに変化が求められるのであれば、「どう変化していくか」を決断していくのはチーム自身である方が望ましい。
なぜそれが望ましいのか、そしてそのための具体的な方法を教えてくれる一冊でした。
『Effective DevOps』や『チームトポロジー』を通じて、サイロをなくすことやチーム設計の重要性について理解したつもりでいましたが、
それが「外部の人間が設計する」ことや「他者がサイロを壊す」ことではなく、チーム自身が定義し直すことこそが重要なのだと、本書を通じて気づかされました。
開発チームが、自らの業務にオーナーシップを持つためには、自分たちが築いた足場の上で動けることが不可欠なのだとイメージしています。
チームの自己組織化について改めて考え直す、大きな学びのある一冊でした。
忘れたくないメモ
■ダイナミックリチーミングの前提
人間を尊敬し思慮深く扱うことなしに、ダイナミックリチーミングを組織にインストールすることはできません。
チームを無機質なものと同じように扱ってはいけない。
特に契約次第でメンバーが増減する受託企業では注意したい。
■ペアのチーム
ペアがどのように一緒に働くかは重要です。ペアプログラミングをしていれば、ペアは「チーム」になるのでしょうか？共通のゴールに向けて調整しながら、並列で作業を進めていても、チームでしょうか？私ならどちらもイエスです。チームたらしめるのは、共通のゴールとアウトカムに対する共同のオーナーシップです。両者がアウトカムに責任を持つなら、それはチームです。両者が双方の共同作業の内容に責任を持つなら、それはチームです。
複数人が同じゴールとアウトカムに一緒に向き合うのであれば、それはチーム。
逆に、一緒に動いていてもそれがずれていればチームではないという話と理解しました。
■チームに新たに人が加わるということ
ダイナミックリチーミングは新しい「チームシステム」や「チームエンティティ」を作り出します。チームに新たに加わった人は、チームに自分の関心や能力を持ち込み、チームに存在する集合知に影響を与えます。チーム全体に、新たな学習機会やアイデアをもたらします
既存のチームに人が増員される場合、学習・適合するのはその人であると盲目的に思っていることに気付きました。
新しい人が加わればチームは変化し、状況に適合し、成長していく。
そのうえで今までできなかったことができるようになる。
■意図的なリチーミング
会社を学習コミュニティとして見ると、創造的なリチーミングによって多くの人と協力できます。組織内でリチーミングを意図的に計画する場合、それは新たな学習機会を提供することになるのです。人間は学習しないと飽きてしまいます。このようにして停滞を避けることで、従業員の退職防止にも役立ちます。
所謂社内版ビズリーチのような流れもこの一種であると理解しました。
組織単位でもリチーミングができる。
■自分たちでリチーミングをする
私は、チームが自分たちで構成を考えて、大きな効果を出すにはどう変えればよいかを決めるように勧めています。構造をどう変えれば、チームがもっと効果的になるでしょうか？このような質問をすることで、チームは1つのエンティティとして自己認識を高めることができるようになります。
チームが自分たちの成長にオーナーシップを持って取り組む重要性。
■今いるところからチーム編成を調整する
ダイナミックリチーミングの大前提は、今いるところから始めることです。チームの構造を見える化しましょう。観察して、チームのことを知るようにしましょう。定期的にふりかえって、チームを調整することに合意しましょう。実験し、学習しましょう。それを踏まえて、チーム編成を調整します。チームを変えるツールとしてのレトロスペクティブについては、14章を参照してください。
チームを見える化し、調整できる状態を作ること。
そのうえで、レトロスペクティブで編成を調整していくこと。
改めて、スクラムはチームの共有モメンタムを醸成する仕組みであるとも理解しました。
■マネジメントの限界
マネージャーは直属の部下のスキルや人柄を理解しているつもりかもしれないが、関係性は指数関数的に増えるので、人間関係の複雑さを理解することはますます難しくなる。経験上、10人程度が限界だ
私にとっても同じイメージでいます。10人以上の人間を見れない。
■チームの共有知識の情勢
みんなモブからモブへ開かれた流動的な方法で移動できるようになりました。各チームで何が起きていたかについてレトロスペクティブをすると、同社は「少し速すぎる。メンバー間で情報が保持されていない」ことに気づきました。どこかを変える必要がありました。そこから、クリスが「交渉ベースの再形成」と呼ぶものが始まりました。
チームで動くのではなく個々人が動くと属人性が高まっていく。
チームでものごとを捉えていくと、そのための時間は必要になる。
ただ、結局最後には属人のリスクは解消できるし、一人でつくるものより良いものが作れる気がします。
■チームの相互作用の質
ベアプログラミングやテスト駆動開発はチーム内のバス因子を高める効果的な方法です。ここで重要なのは、チームの相互作用の質です。他の人の視点から学ぶことができます。多様性が高まり、より安全になるでしょう。
他の人の知見を学ぶこと。自分の知見を客観的に捉えることができること。
なによりお互いの思考のすりあわせができることが重要。
■サイロ化を解消するためのリチーミング
仕事を迅速に進め、全体像を気にかけられるよう、適度なコードのオーナーシップは必要ですが、特定の人やチームが「その機能」だけに固定されるようにはしたくないのです。サイロ化は自然に発生します。このことを念頭に置いて注意し、発生した場合には積極的にリチーミングしましょう。
新規の第三者がチームに加わることは、今まで暗黙の共通認識とされていたものが目に見える形となり、チーム内ですりあわせができる状態になるとイメージしました。
■チームの単位
チームへの帰属意識が強くなりすぎるという表現が興味深かったです。
チームとしての健全な同調感がある気がしています。
■知識のサイロ化を低減する
強すぎる帰属意識と同様に、新しいメンバーが加わることで言語化されていなかった当たり前が、改めて見える状態になると理解しました。
■オンボーディング
オレゴン州ポートランドの Jama Software のエンジニアリングマネージャーであるクリスチャン・フエンテスは、新しく入った人が適応するのにペアリングが役立つ理由を語ってくれました。「誰か新しい人を連れてきて、すぐに「生産的」であることを期待するのは無理です。コードを修正するのに、コードレビューでは遅すぎるし、難しいです。チームの技術プラクティスや技術的な一貫性、チームの文化などは、徐々に慣れていってもらうしかありません」。
特にチームの文化は誰かと一緒に作業をしないと、理解が個々の認知に偏りそうなイメージをしました。
ペアプロ、モブプロを通してメンバー同士が同期化する取り組みが重要。
■当事者に選択肢を与える
この「再起動」の方法は興味深いものです。なぜなら、その意図が非常に人間主義的な立場から来ており、単にチーム配置をしてから知らせるのではなく、当事者に選択肢を与えようと努めているからです。
私が気に入っているのは、このリチーミングには当事者が参加していること、そしてリチーミングの主催者がみんなに将来の構造について十分に考える時間を与え、どこに行き着くかについても必要とあらば上司たちと会話する機会を提供したことです。このリチーミングの話には、メンバーに対する多くの信頼、配慮、尊重があります。
誰かが決めたことに従うのではなく、自分で考えて決断することの重要性。
そして、それを実現するためのメンバーに対する信頼、配慮、尊重の重要性。
関係性があってはじめて実現ができる。
■リチーミングは無償で得られない
リチーミングは簡単に経験できません。どのパターンを試そうとしているのか、どのように取り組もうとしているのかによりますが、とても難しい状況になることがあります。時間の経過とともに自然に起こり、それに対処するか、本書で紹介した5つのパターンを使って変化を起こすことを決め、その結果に対処するか、のいずれかです。ここでは無償で得られるものはありません。クリティカルシンキングをしながら、慎重に考え、ふりかえり、状況に応じて行動しなければいけません。ダイナミックリチーミングをただ「インストール」することはできないのです。
リチーミングは自分たちで熟考する必要があると理解しました。
苦しんで頭を絞って決断したことだからこそ、チームの変化に化学反応が起きる。
■複数のチームにアサイン
人が同時に複数のチームにアサインされると、参加の程度が薄まり、仕事の品質、 チームの成長性に影響を与えるのは明らかです。
肝に銘じておきたい。
■マネージャーのチームに対する距離感
ダイナミックリチーミングのさまざまなアンチパターンを見てきました。ほとんどのアンチパターンに共通することの1つは、機械的なアプローチを使ってしまっていることです。近くにいないマネージャーが、チームの構成や変更を判断することがありますが、私たちが望むような結果にはつながりません。働いているチームや取り組んでいる問題から離れすぎているのです。自分たちがいちばんわかっていると思い込みがちです。マネージャーとしての地位と給与が、「離れすぎている」原因になっているのかもしれません。
マネージャーに限らずチームの開発プロセスに乗っていない人間はチームに対して距離があることを自覚した方が良いと反省しています。
そして、距離があるのであれば、チームのことを信頼し判断を任せることができる関係が重要。
■権力関係上での1on1
マネージャーが「温度を測る人」として定期的に直属の部下と会うような職場もあります。それもよいのですが、そこには権力関係が働いています。私はマネージャー以外のチームメンバーが別のメンバーの感情を把握することが大切だと考えています。これは開発支援チームのメンバーのこともあれば、コーチのこともあります。重要なのは、その人の給与や評価に直接影響を与えず、その人の気持ちに寄り添える人であることです。このような1on1では信頼関係を構築しなければいけません。
フラットであることを意識しても越えられない構造があると思っています。
1on1で実現したいことが、メンバーの感情を把握することであれば、それをメンバーに委ねることも重要ではないかと思いました。
そうして生まれるチームの自己組織化に対する意識もある気がします。
