海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

大規模にアジャイルをやるにはどうしたらいいか、に対する答え

大規模にアジャイルをやるにはどうしたらいいですか?

答え 大規模にしない

以上終わり。


先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね?って聞かれて出た感想が、「大規模にしない」だった。

ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う

そんなチームのプロセスを同期や依存させる意味あるのかと。

「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね!」

って言われたらどう考えても頭おかしい人でしょ。

依存がいらないところをわざわざ依存させない。

偉い人が同じ?組織上同じだから?

依存を増やしてどうやって変化に対応するのか?

変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか?

そんなことを感じないでもない。


アジャイル界隈で悪名高い?Scaled Agile Framework (SAFe) というものがある。

(現在バージョン 4.6) SAFe 5.0 Framework - SAFe Big Picture

エンタープライズレベルで統率されたアジャイル プロセス を適用するためのフレームワークになっている。

そもそもアジャイルを適用することが目的化している時点で怪しい臭いがプンプンしないでもない。

大抵アジャイルが目的化している組織では、アジャイルプロセスに変化したことが目的化していて、そもそもアジャイルを導入するモチベーションとなるべき、顧客への価値提供の最大化や、リスクの抑制、変化への対応といったことが考慮されず、ただただプロセスが適用されて終わる。

場合によっては、その配下の組織(トレインとかいってたりする)のドメインにおいては、PI (SAFe の計画スパン)がすでに変化に対応できないものになっていたりするがおかまいなしにプロセスが適用され、顧客やビジネスの満足度が下がる始末になるのは明白になる。だって見てないもん。

上位組織の承認がなければ自分たちの活動内容を進めることができない、上位組織の決めたプロセスに合わせることが現場の課題の解決の為のプロセス改善よりも優先される。

場合によっては現場がプロセスを ”適用された” 側となってしまい、なぜそのプロセスなのか、そのプロセスがどう機能していないといけないのかに疑問すら持てないまま、「順調に各トレインが運営されています」とか報告されるだろうと考えると頭が痛い。

まあそんな会社や組織はそのうち潰れるだろうからどうでもいいかもしれないので気にしてもしょうがないが。


SAFe でも LeSS でも NEXUS でも DAD でも Spotify モデルでもなんでもいいが、

「依存のあるチームをまとめて大規模に運営できる」 プロセスは、「チーム間の依存をどうやったら減らせるか」 という、当たり前の視点を奪ってしまいやすい。

依存が切れて独立運営できる方が効率が明らかに高いのだが、それに気づく機会を奪うのは中々罪だな、と思う。

Spotify モデルは組織の枠組みの話だし、明確に依存を減らすアクティビティを儲けると謳っているのはさすがだなとは思う)

同期を取らないと開発進めるの大変じゃん、ていう当たり前の事を知らないと、気にせずこの辺導入してしまいそう。(自戒)


(2020/10/19 追記)

Clean Agile ~Back to Basic~ という Uncle Bob の本を読んだら似たようなことが書いてあったので、参考までに追加。

大規模アジャイルはどうなのか?私はそんなものはないと思っている

大規模なチームの組織化は、小さなチームに分割する問題である。アジャイルは小さなソフトウェアチームの問題を解決する。

小さなチームを大きなチームにする問題はすでに解決されている。

したがって、大規模アジャイルの質問に対する私の答えは、「小規模なアジャイルチームを組織せよ」だ。

この本が先に出てればこんな拙稿捻らなくて良かったのでは、感ある。