スプリント計画

スプリント計画の軸は「この期間で何を成し遂げたいのかを、関係者の間で一致させること」です。開発を始めてから認識がずれると手戻りが増えるため、着手前に方向をそろえる場として置かれます。中心に据えられるのがスプリントゴールで、個々の作業項目の寄せ集めではなく、終わったときにどんな状態になっていたいかを一文程度で言い表したものです。

この場には主に三つの役割が関わります。プロダクトオーナーは優先順位と「なぜ今これなのか」という背景を持ち込み、開発チームは実現可能性と作業量の肌感覚を持ち込み、スクラムマスターは議論が噛み合うよう進行を支えます。PMとして関わる場合は、期日や他部署との依存、予算の制約といった、チームの外側にある事情を早めに共有する立場になりやすいです。

つまずきやすいのは、ゴールを立てずに作業項目だけを並べてしまう進め方です。項目の消化自体が目的化すると、終盤で優先度の判断ができず、全部を中途半端に抱える形になりがちです。先に「このスプリントで何を確かめ、誰に何を届けるのか」を言葉にしておくと、途中で取捨選択を迫られたときの拠り所になります。

進め方の軸は「狙いを決める前半」と「やり方を具体化する後半」の二段構えです。前半では、プロダクトオーナーが優先度の高いバックログ項目とその背景を説明し、チームと一緒にスプリントゴールの候補を絞ります。ここで扱うのは、顧客に届く価値や検証したい仮説といった粒度で、作業の細かさには踏み込みすぎません。

後半では、選んだ項目をどう実現するかを話し、必要な作業をタスクへ分解してスプリントバックログを作ります。たとえば一つの機能について、設計・実装・テスト・確認といった工程を書き出し、依存関係や着手の順番を確かめます。この過程で「思ったより重い」「前提が足りない」といった気づきが出れば、扱う範囲をその場で調整します。

見積りには、作業時間を直接積む方法と、相対的な大きさを示すストーリーポイントを使う方法があります。どちらを採るにせよ、過去のスプリントでどれくらい消化できたかという実績を手がかりにすると、無理のない量に近づけやすいです。つまずきやすいのは、空いている時間をすべて作業で埋めようとすることです。割り込みや調査で予定は崩れるものなので、余白を残しておく方が現実に即します。

この節の軸は「計画が形だけになる典型的な崩れ方」です。まず多いのが、詰め込みすぎです。全項目を今回で終わらせようとすると、見積りが楽観に寄り、終盤で未完の項目が積み上がります。結果として、次のスプリントに持ち越す判断が遅れ、計画の信頼が下がっていきます。

次に、準備不足のまま臨むケースです。バックログの項目があいまいなまま計画に持ち込むと、その場で要件を考え始めることになり、時間ばかりかかります。対策として、計画の前にバックログを見直して並べ替える時間（リファインメント）を別に設け、受け入れの条件や不明点をあらかじめ洗っておく進め方がよく採られます。

三つ目は、PMが期日だけを強く押し込む形です。外からの納期プレッシャーは実在しますが、それをゴールの質に変換せずそのまま量として要求すると、チームは機械的な作業消化に向かい、完成の基準が下がります。期日を伝えること自体は必要で、そのうえで何を削り何を残すかをチームと一緒に決める姿勢が、計画を実務的なものに保ちます。見積りが外れたときに責める空気を作らないことも、次回の精度に効いてきます。

軸は「計画という言葉が指す範囲の広さ」です。スプリント計画はスクラムの一つのイベントを指し、一回のスプリントに絞って話します。これに対してプロジェクト全体の計画やマイルストーン計画は、数か月から年単位の見通しを扱い、スプリント計画はその中の短い一区切りを具体化する作業にあたります。両者は入れ替わるものではなく、長い計画が示す方向の中で、短い計画が目の前の手を決める関係です。

成果物の面では、プロダクトバックログとスプリントバックログの違いが要点です。プロダクトバックログはプロダクト全体でやりたいことを優先順にためた一覧で、プロダクトオーナーが管理します。スプリントバックログは、そこから今回選んだ項目と、それを実現する作業タスクをまとめたもので、開発チームが日々更新します。スプリント計画は、前者から後者を切り出す場だと捉えると位置づけがはっきりします。

また、スプリント計画とふりかえりやデイリーの場も混同されがちです。計画が前を向いて段取りを決めるのに対し、ふりかえりは終わったスプリントの進め方を見直し、デイリーは日々の状況を合わせます。それぞれ目的が違うため、計画の場で過去の反省を長く話し込むと本来の段取りが薄くなる、という崩れ方に注意が要ります。

スプリント計画を扱えることは、アジャイルな開発現場でPMとして立ち回る土台になります。ここで問われるのは、期日や予算といった外側の制約を、チームが動ける具体へ翻訳する力です。納期をそのまま作業量として押し込むのではなく、何を残し何を削るかをゴールの言葉に変えて合意できる人は、開発チームとの信頼を保ちながら進行を担えます。

転職を考える場面でも、計画の中身を語れるかどうかで印象は変わります。項目を並べた経験ではなく、優先度が競合したときにどう判断し、見積りのずれをどう次に生かしたかを具体的に話せると、プロセスを回せる人物として伝わりやすいです。ウォーターフォール型の計画やマイルストーン管理と対比しながら、短い区切りで調整を重ねる進め方を自分の言葉で説明できるよう整理しておくとよいでしょう。

スプリント計画にはどれくらい時間をかけますか。

スプリントの長さに応じて調整するのが一般的で、期間が短いほど計画も短く収めます。長く話し込むより、前半でゴールを決め、後半で作業を具体化する二段構えを守る方が実務的です。足りない情報は事前のバックログ見直しで埋めておくと、当日が間延びしにくくなります。

PMとスクラムのプロダクトオーナーは何が違いますか。

PM（プロジェクトマネージャー）は期日・予算・体制・他部署との調整など全体の進行に責任を持ちます。プロダクトオーナーは何を優先して作るかの判断に責任を持つ役割です。スプリント計画では、PMは外側の制約を持ち込み、優先順位はプロダクトオーナーが示す、という分担になりやすいです。

計画どおりに終わらなかったらどうしますか。

未完の項目は無理に当てはめず、次のスプリントで扱うかどうかを優先度から判断し直します。大事なのは原因を責めることではなく、見積りのどこがずれたかをふりかえりで確かめ、次回の計画に反映することです。崩れ自体は想定内として扱う方が、計画の精度は少しずつ上がります。