チームトポロジー ~ 価値あるソフトウェアをすばやく届ける適応型組織設計 ~ を読んで
アイミツ開発チームでエンジニアリングをしている deliku です！
今更ブレワイを購入して遊んでいるのですが、めっちゃ楽しいですね。
▶︎ 自己紹介
価値あるソフトウェアをすばやく届ける に惹かれて、チーム / 組織設計についてなにか掴めるものがないかアンラーニングしたいと思います。
この本は下記のパートとチャプターに分かれており、読者が解決したい課題に対して、どのように読み進めるべきかを提示してくれています。私の場合、下記に興味があったので「チームファースト思考」のキャプチャーを読み進めることにしました。（全体的にボリュームがあるので、自身の問題意識や課題に合わせて読むポイントを整理するのがよさそうです）
ソフトウェア開発チームの実効性を向上させたい
チーム内の士気を上げ、実効性を向上させたい
▶︎ 「チームファースト思考」
本書では、効果的にソフトウェアを提供し続けるためには、チームに誰がいるかではなく、チームの力学が重要であると書いています。ゆえに個人ではなく、チームが最小単位となり、チームとしてパフォーマンスを発揮するにはどうすべきかが記されています。チームが主体性をもち自走するためにはチームメンバが同じ目標に向かっている必要があるとも思いました。
チームがソフトウェアのオーナーとなる
複数のチームに同一システムまたはサブシステムの変更を許すと、変更がもたらす混乱について、誰もオーナーシップを発揮しなくなる。
チームメンバーにはチームファーストのマインドセットが必要
個人のニーズよりもチームのニーズを優先する
コーチングを行なっても、「チームの毒」となる人は実害がでるまえにチームから取り除く必要がある
チームの多様性を受け入れる
「結束したチームを作るには、異質な人が少し混ざっていたほうが効果的」
個人ではなくチームに報いる
「組織内の給与の差は小さく押さえる、ボーナスの額は小さく、個人の業績ではなく、会社全体の業績に対して通常はチーム単位で支払う」
▶︎ 「認知負荷に関する種別と考え方」
効果的なデリバリーと運用をするために、課題内在性負荷を最小に、課題外在性負荷は取り除く、付加価値ついて考える学習関連負荷に使う余力を使っていくことが理想とのこと。また、チームの認知負荷を知るための効果的な手段として、「チームは頼まれた仕事に対して、効果的でタイムリーな対応ができていると思うか？」と尋ねるのが良いとあります。（コード行数、モジュール数、メソッド数などの数値からは単純に測れないそうです）
課題内在性負荷 : 問題領域の本質的なタスクに関連するもの（クラス構造、メソッドの作り方）
課題外在性負荷 : タスクを実施される環境に関連するもの（サービス構成 / デプロイ方法）
学習関連負荷 :学習を進めたり、高性能を実現したりするために特別な注意が必要なもの
▶︎ 「タックスマンモデルの先へ」
タックスマンモデルは有名なモデルですが、最近の研究でチームが存続する間は混乱期がずっと続くため、チームの力学を継続的に育てる必要があるとのことでした。一定のチームビルディングが進むと機能期に移行し成熟したチームになって高いパフォーマンスをだせると考えていたため、混乱期にずっといるのではという問いは衝撃を受けました。
▶︎ 「チームファースト思考」キャプチャまとめ
・個人ではなくチームで動く方が効果を発揮できる。重要なこととして、チームでは許容できる認知負荷サイズがあり、適切に分ける必要がある。
・単一のチームが複数のシステムを扱っていくと、結果的にオーナーシップを失い、心理的な余裕もなくなってしまう。
・個人間のコミュニケーションではなく、チーム同士のコミュニケーションを重視することで、個人のふるまいの影響を限定的にできる。
▶︎ 謝辞
また本書を読み進める上で、下記翻訳が大変参考になりました。
▶ 【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
この記事が気に入ったらサポートをしてみませんか？