スクラムを鵜呑みにしないスクラム導入--背景と「いきなりスクラムを始めない」という判断

背景：なんちゃってスクラムからのスタート

スクラムを導入した──はずなのに、僕たちのチームはまったくスクラムになっていませんでした。

メンバー構成は、開発エンジニア3〜5名、QAエンジニア1名、PM1名。数字だけ見れば、小回りが利きそうなサイズです。形式上は「1週間スプリント」「デイリースクラム実施」と、外から見ればそれっぽい。ですが、運用の中身が決定的にズレていました。

まず、スプリントゴールがない。スプリントバックログも事実上なく、「期限付きタスクリスト」があるだけ。しかも、その多くが1スプリントで終わらないサイズで、平気で数週間またぐ。1機能＝1人担当でfeatureブランチを切り、そのまま長期間こもって作業するのが常態化していました。

この状態では、デイリースクラムは形骸化します。

毎朝「昨日やったこと／今日やること／困っていること」を報告しても、タスクが大きすぎて他のメンバーには進捗も残作業も見えない。結果として、各自が「自分のタスクさえ終わればいい」という世界に閉じこもり、チームとしての一体感は生まれません。

同時に、長生きするfeatureブランチが乱立し、developブランチを長期間取り込まないまま進めることで、マージ時にはコンフリクトの山。デグレのリスクも高く、QAは「どのブランチが正なのか？」の確認から始めないといけない。担当者が抜けたときに引き継ぐのも非常に大変でした。

その背景には、「この人はこの領域が得意だから任せるのが早い」というリソース効率発想があります。一見合理的ですが、行き過ぎると担当領域が固定化し、知識もタスクも属人化する。お互いの領域に踏み込まず、助け合いも起きない。その結果、「着手からリリースまでやたら長い施策」ばかりが増え、チーム全体としてのアウトカムはむしろ鈍くなっていました。

スクラムのイベントだけは形だけ存在するものの、その根底にある

• 透明性
• 協調
• 短いフィードバックループ

といった価値は、ほとんど実現できていなかったのです。

この中途半端な“なんちゃってスクラム”の状態から、僕たちの改善は始まりました。

---

いきなりスクラムを始めない、から始めた

最初にやったのは、「プロセスを増やすこと」でも「スクラムガイドを暗記すること」でもありませんでした。やったのは、スクラムの意味と目的をチーム全員で揃え直すことです。

スクラムの基礎を「一度ちゃんと理解する」

教材として選んだのは『スクラムの拡張による組織づくり』の第2章です。この章だけを切り出し、3回に分けて短い勉強会を行いました。

• 僕が章の要点を噛み砕いて説明する
• 毎回、事前に用意したGoogleフォームの設問に全員で回答してもらう
• 間違いが多かったポイントは、その場で該当箇所を一緒に読み直す

このプロセスで特に重視したのは、次のような「なぜ？」を自分の言葉で説明できる状態にすることです。

• なぜタスクがスプリントを跨ぐと困るのか
• なぜ透明性が重要なのか
• なぜ「個人最適」ではなく「チームとしての成果」を見るのか

ここで繰り返し伝えたメッセージはシンプルです。

• スクラムは「かっこいいスケジュール管理の別名」ではない
• 1週間スプリントは、「1週間で終わる粒度に分解する努力」とセットで意味がある
• チームは「自分のタスクを終える人の集まり」ではなく、「スプリントゴールを達成するユニット」である

後の実践（タスク分割、短命ブランチ、支え合える体制）と結びつけながら、「儀式」ではなく「目的」を理解してもらうことに振り切りました。

ClickUpと役割を「スクラムが回る前提」に寄せる

理解の土台づくりと並行して、使っているツールと役割も整えました。僕たちは ClickUp を使っていたので、次のように構造を作り替えました。

• PBI（プロダクトバックログアイテム）を1つの場所に集約
• スプリント単位でタスクを切り出し、スプリントボード／ダッシュボードを整備
• 「期限付きタスクリスト」から、「スプリントゴールに紐づくタスク群」という見せ方に変更

加えて、役割も明確にしました。

• プロダクトオーナー（PO）を1人に決める
• スクラムマスターは立ち上げ数スプリントだけ僕が担当し、その後は交代制にできる前提で設計
• 開発メンバーには「自分のタスクを終わらせること」ではなく、「チームでスプリントゴールを達成すること」が責任範囲だと明言

レトロスペクティブもYWTからKPTに変更し、

• 「何をしたか」の振り返りより
• 「何を続けるか（Keep）／やめるか（Problem）／試すか（Try）」

にフォーカスすることで、プロセス改善をスプリントの標準機能にしました。

「完璧なスクラム」をあえて捨てる

もう一つ意図的にやったのは、「最初からスクラムガイド完全準拠を目指さない」と決めることでした。理想を全部一気に乗せると、現場の負荷だけが増えて「また儀式が増えた」で終わるリスクが高い。そこで、あえて“やらないこと”も決めました。

最初の段階で許容したこと：

• スプリントレビュー（デモ）は実施しない
• デイリースクラムでは「昨日やったこと」の報告をやめ、 「スプリントゴールまであと何が残っているか」「誰がどれをやるか」「障害はあるか」に絞る
• スクラムマスターやPOの兼任を認める（立ち上げフェーズに限る前提）
• ストーリーポイント見積りは急がず、「タスクを小さくする」「WIPを減らす」を先に徹底する

つまり僕たちは、

「完璧なスクラム」よりも、「今の課題に効く最小限のスクラム」

を優先して導入しました。

この「いきなり全部はやらない」「でも、なぜ変えるかは論理的に説明する」という方針のおかげで、メンバーの納得感は高く、「お作法が増えた」ではなく「今のモヤモヤに対する実用的な処方箋」として受け止めてもらえるようになりました。

この土台の上で、僕たちは最初のスプリント設計と運用改善に踏み出していきます。