スクラムワークショップ -Vol.01 レゴ®編

• 
• 
• 
• 

この記事は約20分で読めます。

はじめに

みなさんこんにちは。成瀬（@nrslib）です。

GMOインターネットにはデヴェロッパータスクフォース（以下DTF）というチームがあります。

DTFは端的に表現すると技術研究チームです。
開発者が互いに切磋琢磨する仕組み・環境の整備・開発技術や開発手法のキャッチアップをして、そこで得た知見を他の開発者や製品・サービスにフィードバックするのが目的です。

DTFが手がける活動は多岐にわたります。
世の中のトレンドや最新の技術のキャッチアップは当然のこととして、既知の技術でありながらノウハウのないものや、技術以外に開発手法なども対象範囲です。

今回、DTFではスクラムのワークショップをいくつか実施しました。
本連載では、ワークショップで得られた知見や様子をお話いたします。

変化を余儀なくされた開発現場

ある日突然リモートに──。

もう一年以上も前のことですが、突如出社が禁止され、私たちはフルリモートで業務を行うことになりました。
当初は戸惑いがありましたが、一年以上もリモートワークをしていると、もはや日常風景です。
カレンダーがめくられるにつれて、ノウハウもどんどん溜まり、今となっては不都合を感じることはほとんどありません。
しかしながら、そのリモートワークが最適化されたものかというと疑問が残ります。

この度リモートワークにスムーズに移行できた理由のひとつとして挙げられるのは、毎年の災害対策用リモートワーク訓練です。
環境が整備され、パートナーに経験が蓄積されていたからこそ、私たちはリモートワークに移行できたのですが、その訓練はあくまでも災害対策用なのです。
あくまでも短期的なリモートワークを想定したもので、長期的な運用を目指したものではありませんでした。
そのため、すべてが効率的で効果的なやり方であるとも言い切れません。
長期的なリモートワークを前提とした、もっと良いやり方があるに違いありません。

そこで、私たちはリモート環境下の開発における「私たちの」ベストプラクティスを探ることにしました。
具体的にはリモート環境下におけるアジャイル開発の探求です。

もちろん、私たちがリモートに移行する以前よりフルリモートを実践している先達は多く、リモート環境下における開発手法の知見は既に多く存在しています。
それらの多くはそのまま採用できるほど洗練された知見ですが、必ずしも私たちのスタイルに合致するとは限りません。

私たちならではのスタイルを探ってみる価値はあるでしょう。
いいものが見つかれば最高ですし、見つからなければ「見つからなかった」という成果を得られます。

さて、すでに知られているとおり、アジャイル開発のトピックは多岐に渡ります。
どのトピックから始めるかは迷うところですが、まずはアジャイルの中でも特に有名なスクラムの見直しから始めることにしました。
つまり、リモート環境下におけるスクラムです。

リモート環境下のスクラムをこすろう

リモート環境下におけるスクラムを深堀りするにあたって、ひとつ問題がありました。
それはスクラム未経験者がDTFに存在するということです。

DTFは兼務を前提としており、各種チームからメンバーが集められています。
チームが為すべきことはチームによって異なり、当然ながらその開発手法もチームによって異なります。
スクラムを経験していないメンバーがいるのも致し方ありません。

しかし、スクラムを深掘りしていくにあたって、スクラムを経験していないのは、守破離の破から始めるようなものです。
到底上手くいくとも思えません。

なにはなくとも、まずは基本から。
ということで、まずはスクラムを体験することから始めることにしました。

スクラムを体験する方法

スクラムを体験するには実際にスクラムで開発をするのがもっともよいでしょう。
しかしながら、DTFは兼務から成る混成チームです。
集まりは週１回。
がっぷり四つにスクラムで何かを開発するのは難しいです。

そこで、スクラムを完全に体験するのは先送りにして、疑似体験する方法を調査しはじめました。
つまり、ワークショップです。

調べてみるとスクラムを体験するワークショップは色々な種類があるようでした。
ピンポンゲームや紙飛行機ワークショップ、そしてレゴ®スクラム。
いずれもスクラムを疑似体験するものといった点で共通していますが、ワークショップごとにカバーする範囲は異なるようです。

