毎週、チームのエンジニアで今週の振り返り会をやっている。今週の開発フローはいかがでしたか、ここが困る、ここがよかった、というのを持ち寄って、じゃあ今週はここをこう変えましょう、というのを30分間で決める会。
開発フローをミスると悲惨なことになるのでファシリテータの責任は重大で胃が痛くなるかというとそうでもなくて、毎週持ち回りで気楽に運用できている。
- 問題について話して、だいたい認識が揃ってたら変える
- 悪かったら来週また変えればいいので、とりあえず変えてみても、そんなに悪いことにはならない
- 良いか悪いかわからないときは、一人だけ変えてみる
- 「今週はいかがでしたかというフォーマットなので、長期的なことを書きにくい」という課題が上がってたので、「今月の話を持ってきても違和感ないかもしれないから、来週一人だけ書いてみる」というので、課題をあげてくれた人だけ開発フローを変えて実験してみるということになった
みたいな形で、どんどん変えられている。
社内でも人数多めのチームで、人数が多いときに完全な合意を得ようとすると、90%まではいけるけど100%にするには時間が3倍かかり、2分が6分になる、みたいなイメージがある。なので、大枠よかったら試してみましょう、という、意思決定の負荷と精度を下げて、実験しているような雰囲気になってきている。
アプリケーションをどんどんリリースしたり、半分だけ仕様を変えてABテストしたり、というのと同じ形のことを開発フローでもやっている、というこになっているのだな、と書いてて思った。
id:papixさんが書いてた、ルールの決め方3種類に加えて、実験型というのもあるのではないか、というのを思ったので書いてみました。
制度の抜け穴を突いて勝手にやるんじゃなくて、実験しましょうってところまで合意が取れるともうちょっと穏便に進められそう。しかし実験することのついての合意は合議制による…となるとあまり変わりない気もする…。
提案されたルールの決定においては, ｢合議型｣と｢論戦型｣と｢トップダウン型｣がありそう.
■ - パピッター
(中略)
現状の制度の抜け穴とか突いて, 提案した制度に似たようなことを実際にやってみて, その効果を宣伝しつつ, いろんな人に実施してもらって, まあ悪い言い方をすれば｢既成事実化｣するみたいな感じ. そうなってくると, その制度の良いところも悪いところも見えてくると思うので, それを元にOK/NGを下せば良い, となるので合議のフェイズを飛ばせるのではないか
