LeSS形式で大規模スクラムを体感！「マシュマロチャレンジ」ワークショップ実施レポート

はじめに

こんにちは！BIPROGY株式会社の23卒エンジニアの千葉です。

わたしは、スクラムによるプロダクト開発チームに所属する傍ら、弊社における組織全体のアジャイル・スクラムに関する理解の促進と、コミュニティ形成を通じた組織学習への貢献を目指し、「スクラム交流会」と呼ばれるコミュニティの運営に携わっています。

先日、そのスクラム交流会の一環として「マシュマロチャレンジ」ワークショップを企画・開催しました。スクラムのプロセスに沿ったアレンジを加えることで、スクラムの基本概念を参加者が「体験」を通じて深く理解できるように工夫しました。今回はその実施概要と、参加する中で得た学びや気づきを皆さんにご紹介します。

スクラムについて興味関心のある方や、スクラムコミュニティの運営活動を行っている方のご参考になれば幸いです。

1. 概要とねらい：マシュマロチャレンジとは？

マシュマロチャレンジは、乾燥パスタ、テープ、紐、マシュマロという限られた材料で、自立可能な最も高いタワーをチームで協力して構築するワークショップです。通常は、チームビルディングを目的として実施されます。

スクラム交流会では、コミュニティ形成のためのアイスブレークとしてはもちろんのこと、アジャイル・スクラムに関する理解の促進も目的としています。そのため、マシュマロチャレンジを大規模スクラム開発のLeSSのプロセスに沿ってアレンジすることで、以下のようなスクラムの概念を実践的に学べるよう工夫しました。

🎯経験主義（透明性、検査、適応）の体感

短いスプリントを繰り返し、成果物（タワー）とプロセスを可視化し（透明性）、定期的に評価し（検査）、その結果に基づいて柔軟に調整する（適応）サイクルを実践する

🎯自己組織化とクロスファンクショナルな協調

チームが共通目標に向け自律的に計画を立て、互いの知識やスキルを活かして協力する

🎯効果的なコミュニケーション

複雑な問題解決や不確実性への対応において、チーム内、チーム間、そしてステークホルダーとの継続的でオープンなコミュニケーションの重要性を体感する

🎯価値提供とフィードバックの活用

ステークホルダーへ提供する価値の最大化に焦点を当て、レビューで得られるフィードバックを次の開発に活かす重要性を実感する

🎯継続的な改善

不完全な情報から開始し、スプリントのリズムの中で試行錯誤と学習を繰り返しながら、より良い解決策へと進歩させていくプロセスを体験する

2. 今回の取り組み：LeSS形式のアレンジ

今回実施したワークショップでは、「マシュマロチャレンジ」に以下のようなアレンジを加えました。

🪄チーム構成

通常のマシュマロチャレンジでは、4人1チームに分かれ、各チームがそれぞれのタワーを作成しますが、今回のワークでは下記のように2つのチームが連携し、共同で1つのタワーを完成させる形式を採用しました。

具体的な構成は下記のとおりです。

• ステークホルダー 1名（マシュマロタワーの買い手、司会進行役が担当）
• プロダクトチーム（マシュマロタワーを建設するチーム）
  • プロダクトオーナー 1名（建設の方向性を決める人）
  • 開発チームA 4名（実際に建設するチーム）
  • 開発チームB 4名（同上）

これにより、大規模スクラム開発におけるチーム間のコラボレーションを体験できます。
今回は人数の都合で実施しませんでしたが、プロダクトチームを複数作成し、プロダクトチーム間で競争することで、より競技性を生むこともできます。

🪄作業目標

通常のマシュマロチャレンジは「できるだけ高いタワー」を目指しますが、今回は「よりステークホルダーを満足させるタワーを作ること」を目的としました。

これにより、実際のソフトウェア開発に体験を近づけます。ステークホルダーが何を求めているか（高さ、耐震性、芸術性など）を知る必要があり、レビューの中で新たな要求に気づくこともあります。

🪄タイムボックスとスプリント

1スプリント25分というタイムボックスの中で、3回のスプリント（プランニング・作業・レビュー・レトロスペクティブの繰り返し）を実施しました。
内訳は以下の通りです。

• プランニング（5分）
  • プロダクトチーム全体でPBIを選定する
  • 各開発チームの担当するPBIを決定する
  • 開発チームに分かれてSBIを作成する
• 作業（12分）
  • スプリントバックログに基づき開発チームがタワーを建設する
• レビュー（5分）
  • プロダクトチームはステークホルダーに建設したタワーを披露し、フィードバックをもらう
• レトロスペクティブ（3分）
  • プロセスについて振り返る

3. ワークの実施風景

スプリント1の様子

バランスを崩して倒れるタワー。三角柱を積み重ねる方式は難しそうだ。

スプリント2の様子

ステークホルダーからレビューを受けている様子。ペットボトルを超える高さは欲しい。

上下を分解してほしいという要求に応える様子。分解可能性を考慮していなかったタワーはボロボロに。

スプリント3の様子

ステークホルダーにタワーをプレゼンする様子。特徴的なアンテナはタワーの高さと魅力価値を両立させる。

