スクラムの窮屈さ
0時に寝て5時に起きてちょっとだらだらして7時ぐらいにはオフィスにいた。
スプリントの期間とプランニング⌗
いまスクラムのスプリントを1週間で運用している。スクラムのスプリントレビューをやっていて、今回のスプリントはスプリントゴールが未達となったという事実がありつつも、ある開発者が本来のスプリント計画にはなかった課題を少し工数を使ってやってしまってたという話題が出た。それはある機能開発の調査の過程でこういうツールがあると業務メンバーの作業効率が上がりそうだとわかって、それをヒアリングしていた開発者が PoC も兼ねてプロトタイプを作っているうちにすぐ運用で使えそうなベータレベルまで作ってしまったという話し。言うても2日ぐらいで作ったと思うのだけど、5日しかないスプリントで2日は40%という大きな工数を占める。スクラムマスターも否定はしなかったけど「スプリントの計画にないタスクに工数を割くのはよくないと、スクラムマスターの立場からはお小言を言わざるを得ない」と言及した。
先日、私も直接はスプリントの計画達成に直接寄与しない リファクタリングに半日を費やした ので、ツールを作ってしまった開発者の気持ちはわかるなと無言で聞いていた。それと同時にスクラムのスプリントは、運用によっては開発者のモチベーションを削ぐことも実感した。やる気の有無で仕事をするのはよくないと一般論では言うけど、実際のところ、人間のモチベーションは制御が難しいのと、知識労働はモチベーションが生産性に大きな影響を与える。開発者のモチベーションが高いときにそのタスクをやるのは理に叶うという側面もある。非開発者は次のプランニングで承認を得て来週のスプリントでやればいいじゃないかと思うかもしれない。でも、違うのだ。いまやってみたいという気持ちが大きいときにいまやるのと来週やるのではモチベーションが異なる可能性がある。この気持ちは開発者にしかわからないと思う。
その開発者がデイリースクラムでツール開発をやることを相談しなかったかの理由も理解できて、合理的に考えたら相談しても承認を得るのは難しいので、黙ってやってしまったのだろうと思う。そして、今回のスプリントのスプリントゴールが未達になったとしても、なにか業務に影響が出るというわけでもないことをメンバーが知っているというのもある。スプリントは全力でやるものだけど、全力でやらなくてゴールが未達になっても、なんら業務に支障がでない事実がスプリントの目的を減衰させている。
そういう業務と実情があっていない現実、ルールに則るとお小言を言わざるを得ない牽制機構、たった2日すら自由に時間を使えない開発者、なんかスクラムって窮屈だなと直観的に感じた。