スクラムは「健康診断」だった —ビジネスチームに導入して見えた認知負荷と、スクラムの外にあった処方箋

スクラム祭り2026 福井トラック スクラムは 「健康診断」だった ビジネスチームに導入して見えた認知負荷と、スクラムの外にあった処方箋 井手 拓夢 イデー / @idee_tm

これまでの登壇 スクラム祭り2025 金沢トラック 井手 拓夢 / イデー Agile Studio ウェビナー 株式会社リコー X: @idee_tm スクラムフェス 金沢2026 02

スクラムって、チームに 何をしてくれるものだと 思いますか? 03

4か月やってみて、たどり着いた答え スクラムは 「みんなでやれば成果が出る仕組み」 ではなく、チームの健康診断だった 04

CHA PTE R 01 越境 開発チームからビジネスチームへ 05

プ ロジ ェ ク ト 社内スタートアップのような組織で、 営業支援SaaSの事業を展開していた プロダクト開発領域 ビジネス領域 スクラムチーム 2チーム体制 4領域・6名 チームA チームB エンジニア・PO・デザイナー データ分析 プロモーション Web運用 CS 開発のスクラムマスターから、ここへ異動 少人数で、事業のすべてを回す体制 06

事 業の 流 れ と、 自 分 の役 割 フェーズが変わるたびに、自分の役割も変わってきた 0→1 ローンチ グロース α版・β版の開発 スクラムで開発 開発は2チーム体制に 売上を立てるフェーズへ ビジネスチームに越境 エンジニア スクラムマスター セールス兼スクラムマスター ▲ 今日の話 07

入 って み た チー ム それぞれが「個人商店」で動くチーム データ分析 プロモーション Web運用 CS 4領域のうち3領域が1名体制。全員が担当業務そのものの初心者 領域どうしは分断されていて、改善のサイクルも優先順位もはっきりしていなかった 08

ヒ アリ ン グ メンバー6名全員に1on1でヒアリングした 「振り返りが 「情報共有が できていない」 できていない」 個人の問題ではなく、構造の問題だと考えた 09

ヒ アリ ン グ で見 え た 課題 個人の能力ではなく、構造の問題が4つあった 1名体制で、領域が分断されている 外部パートナーに依存している 1人休むと止まる。互いの施策も見えない 判断待ちで止まり、ノウハウが残らない 仮説検証が回っていない 優先順位が決まらない ふりかえる相手がいず、同じやり方を繰り返す 各自の判断で、リソースが分散する 10

改善のフィードバックループが 回っていない スクラムで解決できるのでは? 11

提 案し た 体 制 施策を足すのではなく、体制ごと変えることにした 1チームに統合する 段階的に権限を移す 仕事を見える化して、スキルを共有する チームで判断できるようにする 1週間スプリントで回す 事業責任者が判断軸を示す 仮説検証とふりかえりを毎週やる それをもとに、チームで優先順位を決める 最初の1〜2か月は体制づくりの投資期間で、すぐにはスピードは上がらない前提で始めた 12

CHA PTE R 02 導入 13

導 入ま で の 流れ いきなり始めず、ヒアリングと合意から入った まず 次に そして 直前に その翌週 全員に 1on1ヒアリング 運営方針書を つくる 1チームで スクラムをやると合意 アジャイル勉強会 1時間 全体設計の議論、 スプリント開始 上期はまず全員が業務全体を知る。下期から得意分野ごとにリードを置く、という計画にした 14

ア ジャ イ ル 勉強 会 導入前に、1時間のアジャイル勉強会をした Complex やってみないとわからない Complicated グロースの仕事はここ Chaotic Clear ソフトウェア開発に限った話じ ゃない。 ビジネス領域にどう適用して考 えられるか? この観点で、チーム全員の共通認識をつくりたかっ た 15

導入 クロスファンクショナルなスクラムを導入 ● 4領域を1チームに統合 ● 1週間スプリントと、毎朝15分の 1つのスクラムチーム デイリースクラム ● 事業責任者が優先順位の判断軸 を示す 1つのゴール ● 誰が何をやっているかは、見え るようになった 16

CHA PTE R 03 違和感 17

違 和感 1 スプリントゴールに向かっていたのは、3人だけ 自分の担当タスク スプリントゴール 自分の担当タスク 情報共有の場はあるのに、把握できていないメンバーも出てきた 18

違 和感 2 ふりかえりが、業務連絡の場になっていった 「やることが多い」 「時間が足りない」 「施策がこんがらがってきた」「計画ばかりで実行が足りない」という声も出ていた レトロスペクティブ 業務連絡の場 チームの進め方をふりかえる場 報告して終わり 19

違 和感 3 15分のはずのデイリースクラムが、50分かかっていた 0分 50分 ゴールの作戦会議 「全体を通して話したいこと、ありますか?」から始まる議論 15分 35分 どれも大事な話ではあった。 ただ、スプリントゴールとは関係のない、並行して進めている仕事の話だった 20

観察 あえてイベントを休んで、チームを外から見てみた 起きていたこと そのとき思ったこと 誰もファシリをしなかった 「みんな、全然 追えてないじゃん」 KPIやファネルの話が出てこなかった タスクの整理はうまくなってきていたのに 整理して見せていたつもりだった。 このギャップはなんなんだろう 21

そのとき考えていたこと メンバーの実力不足か、 自分のファシリテーションの問題か。 そのくらいにしか、思っていなかった 22

CHA PTE R 04 転機と打ち手 23

社 外イ ベ ン ト AG ILE I NF US E のOS T Agile InfuseのOSTで聞いた、ある非開発チームの話 「最初に計画をがっつり立てて、 あとはサブチームに分かれて動く」 24

「あ、これだ」 チーム・トポロジーの考え方が、OSTの事例をきっかけに、目の前の チームの問題とつながった 25

