「相互依存最大化のすすめ」に参加しました！

こんにちは、ソフトウェアスクラムマスターの niwano です。
だいぶ日が経ってしまいましたが、スクラム実験室の相互依存最大化のすすめ - connpass に参加したので、簡単なトピックとその感想を書きたいと思います。
scrum-jikken.connpass.com

Large-Scale Scrum (LeSS)
「相互依存最大化のすすめ」とは
相互依存最大化とは、どういうこと？
- フィーチャーチームは楽しい
- プログラマーからプロダクト開発者になること
GROOVE Xの開発はどうなっているの？
- 基本はコンポーネントチーム
- 組織構造はフラット
まとめ

Large-Scale Scrum (LeSS)

弊社はスクラムフレームワークで開発をしていますが、８チーム以上のチームが稼働しています。
チームが８チーム以上ある場合は、Large-Scale Scrum (LeSS)と呼ばれています。

LeSSについてはこちらの動画を参照してみてください。
www.youtube.com

「相互依存最大化のすすめ」とは

Large-Scale Scrum (LeSS)を作った、Bas Vodde氏が、2023年9月11日に日本で開催したイベントです。
なんと弊社の会議室がこのイベントの開催場所だったので、幸運にも開催者枠で参加することができました。

相互依存最大化とは、どういうこと？

スクラム開発でも、チーム間もしくはチームメンバーで共通コンポーネントの開発をしないように、分業してしまうことが多いと言われてます。
Aさんはここまでやってね、そのあとBさんが作業するよ、みたいな役割分担のことだと、私は理解しました。

この分業が同一のスプリント内で発生しているのであれば、問題は大きくなりませんが、分業が発生する時期が大きくずれていると問題が発生するとBasさんは言ってました。
Aさんが開発したものに対して、半年後にBさんが仕様の確認をする、みたいなシチュエーションです。
これはつまり非同期の依存です。

それに対して、Basさんが提唱してたものは、みんなで同じタスクを同時に行い、同期して依存させるというものでした。
ソフトウェアソースコードも同じタイミングで編集するため、単一リポジトリが良く、自分の得意分野でない開発も率先して行っていくことが望ましい、そうです。

研修の詳しい内容は、s.hirai さんの note スクラム実験室：「相互依存最大化のすすめ」に参加しました｜s.hiraiによくまとまっていました。
note.com

上記を実現する要素として私はとくに以下の内容が気になりました。

フィーチャーチームは楽しい
プログラマーからプロダクト開発者になること

フィーチャーチームは楽しい

フィーチャーチームとはいろいろな専門領域をもったメンバーを１つのチームにする方法です。
ときには自分の専門領域でない開発があったとしても、積極的に開発に参加することで、日々学びがあり、成長を実感できるのだそうです。

プログラマーからプロダクト開発者になること

プログラマーの姿勢とは、「私の仕事はコードをかくこと、つくるものは誰かがきめて、誰かのいったとおりにコードを書きます。」というものです。
要求をよくしっている人から、聞いたことを、ただただ実装していく。
実際はステークホルダーはどうやって作るかは知らないので、問題を解決するにはステークホルダーとプログラマーのコラボレーションが必要になる。顧客のことを知った上で、開発をしないといけなく、誰かからの要求をきいて実装する、ではいけない。
これができるのがプロダクト開発者である。

GROOVE Xの開発はどうなっているの？

基本はコンポーネントチーム

ソフトウェアは８チームあって、チームの基本はコンポーネントです。

UT/SMALAVO/ALOHAは、Behavior Design として、CLOUD / FLAMEWORKは、KIBAN Working Group として、積極的に情報を共有するようにして動いてます。
チームが自ら何度かの改善を重ねた上で、いまこのかたちになっています。
実はフィーチャーチームちょっとはできてるじゃん！と思ってスクラムマスターとしては嬉しくなりました。