スクラム の記事一覧

こんにちは。儀部です。弊社はグループ会社であるGMO-Z.com RUNSYSTEM(ベトナム)と協業でスクラム開発を取り入れており、その中で私はスクラムマスターを担当しております。本記事では私たちスクラムチームのふりかえりを紹介いたします。 ふりかえり（スプリントレトロスペクティブ）とは スクラム開発のイベントの1つで、スプリントの最後にスクラムチームが行うふりかえり会です。スプリント中に起こったことを振り返ることで、改善点を見つけるためのフィードバックの場として機能します。 ふりかえりの目的 チームメンバーからフィードバックを得て、スプリント中にうまくいったことや、問題が発生した原因を特定すること。問題を解決するために、改善策を話し合うこと。 実施方法 私たちのスクラムチームは渋谷、北九州、ベトナムの3拠点にメンバーがいるため、Zoomを利用し、オンラインホワイトボードツール（MiroやMicrosoft Whiteboardなど）を使用しています。KPTなどの手法に沿って、メンバーそれぞれが意見を付箋に記載します。 ふりかえりで試した手法 私たちのスクラムチームで試した手法として下記の5つを紹介いたします。 KPT 意見を出す手法として、Keep(続けること)、Problem(問題・課題)、Try(試したいこと)の3つの質問に回答する手法です。 KPT シンプルかつポピュラーなので取り組みやすいです。継続的に実施していると、Problem(問題・課題)の意見がだんだんと出なくなることがあります。Keep→Try(強化)よりもProblem→Try(改善)に向かうことがあります。 Continue、Stop、Invent、Act 意見を出す手法として、Continue(続けたいこと)、Stop(やめたいこと)、Invent(提案)、Act(行動)の4つの質問に回答する手法です。 Continue、Stop、Invent、Act KPTと類似しているため、KPTから始めて手法を変更する際に取り入れやすいです。Invent(提案)から改善につながる意見が出やすいです。Stop(やめたいこと)の意見が出にくいことがあります。 Fun Done Learn 意見を出す手法として、楽しかったこと（Fun）、完了したこと（Done）、学んだことや気づいたこと（Learn）の3つの質問に回答する手法です。 Fun Done Learn 楽しく振り返りができます。ポジティブな内容のため、全体的に意見が出やすいです。次のアクションにつなげるのが難しいという課題があります。 Good & New 意見を出す手法として、良かったこと（Good）、新しい発見（New）の2つの質問に回答する手法です。 Good & New 短時間で実施できます。ポジティブな内容であるためアイスブレイクに適しています。単独では継続的に実施するには物足りない場合があります。 YWT 意見を出す手法として、やったこと（Y）、わかったこと（W）、次にやること（T）の3つの質問に回答する手法です。 YWT 実際の出来事を起点に考えるため、意見が出しやすいです。「わかったこと」の共有を通じて、チーム内にノウハウが蓄積しやすいです。 ふりかえりで得た気付き 質問が抽象的で意見が出しづらい 例えば、今回やったことの中で、「新しく取り組んだこと」や「工夫したこと」といった特定の項目に絞ってから意見を出すようにしました。 同じ手法ばかりでマンネリ化することがあった 慣れてきたタイミングで、別の手法に切り替えるようにしました。 静寂に包まれていると意見が出づらい 参加者に付箋を記載する間、BGMを流し、明るい雰囲気をつくるようにしました。 まとめ 以上、私たちのスクラムチームのふりかえりについて紹介させて頂きました。ふりかえりの手法について、最初に取り組むなら、ポピュラーな手法で経験者も多いためKPTがオススメだと思いました。また、角度を変えたい場合は感情という観点でふりかえれるためFun Don Learnが新鮮で良かったです。どの手法も一長一短ありますので、メリット・デメリットを踏まえ、現状のチームに最適なものは何かを考えて都度採用していくのが良いと思います。アクションアイテムの評価など、ふりかえり自体に課題は残っていますが、より効果的に実施していくために、チームで改善を進めていく予定です。

