【アジャイルFAQ 第11回】なぜいつも終わらない？スプリント持ち越しタスクの本当の理由と処方箋

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 第9回から前回まで、見積りと予測の話を続けてきました。今回と次回は、その予測を毎回裏切る2つの常連——持ち越しと割り込み——を扱います。

 毎スプリント、2〜3個のPBIが終わらずに次のスプリントに持ち越しになります。持ち越したPBIのポイントは付け直すべきでしょうか？　また、8割方できているものを「未完了」として扱うのは、頑張ったメンバーに酷な気もします。持ち越しが常態化しているチームは、どこから直せばいいでしょうか？

 質問に3つの問いが含まれているので、短く答えてから本題に入ります。

• 持ち越したPBIのポイントは付け直すべきか——不要です（理由は後述します）
• 8割できたものを未完了扱いにするのは酷ではないか——酷なようですが、未完了です。「ほぼ完成」は、リリースできず顧客に価値をもたらさないという点で、「未着手」と同じです
• 常態化しているチームはどこから直すか——持ち越しを責めることでも隠すことでもなく、原因を分類することから始めます

 持ち越しは失敗ではなく、チームの計画と作業の実態を映す鏡であり大事なデータです。以下、「完成／未完成を二値で扱い続けること」と「持ち越しの原因を種類で分けること」の二つを軸に話を進めます。

 研修や現場で、「スプリント内に完成しなかったPBIは未完了です」「部分的な完成にポイントを計上してはいけません」と指導されたことのある方は多いと思います。そのとき、こんな疑問を持ちませんでしたか？

• 8割の仕事は確かに進んでいる。それを0として扱うのは、実態を歪めているのではないか
• 持ち越しをゼロにするのが目標なら、最初から少なめに計画すればいいだけでは
• 頑張ったメンバーの成果が数字に残らない。士気に響くのではないか

 三つとも、現場の実感に根ざした疑問です。先に結論だけ言えば、未完了の扱いは「頑張りの評価」のためではなく「予測の材料の鮮度」の話です。

• 8割は進んでいても、残り2割の不確実性は0ではない（ということは、進んだと思っている対象が8割かどうかすら定かではない）。
• 持ち越しゼロは目標ではなく、原因を潰した結果として起きること。
• 数字に残すべきは、頑張りではなく完成したかどうか。

 持ち越しがどんな扱われ方をしがちかを見てから、順に戻ってきましょう。

 持ち越しが常態化したチームには、いくつかのアンチパターンがあります。ご自分のスプリントの風景と、重ねてみてください。

その１：出来高計上型——「8割できたので8割のポイントを計上」「持ち越し分は残り2割のポイントに付け直し」という型です。ポイントの合計は長い目で見れば同じになるので、一見、害はなさそうに見えます。けれど部分計上はスプリントごとのばらつきを人工的に潰し、前回見た「幅」を実際より狭く見せます。残り2割に潜むリスクも数字から消えます。しかも「あとちょっと」が3日かかった、いやそれどころか予想以上にズルズルと引っ張られた経験は、誰にでもあるはずです。

その２：黙認型——持ち越しが毎回出るのに、レトロでもプランニングでも議題にならない型です。「まあ、いつものことだから」。持ち越しは記録されず、原因は分析されず、次のスプリントも同じ量を積みます。持ち越しが常態化しているチームの多くは、実はこの型です。遅れも常態化し、遅れていること自体を問題と思わなくなったチームに出会うことも、珍しくありません。

その３：犯人探し型——持ち越しが出るたびに「誰が遅かったか」が問われる型です。以降、持ち越しは隠されるか、言い訳されるか、帳尻を合わされるものになり、原因分析の材料には決してなりません。持ち越しを正直に報告できる空気が失われた時点で、チームは自分の実態を見る手段を失います。

