アジャイル開発で上手にスプリントを運営する４ステップ

「どうしたらアジャイル開発で効果的なスプリント運営ができるのだろうか」

こんな悩みはないだろうか。

ウォーターフォールに慣れ親しんだ人からしたら、アジャイル開発におけるスプリントという概念はかなり新しく映るのででやり方に戸惑うかもしれない。

しかし安心して欲しい。この記事では、そんな悩みを抱える方のためにアジャイル開発を５年経験した筆者がアジャイル開発のスプリント運営の方法を詳しく解説していく。

それではみていこう。

スプリントでやること４つ

この章ではスプリントで行うことを時系列順で４つ紹介する。

ただし、この段階ではイテレーションが始まった段階でのスプリントを想定している。そのため、アジャイル開発において最初に行う、プロダクトバックログの作成はすでに終わっている前提で話を進めていく。

ちなみにプロダクトバックログとは、プロダクト全体の要件や機能に優先順位づけをしたリストのことだ。つまり、プロダクト全体の要件や機能についてはすでに一度定義済みである状態を想定している。

スプリントプランニング

まず最初に行うのがスプリントプランニングだ。スプリントの最初に行うキックオフミーティングのようなものだ。

ここではチームの開発力（ベロシティ）を元に、プロジェクト全体を通して重要なものから開発物を確定していき、最終的にスプリントバックログを作成する。

スプリントバックログを作成するにあたっては、以下の二つに注意が必要だ。
・それぞれの要件の受け入れ要件が定まっていること
・スプリントの期間内で完了できる分量だけスプリントバックログに要件が入っていること

最初の点に関しては、もしそうでなければ、スプリントが完了した時にその要件を完了できたのか判断できないからだ。

次の点に関しては、もしそうでなければ短い開発スパンを切って、スプリントを回していく意味が薄くなってしまうからだ。

ただし、上記はあくまでも原則の話だ。実際には巨大な案件が出てきてしまうこともある。

例えば、筆者が以前担当したプロジェクトでの話だ。そのプロジェクトでは２週間を１スプリントとして運営していた。また、そのプロジェクトは新規開発の案件だった。そのため最初の段階はスピードを重視して、簡易的なDBを使用していた。しかし、利用者が増えてきてプロダクト自体への投資を決めたタイミングで、当時使っていた簡易的なDBからMySQLなどに載せ替えようと言う話が出てきた。

その際には、あえて細かくタスクを切るのではなく、レベルの高いエンジニアに丸っと２〜３スプリント分の大きめの案件をお願いした。

なぜなら、そもそも一人の人間が一貫して全部対応してしまった方が開発生産性が高いケースがあるし、そう言った案件に対しても細かくタスクを分解していくのはPMに余計な負担がかかるからだ。

デイリースクラム

次に行うのが、デイリースクラムだ。これは、日次で行われる短いミーティングである。

ここでは、各開発者が開発状況や、その日にやること、困っていることなどを報告し合う。これによって、各メンバーがチーム全体の状況を把握しやすくなり、早い段階で問題に気づくことができるようになる。

これも実際は、メンバーに目的が浸透していないとなかなかワークしづらい。特に空間的に同じオフィスで働いていて、常にコミュニケーションをとっているようなチームではわざわざこれをやる必要はないかもしれない。

スプリントレビュー

次に行うのがスプリントレビューだ。これは、開発チームがスプリント期間内に開発した成果をクライアントを含めたステークホルダーに見てもらい、フィードバックをもらう場である。

これによって、開発物のお披露目を小さく頻繁に行うことができる。そのため、ウォーターフォールのように納品の直前になってクライアントが初めてプロダクトを触り、実際に欲しかったものと違ったなどの悲劇が起こる可能性を減らすことができる。

スプリントレトロスペクティブ

スプリントの最後に行うのがスプリントレトロスペクティブだ。ここでは、スプリント実施のプロセスについての振り返りを行う。

よく使われる振り返りのフレームワークは「KPT」と呼ばれるものだ。

これによって、スプリントの実施や開発フローについて改善を重ねることができ、より開発チームの生産性を上げることにつながる。

これはとても重要で、楽屋裏トークのような立ち位置にできるとチームの生産性改善にかなり寄与するはずだ。逆に、そう言ったオフィシャル感のないものにできない場合はあまり効果を発揮しづらい。

