認定スクラムマスターになりました

James Coplien 氏が講師を務めるアギレルゴコンサルティングの「認定スクラムマスター研修」を受け、その感想をまとめた。

受講のきっかけ

「すくすく開発会」という社内の開発プロセス改善などに関心のあるスタッフの集まりで、研修を受けてみてはと声をかけられたのがきっかけ。研修の経験者にどうだったか聞いてみると、「体系的に理解できる」「重要な部分を知れることができる」とのことだったので、「用語の意味はなんとなくわかる状態」の自分には良いかも、と思い受講を決めた。

参考：はてなの開発プロセスを改善する、すくすく開発会とプロジェクトテンプレート講義のご紹介 - Hatena Developer Blog

思ったこと

プロダクトオーナーどうする

スクラムの世界では、明確なビジョンを持ったプロダクトオーナー（PO）が存在し、開発者たちはただひとりの PO、プロダクトを持っている。

ただ、現実はそうではないし、そうするのが良いかもわからない。

だから、PO の役割を考えて、現状その役割を誰がしているのか、誰もやってないのかを明らかにして、その役割がどうあるべきか考える必要がありそう。

見積もりは適当で良い

見積もりは必要だが、それ自体では開発は進まないため、ポイントを決めるのに長時間議論する必要はないので、シュッと決めてしまうのが良い。

シュッと決めるには、

• ポイントの最小値、最大値を出した人が話して、再びポイントをつける

  • それ以外の人はあまり話さない

• あらかじめ投票が割れたときにどうするか決めておく

  • 平均 or 中央値にする

  • そのタスクをわかってそうな人の出したポイントにする

  • ポイントが多い方（少ない方）にする

などの方法がありそう。

ポイントがめちゃくちゃにズレる場合は、そのプロダクトバックログアイテムのゴールとか実現方法の認識を揃える必要がある。

障害リストをあまり触ってなかった

障害リストに近いリストはあるが、頻繁に触ってないし順序付けもしていなかった。プロダクトバックログやスプリントバックログと同じように整理された状態を維持したい。

チームで動くにはどうすれば良いか

「チームで判断できることは何か / 判断できないことは何か」ということを考える機会になった。

権限が明確になると、どこまで進めてよいか、どのように進めればよいかがわかりやすくなるので、より円滑に動くことができそう。

受けてみてどうだったか

受ける意味はあったと思う。改善案だったり、それの種になるような考えが得られた。ただ、若干冗長に感じる部分もあった。

質問の機会があるのは良かったと思う。自分も質問してみたけど、そもそも質問の前提がおかしくて微妙に噛み合ってない感じになることがあった。そこで自分の認識がズレていることがわかって良かった。

次にできそうなこと

見積もりとかタスクの整理とかは取り入れられそう。

大きな話になると権限委譲の話とか。どこまでやってよいかが明らかでないと、自分（チーム）で考えて行動するのが難しい。誰にどんな役割・権限があって、どこまで期待されているのか・しているのかを明らかにするのは自己管理に繋がると思う。

権限の問題は PO いない問題にも関係してくるので、デリゲーションポーカーを遊んでみるのもいい気がする。