こんにちは、渡邊です
ニフティさんが開催されているNIFTY Tech Talkにまたまた参加してきました。 今回は「スクラムマスターによるチーム改善LT！ ニフティのスクラムトーク vol 2」」ということで、スクラムをやってみたところのお話を聞くことができました。
ニフティさんは10〜20ほどのチームをスクラム開発で稼働させているそうで、始めたのは5年ほど前とのことですがかなりノウハウが溜まっているような印象でした。
対して、私の方は5名弱の非エンジニア部署にスクラムを取り入れた運用方法を導入しています。 もともとはフィヨルドブートキャンプでアジャイルやスクラムを学んで、チーム開発で実践した経験もあり、チームのタスク管理や目標達成と負荷の定量測定にうってつけだと思って自分の職場でもスタートしてみました。
とはいえ、スクールか職場のやり方しか知らないのでプロフェッショナルな運用や課題を学ぼうと参加してきました。
↓イベントの概要はこちらです。 engineering.nifty.co.jp
↓動画はこちら www.youtube.com
「チーム力を高めるスクラム実践法：カンバン公開と課題攻略について」
ベロシティの稼働率を想定する、というのは定量的に見ていなかったなーという部分。 前週の実績と今週の想定稼働率を出すことで、おおよその実績ポイントを求められるようになる。想定実績ポイントが求められるようになるとそこを下回った、上回ったでまた稼働の分析が取れるので良いやり方だと思う。 とはいえ、現職でやってると実績ポイントには波がめちゃくちゃあるのでここを有用なデータにするのは難しい気もする。
レトロスペクティブでしっかりチームの課題を振り返って議論していた。ここがなかなかできずにおざなりになってしまうことが多いんですよね。スプリントレビューとレトロスペクティブで長時間になるのでここまで行き着かないことが多いです(汗)
「スクラムチームと認知負荷」
こちらのLTは難しかったです…！
とはいえ、私でも分かる部分はちょこちょこありました。 教科書通りのスクラム組織をできていますか？という疑問提起と、多くはビジネス組織が根底にあってのスクラム組織なので教科書通りの構成ではなかなかできていないって話があって、たしかに私の組織でもプロダクト(ブランド)を8つくらい担当しているからブランドごとに優先順位も異なるのでまったく教科書通りにはなっていないですね。
同様に現代的な開発スタイル(アジャイル / リーン / DevOps)は従来のビジネス組織に根ざした設計になってないので、調整が必要。 でもその調整というのはトップダウンにビジネス組織やフローを変えられたらいいけど、なかなかできない。
そこでチームトポロジーが重視していることの一つが「認知負荷の制限」。短いスパンでデプロイするスタイルを維持するには認知負荷がかかる事象が多くあるとそれだけ開発効率が落ちてしまうということ。 そういうわけで、チームメンバーへの認知負荷を調整することでボトムアップでスクラムチームを稼働していくように改善していく…的なお話でした。
難しい内容でしたが、振り返ってみると腹落ちできました👍
参考
- チームトポロジーを読んだ #ちいとぽ - Mirai Translate TECH BLOG
- チームトポロジーを用いたRettyプロダクト開発体制の解説 #ちいとぽ - Retty Tech Blog
おわりに
認知負荷…というよりもチームメンバーの手間を減らす組織運営と考えると一般化できてちょっとわかりやすいかな、と思いました。それであれば私もボトムアップで職場に提案していたりしてましたね。うまくいきませんでしたが(´；ω；｀)
チームトポロジーは面白いですね。そのうち書籍も読みたいところです。
