背景
スクラムを導入したがうまくいかなかった、という話をよく聞きます。その結果、「スクラムじゃなくてもいいのではないか」という声につながることも少なくありません。
日本の現場でも、スクラムのイベントは導入されているものの、期待した効果が出ていないケースは多いように感じます。スクラムを推奨する立場から見ても、こうした状況はスクラムそのものの問題というより、別の要因があるのではないかと思うことが増えてきました。
スクラムが機能しないとき、その原因はスクラム自体にあるというより、「前提条件が整っていない」ことにある場合が多いのではないかと考えています。特に気になるのは、「チームに十分な権限が与えられているか」という点です。
考察
権限を与えられたチームとは何か
スクラムは経験主義に基づいたフレームワークであり、試行錯誤を繰り返しながら改善していくことが前提となっています。しかし、チームに意思決定の権限がない場合、この前提はなかなか成立しません。
たとえば、以下のような状態です。
- 進め方をチーム自身が決められない
- 技術的な選択が上位層によって固定されている
- 改善案を出しても実行できない
こうした状態では、チームは単なる実行部隊になりやすく、スクラムの本質である「適応」が機能しにくくなります。
なぜそうなるのか。スクラムの改善サイクルは、「気づき → 判断 → 実行」という流れで成立します。権限がない状態では、気づきがあっても判断を他者に委ね、実行も承認待ちになる。サイクルが途中で止まり続けると、チームはやがて「気づいても意味がない」と感じるようになります。レトロスペクティブが形骸化していく背景には、こうした構造的な理由があることが多いように思います。
スクラムが「形だけ」になる構造
多くの現場では、スクラムのイベントだけが先に導入されます。デイリースクラムは実施され、スプリントレビューも行われ、レトロスペクティブも形式上は存在する。しかしその内側で行われているのは、単なる進捗報告や形式的な振り返りにとどまることが少なくありません。
たとえば、レトロスペクティブで「テストの自動化を進めたい」という改善案が出たとします。しかしその判断が現場ではなく上位層に委ねられ、次のスプリントでも、その次のスプリントでも何も変わらない。こうした経験が積み重なると、チームは改善提案をしなくなります。イベントは続いていても、スクラムの核心である「検査と適応」はすでに機能を失っています。
この状態は、スクラムをやっているように見えて、実態としては 「イベント付きのウォーターフォール」 に近いように感じます。そうなると、スクラムの効果が出にくいのは自然なことかもしれません。
「スクラムじゃなくてもいい」という結論の背景
こうした状況が続くと、「スクラムは効果がない」という認識が生まれやすくなります。しかし実際には、権限が与えられていない、改善が実行できない、成果が可視化されていない、といった理由により、スクラムが本来の形で機能していないだけではないでしょうか。
それにもかかわらずスクラムそのものが否定されてしまうのは、少しもったいないように思います。
どうすればスクラムは機能するのか
重要になってくるのは、「どこまでチームに任せるのか」を明確にすることではないかと思います。すべてを委ねる必要はありませんが、少なくとも以下の点についてはチームに権限があると、動きやすくなります。
- 作業の進め方
- 技術的な判断
- 改善の実行
この最低限の権限がなければ、スクラムはなかなか成立しません。逆に言えば、この前提が整っていれば、小さなチームであってもスクラムは十分に機能するのではないでしょうか。
まとめ
スクラムがうまくいかないとき、その理由はスクラムそのものではなく、前提条件にある場合が多いように感じます。特に「権限を持ったチーム」という条件が整っていないと、スクラムは形だけのものになりやすい。
スクラムを導入する際には、イベントや形式だけでなく、「チームがどこまで自律的に動けるのか」 という点に目を向けることが大切ではないでしょうか。形を整えることより先に、チームが動ける環境をつくること。それがスクラムを機能させるための、最初の一歩になると考えています。
スクラムに問題があるのではなく、スクラムが機能できる状態になっていないのだとすれば、見直すべきは手法ではなく、環境かもしれません。
コメント