記事を書いてる人：あまみ るい
「スクラムを導入すれば、チームの生産性は劇的に上がる」。そんな魔法のような言葉を信じて、僕もかつて必死に現場へ取り入れようとした一人だった。
専用のホワイトボードを買い、付箋を貼り出し、毎朝のデイリースクラムを欠かさない。しかし、現実は残酷だった。会議の時間は増え、進捗報告のための事務作業に追われ、メンバーの顔には疲労が溜まっていく。以前よりも明らかに「仕事そのもの」に割ける時間が減っている事実に、僕は深い違和感を覚えた。
「自分の勉強不足ではないか」「スクラムの真髄を理解していないからではないか」。そう自分を責めて、さらに新しい本を読み漁る日々。しかし、どれだけ手法を学んでも、現場の歪みが解消されることはなかった。
今ならわかる。僕が向き合うべきだったのは、手法の習熟度ではなく、その手法が機能するための「前提条件」の方だったのだ。
スクラムが機能するための「3つの構造的前提」
スクラムというフレームワークは、単なるタスク管理術ではない。それが本来の力を発揮するためには、組織側に特定の「構造」が備わっている必要がある。僕がかつて見落としていた、3つの決定的な前提条件を整理してみたい。
前提① チームに「権限」が移譲されている
スクラムの根幹は「自己組織化」にある。これは、現場のチームが自らの判断でタスクの優先順位を入れ替え、最適な進め方を決定できる状態を指す。
しかし、僕がいた環境では、プロダクトバックログの優先順位を一つ変えるのにも「部長の承認」が必要だった。スプリントの途中で上から割り込みタスクが降ってくることも珍しくない。これでは、スクラムの「形」だけをなぞっていても、実態は従来通りの上意下達だ。決定権がないチームにとって、スクラムのプロセスはただの「面倒な報告儀式」へと変わってしまう。
前提② 評価制度が「成果」ベースになっている
スクラムは、個人の作業時間ではなく、チームが生み出した価値（アウトカム）を重視する。
一方で、多くの日本企業に見られる「残業している奴が偉い」「上司への印象が良い奴が評価される」という減点主義的な評価構造とは、決定的に相性が悪い。僕の経験でも、チームが効率化を突き詰めて定時で帰るようになっても、人事評価のシートには「やる気が見られない」と書かれる始末だった。努力が報酬や評価に直結しない構造下では、効率化のモチベーションは容易に霧散する。
前提③ 失敗を「学習」として扱う文化がある
スクラムは、短いサイクルで実験と失敗を繰り返し、そこから学ぶことで質を高めていく手法だ。レトロスペクティブ（振り返り）の本質は、次の実験のための設計図作りにある。
だが、もし組織が「失敗＝責任追及の対象」と考えているなら、スクラムは牙を抜かれる。見積もりが外れれば「なぜ外したのか」と詰められ、新しい試みが失敗すれば「余計なことをするな」と叱責される。こうした減点評価の恐怖がある場所では、メンバーは守りに入り、形だけの「安全なスクラム」を演じるようになる。
スクラムを導入した現場を観察していると、奇妙な現象に気づく。チーム全体で「効率化」を謳っているはずなのに、全員が等しく楽になっているわけではないのだ。
定時にサッと帰れるようになった人がいる一方で、以前よりも夜遅くまで残ってツールを更新し、調整に奔走している人がいる。この差を目の当たりにしたとき、僕はかつて「自分の能力が低いから、人より時間がかかっているのだ」と自分を責めていた。
しかし、それは大きな間違いだった。この差は、個人のスキルや努力の量ではなく、組織構造の中で「どの役割を押し付けられたか」という、純粋に構造的な立ち位置によって決まっていたのだ。
今回は、スクラム導入という名の「負荷の再配分」によって、誰の仕事が減り、誰の仕事が増えたのか。その残酷な構造を可視化してみたい。
スクラム導入で「仕事が減った人」の正体
スクラムが導入されると、ある特定の立場にいる人たちの負担は劇的に軽減されることがある。彼らは悪意を持っているわけではないが、結果としてスクラムを「便利な委譲ツール」として使いこなしている。
パターン① 意思決定だけする人
従来、細かな進捗管理やメンバーへの指示に追われていたマネージャー層の一部は、スクラム導入を機に「チームの自律性」という言葉を盾にして、実務から距離を置くことに成功する。
彼らはプロダクトオーナーなどの肩書きを持ちながらも、実際にはスプリントレビューで「いい感じですね」とコメントするだけ。デイリースクラムには姿を見せず、週に一度の報告だけを受け取る。マネジメントという名の「指示出し」だけが残り、それに付随していた泥臭い管理業務はすべてチームへと移管されるからだ。
パターン② 実務をチームに押し付けた人
「自己組織化」という概念を都合よく解釈する人も、仕事が減る側に回る。かつては自分も手を動かしていたリーダーが、「これからはチームで考えて決めるべきだ」として、タスク分解や見積もり、トラブル対応などの重い実務をすべてメンバーに委ねてしまうケースだ。
自分は「戦略」や「外部調整」といった抽象度の高い仕事だけに専念し、現場で発生するコンフリクトやリソースの調整からは解放される。彼らにとって、スクラムは実務負担を適法に手放すための最強の理論武装となる。
【仕事が減った人の共通点】
- 明確な意思決定権を持っている
- 実務を法的に（あるいは組織文化的に）委譲できる立場にいる
- スクラムを「現場に任せるための免罪符」として使える
なぜ日本企業でスクラムがうまくいかないのか
僕が見てきた多くの現場でスクラムが空転していた理由は、個人のスキル不足ではなかった。スクラムという手法自体が、もともと「シリコンバレー型」の組織構造を前提に設計されているからだ。
日本企業の多くに根付いている「年功序列・減点評価・稟議文化」というOSの上に、スクラムという最新のアプリケーションを載せようとしても、バグが起きるのは当然だった。構造の違いを無視して手法だけを移植した結果、現場には「形骸化した儀式」と「増え続ける会議」だけが残ることになる。
【構造の対比】
- スクラム成功の構造：権限移譲 × 成果評価 × 失敗許容 ＝ スクラムが機能する
- 多くの日本企業の現実：上司承認 × 態度評価 × 減点主義 ＝ スクラムが形骸化する
「2倍の生産性」という数字の測定前提
成功事例で語られる「生産性2倍」という数字についても、僕は冷静に見つめ直す必要があると感じている。あの数字は、あくまで特定の条件下で測定されたものだ。
明確なKPIがあり、短期スプリントでアウトプットを出し続けられるソフトウェア開発のような環境。そこでの比較であって、あらゆる業種や職種で再現できる魔法ではない。特に、調整業務や稟議、他部署との合意形成が仕事の大部分を占める環境では、そもそも「生産性」を数値化すること自体が困難だ。局所的な成功事例の数字をそのまま自分たちの環境に当てはめようとしたことが、僕の焦りの正体だったのかもしれない。
成功事例が「適用できない」構造を理解する
僕たちが手本にしようとする成功事例の多くは、スタートアップや外資系IT企業のものだ。彼らの組織は、最初からスクラムの前提条件を満たすように設計されている。一方で、伝統的な大企業や官公庁に近い組織では、そもそも構造が根本から異なる。
| 項目 | スクラム成功企業 | 多くの日本企業 |
|---|---|---|
| 権限 | チームに移譲 | 上司・部門長 |
| 評価 | 成果・KPI | 態度・勤務時間 |
| 失敗 | 学習機会 | 減点対象 |
| 意思決定 | チーム内完結 | 稟議・承認待ち |
どちらの組織形態が優れているかという議論をしたいわけではない。ただ、「構造が違う」という事実を認識しないまま手法だけを真似ることは、砂漠に水生植物を植えるようなものだったのだと、僕は気づかされた。
まとめ
スクラムを導入してもうまくいかない。その理由を、僕は自分の努力や理解が足りないせいだと思い込んできた。しかし、実際には「機能するための前提条件」が揃っていない環境で、無理に車輪を回そうとしていただけだったのだ。
