LEGOによるスクラム体験
「一日業務体験インターン」で実施した「LEGOによるスクラム体験セミナー」のレポートを公開します。
2018年卒の学生に向けて、一日インターンを実施しました。
業務内容の説明や業界説明、先輩社員との交流など、盛りだくさんの内容でしたが、 今回は業務体験の一環として実施した、「レゴによるスクラム体験」コーナーの内容をご紹介します。
概要
今回のインターンは、一日という短期間ですし、 プログラム未経験の学生も対象としていたので、 実際にプログラム開発の体験を行ってもらうのは、時間的に無理でした。
その為、「LEGO4SCRUM」というトレーニング手法を実施することにしました。
LEGO4SCRUMとは
LEGO4SCRUMは、「業務経験者」に向けた、スクラムのトレーニング手法です。
実施方法はWebページで公開されており、誰でも自由に見ることができます。
スクラムとは「開発チームが一体となって働くこと」を目的とした、アジャイルソフトウェア開発手法の1つです。開発メンバーが自発的にコラボレーションを行いながら、流動的な要求仕様の変化に対応し易い点が利点です。
LEGO4SCRUMとの違い
ただし、今回はあくまで「業務理解」のために行いたかったため、一部をアレンジして実施しました。
まず、一番良くあるケースである「システム開発の受託案件」をシミュレーションすること。スクラムの概念理解は「ストーリーポイントやベロシティの理解のみとする」こと、実際のスクラムは、スクラムリーダーがいるなど、方針が異なる点があります。
進め方
基本的には、LEGO4SCRUMで配布しているPDFをベースに、やり方を軽量化しました。実施時間はおおよそ１時間半〜２時間程度に収まります。
準備
- レゴは、下記のものを一箱ずつ購入しました。おおよそ8名くらいは賄えそうな感触でした。
- A3コピー用紙を机の上に敷いておきます。
- 大きめの付箋
- あらかじめ「１階建ての家」「２階建ての家」「お店」「バス停」などを書いた付箋をホワイトボードに貼っておきます。
イントロダクション
- 共同作業を促進するために、参加者に軽く自己紹介してもらいます。
- LEGOを通じて、業務が体験できることを説明します。
- プログラマーの仕事は、ただ席に座ってプログラムをするだけではなく、ヒアリングやチームでの共同作業など、コミュニケーションが多いことを説明します。
アイデア出し
- A3用紙を広げ、川や木、山などの地形図を自由に書きます。
- 「理想の街」にはどんな建物があるか、自由に発想してもらいます。ダメ出しはしません。
- アイデアは付箋上に自分で書いてもらいます。書いてもらった付箋はホワイトボードに貼りつけます。
- だいたい参加者２名の場合で１０件くらいアイデアができればOKです。
ルールの説明
- 計画し、協力することが大事というメッセージを伝えます。
- 作成作業に「７分」の時間制限があることを説明します。
見積もり
- ストーリーポイントの説明を行ないます。
- スイムレーンウォールをホワイトボードに書きます。
- ストーリーポイントに従って振り分けを行ないます。
ストーリーポイントとは、作業量を表す架空の単位です。
例えば、一階建ての家を「ストーリーポイント１」とすると、二階建ての家は二倍の労力がかかると見込まれるため、「ストーリーポイント２」と置きます。
所要時間のような、絶対的な単位で作業を見積もることは熟練者でも非常に難しいですが、 相対的に見積もるのは比較的簡単なので、このような手法を用います。
スイムレーンウォールとは、下記画像のようなものです。
付箋に書いたタスクを一つづつ取り出し、それぞれどれくらいのストーリーポイントを割り当てるべきか、 参加者に聞き、該当するストーリーポイントのレーンに貼っていきます。
スイムレーンに分配し終わったら、それぞれのカードにストーリーポイントを書いていきます。
ストーリーポイントの見積もりには「プランニングポーカー」というカードを使った見積もり手法が有名ですが、 スイムレーンウォールはより高速な見積もり手法です。 今回は時間の制約があるため、スイムレーンウォールを採用しました。
スタート
- 付箋を「バックログ」に移動し、スプリントの箱をホワイトボードに書きます。
- ストップウォッチをホワイトボードに映します。
【１】スプリント計画（３分）
- バックログから「７分でやれる量」を取り出し、スプリントに移動してもらう
【２】スプリント（７分）
- 実作業
- ４分経過時に声をかける
【３】スプリントレビュー（５分）
- 改善案を伝え、付箋に書いてもらう
- 改善案について追加見積もりを行なう
- チームのベロシティを伝え、次の計画に活かしてほしいと伝える
- 未完成のものがある場合は、それを含めない値をActualの参考値として出しておく
これを、３回繰り返します（１回につき１５分かかります）
まとめ
- 参加者に、次回同じことをするとすれば、どうしたら更に良くなるか、方法を考えてもらいます。
- 実務に則ったものであることを説明します。実施者が顧客と実際にあったやり取りなどを例に出して、どうしてきたかを伝えます。
実施風景
小さなパーツを見つけるのが大変なようで、あとで小さいパーツは袋に分ける工夫を行いました。
チームによって、装飾のセンスが出てくるので見ていて面白いです。
オリジナル版では４人以上を推奨としていますが、初対面のメンバーだと案外２〜３名程度の方が、積極的に参加してくれるので感触としては良かったです。
「理想の街」の条件として、交通機関が挙げられることが多かったです。要望を出す側も交通機関があると生活動線からの意見を言ったりと、やりやすい面が有りました。
スプリントの枠は最初から３つ書かない方が良いようです。ベロシティが出る前に、全体の計画に意識が行ってしまいます。
実施者が市長になりきって、「市長の家」や「市長の像」をリクエストするとやりやすいですね。「市長の像」は特に無茶な要求を思いつきやすいという事情もあったりします（作る側は大変そうでしたが）。
参加者から寄せられた感想
参加者からは、以下のような感想が寄せられました。
- プロジェクトをチームで進めていく際のプロセスがわかりやすく体験出来た。
- 大きなものの見積もりが難しいと感じた。
- システムエンジニアの仕事内容が、イメージとズレがあったが、早めにズレをなくせてよかった。
- 実際にお客様と話し合って欲しいものを探していく仕事内容が面白そうでとても興味が湧いた。
- 最初はこれで分かるのか疑問に思っていたが、やり終わった後にだいたいのイメージが湧いて、少し理解できた。
- １回目はかなり時間が余ってしまい、見通しが甘かったと感じた。２回目では経験を活かし、ちょうどいい割当が出来た。３回目では作業を一つ忘れてしまい、目標を達成することができなかった。
- 次に同じことを行なうとしたら、作業一つ一つに責任者を付け、チーム・要求者でどのようなものを作るのかという意識を統一して行いたい。
- チームでの開発の大変なところや忘れがちなポイントも、レビューの結果を交えて説明されていたことが、とても参考になった。
- お客様からの要求をしっかりと確認しておくことで、余計な工程を減らすことが出来るということがわかり、確認の繰り返しも重要な仕事だと感じた。
実施者としての感想
システム開発のプロセス体験としても十分に使える、かなりよく練られた手法であると感じました。また、LEGOを使ったことで、かなり敷居の高さを抑えることが出来ました。
実際に起きるコミュニケーションもなかなかリアルで、例えば１回目のイテレーションで「おもったよりこなせてしまった」チームが、２回目で欲張った計画を立ててしまい、炎上して計画の見直しを余儀なくされるシーンがありました。 慌てる参加者とは裏腹に、実施者としては「この失敗をしてほしかった！」と思っていました。
一方、チームによって作る建造物のスケール感がバラバラで、最初に小さく作りすぎてしまい、最初に切ったチケットの大半が２イテレーションで消化されてしまうことがありました。最初にスケール感を指定して置くことが大事かもしれません。