そこで私たちはいくつかのワークショップをやってみることにしました。
今回はその中のひとつ、去年実施したレゴ®スクラムについてお話します。

レゴ®スクラム

みなさん、レゴ®はご存知でしょうか。

そう、こちらです。

幼い頃、夢中になって遊んだ方もいるでしょうか。
マキビシのようにブロックを踏んづけて痛い思いをした方もいらっしゃるのではないでしょうか。
今回お話するワークショップは、このレゴ®を使ったワークショップです。

レゴ®を使ったスクラムワークショップは古くからメジャーなようで、たとえば「#lego4scrum」というレゴ®スクラムを取り扱ったサイトでは2015年時点の動画が存在します。

https://www.lego4scrum.com

ちなみにこちらのサイトでは、レゴ®スクラムのファシリテーションガイドを入手できたりします。
今回は、こちらのファシリテーションガイドを参考にしながら、アレンジを加えて実施したスクラムワークショップの内容をお届けします。

ワークショップ概要

レゴ®スクラムはレゴ®ブロックを使って、スクラムの手法を実践しながら建物を作るワークショップです。

ワークショップでは参加者同士数名でチームを組んで、テーマにしたがった建物を作ります。
多くの場合は、ひとつの建物を作るのではなく、街などをテーマにして複数の建物を作るようです。

所要時間は少なくとも半日かかります。
スクラムの解説から始める場合は１日かかると考えてよいでしょう。
準備物もそれなりに多く、なによりブロックのコストがかかります。

まとめると、レゴ®スクラムは所要時間が長く、準備にコストがかかる重厚なワークショップです。
その分得られるものは軽量なワークショップに比べて段違いです。

準備するもの

まずはワークショップを実施するにあたって準備するものを確認していきます。

小道具

必要なものは次のとおりです。

• レゴ®
• サインペン
• カラーマジック
• 付箋（正方形）
• プランニングポーカー
• 模造紙

ひとつのチームにつき、こちらのセットをひとつ用意します。

どのブロックを用意するかは悩みどころです。
私たちは次の『黄色のアイデアボックス＜スペシャル＞』と『想像力の窓』を２チーム分購入しました。
大の大人が集まって、どのレゴがいいか吟味するミーティングは乙なものです。

黄色のアイデアボックス＜スペシャル＞：https://www.lego.com/ja-jp/product/lego-large-creative-brick-box-10698
想像力の窓：https://www.lego.com/ja-jp/product/windows-of-creativity-11004

ワークショップを実施した経験からいえば、５名程度のチームであれば、ボックスがひとつあれば、大抵の場合はことたりるでしょう。
それ以上の人数をひとつのチームにしたいときには、『想像力の窓』などのセットを買い足しておくと安心です。

プランニングポーカーは購入してもよいですが、自作でも問題ありません。
マルチカード（名刺など）用紙を使ってプランニングポーカーを作ることもできます。
今回は次のリンク先のプランニングポーカー作成用PDFを利用いたしました。

https://www.surviveplus.net/ja/archives/137

設備

設備はいずれも一般的な会議室であれば揃うものです。

• テーブル
• 椅子
• ホワイトボード
• プロジェクタ（任意）

テーブルは模造紙を広げられる程度の広さが必要です。
また、それ以外にもブロックをあらかじめ広げておくためのテーブルも用意できるとよいでしょう。

ホワイトボードはこのあと解説するプロダクトバックログとタスクボードを作れる程度の大きさが必要です。
一般的なホワイトボードであれば、問題ない大きさです。

ホワイトボードが用意できない場合は、模造紙を壁に貼り付けるのがおすすめです。

プロジェクタは任意ですが、用意しておくとスクラムについての導入や、今何をするタイミングなのかを示すのに便利です。
昨今のリモートワークの流れであれば、事前にオンライン会議で講義する形でもよいでしょう。

ワークショップの流れ

ワークショップは次の順序で進んでいきます。

• スクラム入門講義
• チーム分け
• 題目発表
• ペルソナの決定
• ユーザーストーリーの作成
• プロダクトオーナーの選出
• タスクボードの作成
• プランニングポーカーによる見積もり
• プロダクトバックログの作成
• スプリント（４回）
• 振り返りする

