例えばなんらかの大きな機能をリリースする必要がある場合、こういう風に考える人は多いです。
「このプロジェクトを終わらせるには何スプリントかかるんだろうか？」
これは大いなる間違いです。
「どのくらい要件を削れば今スプリント中にリリースできそうかな？」
スクラムとは、本来はこう考えるフレームワークなのです。
スクラムにおけるスプリントは、価値あるインクリメントを生み出すための固定長のイベントです。
多くのチームがこれを単なる「開発期間」と捉えがちですが、本質は異なります。
スプリント = バーンダウンチャートのX軸という誤り
よくある失敗は、「この大きな機能を作るのには何スプリントかかるのだろうか？」という発想です。
これはウォーターフォール的な計画をスプリントに分割しているだけで、アジャイルの本質を見失っています。
計画ありきでスプリントを「小さめのマイルストーン」として消費していくアプローチでは、予測不能な変化に対応できません。
結果としてスプリントゴールを達成できない、あるいは価値のないものを生み出すリスクが高まります。
またチームが「価値」というものにフォーカスする機会が奪われるため、自己組織化は促されません。スプリント毎に、チームは何を成したのか？という問いかけができないため、ケイデンスの算出もおぼつかないでしょう。
結果として、なんとかリリースはできても「なんかスクラムってミーティングとか儀式多くてメリットなくない？」という結論が出てしまいます。
選択と集中
真のアジャイル、スクラムにおけるスプリントは
「私たちが達成したいこと（プロダクトゴール）に対して、今スプリントでどのような具体的な価値を提供できるか？」
という問いから始まります。
これは、選択と集中の考え方です。完璧を目指すのではなく、今できる最も価値の高いことに集中し、動くソフトウェア（インクリメント）を確実に生み出すことを目指します。
これはスクラムの原則のひとつ、「リーン主義」として説明されています。
仮に過去に類を見ないレベルで難解で複雑怪奇な機能であったしましょう。
それでも要件を削ぎ落とし、非機能要件を一旦無視すれば1スプリントでなにかしらリリースすることは可能です。
アジャイルやスクラムの世界では、リリースされていないコードやテストされていないコードは「在庫」であり、価値を産んでいないと見なされます。
ユーザーに成果物を実際に使ってもらう、というのはスクラムを支える三本柱のひとつである「検査」の究極系でしょう。
とはいえ毎スプリント必ずリリースしなければいけないというのは現実的ではありません。
スクラムガイドを杓子定規的に解釈するならば「スプリントの生成するインクリメントは（ユーザーが）利用可能であること」となりますが、例えばまだ顧客がついていないプロダクトでそれは不可能です。
なので、例えば正式リリース前の社内テスト（ドッグフーディング）のためのプライベートリリースなども、広く捉えれば価値を提供する行為として許容されていることがおおいようです。
イテレーション！イテレーション！イテレーション！
つまり
「あと何スプリント後にそのプロジェクトは完成する？」
という問いは成り立たないことになります。
スプリントごとに「完成」しているからです。
最初にインクリメントと書きましたが、常に完成し、改善され続けるのです*1。
顧客に正式リリース可能かどうか、という問いは可能ですが、これは「判断」の問題になります。
言葉遊びめいてしまいますが「いける」と判断さえすればどんなものだってリリースは可能です（買ってもらえるかどうかは別ですが）。
しかしここまで毎スプリントごとに価値を提供していきたチームであれば、イテレーション毎に出せる「出力」というのが肌感覚で理解できるようになっているでしょう。
こうなってきてはじめて
「プロダクトのクオリティが貴方の求める基準を満たすのは3イテレーション後くらいですかねえ」
という会話が可能になってくるわけです。
これを無視して
「6ヶ月後の目標までにこれこれというプロジェクトを完成させるためには機能A〜Gが必要で、一ヶ月ごとにマイルストーンをおいて、スプリントは1週間だからだいたい1スプリントにはこの進捗を出さないといけなくて、でもテストの期間とか修正の期間とかアレコレあるからバッファもおいて、お腹も減っておやつ食べたくてアッそういえばお風呂掃除やってなかったていうかバスタブクレンジング切れてたし詰め替え買わないと」
とか考えだすチームは非常に多いです。
こうやって文章におこすと
「いやいやそれってウォーターフォールじゃんw オフwwいまどきそんな間違いする人いませんってww」
と判断できるのですが、そうやってウォーターフォールをバカにしてきた人がいざ渦中にはいると「スプリント計画」とかいってスクラム語で書いたウォーターフォールを書いてしまうのです。何度もみてきました。
まとめ
おそらくウォーターフォールの考え方は「人間にとってあまりにも自然」なんだとおもいます。
とにかくあまりにも馴染むのかわかりませんが、この考え方の癖を矯正するのはかなり難しいです。横で一年間異議を唱え続けても直らないくらいキッツい癖です。
また「1スプリントで完成させられるレベルにまで仕様を削ぎ落とせ」というのは、いうのは簡単ですがどうも難しいようです。
あれもこれも必要、あれがないと文句を言われる、あれがないと怒られる、あれがないようじゃあ完成とは言わない、これがないと評価はできない、そんなんじゃどうも収まりが悪い……
これを真面目と捉えるか、勇気がないとするべきかはわかりませんが、ゴールまでの道のりが壮大で遠く険しいほど、最初の一歩はむしろバカみたいに小さなステップで刻まなければならないのです。
スクラム系ウォーターフォールが陥る一つの特徴としてプランニングやリファインメントにかかる時間が無限に肥大化し、かつチームが何かを得た実感をもてないことです。そういうチームでは2日くらいかけて堂々巡りの議論をした挙句に話がまとまらない、だから簡単な確認事項共有だけして作業者に丸投げ、なんてことになりがちです*2。
「リリース」をひとつの点として捉え、スプリントをその通過点とするような考え方ではそうなるのは必然です。
たとえば数ヶ月かかるようなプロジェクトがあったとして、その計画をはじめにこなすのです。杞憂の連続、あるいは見落としの連続でしょう。
リーン主義を実践し、今スプリント分の価値に集中してはじめてプランニングなどのセレモニーは機能するのです。
さて、この記事では少々極端にスプリントについて書きましたが、これだって
- 僕の理解が間違っていたらスプリントガチ勢に刺されちゃうかも……
- ていうか現実的には色々と事情があって完璧な実践は難しいでしょ
とかクヨクヨ考えて予防線を張りまくると10万文字くらいのクソ長い割に多方面へ配慮しすぎて結局コイツ何が言いたいのかわからねえよブログになっちゃうわけです。
まあなんだ、つまり勇気を出して刻んでいけってこと。
