「チーム・ジャーニー 著者による本読みの会 第10話『チーム同士で向き合う』」に参加した後にまとめてみた
今まではKindleで一緒に読みながら本読みの会に参加してたんですが、起き上がる気力も無く、でもアラーム通りに起きたのでラジオのように音だけで聞いていました。
まったく絡もうとしないチーム
前回チームが統合されましたが、まだ各チーム間でほとんどやりとりがなく、衝突すら起きていない状況に陥ってるようです。マウントポジション取ってくるやつもいるし……。
遠慮という名の牽制
3つのプロダクトを統合するため、共通の認証基盤を作ることは決まっているそうです。統合のためにはさっさとやった方がいいやつですね。でもそこそこ工数かかるのは見えています。でも各チームのPOに話を振っても全然乗り気ではない感じが辛い😣
御室のチームは別のオフィスビルにいるようです。直接乗り込んで行って強制的にミーティングを開催することになりましが距離は一向に縮まることなく、広がる一方だそうで……。
みんな自分たちのことで精一杯というのが透けて見えますね。余計なタスク引き受けたくないと。上から一方的に降りてきた統合の話なので現場も熱意が無さそうです。
暇なんでしょ？
仁和くん……😓 仁和くんとの話の中で自己中心的発言により精神が削られていきますね。でも彼もまた悪意があるわけじゃなく、自分のことで精一杯なんでしょう。でもねぇ……。
そしてチームの状況をプロジェクトマネージャーとシニアPOに報告し、シニアPOから言われた言葉がこちら。
「で？ どうするの？」
＼シニアPO仕事しろ！／
まずお互いに出会い直そう
そういった状況で解決編に入ります。
ただ単に3チームの代表が集まれば良いわけではない。3チームの間で情報を共通にした上で、意思決定を行い、そしてその内容を各チームに定着させる流れをつくらなければさほど意義がない。
（原文だと誤字って？ましたね。「つくれなければ」）
そしてステアリングコミッティとチームリーダーがコミュニケーションする場という名目で御室を呼び出すといった社内政治をしています。なんにせよチーム間でコミュニケーションの場は設けることができました🎉
そのトップたちのミーティングで決まったことを下に流すのも大事ですし、現場から吸い上げてお互いの状況をわかるようにするのも大事です。この辺りがちょいちょい出てくる「塹壕」という比喩が示してるものでしょうね。西部戦線異状なしダメ、絶対。
ただその情報経路も考えなければなりません。現場 → リーダー → 別のリーダ → 別の現場では長すぎます。そのために2つの切り口の場を設置することにしたようです。
一つはプロダクトオーナーで、もう一つはテクニカルリードを挙げられていました。後者は技術方針をチーム間で情報共有する役割や開発環境整備を担います。
さらにはリーダー会にリード側の人がローテーションで参加してもらうようにし、コミュニケーションがかき混ざるように努めたそうです。そのおかげか、
「ぜんぜん大丈夫ではないことがみんなで理解できるようになった。これまでに比べたらとっても大きな一歩ですよ。」
分からないことが分かった！
チームや役割から越境する
1PO - 1開発チーム構造
一つの開発チームに一人のPO。POと開発チームの間で分断が起きます。チーム内でも各自が自分の役割を小さく狭く捉えてしまうと分断が起きます。
役割を越境するために向き合う問いは「自分は何をする人なのか？」で、これにより、境界の存在に気付くことができます。
1PO - 複数開発チーム構造
一人のPOと複数の開発チーム。POの経験と力量で収まるチーム規模かが問われます。チーム間の情報の流通経路を作る必要があります。
複数PO - 複数開発チーム構造
それぞれが複数の体制。いろんなところで分断がおき、ユーザからすると利用体験のつながりに違和感を抱く要因になります。
POの役割を構造化し、「POチーム」を統べる別の役割を設ける考え方もあり、プロダクトマネージャがこれに当たるそうです。それぞれがビジネス面かユーザ体験かを分担させることができます。
越境のデザイン
役割からの越境
人と役割の結びつきを弱めるために「リード」という概念があります。
図10.5「リーダー」と「リード」の違い の中でこう説明されていました。
ある状況において前進を先導する「役割」
役割なので、他の人に代わる、代えることもある、より動的なイメージ。
リードパターンとして以下のようなものが挙げられていましたし、自由に○○リードと設置しても大丈夫です。
✔ テクニカルリード
✔ 仮説検証リード
✔ テストリード
✔ デベロッパーエクスペリエンスリード
もちろんリードというからには、スキルの確保が課題になってきます。またスキルに偏りが出ると結局は人と役割が結びついてきます。チームでどのようなリードスキルを獲得していくのかの見立てを行い、そのための準備をプロダクトづくりの中に織り込んでいく必要があると書かれています。
チーム内で一つのリード役を複数人が担えると柔軟性や選択肢が増え理想の状態に近づけるでしょう。スクラムガイドブックにも多能工的なメンバーが良いって書かれてた気がしますし。
チームからの越境
コミュニケーションの構造化と、それを支えるための見える化が具体的な工夫です。
構造化することでチーム全体の情報流通の経路の確保ができます。
チーム活動の基盤は、各チーム内での同期コミュニケーションになります。
「ネットワーク中心の戦い」みたいなことですね。
また、誤らないようにしたいのは、リーダー会をすべてについての意思決定の機関にしてしまわないことです。
それな。それな。それな！！！！
お互いが状況に対する共通の認識を持てるために、またいつでも誰でも状況の確認ができるように、カンバンの運用が勧められていました。
また情報の粒度についても触れられており、細かい粒度の内容を代表者ミーティングで扱うのは現実的ではない、リード別同期ミーティングで細かい内容を扱うと決め過ぎになるといった点が挙げられていました。
そしてリード役を別のチームに切り出す、コンポーネントチームという考えや、逆に一つのチームにプロダクトづくりに必要な役割を集めるフィーチャーチームがあります。インフラチームやSREチームは前者に当たりますね。
コミュニケーション構造の見える化は今すぐにでもできるものなのでやってみたいですね。どういった構造をしていて、どこで分断ができそうか、現実問題どこで分断が起きているのかの分析と、どうすれば解消できるのかを考えるいいきっかけになると思いました。
😉