こんにちは、スクラムマスターの asato です。
あるスクラムチームのリードタイムが半年ちょっとで1/4に改善しました。 具体的には、最低3〜4週間を要していたリードタイムが1週間未満になったのです。 このブログでは、この期間にこのスクラムチームで起きていた変化を共有します。
このブログを通して、「チームのリードタイムに課題を感じている人」が「具体的な物語を通して、自分たちのチームに適用できるプラクティスを思いつく」ことをお手伝いできれば嬉しいです。
序章：リードタイムが4週間のスクラムチーム
このチームは発足から1年ほど経ったところで、スクラムに取り組み始めました。私が加入したのは、その3ヶ月後のことです。 ほとんどのチームメンバーにとって、スクラムへの転換は好印象でした。 一方で、いままでスクラムやアジャイル開発に詳しいメンバーがいなかったこともあり、「このままで十分なのか、もっと改善できることはないのか」といった点で困っているようでした。
まず最初の2週間、私はチームを観察し、チームメンバーと対話することに集中しました（詳しくは「チームに新しく飛び込んだスクラムマスターが最初にやること」を見てください☺️）。 その結果、リードタイムが最低4週間かかるであろう開発のフローが特に気になりました。
このチームでは、プロダクトマネージャーが主導するPRD（Product Requirement Document: プロダクト要求仕様書）やステークホルダーのフィードバックから各職能（フロントエンドエンジニア、バックエンドエンジニア、QAエンジニア）がそれぞれの職能のためのPBI（Product Backlog Item: プロダクトバックログアイテム）を作成し、タスクを可視化していました。 問題はその依存関係とスプリントプランニングのコミットメントでした。
まず、それぞれの職能用のPBIは別の職能用のPBIに依存していました。 フロントエンドのPBIはバックエンドのPBIで実装されるAPIを待つ必要があります。 QAのPBIはフロントエンドのPBIで実装される画面がなければ開始できません。
この依存関係は、スプリントプランニングにおけるコミットメントも難しくしていました。
例えば、フロントエンドエンジニアがあるスプリントでPBI_Aに取り組みたいと考えているとします。 このPBI_Aは、バックエンドのPBI_Bに依存しています。 バックエンドエンジニアはPBI_Bをスプリントバックログに選択しますが、完了は早くてもスプリント終盤になると言っています。 それではPBI_Aはこのスプリントで完了できないため、フロントエンドエンジニアは別のPBI_Cを選択し、PBI_Aは次のスプリントで対応する計画を立てます。 このようなことがあらゆるPBI間で発生し、「このスプリントでの完了をコミットできないので次のスプリントに回す」ということが多発していました。
お気づきのとおり、これら「各職能用のタスクPBI」は、すべてが完了してはじめてユーザーにとっての価値を生み出せるものです。 つまりこのチームは、フロントエンドエンジニアのタスク、バックエンドエンジニアのタスク、QAエンジニアのタスクと、1つの価値を生み出すために少なくとも3スプリントを要していたのです。
ひとつひとつのタスクPBIはスプリント内で完了できているため問題視されていませんでした。 しかし、ユーザーに新しい価値が届くまでのリードタイムで考えると、最低でも3週間（スプリント期間は1週間でした）が必要な状況でした。
さらに悪いことに、デザインの修正や不具合などは新規のPBIで管理する運用になっていました。 これらは実装したスプリントの次のスプリント以降で発見されるため、リードタイムは4週間前後であると考えるのが妥当でした。
なぜリードタイムが大切なのか？
リードタイム改善の物語に進む前に、なぜリードタイムが大切なのか、考えてみましょう。
リードタイム（lead time）は、生産・流通・開発などの現場で、工程に着手してから全ての工程が完成するまでの所要期間である。
リードタイム - Wikipedia (アクセス日: 2025/6/27 9:00)
リードタイムは一つの価値をどれだけ素早くユーザーに提供できているかを表す指標です。
リードタイムが短いということは、それだけ速くプロダクトに新しい価値を積み重ねられ、ユーザーに届けられるということです。 変化の激しい昨今においては、市場の関心が別の方向に変化してしまう前、つまり賞味期限が切れる前に価値を提供できるとも言えます。
また、より速くユーザーに届けることができれば、より速くフィードバックを得られ、より速く学習機会を得ることにもつながります。 高速なフィードバックループを得ることができるのです。
もっと詳しく知りたい方は、リーンシンキングやフロー効率などを調べていただくと良いでしょう。 私は『This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント』が好きなのでお勧めします。
リードタイムが1/4になるまでの変化
やっと本題です。 このチームのリードタイムが1/4になるまでに起こした変化についてお話しします。
1. PBIをタスクベースから価値ベースに
まず、タスクベースで管理していたPBIを価値ベース、つまりユーザーストーリーベースに管理するように運用を変えました。 タスクベースでは、どうしてもユーザーにとっての価値に対する関心が薄くなってしまいます。 PBIがタスクベースで管理されていては、自分たちが速い価値提供を実現できているのかどうか、定量的にも定性的にも把握するのが難しくなります。
「ユーザーストーリー」を詳しく知らない人のために『アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法』から引用しておきます。
ユーザーストーリーは、ソフトウェア要求を表現するための軽量な手法である。ユーザーストーリーは、システムについてユーザーまたは顧客の視点からフィーチャの概要を記述したものだ。ユーザーストーリーには形式が定められておらず、標準的な記法もない。とはいえ、次のような形式でストーリーを考えてみると便利である。「<ユーザーの種類>として、<機能や性能>がほしい。それは<ビジネス価値>のためだ」という形のテンプレートに従うと、たとえば次のようなストーリーを書ける。「本の購入者として、ISBNで本を検索したい。それは探している本をすばやく見つけるためだ」
ユーザーストーリーをPBIの単位とすることで、必要以上にPBIを分割することを回避し、ユーザーにとっての価値を見失わずに仕事を進めることができます。
新規に作成・管理するPBIについては、ユーザーストーリーを単位とすることをチームのグラウンドルールにしました。 一方で、既存のPBIをユーザーストーリーの単位にまとめ直すのは、ROI（Return On Investment: 投資利益率）が低いと判断し実施しませんでした。 ただし、既存のPBIも散らかっていてPBI間の依存関係が見えにくくなっていたため、同じユーザーストーリーに紐づくPBIは近くに置くなどの整頓は実施しました。
デザイン修正やテストで検出された不具合の管理も変更しました。 今までは、元のPBIはクローズし、新規にPBIを作成する運用でした。 しかし、その対応が完了しないと価値を創出したといえない場合は、元のPBIをクローズせず、サブタスクとして起票するようにしました。 これにより、PBL（Product Backlog: プロダクトバックログ）が現在の価値創出の真の進捗状況を示してくれるようになりました。
もちろんこの変化も簡単な話ではありません。 ただただ「ユーザーストーリーベースに管理してね！」で済むなら最初からそうしていたはずです。 ユーザーストーリーとそれに関連するもの（INVEST、Epic、3C、受入基準、など）について、ドキュメントにまとめて、議論し、共通理解をつくる活動を丁寧に行ったことで、この環境をつくれたと感じています。
2. Definition of Readyの言語化
上記と並行して、DoR（Definition of Ready: 準備完了の定義）の言語化にも取り組みました。 このチームでは、要求事項の確認のために実装が中断したり、実装後にエンジニアとデザイナー間の認識齟齬が明らかになることがよくありました。 これではスプリント（短距離走）というよりロケットランです。ですよね！
この課題を解決するために、チームでDoRを定義しました。今までも人によっては意識していたことをあらためて言語化したものです。
- Figmaで画面イメージが共有できる状態になっていること
- PBIにユーザーストーリーが記載されていること
- PBIに受入基準が記載されていること
- 開発者にとって、スプリント前に明確にしておきたい、かつ、明確にできることが他にないこと
また、このDoRを満たすために、リーダーシップを特に発揮する人の認識も合わせました。 具体的には、画面イメージやユーザーストーリーはデザイナーが、受入基準はQAエンジニアがオーナーとなり、リファインメント前に協働で叩き台を作成することにしました（この取り組みの詳細は、「あるチームの取り組み - デザイナーとQAのストーリーチケットづくり」をご覧ください）。 この取り組みにより、PBIのWhyやWhatはリファインメントで明確になり、スプリント中はHowに集中しやすくなりました。 要求確認のための中断や、実装後の認識齟齬の発生が少なくなったのです。
3. リードタイム・サイクルタイムを可視化する
ここでようやく、価値創造のリードタイム・サイクルタイムの可視化に取り掛かりました。 いままではタスクベースのPBLだったため、リードタイムやサイクルタイムを計測するのが難しい状況でした。そのため、ある程度1、2の取り組みが安定してからこれらの計測に取り組みました。
リードタイムは、あるPBIの実装が始まってからリリース待ちになるまでの時間を計測することにしました。 リードタイムのボトルネックを検査するためにサイクルタイムも計測しました。 サイクルタイムは、リードタイムの計測範囲を「実装開始〜実装完了」「実装完了〜コードレビュー完了」「コードレビュー完了〜テスト完了（= リリース待ち）」に分けて計測することにしました。
平均リードタイムが32日...😅
仮説のとおり、4週間前後のリードタイムであったことがわかりました。
1や2の取り組みの過渡期だったため正確に測定できているとは言い難いのですが、改善傾向が見えるのは上記の意識変革の影響があったのだと思います。
それでもまだリードタイムは2週間前後であり、改善の余地があることがわかります。
4. リードタイムとサイクルタイムをふりかえりにインプットする
リードタイムとサイクルタイムですが、可視化するだけではチームに影響を与えることはできません。 チームメンバーに関心を持ってもらい、リードタイムに対する適応を促すために、リードタイムとサイクルタイムのグラフをふりかえり（スプリントレトロスペクティブ）のインプット情報として活用しました。
私たちのチームでは、ふりかえりの最初に「思い出す時間」を設けていました。 3分間で、瞑想したり、スプリントバックログを眺めたり、前回のふりかえりのボードを眺めたり自由に過ごす時間です。 先ほどのグラフをふりかえりボードに置いておくことで、思い出す時間で目に触れるようにしておきました。 最初のうちは冒頭でコメントを添えたり、注目を集める工夫もしていました。
結果、ふりかえりのトピックとしてリードタイムやサイクルタイムへの言及が増えました。
例えば、コードレビューのサイクルタイムの議論が増えました。 もともとテストに時間がかかっていると感じていたメンバーが多かったのですが、可視化すると実際はコードレビューのほうがより時間がかかっていることがわかりました。
これにより、チームメンバーのコードレビュープロセスに対する関心が高まり、ふりかえりのトピックとして議論されることが多くなりました。
当時、私たちの開発本部内でFindy Team+のパイロットプロジェクトの話があったこともあり、より詳しくコードレビュープロセスの状態を可視化するために、Findy Team+のサイクルタイム分析をふりかえりのインプット情報に追加しました。
このようなインプット情報は、以下のような実験に取り組むきっかけになり、リードタイムを低減することにつながりました。
- コードレビューのレビュアーの人数を減らす
- コードレビューをリアルタイムのモブワークとして実施する
- 作業がひと段落したときに、新規の作業よりも優先順位の高いPBIのコードレビューを優先するグラウンドルールを制定する
5. チームでフロントエンドとバックエンドの越境に取り組む
上記以外にもさまざまなアイデアがふりかえりで出てきました。 そのうちのひとつが「バックエンドエンジニアもフロントエンドのコードを書けるようになったほうがよいのではないか？」です。
このチームでは、歴史的な背景もありフロントエンドとバックエンドのコードはそれぞれの職能のエンジニアしか変更してはいけない暗黙の慣習がありました。 しかし、リードタイムの短縮のための議論の中で、実はこのルールが効果的ではないと感じているメンバーが多いことがわかりました。 そこで、チームとして、フロントエンドとバックエンドの越境に取り組むことにしました。 取り組みの詳細は、ブログ『フロントエンドとバックエンドの開発の越境のためにチームで取り組んだこと』をご覧ください。
上記のブログでも書いた通り、「チームとして」このスキルを獲得することに合意して取り組めたことは大きかったです。 結果、短い期間で求めていた成果を手にいれることができ、「あと少しだけど、〇〇エンジニアの手が空くまで待つしかない」という状況をなくせるようになりました。 この少しの越境は、平均リードタイムの短縮に大きく寄与しました。
6. Sprint PlanningをやめてDaily Planningへ 〜 今日、チームとして何を完成させる？
リードタイムに集中していく中で、しっくりこなくなってきたスクラムイベントがありました。 それは、スプリントプランニングです。 もっといえば、スプリントだったのかもしれません。
リードタイムは改善傾向で、ユーザーに速く価値を提供するためのアイデアも取り組まれてきました。 しかし、チーム内には「スプリント中に終わればいい」という空気がまだあり、コードレビューやテストがスプリントの後半に集まったり、WIP（Work In Progress: 仕掛かり中のタスク）が多くなる傾向がありました。 スプリント中になんとしてもPBIを完成させたいメンバーもいれば、そこにこだわらず持続可能なペースでコンスタントに価値をつくることを大切にするメンバーもいました。 また、まだエンジニアのスキルセットのばらつきもあり、プランニングで1週間のコミットメントを作るのが難しいと感じるメンバーも多かったです。
この状況を眺めていて、「このチームにはカンバンのようなスタイルのほうが合っているのではないか？」という仮説が生まれてきました。 カンバンは、スクラムでいうスプリントのような特定の期間を繰り返すのではなく、優先度の高い価値を高速で作り出すことに集中する戦略です。 今のチームには、「最優先のPBIをどうやって最速で完成させるか」に集中してもらうことが重要なのではないかと感じたのです。
そこで、スプリントプランニングをやめ、デイリーのコミットメントをつくるデイリープランニングに移行することを決めました。 スプリントプランニングは、そのスプリントの目的を明らかにし、それを達成するためのスプリントバックログを作成しコミットするイベントです。 デイリープランニングはそれを毎日その日分やるイメージです。
デイリープランニングで投げかけられる質問は「今日、チームとして何を完成させる？それは、どうすれば完成させられる？」です。 チームは今日完成させたいPBIを選択し、それを完成させるためにどんなコラボレーションが必要かを話し合います。 これはデイリースクラムと同様、15分以内のタイムボックスで行いました。
ちなみに、スプリントプランニングをやめるのはかなり慎重に進めました。 ただただやめてしまえば、今まで得てきたスクラムの良さがすべて消えてしまいます。 個人的にも、うまくいくのかどうかとても不安でした。
そのため、ディシジョンレコードを書き、チームメンバーからフィードバックをもらい意思決定をする方法を選択しました。 その中でも、「よりコミットメントが求められるけど、自分たちにその勇気はあるか？」といったコミュニケーションがありました。 このコメントを見て、ここまでスクラムを実践した中でチームに良いマインドセットが育まれたことを実感し、この実験を推し進める勇気が湧いたシーンでした。
結果、この実験は成功だったと感じています。 チームは今までよりも迷いなく、優先順位の高いPBIに協力して取り組む姿勢が生まれていました。
結果：リードタイムが1/4に改善
結果は以下のとおりです。
改善してますね！ 人の入れ替わりやプロジェクトの状況によって上がり下がりはありましたが、トレンドとしても改善傾向を示せていました。
計測開始時点で32.2日だったリードタイムは、半年少しで3.9日に改善していました。 最初の山を外れ値としても、2月中旬のリードタイムが14.2日でしたので、約1/4に改善できました 🎉
まとめ
このブログでは、半年ちょっとでリードタイムを1/4に改善したチームで何が起こっていたのかを紹介しました。 観察と対話を通した集中するべき課題の発見から、計測、ふりかえり、実験を繰り返し、この結果を得られたことが伝わっていれば幸いです。
このブログに、みなさんのチームの改善を加速させるヒントがあったことを願っています 🤞
ここまで読んでくださり、ありがとうございました ☺️
