チームの自律を免罪符にして、プロダクトを沈ませるな『マイノリティ・リポート』

ダッシュボードの僅かな変化を見逃すな

大規模なアジャイル開発を導入し、複数のスクラムチームを率いていたときの話です。私はPO（プロダクトオーナー）として、スクラムの原則である「透明性」を重んじ、チームが自律的に動き、自ら問題を解決する「自己組織化」の実現を目指して組織を組み立てていました。

世の中のマネジメント本には「数字は完璧なのに、なぜか現場が疲弊している」というエピソードがよく出てきます。しかし、私はそうは思いません。組織に起きている生々しい異変は、間違いなく数字に現れます。

• スプリントの完了率が落ちていく

• ベロシティが減っていく

• バグが増えていく

時系列でデータを眺めたり、チーム間で比較したときに、数字は必ず小さな悲鳴を上げています。あるいは、デイリーや振り返りの場で、メンバーの何気ない一言に混ざる違和感として、それは確実に姿を現しています。

ルールに従えば満足な結果につながるのか

数字の異変に気づくのは最初のステップに過ぎず、本当にタフなのはそこから真因を探し当てるプロセスでした。原因の要素分解を始めると、終わりのない泥沼に足を踏みに入れる感覚になります。

• 開発タスクの見積もりが甘かったのか

• 開発タスクの種類と、チームの得意分野がズレていたのか

• 開発プロセスが、チームのスケール化に合っていないのではないか

• チーム内で役割の適正が崩れているのではないか

私は、GitHub Analyticsの画面に並ぶ数字を睨みつけながら、思考を巡らせていました。開発を一時的にストップして原因究明に時間を投資すべきか。それとも、いくつか仮説をたてて、走りながら対策を打つべきか。チームが前提にしているスクラムの原則を適用しても、現場の切迫した状況の前では限界があるという現実を知りました。

自分が違和感を吸収し優先順を歪めていた

何より私を追い詰めたのは、POとしての自分自身の「弱さ」でした。

開発するフィーチャーに対して、各チームの開発力のバランスが明らかに崩れている。次のPBIをどのチームにアサインすべきか悩むとき、私はプロダクトの価値ではなく「あのチームは今、これを受け入れられる状態か」という現場のコンディションを伺い、優先順位を歪め始めていたのです。

何かがおかしい。しかし、表面的なプロセスの議論を重ねても、その歪みの根本にはどうしても辿り着けませんでした。

システムが示す数値と、切り捨てられた違和感

映画に登場する「犯罪予知システム」は、一見すると完璧なデータ駆動型のプロダクトです。しかし、その裏側では、システムを維持するために都合の悪いデータがノイズとして処理されていました。

これは、ベロシティやデプロイ数という整理されたダッシュボードを盲信し、現場の個人の声を無視してしまうマネジメントの構図と完全に重なります。

チームに対して、数字に基づく原因分析と対策を委ねても、彼らが自力で導き出す解決策には限界があります。プロセスを変えるだけでは、現場の根深い歪みは崩せませんでした。スクラムの原則が掲げる「自己組織化」という大前提が、皮肉にもPOの変革を躊躇させる足枷になっていたからです。

スクラムの原則を遵守してチームが沈むのを待つか、嫌われる覚悟で禁忌を破るか。後半では、私がダッシュボードという現代の予知システムを抜け出し、「人の組み合わせ」という最後の聖域に手を突っ込むまでをお伝えします。