上下を分解してほしいという要求に応える様子。頑丈な構造に変わり、分解・再構築しても壊れない。

---

3スプリントを経て、失敗を繰り返しながらも最終的にステークホルダーの期待に沿ったマシュマロタワーを建てることができました。これは、参加者全員の協力と、スクラムのプロセスに沿った継続的な改善の結果であると言えます。

4. ワークから得られた学びと気づき

ワークの最後に参加者の皆様と振り返りを行いました。スクラムの重要な原則と実践に関する多くの学びと気づきが得られたことがわかりました。下記に皆様から挙がった声をまとめます。

✅計画と適応の重要性

初期の計画だけでは不十分であり、スプリントを繰り返すごとに仮説と検証を行い、失敗や経験から学んで戦略をブラッシュアップしていくことの有効性を強く感じました。
ワーク開始当初の「右も左もわからない状態で立てた計画」と比較し、レビューと振り返りを経て改善された計画のほうが、はるかに高い精度と実現可能性を持つことが明確になりました。

✅要求の変化への対応

各スプリントのレビュー時、「上下分解してほしい」「耐震性が欲しい」といった、事前に伝えられていなかった新たな要求が出てきました。
これは、実際のソフトウェア開発において、開発の進行とともに顧客の要求が具体化したり変化したりする状況を非常によく表しており、継続的なレビューと顧客との対話が、最終的な成果物の品質向上にどれほど重要であるかを体感する機会となりました。

✅協調とコミュニケーションの価値

◽完成イメージの共有

プランニングの段階で、各グループ間で完成イメージを共有することの重要性が再認識されました。口頭や文章のみでは認識のズレが生じやすく、図を用いることでメンバー間の認識が揃い、スムーズに作業を進められることが分かりました。

◽チーム間コミュニケーションの頻度と質

ワーク中は、チーム間のコミュニケーションを「小さく細かく頻繁に」行うことの重要性が実感されました。これにより、問題発生時の早期発見・解決、ノウハウやリソースの効率的な共有が可能となりました。

◽LeSS形式における連携

隣のグループの様子を見に行ったり、積極的にコミュニケーションをとってノウハウやリソースを共有し合ったりと、ワークを進めるために自然とグループ間の連携が生まれました。これは、大規模な開発プロジェクトにおいて、複数の開発チームが協調し、共通の目標に向かって協力することの重要性を示唆しています。
同時に、「作業に集中しすぎるとチーム間の協業という観点が見失われがちになる」という貴重な気づきも得られました。これはLeSSに限らず、DevOpsチームとビジネスチーム間の連携など、普段の業務における異なる部門間の連携においても同様の課題が存在し、常にコミュニケーションパスを確保することの重要性を示唆しています。

✅継続的改善の有効性

スプリントレビューで得られた指摘をもとに修正を行い、ふりかえりのプロセスを通じて、タワーの構造や作業プロセスを継続的に改善していく体験は、参加者にとって大きな学びとなりました。
一度で完璧な状態を目指すのではなく、不完全ながらもレビュー可能な状態にし、早い段階でフィードバックを受け、得た学びを次の計画に反映させるといった、学びのサイクルを高速で回してより良い結果に繋げていく継続的改善の効果を実感できました。

5. 運営としての所感

運営として参加する上でも、下記のような様々な学びを得ることができました。

• 右も左も分からない状態で策定した計画が、仮説と検証、そして継続的な改善を通じて精度が高まっていく過程や、レビューを通じて事前に想定していなかった要求が出てくる点は、まさにスクラムを用いたソフトウェア開発のメタファーそのものであり、興味深いものでした
• 隣のチームと自発的に連携を取り、ノウハウやリソースを共有し合う姿は、スクラムが目指す自律的なチームと組織横断的な協調性を垣間見せるものでした
• ワークを進める上で自然と取っていた行動が、普段の業務で発揮できていたかという視点で振り返ると、自身の行動を顧みる良い機会となりました
• オフライン開催が参加者の積極性や一体感を高める上で有効であることを再認識できました

おわりに

今回のスクラム交流会では、スクラムの重要な原則である「経験主義」「継続的なコミュニケーション」「ふりかえりによる改善」を、LeSS形式での大規模スクラムのコラボレーションを交えながら実践的に体感できました。

この経験を通じて得た知見を、社内だけでなく、広くアジャイル・スクラムに関心を持つ皆さんと共有し、コミュニティ全体の学習と発展に貢献していきたいと考えています。今回の記事が、皆さんのスクラム実践のヒントや、新たなワークショップ企画のきっかけとなれば幸いです。

参考文献

• マシュマロチャレンジ
  • TED Global「トム・ウージェック：マシュマロ・チャレンジから学べること」
    • https://www.ted.com/talks/tom_wujec_build_a_tower_build_a_team?language=ja
  • 日本マシュマロチャレンジ協会
    • http://www.marshmallow-challenge-japan.org/
• LeSS (Large-Scale Scrum)
  • LeSS 公式ウェブサイト
    • https://less.works/?preferred_lang=jp
• スクラム
  • スクラムガイド (The Scrum Guide) 日本語版
    • https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

We Are Hiring!