「バックログはなぜ一つであるべきか？スクラムチームの適応力を因果ループで読み解く」の感想メモ
背景
先日、スクラムフェス仙台2025( https://www.scrumfestsendai.org )に参加してきました。その中で、以下のセッションを視聴し、非常におもしろいと思ったので、自分のメモがてら感想を残しておこうと思います。
感想
私も昨年、LeSSのトレーニングを受講したり、LeSS' Yoakéに参加したりして、LeSSの思想にはよく触れており、本セッションの趣旨であるバックログは一つであるべきというのはその通りだなと感じています。その理由を改めてシステム思考を用いて説明するのは非常に分かりやすいと思いました。
コンポーネントチームなどに分けるという戦略は、前提としてスコープを減らすという狙いがある
という記載がありますが、ここが重要なポイントだと思います。スコープを減らすとか認知負荷を下げるという言葉に表されるように、あるチームが自分たちが見るべき領域を狭めてそこだけに集中できる状況を作る方が望ましい、という前提に立つとすると、チームをコンポーネント単位や機能領域の単位で分割したくなり、結果としてバックログが分割され、チームはその範囲しか見なくなります。ただ、私自身の経験からもやはりそれではうまくいかないというのを感じています。このようなやり方ではチームごとの局所最適に陥ってしまい、プロダクト全体として整合性が取れていないものになってしまう可能性が高いと感じます。
うちは1チームなので問題はないですね。
メンバーに役割を付与したら同じ話になりえる
これもまさにその通りだと思います。よくないとは思いつつ、メンバーごとにAさんはX機能の担当、BさんはY機能の担当、のような構造についついなってしまいます。
以前、Odd-e社のCSD研修の中で、「コードの共同所有」という言葉の説明として、「Googleスプレッドシート上で共同編集するようにメンバー全員でコードを書いていく状態を目指す」、という話を聞きましたが、その話を思い出しました。各メンバーがローカルPC上でシートごとに分かれたExcelファイルを編集し、後で結合するというやり方をしたときにそれが全体としての統一感がとれるはずもないというのは想像に難くありません。
どうすればよいか
分業が進んでいる状況がよくないとして、ではどうすればよいかというところですが、結局のところ、POがどれだけ強い意志をもって、いまのプロダクトにとって一番必要でROIの高いPBIはこれだ、という優先順位をつけられるかというところに帰着すると思いました。セッションのスライドではPOが「①～④が最優先なんだけど、①しかできないのか。ビジネス機会を逃してしまう…」と言っているページがありますが、もしPOがそのように確信をもっていえる状態にないとしたら、そこに対する支援が必要なのだろうと思いました。チームがそれに応えられるケイパビリティがあるかどうかはその次の話かなと。まあでもチームのケイパビリティがあるからこそ仮説検証が早く進むのでPOの確信度も上がっていくということもあるのかな…。
特に結論めいたものがあるわけではないのですが、そんなことを考えさせていただいたよいセッションでした。引き続き考えていこうと思います。
Discussion