"変化に対するキャパシティ"のズレと改善活動の難しさ

スクラムチームにせよ、エンジニアチームにせよ、僕が属するチームには自分たちの開発プロセスを自分たちで改善する裁量がある。ありがたい話だ。
ただ、誰もが僕みたいに反省や改善が大好きなわけではないし、僕より遥かにハイペースで改善し続けようとする人だっている。期待する改善のペースは人それぞれで、だからチームで取り組む改善活動は難しい。

＊ ＊ ＊

ところで、改善とは変化の連続の上に成り立つものだ。
何かしらを改善しようと思ったら、新しい方法を試行して、データを集めて、検証して…と毎イテレーションで違うことを行うことになる。いつもと違うことを実践し続けた先に「改善」という結果が浮かび上がる。なのでどれくらいのペースで改善に取り組むかは、言い換えるとどれくらいのペースで変化し続けるかということだ。

しかし一度にどれくらい変化を受け入れられるかは人によって違う。開発プロセスの改善が難しい要因のひとつは、変化に対するキャパシティが違うチームメンバーが全員揃って取り組む必要があるからだと思う。

＊ ＊ ＊

思い返すと、スクラムマスターをしていたときに一番悩んでいたことは「変化のキャパシティが一致しないチームメンバーでどうやって改善活動のペースを維持するか」だった気がする。結局選択肢はあまりなくて、

・キャパの大きい人に改善活動をリードしてもらう
・キャパの小さい人に沿うペースで少しずつ改善していく
・間をとる

あたりを行ったり来たりしていた。少しでも変化の速度を上げられるように問題に気付いてもらおうと助言してみたり、「なぜ変化が必要か」や「なぜ変化が怖いか」を議論してみたりと、あの手この手を試したが、結局変化のキャパシティはそう簡単には変わらないということが分かっただけだった。

例えばこれが部活動であれば「人により可能な練習量は違うだろうが、強引にハードなほうに体を慣れさせる。合わない人は出ていってくれ」という手が取れるかもしれない。
ただ仕事となると難しい。変化への適応力は少なからず必要だが、変化が得意な人以外は出ていってくれとは言いたくない。むしろ同じことを淡々と精度高く繰り返せる人が活躍する場面もいっぱいある。変化への対応が得意な人と変化せず繰り返すことが得意な人とが協業しながら改善し続け、プロダクト開発をし続けられるチームにしていく方法は……どこかにないものだろうか。

＊ ＊ ＊

僕が今マネジメントしているチームは、ものすごく稀なことに、変化のキャパシティが近いチームメンバーが集まっている。高頻度で新しいことを試してプロセスを変化させ続けていて、それを楽しめている様子だ。

だけどたまたまそうだっただけで、悩みが解消されたわけではない。今のチームだっていつか変化のキャパシティが食い違ってくるかもしれないので、そうなる前に対応を考えておきたいところだ。