チーム・トポロジーのゴールは、コラボレーシ ョンが必要な場所やタイミング、実行に集中し てコミュニケーションのオーバーヘッドを減ら すべき場所やタイミングを、組織が適応しなが ら動的に見つけられるようなアプローチとメン タルツールを提供することだ Matthew Skelton, Manuel Pais『チーム・トポロジー』 26

チ ーム ・ ト ポロ ジ ー チーム・トポロジーの認知負荷の考え方 ● チームが一度に扱える認知負荷に は上限がある 範囲が広すぎる 範囲を切る あふれた仕事 ● だから、チームの責任範囲を、扱 える認知負荷に合わせて切る ● 人を増やしたり頑張ったりしても 、上限を超えた分は処理されない チーム それぞれ上限に収まる 参考:Matthew Skelton, Manuel Pais『チーム・トポロジー』 27

チ ーム ・ ト ポロ ジ ー 責任範囲が広すぎると、内発的動機付けが失われる 自律 熟達 目的 複数チームの要求や優先順位を いろいろ抱えすぎて、どれ 責任範囲が広すぎて、何のため 、絶えず調整し続けることで失 も深まらない。多芸は無芸 のチームかがぼやける われる ダニエル・ピンクが提唱する内発的動機付けの3要素(『チーム・トポロジー』より) 28

自 分の チ ー ムに 当 て はめ る と 担当業務だけで、扱える上限に近かった 担当業務(初心者なので重い) 扱える上限 全体の把握・連携 自分の領域だけで手いっぱいのところに 、スクラムが認知負荷を上乗せしてい た Web プロモーション CS / パートナー 29

型 と現 実 現実と型が、合っていなかった 現実 スクラムの型 ≠ Web プロモ CS ゴール・納期 ゴール・納期 ゴール・納期 1つのチーム、1つのゴール 型に現実を合わせようとしていた 30

タスクを取らないのは、その人の実力不足? 人の問題ではなく、 仕組みの問題だった 31

チ ーム ・ ト ポロ ジ ー のア プ ロ ーチ で コラボレーションする場と、実行に集中する場を分けた 実行に集中する場 コラボレーションする場 全体で方向を合わせる 方向を決めて、分かれる サブチームで進める ・最初に全体で計画を立てる ・レビュー(毎週) ・リファインメント(月1) ・ふりかえりの共有 週に1回、持ち寄る Web セールス プロモ パートナー CS デイリーも日々の判断も、ここで完結 32

打 ち手 抱えきれる範囲で、3つのサブチームに分けた 最初に全体で計画を立てる Web セールス・プロモーション リード 自分たちのゴールとイベント リード 自分たちのゴールとイベント パートナー・CS リード 自分たちのゴールとイベント 各サブチームに、担当領域を引っ張るリードを立てた。全体で持つのはレビュー(毎週)・リファイ ンメント(月1)・レトロの共有だけ 33

変 えた 結 果 会議が減り、作業する時間が増えた 分 ける 前 分 けた 後 全員で全施策を見る 日々はサブチーム、全体は週1のレビュ デイリースクラム 50分 ふりかえりの主題は「タスク出し」 ファシリテーションは自分 ーに絞る → デイリースクラム 15分以内 ふりかえりの主題は「仕事の進め方」 ファシリテーションは各領域のリード 34

し ばら く し て 自分が介入しなくても、改善が回るようになっていた ● 各領域のリードが、KPIを起点に自分で判断する ● サブチームが自分たちで改善策を決めて動く 例:集中して作業する日をつくる、有識者を入れた定例を始める ● 「非同期でやりませんか」「期日を決めませんか」と、進め方の提案がメン バーから出る ● 各自が担当領域に集中できて、意思決定が速くなった 全員が担当業務の初心者だったチームには、この形が合っていた 35

CHA PTE R 05 学び 36

「スクラムとは問題を発見する フレームワークであり、 その問題を解決するのは人だ」 スクラム道関西の座談会記事で、スクラムマスダーこと増田謙太郎さんが研修講師の言葉として紹介 Agile Journey「スクラムの「うまくいかない」はなぜ？ 組織や関係性に隠れた課題を探る」(2026/07/23) https://agilejourney.uzabase.com/entry/2026/07/23/103000 37

• https://agilejourney.uzabase.com/entry/2026/07/23/103000

AG ILE JOUR N EY / ス クラ ム 道 関西 問題が次々と見えるのは、スクラムが機能している証 健康 診断 治療 問題を発見する 問題を解決する スクラム 人・組織設計 38

学び 問題を見つけるところと、解決するところは別だった スクラムの中 スクラムの外 発見する 原因がわかる 治療する スクラムで問題が見えた 問題は認知負荷だった 体制の見直し スクラム道関西の言葉 チーム・トポロジー サブチーム分割 39

うまくいかなかった理由 スクラムが見せてくれた問題を、 人の問題だと考えていた 「メンバーが追えていない」「自分の進め方が悪い」 見つけることも解決することも、スクラムの中でやろうとしていた 40

ま とめ 持ち帰ってほしいこと チームが抱えられる認知負荷から考える 全員が初心者のチームに、いきなり1チームのスクラムは重い うまくいかないときは、体制を変える選択肢を持つ イベントを工夫するより先に、抱えきれる範囲に分ける うまくいかないのは、誰かのせいじゃない スクラムが見せてくれた問題として、何が見えたのかを考える 41

スクラムがうまく回らないとき、 人のせい(自分も含めて)にする前に 「チームの何が見えたのか」を考える 42

みなさんのスクラムは、 何を診断していますか? 43

井手 拓夢 / イデー 株式会社リコー い まの 役 割 ビジネスデザイナー X: @idee_tm 44

Thank you!!