スクラムを鵜呑みにしないスクラム導入──生産性はどう変わったか

前回の第2章では、

最初の数スプリントで、マージ戦略や Feature フラグ、1週間スプリントなど「今の課題に効く最小限のスクラム」をどう設計して動かしたか
Story Point 見積もりやデイリー／レトロの運用を通じて、「場の雰囲気」と属人化・差し込みタスクの問題にどう手を入れたか

といった話を書きました。

今回は、その試行錯誤の先で「生産性は実際どう変わったのか？」を振り返る話です。
ベロシティという数字だけではなく、「スプリントを回すのがどれだけ楽になったか」という現場目線でまとめてみます。

「スクラムを始めたらベロシティが◯倍になりました！」みたいな派手なグラフは、正直まだありません。
ただ、チームの“仕事の回り方”はかなり変わったと感じています。

ここでは、

Story Point の見える化
マージ戦略と Feature flag
チームの主体性

という三つの観点から、「何がどう変わったのか」をまとめてみます。

Story Pointの「見える化」で、会話の質が変わった

第2章でも書いたように、僕たちは時間見積もりから Story Point（SP）に切り替えました。
そこからさらに数スプリント回すなかで、「SPをスプリント単位で見える化する」 ようにしました。

今スプリントでどれくらいのSPを持ったか
実際どれくらい消化できたか
どのあたりに見積もりのブレが出ているのか

といったことが、ボードやバーンダウンチャートで一目で分かる状態です。

この「見える化」には、副産物としていくつか良い効果がありました。

見積もりが「答え合わせ」ではなく、ディスカッションの場になった

SPをチームで一緒に見積もるようにしたことで、

「このタスク、本当に3SPで収まる？」
「この前の5SPのタスクより難しそうじゃない？」

といった議論が自然に生まれるようになりました。

以前の見積もりは、

担当者がサクッと時間で見積もる
他メンバーはあまり口を出さない

という、ほぼ“答え合わせ”の時間でした。

それが今は、

タスクをどう分解するか
前提条件は揃っているか
リスクはどこに潜んでいそうか

を、見積もりの場でかなり細かく話すようになっています。

本当は、こういう「でかいタスクを分割する議論」は、スプリントプランニングではなく、
スプリント中の「分解イベント」（いわゆるバックログリファインメント的な場）でやるべきでした。

実際には、最初のうちはプランニングにかなり時間を使ってしまっていたのですが、それでも、

「見積もるためには、タスクをちゃんと理解する必要がある」

という当たり前の事実に、チームとしてちゃんと向き合うようになったのは大きな変化でした。

属人化の予兆が、SPを通じて見えるようになった

もうひとつの効果は、属人化の“匂い”が早めに検知できるようになったことです。

見積もりの場で誰かが、

「すみません、このチケット全然イメージ湧いてないです……」

と言ったとき、それは、

仕様や背景が共有されていない
特定の人だけが全体像を握っている

という属人化のサインでもあります。

SPベースで見積ろうとすると、こうした「分からない」がはっきり表面化します。
それをきっかけに、

その場でチケットの背景を説明し直す
タスクを、他の人も担当できる粒度に分割し直す

といった会話が増えました。

スクラムのキーワードでいうと、

透明性（Transparency）：SPとタスク理解が可視化される
検査（Inspection）：見積もりの場で「分からない」が見つかる
適応（Adaptation）：属人化しないように分割や共有の仕方を変える

という、スクラムの三本柱が、少しずつ現場の会話の中に入り込んできた感覚があります。

マージ戦略 × Feature flag で、QA負荷が“激減”した

スクラムを円滑に回すために最初に手を入れたのが、マージ戦略と Feature flag でした。
これは生産性へのインパクトがかなり大きかったです。

Before：巨大featureブランチと「リリース前一週間QA地獄」

導入前は、典型的なフローでした。

1機能 = 1人の担当で巨大な feature ブランチを切る
数週間〜数ヶ月、そのブランチだけで作業する
リリース直前に main を最新化して、まとめてQA

