スクラムを鵜呑みにしないスクラム導入──最初の数スプリントで実際にやったこと

第1章--背景と「いきなりスクラムを始めない」という判断はこちら

前回の第1章では、

「なんちゃってスクラム」からスタートした背景
いきなりスクラムを完コピしないで、「今の課題に効く最小限のスクラム」から始めたこと

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

今回は、その土台の上で最初の数スプリントで実際に何をやったのかをまとめます。
机上の理屈ではなく、「現場でこう動かした」という話です。

1. 最初の数スプリントで「まず手をつけたこと」

1-1. マージ戦略を整理して「長生きPR」を撲滅したい

第1章でも触れたように、僕たちのチームの大きな問題のひとつは

1機能＝1人の担当で feature ブランチを切る
そのまま長期間こもって作業する
最後に巨大な PR でどかんとマージ

というスタイルでした。

結果として、

数週間〜数ヶ月生き続ける PR が量産される
コンフリクトの嵐
QA から見ると「どのブランチが正か分からない」状態

と、開発の透明性もリスクもひどい状態でした。

そこで最初の数スプリントで、マージ戦略を一度リセットしました。

独特な「自家製マージ運用」からいったん離れる
まずは git flow へ移行
将来的には GitHub Flow へ寄せることを目標にしつつも、
まだテストが弱く CI も貧弱なので、
いきなり trunk-based に振り切るのはやめる

という判断です。

具体的には：

develop ブランチにこまめにマージする運用を徹底
release / master ブランチにマージされたら
自動的に develop にも同期される workflow を用意
「長生きPR」はチームのアンチパターンとして明示的に禁止

にしました。

「スクラムっぽくするため」ではなく、

長生きPRを減らすことが、透明性とフィードバック速度を上げるための
一番のボトルネックだった

ので、ここから着手した形です。

1-2. Featureフラグ導入を企画する──開発とビジネスの歩幅合わせ

もう一つのボトルネックは、**「開発が終わってもすぐにはリリースできない」**ことでした。

商品発売は 商品開発チーム
施策リリースは マーケティングチーム

と連携が必要で、

コードとしては完成しているのに、
ビジネス側の準備待ちで、いつまでもリリースできない

という状態がよく起きていました。

その結果：

「リリースできるまでブランチをマージしないでおこう」
「PRは出したまま、数週間放置」

という長生きPR製造マシーンが生まれます。

ここを断ち切るために企画したのが、Featureフラグの導入でした。

開発チームのゴール：
「コードができたら、あとはフラグを ON にするだけの状態まで持っていく」
ビジネス側のゴール：
「いつリリースするかは、自分たちのタイミングで決められる」

この2つのゴールを両立させるための仕組みとして、Featureフラグを選びました。

検討の過程では、Martin Fowler の Feature Toggles 記事を参考にして、
最終的には “Changes with runtime re-configuration” パターンを採用しました。

デプロイなし／再起動なしで設定を切り替えたい
ただし、いきなりフル機能のフラグ管理サービスを導入する体力はない

という現実とのバランスを取りつつ、

まずは既存のアプリ構成の中で
「設定変更 = runtime re-config」で吸収できるようにする
将来もっと高度なフラグ管理が必要になったら
そのとき専用サービスを検討する

という「段階的導入」を狙った形です。

1-3. スプリントスパンは1週間にした理由

第1章で書いたように、僕たちは最初から1週間スプリントを採用しました。

理由はシンプルです。

スクラムをちゃんと回した経験がほぼない
最初の数スプリントは、どう考えても失敗が多発する

と分かっていたからです。

であれば、

2週間〜1ヶ月スプリントで大きくコケるより
1週間スプリントで小さくコケて、小さく学ぶ

ほうが、チームへのダメージも心理的負荷も小さい。

失敗前提で

「早く失敗して、早く学び、早く次のスプリントに活かす」

というサイクルを回すため、あえて短いスパンを選びました。

1-4. Story Point見積もりで属人化に挑む

もともとの運用では、見積もりはほぼ

「その人の感覚で時間で見積もる」
「この人なら1日で終わるでしょ？」

といった属人的な世界でした。

これを少しでも崩すために、時間見積もりではなく Story Point（SP） を採用しました。

SP は「絶対時間」ではなく、相対的な難易度
「このタスクは前にやったあの3SPくらいと同じくらい」
「こっちはそれよりちょっと大変だから5SPかな」

という考え方に揃えていきます。

運用上、良かったことは：

「見積もれないタスク」が見つかりやすくなった
- 見積もれない =
  - 前提条件があいまい
  - 作業の分解が足りない
- なので、その場で議論して分解するクセがついた
見積もりの場が、
「答え合わせ」ではなく「問題を早期発見する場」 に近づいていった

ことでした。

1-5. デイリースクラムを「進捗報告会」から救い出す

導入前のデイリーは、完全に進捗報告会でした。

昨日やったこと
今日やること
困っていること

を各自が淡々と読み上げるだけ。
タスクが大きすぎるので、聞いてもあまり状況が分からない、というおまけ付きです。

ここを変えるために、ファシリテーションを根本から変えました。

