Scrumは歪む — 組織設計の原理原則

このスライドはスクフラムフェス福岡2026で発表したものです。
https://confengine.com/conferences/scrum-fest-fukuoka-2026/proposal/49691/scrum-btob-saas

Scrumは、経験主義（透明性・検査・適応）を軸に、価値を学び続けるためのフレームワークです。
一方で、競争の激しいBtoB SaaSの現場では、新機能・UX・AIによるプロダクト間競争、顧客からの問い合わせ対応、SLA制約、フレームワークやライブラリの運用保守、技術負債対応といった要素が常に並行して存在します。

本セッションでは、こうした環境下でScrumを運用する中で生じた「歪み」に着目しました。
1つのチーム（または複数チームで同じミッション）で新しい価値創出と運用・保守をすべて担おうとした結果、スプリントの不安定化やゴールの形骸化が起き、学習が回らなくなっていった実例を紹介します。
その上で、マネージャーとして下した組織設計上のサイロ化の判断を取り上げます。
この判断はScrumを捨てるためのものではなく、Scrumの原理原則をプロセスではなく組織設計に適用することで、現実に耐える形で成立させようとした試みでした。
Scrumが「使える／使えない」という二元論ではなく、競争環境下でどのように歪み、どこに手を打つべきかを考えるための、開発マネージャー視点のケーススタディとして発表しました。

Transcript

1. Scrumは歪む 成⻑するBtoB SaaSで 原理原則を組織設計に持ち込んだ話
2. あなたのチームは 今も 集中できていますか
3. 蘆原 ⼤輔 マネーフォワード  エンジニアリングマネージャー BtoB SaaS / 業界上位シェア 数⼗名の開発組織で 変わり続ける「最適」を追い求めています ⾃⼰紹介
4. 顧客：少ない チーム：1つ 問い合わせ：ほぼ無し Scrumが⾃然と機能した プロダクト誕⽣からしばらくはうまく回っていた
5. 顧客増 / 問い合わせ増 チーム拡⼤ 競争激化 前提が変わった 集中できなくなった
7. Scrumを疑った Scrumフレームワークそのものが 機能不全を起こしているのではないか
8. スプリント揺れる 改善が残らない 集中が崩れる 問題は付箋ではない 歪み
9. 構造は変えていなかった 表⾯上のプロセスをなぞり ⼟台となる「構造」に⼿を触れていなかった
10. Feature 新機能 / AI機能などの 「攻め」 Sustain 問い合わせ / 保守などの 「守り」 Enabling 技術負債 / アーキの 「⼟台」 構造を変えた（3つの役割）
11. 整理された 気がする ⼀瞬整う
12. 構造は 万能ではない 葛藤は消えない
13. Feature ⽬に⾒える価値 / しかし、期 待という重圧 Sustain 事業に不可⽋ / しかし、評価 されにくい孤独 Enabling 未来への挑戦 / しかし、⾒え ない成果への不安 ⼈の⾮対称
14. 今でも分からない or 技術負債 機能開発 揺れた判断
15. プロセスだけではない 「判断の質」にも向き合う 透明性 検査 適応 Scrumの原理原則
16. 分けるだけでは⾜りない 境界線を引くだけでは、 本当の意味で「歪み」を解消することはできない
18. 判断を 検査しているか チームは集中できているか 「正解」を求めるのではなく、 ⾃分たちの「選択」を疑い続けること。 Scrumは歪む