実際に私たちが実施した内容を元に、それぞれ確認していきましょう。

スクラム入門の講義をする

レゴ®スクラムは半日以上かけてスクラムを体験するワークショップです。
体験の質を向上させるためには、スクラムに関する概要的な知識が必要です。
さもなければ、ワークショップ中の作業やイベントの意図や位置づけが不明になってしまい、まったく意味のないものになってしまいます。

スクラム未経験者や知識のない参加者がいる場合には、ワークショップ開始前に彼らに向けた入門用の講義を行います。
講義内容はワークショップで実際に体験する事物を中心に説明します。
とはいえ、一般的なスクラムを網羅的に体験するワークショップですので、スクラムを構成するロールや作成物、イベントを網羅的に解説することになります。

ここでは実際に私が解説した内容を確認していきます。

スクラムの概要説明

最初にスクラムがどういったものかを解説します。
アジャイルにおけるスクラム開発の位置づけや構成要素の確認です。

ロールの説明

ロールに関しては、数も多くないのですべて解説します。

• 開発者
• プロダクトオーナー
• スクラムマスター

今回計画したワークショップでは、参加者は開発者を必ず経験します。
また１チームにつき１名がプロダクトオーナーを経験することになります。

スクラムマスターはスクラムに関する理解と意欲がある参加者が存在する場合には立てられます。
これに関しては「プロダクトオーナーを選出する」の項で説明します。

作成物の説明

スクラムにおける作成物を説明します。
ここで解説した作成物は次の３つです。

• プロダクトバックログ
• スプリントバックログ
• インクリメント

ユーザーストーリーやタスクボード、完成の定義など、それぞれの作成物を作るにあたり必要になる事物や概念の解説もしておきます。

イベントの説明

ここで解説するイベントは次のとおりです。

• バックログリファインメント
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

タイムボックスやベロシティといった重要な概念も出てくるので、手厚く解説をしましょう。
とくにタイムボックスはおろそかになりがちなので、重点的に解説します。

チームを分ける

今回のワークショップでは、チームの規模は５名で実施しました。
スクラムを取り入れたいチームが対象であればチームごと参加いただくのがいいでしょう。

参加者にスクラム経験者が少なかったので、経験年数で均等になるようにチーム分けを行いました。

ちなみに今回はDTFのメンバー以外に、新卒二年目の若手とデベロッパーリレーションズチームのリーダーにご協力いただいて、総勢１０名の参加です。
５名ずつに分かれて２チームが作られました。

各チームごとにチーム名を考案してもらって、チーム分けは完了です。

チーム名は「Team Japan」と「サラマンダー」です。
日出ずる国vs火の精霊ですね。
神話かな。

題目を発表する

ワークショップでチームが開発するテーマを発表します。
テーマはブロックで表現できればなんでもよいです。
私がワークショップを組み立てる際に候補にしていたのは次の３つです。

• 街
• 職場
• 遊園地

街づくりは誰でもイメージしやすいオーソドックスなテーマです。
職場づくりはブロックで表現するには狭すぎる印象があります。
遊園地はペルソナがお客様なのかパートナーなのかによって、考えることが様変わりするので面白いテーマです。

最終的に「最初はオーソドックスにしたい」と考え、「街」をテーマにしました。
「遊園地」も面白そうなのですが、著作権に関わりそうな建物が建てられそうなので今回は見送りです。

ペルソナを決める

参加者はそれぞれテーマに沿って自分のペルソナを決めます。
「街」がテーマであればそこに住む家族、「職場」がテーマであればいくつかの職種、「遊園地」であれば来園者やそこで働くパートナーがペルソナの候補になります。

今回のワークショップでは「街」をテーマにしたので、ペルソナの候補は次のとおりにしました。

• 祖父
• 祖母
• 父
• 母
• 息子
• 娘
• ペット

参加者はいずれかを選択し、年齢はいくつなのか、職業は何なのか、趣味はなにか、種族はなにか、といったようにペルソナを深掘りしていきます。

ユーザーストーリーを作成する

