アジャイル導入という新たな儀式 — スプリントが形式化するとき

スプリントは「儀式」になっていないか

2週間ごとのスプリントレビュー、デイリースタンドアップ、バックログ管理——アジャイル開発の作法を導入した大企業の新規事業チームは急増した。しかし、これらの儀式を忠実に実行しながら、アジャイルの根幹である「顧客フィードバックに基づく仮説の更新」が一度も行われていないチームが多数存在する。

13年260社以上への新規事業プロジェクトの共動を通じて繰り返し観察されてきたのは、アジャイル導入の失敗パターンが「手法の問題」ではなく「組織設計との不整合」から来るという事実だ。スクラムを正確に実行しながら、組織の意思決定構造はウォーターフォール時代のままというチームは珍しくない。

外形的なプロセスを導入することと、アジャイルな思考様式を組織に実装することは、まったく別の営みだ。 前者は研修と規約の整備で達成できる。後者は組織の意思決定構造、評価制度、経営層のコミットメントを変えなければ実現しない。

アジャイル版イノベーション・シアター——アジャイルの形式を整えながら、それが生み出すはずの本質的価値を得られない状態——の構造を解析する。

「大企業アジャイル」が陥る5つの形骸化パターン

パターン1：スプリントが計画通りに進むことがゴールになる

アジャイル開発の本質は「計画通りに作ること」ではなく「学びながら方向を修正すること」だ。しかし組織文化として「計画通り実行する」ことが美徳である大企業では、スプリントの評価基準が「予定した機能を予定通り届けたか」になる。

これにより、スプリント中に「この機能はそもそも不要だった」という発見があっても、「でも計画に入っているので実装する」という判断が下される。 仮説が棄却されているにもかかわらず、計画の遵守が優先される。 これはウォーターフォール開発を2週間ごとに区切っているに過ぎない。

パターン2：「顧客」が社内のステークホルダーに置き換わる

アジャイルが前提とする「顧客」は、製品・サービスの最終利用者だ。しかし大企業の新規事業チームでは、この「顧客」が無意識に「社内のステークホルダー」に置き換わる。

スプリントレビューの出席者が社内の上長と承認者で構成される。フィードバックが「実際の顧客の反応」ではなく「経営層の意向」になる。優先度の高いバックログが「顧客が求めているもの」ではなく「経営層が見たいもの」になる。

この置き換えが起きると、スプリントのアウトプットは「社内プレゼンの質」で評価される。 実際の市場での顧客価値は問われない。

パターン3：スプリントのリズムが「報告サイクル」に一致させられる

月次報告、四半期レビューのサイクルに合わせてスプリント設計が歪められる。「月次報告に間に合わせるためにスプリントを3週間にする」「四半期ごとに一度、経営会議向けの成果物を出すスプリントを入れる」——報告のためのイテレーションが混入することで、本来の学習サイクルが断絶する。

アジャイルのリズムは「顧客の学習速度」に合わせて設計されるべきだ。組織の報告サイクルに従属させた瞬間、アジャイルは組織管理のツールに変わる。

パターン4：レトロスペクティブが「形式的な振り返り会」になる

スプリントレトロスペクティブ——チームが「何がうまくいったか、何を改善するか」を議論するセッション——は、アジャイルの学習機能の中核だ。しかし多くの大企業チームでは、このセッションが形式的な会議に変質する。

「今回もよくやった」という総括で終わり、具体的な改善アクションが出ない。「出た問題」を議論するが、その問題の根本原因を組織設計にまで遡って検討しない。「チーム内で解決できること」だけが議題になり、「組織の構造を変える必要がある」という発見は議題にならない。

構造的問題を「チームの話し合い」で解決しようとすることの限界が、ここに現れる。

パターン5：アジャイルコーチが「プロセス管理者」になる

アジャイルコーチやスクラムマスターの役割は、チームが自律的に学び・改善するのを支援することだ。しかし組織によっては、アジャイルコーチが「アジャイルのルールが守られているかを監視する管理者」として機能するケースがある。

スタンドアップの時間が守られているか、バックログが適切に管理されているか——プロセスの遵守を管理するほど、チームは「正しいアジャイルをやること」に意識を向け、「正しいプロダクトを作ること」からずれていく。

なぜ大企業でアジャイルが形骸化するのか

アジャイルの本質は「不確実性を前提とした意思決定の連続」だ。何を作るべきかが事前にはわからないという前提の下で、短いサイクルで仮説を検証し、学びに基づいて方向を修正する。

しかし大企業の組織構造は、「不確実性を前提とした意思決定」に適していない。 年次予算計画、中期経営計画、KPI設定——これらは「事前に結果を予測・約束することを前提とした制度」だ。アジャイルが「今週の学びによって来週の計画を変える」ことを前提とする一方で、組織は「3年後に何を達成するかを今約束する」ことを求める。

この根本的な矛盾を解消せずにアジャイルの形式だけを導入しても、組織の論理がアジャイルの論理を上書きする。スプリントという形式は残るが、アジャイルが実現するはずだった「学習による適応」は消える。

アジャイルを実質化するための構造的条件

アジャイルを形式ではなく実質として機能させるには、3つの構造的条件が必要だ。

条件1：スプリントの成果を「計画通りの実装」ではなく「検証できた仮説数」で測る。 スプリントの評価軸を「予定した機能を作ったか」から「当初の仮説のうち、顧客検証で確認または棄却できたものは何件か」に変える。仮説を棄却して方向を変えたスプリントが、「計画通りに作ったが顧客に使われなかったスプリント」より高く評価される文化を作る。

条件2：スプリントレビューに実際の顧客を参加させる。 社内のステークホルダーだけのレビューを廃止し、プロトタイプの段階から実際の顧客あるいは潜在顧客のフィードバックを収集する。「顧客が使ってみた」という事実が最も重要なインプットであることを組織の仕組みとして担保する。

条件3：アジャイルの「変更する権限」を現場に付与する。 中期計画や年次計画の中で、スプリントの学びに基づいて方向を変更できる権限と予算の裁量を現場チームに持たせる。「計画変更には上長承認が必要」という構造のまま「アジャイルにやれ」と言っても、チームは矛盾した命令の中で身動きが取れなくなる。

アジャイルは「方法論」ではなく「仮説検証のための思考様式」だ。その思考様式を機能させるには、組織の設計が「不確実性を前提にした意思決定」と整合している必要がある。

リーン・スタートアップとアジャイルの関係については「リーン・スタートアップが失敗する条件」を、仮説検証の実践については「顧客発見の神話」を参照してほしい。

参考文献

Beck, K. et al. “Manifesto for Agile Software Development,” Agile Alliance (2001)
Schwaber, K. & Sutherland, J. The Scrum Guide (2020 version)
Rigby, D. K., Sutherland, J. & Takeuchi, H. “Embracing Agile,” Harvard Business Review (May 2016)
Denning, S. The Age of Agile, AMACOM (2018)
平鍋健児・野中郁次郎『アジャイル開発とスクラム』翔泳社（2013年）