その４：テスト先送り型——業務系の現場でよく見る変種です。実装は終わるが、テストだけが毎回間に合わない。テストの多くが手作業のままで、スプリント内に完成（テスト込み）を収めるスピードが出ない。これを「仕方ない」と受け入れてテストをスプリントの外へ追い出し始めると、システムテストや統合テストがリリース間際に積み上がり、スプリントの見た目をした「テスト先送りの一括開発」ができあがります。
 本当に恐ろしいのはその先です。結局テストに十分な時間はかけられず、頼みの綱のドキュメントも（ウォーターフォールに比べれば）少ない。その結果、不具合は見つからないまま、迅速にユーザーへ届けられます。

 四つの型は、同じ土台の上に立っています。**「持ち越しは、計画を守れなかった失敗だ」**という前提です。この前提に立つと、失敗は小さく見せるべきであり（出来高計上）、触れないほうがよく（黙認）、責任者がいるはずであり（犯人探し）、間に合わない工程は外に出せばよい（テスト先送り）、という判断がすべて自然に導かれます。
 先ほど保留した三つの疑問を、ここで解きます。

 まず、8割を0として扱うのは、実態を歪めているのではないか。逆です。8割を8割として扱うほうが、実態を歪めます。スクラムが「完成の定義」にこだわるのは、精神論ではありません。8割できたPBIの残り2割には、テストの通っていないコード、レビュー未了の設計、結合していないモジュールが含まれています。ソフトウェア開発では、残り2割にこそリスクが集中します。完成／未完成の二値で扱うのは、この「あとちょっとの不確実性」を計画から締め出すための規律です。部分ポイントを計上したり、持ち越し時にポイントを付け直したりしないのも同じ理由で、中途半端な計上はベロシティを実態より滑らかに見せます。持ち越したPBIは元のポイントのまま運び、完成したスプリントで初めて計上する。地味ですが、これが一番嘘のない記録になります。なお、対外的に出来高ベースの進捗報告が必要なら、それは別に出せばよい。ただしベロシティには混ぜないことです。

 次に、最初から少なめに計画すればよいのではないか。半分正解です。前回、確実に入れる分は悲観値で積む、と書きました。それでも持ち越しが出るなら、問題は量ではなく、PBIの大きさか、キャパシティの見立てか、着手の仕方にあります。量を減らすだけでは、見かけは解決したように見えて、本質的な原因は残ったままです（そして、それ以降も繰り返し同じ状況に陥ります）。持ち越しゼロは目標ではなく、原因を潰した結果として起きることです。

 そして、頑張りが数字に残らないのは士気に響かないか。響くとすれば、それは「完成」がチームの成果として認められていないからです。ベロシティは個人の頑張りを記録する数字ではなく、チームが届けたものを記録する数字です。個人の8割を認めたいなら、数字ではなく言葉で認めればよい。数字に残すのは完成だけ、という規律のほうが、長い目で見ればメンバーを守ります。「あと少しなのに」を毎回抱えるより、小さく切って毎回完成させるほうが、はるかに気持ちのよい働き方だからです。

 では、計画を守れなかった失敗という前提の出どころはどこか。計画は守るものであり、未達は失敗であるという、スクラム以前からの規範に根ざしています。線表を引き、遅れを詰め、未達には理由書を出す——多くのメンバーはこの文化を身につけてからスクラムチームにやってきます。責める相手はいません。ただ、スプリントの計画に、この古い規範がそのまま適用されるだけです。

 一方、本来の持ち越しは何か。スクラムはこの規範を反転させます。計画は仮説であり、未達は仮説と現実のずれを教えてくれる観測結果です。
 観測——何が、どれだけ、なぜ終わらなかったかを、そのまま記録する。責めず、隠さず、丸めない。
 検査——持ち越しの原因を種類で分け、繰り返しているものを見つける。「誰が遅かったか」ではなく「今回の持ち越しはどの種類か」を問う。
 適応——種類ごとに、次のスプリントの計画や作業の仕方を変える。分割、キャパシティの見直し、着手の仕方。

 これに照らすと、黙認型と犯人探し型の欠落が見えます。前者は観測を捨て、後者は観測を歪めている。どちらも検査に進めません。「失敗を小さく見せる」から「原因を分類して次の計画に反映する」へ、向きを変えます。この転換が、以下の処方の土台になります。

 ここからは手当てです。分割の技法もキャパシティ設計も有識者の提案は多く、どれを選んでもかまいません…と、毎回言ってますね。そのうえで一つだけ。「分割しました」と言って終わりなら、原因を見ずに量を減らしたのと同じことです。試したあとは、持ち越しの数が減ったか、減っていないならどの種類が残っているかで判断してください。

