RareJob Tech Blog

レアジョブテクノロジーズのエンジニア・デザイナーによる技術ブログです

#2 スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみる(全5回)

まえがき

レアジョブテクノロジーズの三上です。

2回目の投稿です。前回から1年と4ヶ月振りの投稿です。お待たせし過ぎたかもしれません。

前回の記事 -> #1 スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみる(全5回) - RareJob Tech Blog

早速ですが、今回もインタビューを受ける気持ちで直感で答えてゆきます。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

前提としてプロダクトバックログは優先度の高いもの、価値のあるバックログアイテムから順に並んでいるはずです。もしもそうなっていないのなら、まずはその議論からはじめます。

また「価値のあるストーリー」は組織の状況、市場の状況によって変動するものという前提です。各ストーリーの先には組織またはチームが達成したいゴールがあるはずです。毎日忙しいとゴールは見失いがちです。何度でも問いかけて良いと思います。

目指す先があって、チームの目線が揃ってこそ建設的なプランニングができると思うのでそこを意識してファシリテーションします。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

ユーザーストーリーのWHOに依存すると思いました。例えばエンドユーザーであればCVRやLTVは成果として分かりやすく適切に思いますし、社内の人であればコスト削減の結果の数値だったり可能な限り定量的な目標にしたいです。

リファクタリングや負債解消を目的としたストーリーの場合、前提としてDORAなどのメトリクスを計測できているとプロダクトオーナーと優先度の会話もしやすくなると思います。

そんな我々もDORAメトリクスの計測をはじめました!!(大事)

受け入れがたいものは前述の逆で、抽象度の高いものや誰がどう判断できるのか説明できないものは避けるべきと思いました。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

コミットメントの権限 の解釈が難しく思いましたが、チームとステークホルダー(PO)の間でデリバリーの確約に対するズレが生じた状況を想像しました。

ここでお互いの達成したいことは何だろうと考えた時に「価値のあるユーザーストーリーを選べる」ように支援することだと思いました。双方の「ズレ」が何なのか観察して問いかけ、解決に導くようにします。このような状況では、あくまで第三者的な観点を持ち、冷静でいることを意識しています。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

正直なところ状況による と思いますが、経験上はリファクタリングが後回しになりがちな状況があるあるだと思いました。この状況の場合は、「ベロシティの3割程度はあえてプランニングに含めずに改善の時間として使う」ということを試したことがあります。この時間がなぜ必要で重要なのかはチーム全体で納得いくように支援します。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

面白い質問ですね。笑

幸いこの状況になったことがありませんが、あるとしたらチームへの信頼がないのだと思いました。チームはあなたが思っているより優秀だし、マイクロマネジメントは必要ないと伝えます。逆にチームが未成熟なのであれば、自律思考になるようにチーム側を支援すると思います。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

絶対にやってはいけない!とは強くは言わないですね。

なぜつまみ食いしたのかを確認して、それが必要なものだったとしたら透明性やベロシティの重要性を伝えます。自分の担当すべきアイテムが完了していて、スプリントゴールも達成しているって前提だったとしたらチームに共有した上でつまみ食いも良いんじゃないかと個人的には思います。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

完成の定義が決まっていないアイテムを計画に入れた場合、意図していないもの=価値の低いものになってしまう可能性があるのでそれを伝えます。また、ストーリーとして確定していないのでポイント見積もりも出来ていないので、他のストーリーが完成できないリスクもあるかもしれない。それでも追加したいですか?とまずは問いかけますね。

どうしても、というならあえて失敗して学ぶのもアリと思う。それがスクラムの強みでもありますし。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

時間の無駄と感じる理由から聞きたいですが、実際にありそうなのは「プランニングが直接自分に関係のない話だ」と感じるとしたら、本当に関係ないか?と問いたい。チームが分業のようになってしまうのはよくあるパターンだと思うので

スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的(プロダクトゴール)に集中している専⾨家が集まった単位である。

というスクラムガイドにある記述を引用しつつ、チーム開発をするメリットを理解してもらえるよう会話します。多くのメンバーがそう感じるとしたらスクラム自体の採用を見直す議論も必要だと思いました。

終わりに

いくつかは回答に詰まるものもあり、改めて考え直す良いきかっけになりました。レアジョブテクノロジーズでの開発に少しでも興味を持っていただけたら嬉しいです。

We're hiring!
弊社では、一緒に働いてくださるエンジニアを募集しています。
rarejob-tech.co.jp