開発基盤(インフラ)チームでのスクラム開発についての一考察

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

人生何度目かのスクラム開発をしているんだけど、昔気付かなかったメリットにいくつか気付いた。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

一番のメリットは予測可能性が上がること。これはようはちゃんとやっていなかったバックログリファインメントやスパイクを計画的にしているだけなんだけど、レトロスペクティブでそこが改善点だと認識したことでちゃんと投資することになり、飛躍的に改善した。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

あとは、フォーカスがちゃんと動くようになったと思う。 より詳しく書くと、相変わらず調査と実行は並行せざるを得ないんだけど、今のスプリントに実行しているものについては事前にきっちり実行計画を詰めているので追加調査が発生することがほぼなくなった。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

一方で、調査は次スプリント以降のものになった。 これによるメリットは何かというと、今現在実行しているタスクについては計画がしっかりあるので、スプリントゴールを達成する = ちゃんとやりきる、と実行にフォーカスできるようになったこと。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

これにより調査⇔実行の往復でゴールが曖昧になることが減った。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

ただ、課題もあって。 最大の問題は自分たちが開発基盤チームであり抱えているインフラ・システムが多数で1人1人やっていることが違うという点。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

スクラムの最大の力、魅力を今の僕はゴールを1つにすることでチーム内での個人間の協力(と持続的組織的な成長)を引き出せる点だと思うんだけど、やっていることがバラバラだと1つのゴールというものを設定しづらい。 結果的にチーム総体でのゴールへの推進力が生まれづらい構造になっていると思う。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

たぶんこのバラバラのことをやっているということは計画・振り返りのコスト増・深度が浅くなるというデメリットも発生している。 ここら辺は業務性質、というより僕らの捉え方に改善余地があるという話かもしれない。うまくリフレーミングしてやればゴールを1つにすることも不可能ではないかも。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

もう1つはインフラ部署特有の、割り込みタスク問題なんだけど、これはまったく何も考察が進んでいないのでここでは一旦書かない。