あなたのチームは、何のゲームをしているのか
1986年、哲学者James P. Carseは一冊の薄い本を出版しました。タイトルは Finite and Infinite Games（有限と無限のゲーム）。 ゲーム理論でも経営学でもなく、純粋な哲学書です。 しかしその核心にある問いは、30年以上を経た今もソフトウェア開発の現場に鋭く刺さります。
「有限ゲームは勝つためにプレイされる。無限ゲームは続けるためにプレイされる。」— James P. Carse
ウォーターフォールとAgile。この二つの開発手法を比較する記事は山ほどあります。 しかしほとんどは「効率」や「柔軟性」の話に終始します。 Carseの視点を借りると、この問いはもっと根本的なところに届きます—— あなたのプロジェクトは、どちらのゲームをしているのか、と。
二つのゲームの基本ルール
Carseの定義は驚くほどシンプルです。
| 有限ゲーム | 無限ゲーム |
|---|---|
| 終わりがある | 終わりがない（続けることが目的） |
| 固定されたルールの中でプレイする | ルール自体を変えながらプレイする |
| 勝者と敗者がいる | 勝敗がない（参加し続けることが目標） |
| サプライズは敵（予測・制御が重要） | サプライズを歓迎する（変化が糧になる） |
| 例：チェス、野球、受験 | 例：文化、芸術、友情 |
この二軸で、ウォーターフォールとAgileを見てみましょう。
ウォーターフォールは「完璧な有限ゲーム」だった
ウォーターフォール開発の構造を思い出してください。 要件定義 → 設計 → 実装 → テスト → リリース。 明確なフェーズがあり、各フェーズに成果物があり、 プロジェクトには「完了」というゴールがあります。
これはCarseの「有限ゲーム」の定義に、ほぼ完璧に合致します。
- 終わりがある：リリース日という「ゲームオーバー」が存在する
- 固定されたルール：要件定義書が最初から最後まで「法律」として機能する
- 勝敗がある：スコープ・コスト・スケジュールの三角形を守れたかで評価される
- サプライズを排除：変更管理プロセスが仕様変更（＝サプライズ）を「敵」として扱う
ウォーターフォールが本来の力を発揮するのは、プロジェクトが本当に有限ゲームであるときです。 インフラ移行、規制対応のシステム刷新、打ち上げたら変更できない組み込みソフトウェア——。 ゴールが明確で、変化が少なく、「完了」が本当に存在するプロジェクト。 そこではウォーターフォールは強力な武器になります。
Agileは「無限ゲームのフレームワーク」として設計された
2001年のAgileマニフェストを、Carseのレンズで読み直してみてください。
「包括的なドキュメントよりも動くソフトウェアを。」
「契約交渉よりも顧客との協調を。」
「計画に従うことよりも変化への対応を。」
これは「有限ゲームのルールを手放す」という宣言です。 固定された要件書（ルール）よりも、動き続けるソフトウェア（継続）を。 契約（勝敗の判定基準）よりも、協調（共にプレイし続けること）を。 計画への服従よりも、変化（サプライズ）への適応を。
プロダクト開発に「完了」はなく、ユーザーのニーズは進化し続け、 市場は変化し、チームは学び続ける——Agileマニフェストは、 そういう世界のための、本質的に無限ゲームの設計思想として書かれています。
しかし、Agileには「有限ゲームへの転落」という罠がある
ここからが核心です。
多くのチームがAgileを「導入した」と言いながら、実際には有限ゲームを繰り返しています。 最大の証拠は、Sprintの使い方にあります。
罠①：Sprintは構造上、有限ゲームである
SprintはCarseの定義でいえば「有限ゲーム」です。 2週間という境界があり、Sprint Goalというゴールがあり、 Sprint Reviewという審判の場が存在します。これ自体は問題ではありません。
問題は、チームがSprintに「勝つ」ことを目的にしてしまうときです。 計画したストーリーポイントをすべて消化することが目標になり、 「なぜそのストーリーを作っているのか」という問いが消える。 これが「有限ゲームへの転落」です。
罠②：Velocityという「スコアボード」の歪み
Velocity（ベロシティ）、Burndownチャート、Sprint完了率——。 これらはすべて、無限ゲームに有限ゲームのスコアボードを持ち込んだものです。
Carseはこう言うでしょう。有限プレイヤーはスコアを上げるためにプレイする。
その結果、チームは何をするか。スコアを上げやすいように行動します。
- ストーリーを小さく分割してポイントを稼ぐ
- 品質を犠牲にして「Done」の定義をゆるくする
- 難しい課題を次のSprintに先送りする
これはAgileの失敗ではなく、無限ゲームに有限ゲームの評価軸を適用した、必然的な結果です。
レトロスペクティブ：唯一の「無限ゲームの儀式」
Agileのセレモニーの中で、Carseの意味での無限ゲームに最も忠実なのが レトロスペクティブ（振り返り）です。
レトロスペクティブの本質的な問いは何か。
「このSprintで勝ったか？」ではなく、「どうすれば、より良くプレイし続けられるか？」
これはCarseの無限ゲームの定義そのものです。 目的はゲームを終わらせることではなく、ゲームを続けられるよう、 必要であればルール自体を変えること。 チームの働き方、コミュニケーション、プロセス——これらを「変えてもいい」と認めているのが レトロスペクティブです。
逆に言えば、レトロスペクティブを形式的にこなすだけのチームは、 Agileが持つ最も重要な無限ゲームの要素を捨てていることになります。
では、どちらを選ぶべきか
Carseのフレームを使うと、答えはシンプルになります。 まず、あなたのプロジェクトはどちらのゲームかを問うことです。
| プロジェクトの性質 | 向いているアプローチ |
|---|---|
| 明確な完了条件がある（移行・規制対応・一回限りのリリース） | ウォーターフォール（有限ゲームの構造が機能する） |
| ユーザーのニーズが変化し続ける（SaaS・プロダクト開発） | Agile（無限ゲームの思考が不可欠） |
| 「完了」の定義が途中で変わる可能性がある | Agile（変化を設計に組み込む） |
| 外部との契約や規制で仕様が固定されている | ウォーターフォール（固定ルールが保護になる） |
そして、Agileを選ぶなら、もう一つ問うべきことがあります。
あなたのチームは、Agileを「無限ゲーム」として運用していますか？ それとも、Sprintというフォーマットで「有限ゲームを2週間ごとに繰り返している」だけですか？
おわりに
James P. Carseは哲学者であり、ゲーム理論家でも経営コンサルタントでもありません。 しかし彼の問いは、方法論の議論より深いところに届きます。
ウォーターフォールは悪くありません。それが有限ゲームであると分かっている人が使う分には。 Agileも銀の弾丸ではありません。無限ゲームの思考なしに使えば、 2週間ごとにミニウォーターフォールを繰り返すだけです。
本当の問いはツールの選択ではなく、 自分たちが何のゲームをしているかを理解しているかどうか——です。
参考：James P. Carse, Finite and Infinite Games (1986). Carseの思想はその後、Simon Sinekの『The Infinite Game』(2019) でビジネス文脈に広く応用されています。