yuheijotaki.com

【読書メモ】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

市谷聡啓さんの上記2冊に続いて、チーム・ジャーニーを読みました。
カイゼン・ジャーニーの続編ぽい感じだったので(実際には単体でも読める)2月の発売から楽しみにしており、3月に内容も多めだったのですが、ちょっとだらだらしながらになってしまいましたが読みました。

目次

第1部 僕らが開発チームになるまで─1チームのジャーニー

  • 単一チーム 基本編
  • 単一チーム 応用編

第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー

  • 複数チーム 基本編
  • 複数チーム 応用編

カイゼン・ジャーニーは、1人から始められるカイゼンを繰り返しチームが遷移していく(だけど焦点は個人に合っている)物語でした。
対してチーム・ジャーニーは、チームマネジメントやチームづくりについて、よりチーム全体に焦点を当てた内容になっています。
物語方式にて、まず問題(ストーリー・問題編)、次に課題(ストーリー・解決編)、最後に解説が各章にておかれています。
基本編で4章、応用編で4章、それが1部+2部なので全16章というボリュームになっています。

概要・ポイント

大枠として、度々書かれていたこと

  • なめらかに進める
  • 解像度を意識する
  • 状況によってフォーメーションを組む

チームマネジメントにおいて、一気に状況を変えようと思っても無理は利かないので段階的に予定を立て進めていく。
人によってその情報や状況に対する捉え方(視座=高低/視野=広狭)が違うので念頭におく。
ひとつの固定の役割、既存の概念に囚われず状況に応じて柔軟に配置転換、役割の創出などを行なう。

その他、気になったこと、なるほどと思ったことなど。

コンウェイの法則

プロダクトやシステム設計が、組織構造(チーム分割等)を反映したものになることをいう。
逆にプロダクトの機能などから組織構造を作ることを逆コンウェイの法則という。

取引コスト

もとは経済学の言葉で、違う文脈を持っている相手に対してコミュニケーション取ることは取引コストが高い、などという。

「リード」という役割

「リーダー」とは別の「リード」という役割
・リーダー => 組織上の職位として定義
・リード => ある状況において前進を先導する「役割」。例)テクニカルリード、仮説検証リード、テストリード

情報の解像度

レイヤーによって粒度分けて展開するのが望ましい。
例えばPOなどのレイヤーで細かな機能についてまで話を展開してしまうと、開発者メンバー側では情報を受け取って「ただそれを実装する人」になってしまう。
ある程度は余白もたせて PO => リード => 開発者 などに受け渡ししていき細部を詰める流れがよい。

番頭の輪番化

担当をローテーションすることで、トラックナンバー1問題(誰々しかこのコードを触れない問題)につながらないようにすること。

ただし、チームメンバーの専門性や関心などで、あるメンバーに依存する領域が生まれてしまうこと自体は悪いことではありません。むしろメンバーの多様性がいきている状態ともいえます。属人性を排除することを過度に目指すのではなく、何かが起きたときに他の人でプランB(本人ほど最適ではないが、他の人でもなんとか対応できる作戦)が立てられるかどうかを明らかにしましょう。

事前に許可を求めるより、後でゆるしを得たほうがたやすい

先に動いてしまって後でゆるしを得にいくということ
これ結構メンバー側目線で自分も意識していて、ケースバイケースではあるものの決裁権持っているひとにいちいち確認しても時間もったいない(=ボトルネックになる)と判断したら答え確定して出した方がいいなと

視座と視野で決まる視点

物事をどこからどこまでを見るようにするか、「どこから」というのは「視座」、「どこまで」とは「視野」にあたる。
その上で
・視座や視野への偏りをつくらないこと
・視座の高低と視野の広狭を自分たちの意思で行き来できること
が重要。

良かった点

  • 少し登場人物の名前が分かりづらいが、相変わらずストーリーがおもしろい。
  • 問題:課題:解説の割合、1:1:1 くらいですが、ある問題に対して内容割いている本も少ないように思うのでためになる。

惜しかった点

  • 特になし

まとめ

本に解説してある内容でも実際の現場では状況も違うので、その都度ベストな選択や考えを結局自分自身がしたり持ったりしなくてはいけないのだけれど、その幅が広がったり選択がしやすくなるような内容の本だと思う。

いっぽうで結局正解はないので読者の主観に後は委ねられる部分も多くある、そういう不確定要素を好まないひとには向いていないかもしれないが、筆者の「正しいものを正しくつくる」でさんざん語られていたように今の時代そういう開発形態も考えも主流になっていくなかでうまく自分も適用できるようにならないとと感じた。

最近発売されたオライリーの みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた の説明にも

本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、...

と書かれています。
自分も今の会社に入って分かったのですが、結構クライアント側の方が開発に入ってくることが多く、その良い面みたいなのはすごく感じています。それでいて知識も豊富だと後ででてくる要件も出づらいのでやりやすいなと。

今回の本はチームビルディング的な観点だったので、いちメンバーである自分には適用しづらい内容も多かったですが、そういう視点も持ちながら働く/働かないではわりと違うんでは、と思っているのでもちょっと視野広げてやっていきたいと感じられました。