スクラムを鵜呑みにしないスクラム導入──「完全スクラム」をやめて残したもの

前回の第3章では、

Story Point やマージ戦略、Feature flag の導入で、チームの「仕事の回り方」がどう変わったか
スプリントを回すのが以前より「楽」になってきた、という感触

について書きました。

今回は、その続きとして、「このいい状態はなぜ長く続かなかったのか」、
そして最終的に 「完全なスクラムをやめる」と決めるまでの話 をまとめてみます。

SPの改善サイクルが、最後まで噛み合わなかった

最初のうちは、SP がブレても前向きに受け止めていました。

「ブレた分はレトロで学びに変えて、次のスプリントで調整していけばいい」

という想定です。

しかし現実には、

「このタスクは重かったので次は+1SPにしよう」
「この手のタスクは、依存関係も含めて事前に洗い出そう」

といった振り返りをしても、次の見積もりに反映されるスピードが非常に遅かった。

理由はいくつかありますが、

特定の種類のタスクは特定のメンバーしか普段触っておらず、触ったことのないメンバーにとっては「どれくらい大変か」の感覚をつかむのが難しい
割り込みタスクに追われて、前回の学びを思い出している余裕がない
「SPの精度を上げる」こと自体に、あまり強いモチベーションが湧かない

といったものが大きかったです。

結果として、SP改善のPDCAが最後まできれいに回らないまま、

「まあ…今回もブレたけど、それより今目の前のタスクをやろう」

という空気が強くなっていきました。

「透明性 → 検査 → 適応」というスクラムの経験主義サイクルは、
理屈としては理解していても、現実の忙しさの前に優先度が負ける―
その典型例が、SP周りの運用だったと思います。

割り込みに飲まれたスプリントと、壊れたベロシティ

もうひとつの大きな問題は、割り込みタスクの多さです。

プロダクトの性質上、

既存機能に対する問い合わせ
細かい仕様変更のリクエスト
「ちょっとこれだけ見てほしい」系の保守対応

が、思っていた以上に潜在化していました。

スプリントプランニングでは、スパイクタスクを置いたりして「見える化」しようとしましたが、
それでもさばききれず、結果的に、

そういう割り込みタスクに追われるメンバー、1スプリントで実績0.5SP

という、もはや何の数字か分からないベロシティが出てしまったスプリントもありました。

スプリントごとのべロシティも、

SP 5のときもあれば
SP 20のときもある

というレベルで大きくブレていて、

「このまま頑張れば、やがて安定する」

という未来を、正直あまりイメージできませんでした。

ベロシティを本気で安定させようとすると、

「割り込みを減らす重要さ」をチームに徹底して浸透させる
プランニングやリファインメントの時間をさらに伸ばして、タスク設計をかなり厳密にする

といったことに、チーム全員の時間をかなり使う必要があると見えてきました。

そこで、ふと冷静になります。

「そこまでしてベロシティを安定させる必要、うちにあるんだっけ？」

安定したベロシティは、うちの会社には「必須ではなかった」

ここで立ち返ったのが、

「ベロシティが安定すると、会社として何が嬉しいのか？」

という問いです。

うちの事業の前提として、

プロジェクト丸ごとのWBSを引いて、
「○月○日までに○○機能まで完成させる」
みたいな長期ロードマップを、ピンポイントで確定させる場面はほとんどない
プロダクトとして重要なのは、
「商品の新規発売日」や「新しい施策のリリース時期」が守られること

という事情があります。

つまり、

中長期の “正確な” 見積もり精度は、それほど強く求められていない
「ちゃんと売れるタイミングで新機能が出るか」の方が重要

という状況でした。

ここで大事なのは、

スクラムそのものは「経験主義（透明性・検査・適応）」がコアであり
ベロシティは、その中で 予測可能性を高めるための “ひとつの指標” に過ぎない

という点です。

僕たちの環境では、

「予測可能性」を高めるリターンがそこまで大きくない一方で
ベロシティを安定させるコストは小さくない

