DoorKeeper
http://taoofscrum.doorkeeper.jp/events/4145
場所はバンダイナムコ未来研究所です。
参加者は40人くらいでしょうか。
以下の書籍を題材にしたスクラム道のイベントなのです。
 | SCRUM BOOT CAMP THE BOOK (2013/02/13) 西村 直人、永瀬 美穂 他 商品詳細を見る |
もちろん私も既読です。
スクラム道のイベントは本日19時からです。内容は書籍やScrumに関することを直接聞ける No-Bull Know-How を予定しています。著者やスクラム道スタッフに色々聞いてみよー http://t.co/Le9bjS2NCL #scrumdo #scrumbcbook
— Nishimura Naoto (@nawoto) June 21, 2013
この日は「No-Bull Know-How」という形式での進行でした。
参加者がスピーカーと一緒に壇上でディスカッションするセッションです。
「みのもんたの人生相談」をイメージするとわかりやすいとのことｗ by @nawoto
最初、壇上に上がろうとする参加者さんがぜんぜんいなかったんですが。。。。
さすがは西村さんでした。絶妙なトークと進行！
その後、壇上に相談に上がろうとする参加者が途絶えることはありませんでした。
この段取りと進行の上手さは見習うべきトコですね。
あと、今日はスクラム道のメンバーも多数参加されてました。いろんな意見が聞けてよかったです。
以下、個人メモ。
■ Q1. スプリントレトロスペクティブ（振り返り）の形骸化について
Q.
スプリントレトロスペクティブ（振り返り）で、振り返りするネタが無くなって来たので止めたいと思っている。
理屈では振り返りは継続したほうが良いと思ってはいるのだが。
プロジェクト後期での、振り返りのオススメなやり方があれば教えて欲しい。
A.
振り返りは自分達でしないといけない、ということを、プロジェクト後期までにチームメンバに理解してもらわないといけない。
振り返りって大事だよね、楽しいもんだよね、というのをまず理解してもらうのが大事。
改善アクションの効果が少ないのでやっても意味がない、という考えはいったん捨てる。
たまには「１００倍効率良くなる方法をブレストしようぜ」と言った感じに、ぶっ飛んだ発想を出させる。
美味しいお茶を飲みながら、１０分～１５分くらいの短い時間ででブレストをする。
そうすると「やめよう」とはなりにくい。
開発後期で忙しくて１０分～１５分の時間も取れないようでは、プロジェクト自体上手くいってない証拠。
振り返りが上手くいかない原因は、実は別のところにあるのでは。
まずは１０分、時間をとってみようよ。
■ Q2. スプリント期間内に作業が終わらない！ ～其の壱～
Q.
現場にScrumを導入しようとしている。
今問題となっているのは、１スプリント毎に見積もるけど、それがスプリント内で終わらないことが続いている。
それで、終わらないのが普通だよね、という感覚にチームがなってしまっている。どうすればいいか？
A.
「スプリント内に終わらすもんですよ！」と誰かが一度いってやる。
あと、計画を立てる能力が必要。その能力が養われてないなら、無理にやってもダメ。
まずは量を減らす。終わらすことが大事。
■ Q3. 設計書を作成するタスクの扱い
Q.
お客さんから「アジャイルで好きにやっていいよ」と言われている。
そこで、設計書いつ作るとか、どう決めればよいかわからない状況。
今は、イテレーションに「設計書を作る」というタスクを入れている。
他のプロジェクトってどうやってるのか知りたい。
A.
Railsでやったらどうなるんだろうね、といった荒い設計は事前に実施している。
それでいけそうなら、スプリントを始めるようにしている。
■ Q4. 西村さんのお給料
Q.
西村さんの給料っていくらですか？
A.
GREEさんの半分くらいちゃう？ｗ
■ Q5. 書籍の執筆について
Q.
書籍の執筆はどのくらいしんどかったか？
A.
これまでデスマーチを3回くらい経験したが、今回の執筆が一番しんどかった。
見積もりを間違えたのが原因。
Q.
執筆で得られたものあるか？
A.
Scrumのことがよくわかった。
章立てて書籍を書くことで、知識がかなり整理された。
普段考えないことまで考えた。
「相対見積もりなんて、なんでそもそもやるんだろ？」とか。
わかった気になってたのが整理された。
なので、本は書いた方がいい。
アジャイルサムライの著者のジョナサンが来日したときも「本は書いた方がいい」と言っていた。
自分の勉強のためにも書いた方がいい。
ちなみにジョナサンは、出版社さえ決まっていないのにアジャイルサムライを書き始めた。
書いてから出版社に持っていこう、ということで二年間書いていたらしい。
■ Q6. 書籍の執筆陣で意見が分かれた点について
Q.
１年前くらいに、吉羽さんが講師のScrum Boot Camp Premiumに参加した。
そのときに吉羽さんがおっしゃっていたことと、書籍に書いてあることが違っている箇所があった。
Scrumを理解している人達の間でも、主張が違うことがある。
今回書籍を書いてて、ケンカとかなったことはあったか？
例えば、プロダクトオーナーとスクラムマスターは分けろ、と明確に主張している人もいる。
でも、書籍だとそこまで強く書いていなかった。
A.
一番揉めたのが「完了の定義」。
@ryuzeeはスパッと行くタイプ。POが役目を全うできないならクビだ、という主張。
逆に、日本社会はそんなのは無理、という意見もあった。
その場合は、開発チーム側でどこまでできるかやってみて、纏めたものをPOと調整して完了の定義を決める。
■ Q7. デイリースクラムの形骸化
Q.
デイリースクラムでチームメンバーから「何も問題はありません」という報告が散見される。
それで「じゃ、コレはどうやるの？」とその人に聞くと、問い詰める感じになってしまった。
上手く気付きを導く工夫ってあるか？
A.
観察はする。チームで気づいてもらわないと意味がない。
振り返りにもってくなり、「こんなことあったんじゃないの？」と軽く聞くようにすると良いのでは。
あとは、状況を見えるようにしておいてあげる。自分で気づくようにしてあげる。
例えば、各タスクにかかった時間をメンバに書かせてみる。
困ってることを言葉にするのは難しいので、気づけるようにしてあげる。
言ってあげるのも大事だが、毎日「どう？」と聞くのはダメ。
例えば、聞く曜日を決めておくとか。
■ Q8. スプリント期間内に作業が終わらない！ ～其の弐～
Q.
スプリント内に終わることが大事、と先程あった。
このことをメンバーに意識してもらう、気づいてもらうにはどうすればいいか？
A.
まず最初、きちんと説明してあげないといけない。
「スプリント内に終わることが目指さないといけないこと」ということ。
目的と理由をちゃんと伝える。それでメンバに「なるほどねー」と納得してもらう。
言葉だけだとダメなので、そのあともケアしてあげる必要がある。
■ Q9. プロダクトオーナーが捌き切れない問題
Q.
「部長 - PM - 開発メンバ」という体制が長いこと続いていた。
その後、プロデューサという役ができた。
Scrumチームが５つくらいあって、一人のプロデューサがPOとして全部を見る。
でも、プロデューサがPOとして捌ききれなくなった。
チーム１つにPO１人が良いのは分かっているが、会社の都合上できない。
どうすればいいか？
A.
POが問題をかかえている、ということが分かった。
なら、スクラムマスターは助けるのが役目。スクラムマスターがPOを助ける。
スクラムマスターって聞くと仰々しいが、大した奴じゃなくていい。下っ端でいい。
例えば、ジャンケンで負けた人がスクラムマスターをやるとか。
それで「だいじょうぶですか」と声かけるようにする。
今の状況を聞く限りだと、POを支援する人がどうしても必要になる。
ただ、POを手伝いにいくメンバーは、スクラムチームと分けたほうが良い。
■ Q10. 人事／人材について
Q.
そもそも「部長-課長-係長」って役職、いらないんじゃね？
他のプロジェクトってどうされてるのかなぁ。
A.
Scrumチームが人事まで踏み込むのは大変。
海外でもそこまで踏み込めているのは少ない。
プロジェクトを回せる状態を作って、そこで初めて「ウチの会社ってどういう人材が必要だろう？」とかステップを考えていく。
■ Q11. 西村さんを会社にお呼びしたい！
Q.
IPAが先日出した「アジャイル型開発におけるプラクティス活用 リファレンスガイド」を読むと、アジャイルコーチを呼ぼう、と書いてある。
http://www.ipa.go.jp/sec/reports/20130319.html
西村さんは呼べば現場に講演に来てくれますか？
A.
ビール一杯で行きます（笑
これ、けっこーあちこちで言っているんですが、行きますｗ
■ Q12. モチベーションが上がらないメンバへの対処
Q.
アジャイルなプロジェクトに参加したことがない。
書籍を読む限りだと、上手くチームで進んでいるように見える。
もし、モチベーションが上がらない人がチームいたら、どういうアプローチしたらいいか？
A.
実は最初、書籍で題材としているチームに「慎重派君」を入れようとしていた。
いわゆるアジャイルに慎重派なメンバーとして。（実際は入れなかったが
チームメンバーには、小さい成功体験を積ますのが良い。
誰でも、知らないことには不安になるもの。
全員に話をきくこと。何か仕事で困ってることない？と聞いてみる。
それで、みんなから聞いてみた結果を踏まえて、みんなに関係がありそうなものから始めてみる。
そんな感じでちょっとずつやっていく。
誰が成果を出すかと言えば、現場。
自分が「よし、やるぞ！」と思えるよう練習したりとか。
不安なところはコミュニティで相談したりとか。
みんなが「おもしろい！」と感じ始めたら、その後のスピードは早い。
なので、ちょっとずつでいいからやってみること。
■ Q13. １スプリントの期間について
Q.
Scrumをやり始めた。
スプリント期間を決めようと思って、ノリで決めてしまった。。。
実際、どうやって決めればよいか？
A1.
まず２週間でやってみる。なぜ２週間かと言うと、１週間だと息切れするから。
１週間だと金曜が忙しくなる。心理的負担が大きい。
まず２週間でやってみて、そこから状況に応じて変える。短くしたり長くしたり。
A2.
まず１週間から始める。
というのも、期間が短いプロジェクトだと、スプリントの期間が長いほどフィードバックの回数が少なくなるから。
あと、スプリントの切れ目も金曜ではなく、火曜とかにする。
そこはケースバイケース。
A3.
スプリントの切れ目を１日にする。
スプリント最後のスプリントレトロスペクティブと、次のスプリントのスプリント計画ミーティングを同じ日にやる。
それぞれスプリント期間の2.5%の時間をかければよいという決まりだけなので、別の日にやる必要はない。
前のスプリントの振り返りと次のイテレーションの決め事を１日でやると、あと４日が丸々使える。
A4.
まず１週間でやってみる。
それでチームに「しんどいか、しんどくないか」を聞いてみる。
大抵、１週間でやってみると終わらない。
しんどいのは嫌い。慣れる、とか無理しない、とかが好き。
■Q14. 新人のチームへの入り方
Q.
新卒でプログラミングが未経験。
どういうふうにチームに入っていけばよいか？
A1.
まず技術力をあげるのが先。
やり方はチームの雰囲気があるので、そこに合わせていく。
新人に限らず、そこのチームの価値観とかクセとか習慣とかをまず知るのがよい。
やること／やらないことの基準とかを知ること。
あとはプロジェクト計画書とかをまず読む。
A2.
自分が「わからない」ということをどんどんアピールする。
そうするとメンバと話す機会が増える。みんなとしゃべること大事。
新人の特権は知らないこと。
知って馴染んでしまうと、逆にできなくなることがある。
「わからない」というよりは、「疑問に思ったこと」を片っ端から突く。
A3.
スクラムマスターは生意気な新人にやらせるのがいい。
生意気なことを言える人。
間違っていることはきちんと間違っている、と臆せず言える人。
■Q15. 新人が見積りをやるには
Q.
新人だが、見積りってどうやればよいか？
A.
見積もりは、新人には無理。
作業がイメージできないうちは、予想じゃなくて妄想。
まず技術力を付ける事。
まず自分の１日の作業の見積りからやってみるといいんじゃないか。
■Q16. 残業について
Q.
Scrumだと、チームの残業が無いと期待している。
でも、書籍だとチームが夜遅くまで残業しているシーンが出てくる。
残業は是なのか？
A.
残業は普通にある。
ただ、定時で帰れるようにしていかないとうまく行かない。なので残業無しは目指すところ。
無理のないペースじゃないと、継続できない。
書籍に出てくるチームも、最初からうまくできるわけがない。なので残業は発生する。
でも彼らは自分達の判断ミスによって時間内に出来なかったところに対し、残業をしている。
本当はリスクを前倒しで検討しておけば平和で過ごせたはず。でも、それができなかった。
残業は現実として発生する。
■ Q17. バッグログの見積りし直すタイミング
Q.
バックログの見積もりをし直すタイミングをどうすれば良いか？
自分のチームのタイミングは、書籍と違った。
A.
違和感を感じたらいつでも見直してください。
見積もりは予想。最新な方が嬉しい。いつでもアップデートしたほうがいい。
いつでも、が見つけられない段階は、スプリントの中で見積りを直す時間をとる。
見直す必要がない、とわかったら、すぐに解散で作業に戻る。
まずはスプリントで１回。次は１週間で１回を目指す。次は任意のタイミングで見直す。
良いと思ったチームでは、デイリースクラムが終わったあと、「見積もりする？しない？」を会話してたチーム。
まずはスプリントで１回やってみるのが良いのでは。
■ Q18. XPとScrumの関係
Q.
XPとScrumの関係について教えて欲しい。
A1.
XPとScrumは補完関係にある。
Scrumは技術的なことはあんまり書いていない。そこにXPがカチッとハマる。
Scrumだけやっても失敗する。これだけやればいい、というのはない。
きちんとアーキテクチャを設計したりとかもしないといけないので、いろんなことをして必要なエッセンスは取り入れる。
A2.
XPもScrumも一緒。誤差の範囲。
ちなみに「アジャイルサムライ」はXPの本。
XPもScrumも目指すことは一緒で、アプローチが違うだけ。入り口が違うだけ。
ジョナサンがアジャイルサムライでこんなことを言っている。
「人によって好きなアイスクリームの味は違う。XPとかScrumはフレーバの違いでしかない」
やりたいことは取り入れてみる。ダメなら捨てちゃえばいい。
大事なのは考え続けること。
■ Q19. 大規模でScrumをうまくやる方法
Q.
スクラムチームメンバーからスクラムマスターに立場が変わり、更に、会社でScrumを推進する立場になった。
組織的にScrumを導入しようとしているが、ぜんぜんうまくいかなかった。
Scrumを大規模にしたときに、バランスをとることが目的になってしまい、うまくいかなかった。
Scrum of Scrumという言葉もあるが、大規模でScrumをうまくやる方法あるか？
A1.
最初に30人でScrumをやってから、あとで30人を追加で入れてもうまくいかない。
追加で入った30人には、最初の30人にしたのとと同じように、まず引き上げることが大事。教育とか。
A2.
規模が大きくてうまくいかなかった時は、チームを分けた。
サイズを小さくしてやる。どうやればチームを小さくできるかを考える必要がある。
A3.
気を付けてるのは、小さな成功体型。
大きなプロジェクトだと、大きな成果をを求められる。それがプレッシャーになる。
なので、問題をちょっと小さくしてあげる。
どんだけデカいものに当たっても、目の前にあるものが小さいものになるようにする。
いっぱい人がいる、じゃなくて、小集団で考える。
1人の人として動けているか、をちゃんと見る。
まずは、小さくすること。
■ Q20. お金や契約の話
Q.
本にお金の話が出てこない。
契約に絡んでる人たちって、どういう知恵があるか？
期間内に出来ないからといって要件をどんどん切り捨てるとかしてたら、お客さんの信頼を無くすのでは。
A.
契約面は今までと何も変わらない。
無理に案件を受けないこと。作業する人が自分でちゃんと見積もること。ジャッジはちゃんとすること。
案件を受ける／受けないは会社の判断。
リスクがある案件を取るなら、会社のサポートも必要。
お金を気にする層って今も昔も変わってない。お金を気にするのは営業とかマネージや組織の長のみ。
チームはそこは意識しない。
開発側が単価とか時間を気にしなくていいよう、逃げ道を用意する。
「お金のことは上の立場のと交渉して」と逃がしてあげる。
契約の時も、エンジニアの単価とかまで開発チームが気にしなくていいようにすべき。
■ Q21. Scrumの導入
Q.
Scrumをやりたいと思っている。
でも今は、業務委託で常駐形式でウォーターフォール。
なので、出来るところから取り入れていこう、とやっている。
アジャイルのキーワードを使わずに、デイリースクラムとかをチームでやってきた。
でもそこから先、開発プロセスのハードルが大きくて、できない。
具体的にScrumに近づけていくのにどうすればいいか。
A.
まず二人を目指す。
二人いるとディスカッションができて、解ける問題が増えてくる。
自分達のチームをアジャイルで回すことを最初にやった。
あと、成果を見せる場をどっかにねじ込む。
上はモノを見ると、口を出したくなる。
んで、そこで出た要望に対して「はい、喜んで！」と言う。
バックログを作って、そこに入れて管理する。
これ、テクニック！
全員で「はい、よろこんで！」と言うと、上は任せてくれるようになる。
それで、他から「上手くやってるようだけど、それってなんなん？」と聞かれたら「アジャイルでやってるんです」と言う。
チームでうまくいってるなら、宣伝しまくる。それで、「聞かせてよ」となるようにする。
自分がやってみせて、真似したいな、と思わせる。
★感想：
実際の現場での悩みや対処方法といった、生々しい話が直に聞けて大変勉強になりました。
だいたい日本のアジャイルの状況はどんな感じかは、どっかの報告読むよりスクラム道の大きめのイベントに来た方が分かるという自負はあるぞww
— Nishimura Naoto (@nawoto) June 21, 2013
イベントが終わった後の西村さんのツイート。
まさにその通りでした。
あと、職場に配属されたばかりの新人さんが3人くらい壇上に上がって質問していたのが、凄いなーと思いました。
私、新人の頃なんて勉強会の存在すら知らなかった。。。
あとバンダイナムコさん、自宅から自転車で行ける距離なんで、この日は自転車で行きました。
電車賃もかからないし、助かるわー。
品川シーサイドの楽天さんとか日立ソリューションズさんとかバンダイナムコさんでやってもらえるとお財布にも優しいです。
スクラム道のスタッフさん、登壇してくださった参加者さん、会場提供のバンダイナムコさん、ありがとうございましたー
- 関連記事
-
- 「JJUG Night Seminar ～ Java エンジニアのためのJava(再)入門 ～」に参加しました
- 「Scrum Boot Camp The Talk 春の増刊号」に参加しました
- 「Scrum Boot Camp in NII」に参加しました