参加者それぞれが自身のペルソナを決めたら、ペルソナにしたがってユーザーストーリーを作ります。

ユーザーストーリーというと難しく構えてしまいますが、要するに自分が欲しい何かを列挙するだけです。
たとえば「街」がテーマであれば、「家の近くにコンビニが欲しい」とか「運動したいのでジムが欲しい」といった要領で、自分が住む町に欲しい施設を挙げるのです。

ユーザーストーリーは付箋に記述しますが、その記法は次のテンプレートにしたがいます。

「＜どういった立場＞として、＜どういったもの＞が欲しい。それは＜どんなことが達成したい＞からだ」

このテンプレートでは太字の部分を記入します。
たとえば「散歩が好きな犬として、大きな公園が欲しい。それは走り回る場所が欲しいからだ」といった具合にです。

簡単そうに見えますが、慣れないうちは欲しい施設だけを付箋に書いてしまって終わってしまうことがあります。
欲しいものそれ自体はもちろん重要ですが、立場や動機はそのユーザーストーリーの背景を知るのに重要です。
まずはテンプレートを守るようにしましょう。

ユーザーストーリーが書けたら模造紙を地図に見立てて配置します。
中央に自分たち家族の家を配置して、施設の位置関係や道路などをカラーマジックなどで書き込んでいきます。

こちらの作業は最初はみんな戸惑っていましたが、乗ってくると楽しくて、終わり時を逃しやすいです。
トレーナーには冷徹に時間を区切って次に進める胆力が必要です。

プロダクトオーナーを選出する

各チームごとにプロダクトオーナーとなるメンバーを選出します。
#lego4scrumでは、トレーナーがプロダクトオーナーをやることになっていますが、せっかくなので参加者にプロダクトオーナーをしてもらって、トレーナーがそれをサポートすることにしました。

プロダクトオーナーのやることは、このあと作るプロダクトバックログの管理を主体的に行うことです。
開発チームと相談しながら、プロダクトバックログの優先順位を変え、必要に応じてステークホルダーとのやり取りを行います。
もちろん開発者も兼務することになるので、ブロックで建物を作ります。

この際、スクラムマスターを立てることも可能ですが、注意すべき事柄があります。
スクラムマスターを担うにはスクラムに関する理解と意欲が必要です。
さもなければタイムボックスを意識して守れなかったり、イベントで他のことをやってしまい、うまくスクラムを回せない結果に繋がります。

スクラム未経験者や初心者ばかりの場合にはスクラムマスターを立てない方が無難でしょう。
今回の私たちのワークショップでも、スクラムマスターは立てない方向で進めました。

要求を交換する

プロジェクトの多くは、自分以外の誰かが欲しいものを作ることが多いです。
そこで、今回のワークショップでもそれを再現すべく、地図の交換をしました。
つまり、参加者の眼前には他のチームのユーザーストーリーが貼られた街が広がることになります。
参加者が開発するのは、目の前の街です。

以降、参加者は一人二役になります。
目の前の街に対しては開発チームとして振舞い、もう一方のそれまで自分たちの要求を張り付けてきた街に対してはステークホルダーとして振舞うことになります。

タスクボードを作成する

チームごとにタスクボードを作成します。
タスクボードはユーザーストーリーを貼るスペースとTODO, DOING, DONEのフェーズを用意したシンプルなものです。

スプリント自体は短いので、これくらいの粗い粒度で十分です。
むしろ、これ以上粒度を細かくしても、扱いきれないでしょう。

プランニングポーカーで見積もる

ユーザーストーリーをプランニングポーカーを使って見積もりします。

プランニングポーカーを知らない方向けに説明すると、数字の書かれたカードを一斉に出し合う見積もり方法です。
メンバーは任意のユーザーストーリーに対してプランニングポーカーを使って、自分が思うポイントをあてはめます。

プランニングポーカーで使われる数値は工数を直接表すものではなく、重みを表すポイントです。
基準となる数値を決めて、そこから相対評価でポイントを見積もります。
人間は相対評価が得意なので、スムーズに見積もりができます。

