developer の記事一覧

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第2回のテーマはマインクラフトを使ったオンラインでできるスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/technology/3750 ▻Vol.02_ｲﾏｺｺ https://developers.gmo.jp/technology/5571 https://developers.gmo.jp/technology/10479 https://developers.gmo.jp/technology/13055 はじめに みなさんこんにちは。成瀬（@nrslib）です。 前回はレゴ®を使ってスクラムワークショップを実施した話をしました。スクラム開発の要素をひと通り体験するにはとてもよいワークショップでした。 しかし、ひとつの問題がありました。それは、物理的なアイテムを使うがゆえにオフラインで実施する必要があることです。 私たちの現在の目的は、リモート環境における開発手法を探ることです。そのためのワークショップがリモート不可では片手落ち感が否めません。 そこで、リモート環境下におけるスクラムワークショップを実施することにしました。題材に選んだのは『マインクラフト』です。 マイクラスクラム 今回のワークショップはデモムービーを作ってみました。 https://youtu.be/8Ve_iMd92U4 楽しそうですよね。今回はこのMinecraft（マインクラフト）を使ったスクラムワークショップ、マイクラスクラムについて解説していきます。 Minecraftとは Minecraft（マインクラフト）は正方形のブロックで構成された仮想世界で、サバイバル生活を楽しんだり、自由にブロックを配置して建築をして楽しむサンドボックスビデオゲームです。2011年にリリースされ、執筆時点ではテトリスを抜いて世界で最も売れたゲームになっています。 どういったゲームか詳しい説明は公式をご覧ください。 https://www.minecraft.net/ja-jp/about-minecraft（公式サイト：Minecraftについて） Minecraftは一人でも楽しめますが、マルチプレイ機能があり複数人で遊ぶこともできます。代表的な遊び方として、複数人で協力しながら建物を作ったりします。つまり、レゴスクラムと同じようなやり方でスクラムワークショップができるのです。 さっそくマイクラスクラムのやり方を解説していきましょう。 ワークショップ概要 マイクラスクラムはMinecraftのマルチプレイモードを使って、スクラムの手法を実践しながらブロックで建物を作るワークショップです。 ワークショップでは参加者同士が数名でチームを組んで、テーマにしたがった建物を作ります。後述しますが、Minecraftではひとつの建物を作る方が向いています。 所要時間はレゴスクラムと同じく半日かかるものとみてください。特に、スクラム自体の解説から実施する場合はほとんど１日かかると考えてよいです。 準備するものは物理的なものは一切不要で、ソフトウェアやサービスをいくつか用意する必要があります。コストはMinecraftのソフト代（Java Editionは3,000円）のみです。また、どうしてもコストが出せない場合はMinecraft Classicという選択肢もあります（詳細は後述）。 マイクラスクラムはレゴスクラムと同程度に重厚なワークショップで、スクラム開発の基本を疑似的に体験できます。 準備するもの ワークショップを実施するにあたって準備するものは次のとおりです。 Minecraftホワイトボードソフトプランニングポーカーソフトマルチプレイ用サーバー（場合によっては不要） Minecraft これがなくては始まりません。参加人数に応じた数だけ購入しましょう。 注意点として、MinecraftにはJava Editionと統合版の２つの選択肢があります。バージョンによっては一緒にプレイできないので、参加者同士でバージョンを揃えるようにしておきましょう。 特にこだわりがなければJava Editionをお勧めします。Java Editionは統合版に比べてスペックが求められますが（それでもそれほど高いスペックではないです）、価格が安く、MOD（ゲーム性を変更する仕組み）が使えたりするなど自由度が高いです。 またJavaが動く環境であれば動作するので、OSに左右されず動作させられます。Nintendo Switchなどでワークショップをする姿は遊んでるように見られかねませんので、PCでできるというのは重要なところです。 なお、Minecraftを購入するコストが捻出できない場合はMinecraft Classicを利用する手立てもあります。Minecraft Classicはブラウザ上で遊べる無料のMinecraftです。ブロックに制限があったり、後述のフラットモードにできなかったりしますが、最大9人までのマルチプレイに対応しています。使い勝手は本家に劣るので、一度触ってみてから採用するか検討してください。 ホワイトボードソフト ワークショップではプロダクトバックログやタスクボードを使います。オフラインで実施する場合には物理的なホワイトボードがあれば問題ありませんが、オンラインの場合何かしらのオンラインソフトを利用する必要があります。 ホワイトボードで扱うものは次のとおりです。 プロダクトバックログタスクボード振り返り（KPTなど） これらが用意できるのであれば、ツールはどれでも構いません。 なお、私たちが今回のワークショップで使ったのはmiroでした。色々調べて触って候補を探したのですが、タスクボードの操作しやすさなどはmiroが最も手軽でした。 miroイメージ（左下がKPT、右下がタスクボード） プランニングポーカーソフト チームでユーザーストーリーを見積もる際にプランニングポーカーを使います。こちらもオフラインの場合はプランニングポーカーを使うのが最もやりやすいですが、オンラインの場合は工夫が必要です。 通話しながら「いっせーのせ！」でストーリーポイントを言い合う方法でもいいのですが、スマートにサービスを利用しましょう。 プランニングポーカーを複数人で行えるサービスにhajitsuというサービスがあります。ルームを作成して、参加者はそのURLにアクセスするだけでプランニングポーカーが行えます。非常に手軽なサービスなのでこちらをお勧めしておきます。 マルチプレイ用サーバー Minecraftでワークショップ用にマルチプレイサーバーを用意します。サーバーの設定はクリエイティブモード（自由にブロックを配置できる）でワールドタイプをスーパーフラット（平らな土地）にします。 Minecraftをマルチプレイする方法は大きく３種類あります。 ポートを開放するサーバーを建てるレンタルサーバーを利用する それぞれ簡単にご紹介します。 ポートを開放する ポート開放は若干の知識やルータへのアクセス権限などが要求されますが、コストは無料です。人数制限はポート開放をしたPCのスペックに左右されます。 サーバーを建てる サーバーを建てる選択肢はポート開放より高度な知識が要求されますが、解説サイトを利用すればそれほど難しくはないでしょう。ちなみに、私たちも最初はメンバーがサーバーを建てたのですが、うまく全員が接続できないトラブルが発生したので断念しました。 レンタルサーバーを利用する レンタルサーバーを利用する選択肢は今回私たちが利用した方法です。 MinecraftにはMinecraft Realmsというサブスクリプションがあります。Minecraft Realmsは月額1,000円弱でマルチプレイ用サーバーを利用できるサービスです。 Minecraft Realmsは公式が提供しているサービスなので、こちらを使うのが最も手軽です。が、落とし穴として、人数制限が10名までだったり、MODなどを使えなかったりします。 Minecraft Realms以外で手軽な選択肢として挙げられるのは、手前味噌でございますがConoHaのVPSです（PRしたいわけではないのですがお勧めなのでご容赦を……）。ConoHaのVPSではMinecraftサーバーのテンプレートが用意してあるので、そちらを使うだけでMinecraftのマルチプレイが可能です。料金も時間による従量課金形式なので、たとえば5-10名でお勧めのメモリ4GBのプランを10時間使ったとしても48円、11名以上推奨のメモリ8GBのプランの場合は93円とリーズナブルです。人数制限はスペックによって変更でき、MODなどのカスタマイズは無制限ですので、ワークショップ用にはおすすめです。 今回、私たちもワークショップをする際に最終的にはConoHaを利用したので、その手順をここでご紹介します。 まずConoHaでMinecraftサーバーを建てるには次のサポートページが参考になります。 ConoHa Minecraftサポートページ: https://support.conoha.jp/v/hellovps-m-01/ サポートページを参考にMinecraftのサーバーを作成したら、次はワークショップ用の設定をしていきます。ワークショップではクリエイティブモードの設定とワールドタイプをスーパーフラットに変更します。 まずサポートページに「VPSにログインしてMinecraftの設定をする」の手順のようにVPSにログインします。ログインしたらマインクラフトのディレクトリ（/opt/minecraft_server）のserver.propertiesを開きます。 cd /opt/minecraft_server/vi server.properties そして、次のプロパティの値を変えます。 gamemode=1level-type=flat 以上で設定は完了です。 スーパーフラットでワールドを再生成する必要があるので、次の手順でワールドを再生成しましょう。 サーバー停止worldディレクトリのリネームまたは削除サーバー起動 これで準備は完了です。なお、無駄に料金がかからないようにワークショップが終わったら忘れずにサーバーを削除しておきましょう。もしワークショップを行ったワールドを残しておきたい場合にはスナップショットを忘れずにとっておいてください。 ワークショップ解説 ワークショップは次の順序で進めます。 スクラム入門講義Minecraft練習チーム分け題目発表ペルソナ決定ユーザーストーリー作成ロール決定（PO／ScM）要求を交換するタスクボードの作成プロダクトバックログの作成プランニングポーカーによる見積もりスプリント（４回）ワークショップのふりかえりとまとめ 基本的に流れはレゴスクラムと同一です。流れを追いながらそれぞれでやることを確認していきましょう。 基本的な座組は同じなので、解説は一部レゴスクラムと同じになりますがご了承ください。 スクラム入門講義 何も予備知識なしに実施すると、各種イベントの位置づけや関連性がよく分からないまま、流れに身を任せる形になってしまいます。せっかく時間を使うのに、それでは勿体ないことこの上ないでしょう。 そこで、ワークショップの体験をより良い学習活動に変化させるために、ワークショップの前にスクラムの概要を説明する講義を行います。 ここで解説しておくべき内容はロールとスクラム全体の流れ、イベント・作成物の概要です。内容についてはレゴスクラムで解説した内容と同一ですので割愛します。 もしスクラム入門講義が難しいようであれば、個人の活動ですがマイクラスクラムと同じような座組で、モンハンを使ったスクラムワークショップを実施した際の入門講義が使えると思います（リンク先動画有）。 https://nrslib.com/monhan-scrum/ Minecraft練習 参加者はMinecraftの操作ができなくてはなりません。とはいえ、そのハードルは高くなく、いわゆる豆腐ハウス（正方形の家）を作れる程度には操作できれば問題ありません。まったくの初心者であっても正味２時間ほど操作して建物を作ったりすれば、ワークショップに必要な操作は覚えられるでしょう。 私たちもゲームをほとんどしないメンバーも多かったので、一度Minecraft練習をしました。時期的にはちょうど忘年会の時期だったのでMinecraft忘年会です。 https://twitter.com/nrslib/status/1340985190005362688 Minecraft忘年会の様子 もし練習する場合は、クリエイティブモードのスーパーフラットで行うのがおすすめです。建物を建てながら、どれくらいのものがどの程度の時間で建てられるのかを、参加者それぞれが確認しておくとよいでしょう。 練習時間に建築したもの チーム分け 今回のワークショップ参加者はトレーナー兼撮影係の自分を除いて６名。３名ずつの２チームに分けました。 Team15%成長 チームJapan 「チームJapan」は前回のスクラムワークショップから続投のチーム名ですが、チームメンバーは変わっています。今後もチーム名だけ受け継がれていきそうですね。 題目発表 チームが決まったら、今回作る建物のテーマの発表です。今回は「理想の職場」をテーマにしました。 その他の選択肢としては、「理想の街」や「遊園地」がありました。そのなかで「理想の職場」を選んだ理由は、Minecraftは細かい内装の作りこみができるので、ひとつの建物を作るのが面白そうだと考えたからです。 ペルソナ決定 メンバーそれぞれひとつのペルソナを持ちます。チームごとにどういった組織の職場になるのか意識合わせをして、職種や趣味などの属性を決めていきます。 参考までに私たちが作ったペルソナを紹介します。 若手エンジニア　ボルダリングが趣味ＣＴＯ　お酒好き部長　釣りが趣味デザイナー　アニメ好き企画職　アウトドアが趣味 ちょっと簡易的すぎますね。もう少しペルソナを深掘りしておくと次の行程がやりやすいです。 ユーザーストーリー作成 それぞれのペルソナにしたがって、理想の職場に欲しいものをユーザーストーリーとして作成していきます。ユーザーストーリーは次のテンプレートにしたがって記入します。 【どのような立場】として【どういったもの】が欲しい。それは【どういったこと】を達成したいからだ。ユーザーストーリーテンプレート ユーザーストーリーは建物の見取り図を描いて、ユーザーストーリーを配置したい箇所に貼っていきます。 チームごとにどういったユーザーストーリーになったか紹介します。まずは「チーム15％成長」です。 チーム15%成長のユーザーストーリー（３階部分抜粋） 「チーム15％成長」の組織は大企業で５階建てのビルに職場があります。「【部長】として【偉い】ので【個室】が欲しい」のユーザーストーリーはある種の潔さを感じますね。このチームの部長に対するイメージどうなってんだ。 ちなみに画像に３階部分抜粋とあるとおり、ユーザーストーリーは１階から５階に分けて配置されていて、１階にはカフェなどテナントに関するユーザーストーリーがありました。 チームJapanのユーザーストーリー 「チームJapan」は先ほどとは正反対にベンチャー企業とのことです。ボルダリングといった遊び心の中にデスマなどの不穏な単語が潜むのもそれ由来だそうです。 ロール決定（PO／ScM） チームごとにメンバーからプロダクトオーナーとスクラムマスターを選出します。 プロダクトオーナーはこのあと作るプロダクトバックログの管理を主体的に行います。開発チームと相談しながら、バックログアイテムの順序を変更し、必要に応じてステークホルダーとのやり取りします。もちろん開発者も兼任することになるので、建築物を建造します。 スクラムマスターを選出するかどうかについては任意です。スクラムマスターを選出する場合は、事前に打診して、スクラム開発に関する理解を深めてもらう必要があります。 なお今回は、前回レゴスクラムをやった経験があったので、任意のメンバーにスクラムマスターを担当してもらうことにしました。 要求を交換する プロジェクトの多くは、自分以外の誰かが欲しいものを作ることが多いです。そこで、今回のワークショップでもそれを再現すべく、地図の交換をしました。つまり、参加者の眼前には他のチームのユーザーストーリーが貼られた街が広がることになります。参加者が開発するのは、目の前の街です。 以降、参加者は一人二役になります。目の前の街に対しては開発チームとして振舞い、もう一方のそれまで自分たちの要求を張り付けてきた街に対してはステークホルダーとして振舞うことになります。 タスクボードの作成 チームごとにタスクボードを作成します。タスクボードのフェーズはTODO, DOING, DONEだけのシンプルなもので構いません。ユーザーストーリーごとに複数のタスクができる可能性があるので、いくつか行を用意しておくとよいでしょう。 タスクボードサンプル プロダクトバックログの作成 取り掛かるユーザーストーリーの順序を決めて、プロダクトバックログを作ります。なお、建物見取り図に配置されたユーザーストーリーをそのままプロダクトバックログに移動してしまうと、どこに配置すべきものなのかわからなくなってしまいます。建物見取り図からユーザーストーリーをコピーしてプロダクトバックログを作りましょう。 プロダクトバックログのサンプル このときユーザーストーリーには存在しなかった「オフィスを建てる」といった共通して必要になるようなものもバックログアイテムとして追加します。 プランニングポーカーによる見積もり ユーザーストーリーをプランニングポーカーを使って見積もりします。 プランニングポーカーができるサービス「hajitsu」 プランニングポーカーを知らない方向けに説明すると、数字の書かれたカードを一斉に出し合う見積もり方法です。メンバーは任意のユーザーストーリーに対してプランニングポーカーを使って、自分が思うポイントをあてはめます。 プランニングポーカーで使われる数値は工数を直接表すものではなく、重みを表すポイントです。基準となる数値を決めて、そこから相対評価でポイントを見積もります。人間は相対評価が得意なので、スムーズに見積もりができます。 場に出たカードのポイントが一致すれば、合意が取れたことになります。数値が大きい、あるいは小さいときは、なぜその見積もりになったのかをインタビューして、そこに潜む問題点やハックを深掘りします。このような手順を取ることで、見積もりが公正で透明性と納得感のある数値に近づきます。 なお、相対評価をするためには基準を最初に決める必要があります。通常は開発チームで合意が取れるもっとも平均的なユーザーストーリーを選んで、それを３とします。練習時間に作った建物で平均的な建物の合意を取りましょう。 見積もったストーリーポイントはユーザーストーリーに記入しておきます。 見積もったポイントをユーザーストーリーに記入（miroのタグ機能を使ってます） スプリントを実行する ここからはスプリントの開始です。スプリントの流れは次のとおりです。 スプリントプランニング実行スプリントレビュースプリントレトロスペクティブバックログリファインメント スプリント開始前に、チームごとに境界線を決めておきます。 境界線 スプリントプランニングの実施（5分） 実行の前にスプリントの計画をします。スクラムでは計画が重要視されます。 最初に今回のスプリントで消化できるポイントの予測をします。消化とはステークホルダーに検収してもらえることをいいます。この予測はスプリントを何度かこなすことで正確性が強まるものなので、初回は練習時間を参考に予測しましょう。スプリントが２週目以降であれば、ベロシティ（それまでのスプリントの結果を参考にした消化予測ポイント）を参考にします。 予測されたポイントに従ってプロダクトバックログの上から順番に、今回のスプリントで取り組むユーザーストーリーを機械的に決めていきます。消化予測ポイントに対して機械的にユーザーストーリーを決めていくと余ってしまうことがあります。その際にはユーザーストーリーの順序を入れ替えて、なるべく余りが出ないようにします。 また、巨大すぎるユーザーストーリーは取り扱いづらいものです。その場合にはプロダクトオーナーと相談しながら、ユーザーストーリーの分割をします。 今回のスプリントで着手するユーザーストーリーが決まったら、次はタスク分けを行います。 実行 開発開始！ いよいよMinecraftの開始です。計画に従って建築していきます。タスクにサインアップして作業に取り掛かりましょう。タイムボックスは45分です。15分経過、30分経過時点でデイリースクラムを実施します。デイリースクラムはスクラムマスターの判断によりスキップしても構いません。 スプリントレビューの実施（3分） チームが開発したものをステークホルダーにデモします。 レビューの様子 開発チームは着手したユーザーストーリーとインクリメントをステークホルダーにデモします。インクリメントが検収可能ならステークホルダーは完成を伝えます。反対に検収不可能であれば、足りない要素が何かをフィードバックします。 ここで重要なのは、スプリントレビューはプレゼンテーションではなくワーキングセッションであるということです。ステークホルダーと一体になって、成果物が完成しているかどうか、完成していないのであれば何が必要か、フィードバックします。 スプリントレトロスペクティブの実施（5分） レビューを終えたらスプリントのふりかえりを行います。 KPTなどのフレームワークを使って5分で振り返りを行います。 KPTによる振り返り KPTを利用する場合は、Pに囚われがちなので、KやTを重視するように言い渡しておくとよいでしょう。 バックログリファインメントの実施（5分） 次のスプリントの前にプロダクトバックログのお手入れをします。 具体的にはプロダクトバックログの上位にあるバックログアイテムを着手可能にします。情報が不足している場合にはステークホルダーにインタビューを行い、必要な情報集めます。ユーザーストーリーが巨大すぎる場合には分割をします。 次のスプリントへ スプリントが終了したら次のスプリントに進みます。 スプリントは全４回です。２回終わった時点で休憩を入れるとちょうどよいです。 ワークショップレポート ここからは私たちが実際に行ったマイクラスクラムワークショップのレポートです。 できあがった職場 スプリント４回時点のインクリメント 右の建物が「チーム15%成長」のメンバーがオフィス部分を借り上げて職場としているビルで、左の建物が「チームJapan」のベンチャー企業が拠点とする事務所です。 スプリント一回目の状況と比較するとかなりの大作になりました。 スプリント１回目の様子 撮影した建築シーンをダイジェスト動画にしてみたので興味がある方はどうぞ。 https://youtu.be/yJiRxvJiJU4 参加者の感想 今回も参加者に感想を書いてもらったので、ここにいくつかピックアップします。 レゴなりマイクラなり半日以上のワークショップをしないとスクラムのやり方がはなかなか理解できなさそうリモートワークでもしっかりスクラムができることが分かって良いマイクラの操作（wasd）に慣れていないと若干きついスクラムの一連の流れを掴めたので、このノリ（マイクラでやったじゃーん的な）で業務に活かせそうレゴより体力的に負荷が少ない安定したネットワーク等ある程度のPC環境が必要レゴスクラムと同じくらいスクラムに対する学びがあると感じたオンラインツールと組み合わせてワークショップを進められるのが良かったレゴよりも表現の幅やできることが多いので、マイクラの方が見積もりやタスクで苦戦できて良い学びになる 総じてポジティブな意見が多く、リモートでコミュニケーションの貯金をする手段としても有用になりそうです。 成瀬の感想 今回はスクラムマスターをチームのメンバーに任せたのに加え、リモートでのワークショップなので疲れはほとんどありませんでした。むしろずっと撮影係をしながら、各チームのチャットに乱入して、マイクラのアドバイスをしていた記憶しかありません。 ワークショップとしては、メンバー個人個人がMinecraftをもってさえいれば、かかるコストはマインクラフトサーバー代ぐらいになるので、とても気軽に実施できてお勧めです。 得られる学びもレゴスクラムとほとんど遜色ありません。スクラムを取り入れたり、未経験者がオンボーディングするために、半日を費やす価値はあるのではないでしょうか。 建築物のハイライト お待ちかね、建造物紹介のコーナーです。 まずは真面目なものから。とても開放的な執務スペースです。 【プログラマ】として【広いデスク】がほしい。それは【快適に業務がしたい】からだ。 目が疲れたら緑に視線を移して視力を維持できそうですね。調度品とかランプがおしゃれです。 お次はどちらのチームでも作っていた会議スペースです。 【部長】として【会議室】がほしい。それは【ミーティングすることが多い】からだ。 【プログラマ】として【開放的な応接スペース】がほしい。それは【透明性があるミーティング】をしたいからだ。 いずれのチームもガラス張りです。ワークショップ参加者は全員開発者なので、透明性とかそういった言葉に弱いんですよね。かたや豪華なしつらえに対し、足元に草が生えているなど、大企業・ベンチャー企業の特徴がそれぞれ出ています。 今度は仮眠スペースです。 【プログラマ】として【仮眠室】が欲しい。それは【眠気を覚ましたい】からだ。 【若手エンジニア】として【寝床】が欲しい。それは【デスマがある】からだ。 前者はともかく、後者は仮眠ではなさそうですね。ちなみに扉を開くペダルスイッチは外側にしかないので、内側からは開けることができない仕組みです。 最後は特徴的な建物についてです。 【若手エンジニア】として【植木鉢と花】が欲しい。それは【コーディングに疲れたときに癒されたい】からだ。 植木鉢……？ 示し合わせたわけではないのですが全員の共通認識として「世界樹」と呼ばれていました。大きな樹はなんでも世界樹になっちゃうのは人類共通なのかもしれません。ちなみに根本が暗すぎてコウモリが沸いてました。ペットって言い張ってました。 おわりに 昨今、リモートワーク普及により、新たなメンバーのオンボーディングがオンラインで完結するケースが増えてきました。そういった状況下でスクラム開発未経験者がスムーズにスクラムチームにオンボーディングする方法として、オンライン完結のワークショップは最適です。 単純なレクリエーションとしても面白いので、新規メンバーのオンボーディングにお悩みのみなさまにお勧めします。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第一回のテーマはレゴ®によるスクラムワークショップです。 この記事は約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 チームサラマンダー チーム名は「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が開発した街です。 Team Japanが開発した街 全体的にしっかりした建物が多い印象です。途中で色については合わせなくても問題ないと判断したのか、色の統一はしなくなったようです。 次はチームサラマンダーの開発した街です。 チームサラマンダーが開発した街 特徴的な形をした建物が多いです。私は温泉が好きです。 今回のワークショップはかなり上手く建物を作れたのではないかなと考えます。恐らく、普段から交流のあるメンバーが多かったので、連携が取れていたのが要因でしょう。 建物のハイライトは最後にしますのでお楽しみに。 ベロシティの変化 １回のスプリントで消化できる要求の総量をベロシティといいます。今回のワークショップでいえば、１スプリントで消化するユーザーストーリーの見積もりポイントの総和がベロシティです。 ベロシティは初回は小さく、スプリントが進むうちに安定するようになります。特にはじめて実践するものだと完成にこぎつけないことも多く、最初のスプリントはベロシティが０になることもしばしばあります。 今回のワークショップでのベロシティの推移は次の画像のとおりです。 ベロシティの推移（丸数字が回数で、その横の数値は「完了／予測」を表す） 画像ではスラッシュの右側が予測値で左側が実際に消化できたポイントの総和です。「＋１９」といった表記は、直前のスプリントで完成できなかったユーザーストーリーが完成になったことを表しています。 いずれのチームも最初はベロシティが低かったのですが、３回目から高い値で安定しはじめています。また予測との乖離も少なく、ベロシティが信頼たる数値になりつつあるのが分かります。 参加者の感想 参加者には感想を書いてもらったので、ここにいくつかピックアップします。 スプリントをこなすにつれてベロシティのズレが減ってきたのはリアルだと感じた１周目あたりは、ルールが飲み込めず戸惑ったことがあった誰が今何をやってるかの共有をして、タスクのバッティングの危険を防ぐといった経験から、コミュニケーションの重要性を改めて認識したたとえば犬小屋の大きさについてなどで、ユーザーストーリーで認識の齟齬があったので、仕様確認の重要性を改めて認識したTryで試みた「コンパクトに作る」や「建物の特徴を出す」を実践し、レビューでOKをもらえたのは達成感があったレゴ®だから楽しくできたのであって、実際に開発になると全然違う印象になるんだろうなと思った普段コミュニケーションを取る機会がない人とも距離を詰めることができた新卒の人たちにもスクラムを体験してもらいたい 事前にほかの軽量なスクラムワークショップをいくつか実施していたこともあり、このワークショップの効果をまじまじと感じたようで、スクラムに関して深く体験できたと感じた方が多かったようです。 またコミュニケーションを取るという意味でも、ワークショップは役立ったようです。 成瀬の感想 得るものや楽しさがもちろんあるのですが、それらを差し置いてとにもかくにも疲れました。トレーナーとして、ファシリテーションしながら、同時に各チームのスクラムマスターをしてるような動き方をしていたので、かなり集中力を使いました。 DTF主管の部長が「スクラムはやっている最中はハイになっているけど、終わるとどっと疲れる」と言っていたのですが、その意味がよくわかるワークショップです。逆に言えばこれほどの労力をかけないと、スクラムの本当のところを感じたり、学ぶのが難しいのではないかなという印象があります。 もちろん、実務で実践的にスクラムを学ぶこともできます。その場合は１週間や２週間といった長いスパンでスクラムイベントを体験することになります。そのため、なかなかそれぞれのイベントの趣旨やルールを覚えづらいです。 このワークショップであれば、スクラムで実施するイベントをその日のうちに何度も体験するので、趣旨やルールを確実に理解できます。スクラムをこれから取り入れたいといったチームにとって、半日を費やす価値はあるのではないでしょうか。 作成物のハイライト 折角ですので、ワークショップで作られた建物のうち、いくつかをピックアップしてここで紹介します。 まずはどちらのチームも作ったものです。テーマが同じであるので、意図せずして同じものが作成物にありました。チームごとの特色が見えたりするので、まずは比べながら見てみましょう。 最初に紹介するのは「駅」です。 チームサラマンダーの駅 Team Japanの駅 同じ駅でも何を重視するかというのはチームによって異なるのが面白いですね。 駅以外に、両方のチームで作られた建物としては公園がありました。 Team Japanの公園 チームサラマンダーの公園 いずれも滑り台や植物は同じブロックを使っていて、最適解にたどり着いた印象がありますね。 次は私が個人的に好きな建物です。 左手前の建物 この左手前の建物が、何かわかるでしょうか。　──そう、温泉です。センスが光りますね。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 さて、次は誰が見ても分かる建物です。 誰が見てもわかる建物 どうみても１００円ショップですね。参加者全員がひと目でわかりました。 最後は誰が見ても分からない建物です。 誰が見てもわからない建物 お分かりでしょうか。 そうです。コスメです。「建物じゃないじゃないか」と思った方、そのとおりです。 本来は「コスメショップ」が欲しかったようですが、ユーザーストーリーに「コスメ」と書いてあったので、「コスメ」になってしまいました。これはユーザーストーリーの書き方が悪かったのとステークホルダーとコミュニケーションエラーが発生した結果です。実際のプロジェクトでもこういったことはよくありますよね。 おわりに これはよく言われることですが、スクラムはフレームワークです。どれか一部を切り取ってみても、あまりうまくいかないことが多いです。 ではフレームワークとしての効果を発揮するために、スクラムをいきなり実践で始めるのはどうでしょうか。チームに意欲があっても、知識や理解がない状態では上手くまわらないでしょう。 「スクラムを始めるためにスクラムの知識や経験がほしい」そんな要求に応えられるのがこのレゴ®スクラムです。スクラムを実践したい方々にはぜひおすすめします。 また単純にコミュニケーション目的で実施するのもおすすめです。スクラムをやったことがないチームには勉強目的で、既にスクラムを実践しているチームは新メンバーが増えたときなどに行うと自然とコミュニケーションを促せます。 童心に帰ってレゴ®をするのは立場も年齢も関係ありませんからね。 部長が本気でブロックを組み立てる様子 以上で今回の記事は終わりです。長大な文章をここまでご覧いただきありがとうございました。 お気に入りの建物をもって記念撮影 次回は、レゴ®スクラムの問題点であるオフライン環境必須という条件を打破すべく実施した、リモート環境下におけるスクラムワークショップのレポートを予定しています。 おまけ レゴ®は置く場所がなかったので部長の席が保管場所になりました。 シリーズ一覧 https://developers.gmo.jp/technology/5571 https://developers.gmo.jp/technology/10479 https://developers.gmo.jp/technology/13055