スクラム道05 行ってきた

今日は「6月24日 スクラム道バースト(東京都)」というイベントに参加してきました。

スクラム (ソフトウェア開発) - Wikipedia

スクラム（英: Scrum）は、ソフトウェア開発における軽量なアジャイルソフトウェア開発手法の1つである。その名称はスポーツのラグビーでのスクラムに因んでいる。

この手法は私が知ったのは2005年ぐらいだったと思う。詳しく勉強したわけじゃなかったけど、当時なんとなく読んだ感じでは他のソフトウェア開発手法に比べて、ゲーム業界なんかでも使えそうな手法だなーという印象だった。
もうすっかりそんなことは忘れてたところに、Iwade Takashi (rockout77) さんから、こんなイベントあるんだけど観に行ってみない？って声が掛かったので折角だから見てきました。

といいつつ、スクラムっていう開発手法が気になったのはウソじゃないんだけど、もうひとつの目的はこっち・・・

なんと、会場がバンダイナムコゲームスでした！
すげー、本当にこの形の建物なんだ・・・。ロビーにはクラシックなアーケードゲーム機が置かれてたり、さすがゲーム会社。会場への入口もなんか水が流れてるところをわたってく感じで不思議な感じ。会場もなんか綺麗でした。


イベントは実際にスクラムを使ってる人たちが出てきてお互いどうやってるの？と質問をしあうのを見る感じ。Twitterのハッシュタグ#scrumdo も活用されてて、主催者側もみながら質問に答えたりと講演会というよりはもっと砕けた感じで良かった。
ただ、私のほうが勘違いしてて・・・もう少しスクラムの普及をはかるために基本的な話から説明があるのかな？と思ってたら、基本的なことは知ってる上で運用事例をざっくばらんに話す感じ会で、これならもう少し下調べをしてから聞きに来るべきだったなぁと思った。

でも、色々と興味深い話しが聞けた。その場で聞いた限りの理解なので勘違いとかもあるかもしれないけど、寝る前に覚えてる限り書きなぐっておく
・スプリント
短期的な目標計画。期間としては1ヶ月程度。運用の仕方によっては2週間とか1週間でやったりもするらしい。この1ヶ月での目標を決めるミーティングが「スプリント計画ミーティング」と呼ばれる
・スクラムでの役割
スクラムをやる上での人の役割は大きく３つある。
　「プロダクトオーナー」そのプロジェクトの総責任者。こういうモノが欲しいっていうプロジェクトの実装目標を持つ人
　「スクラムマスター」スクラムフレームワークが正しく実装されていることを保証する役割（引用そのまま）。なんだろう？皆をうまく誘導してスクラムの開発手法にのせようとする人みたいな感じかな？
　「チーム」開発者達

・スプリント計画ミーティング
スプリントでの実装目標を決める。ミーティング自体は2部構成で1ヶ月のスプリントの場合は約4時間ずつぐらいで行うのが好ましいらしい。
第一部ではプロダクトオーナーからの要求を理解することが主目的になる。要は何をしたいかってことかな？
第二部ではそれを達成するための仕事をタスクとして分解してチームとしてこなせるかを調整していく感じ？

・プランニングポーカー
ちょっと面白いなと思ったものは、このプランニングポーカー。コストが描かれたカードが沢山あって、ある要求事項の実装に対してどれぐらい重い作業なのかを、各自が自分で考えて見積もった結果をせーのでオープンする。お互いの見積が大幅に食い違った場合は何か認識の違いがあるということで話し合い。なぜそのコストなのか？とか・・・
そうやって、要求事項毎にポイントをつけていってスプリント計画を作る。実際に1ヶ月なりのスプリントをやってみてどれぐらい消化できたかをフィードバックすることで見積もりの精度を上げていく手法らしい。

・スクラムを導入するに当たっての障害
「計画を立てたりすることに慣れてないと、面倒だという人がいて協力してくれない。」これ、なんか自分の事を言われてるみたいだ。確かに計画を立てるのって面倒なんだよね、それに対しての答えが
　計画を立ててもらえると他の人との連携が取りやすい。コレが上手くはまっていくと効果が実感できるようになってだんだんやってもらえるようになるそうな
　タスクの分解が面倒といって大まかな計画だけドカンと出す人には、仕事で何をやっているのかが不透明で周りから不信感があるよとプレッシャーを与える。・・・てか、コレも自分のことを言われてるような、なんだ？俺はスクラムに興味があるといいつつ導入すると面倒だーって思ってしまう感じなのか？少し考えを改めるべきか・・・

・スクラムをどのようにして導入したか
　社長に「社長がスクラムマスターだとカッコイイですよ！」っておだててのせてしまって、そのまま社長と講習会に行って導入した。
　うーむ、策士だなｗ
　
　チーム内で自発的に賛同者を集めてスクラムを実践し、残業をせずに帰る伝説のチームとなって社内にインパクトを与えた。
　結果が目の前で示されると、どうやってんだ？って興味がわくってことだね。スクラムは適応できる範囲を大きくも小さくもできそうだし、特定のパートに関して行って実績を出すことで全体への説得にするってのもありなのかも？

　プロジェクトマネージャ的な役割の人がスクラムマスターとなって上司、顧客、チームをスクラム用語を使わずごく一般的な用語で誘導してスクラムを気づかれないうちに実践させる。外から見たらウォーターフォールにみえるけど実はスクラムという不思議な状態。これは立ち回りがうまい人じゃないとできないな。でも身構えられずに気づいたら実践させられてるってのは、個々においてのスクラム的な要求は説明されれば納得出来るような事ってことなのかな

・タスクの粒度
スプリント計画の要求事項をタスクに分解するさい、タスクってどれぐらい細かく分解していますか？という話。
最低単位が30分という意見が多かった。逆に最長単位が1日。1日以上かかるような仕事は分解したほうがいいという感じらしい。
ただ、タスクの単位といってもスプリント計画が1週間なのか1ヶ月かなので随分と粒度は変わってくるんじゃないか？という意見も。
「メールを受け取る」とかいう一瞬で済むタスクも30分として計上しているという意見も。余った時間はマージンとしてつかってるらしい。
タスクは、コレができたら完了というのが分かりやすく。昨日仕事は何したの？って聞かれて「コレをやりました」って言えるぐらいの粒度がいいんじゃないか？という感覚的な意見も出てた。この考え方が私にはあってそう。30分とかで区切られるより1日を4分割ぐらいして午前中、午後、夕方、夜の４つでそれぞれを1単位としてタスクを作っていく感じならそこまで面倒にならない気がする。
ミーティングが多い日は1タスクがミーティングになったりするのか。少し重めの作業は3タスク分使うとか・・・変かな？

そんなこんな話を聞いているうちに時間がきてしまいました。なかなか興味深い話が聞けました。とりあえず、一度自分だけで出来ることとして、この手法に近い感じでタスクを整理してみるかな。なんか今何をやらんといかんのかふわっとしているものが多すぎる。