カードの数値はフィボナッチ数列が使われることが多いようです。
フィボナッチ数列は1, 2, 3, 5, 8, 13, 21, ……といったように、直近２つの数値を足し合わせた数列です。
「平均値より小さい」や「平均値より大きい」、「平均値よりとても大きい」、「想像もつかないほど大きい」といった表現がしやすいのがこの数列です。

場に出たカードのポイントが一致すれば、合意が取れたことになります。
数値が大きい、あるいは小さいときは、なぜその見積もりになったのかをインタビューして、そこに潜む問題点やハックを深掘りします。
このような手順を取ることで、見積もりが公正で透明性と納得感のある数値に近づきます。

なお、相対評価を行うためには基準を最初に決める必要があります。
通常は開発チームで合意が取れるもっとも平均的なユーザーストーリーを選んで、それを３とします。

しかしながら、レゴ®に関しては一体どれくらいかければどれくらいのものができるのか、という知見がほとんどの場合ありません。
そこで、事前に私のほうで試作をしました。
試作品をご紹介しましょう。

スプリントは７分の予定なので、７分で作った建物です。
色をそろえると７分ではなかなか厳しそうという印象がありました。
あとオフィスでレゴ®をするのはなかなかの胆力が必要でした。

建物以外に、もうひとつ作品を作りました。

これは見ればわかりますね。
弊社のホスティングサービス「ConoHa」の応援団長である美雲このは（@MikumoConoHa）です。

これらの作品を３ポイントとして参加者は見積もりをしていきます。

見積もったポイントはユーザーストーリーの付箋に書いておきます。

見積もりをしていると、疑問や確認したいことが発生することがあります。
その際には、プロダクトオーナーがステークホルダーにヒアリングを行い、開発チームに共有します。

プロダクトバックログを作成する

ユーザーストーリーの優先順位を決めて、プロダクトバックログを作ります。

ユーザーストーリーを模造紙から剥がして、ホワイトボードに貼り、優先順位に並べ替えます。
模造紙から剥がすとき、それが地図のどこにあったか分かるように識別子を振って、地図に書いておくといいでしょう。

スプリントを実行する

ここからはスプリントの開始です。
スプリントは次の流れで行います。

• スプリントプランニング
• 実行
• スプリントレビュー
• スプリントレトロスペクティブ
• バックログリファインメント

実際のスクラムでは、実行の際にデイリースクラムが実施されます。

スプリントプランニングの実施

スプリントの最初にはスプリントの計画をします。

まず最初に次のスプリントで消化できそうなポイントの予測をします。
消化とはステークホルダーに検収してもらえることをいいます。
この予測はスプリントを何度かこなすことで正確性が強まるものなので、チームの誰も類似の作業をしたことがない場合には、初回に関しては勘によるところも多いです（予測のために研究期間を設けることもあります）。

見積もった数値によって、ユーザーストーリーを入れ替えた方が綺麗に収まる場合があります。
たとえば、消化予測ポイントが２０のとき、８＋８＋３＝１９よりも８＋８＋２＋２＝２０の方が消化率はよいです。
そういったときは順序を並べ替えます。

また、巨大すぎるユーザーストーリーは取り扱いづらいものです。
その場合にはプロダクトオーナーと相談しながら、ユーザーストーリーの分割をします。

今回のスプリントで着手するユーザーストーリーが決まったら、次はタスク分けを行います。

ひとつのユーザーストーリーでひとつのタスクになることもあれば、複数のタスクが必要な場合もあります。
ここでタスクを洗い出しておくことで、開発チームはユーザーストーリーを分業できます。

実行

いよいよ開発のはじまりです。
７分のタイムボックスでタスクをこなしていきます。

タスクボードでタスクにサインアップして、ブロックを組み立てます。

実際にやってみると７分はあっという間です。

スプリントレビューの実施

７分の楽しい時間を終えたら、いよいよお披露目の時間です。

開発チームは着手したユーザーストーリーと成果物をステークホルダーにデモします。
成果物が完成していれば、ステークホルダーは完成を伝えます。

ここで重要なのは、スプリントレビューはプレゼンテーションではなくワーキングセッションであるということです。
ステークホルダーと一体になって、成果物が完成しているかどうか、完成していないのであれば何が必要か、フィードバックします。

