スクラムイベントにもの思い
23時に寝て6時半に起きた。昨日は疲労困憊だったのでなんもせずすぐ寝た。
スクラムイベント⌗
お仕事のスクラム開発で木曜日はスプリントレビューとプロダクトバックログリファインメントを行う。主にステークホルダーとプロジェクトオーナーがプロダクトバックログアイテムの優先度を議論したり、タスクに細分化されていない課題をタスクにしていくための作業に当てたりしている。本当はタスク化されたイシューをさらにリファイメントするイベントなのだろうだけど、まだそこまで業務やチームの体制が成熟していないため、タスクの細分化のための時間になっていたりしている。
これらのイベントで開発者がイニシアティブをとることはないけど、プロダクトオーナーやその業務チームにいるメンバーたちがどうやって業務をタスク化しているかのやり取りもみえたりする。開発者にとってそのやり取りをみていることに意味があるかどうかはまだ私にはわからないが、業務チームのメンバーがどういった働き方をしているかを知るきっかけにはなる。業務チームは miro を使ってメンバーみんなで同時編集しながら課題を付箋代わりのメモに落としていく。その個々のメモがタスクに近いものになるのだろうけど、私からみたら業務すべてを知っている人がまとめて細分化してドキュメントに書き記して2-3回みんなでレビューすれば終わるようなものを、みんなで付箋紙に書いていって整合性が取れているのかどうかわからないメモの固まりを作っているようにみえる。この作業はみんなでやらないと進捗しないので1週間に1回とかになる。
- チームが扱うすべての業務を知っているメンバーはいない
- 業務に必要な機能の優先順位や優先度を決める権限をもっていない
- 情報が足りないと思ったときにメンバーが自律的に動いて補う体制が整っていない
あとステークホルダーが話す要件や仕様に関わってくる話の大半が口頭で行われていてドキュメントや課題管理に文章として書き記されていない。だから同じ話しを何度も繰り返し聞くようなケースも発生する。わからないことを聞くことも、繰り返し聞くことも問題ではないが、議事録以外にそこで話す内容がドキュメント化されないのはどうしてだろう?という気もした。もっともっと文章を書かないと情報共有やノウハウをためることにはつながっていかないだろうということも垣間みえる。
総括すれば、どんな開発方法論を使っても、リーダーやマネージャークラスが圧倒的に文章を書けないと、その配下のメンバーは自律的に行動できないというだけの話しでしかないが、どうやったら解消できるか?はまだまだこれからの私の課題でもある。