メニューを閉じる

テクノデジタルグループ

メニューを開く

2016.07.21

その他

LEGO(R)ではじめるスクラム入門(レゴスクラム)に参加してきました。

N.Sです。

弊社一部チームでは昨年よりスクラムを実践中です。

本を読んだり、認定スクラムマスターにアドバイスをもらったりはしてきましたが、実際にスクラムを教わったことがないな…ということで、とても今更ながら、セミナーに参加してきました。

講師は角さん、角谷さん。

スクラム関連の書籍の翻訳に携わっていらっしゃる方々に、途中途中で質問の機会もあり、貴重な機会だったと思います。

 

アジャイル開発に詳しい順?

参加者は12人ほど。まず最初にチーム分けから始まりました。

与えられた指示は「アジャイル開発に詳しい順に、自分たちで決めて並んでください。」

初対面同士で、詳しいってなんですかね…と相談しつつ、ひとまず経験者/未経験者で分かれることにしました。

経験者(仮)側に入ったので、こちら側では更に経験年数で並び、ほぼ同じだったら背の順(ヒール含む全長)で並びました。

そこから3チームずつに分けて、結果は3チーム×4名程度となりました。

チームメンバーはSE、デザイナ、教材関連など受講される方の幅は広いよう。

チームが決まったところで、当日のアジェンダは

■1h:スクラムについて(座学)

■3.5h:レゴで実践

■残:質疑応答

質問は残り時間で、とあったものの、随時付箋でホワイトボードに貼っていき、休憩時間明けに角さんが答えてくださる形でした。

常にお菓子がありました。お菓子があるだけでなんか気分が違いますね。弊社のMTGでも取り込んでいきたいです。お菓子代欲しい。

 

スクラムについて

テーブルに配られている文房具が揃ってるか確認、そして付箋の剥がし方。

●達人は縦に引っ張る。

●横からめくるのは素人。今っぽくない。(やってしまう…)

●壁とかに貼ったときぴたっとなってないとニワカくさい。

耳が痛かった。

 

座学フェイズはざっと。

●comlicated(複雑)とcomplex(複雑)の境界とは?

→部品にバラせるかどうか。

→バラせないもののほうにスクラムは向いている。

●「最高においしい焼きそばの作り方」を考えてください。

→FeedBackを受けるタイミングがあるかどうかが重要。開発も同じ。

→おいしいものが出来たか?もっとうまく作る方法はないか?改良点を見つけること。

●マネジメントの役割は、チャレンジングな課題と大きな自由度をチームに与えること。

●開発チーム:要求を成果物に変える専門家チーム。

●スクラムマスター:命令してはいけない。「どのように作るか」の責任者。質問には答えられるような人。(もしくは適切な人を知ってる人)工場の班長がイメージ。指示を出さずに自己組織化を促す。犠牲になる人。

●プロダクトオーナー:「何を作るか」の責任者。ステークホルダーとチームの門番。

●SCMとPOの境界は曖昧。もともと一つだった役職を分けた。

●不要なSCMのほうが優秀(開発チームが優秀であればSCMは要らない)

●新しいPJと、新しいスクラムは一度に始めないほうがよい。(chaosの領域になる)

●Q.SCMって何するの?

→Jenkinsおじさん、進捗管理おじさん、リファクタリングおじさん etc

→開発がうまくいくような工夫。やっておいたほうがよいことをする。外との調整。開発チームがやりたがってない部分を引き受ける。重要だけど緊急じゃないこと。

●”People first” 働いている人が楽しいか。

●「サイクルで変化していなければアジャイルではない。」

だいぶ目から鱗でした。

特にスクラムマスターが何するのか、本ではサーヴァントリーダーとか聞いたり、チームを引っ張る感じの描写が多いものの、具体的に何してるのかを知る機会があまりなかったので、具体的に聞けてよかったです。

やっとサーヴァントリーダーという単語にも納得できました。

 

ここから実際にレゴを使った実践。

 

レゴスクラム開始

テーマは「街を作る」。

3チームそれぞれが、あるチームのPOとなり、別のチームの開発チームとなります。

まず自チームである一家のペルソナを作り、ユーザストーリーとして街に何が欲しいか?を書きます。

ペルソナ:1歳のペット(犬)。散歩が好き。食事にこだわってる。

