2013年3月7日（木）にジュンク堂池袋本店で開催された「SCRUM BOOT CAMP THE TALK」のレポート。Part3は、質疑応答・後編をレポートします。
■スクラムの活用方法も知ることができる充実の質疑応答・後編
◎プロダクトオーナーの話
プロダクトオーナーがチーム外で気をつけること
―プロダクトオーナーは、チームの外のどこに気をつければいいでしょうか？
西村さん：プロダクトオーナーはステークホルダーを管理しないといけない。その中でも、攻めないといけない人とは毎日話すこと。プロダクトオーナーは下手をすると集中砲火を食らってしまうが、ほとんどは相手をしなくて大丈夫。周囲が思ったように走らないと不安に思うことが多い。その不安を払拭できているか。
永瀬さん：本当に話を聞くかどうかはともかく、協力者をたくさんつくる。ステークホルダーは全方位的に見たほうがいい。唯我独尊だと思われると協力してもらえなくなる。気を遣うのとは違う意味で、いろいろな人の話を聞き、情報を集める。
吉羽さん：大きいシステムでは政治の話が出てくるので、その辺りは押さえておいたほうがいい。これはスクラム関係なく円滑に進めるために大事なこと。プロダクトオーナーは最後には「えい！」っと並べ替えるしかない。みんなの話を聞いて意味のない並び順にしても仕方がないということ。
自覚のないプロダクトオーナー
―プロダクトオーナーが自覚を持っていない場合、何から手をつけるかいつも困っています。
西村さん：プロダクトオーナーが機能しないというのは「あるあるネタ」で、みんなつまずく。プロダクトオーナーは悪くなく、それはプロダクトオーナーが担う部分が弱っているという話。問題がわかってよかったねというのが1つ。
「じゃあどうするの？」というのはみんなで考える。できていないなら、それはスクラムマスターがきちんと教育したり伝えたりしていないということ。朝、じゃんけんに負けた人がプロダクトオーナーに電話するとか、そこまでやればプロダクトオーナーもやる。それでもダメなら、スクラムチームとしてプロダクトオーナーを誰にするかを考えればいい。
永瀬さん：スクラムマスターは開発者からなった人が比較的多いので、プロダクトオーナーよりも開発チームを向いてしまう。だから思っている以上に、プロダクトオーナーをケアしたほうがいいと思う。プロダクトオーナーの代理によってレビューが回っているなら、実際はその人がプロダクトオーナーかもしれない。
吉羽さん：プロダクトオーナーは結果責任を負うべきなので、プロダクトバックログを並び替えないなら、開発チームはビーチに行くかスキーに行けばいい。1回痛い目を見せる、という愛のムチもある。
◎スクラムチームの話
アジャイルが軌道に乗るまで
―アジャイルには慣れるまでのオーバーヘッドがあると思っていて……。損益分岐点というか、どれくらいやると軌道に乗るイメージを持っていますか？
西村さん：1チームなら、毎日ケアして1ヵ月。毎日ケアしなければ、3ヶ月くらいは軽くかかる。
永瀬さん：もともとのチームがどういう仕事をしていたかにもよる。それまでのやり方によって、大丈夫な箇所と弱い箇所が出てくる。良いチームに「見えるだけ」なら1週間くらい。中身が「まあまあ」になるまでは3ヶ月くらい。
吉羽さん：初めてスクラムをやるチームで案件が大きくない場合、スプリントを小さくする。まず「山のように改善することあるよね」ということで、1週間。こういうケアの仕方なら1ヵ月くらい。あとはチームメンバーに依存。
岩切さん：7年もののアジャイルチームを知っているが、まだ完璧ではない。未だに問題があったりする。問題はいつでもあるということ。だったら、成功するイメージを持つことに集中したほうが、うまく回るのではないかなと思う。
理想のスクラムチーム
―理想のスクラムチームとは、具体的にどういうものでしょうか？
吉羽さん：毎回どんなチームに入ったときでも「もっとうまくできたはず」と思う。自分の関わる量によらず、そう思うし、毎回後悔がある。改善していけるチームが理想なのかなー、とは思う。
西村さん：スクラムとか言わないチーム。ロールとか関係なく、自分たちがつくっているものが代表作で「これがうまいっていない」とフラットに言えるチーム。楽しそうにやっていることが理想。
◎複数プロジェクトをかけもちしている場合の話
複数プロジェクトにアサイン
―メンバーが複数のプロジェクトにアサインされている状況でも、スクラムはできますか？
西村さん：できる。
ベロシティが安定しない・測定できない
―ベロシティが安定しなかったり、測定しようがなかったりして管理が難しくなったことがありました。
西村さん：そうなる原因をクリアすればできる。朝会でプロジェクト毎の時間配分と、そこからできる作業量のデータを集める。ベロシティは安定しないが、それはあくまでも目安。自分たちがどれだけできるかが分かればいい。工夫をすればいくらでもできる。
永瀬さん：プロダクトバックログを1つにするとか、やり方はあるけれど……。本質的な問題はそこではない気がする。
吉羽さん：マルチプロジェクトは、ストレスがたまりやすいし品質も悪くなる。まずそれを解決した方がいい。
◎「プロダクトバックログとスプリントバックログでは、そもそも測定するものが違うんだよ」という話
ストーリーポイントの見積もりとタスクの見積もり
―ストーリーでは相対、タスクでは時間。ここで不整合が発生したとして、どういうタイミングでメンテナンスすればいいでしょうか？
西村さん：そもそも見積もっているものが違う。そもそもつながっていない。ストーリーポイントの見積もりはスクラムチームが先を見通すためのもので、タスクの見積もりは開発チームがスプリントでやるためのもの。世界が違うものをつないでもあまり意味がない。うまくいったときに「うまくいったなー」と思えば大丈夫。
吉羽さん：短期的にメンテナンスは要らない。次の見積もりの精度に生かせればよくて、数字遊びをしても意味がない。経験を蓄積すれば精度が上がり、だんだん合うようになるはず。
プランニングポーカーでストーリーポイントを見積もる場合、大きい数字になると差の意味が曖昧になる。ばくっと全体像を捉えることが大事。
合意した見積もりを達成できないとき
―メンテナンスをしないと、スプリント計画ミーティングで合意したストーリーの数が達成できなくなるのでは？という不安があります。最終的には合うとしても……。最初に合意したものが達成できないときなど、うまく説明できなくなってしまいます。
西村さん：「これだけやれそうです」「…やれませんでした」というのは、タスク見積もりの話ではない。その問題をプロジェクト期間内に解決することの方が大事。時間単位まで見積もって「…やれませんでした」という話であれば、なぜ見積もりが外れたのかを考えることの方が大事。
吉羽さん：開発チームが毎回10ポイントつくらないといけない状況は、そもそもまずい。どんなに理想があっても、開発チームの持つ速度以上には走れない。過去の実績ベースで計画を立てたほうがいい。
タスクを分解したら全然多かった場合は「入らないのでできません」とプロダクトオーナーに言わないとまずい。スプリント計画ミーティング第一部で合意したものを「任せるから保証してね」というのは、スクラムチームの関係性ではない。
岩切さん：必要だと思ったら時間を見積もりし直ている会社を知っている。そこは、必要がなければ時間をとらない。
◎最後に
『SCRUM BOOT CAMP THE BOOK』の話を聞くつもりで参加したのですが、スクラムそれ自体の話もたくさん聞くことができ、とてもいい経験になりました。
翔泳社さん、岩切さん、西村さん、永瀬さん、吉羽さん、ジュンク堂書店さん、ありがとうございました！
公認レポーター Eiichiro Ogura
もっと知りたい！SCRUM BOOT CAMP THE BOOK
『SCRUM BOOT CAMP THE BOOK』
- 出版社：翔泳社
- 発売日：2013-02-13
あわせて読みたい！
『アジャイルサムライ－達人開発者への道－』
- 著者：Jonathan Rasmusson
- 出版社：オーム社
- 発売日：2011-07-16
著者
西村 直人さん
- about.me：Nishimura Naoto
- Twitter：@nawoto
- Blog：ヲトナ.backtrace
永瀬 美穂さん
- about.me：Miho Nagase
- Twitter：@miholovesq
吉羽 龍太郎さん
- Twitter：@ryuzee
- Blog：Ryuzee.com
交流するには
ハッシュタグ：#scrumbcbook
読者と交流用にFacebookページが用意されています。執筆裏話なども掲載されているので、書籍と合わせて楽しめます。