弊社のグループ会社であるGMO-Z.com RUNSYSTEM(ベトナム)と協業で開発を進める上でスクラム開発を取り入れており、その中で私はスクラムマスターを担当しております。本記事ではスクラムでのメリットや今後の改善点などを紹介いたします。 スクラム開発の導入 生産性の向上を目指してスクラム開発が導入されました。 他にも事業部門との連携強化などの効果も見込んで取り組んでおります。 スクラムチームの体制 チーム構成は下記の通りで所属はバラバラですが、スクラムチームとして活動しております。ステークホルダーは弊社事業部門のマネージャーの方にご担当頂いております。 プロダクトオーナー：弊社事業部門のメンバー開発チーム　　　　：GMO-Z.com RUNSYSTEMのメンバースクラムマスター　：弊社システム部門のメンバー スクラムの実際の運用 前提 タスク管理ツールはJiraを使用してタスクをチケットとして管理しております。スプリントの期間は2週間で実施しております。開発チーム6名のうち日本語でコミュニケーションを取れるのはブリッジSE1名で、スクラムイベントへの参加者も開発チームからはブリッジSE1名のみになります。（ブリッジSEが開発チームの状況を把握した上での参加）見積と実績は時間で運用しております。スクラムイベントはカスタマイズして実施しております。（ご了承くださいませ） デイリースクラム 参加者　：開発チーム、スクラムマスター開催頻度：毎日開催時間：15分 アイスブレイクの一環として日本とベトナムの違いについて雑談。ブリッジSEからチケットごとに「昨日の進捗」「本日の予定」「問題点や相談事項」に沿ってヒアリング。 スプリントプランニング 参加者　：プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 下記①、②は事前にご対応頂き、スプリントプランニングでは③に注力しております。①プロダクトオーナーがチケットを優先度順で登録する②開発チームが登録された各チケットの対応にかかる時間を見積もる③スクラムチームがこれまでの実績と見積もりを比較の上、どのチケットまで対応完了できるか計画を話し合って合意を取る スプリントレビュー 参加者　：ステークホルダー、プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 ステークホルダー向けにスプリントでのインクリメントのレビューを実施して、頂いたご意見をもとにプロダクトの改善を図るきっかけとなっております。チケットごとに対応内容の説明はプロダクトオーナー、デモはブリッジSEが担当してレビューを進めております。 スプリントレトロスペクティブ 参加者　：プロダクトオーナー、開発チーム、スクラムマスター開催頻度：2週間に1回開催時間：30分 KPT（Keep：続けたいこと／Problem：問題点・課題／Try：挑戦したいこと）に沿って出た意見の中で1番賛が多かった意見を次のスプリントで実施するようしています。他のフレームワークも試してみて、合うものを模索したいと考えております。 導入したメリット スクラムチーム内で確認したところ、下記4点挙がりました。 タスクボードの活用によって各チケットのステータスや担当者などの情報が可視化されたため状況が把握しやすくなったチケットの相対的な優先順位を認識することができるようになったゴール（どのチケットまで完了する見込みか）の共通認識をチームで持つことができた導入前と比較してMTGにかかる工数を削減することができた 今後の改善点 直近の改善点として下記を考えております。 スクラムイベントの最適化 ブリッジSE以外の開発チームメンバーもスクラムイベントに関われるように運用を変更する チケット対応方法 1チケット1開発者での対応でなく、優先順位をもとにチームでチケットを対応してもらうようチケットの中でさらにタスクを分割する まとめ 私自身、前任者がスクラム開発を導入した状態から昨年12月に引き継いで当PJに参画いたしました。まだ試行錯誤している状態ですが、改善を重ねてより良いスクラムでの運用をできればと考えております。 ここで出たメリットはスクラムチームのみなさまにご理解・ご協力頂いた賜物だと思っていますので、今後も生産性の向上を目指して、チーム一丸で挑戦していきたいと考えております。