ユーザストーリー:「散歩が好きな犬として、大きな公園が欲しい。走りまわる場所が欲しいからだ。」「食事にこだわる犬として、ペットショップが欲しい。豊富なドッグフードから選びたいからだ。」

この他、メンバーがお父さんだったりおばあちゃんだったり、それぞれ異なったペルソナを作り、ユーザストーリーを作ります。

その後おおよそのイメージ(理想像)を模造紙に描いた後、自分たちが開発チーム側となるチームのテーブルに移動。

ここから開発チームとしても、他チームのPOとして動きまわることになります。

見積もり、施設になにがあればよいかPOと決め、総見積もりを4スプリントでまわす想定で1スプリント分の目標値を決め(全部で28、1スプリント7くらいは消化できるつもり)、優先順位を決定、「ベンチがなければ公園はもうちょっと早く作れる」と交渉、タスク分割、サインアップ、レゴ開始、パーツ集め、力を込めすぎると崩壊する建物、同色のレゴを集めてたけど時間がなくなってきて色がバラバラになる壁、他はできてないけど女湯と男湯の入り口だけできてる銭湯…

1スプリント(7分)終わる頃には街どころか建物一つ完成せず、まったく進んでいない現実に打ちのめされました。超リアルでした。

POのレビューでは「壁の色は統一してほしい」「壁に空いてる穴(レゴの穴の個数の問題で埋められなかった)をなんとかしてほしい」などなど要望が次々あがってきました。

1スプリント目に達成できた建物はゼロ。実績(ベロシティ)もゼロ。

その後は、どうすればよかったかを振り返り。

複数の建物をみんなでやるのがよくなかった、まずはひとつ建物を作るようにする、同じ色のパーツを集める担当を作る…などなど。

せめて1つは建物を完成させようと、次の予想値は喫茶店を立てる見積もり「3」。

また、全体の難易度が思っていたよりも高かったことから、全体を見積もり直し。(屋根を作るのは案外大変)

とやったところまでで、「POは優先順位をガラリと変えてください」という悲しい指示で、建設中の銭湯は放棄され、別のものをイチから作りなおすことになりました。

そこからはまた同じくスプリントを開始。

4スプリント繰り返し、なんとかPOにもOKをもらえる建物がいくつか出来上がりましたが、すべての建物の1/3程度。

見積もりって難しい。作るって難しい。

 

まとめ

スクラムと称してやっていることの大枠としてはそんなに間違ってなかったようだ、と少し安心しました。

チーム内で、木を作るにも「こうやると思ってた」「思ってたのとやり方が違ってた」とすれ違う部分があったのは生々しかったです。

それでも振り返りを通して改善されていきました。

また、適宜質問できるチャンスがあってありがたかったです。

スクラムについて聞く相手ってなかなかいないので貴重でした。

実際のスクラムとまったく一緒ではないものの、流れを体感するにはとても良いセミナーだと思いました。

そして、レゴは思っているよりも組みづらい。製品は見積もりよりも作りづらい。生々しかった。

 

 

 

「おしゃれな喫茶店」と言われておしゃれそうなマスターを付けた喫茶店と、

入り口はちゃんと分かれてる銭湯の名残。


【記事への感想募集中!】

記事への感想・ご意見がありましたら、ぜひフォームからご投稿ください!
  • こんな記事が読んでみたい、こんなことが知りたい、調べてほしい!という意見も募集中!
  • いただいた感想は今後の記事に活かしたいと思います!

感想フォームはこちら


【テクノデジタルではエンジニア/デザイナーを積極採用中です!】

下記項目に1つでも当てはまる方は是非、詳細ページへ!
  • 自分でアプリを作ってみたい
  • ITで世の中にワクワクを生み出したい
  • 使いやすさ、デザインにこだわったWebサイトを開発したい

採用情報の詳細はこちら


Qangaroo(カンガルー)

  • 徹底した見やすさと優れた操作性で、テストの「見える化」を実現。
  • テストの進捗が見える。開発がスマートに進む。
  • クラウド型テスト管理ツール『Qangaroo(カンガルー)』

【テクノデジタルのインフラサービス】

当社では、多数のサービスの開発実績を活かし、
アプリケーションのパフォーマンスを最大限に引き出すインフラ設計・構築を行います。
AWSなどへのクラウド移行、既存インフラの監視・運用保守も承りますので、ぜひご相談ください。
詳細は下記ページをご覧ください。

https://www.tcdigital.jp/infrastructure/

最近の記事