というバランスでした。

その前提に立つと、

ベロシティを±10%以内に安定させる
そのためにスクラムイベントをさらに厳格に運用する

といった投資は、コストに対してリターンがあまり見合わないと感じました。

「ベロシティがふわっとしていても、
ビジネスが回っているなら、それでよくないか？」

という、かなり現実的な結論に近づいていきます。

「徹底的なスクラム」より、小さなチームの現実

属人化についても、同じようなことが起きました。

理想的なスクラムチーム像だけを見れば、

全員がフルスタックで動ける
フロントエンドもバックエンドも要件レベルで理解している
誰が休んでも、スプリントゴールにほとんど影響がない

といった状態が望ましいでしょう。

現実のチームは そもそも人数が少ないので、

ビジネスの要求スピードに応えながら
技術的にもフルスタックで育成し
さらにスクラム的な理想にも近づける

というのは、かなり重たいチャレンジです。

本当は、

「バス係数1の領域（その人しか知らない領域）」だけは無くしたい
致命傷になりそうなところだけでも、知識を分散させたい

という気持ちもありました。

ただ現実には、

そこに十分な時間を割くと、ビジネス側のスピードが厳しくなる
チームの体力的にも、そこで踏ん張り続けるのは難しい

という判断になり、結果として、

「属人化リスクをゼロにする」理想像よりも
「とにかく施策をできるだけ早く消化する」

という方向に、再び重心が戻っていきました。

要するに、

リソース効率を重視するスタイルに、現実的には逆戻りした

ということです。

この状態を、もはや 「スクラムです」と名乗るのはやめよう、
というのが僕の結論でした。

スクラムの中心思想からはだいぶ離れていて、

スプリントもやっている
レトロもやっている

けれど、優先しているのは 「フロー効率」ではなく、リソース効率。
それなら、素直に「うちはスクラムじゃない」と言ったほうが、健全だと感じました。

それでも、スクラムから“持ち帰ったもの”はある

とはいえ、すべてを捨てたわけではありません。

スクラム導入の過程で生まれた副産物は、今でもしっかりチームに残っています。

Feature flag による段階的リリース
大きな PR を作らないマージ戦略
「巨大な feature ブランチを長期間寝かせない」という文化

これらは、

開発フローをシンプルにし
バグを減らし
リリース前の「カオスな一週間」を確実に減らしてくれた

という意味で、間違いなく良い資産になりました。

スクラムを「全部やめた」というより、

自分たちの現実に合う部分だけを残した

という表現の方が近いと思います。

教訓：スクラムを導入する前に、ちゃんと「目的」を決める

今回の経験から学んだことを、少し乱暴にまとめるとこうです。

スクラム導入 = それだけで正解、ではまったくない
→ 「何を達成したくてスクラムを入れるのか」 を決めないと、途中でしんどくなる
スクラムのコアは「透明性・検査・適応」による経験主義であって、
ベロシティやストーリーポイントはあくまで そのための道具 にすぎない
部分的な導入は全然アリだけれど、
それがスクラムの価値観からズレているなら、無理にスクラムと呼ばなくていい
人数が少なすぎるチームにとって、完全なスクラムは重荷になり、
下手をすると生産性を下げることすらある

そして一番難しいのは、

「自分たちの問題は何なのか」「それに対して今の解き方は本当にフィットしているのか」

を冷静に見極めることでした。

現実を見て、
「これはうちには合わないな」と納得すること。
もし納得できないなら、そもそもそのチームに所属しないほうが幸せなこともある。

スクラムに限らず、プロセスの話は「正しさ」で語られがちですが、
結局のところ大事なのは、

自分たちの制約や目的を踏まえて、どこに折り合いをつけるか

なのだと思います。

この連載が、「スクラムをやめる／やめない」の二択ではなく、
**「うちにとってちょうどいい距離感はどこか」**を考えるきっかけになれば嬉しいです。