スプリントレトロスペクティブの実施

レビューを終えたらスプリントのふりかえりを行います。

今回はKPTを使って振り返りをしました。
KPTはKeep, Problem, Tryの頭文字をとった振り返り方法で、「今後も続けること」「問題や課題」「次に挑戦すること」をそれぞれ考えて振り返る方法です。

KPTを実施するとPに囚われがちなので、Tを重視するように言い渡しておくとよいでしょう。

スプリントレトロスペクティブでありがちなのが、ここで次のスプリントの計画をはじめてしまうことです。
次のスプリントを計画するための時間として、スプリントプランニングがあります。
ここで行う計画は次のスプリントで行う改善の計画にとどめておきます。

バックログリファインメントの実施

スプリントが終わったら、次のスプリントにむけて、バックログリファインメントを行います。

バックログリファインメントはプロダクトバックログのお手入れをします。
優先順位の変更や優先順位上位のユーザーストーリーを着手可能にするために情報収集します。

次のスプリントへ

リファインメントが終わったら、またスプリントをはじめます。

今回私たちは４回スプリントを実行しました。
スプリント１回につき、だいたい３０分程度かかり、全体では半日程度の所要時間になります。

ワークショップレポート

ワークショップを実施した様子や感想を確認します。

できあがった街

まずはTeam Japanが開発した街です。

全体的にしっかりした建物が多い印象です。
途中で色については合わせなくても問題ないと判断したのか、色の統一はしなくなったようです。

次はチームサラマンダーの開発した街です。

特徴的な形をした建物が多いです。
私は温泉が好きです。

今回のワークショップはかなり上手く建物を作れたのではないかなと考えます。
恐らく、普段から交流のあるメンバーが多かったので、連携が取れていたのが要因でしょう。

建物のハイライトは最後にしますのでお楽しみに。

ベロシティの変化

１回のスプリントで消化できる要求の総量をベロシティといいます。
今回のワークショップでいえば、１スプリントで消化するユーザーストーリーの見積もりポイントの総和がベロシティです。

ベロシティは初回は小さく、スプリントが進むうちに安定するようになります。
特にはじめて実践するものだと完成にこぎつけないことも多く、最初のスプリントはベロシティが０になることもしばしばあります。

今回のワークショップでのベロシティの推移は次の画像のとおりです。

画像ではスラッシュの右側が予測値で左側が実際に消化できたポイントの総和です。
「＋１９」といった表記は、直前のスプリントで完成できなかったユーザーストーリーが完成になったことを表しています。

いずれのチームも最初はベロシティが低かったのですが、３回目から高い値で安定しはじめています。
また予測との乖離も少なく、ベロシティが信頼たる数値になりつつあるのが分かります。

参加者の感想

参加者には感想を書いてもらったので、ここにいくつかピックアップします。

• スプリントをこなすにつれてベロシティのズレが減ってきたのはリアルだと感じた
• １周目あたりは、ルールが飲み込めず戸惑ったことがあった
• 誰が今何をやってるかの共有をして、タスクのバッティングの危険を防ぐといった経験から、コミュニケーションの重要性を改めて認識した
• たとえば犬小屋の大きさについてなどで、ユーザーストーリーで認識の齟齬があったので、仕様確認の重要性を改めて認識した
• Tryで試みた「コンパクトに作る」や「建物の特徴を出す」を実践し、レビューでOKをもらえたのは達成感があった
• レゴ®だから楽しくできたのであって、実際に開発になると全然違う印象になるんだろうなと思った
• 普段コミュニケーションを取る機会がない人とも距離を詰めることができた
• 新卒の人たちにもスクラムを体験してもらいたい

事前にほかの軽量なスクラムワークショップをいくつか実施していたこともあり、このワークショップの効果をまじまじと感じたようで、スクラムに関して深く体験できたと感じた方が多かったようです。

またコミュニケーションを取るという意味でも、ワークショップは役立ったようです。

成瀬の感想

得るものや楽しさがもちろんあるのですが、それらを差し置いてとにもかくにも疲れました。
トレーナーとして、ファシリテーションしながら、同時に各チームのスクラムマスターをしてるような動き方をしていたので、かなり集中力を使いました。

