1. はじめに
常にどうすればもっとも価値のあるプロダクトができるのか考えており、そんな中でもスプリントゴールは支配的な影響があるのではないかと最近感じています。しかしスプリントゴールは難しく、曖昧であってもいけないし、タスクのようになってしまってもいけません。
チーム内でも議論と検証、検査を繰り返し行いながら奮闘していますが、今回はスプリントゴールに関する興味深い記事 Getting to Done: Creating Good Sprint Goals を見つけたので、それを簡易にまとめて見解を追記しながら、僕らのチームでの経験なども踏まえて記事にしました。
引用内容はこのように表記しています
※元記事の引用は区別して記載していますが、意訳した内容のため僕の解釈を含むことを留意してください。気になる方は元記事を読むことを推奨いたします。
スプリントゴールについて課題を感じている方、チームメンバーの指向をプロダクトへ向けたい方などに参考なれば幸いです。
2. 序説
ソフトウェア開発は複雑でわかっていないことに対して完全な計画はできないという前提で、スプリントバックログに対して変化を許容するためにはスコープの交渉可能性が必要かもしれない。スプリントゴールという目標に注力することで、目標達成のために交渉することができるようになる。
スクラムではスプリント毎に計画を立てて開発を進めますが、そのスプリント内でも変化に適応していくことが重要となります。その際、何に対して柔軟性を求めるかというと、目的を軸にして検査と適応をすることになります。スプリントバックログをただ優先度順に消化するのではなく、目的を達成するために変化を許容するということです。
例えば、リファクタリングをする際にテストで抑えてから実装方法を変えるのは、構造的には近いことかもしれません。スプリントゴールがあれば、それを達成するためにスプリントバックログやユーザーストーリーの受け入れ条件の変更は、流動性が認められるのではないでしょうか。
ただ、このスプリントゴールというのはくせもので、設定の仕方や扱い方によっては全く機能しなくなってしまう恐れがあります。実際、僕らのチームでも同じ問題を抱えていた時期がありました。参考にした記事では大きな４つの問題について見解が示されています。
3.1. 大きすぎるスプリントゴール
AとBとCを達成する、みたいなものは集中や柔軟性を犠牲にする。
目的を切り替えて考える際に無駄が発生する。
この状態はスプリントが長く、方向展開の機会を失っている可能性がある。
複数の目的を一度に出してしまうと、検査や発見によって状況が変わったときに、ゴールを切り替えて方向性を変えることが難しくなるということです。AとBを進めたらCに価値がないことがわかった場合など、そのままCをやる必要はないはずです。ゴールに価値がなくなった場合にスプリントは中止されますが、その判断を下し辛い状況を引き起こすのではないでしょうか。
PBI全部やるというのはゴールがないことと一緒。
これはスプリントゴールの目的からすれば自明なことですね。変化を許容できないためNGです。とはいえ僕らのチームでもこういった段階はありました。事前にスプリントゴールについてもっと調べて記事を読んでいればよかったなと今では思います。
ゴールが難しくなさそうな場合、十分にチームが働かないのではないかという懸念は、意味のある方法で貢献することを阻害する。信頼して自己組織化や権限を与えればチームはベストを尽くすだろう。
これはPOが支配的であったり、マネージャーや経営層からの圧力がある場合でしょうか。
うちのチーム内では、そのゴールは簡単すぎないかという意見が出たこともありますが、難易度で決めるのではなく、なぜ今その観点で確約することが重要なのか、という観点で考えるべきだろうという結論に落ち着きました。
3.2. 漠然としたスプリントゴール
スプリント終了時に、ゴールを達成したかしていないか関係者で見解が一致しない場合、ゴールは不明確すぎる可能性がある。プランニング時点で、どうやってゴールの達成を確認するのか、という問いにチーム全員の見解を一致させる必要があり、評価がブレないように可測性のあるゴールにすべき。
これはゴールの振り返り観点の一つになり得ます。もし達成判定の見解が異なる場合、次のゴールの達成確認方法についてより明確に議論することで適応できます。抽象的すぎたり、メンバーによって見解が変わらないよう、事前に認識を合わせることが重要です。これはプランニングポーカーと同様、それなりに時間がかかります。
我々も初期はかなりの時間をかけて議論しましたが、ゴールについて議論することは、メンバー全員の関心をプロダクトに向けることにつながるので、将来的な投資効果は高いです。これもプランニングポーカーと同様で、チームが成長してくると共通認識量が増えるため、決めるための時間はより短くなります。
僕らのチームで課題として上がったのは、方向性は合っているがスクラムチームでは寄与できないようなレベル感で設定してしまうことでした。ビジネス目標に合わせて、〇〇機能によって商材契約率をあげる、などです。契約には開始からおよそ2〜3週間ほどかかる商材であるのに対し、スプリントは2週間のためスプリント中に測定することが不可能でした。また、契約にはさまざまな状勢や顧客の都合が絡むため、チームがコントロールできない範囲を超えてしまい、どれだけ頑張っても達成できない可能性もあり、コミットすることの意義が薄れてしまうこともありました。ある程度堅実に測れるような、チーム内で収まることに注力することは、場合によっては重要かもしれません。
3.3. スプリント中にゴールに意識が向かない
スプリントゴールはみんなからいつでもみえるようにしよう。
スプリント中に意識が向かないのは陥りがちな罠で、実際に僕も身に覚えがありました。スプリントゴールを決めたり達成確認は早期のうちから可能ですが、スプリント中にゴールに対する適応をすることはより難しいことです。
僕らの場合、視認性のためスプリントバックログの一番上にスプリントゴール（Github Issue）を固定することにしました。
※業務のデータは許可取れていないため、個人開発の図を参考に載せています。
デイリースクラムでゴールへの進展について議論しよう。
ゴール達成の可能性について確認し、そのために計画の適応が必要か、スコープを調節すべきか議論しよう。
ベロシティを見えるようにするのと同じように、スプリントゴールを指標として進展をみえるようにしよう。
経緯や履歴はレトロスペクティブでの議論を活発させるだろう。
デイリースクラムではユーザーストーリーの進展やスプリントバックログの消化率に注意が向かいがちです。記事ではデイリースクラムの最後にゴールについて進展の確認をすることが提案されています。僕らは個別のストーリーについて扱うのをやめ、スプリントゴールに対して各自何か課題を見つけたか、ゴールに対して進展はどうか、再計画が必要か議論することにしました。さらにゴールを達成できそうか、そうでないか検査をして、準備が整えばゴール達成できるかどうかの検査に進むことにしています。
また、僕らのチームではスプリントゴール(Issue)のメモ欄に、メンバーからの課題報告や進展があれば残すようにしています。これはレトロスペクティブで改善を考える際の情報として役立ちます。より適切なスプリントゴールを設定するための振り返りを促進するでしょう。例えば、このゴールの確認方法では〜と言う部分が実際には確認できなかったため、〜に対しては〇〇して確認することが必要だ、などのように検査と適応をしていきました。
※業務のデータは許可取れていないため、個人開発の図を参考に載せています。
3.4. スプリントゴールに意味を感じない
スプリントゴールは、チームがなぜインクリメントを作るのか知ることを助け、これは業務へのモチベーションにつながる。
プロダクトを作る人にとって、ゴールをより意味のあるものにしよう。
決めたゴールを達成することに価値があるかどうかは、プランニング時に話すべき重要な観点です。なぜ、今そのゴールを確約すべきなのか、徹底的に議論することで納得性も生まれ、方向性もより良いものになります。しかしやはり時間はかかります。
僕らの場合は、プランニング時に加えさらに、定期的なリファインメントの際、この話をチームで考えるようにしました。なぜなら、リファインメントすべき対象や優先度を決めるには、次のスプリントで何を明らかにしたいか、どんな価値を提供したいか考える必要があり、それはスプリントゴールを考えることに関係するからです。
開発者はユーザーが本当に必要なものは何か知らないし、ユーザー自身も何かしらないことがあるので、仮説検証とフィードバックを得ることを集中しよう。導入しようとしている技術や設計はダメなら方向性を変えられる。転換は早い方が損失は少ない。
こちらは検証の観点です。一つ目はビジネス的な価値、二つ目は技術的な課題であり、自論ですがアジャイルテストの4象限と対応つけると理解しやすいと思います。
右側領域であるプロダクトを批評（Critique the Product）に対し、一つ目であるユーザーが本当に必要なものを得たのかどうかは右上領域のUATに該当します。二つ目である、導入しようとしている技術や設計は有効かどうかは右下領域に該当します。このように捉えると、左領域（Guide Development）については正しく実装することとしてシフトレフトされ、右領域については正しいものを作ることとして、ゴールに対する検査として行われると認識することができます。
僕の理解では、スプリントゴールはある意味でスプリントに対する受け入れテストのようなものであり、それらを積み重ねてプロダクトゴールへ近づいていくイメージを持っています。このように捉えると、テスト技法などのQA観点の発想をゴールの検査に応用できる可能性もあり、夢が広がります。
例えば、右側領域（Critique the Product）をシフトレフトするというのは可能でしょうか。僕らのチームでは、ゴールの達成確認はいままでスプリントレビューで行っていました。しかしその場合、顧客視点のフィードバックを得る回数が少なく、事前に聞いておけば軌道修正してゴールを達成できた可能性がありました。そこで、ゴールの検査は達成できると判断した瞬間にユーザーを呼んで、レビューより前に検査をして問題があればさらにストーリーを追加するなどを図りました。これは効果的に作用し、実際にゴールを達成できる頻度が増えました。このような取り組みはゴール検査のシフトレフトと言えるのではないでしょうか。
4. まとめ
スプリントゴールについて、元記事を参照してさまざまな議論を展開してきました。しかし以降の記事で紹介するように、なかなかこのような議論だけでは実際のプロダクトやチームへの適応は難しいです。この問題に対して、ゾンビスクラムサバイバルガイドの著者の一人であるChristiaan Verwijs氏は、Examples Of Real Sprint Goalsという記事で、実際のスプリントゴールとスプリント中にどのように考えてゴールを決めてきたのかまとめられています。例えば、スプリントゴールが先なのか、スプリントバックログが先なのか。直近の顧客価値を提供すべきなのか、リスクを低減すべきなのか、意思決定の背景にどのような思考があったのかなどです。
この記事は僕らチームでもとても参考になったため、次回は、Examples Of Real Sprint Goalsについて触れながら、本投稿と同様に見解や経験上の話を追記してまとめようと思います。
スプリントゴールについてはまだまだ話し足りないことが多く、今後もこのテーマで色々な観点から議論できればと思います。