見出し画像

「チーム・ジャーニー 著者による本読みの会 第06話『分散チームへの適応』」に参加しそびれたので一人でまとめてみた

 やらかした。

 7時にアラームで目が覚めたけど起きたら8時半。自分でも気づかなかった二度寝をかましていた。ステルス二度寝。参加した時にはすでに本編が終わっており質疑応答でした。

 前回の参加記事。「習慣化した」(キリッ 😇

分散チームへの適応

働き方と働く場所が異なる分散チーム

 スクラムに取り組もうとしたときに「プロダクトオーナーの役割」は直面する問題です。さらに場合によってはチームや組織の外側にいる人がプロダクトオーナーとして振舞ってくれるのか、協力してくれるのかから開始するチームも現実的にはあると思います。なのでこの本ではむやみに対象を広げずに、開発チーム、プロダクトオーナー、ステークホルダーという順で拡張を進めていくことが書かれています。

「それは途中の段階ではスクラムとは呼べないのではないか?」
「だから、なんだ?」

 強い。

 そう考えるとうちのチームはまだ開発チーム内の取り組みだけで終わってしまってなあなあになってしまっているような気がしてきました……。😇

プロダクトオーナーからの新たな挑戦

 プロダクトオーナーからの要望を捌けきれなくなったのでメンバー増強が行われました。彼はフルリモートで働くプログラマーです。しかも時短。

 昨今の情勢でリモートワークに切り替わった人も多いと思いますし、タイムリーな話題ですね。

 さらにもう1人フリーランスのプログラマーが追加されます。

壊れてしまったスクラム

 働く時間帯が異なるメンバーに合わせてスケジュールを組むことになり各種のスクラムイベントが夜に開催されるようになりました。この夜の時間帯は定時後ってことなのでしょうか……?

 システムの仕様や、チームやシステムの歴史的経緯を知らない新しいメンバーが増えたことでコミュニケーションロスが発生しすりあわせに時間が掛かってしまいます。方向付けをしようにも機能追加要望に応えるためには時間を惜しみたくないそんな状況ではこなし仕事になってしまい、コミュニケーションが粗くなってしまっていきます。

 タスクが三条さんに偏ってしまい、またリタイアしてしまいます。

状況を見て、チームにある分断を捉えよう

 はい、全員集合! ってことで現場に来てもらってチームミーティングが開催されます。

「新しいメンバーが増えて、活動上の制約が現れた。状況はすでに変わっている。今までどおりを維持しようとするのは、適応とは呼ばない。」

 スクラムイベントを昼と夜で分けてしまうことが提案されます。

「俺たちはなぜここにいるのか? スクラムをやるためか、それともプロダクトを世の中に届けるためか?」
「働き方や働く場所の違いはチームに3つの分断をもたらす。つまり、時間の分断、場所の分断、経験の分断だ。」

 時期的に新入社員の入社、リモートワーク導入と分断の嵐が吹きまくってますから納得できました。こういう状況を見て問題を捉えて解決していくことが重要です。ここでは役割とそのミッションを決めることになりました。

プロダクトにおける「制約」をつくり、その制約の下で機能開発を進めていこうという考え方なのだ。

 制約があるからこそブレなくて済むという利点も述べられています。

チーム状況に適したフォーメーションを組む

 分断によって引き起こされる問題が挙げられています。ではどう向き合うかということで一つのパターンとして「雁行陣開発」が紹介されています。

 人によっては梯形陣の方が分かりやすいかも🚢

 雁行陣開発とは、プロダクトの作り方、方針、その実装について先導する役割のプロダクトリードと、チームの運営を担う役割のチームリードを置きます。その他メンバーは適宜プロダクトバックログを実装する役割になります。

 この分け方は VPoPVPoE で分けるのと同じ思想と思いました。一人の人がどっちも見てられませんしね。

雁行陣開発でのプロダクトバックログの管理については、まずその性質からプロダクトの「背骨」にあたるプロダクトバックログ「お肉」にあたるプロダクトバックログとに分けることから始める。背骨バックログとはプロダクトを利用するユーザーの体験上必ず必要となる機能群になる。
お肉バックログは、背骨があることを前提としてそこにまさに肉付けするようにつくることができる機能群のことである。

 なるほど?

プロダクトリード、チームメンバー、チームリードの果たす役割

 「背骨」をプロダクトリードが先行して作り、制約やレールを整え、そのうえでチームメンバーがお肉を作っていく開発になるそうです。

 なるほど。極端な例かもしれませんが、新規機能開発にフレームワークやライブラリの選定からメンバーが担当するよりは、経験豊富なプロダクトリードがメンバーからのフィードバックを受けつつ選定してくれた方が安心感もありますからね。

 その分プロダクトリードが独り歩きしやすくメンバーとの分断も起きてしてしまいそうですが、そこで活躍するのがチームリードです。情報共有や相互作用が十分にいきわたるように働きかける媒介者として動きます。

 「背骨」「お肉」って出てきたときは🤔ってなりましたけど、こういう風に説明されると分かりやすくていいですね。効果的に働きそうな気もしてきました。

 雁行陣開発はフォーメーション・パターンの一つで、直面した状況に対して、適宜最適なフォーメーションを組んで対応していく必要があるとも書かれているので、普段の業務を俯瞰してフォーメーションを分析してパターン化していきたいです。役割をフレキシブルに変えていくことで能力開発、経験蓄積、人材育成ができるとも書かれています。

 この辺りで入ったので流れがよく分かっていませんが、アオアシやハイキュー!!がフォーメーション学ぶ参考文献としていいぞ! みたいな話がありました。

次回8時からですよ。



いいなと思ったら応援しよう!

ふじい
😉

この記事が参加している募集