nishida プロダクトバックログを管理するおすすめのツールは？
新井：
付箋と模造紙がベストじゃないかな（笑）。
Googleスプレッドシートもいいですよね。同時編集できるっていうのがポイントかな。
中村：
私も、できればリアルで壁に縦長の模造紙を貼って、そこで管理すればいいんじゃないかなと思います。
ベロシティや見積もり計算がしたいのであれば、やはりスプレッドシートかな。
新井：
クラウドサービスは便利だけど、それに使われちゃってる感じがすることもあります。
リモートワーク全盛期ではありますが、あえてアナログから始めると必要なエッセンスが体感として分かります。
miroとかMURALとか、アナログ性のあるオンラインホワイトボードツールがおすすめかな。
中村：
実際に、タスク管理も含めてすべてmiroでしている現場がありました。カンバンの形とか、バックログに何を置くかとか、運用しながら自分たちのスタイルを見つけていっていましたね。
自分たちに必要な情報や進め方が見つかってから、それに合うツールを探せばいいと思います。
新井：
「汗をかき手を動かして」みたいな根性論を言いたいわけではなく、「順番として」しっくりきますよね。
あと、ホワイトボード系のツールだと「改造」しまくれるんですよね（笑）。デコレーションしたりとか、とにかく自由度が高い。
それがデメリットになることもあるんだけど…。自分たちでカスタマイズすることで、「スクラムマスターのもの」ではなく「自分たちのもの」に変えていけるんですよね。
全員で作っていけば、自己管理型チームの見える化ボードに変えられるんです。
中村：
自分たちのものにするっていう感覚は、すごく大事ですね。
自分たちが成果を出せるように、使うツールややり方を決めるというのは、自分たちで快適な仕事場にするという意味合いもあると思います。
例えば、プロダクトバックログを誰が書いているのか？ 常にプロダクトオーナーしか書いていないこともあれば、スクラムマスターも開発者もみんな一緒に書く場合もあるかもしれません。
最終的な順番を決めるのはプロダクトオーナーでも、それほど大きくないチームであれば、オンラインホワイトボードツールを使って、みんなでアイディアを出し合いながら「わちゃわちゃ」やるのがいいような気がしますね。安心します。
新井：
ログとしても残りますしね。
中村：
参加者の皆さんは、どんなツールを使っているでしょうか？
参加者コメント：
中村：
ありがとうございます。参考にしていただけたらと思います。
Message from coaches
- 付箋や模造紙を使ってアナログから始めてみるのがおすすめ。自分たちにとって必要なエッセンスが見えやすい。
- ポイントは同時編集ができること。見積もり計算ならGoogleスプレッドシートもおすすめ。
- miroやMURALなどアナログ性のあるオンラインホワイトボードツールもおすすめ。カスタマイズがしやすく、自分たちなりのスタイルを見つけやすい。
- 「自分たちのもの」という感覚を持てることが大事。みんなでアイディアを出し合いながら「わちゃわちゃ」することで、自己管理型のチームに近づける。
- まずはアナログにやってみて、自分たちに必要な機能や情報、進め方がある程度明確になってから、それに合うオンラインツールを探してみては。
プロダクトバックログをチームで管理するには？
中村：
お申込み時にいただいている参加者アンケートからのトピックです。
アンチパターンから言うと、プロダクトオーナーだけがせっせとカードを作って書き込んで、開発者は読むだけというのはちょっとさみしいですよね。
新井：
全員で育てていく感じだといいですよね。
開発チームからプロダクトオーナーに提案してもいいし、もし自分の家族がユーザーなら、そこからのフィードバックをプロダクトゴールに入れてもいいと思います。
映画だったら、エンジニア一人一人がエンドロールに堂々と自分の名前も載せたいって思えるようなプロダクトに仕上げていかなくてはならないので、自分の名前は載せたくないって思っちゃうのは困ります。
中村：
リファインメントとか、みんなで集まってわちゃわちゃとバックログを触るみたいなこともやっていいと思います。
「誰かのもの」じゃなく「みんなのもの」っていう形になるのが大事です。
参加者コメント：
チームの生産性を考えるときに、完了したプロダクトバックログアイテム（PBI）のストーリーポイント（SP）の合計値をチームのベロシティとして見るケースがあると思います。このとき、各PBIに設定したSP値が妥当なものになっていないと、チームのベロシティ計算も正確なものにならないと思います。
SP値の設定の仕方そのものを見直す活動などはしていますか？
中村：
3ポイントだと思っていたのが、終わってみたら実は違う数値だったらどうするの？ みたいなことかな。
まず前提として、個々のバックログの精緻さを上げても凸凹は当然あると思うんですよ。体験としても結果的におしなべていい感じになることがわかっているので、私は変えないですね。
終わってみて大きく違っていた場合は、その先に類似するものが出てきたらアップデートを検討するくらいかな。
新井：
大体平坦になっていくというのは、同じく経験則として感じます。私も、スプリント開始前までならアップデートしちゃいますが、終わったものに対してアップデートをかけることはほぼありませんね。
ただ、「ズレていたね」という会話はどんどんしていっていいと思います。
中村：
そうですね。「ズレていたから、次の似たようなバックログはアプローチを変えようか」というくらいですよね。
こんなことを言うと語弊があるかもしれませんけど、そもそもベロシティってただの相対見積もりなので、そんなに精緻には出ないと思うんですよ。
凸凹を実績に合わせようとしても、労力の割に得られるものは少ないんじゃないでしょうか。
新井：
たしかにそうですね（笑）。
参加者コメント：
お客様からチームのベロシティ分析を求められているため、対応に苦労していました。とても参考になりました。
中村：
ベロシティはあくまでも自分たちのために使うものなので、お客様や外の人から求められるというのは、本来の使い方からちょっとズレちゃっているんですよね。
どうしても必要なら、バーンアップチャートの方が適しているような気がします。
Message from coaches
- 「誰かのもの」ではなく「みんなのもの」になるように、全員で育てていく感覚を持とう。
- リファインメントではみんなが集まって「わちゃわちゃ」と手を動かしてもいい。
- 完了したプロダクトバックログアイテムのストーリーポイント値をアップデートする必要はない。大きく違った場合は、次に類似するものが出てきたときに設定の仕方をアップデートしよう。
- ベロシティは本来自分たちのために使うもの。相対見積もりなので精緻に出るものではないことを覚えておこう。お客様に示す場合はバーンアップチャートの方がおすすめ。
プロダクトオーナーがプロダクトバックログの着手順を決められない
新井：
恐らく、優先順位を決められないということですよね。
対応としては、例えばインタビューしてファクトを取りに行くとか、開発チームのメンバーと相談しながらスクラムチーム全員で決めるのもありです。
中村：
決断力が弱くて自分で決められないとか、決めても別の人がひっくり返しちゃうっていうこともあるのかな。
新井：
ああ、そういうケースもありえますよね。でもまあ、決めるっていう行為が大事なんですよね。
誰も完全な正解はわからないので、決めて動くことが大事じゃないかな。
中村：
最初は下手でも、自分がなぜそう思うのかを話してみて、周りの人もサポートしてあげるといいですね。やってみた結果を踏まえて、次をまた考えたらいいと思います。
新井：
サイクルで回しているメリットはそういうところにありますからね。
Message from coaches
- 優先順位を決められないときは、判断材料となるファクトを集めるためにインタビューをしたり、スクラムチーム全員で話し合ったりしてみよう。
- 完全な正解は誰にもわからない。まずは決めて動くことが大事。やってみた結果を踏まえて、次をまた考えよう。
- 最初からうまくいかなくてもいい。決めたらなぜそう思うのかを言葉にして表明してみよう。
- 周りのメンバーはプロダクトオーナーをサポートしよう。
redjourney.jp