「スクラムが失敗した」とはどういうことか？――Two Loopsモデルと現場での実践知から紐解くアジャイルの本質

はじめに

「スクラムを取り入れたが失敗した」という声に向き合う

「以前のプロジェクトでスクラムを取り入れたのですが、結局うまく機能せず失敗に終わりました」

アジャイル開発や組織変革の現場で、このような話を耳にすることがあります。その語り口からは、「スクラムというフレームワーク自体に欠陥があった」「自社の文化には合わなかった」というニュアンスを感じ取ることが少なくありません。

しかし、その捉え方は適切なのでしょうか。

スクラムガイドに書かれているイベントやロール、あるいはアジャイルの各種プラクティスは、あくまで学習と適応のための「枠組み」に過ぎません。形式通りに運用することや、ルールを守り切ること自体が目的ではないはずです。

「手法の成否」という表面的な議論にとどまらず、組織の中で本当は何が起きていたのか。私自身の現場での経験と、「Two Loopsモデル」という構造的な視点を交えながら、この「スクラムの失敗」と言われる現象の正体を整理してみたいと思います。

スクラムは「課題を可視化するシステム」

スクラムを導入して現場が混乱に陥ったとき、それはアジャイルという手法そのものの不備で起きているわけではないと考えています。

スクラムは、チームの状況やプロセスの課題に対する透明性を劇的に高めるシステムです。

これを既存の組織に組み込むと、従来の管理体制や評価制度、コミュニケーションのボトルネックとハレーションを起こします。つまり、スクラムが失敗したように見える現象の本質は、手法の破綻ではなく、既存組織の中に隠れていた構造的な課題が可視化された状態だと捉えることができます。

特に歴史のある大企業などで顕著ですが、このコンフリクトの根底には、新旧システムにおける思考様式の深い非対称性があります。

従来の大企業では、長年にわたり「予測可能性」と「計画通りの遂行」を前提とした組織構造が作られてきました。綿密な計画を立て、リスクを最小化し、評価や承認のラインを重厚に重ねることで成果を上げてきた歴史があります。

一方で、スクラムをはじめとする適応型のアプローチは「前提となる未来は予測不能であり、短サイクルでの実験と学習によって答えを見出していく」というスタンスを取ります。

計画通りの運用を求める既存の仕組みと、探索的に価値を検証しようとする新しい仕組み。前提とする思想が異なる以上、既存組織の中に新しいアプローチを持ち込もうとすれば、摩擦が発生するのは当然のことです。

Two Loopsモデルで読み解く「構造的な摩擦」

この摩擦の構造を捉えるうえで助けになるのが、バーカナ研究所が提唱する「Two Loopsモデル」です。Two Loopsモデルは、既存のシステムが減衰しながら、新しいシステムへと移行していく組織変革のプロセスを表した概念です。

Two Loopsモデルの図

出典：Complex Systems Frameworks「Two-Loop Model」

• 第1のループ（既存システム）
  従来の計画主導型システムです。環境変化が激しい現代においては限界を迎えつつありますが、予算管理、評価制度、情報システム部門などの組織基盤において、依然として強力な力を持っています。
• 第2のループ（新システム）
  スクラムをはじめとする適応型のシステムです。現場のあちこちで試みが生まれるものの、初期段階では第1のループの強力な慣性に引き戻されやすい性質を持っています。

スクラムという第2のループが既存のループに引き戻された結果、形だけはスプリントを回しているものの、実態は「ウォーターフォールを細かく刻んで繰り返しているだけ」という、いわゆるゾンビスクラムのような状態に陥ってしまいます。第1と第2のループが交差する過渡期において、このシステム間の摩擦をどのようにマネジメントするかが問われます。

そして、スクラムマスターのようなロールはこの変革をうまくマネジメントしていくことに専門性と責務を持っていると考えています。

摩擦は「お互いが正しい責任を果たそうとしているから」起きる

現場が第2のループへ移行しようと探索的なアプローチを取ると、外部に対して明確なリリース時期や最終仕様をあらかじめ約束することは難しくなります。

