コイン渡しゲームで学ぶ、スクラムにおけるフロー効率と小さな単位の価値

はじめに

こんにちは。KDDIアジャイル開発センター株式会社（KAG）の金子です。

この記事では、私たちのチームで実施した「コイン渡しゲーム」を通して、スクラムにおける フロー効率 や 小さな単位で価値を流す重要性 を振り返ります。

ゲームの元ネタは、以下の書籍を参考にしています：

コイン渡しゲームとは？

ゲームの内容

• コイン（または代替のもの）をバケツリレーのように、次々に渡し、完了までの時間を測る
• 20枚 → 5枚 → 1枚 と、一度に渡す量（バッチサイズ）を変えて比較する

観察できるポイント

• バッチサイズが大きいほどリードタイムが長くなる
• 最初の1枚（＝価値）が相手に届くまでの時間が遅くなる

学べる本質

• 「小さく流すほうが速い・詰まらない・早く気づける」

なぜチームでこのゲームをやるのか

• 「なぜ大きい作業が遅くなるのか」を体感で理解するため
• 理屈ではなく「腹落ち」した状態でエピック / PBI の分割に取り組むため
• スクラムの「小さく価値を届ける」という原則を、体験として理解するため

コイン渡しゲームのやり方

1. 準備するもの

• ホワイトボード
• コインまたは代替のもの
• タイマー
• 付箋とペン

＊今回はリモートで実施しましたが、オフラインでも同様にできます。
　このようなホワイトボードとコインを用意しました：

2. ゲームの進行（3ラウンド）

1. 20枚まとめて渡す
2. 5枚まとめて渡す
3. 1枚ずつ渡す

※ オンラインホワイトボードでは「複数コインの同時選択はNG」と事前に共有しました（笑）

各ラウンドで以下を記録します：

• 全部のコインが届いた時間
• 1枚目のコインが届いた時間
• 各担当者が作業していた時間

コイン渡しゲーム結果

以下は今回の測定結果です。

項目	20枚まとめ	5枚まとめ	1枚ずつ
全部のコインが届いた時間（秒）	148	60	51
1枚目のコインが届いた時間（秒）	122	27	17
A さん	42	39	43
B さん	27	36	41
C さん	37	36	38
D さん	27	34	33

チームの気づき

以下の問いをもとに、チームメンバーに気づきを書き出してもらいました。

投げかけた問い

1. なぜ20枚（大きいバッチ）は遅くなったと思いますか？
2. なぜ1枚ずつ（小さいバッチ）は速くなったと思いますか？
3. 私たちの開発フローの中で、このゲームと“同じ構造”はどこにありますか？

メンバーの気付き（代表的なもの）

1. 大きなバッチは、前の人が終わるまで次の人が動けず「待ち」が多発した
2. 実装やレビューが重くなり、着手できない時間が増えた
3. 一度に大量の作業を抱えると、どこで詰まっているか気づきにくかった
4. 小さいバッチは常に誰かが動いていて、流れが止まらなかった
5. 小さい単位だと問題にすぐ気づけ、手戻りの影響が小さくなった
6. 大きく作りすぎるとレビュー開始が遅れ、レビュー時間も長くなった
7. 進捗が見えない時間が増え、心理的にも「遅れている感」が強くなった
8. 小さい単位のほうが、周囲への影響が小さく全体がスムーズだった
9. 設計 → 実装 → レビューの流れの中にも同じ「詰まり」があると気づいた
10. サブタスクレベルへの細分化がフローを良くし、全体を軽くすると感じた

さいごに

コイン渡しゲームを通して、ソフトウェア開発における 「バッチサイズの大きさ」と「流れの良さ（フロー効率）」 が密接に関係していることがあらためて確認できました。

大きな作業は

• 完了が遅れやすく
• 問題が見えにくく
• レビューが重くなり
• チーム全体の進みが鈍る

という状態を引き起こします。

これはスクラムが重視する透明性（見える化）・検査（早期フィードバック）・適応（小さく改善） が働きにくい状態です。

一方で、小さく分けて作業を流すと

• 最初の価値が早く届き
• フィードバックの返りが早く
• 問題がすぐに見え
• レビューも軽くなる

といった “フローの良さ” が生まれます。

今回扱ったコイン渡しゲームは、こうしたスクラムの原則を「体験として理解する」ための学習ツールだと感じています。小さく価値を流し、問題を早く見つけて改善していく。その本質の一端を、このゲームが教えてくれます。