こんにちは。デベロッパーリレーションズチームの村上です。今回は最近チームで取り組んでいるスクラム開発について書いていきます。よく聞く開発手法だけど具体的にどんなものなのか、実際生産性って向上するのか等、気になる方はぜひ参考にしていただければ幸いです。 スクラムの導入 今回チームにスクラム開発を導入するとなった経緯は、上長からの指示がきっかけでした。ただ自分自身別の機会でスクラム開発のいい部分を経験していたので、ぜひ取り組みたいものでした。全員で始めるのは難しいので、まずはトライアルとして少数で始めることになりました。 https://developers.gmo.jp/5571/ https://developers.gmo.jp/14672/ 体制について スクラムマスターは私が担当し、サービスのディレクションをするディレクターにプロダクトオーナーを担当してもらってます。開発チームは新卒2～3年目のメンバーを中心に4名アサインしました。全員がスクラム開発をするのは初めてなので、（今もですが）手探りで最適なやり方を探しています。ステークホルダーは事業部の担当者になりますが、まだまだスクラム開発の流れにうまく参加してもらえていない部分があるので、今後更にスクラム開発を進めていく上では、協力してもらうことが必須になってきそうだなと考えてます。 スクラム実践 それでは実際にどのように実践しているかを書いていこうと思います。実践するにあたり、所謂スクラム開発の型には嵌めてまず取り組み、チームのやり方として合わないなというものを自分たちに合うように改変して行っています。なのでアンチパターンを含む部分もありますが、ご了承いただけると幸いです。 使っているツールに関して スクラム開発を行う際に、バックログやタスクボードを管理する必要がありますが、本来であればホワイトボードに模造紙を貼り、直接書き込んだり付箋をペタペタ貼っていきます。ただ現在オフライン・オンラインでのハイブリッドな体制で日々業務を行っているので、今回はmiroを使用しています。スクラム開発で出てきた様々な情報は、このmiroに書き込んでいってチームの全員がいつも目に入るようにしておくことで、作業効率をアップさせていきます。 スプリントの期間 テンプレートなやり方だと、スプリントの期間は最低2週間からと言われています。それに倣いうちのチームでも1スプリントを2週間と定めました。案件によっては2週間が長すぎる場合もありますが、まずはスクラム開発のリズムを掴んでもらうため、現在もそのままにしています。 デイリースクラム デイリースクラムは朝に行っています。デイリースクラムは15分以内という制約があるので、それ以前と比べてスピーディーにMTGを終わらせることができています。ただ時間に囚われて大事な報告や相談事が漏れてしまうことがあったので、短い時間の中でしっかりと話し合う力をつけることは大事かもし行うれません。報告を行う際は、ふんわりとした表現は使わず、あと○時間で終わりますや、こういう懸念事項があるので終わりませんと言い切った報告してもらえるとわかりやすいですね。 スプリントプランニング スプリントプランニングは主にスプリントの開始時にやってますが、バックログがなくなってきたり新しいバックログが追加された際は都度行っていきます。最初は仕様がわかっている私がタスク作成を行っていたのですが、現在は開発チームで頑張ってやってもらってます。タスクに関してはなるべく細かく分割するようにして、複数の改修を含まないように作ってもらってます。そうすることでタスクのコードレビューがやりやすくなり、ミスが減ったり複数人での仕様の理解が進んでいるように感じます。タスクは開発チームでサインアップしており、自身のレベルに合わせたタスクを取ったり、やってみたいタスクを取れる環境ができています。スクラム開発の当初より積極的にサインアップを行っていたり、難しいタスクを複数人で対応しようとしたりする姿が見えて、チームも成長している実感が非常にあります。 スプリントレトロスペクティブ 振り返りに関してはまだうまく意見を出せてる感じはありません。今後もスクラム開発を継続していくことで「なぜうまくいかなかったか」「次回はどうすればうまくいくのか」を繰り返していくことが大事だと考えてます。まだまだ意見は少ないですが、慣れてくればもう少しスクラム開発についてが見えてくるようになるはずです。 これから改善する点 上記のスクラムの実践ですが、現在3ヶ月ほど経過した状況です。その中でもこれから実践・改善に取り組まないといけないポイントを上げていきます。 スプリントの期間が長い 現状細かな案件を含めると週に2度ほどリリース作業を行っています。その状態でスプリントが2週間というのがちょっと長すぎるかなという印象があります。アンチパターンではありますが、スプリントを1週間にして、金曜にスプリントプランニング、木曜にスプリントレビューを行うようなリズムが良さそうと考えてます。週末にプランニングしておくことで、週初めからスムーズに作業に入れるかなと考えたからです。いっそスプリントレビューも金曜にして、午前中にスプリントレビュー、午後にスプリントプランニングみたいなやり方でも良いかもしれません。 ベロシティが安定しない・測りづらい これには色々な要因があると考えます。 1つはサービス開発における運用案件の存在です。現在のスプリントプランニングに運用案件を入れていない為、純粋に元あるタスクが進まないという状態になります。プランニングに含めればベロシティとしては測れるようになるので、今後は含めてスクラムを回していかないといけません。 それ以外だとストーリーポイントの数値の不正確さです。これはエンジニアのスキル差が結構あるのもあるし、そもそもプランニングポーカーの数値のイメージがチーム内で揃っていないような感じを受けてます。今後もあんまり上手く見積もれる気がしていないので、実際の時間で見積もりしようかと考えてます。通常はストーリーポイントとかでタスクの分割を意識するのですが、現在は1改修＝1タスクにしてかなり細かくしてるので、タスクに落とし込む部分はうまくできてそうです。 スプリントレビューの重要度 スプリントレビューはスプリントでのインクリメントのレビューを行うものですが、現状では開発に入った段階でかなり仕様が確定してるので、ステークホルダーにインクリメントのレビューを行ってもらうほどじゃないという状態です。ただリリース直前にステークホルダーのチェックがはいるので、それがスプリントレビューの代わりになってます。どのような形でスプリントレビューを実施するか、その形を今後は模索していくことになりそうです。 まとめ いかがだったでしょうか。まだまだ荒削りというか試行錯誤の段階なので、色々と考える部分はあるのですが、うまくスクラム開発を回せれば生産性向上に繋がりそうな感じはあります。現在うちのチーム以外でもスクラムチームの運用が始まっており、定期的に情報共有を行ってます。みなさんもスクラム開発は自分のチームに合わないなと最初から決めず、まずは取り組んでみて自己流にカスタマイズするのもありじゃないかなと思います。それがアンチパターンであったとしても、結果として生産性向上に繋がれば成功です。ぜひ取り組んでみてください。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第４回のテーマは紙飛行機を使ったスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/3750 https://developers.gmo.jp/5571 https://developers.gmo.jp/10479 ▻Vol.04_ｲﾏｺｺ https://developers.gmo.jp/13055 はじめに みなさんこんにちは。成瀬（@nrslib）です。 今回も前回と同様、レゴやマインクラフトを使った重厚なワークショップの前に行った、パイロット的なスクラムワークショップをご紹介します。ワークショップは2020年11月に実施したものです。 このワークショップで取り扱う題材は「紙飛行機」です。 本格的なスクラムワークショップをするために必要なこと スクラムを実践するにあたって、その全貌を把握しておくことはオンボーディングのスムーズさに寄与します。全貌を体験しながら実感に落とし込むのにワークショップはうってつけです。 そこでワークショップを企画するのは自然な流れですが、どういったワークショップを実施するかを考えなくてはいけません。 スクラムのワークショップはおおきくふたつのワークショップに分けられます。半日や１日といった長いスパンで行う本格的なワークショップと、１・２時間程度で終わる簡易的なワークショップです。 スクラムを実感に落とし込むためには、長いスパンで行う本格的なワークショップを実施すべきです。そこでいきなり本格的なワークショップを実施しようとすると、うまくいかない可能性があります。なぜなら本格的なワークショップを実践するためにもある程度の知識が必要だからです。そこで簡易的なワークショップの出番です。スクラムのワークショップは簡易的なものとはいえ、スクラムの重要な要素を部分的にカバーしています。参加者全員が何もわからない状態で本格的なワークショップを行うよりも、ある程度前知識として知っている部分がある状態のほうがスムーズにいくのは想像に難くありません。 今回は本格的なスクラムワークショップの前に実施した、簡易的なスクラムワークショップの紹介です。 気になるワークショップの題材は…… 紙飛行機です。 紙飛行機ワークショップ 今回紹介するワークショップはその名のとおり紙飛行機を使ったワークショップです。 前回のピンポンゲームに比べると、少しワークの内容が複雑で、くり返し改善していく流れが体感できます。 基本的な流れは下記記事を参考に行いました。 https://dev.classmethod.jp/articles/scrum-training-airframe/ ワークショップ概要 ワークショップではA4の紙から紙飛行機を作って飛ばします。そのうち３メートル以上飛んだものをポイントとして加算します。 もちろん、ただ紙飛行機を作って３メートル以上飛ばすだけではなく、いくつかのルールが存在します（まさか紙を丸めて３メートル放り投げるような人はいないでしょうが）。 ルール ワークショップでは紙飛行機を３メートル飛ばすのを目標としますが、いくつかの制限事項が存在します。 A4の紙を４つに切って使う紙飛行機の先端はハサミで丸くする一度折ったらほかのメンバーに渡す（連続で折らない）紙飛行機を飛ばすのは１回につき１機（まとめて飛ばさない）紙飛行機を飛ばすのは１機につき１回（同じ飛行機を何度も投げない）各スプリント終了時に作成物はすべて破棄する これらのうち特にキーとなるのは「一度折ったらほかのメンバーに渡す」といった点です。連続で折り紙を折れないのはあきらかに障害となるため、どのように対処するかはチームごとの色が出ます。 またこれらの制限事項以外に、次の制約があります。 紙飛行機は常識の範囲内の形状をしていること紙飛行機には人が乗っているものと意識すること 要するに、雑な作りで投げまくるのはやめたまえ、ということです。ソフトウェア開発者はすぐバグを見つけたがる……。 禁止事項 基本的には参加者は大人なので不要だとは考えましたが、一応禁止事項を用意しました。 ひとつめは検索の禁止です。開発者の強い味方であるインターネットの力は今回封印させていただきました。最初のスプリントは検索に費やして、残りで巻き返す、みたいなことはできません。 ふたつめは床や机に傷をつけないです。要するにA4を４つ切りにするために、紙を手に持ったまま切ってくれれば問題ありません。これは何らかの作戦を防ぎたいというわけではなく、あとで責任者の自分が怒られないように用意したものです。 準備するもの 紙飛行機を飛ばすことになるので準備物はそれなりにあります。 ハサミ（１チームにつきひとつ）ペン（１チームにつきひとつ）A4用紙（１チームにつき６０枚程度）マスキングテープメジャー マスキングテープやメジャーは飛行試験場を作るのに使います。 設備 設備に関しては基本的な会議室であれば問題ないです。 どちらかといえば、紙飛行機を飛ばす関係上、ある程度の広さが必要です。少なくとも３メートルの飛行場を作成できる広さとチーム数に応じて作業場を確保する必要があります。 私たちがどれくらいの広さを用意したかがわかる写真を載せておきます。 用意した会議室 テーブルはチームごとに用意してあります。椅子に関しては飛行試験の際などに邪魔になったりしそうなので撤去しています。 飛行場は写真の右手側、ジュリアン・オピー氏のアートの前です。写真だと狭く見えますが、別角度でもう一枚。 会議室を別角度から ３メートルの長さに加えて、ふたりが飛行試験をしてもぶつからない程度の広さを確保しています。 参加者 人数に関しては１チームにつき３・４名で、２チーム以上と用意できると競い合いになって盛り上がるでしょう。但し、前述のとおり、チーム数に応じて広さが求められるので、キャパシティには注意してください。 今回も前回と同様デヴェロッパータスクフォースのメンバーとシステム本部の若手に参加してもらいました。実はピンポンゲームを行った直後に紙飛行機ワークショップを実施したので、参加者は継続です。 ワークショップ解説 紙飛行機ワークショップもほかのワークショップと同じように、最初に参加者に趣旨やルールを説明します。 ワークの流れを開設する ワークショップでは次のスプリントを繰り返します。 計画をする（２分）成功機体の予想発表（１分×チーム数）※実行（３分）実績発表（１分×チーム数）※振り返り（２分）振り返り発表（１分×チーム数）※ ※マークのついた項目はチームそれぞれの状況を確認するための時間です。 今回のワークショップではこのスプリントを４回繰り返しました。バランス的にもちょうどいい回数だったと考えます。 各フェーズを詳しく確認していきましょう。 計画をする（２分） まず最初に、このスプリントの計画をします。 ハサミとA4用紙を前に議論 紙飛行機はひとりが連続で折れないという制約があるので、効率的に紙飛行機を作る方法を考える必要があります。また、それと同時に３メートル飛ぶという品質も担保しなくてはいけないので、ここでの計画は重要です。やみくもに作業をしてもうまくいかないのは目に見えています。 とはいえ、計画の時間は２分しかないため、議論が白熱しすぎるとまったく計画が決まらないまま終わってしまうこともあります。タイムボックスは重要な要素なので、たとえ議論が終わらなかったとしても慈悲はありません。次のフェーズに移行します。 成功機体の予想発表（１分×チーム数） 計画にしたがったら、チームごとにどれくらい３メートル飛ぶ飛行機を作れるか予想します。 スコア予測 初回に関しては予想の材料がないため適当になってしまいますが、２回目以降は実績に基づいて予想できます。 ちなみにチームは「NKHT」チームと「Internet for Everyone」チームです。 NKHTチーム NKHTチーム（以下NKHT）の由来はメンバの頭文字だと思います（もう１年以上前なのでうる覚え）。 Internet for Everyoneチーム Internet for Everyoneチーム（以下I4E）は前回からも続投（メンバは何人か違う）のコーポレートキャッチですね。 このタイミングで各チームの作戦についても聞いておきます。ここで作戦を聞いておく理由は、改めて認識させるというよりも、ワークショップ全体の振り返りをする際の材料にするためです。 実行（３分） 各チームが計画したことを実行します。制限時間は３分です。 計画の実行 いくつかの制限事項がありますが、実際のところ、厳密には監視をしていないので紳士協定です。みなさん大人ですからそれぐらいのゆるさでも大丈夫です。 できた紙飛行機は飛行試験場で試験飛行されます。 最高にフォームがきれいなIさん 紙飛行機を飛ばすのにもある程度のスキルが必要なので、チームの戦略によってはパイロット専任が誕生することもあります。 また紙飛行機を作って飛ばす以外にも、チームには重要なタスクがあります。それは、紙飛行機のカウントです。 紙飛行機のカウント このあと実績発表をするので、各チームは紙飛行機を作成した数と３メートル以上飛んだ数をカウントします。実はこのタスクは煩雑になりやすいので、チームごとに戦略が異なります。 実績発表（１分×チーム数） 実行の結果をチームごとに発表します。 実績を発表する 作成した数と試験飛行に成功した数を記録するので、効率に課題があるのか、品質に課題があるのかが一目瞭然です。 振り返り（２分） 実行や実績を受けて、各チームで振り返りをします。とはいえ、２分しかないため、KPTといったフレームワークではなく、今回のスプリントでの良かった点と問題点を共有しあう程度です。 振り返りの様子 振り返り発表（１分×チーム数） 各チームごとに振り返りの内容を発表してもらいます。ここでの発表も、作戦を聞くときと同じく、定点観測の意味を込めたものです。 既定の回数くり返す 規定回数スプリントをくり返します。最初のスプリントに比べると後半は動きやテクニックが洗練されていきます。 イベント ただ同じことを繰り返すのではそれこそルーチンワークのようになってしまいます。スクラム、ひいてはアジャイル開発は不確実なものをいかに御しながら価値を届けるかが主目的です。紙飛行機ワークショップでは不確実性をイベントで演出します。 具体的には３スプリント目で「制限事項をひとつ廃止できる」というイベントを発生させます。つまり、次のうちいずれかを無視できるということです。 A4の紙を４つに切って使う紙飛行機の先端はハサミで丸くする一度折ったらほかのメンバーに渡す（連続で折らない）紙飛行機を飛ばすのは１回につき１機（まとめて飛ばさない）紙飛行機を飛ばすのは１機につき１回（同じ飛行機を何度も投げない）各スプリント終了時に作成物はすべて破棄する どの制限事項を廃止できるのはチームで決めます。チームごとに特色がでて面白い部分ですね。 またこのイベントは１スプリントだけで、次のスプリントではもとに戻すのですが、そのことについては次のスプリントが始まるまで黙っておくとよいです。振り返りした内容が次のスプリントでは使えなくなるといった不確実性を演出できます。 ワークショップ全体の振り返り すべての行程が終わったらワークショップ全体を振り返り、総括します。 総括の様子 スプリントごとに各チームの計画や試行錯誤について振り返ると、改善の片りんを感じたり、このワークショップを通して学べたことを再確認できます。 ワークショップレポート ここからは開催したワークショップのレポートです。 最終スコア まずは結果を見てみましょう。 最終スコア 画像の「予」は予想を表し、「実（成／生）」は実績を表し、そのうち分母が生産機体数、分子が試験飛行成功数になっています。 結果を確認すると、いずれのチームも最初の数値が２回目３回目でだんだんと増加しているのがわかります。これは振り返りを行い、それを受けて計画をしているため、だんだんと改善されて行っている結果です。 同時に４スプリント目では数値が小さくなっているのにも気づきます。これは３スプリント目では制限事項をひとつ解除したのが、４スプリント目で復活した結果です。 生産機体数と試験飛行成功数の比率を見ると、チームごとの作戦が透けて見えますね。人が乗ってるという前提をI4Eはどう捉えていたのかは気になるところです。 各チームの流れ チームごとに各スプリントの計画や振り返り発表のメモがあったので、ここにまとめます。 NKHT まずは優等生が集うNKHTからです。 １スプリント 予測成功数５、実績３／４ ■計画 最初の１分は紙飛行機の作成に集中する役割をわける（切る人１、紙飛行機を折る２人、声出し（？）兼パイロット１）感覚値で５機はいけそう ■振り返り 飛行成功機体が３機だったので作戦はよかった ２スプリント 予測成功数５、実績５／７ ■計画 前回振り返りから基本は継続予定精度をあげたい ■振り返り 飛行成功数が伸びているし、精度も大きく落ちていないのでいい感じ ３スプリント 予測成功数１０、実績６／１３ ■計画 撤廃するルールは「一度折ったらほかのメンバーに渡す（連続で折らない）」 ■振り返り ルールが変わった結果、これまで折ったことがない二人が飛行機を折った初めて紙飛行機を折ったため手間取り、あまり生産数が伸びなかった ４スプリント 予測成功数８、実績９／１１ ■計画 ２スプリント目と同じ作戦に戻る ■振り返り 折り合いが熟練の動きだった熟練二人が折った紙飛行機は９機で失敗ゼロはじめて折り紙を折った二人は両方３メートル飛ばなかった 総評 スプリントを重ねるごとに着実に改善されていったチームでした。 役割分けが功を奏し、はじめから最後まで高品質な紙飛行機を生産し続けていました。特に後半、紙飛行機をずっと折っていた熟練工二人はまったく失敗なしで、時間があまったので初めて折った二人はひとつもテスト飛行が成功しないというエピソードは面白いです。ただ、スクラム的には、スキルレベルにばらつきがあると見積もりが難しくなるので、そういった点では課題はまだ存在します。 I4E 次は問題児独創的なアイデアマンが多いI4Eです。 １スプリント 予測成功数２、実績０／４ ■計画 正攻法で回す手渡し手渡しで紙飛行機を折っていく ■振り返り 毎回毎回回ってくる紙飛行機の状態が違う（折り方が変わる）綺麗に４等分した紙飛行機は３メートル飛ばない説 ２スプリント 予測成功数２、実績１／１４ ■計画 ４つに切って３つ捨てる（←？） ■振り返り コツがつかめたので次からはドライブしそう ３スプリント 予測成功数４、実績６／１１ ■計画 撤廃するルールは「A4の紙を４つに切って使う」 ■振り返り フローが減った結果、飛行機の形が同期できた ４スプリント 予測成功数４、実績５／３３ ■計画 A4用紙の端を縦に切って３つに切る（←？） ■振り返り ごみ捨て係ができた（←？）最後はみんなでごみ捨て 総評 質より量を選んだチームです。２スプリント目からあきらかに飛行機の生産数がおかしなことになっています。 紙飛行機作成風景も独特です。 紙飛行機作成風景？ 極めつけは４スプリント目では４枚に切って、３枚を捨てるという暴挙。作成した機体数３３というのは、８機はちゃんと追って、残りの２５機は紙飛行機の形を成していない切れ端ということです。最後のスプリントは２５機を捨てるテスト飛行するため、全員でぐるぐる机の周りを走り回ってきたのが印象的でした。 ……おかしいなぁ。「人が乗ってるつもりで飛ばしましょう」と伝えたんだけどなぁ……。 所感 このワークショップで学べることは次のとおりです。 タイムボックスベロシティプロセスの改善 各フェーズにおける制限時間を厳密にすることで、タイムボックスを守ることを体験できます。タイムボックスを意識しないと、特にミーティングなどはダラダラしてしまったり、関係のないメンバのリソースを奪うことになるのでとても大事なことです。 ベロシティは紙飛行機の数です。予測と実績を都度確認することで、ベロシティとしますが、本格的なスクラムからすると、ふわっとしたものなので、正直なところワークショップの肝ではありませんでした。 改善に関してはスプリントが進むごとに試行錯誤があってよいです。突発的な制限事項減少イベントにどのように対応するのか、その制限事項が復活したらどのように対応するのか、といった臨機応変な対応はまさに不確実性と向き合うものです。 このワークショップだけでスクラムを始めるには力不足です。本ワークショップの位置づけとして最適なのは本格的なワークショップの準備として実施するのがよいかと考えます。 本格的なワークショップは長時間に及ぶため、失敗したくないものです。本ワークショップでタイムボックスなどの基礎的な部分を経験しておくのは、前準備としてとても有効に働くでしょう。 おわりに 本ワークショップはピンポンゲームと同じく短時間で実施できます。したがって、ピンポンゲームと同じように新たなメンバーが加入した時などにレクリエーションとして実施してみても面白いです。 みなさんもぜひ童心にかえって、紙飛行機を折ってみませんか。 Vol1. スクラムワークショップ Vol.1 レゴ®編Vol2. スクラムワークショップ Vol.2 マインクラフト編Vol3. スクラムワークショップ Vol.3 ピンポンゲーム編Vol4. ｲﾏｺｺ

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第３回のテーマはピンポン玉を使ったスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/3750/ https://developers.gmo.jp/5571/ ▻Vol.03_ｲﾏｺｺ https://developers.gmo.jp/10479/ https://developers.gmo.jp/13055/ はじめに みなさんこんにちは。成瀬（@nrslib）です。 前回はマインクラフトを使ったオンラインのスクラムワークショップについてお話しました。リモートワークなどでメンバーが遠隔地で分散されているチームがスクラムを学び始めるのに適したワークショップでしたね。 今回は時系列が前後しますが、レゴやマインクラフトを使った手の込んだワークショップを実施する前に、より簡易的なスクラムワークショップを実施したのでそちらをご紹介します。（ワークショップは2020年11月に実施したものです） 今回の題材は「ピンポン玉」です。 手軽にスクラムを体験したい スクラムは、見聞きした情報だけで実践するのは難しいです。各種スクラムイベントには一定の正解があるわけではなく、確固たる目的意識がないと趣旨を見失いやすいからです。 OJTと称して、実践しながら学ぶのもお勧めできません。多くのスクラムイベントは大抵１スプリントにつき１回です。スプリントは１週間や２週間といった期間になるため、それぞれがどういったもので、どういった立ち位置かを学ぶまで長い時間がかかってしまいます。 スクラムは百聞は一見に如かずという言葉が似合います。言うは易く行うは難しでもよいでしょう。座学で学ぶよりも、経験をしたほうが圧倒的に早く理解が進みます。そのため、ワークショップを実施するのがスクラムの理解や導入に役に立ちます。 本連載で紹介してきたレゴスクラムやマインクラフトスクラムはスクラムの理解や導入に最適ですが、その内容はとても重厚なワークショップです。レゴやマインクラフトなどの初期費用を無視したとしても、準備にかかるコストが高く、ワークショップを気軽に実施してみたい場合にはふさわしくありません。 私たちもスクラムのワークショップをするにあたって、どの題材がいいか調査しました。結果、「最初からレゴスクラムするのは得策でない」として、いくつか別の題材で実施してから、本格的なスクラムワークショップをすることにしました。 というわけで一番最初に実施することにしたスクラムワークショップのテーマは…… ピンポン玉です。 ピンポンゲームスクラム ピンポンゲームはピンポン玉を使った簡単なゲームです。そのピンポンゲームを題材にスクラムを体験するワークショップがピンポンゲームスクラムです。 ゲーム自体が単純なので、実施するのが難しくないワークショップです。 ワークショップ概要 ピンポンゲームはピンポン玉にメンバーが触れた数をスコアとするゲームです。ピンポン玉に触れるといっても、ただ触れればよいのではなく、ルールがあります。ルールは次の通りです。 チームメンバー全員が触れるボールは宙に浮かせて受け渡す それほど難しくないですね。これらのルールにしたがって、一定時間のうちにどれだけスコアを稼げたかを競うゲームです。 なお、私たちの実施したワークショップでは、これらのルールに加えて、次のルールを加えました。 最終的にピンポン玉をゴール（バッグ）に入れる 要するに「全員が手渡し以外でピンポン玉に空中で触れながらバッグに入れたら１点」です。 準備するもの ワークショップを実施するにあたって準備するものは次のとおりです。 ピンポン玉（１チームにつき１００個）バッグ・袋（１チームにつき２個） シンプルです。ピンポン玉の金額はピンキリですが、１セットにつき2,000円程度と思っておけばよいです。 バッグ・袋はピンポン玉が１００個入るサイズです。ピンポン玉に付属しているのであれば、もうひとつ大きめのバッグを用意するとよいでしょう。 設備 特別必要なものはありません。床さえあれば実施できます。 とはいえ、あるとベターといったレベルで設備を挙げるなら次のリストになります。 ホワイトボードプロジェクタ ホワイトボードはスコアの予測と結果を記入するために利用します。 プロジェクタはルール説明用資料投影とタイマーの表示に利用します。 参加者 ワークショップに欠かせないのが参加者です。このワークショップは予備知識が不要なので、だれでも参加できます。１チームにつき少なくとも３名程度が必要です。 今回はデヴェロッパータスクフォース（技術研究チーム、以下DTF）のメンバーと、システム本部の若手に参加してもらって実施しました。 ピンポンゲームに馳せ参じたメンバー ワークショップ解説 ワークショップを実施する際には、参加者に趣旨やルールを事前に説明します。 ワークショップは次のスプリントを繰り返します。 戦略を考え、スコアを見積もる（60秒）実行（120秒）スコアを計測・片付け（60秒）振り返り（60秒） 今回、私たちは５回実行しました。最低３回こなせば十分かと考えます。 なお、今回のピンポンゲームのスクラムワークショップはDTFメンバーの中川くんが企画してくれたので、彼が趣旨やルールを説明してくれました（成瀬は一般参加枠です）。 趣旨を説明する 戦略を考え、スコアを見積もる（60秒） ひとつのスプリントで最初にやることは、戦略を考えることです。 ピンポン玉片手に真剣に戦略会議を行う参加者 120秒という制限時間の中で、できるだけ多くピンポン玉を運べる方法について、メンバーで話し合い戦略を決定します。 戦略が決まったら、チームごとにどれくらいのスコアになるか予測をします。 それぞれのチームの予測 成瀬が所属した「Team Japan」は強気の120個予測です。実際、このときは完璧な作戦を考案したとメンバー全員が思っていました。 ちなみに100個すべて移し終わったら、元のバッグへ移していきます。バッグからバッグへ往復していくイメージですね。 実行（120秒） 実際に考えた戦略を制限時間の間、実行します。 「世界の高道」チームの初回実行の様子 「Team Japan」の初回実行の様子 画像でみるとそれぞれのチームの戦略の違いがみえますね。 なお、このとき、いくつまでスコアが伸びたのか把握する必要があります。ピンポン玉が足りなくなり、リユースする場合には正しくスコアリングするように注意しましょう。 スコアを計測・片付け（60秒） 実行が終了したらスコアを計測し、元に戻します。 片付けの様子 急いだり、作戦次第ではピンポン玉が床に散らばっていきます。このタイミングで元に戻して次のスプリントに備えましょう。 今回はバッグに移すと１点というルールがあるため、落としてしまったピンポン玉は加算しないようにしてスコアリングしていきました。 「Team Japan」は97個 我らが「Team Japan」の初回実行では、予測120個に対して97個と、かなり予測を外してしまいました。 「世界の高道」チームは80個 それに対して「世界の高道」チームは80個予測に対して実績80個と予測通りの結果でした。素晴らしいですね。初めて行う作業の見積もり予測は難しく、ほとんどの場合は正確でないので、かなり珍しいケースです。 振り返り（60秒） スプリントの最後には振り返りをします。 振り返りの様子 今回の実行でよかったこと、よくなかったことを短い時間で振り返りましょう。 私たち「Team Japan」も初回の戦略が最強に思えたのですが、実際にやってみると改善点が見つかって、どんどん戦略が変わっていきました。 既定の回数繰り返す これらの一連の流れを最初に決めた規定回数に達するまでくり返し実施します。 振り返りの実施 ワークショップが終わったら、ワークショップ自体の振り返りをしましょう。各チームがそれぞれの回でどのような戦略を立て、変化させていったかについて披露します。 振り返りの様子 このワークショップはスクラムよりも改善活動の重要性を体験するものなので、その点留意しながらしっかりと予測と作戦、振り返りの重要性を確認します。 ワークショップレポート すでに初回分についてはワークショップの解説の流れで紹介しましたので最終的な結果からワークショップのレポートをします。 最終スコア 各チームの最終的なスコアは次のようになりました。 最終的なスコア いずれのチームも初回以外はスコアを飛躍的に伸ばし、また安定しています。特に「世界の高道」のスコアは驚異的です。 このようにくり返し改善していくことで、同じ作業であっても効率が高くなっていくのがよくわかりますね。 ただ予測の精度はあまり向上しませんでした。これはどちらかというと、戦略を毎回変えていったため、「常に初めての戦略」をすることになったため、スコアが安定しなかったのだと考えます。 各チームの戦略 「世界の高道」チームの最終実行 「Team Japan」の最終実行 両チームとも最終戦略はピンポン玉を受け渡すというより、ピンポン玉を手に当ててバッグに流し込むという戦略です。奇しくも同じ戦略にたどり着いたようです。 こうなってくると大変なのは、正確なスコアリングです。もはや成功した数を数えるのではなく、落とした数を数えてたりします。実はこのスコアリングにも改善の力が働いていたのです。 所感 最初の戦略を練った時点で「最強の戦略」が生み出せたと思っていました。そのため、５回は多すぎると思っていました。これはほかの参加者も同じことを思っていたようです。 しかし、実際にやってみると改善できることは尽きることなく、それはそのままスコアに反映されていきました。 このように振り返りをすることで、各メンバーが実行中に感じた課題が共有でき、次の戦略に生かされるといったループが発生します。このカイゼンループは一度は体験しておくべきものでしょう。 反対に、本格的なスクラムを体験したい場合はこのワークショップは適していないと感じます。スクラムを体験するにはパーツを省きすぎているからです。 本ワークショップの立ち位置としては本格的なスクラムのワークショップを実施する前にコミュニケーションもかねて実施する試験的なワークショップの位置づけがよいのではないかと考えます。 おわりに 本ワークショップは正味１時間もあれば実施できます。かなり軽量なワークショップで気軽に開催できます。 チームに新たなメンバーが加入したときなど、オンボーディングをスムーズにする目的でもお使いいただけるのではないでしょうか。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第2回のテーマはマインクラフトを使ったオンラインでできるスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/3750/ ▻Vol.02_ｲﾏｺｺ https://developers.gmo.jp/5571/ https://developers.gmo.jp/10479/ https://developers.gmo.jp/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/5571/ https://developers.gmo.jp/10479/ https://developers.gmo.jp/13055/