1時に寝て7時に起きて午前中はだらだらしていた。午後からオフィスでちょっと作業して夜はドラクエタクトしてた。

スクラムの悪いところ⌗

金曜日に メタバース雑談会 に参加してチームビルディングや課題管理の雑談になった。そのときに課題管理やスクラムの概要を話してみたけど、多様なメンバーだといま一つ手応えがなくてコンテキストを揃えないと組織論の話しは難しいなと思えた。コンテキストが共有できていない状況ではあまり雑談に向く話題ではなかった。そんな中でスクラムの悪いところを考える機会が最近多いので簡単にまとめてみようと思う。もちろん、スクラムにはよいところもたくさんあって世の中に普及しているのはそれがためだと思う。よいところはすでにあちこちで言われているだろうから、あえて、ここでは悪いところを整理してみようと思う。

  • 心理的安全性のないチームではぬるま湯と化す
  • プロダクトオーナーに超人を要求する
  • スクラムイベントが時間とともに形骸化していく

スクラムが悪いのではなくチーム (組織) が悪いということもできるが、スクラムを1年近くやっていて陥っているのでスクラムの影響は大きいと考える。

心理的安全性のないチームではぬるま湯と化す⌗

スクラムでは個人の責任を問われることはなく、名前の通り、チーム一丸となって課題に取り組むことを意図するプラクティスなので、悪く言えば、個人の怠慢が問われることもまずない。ここでいう怠慢は悪意をもったものではないとしても 社会的手抜き を容易に発生させる。個々のメンバーの責任を減少させると必然的に裁量も減少してしまう気がしている。ある課題がうまくいかなくても自分の責任とは言えない状況であればそのまま放置してチームが解決してくれるのを待つという選択が合理的になるケースが出てくる。これは人間の習性として抗いがたいと私は考えている。楽をしたいのが人間だと思う。必然的に楽な方に引き寄せられていく。克己心とまで言わなくても自分を律して課題に取り組んでいないとスクラムの枠組みではいくらでも楽をしてしまえる。業務としてその品質や納期に一定の厳しさをもっていないチームは簡単にぬるま湯と化してしまう。

プロダクトオーナーに超人を要求する⌗

以前、こみやさんと話していたときに出た話題。スクラムはすべての責任はプロダクトオーナーが負うことになっている。プロダクトオーナーは開発者でないことが多いと思われる。建前としては開発がうまくいかないことの責任をすべてプロダクトオーナーが負うことになるが、これはフェアとは言い難い状況もある。はらさんと話していると、プロダクトオーナーは無茶苦茶な要求を開発者にしてしまいがちなのでそれをなだめたり指導したりするポジションとしてスクラムマスターがいるという話しも聞く。うちのプロダクトオーナーは人格者でまったく無茶な要求をしない。おそらく現場出身の方なのでシステムに疎いことは周りも理解していて開発責任を問われていないのではないか推測する。プロダクトオーナーに責任が集中している割にスクラムマスターが盾になることで開発への口出しは制限される。またスクラムマスターも業務上の責任をなんら負っていない。スクラムマスターの助言を遂行する責任はすべてプロダクトオーナーに求められる。スクラムは業務の役割分担としてプロダクトオーナー、スクラムマスター、開発リーダーの三位一体のような構成を取るものの、責任をプロダクトオーナーに押し付けつつ、プロダクトオーナーの権限を奪う構成ともみれる。

スクラムイベントが時間とともに形骸化していく⌗

スクラムに不慣れなチームがスクラムガイドに書いてあることを実践していくには少し時間がかかるし、スクラムマスターのようなスクラムガイドを熟知しているメンバーに指導を仰ぐのは理に適っている。しかし、半年もやればスクラムガイドの手順やワークフローをメンバーは習熟する。実際にうちのスクラムマスターはふりかえりのファシリテーション以外にやることがないとちょくちょく発言していて、実際にデイリースクラムも半分ぐらい休んでいる。ファシリテーション以外で業務のイニシアティブを取ることはない。スクラムマスターがドメイン知識を身につけるべきかどうか、私はまだわからないが、うちのスクラムマスターはドメイン知識を習得していないので業務の話にはまったく入ってこれない。少し前に ゾンビスクラム という言葉を教えてもらったが、スクラムイベントのいくつかはただこなすだけの業務になりつつある。うちのチームのスプリントの実態やストーリーポイント運用は私からみたら課題だらけだが、ダメなところも含めてその予定調和に慣れてしまって複雑で難しい問題を改善しようとしていないように私からはみえている。