DTF主管の部長が「スクラムはやっている最中はハイになっているけど、終わるとどっと疲れる」と言っていたのですが、その意味がよくわかるワークショップです。
逆に言えばこれほどの労力をかけないと、スクラムの本当のところを感じたり、学ぶのが難しいのではないかなという印象があります。

もちろん、実務で実践的にスクラムを学ぶこともできます。
その場合は１週間や２週間といった長いスパンでスクラムイベントを体験することになります。
そのため、なかなかそれぞれのイベントの趣旨やルールを覚えづらいです。

このワークショップであれば、スクラムで実施するイベントをその日のうちに何度も体験するので、趣旨やルールを確実に理解できます。
スクラムをこれから取り入れたいといったチームにとって、半日を費やす価値はあるのではないでしょうか。

作成物のハイライト

折角ですので、ワークショップで作られた建物のうち、いくつかをピックアップしてここで紹介します。

まずはどちらのチームも作ったものです。
テーマが同じであるので、意図せずして同じものが作成物にありました。
チームごとの特色が見えたりするので、まずは比べながら見てみましょう。

最初に紹介するのは「駅」です。

同じ駅でも何を重視するかというのはチームによって異なるのが面白いですね。

駅以外に、両方のチームで作られた建物としては公園がありました。

いずれも滑り台や植物は同じブロックを使っていて、最適解にたどり着いた印象がありますね。

次は私が個人的に好きな建物です。

この左手前の建物が、何かわかるでしょうか。　
──そう、温泉です。
センスが光りますね。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

さて、次は誰が見ても分かる建物です。

どうみても１００円ショップですね。
参加者全員がひと目でわかりました。

最後は誰が見ても分からない建物です。

お分かりでしょうか。

そうです。
コスメです。
「建物じゃないじゃないか」と思った方、そのとおりです。

本来は「コスメショップ」が欲しかったようですが、ユーザーストーリーに「コスメ」と書いてあったので、「コスメ」になってしまいました。
これはユーザーストーリーの書き方が悪かったのとステークホルダーとコミュニケーションエラーが発生した結果です。
実際のプロジェクトでもこういったことはよくありますよね。

おわりに

これはよく言われることですが、スクラムはフレームワークです。
どれか一部を切り取ってみても、あまりうまくいかないことが多いです。

ではフレームワークとしての効果を発揮するために、スクラムをいきなり実践で始めるのはどうでしょうか。
チームに意欲があっても、知識や理解がない状態では上手くまわらないでしょう。

「スクラムを始めるためにスクラムの知識や経験がほしい」
そんな要求に応えられるのがこのレゴ®スクラムです。
スクラムを実践したい方々にはぜひおすすめします。

また単純にコミュニケーション目的で実施するのもおすすめです。
スクラムをやったことがないチームには勉強目的で、既にスクラムを実践しているチームは新メンバーが増えたときなどに行うと自然とコミュニケーションを促せます。

童心に帰ってレゴ®をするのは立場も年齢も関係ありませんからね。

以上で今回の記事は終わりです。
長大な文章をここまでご覧いただきありがとうございました。

次回は、レゴ®スクラムの問題点であるオフライン環境必須という条件を打破すべく実施した、リモート環境下におけるスクラムワークショップのレポートを予定しています。

おまけ

レゴ®は置く場所がなかったので部長の席が保管場所になりました。

シリーズ一覧

https://developers.gmo.jp/5571/

https://developers.gmo.jp/10479/

https://developers.gmo.jp/13055/

著書の紹介欄

ブログの著者欄

採用情報

関連記事

• 

  私たちのふりかえり

  技術情報

• 

  オフショアとのスクラム開発への取り組み

  技術情報

• 

  チームでスクラム開発を導入してみました

  技術情報

• 

  スクラムワークショップ -Vol.04 紙飛行機ワークショップ

  技術情報

• 

  スクラムワークショップ -Vol.03 ピンポンゲーム編

  技術情報

• 

  スクラムワークショップ -Vol.02 マインクラフト編

  技術情報