第7章 より効果的なアジャイル:分散チーム
基本原則: よりタイトなフィードバックループで説明されている、分散チームが仕事をするのが難しい要因の説明が分かりやすかった。
2000年代の初め、企業はフォローザサン体制をサポートするために開発チームとテストチームを別々の場所に配置していた。
聞いたことはあるけれど、これでうまくいっていた事例は聞いたことが無い。
「拘束力のある決定をその場で下す能力と権限を持つ、自律した機能横断的チームを結成する」という分散チームのベストプラクティスが、アジャイルチーム全般のベストプラクティスと同じであることは偶然の一致ではない。
かっこいいなーとも思えるし、視野が狭いとも言えるかもしれない。実感としてはその通り。
。あるグローバル企業の最高幹部は、「信頼の半減期は6週間だ」と言っていた。ミスが増えてきたと感じたら、メンバーを飛行機に乗せ、一緒にゲームをさせ、一緒に食事をさせることで、人間関係が築かれるようにしよう。チームメンバーを6週間以内に一度の割合で他の拠点に派遣し、数年かけてチームメンバーの100%が他の拠点を訪問している状態にすることが目標となる。
すごい気になった。出典が知りたいけど、これはマコネルの知り合いとかカンファレンスでよく聞くとかそういった類なのかなー。ハッキリしたデータがなくてもいいので、どういった企業のどんな幹部がどんな時に言ったのか気になった。
リモート代理人
先週、新さんが言っていた代理POとかもこういうことなんだろうなー。
立場の違いや自律性の低さは各拠点のモティベーションを損なう。二次的な拠点のチームはその立場や責任の度合いをそういうものだと自覚していることが多いようだ。
これが子会社でも起きている気がしていて、なるほどなー、大事だよなーっていつも思います。
それぞれの拠点の作業が組織または世界全体にとってなぜ重要なのかを積極的に伝えるようにしよう。
先週の新さんの「WHYを伝える」というのと同じだろな。
分散チームをうまく収束させるには、それらのチームが「完成の定義」に特別な注意を払う必要がある。
こういうところ重要だよなー。分散チームだからより重要度が上がるプラクティスが一覧になっていると良さそうだな。
単に、地理的に近い場所にいる人々と仕事をしていると自律性が不足していても埋め合わせるのが容易であるため、そのことに気付いていないだけかもしれない。
うっ
7.5推奨リーダーシップアクション
検査
分散チームのフィードバックループはどれくらいタイトだろうか。本章で確認した典型的な間違いの中に、身に覚えがあるものはないだろうか。
「プロダクトオーナーと開発チームが別の場所にいる。」は見かける。あと、自分のチームもそこまでタイトにできていない時があって、やはりその時はうまくいっていない。
分散チームだからタイトでなくなる、というのはあまり感じていない。分散チームとは関係ないが、別仕事を兼任しているメンバーがいて、後でそのメンバーが戻ってきて重要な視点で意見をして、そのメンバーが戻ってくるまでの時間の議論が白紙になるとかはあった。
モブワークだからだから差異が無い感じ
本社(愛知)の人たちと開発をしたときはスプリント期間を長めにしないと予定が取れない上に別のことでも忙しくて、なかなかコミュニケーションを取るのが難しかった。
自分も、分散チームだからタイトでなくなる感じはしてません。(週1リリース) フィードバックループとしては、タイトになってないときあるかー。オフラインでは消極的になる人が多い印象。僕はわりと積極的に質問するタイプなので問題ない感じです。
各拠点の言語、国の文化、拠点の文化の違いを確認する。そうした違いが意思の疎通をどれくらい損なうのかを評価する。
この辺は自分が知らないこと自体がずっと課題だなーって思っていて、少しずつ覚えていっているところ。どれくらい損なわれているのかは、評価したことがない。儒教ベースの日本と、キリスト教ベースのアメリカでかなり意思疎通が面倒になるという話をたまに聞くので、お互いにそういった考え方を学んでいきたいなーっていつも思う。
個人的には、文化の違いをそこまで気にしたことはなくて、別拠点にいる人とは特に価値観の違いをすり合わせすることが多い。国ごとにどういうバックグランドの違いがあるのかという知識を持てているとよさそう。
英語で細かなニュアンスを伝えられない、理解できないというもどかしさはあった。
各チームは自律心、熟達感、目的意識を養えるような方法で構成されているだろうか。
目的意識を養うって難しいなー。常にできるような方法ってなんだろう。
これ、日本語が難しい?チームの構成が、自立心、熟達感、目的意識を養えるようになっているかということだろうか?いずれにしてもそれらを養える構成って難しい。今のチームは割と各メンバーの意識がバラバラになっていて、各々が何を目的に活動しているのかわかりにくい感じがする。そういう状況だと、自信をもって自分の成長のベクトルを設定できない。
できている?…わからない…
自律心、目的意識は満たせているはず。熟達感は養えるような構成になっているのか、微妙な所。。(分散しているチーム同士のフィードバックは希薄な気がする)
同じ場所にいたときと「少なくとも同じ頻度」でリリース可能な品質水準に収束することに関して、分散チームの規律は守られているだろうか。
できている時もある。コロケーションチームでの比較を2年もやっていないので実態としてはもう比較はできない。
守れている。
分散チームでの検査と適応の活用を体系化し、この困難な構成でのより効果的な作業方法を学習できるようにしているだろうか。
体系化はできていないけど、パタンにしたりはしているかなー。少しまとめてみたいなとも思った。
まったくできていない。基本Teamsに集まりっぱなしにしておいた方がいいよね、位のレベル。
適応
必要であれば、フィードバックループをよりタイトにするために、チームとコミュニケーションパターンを再編成する。
もっとゼロベースというか、目的に沿ってやれるようにしないとなーって改めて思った。
現状、デイリーミーティングの場以外でのコミュニケーションがほとんど無く、フィードバックループはタイトになっていない。もう少しメンバー同士のコラボレーションを増やしても良いと思っている。自分は稀にメンバーに依頼してペア作業してもらったりしていて、その際にはタイトになっていると思う。そういうやり方をチームに定着させることでチーム内のフィードバックループをタイトにしていきたい。
コミュニケーションパターンはないなあ。基本モブでやろうね、くらいの感じ。
拠点間のコミュニケーションと理解を改善する計画を立てる。
アドホックすぎるのでさっき出てきた6週間ごとみたいにやる方が健全さを保ちやすいかもなー。8週間ごとにはやりたいかもしれない。
何かずれがありそうだったり、レトロスペクティブで今いちコミュニケーションがうまくいかなかった時(知らない事実が高頻度で出てきた時)にやる感じにしているので、そういったトリガーが何もなくても計画を立てられるようにした方がよさそう。
分散チームの自律心、熟達感、目的意識を高める計画を立てる。
この質問を見て、それぞれの定義が難しいな...と今更思い出した。(特に熟達感が高まった状態とはどういう状態なのかが全然分からなくなってきた)
常にリリース可能な品質水準を保つことの重要性をチームに伝え、適切な完成の定義を徹底させる。
これ、共通のCIとか設定みたいな話から、レビューの基準とかも考えると、勉強会をやるとかもある種そうなんだろうなー。やっていきたさ。
DODは見直しを定期的にかけており、常にリリース可能な状態は維持できているが、割と機械的に行ってしまっている側面が多いので、なんでこういうDODなのか、どういう過程でDODが変遷してきたのか、とかはチームにもっと伝えたい。
スプリントレトロスペクティブの気付きに基づいて変更を行うための権限をチームに与える。
これもっとやっていきたいなー。障害を排除するマネージャーとして動けるようにならねば。。。
チーム内で変更する権限は既にもらえている。
7.6 参考文献
本章の内容のほとんどは、ConstruxSoftwareの直接の経験をまとめたものである。このため、追加の参考文献は次の3つである。
■Conway,MelvinE.1968.How do Committees Invent? Datamation .April1968.コンウェイの法則に関する原論文。
■Hooker,John,2003.Working Across Cultures. Stanford University Press.文化をまたいで仕事することについての一般論をまとめた1冊。中国、インド、アメリカ、およびその他の国についての具体的な解説を含んでいる。
■Stuart,Jenny,etal."Succeeding with Geographically Distributed Scrum," Construx White Paper, March2018.スクラムに特化した分散チームに対する提案をまとめたホワイトペーパー。本章で説明したものと同じ経験の多くが盛り込まれている。