まずは、あまりワークしなかった例について語る。前職での話だ。そこでもKPTを行っていた。しかし、KPTではほとんどチームの生産性を上げるための発言は出なかった。結果として、毎週やっていたのだが１時間でカレンダーに登録はされているが、実際は１５分程度で事務的な共有事項がなされて終わるだけのことが多かった。

これは、通常業務ではチームとして一体となって活動していると言うよりは、個々人が個別に動いている開発者の集まりだったし、尚且つKPT自体にオフィシャル感があったためではないかと考えている。

反対に、うまくワークしているなと感じた例についてだ。これは、以前関わったプロジェクトでの話だ。そこでは２週間に１度、1.5時間程度の振り返りの時間をとっていた。

そのプロジェクトでは全員が活発に発言をしていて、毎回少し時間をオーバーするくらいの盛り上がり方だった。具体的には、様々な観点からチーム内外に向けた改善案の話が出ていた。また、各人のスキルアップという観点から、そのスプリントで行ったインプットに関する共有の時間も設けられていたため、積極的にメンバーはスキルアップに取り組んでいたしそれを喜んで共有していた。

これは、このチームが３人チームで密にコミュニケーションをとっていたことや、またKPT自体も業務以外のことについて話したりとオフィシャルな感じがなかったためではないかと考えている。

スプリント運営での注意点

ここではスプリント運営で気をつけたい点を２つ紹介する。

それぞれ見ていこう。

やるべきことを詰め込みすぎない

まず１つ目は、一つのスプリントでやることを詰め込み過ぎないという点だ。

スプリントでやることが多すぎる場合は以下のどちらかの状態に陥ってしまう。
・チームがそのタスクを終わらせるために疲弊する
・スプリント内でタスクが終わらないことが常態化しスプリントで設定されるタイムスパンが無意味になる

特に後者に関しては、スプリントのメリットの以下２つを捨てることになってしまう。
・スプリントという身近な締切があることによる開発生産性の向上
・要件の変更に柔軟に対応できるというメリット

なぜならスプリント内でタスクを終わらせる意識が薄れると、自然とタスクのバッチサイズが大きくなってしまう可能性があるからだ。その結果、一つの案件が１ヶ月を超えるようなものが出てきて、小回りの効かないプロジェクト運用に陥りかねない。これは要件の変更に柔軟に対応できるというメリットを捨てることになる。

形式的な会議を行わないようにする

スプリント運営での注意点の２つ目は、「形式的な会議を行わないようにする」だ。

アジャイル開発のスプリントについては、インターネット上にたくさんの情報が出回っている。そのため、ある程度やるべきことが把握できると思う。この記事でも、アジャイル開発において行うべきイベントを４つ挙げた。

しかし、それらはそれ自体を行うことが目的ではない。そのイベントが目的としていることを実現するための単なる方法だ。

そのため、チームの状態としてそのイベントがなくても、目的を達成できるのであればあえて開発時間を減らしてまで前述のイベントを行う必要はない。

例えばアジャイル開発だからと言って、必ずデイリースクラムを行う必要はない。デイリースクラムの目的をチームで以下のように分解したとしよう。
・毎日チーム内で会話をすることで、情報共有のしやすい状態を作る
・毎朝その日にやることを発表することで、始業と同時にやるべきことの認識ができている状態を作り上げ、1日の生産性を上げる

しかし、そもそもチーム内のコミュニケーションが活発だったり、他の方法（タスク管理ツールなど）で一日のタスクを各人が把握しやすい状態が作られている場合には、デイリースクラムに時間を使う必要はないだろう。

目的や狙いがあいまいな会議が増えれば増えるほど開発者の時間は奪われ、開発生産性が下がっていくからだ。

実際、筆者の前職でも似たようなことがあった。ある日突然、デイリースクラムが導入されたのだ。

もともと３人チームでコミュニケーションが活発だったし、各人のタスクもタスク管理ツールを使って可視化されていた。そのため、筆者としてはなんの課題も感じていなかった。

しかし、特に狙いや目的も説明されないままデイリースクラムの運用が始まった。その結果、メンバーがタスクを何となく発表するだけの場になってしまい、そこでの会話から何かが生まれることもなく２週間でその運用はストップした。