まず、持ち越しを3種類に分類する
 手を入れる前に、分類から始めます。何につけ、事実を把握するのは、改善への最初の一歩です。持ち越しが毎回出るチームのスプリントを観察すると、原因はおおむね3種類に分類できます。

1. 大きすぎる: PBIが1スプリントに対して大きすぎる、または受け入れ条件が曖昧で「どこまでやれば完成か」が着手後に膨らんでいく
2. 削られた: 割り込み対応や欠員で、計画時に想定したキャパシティが実際には存在しなかった
3. 散らばった: 全員がそれぞれ別のPBIに着手し、どれも8割で並ぶ。着手数が多すぎて完成が出ない

 持ち越しが出たスプリントのレトロで、1個ずつ「1〜3のどれか」を問い、記録してください。3スプリント分たまると、このチームの持ち越しがどの種類に偏っているかが分かり、処方が選べます。犯人探しは分類を歪めます。持ち越しを正直に報告できる空気は、それ自体がチームの資産です。

原因1（大きすぎる）には、分割の技術を
 「1スプリントに収まるか微妙」なPBIは、計画の時点で分割します。分割の切り口はいくつもあります。ワークフローのステップで切る（申請だけ→承認は次）、受け入れ条件で切る（正常系→異常系）、対象データで切る（国内のみ→海外対応）、品質レベルで切る（手動運用前提→自動化）。第4回の言い方をすれば、これらはどれもユースケースのフロー——基本フローと代替フロー——の分かれ目で切っています。分割の切り口を探すとは、フローの分かれ目を探すことです。「機能を薄く縦に切る」（画面からデータベースまでを貫く、細い一本の動線ごとに切る）感覚を掴むまでは、リファインメントに少し多めに時間を使う価値があります。経験則として、1PBIがスプリントの2〜3日分に収まるサイズになると、持ち越しは目に見えて減ります。

原因2（削られた）には、実績ベースのキャパシティ設計を
 割り込みが恒常的にあるなら、それは想定外ではなく想定すべき定数です。対処は第12回（次回）で詳しく扱いますが、要点は、割り込みの実績を計測し、割り込みの枠を計画の中に見える形で持つことです。

原因3（散らばった）には、スウォーミングを
 「新しい項目に着手する前に、終わりかけの項目を終わらせる」を合言葉にしてください。第6回の「ボードの右端から歩く」デイリー——完成に一番近いPBIから「これを今日終わらせるには？」と見ていく——は、そのままスウォーミングの入口になります。複数人が1つのPBIに群がって片づける働き方（スウォーミング）は、個人の稼働率は下がって見えますが、スプリントの完成数は増えます。稼働率ではなく完成を最適化する——アジャイルの中でも直感に反しやすく、そして効果の大きい転換です。スプリントゴールが「積んだものを全部終わらせる」ではなく「この業務がこう回るようになる」と書けていると、どのPBIに群がるべきかも自然に決まります。

テスト先送り型には、テスト自動化への投資を
 この変種の根本対処は、分割やスウォーミングではなくテスト自動化への投資です。テストを人海戦術で吸収する前提の体制が長く続いた組織ほど、この投資は後回しにされがちですが、スプリント内で「完成」できない構造を放置する限り、持ち越しは消えません。自動化への投資については、今後の回で採り上げる予定です。

 「持ち越し＝悪」という感覚は、研修一回で消えるものではありません。線表と理由書の文化を身につけた新しいメンバーが入るたびに、チームに持ち込まれ直します。だからこの質問は、チームが入れ替わるたびに、形を変えて戻ってきます。

 持ち越しを罰するチームは同じ持ち越しを繰り返し、持ち越しから学ぶチームは計画の精度を上げていきます。分かれ目は能力ではなく、未達をどう扱うかの文化です。今回の持ち越しは種類ごとに記録され、次の計画に反映されたか——その一点で、このチームが持ち越しをデータとして使えているかが分かります（念のため: これは社内の計画観の話です。対外的な納期の約束を軽んじてよい、という話ではありません）。

次回: 「割り込み作業はどう計画に入れる？」