個人単位で順番に話すのをやめる
スプリントバックログの上から順に見る
- スプリントゴールに直結するタスクを優先的に確認
- まだ誰も触っていない重要タスクがあれば、その場で担当をアサイン
進捗が悪いタスクや、詰まりが見えているタスクは
その場で軽く議論して、助け合いのきっかけを作る

こうすることで、

「自分のタスクの進捗を報告する時間」から
「スプリントゴール達成のために、今日どこに力をかけるかを決める時間」

へ、デイリースクラムの意味を少しずつ変えていきました。

1-6. レトロの雰囲気を変える

レトロスペクティブも、最初は YWT（やったこと／わかったこと／次やること） 形式で、
どうしても「報告会」になりがちでした。

第1章で形式としては KPT に切り替えましたが、
形だけ変えても、Problem がなかなか出てこないという課題が残っていました。

そこで、雰囲気づくりから手を入れました。

毎回、まず僕が Problem を自分で書く
- 「こういうところ、正直うまくいってないよね」と
  先に自分の失敗や改善点をさらす
その上で、チームメンバーにも
「小さなモヤモヤでもいいので Problem に書いてほしい」と依頼
同時に、Keep にはメンバー同士への賞賛を書く
- 「◯◯さんがこのタスクを巻き取ってくれて助かった」
- 「QA の◯◯が早めに指摘してくれたおかげで大事故にならなかった」
  といった具体的な感謝や称賛を残す

こうすることで、

Problem を書くこと = 誰かを責めること
ではなく
Problem も Keep も含めて、
「お互いを尊重しながら、より良くするための材料を出す場」

という雰囲気に少しずつ近づけていきました。

2. うまくいかなかったことと学び

もちろん、ここまで書いたことが全部スムーズに進んだわけではありません。
むしろ、最初の数スプリントは失敗のオンパレードでした。

その中でも大きかったのが、次の2つです。

2-1. Story Pointのブレをどう収束させたか

SP を導入したものの、最初は

相対的な難易度の考え方が浸透せず
同じタスクでも人によって 2SP〜8SP まで幅が出る

といった状態でした。

本来であれば、時間に換算しないほうがきれいです。
ですが、現場で回してみると、

「SPと言われても、結局どれくらいの作業量なのかイメージがわかない」

という声が多く、議論が迷子になりがちでした。

そこで割り切って、簡単な時間換算表を用意しました。

「だいたいこのSPなら、これくらいの時間レンジかな」
あくまで**“レンジ”であって、「1SP = X時間」ではない**

というスタイルです。

この表の目的は、

「SP = よく分からない謎の数字」から
「ざっくりこのくらいの重さを表す数字」

くらいまで認知を上げることでした。

もちろん、

時間との直結は望ましくない
将来的には、この換算表なしでも見積もれる状態にしたい

という前提は毎回強調しました。

それでも、

チーム全員の「SPの感覚」を近づける
見積もりの議論を、「人によって倍違う」レベルから卒業させる

という意味では、導入してよかったトランジションだったと思っています。

2-2. 差し込みタスクにどう向き合ったか

もうひとつの大きな失敗は、差し込みタスクです。

プロダクトの性質上、

既存システムのバグ修正
CS からの問い合わせ対応
調査タスク（障害調査など）

といったタスクが、スプリント中に頻繁に発生します。

最初のころは、

スプリントゴールを決める
でもスプリント中に差し込みが連発
気づいたら、スプリントゴールがボロボロに崩れている

ということがよくありました。

ここでやったのは、「無限に差し込みを受けない仕組み」を作ることです。

具体的には：

スプリントごとに 「スパイク枠」 を用意する
- 差し込みタスクや調査タスクのための容量を、最初から確保しておく
差し込みの総量がスパイク枠を超えたら：
- 既存のタスクをスプリントから外す
- そのうえで差し込みを受けるか、PO と相談して優先度を入れ替える

という運用に変えました。

これによって、

「差し込みは無限に飲み込むもの」から
「容量を超えたら、何かをあきらめる必要があるもの」

と認識が変わりました。

結果的に、

スプリントゴールの守り方がチーム全体で揃う
PO も「差し込みを入れる = 何かを外す」前提で判断できる

ようになり、スプリントゴールが崩壊する頻度はかなり減りました。

まとめ：スクラムを“やったことにしない”ために

最初の数スプリントでやったことを振り返ると、

マージ戦略の整理（長生きPRの撲滅）
Featureフラグ導入の企画（開発とビジネスの歩幅合わせ）
1週間スプリントで小さく失敗する設計
Story Point見積もりで属人化に挑む
デイリースクラムとレトロの「場の雰囲気」を変える
そして、Story Pointのブレと差し込みタスクという大きな失敗

といった、かなり地味な改善の積み重ねでした。

どれも、

「スクラムガイドにはこう書いてあるから」

ではなく、

「今の僕たちの課題にどれが効くか」
「現実的に、このチームで運用できる形はどこか」

を考えながら選んでいった結果です。

スクラムを導入すると、「イベントを増やした」「ボードを作った」時点で
「スクラム、やりました！」と満足してしまう罠に入りがちです。

僕たちが意識したのは、

スクラムの“お作法”を増やすのではなく
チームのボトルネックに対して、一つずつ手を打ち続ける