結果として：

差分が大きすぎて、影響範囲が全体に広がる
QAしていない期間が長く、バグも仕様抜けも溜まり放題
リリース前一週間に、大量の指摘と修正がなだれ込む

という、なかなかハードモードな運用になっていました。

スクラム的に言えば、「潜在的にリリース可能なインクリメント」には程遠く、
“でかい塊を後ろでまとめて検査する” 状態だったわけです。

After：小さくマージして、小さくリリースする世界へ

そこで、

マージ戦略を見直して、こまめにメインのラインに取り込む
機能のON/OFFは Feature flag で制御する

という形に切り替えました。

これによって、

コードとしては早めに main にマージしておく
ビジネス的なリリースタイミングは、Feature flag で調整する

という運用ができるようになりました。

結果として、以前は、

「でかいfeatureブランチを、一気にリリース」

していたものが、今では、

「1つの機能でも、複数週にまたがって少しずつ出していく」

という形に変わっています。

1回のリリースに含まれる変更量が小さい
影響範囲も狭い
QAでの指摘件数も明らかに減る

ので、QAの負荷はかなり軽くなりました。

スクラムの観点で見ると、

スプリントごとに「リリース可能な状態」へ近づける
小さなインクリメントでフィードバックループを回す

という意味で、ようやくスクラムらしい短いサイクルに近づいてきた感覚があります。

「チームで仕事を進める」雰囲気が、少しずつ育ってきた

もうひとつ、数字には出しづらいけれど、個人的に一番嬉しい変化がこれです。

Story Point の見える化、マージ戦略と Feature flag の導入などを積み重ねるうちに、
「チーム感」が目に見えて増えてきました。

具体的には、

ボード上で「空いている重要タスク」を見つけて、誰かが自主的に手を挙げる
誰かが詰まっているタスクに対して、「一緒に見ようか？」と声をかける
「このチケット、自分も背景を知っておきたいので、レビューさせてください」
という動きが出てきた

といった変化です。

以前は、

「自分にアサインされたタスクを、とにかく終わらせる」

という“個人戦”に近い雰囲気がありました。
それが少しずつ、

「スプリントゴールを達成するために、今チームとして何をするか」

という“チーム戦”の空気に変わりつつあります。

スクラムガイド的な言葉で言えば、

1つのスプリントバックログを、チーム全体で引き受ける
スプリントゴールに向けて、誰が何をするかを毎日調整する

という、自律的なチームの方向に少しずつ寄ってきた、という感じです。

生産性は「スプリントを回す楽さ」として効いてきた

ここまでを書いてみると、生産性の変化は、

ベロシティの数字が劇的に跳ね上がった
残業時間がゼロになった

といった派手なものではありません。

むしろ体感としては、

スプリントプランニングが前よりも現実的になった
QA前の「カオスな一週間」がかなり減った
毎日のデイリーで、助け合いが起こりやすくなった

という形で、「スプリントを回すのが以前より“楽”になった」 という変化に近いです。

スクラムを始めた当初は、

「イベントは増えたけど、むしろ疲れてないか？」

という疑念も正直ありました。

ですが、Story Point、マージ戦略、Feature flag といった地味な改善を積み重ねたことで、

スプリント内での判断の材料が増え
リスクの見え方が変わり
チームで動きやすくなった

という意味で、じわじわ効いてくるタイプの生産性向上は確かに起きていると感じています。

でも、いい話ばかりではない

いい話ばかり書いてきましたが、この「いい状態」は長くは続きませんでした。

SP はブレたまま収束せず、割り込みタスクに押し流され、ベロシティは形骸化。
一方で、Feature flag やマージ戦略といった“副産物”だけはしっかり生き残ります。

次の第4章では、そこから 何をやめて、何だけを残したのか をまとめます。
「うちもスクラムっぽいけど、スクラムじゃないな……」と感じている人ほど、楽しめる内容になるはずです。