「終わりがない戦いで辛い」をストーリーポイントの導入で終わらせる
今回は、私が所属する開発チームに導入されたストーリーポイントの概念と効果を振り返りまとめつつ、さらなる課題の抽出・提案も記していました。
元々のチームの状態（before）
私の所属するチームは、開発者3人とPM（リーダー）1人という小規模な構成でした。PMがマネージャーレイヤーの人だったこともあり、基本的に開発者3人があれこれ考えて開発を回していくスタイルで、開発プロセスも特に整備されていませんでした。各々が与えられたタスクをただこなしていく、そんな日々でした。
当時抱えていた最も大きな課題は、1週間でどれだけの開発ができるのか、誰もイメージできていなかったことです。タスクが終わればまた次のタスクが降ってくる。計画性もなければ、チームとしての一体感もない。ゴールが見えないので、その日の開発をどこまでやれば良いのかもわからず、いつ仕事を終えれば良いのかも判断できませんでした。私の場合は、休みの日もずっとこれが頭から離れず、正直全然休めていなかったのを覚えています。
そんな状況を見かねたPMは、ストーリーポイントを導入しようと提案します。
ストーリーポイントとは
アジャイルのストーリーポイントとは？メリットや導入の4つのポイントも解説
ストーリーポイントは、アジャイル開発チームがプロジェクトのタスクを評価するために使用する相対的な指標です。この指標はタスクの複雑さや必要な労力、リスクなどを数値化し、時間ではなく相対的な基準に基づいて評価するというものです。
ストーリーポイントとは対象の規模や大きさを表す相対的な数値であり、複雑さやリスクを踏まえたものである
ストーリーポイントの導入で起きたこと（after）
ストーリーポイントの導入は、思っていたよりもすんなりと進みました。スプリント開始前に1週間でこなすストーリーポイントを目標として定め、それに向かって開発を進めていく。たったこれだけのことですが、チームに大きな変化をもたらしました。
（とはいえ、アジャイルスクラムに関する一定の知識がないとなかなか厳しいと思うので、SCRUM BOOT CAMP THE BOOKなどを読むとイメージしやすくなるかもです。）
最も大きな変化は、日々の開発の中で順調か遅れているかが判断しやすくなったことです。「今週は30ポイントが目標。今日までで20ポイント消化できてるからOK」といった具合に、ゴールに対する現在地が可視化されました。
これにより、土日を迎える際の心理的な負担が劇的に軽減されました。目標に対して順調に進んでいれば、安心して休日を迎えられる。しっかりリフレッシュできるようになったのです。（逆にビハインドしているときは気が休まりませんが...笑）
見積もりの方法としては、スプリントの境目に行うプランニング（リファインメント）の際に、PMと技術力のあるメンバーが相対的に数値を提案し、みんなが納得したらその値で確定する形を取りました。最初は手探りでしたが、3スプリント目くらいから感覚が掴めてきて、「このチームなら1週間で大体このくらいのポイント数をこなせる」という目安が見えてきました。
私たちはその目標値を徐々に上げていくことで、生産性を上げるマインドで日々精進していました。
とはいえステークホルダーにとってはなんの価値もないかもしれない
ただこれで満足してはいけません。ここからはおまけになりますが、本当に開発チームをより良くするための（楽しい）戦いはここからです。
私個人の見解ですが、ストーリーポイントを導入しても残るのは、ストーリーポイントとか、ステークホルダー（クライアント？）からしたらどうでも良いという現実です。
多分クライアントはこう思います。「ストーリーポイント？何それ？」、
「とにかくリリースして価値を提供してほしい」...など。
また、個人個人にストーリーポイントを設定していると、各々が自分の目標を達成しようと動くため、チームに一体感が生まれるかと言われればそれは別問題です。
さらに、ストーリーポイントを稼ぐために、細々として「今やらなくても良い」という課題を差し込みたくなりがちで、ここはしっかり本質を捉える必要がある。
最近私は（マネージャーのサポート付きですが）PMを任されるようになり、色々策を考えました。
そこで私はリリース目標を設けることを提案しました。
（その他にも様々な働きかけがあり、それがチームに良い作用がもたらされています。これらについては別途記事で言及したいです。）
リリース目標も設ける
1週間（1スプリント）でリリースするものを、プランニング（リファインメント）の段階で決めます。もちろんストーリーポイントのベロシティを踏まえて、リリースできそうなチケットをピックアップします。
これを設定することで、個人の目標を各々が独立して目指すのではなく、チーム共通の目標の視点で動けるようになります。「何々をいついつまでにリリースするためには、いついつまでに動作確認依頼をステークホルダーに出して、それまでにPRを上げて...」というように、逆算してスケジュール感を掴みやすくなります。
実際に導入してみて効果も感じています。ステークホルダーに対してリリースという価値を提供することを意識して動けるようになりました。
最後に、スクラムに正解とかなくてチームごとの最適化を目指していくのが良いのだよという話
アジャイルスクラムは手段という話をしたいです。書籍や一般論はたくさんありますが、あくまで選択肢だと思っています。チームにとって肌触りの良いものを取り入れて、最適化を目指していく。そのためにスクラムイベントには振り返り（レトロスペクティブ）が設けられています。振り返り改善の繰り返しです！💪
Discussion