一方で、経営層や関係部署などのステークホルダーは第1のループの論理で動いています。彼らは当然のように「確実な納期」や「確定した成果」を求めてきます。

ここで大切なのは、ステークホルダーを「変化を拒む存在」と見なさないことです。 彼らもまた、自身の立場において「他部署との同期」「予算の確保」「経営への説明責任」という、第1のループにおける正当なルールに基づき誠実に責任を果たそうとしています。お互いが自身の置かれたシステムの中で正しい行動を取ろうとしているからこそ、必然的に強い摩擦が生まれるのです。

レビューの場と意思決定の場を分離した事例

私が実際に関わった現場でも、まさにこの構造的な摩擦に直面しました。当初はスプリントレビューに事業側の主要なステークホルダーにも参加してもらっていたのですが、回を重ねるにつれて議論の噛み合いにくさが目立つようになったのです。

確実な進捗確認や統制を求めるステークホルダーの視点と、柔軟なフィードバックと学習を重視する現場の視点が同じ場で交錯してしまったことが主な要因でした。その結果、レビューが進捗確認や方針追及の場と化してしまい、プロダクトに対する純粋なフィードバックを得るという本来の目的を果たせなくなっていました。

そこで私たちが実施したのが、スプリントレビューとは別に、事業上の意思決定や進捗統制を行うための調整会議を明確に分けて設置することでした。進捗の管理や意思決定を行う場と、プロダクトの試作を見ながら意見を交わす場を役割ごとに整理・分離したのです。

この提案をした際、チーム内からは「スクラムの標準的なガイドラインから外れるのではないか」「会議体を増やすのは非効率ではないか」といった懸念の声も上がりました。

しかし私は、標準の型を厳格に守ること自体が目的ではなく、自分たちの組織が目的に向かって対話しやすい環境を作ることが最も重要だと考えました。そこで「まずは1ヶ月間試してみよう」とチームに働きかけ、検証として試行を開始しました。

実際に場を分離したところ、スプリントレビューは本来の柔軟なフィードバックを得る場としての機能を取り戻しました。一方で、新設した会議体によって事業側が求める確実な意思決定や統制もスムーズに行えるようになり、大きな成果を実感することができました。

型を守ることではなく、摩擦から新しいモデルを生み出すこと

このような「レビューの場と意思決定の場の分離」といったアプローチは、一見すると既存組織への妥協や、スクラムの標準的な型の形骸化のように見えるかもしれません。

しかし本質的には、既存システム（第1のループが求める統制）と新システム（第2のループが求める適応）の要求をそれぞれ整理・統合し、その組織のコンテキストに適合する「新たな運用モデル」へと再構築するプロセスであると捉えられます。単に双方の意見を折衷するのではなく、それぞれの目的を正しく理解したうえで高次のアプローチへと昇華（アウフヘーベン）させる営みです。

既存の仕組みに流されてアジャイルの原則を失うのでもなく、フレームワークのルールだけを根拠にして従来の組織構造や文化を全否定するのでもない姿勢が求められます。

異質なシステム同士を共存させながら現場に適した形へと定着させていくこと。2つのループが重なり合う過渡期において、組織構造と現場の実践をつなぎ、実験と適応を支え続けるアプローチこそが、変革を推進するうえでの重要な鍵となります。

おわりに

スクラムを実践するうえで重要なのは、スクラムガイドに書かれているルールやイベントを形式通りに守り切ること自体を目的化しないことです。

既存の組織構造や思考様式という「旧システム」の中に「スクラム」という「新システム」を差し込むことで、あえて構造的なコンフリクトを生み出し、そこから現場のコンテキストに即した新たな運用モデルを紡ぎ出していくことこそが、アジャイルの本質的な取り組みなのではないかと個人的には思っています。

「スクラムが失敗した」と感じた瞬間こそ、組織の真の課題と向き合い、次の一歩を踏み出す絶好のチャンスです。

完璧なフレームワークの適用を目指すのではなく、目の前の摩擦を対話のきっかけに変えながら、自分たちだけの最適なプラクティスを探索していきましょう。あなたの現場での小さな実験と挑戦が、組織全体を動かす大きな変革の第一歩となるはずです。