2013年3月7日（木）にジュンク堂池袋本店で開催された「SCRUM BOOT CAMP THE TALK」のレポート。Part2は質疑応答・前編をレポートします。
■ブートキャンプ本をもっと知ることができる質疑応答・前編
◎『SCRUM BOOT CAMP THE BOOK』を読んで思ったことの話
プロダクトオーナーの見つけ方
―読んでいてプロダクトオーナーがすごい大変だと思いました……。チームから見たすてきなプロダクトオーナーとは、また、そのようなプロダクトオーナーの見つけ方を教えてください。
西村さん：近くから探したほうがいい。スクラムチームとしてうまくいけばいいので、誰がやってもいい。みんなで助けてダメなら変えればいい。
永瀬さん：確かに誰でもいい。やりたいことと理想を振りかざせる人。
吉羽さん：プロダクトオーナーはいろいろ決断しないといけないので、間違ってもいいから「こうしよう」と決められる人。ほとんどの意思決定は後からやり直せる。自分で決められない人は向かない。
持っていた方がいいスキル
―この本では、個々のスキルを洗い出していましたが、各自が持っていた方がいいスキルはありますか？
西村さん：朝、出社したときに挨拶ができること。これができない人はダメ。
開発チームであれば、毎日テストコードを書き続けられること（TDDなどの技法ではなく、もっと一般的な意味で）。大体の人は、プロジェクトの途中でテストが書けなくなってしまうが、スクラムをやりたいのであれば毎日続けられるスキルは必要。
永瀬さん：普通の社会人であること。意見を言うスキル。文書でも何でもいいけれど、意思表示をしっかりできる人。
吉羽さん：（みんなで合意した時間に出社するなどの）チームのルールに従うことができること。
◎スクラムと会社の話
スクラムを全て導入できない
―会社的にスクラムを全てやることは難しそうです。やるとしたらどれでしょうか？
西村さん：スクラムは「これだけは最低限できるでしょ」を集めたもの。だから誰も見ていないとしても「プロダクトバックログなど全部やる」というのが教科書的な回答。
自分1人でやるとして……、大事なところであれば、デイリースクラムや振り返り。あるいはロールをやってみるとか。月曜日はプロダクトオーナー、火曜日はスクラムマスター、残りはチームメンバーとして。
永瀬さん：ここだけは外してはいけないという勘所がある。それはやったことを反芻すること。次にまた同じことを繰り返してはダメ、だから振り返りをする。振り返りは、良い方向に変わり続けていくことを一番実現しやすい。
吉羽さん：プロダクトバックログで、どの順につくりたいかを決めること。「何が一番ほしい」がないと、いくら改善できてもお金を稼げない。
アジャイルの広め方
―アジャイルを身の回りに広めていくとき、この本の他にアドバイスはありますか？
西村さん：コミュニティ活動。自分だけだと心が折れそうになるが、コミュニティなど会社の外にいる人と交流すれば、もっといろいろなことを知ることができる。コミュニティには面白い話が転がっているので、ぜひ交流してほしい。
永瀬さん：社内に話せる人がいる状態が一番いい。でも頼りになったのは社外の人だった。
吉羽さん：名前が売れている人に「うちの会社でしゃべってくれ」と頼む。意外と引き受けてくれる。成功させたいなら、使えるものは何でも使ったほうがいい。「ダメで元々」で当たってみる価値はある。
岩切さん：仲間になってくれる人に本を買ってもらう。同じ本を読むと同じ言葉で理解するので、説明しなくても分かってくれる。
事業責任とプロダクトオーナーの間
―事業責任とプロダクトオーナーの間の役割がないような気がしていて、それがプロダクトオーナーの難しいところかなと思っています。
西村さん：権限がなければできないわけではない。会社によっていろいろなやり方がある。例えば、社内で話を通すのがうまい人をプロダクトオーナーにしたら、すごくうまく回った。会社全体の営業戦略会議とかプロダクトに影響しそうなものには、呼ばれていなくても片っ端から参加して情報を集め、会社が求める優先順位を決めることができた。
永瀬さん：判断はプロダクトオーナーに委ねないといけない。そうしないと、最後に事業主がひっくり返してしまう。プロダクトオーナーに権限を委譲することが大事。
吉羽さん：人事権も決裁権もないのにやらされたりとか、分かりづらいところかなー、とは思う。プロジェクトの種類によってプロダクトオーナーの選び方が違う。例えば、ゲームであれば「俺はこれをつくりたい」という人を選ぶと楽。言われたからやる人は、つまらないゲームをつくりそう。
◎スクラムとプロジェクトの話
スクラムに向くプロジェクト・向かないプロジェクト
―スクラムに向くプロジェクトと向かないプロジェクトはどういうものでしょうか？
西村さん：何にでも向く。スクラムを導入しているところもソフトウェア業界に限らない。スクラムは「みんなでやった方がいい活動」を抽出しているだけ。
スクラムが向かない理由の多くは組織。言われたままの仕事をやるほうが評価されるところでは、そういう仕事のやり方が向く。できない理由はプロジェクトではなく、組織にあるということ。であれば、それを変えましょうという話。
永瀬さん：つくるものに対するビジョンが生まれ始めたときから参画できれば、チャンスは大きい。開発だけスクラム、というのはうまくいかない。実際の現場には、プロダクトオーナー不在のチームもありえるが、それはスクラムチームではないので気をつける。
吉羽さん：例えば、言われたことしかやれない人が集まったチームは、改善し続けてゴールを目指すことが難しいチームなので、スクラムをやるのは大変。
官公庁、銀行、金融機関の基幹系なども向かない。そもそもスクラムをやらなくていいのでは。何とかしてうまくやろうと思っている人たちが集まっていると、うまくいきやすい。人によるところが大きい。人は変わることができるので、それを忘れない。
マルチベンダでのスクラム事例
―マルチベンダでのスクラムの適用例を教えてください。
吉羽さん：契約に依存するが……、会社ごとにチームを切らないほうがいい。みんな集めてチームを複数にした方が文化をつくりやすい。契約がらみでできない場合、「それどうやったら統一できるの？」という辺りをDoneの定義でガードしないといけないと思う。
プロダクトの成功に対して責任を負っているように見えることがない。プロダクトのビジョンをどう理解してもらうか、というところで工夫がいる。
永瀬さん：マルチベンダ＝大きなつくり物があって分割されているということ。それを1つのスクラムでやるのは、そもそもきつい話。
全体の整合性についてアジャイルのいいところを全て活用できるかというと、そうではないと思う。「ここはスクラム」「ここはウォーターフォール」は、ぜんぜんありだと思う。
西村さん：会社で分けると「うちの会社は失敗できない」と守りに入るので、1チームに同じ会社の人同士を入れないようにしないといけない。強権のプロダクトオーナーが「お前の会社ダメだから」と毎月変えているところもある。それくらいやらないと、大きいシステムはうまくいかない。
スクラムは問題が浮き彫りになるフレームワークなので、状況把握の手段として使い、リスクを下げるやり方もある。ただし、うまくいくかは別。
公認レポーター 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ページが用意されています。執筆裏話なども掲載されているので、書籍と合わせて楽しめます。
