この記事はカオナビ AdventCalendar2023(シリーズ1) 13日目です🎉
はじめに
株式会社カオナビ、新卒1年目エンジニアの中村と申します👀
現在は新卒研修として、本配属されるまえにいくつかのチームをOJTとして巡る、みたいなことをやってます。
私がこれまで参加してきたチームの中には、スクラム開発を取り入れているところもあったのですが、スクラム初心者として戸惑う場面がありました。
そのような戸惑いを解消するために、チームの先輩にスクラムについていろいろ教えてもらったり、以前から耳にすることがあった「SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発」を読んだりしてきました。
本記事では入社してからこれまでの間で、スクラムについて「勘違いしてた」と私が気づいたことについてまとめてみます。✍
※ 注意
今回紹介する内容は、あくまで基本的なスクラムの思想や手法について学んで得た気づきです。
具体的なスクラム開発の進め方はチームによって変化していくものなので、「本記事で紹介すること = スクラムの正解」とは限らないという点にご注意ください。
勘違い① 「ストーリーポイント = かかる時間やお金」
バックログあたりの作業の量を表す単位として、「ストーリーポイント」というものをつけます。
ストーリーポイントは、かかる時間やお金から割り出すものだと思っていたのですが、そうではありませんでした。
ストーリーポイントは他のバックログの作業の量と比較しながら、相対的につけるポイントであるべきなようです。
これには、以下のような理由が考えられます。
プレッシャーを与えるものであってほしくないから
ストーリーポイントを具体的な時間などにしてしまうと、それを達成しなければならないというプレッシャーが生まれてしまいます。
そうなると、次のような現象が起きることが考えられます。
- 達成するために突貫工事的な実装になる
- チーム外のプレッシャーに負けて、より小さなポイント（少ない時間やお金）で設定しなければならないと考えてしまう
ストーリーポイントをチームの状況や実力を図るための「正直な指標」にするために、外部のプレッシャーが介入しないものであるべきなようです。
過去のバックログとの相対的なポイントであれば、外部のプレッシャーが介入しない値になり、より正確にチームの状況や実力を測ることができそうです。
対話を生んで懸念点を出しきることが重要だから
ストーリーポイントを決定する手法にはプランニングポーカーなどを用います。
これにより、それぞれが予想したストーリーポイントのズレに気づくことを期待しているようです。
そのズレの理由について互いに意見を交わすことで、バックログをこなしていくにあたっての懸念点を共有することができます。
お金や時間でストーリーポイントを決定してしまうと、実際に作業する人以外がポイントの決定することができてしまいます。
すると、懸念点について共有する機会がないまま見積もりが終わってしまうことが考えられます。
相対的に考えてどれくらいの作業量が発生するのか？というのは、「やる人」しか想像できないという点で意味がありそうです。
正確さよりもスピードを優先したいから
アジャイル開発が求められるようなプロダクトでは優先度、受け入れ基準、時間、予算等が次々に変化していくとされています。
そのように不安定なものの上に立つバックログの見積もりをどれだけ時間をかけて正確に立てても、すぐに意味のない値になりかねません。
複数人で懸念点を出すことで一定の信頼度は担保しつつ、サクッと「このタスクより大変そう」ぐらいのノリで決めちゃえるという意味で、相対的な見積もりは良さそうです。
勘違い② 「自分なんかが...」
- 自分なんかが、みんなわかってそうなことを質問して時間を奪っていいのか
- 自分なんかが、プランニングポーカーに参加していいのか
- 自分なんかが、イベントのファシリテーションをしていいのか
- 自分なんかが...（以下略）
私はこんな具合で「自分なんかが」と遠慮してしまう場面が多々ありました。
しかしスクラムにおいてはできるだけ、そのような考えを捨て、気になることがあったら意見をしてみる「勇気」が必要なようです。
- なんとなくの不安感が、のちのちの大きな手戻りにつながる
- チームの正確な実力や状況、問題点を測ることができない
といった問題を生み出す可能性があるためです。
実際に私がOJTで参加したチームでは、QCさんがプランニングポーカーに参加している場面がありました。
初めて見たときは驚きましたが、確かにコードを書く人とは違う観点からの懸念点を出せるなどの意味で、すごく大事なアクションなんだなと改めて思いました。
この記事を書きながらも100%堂々と意見を出せる自信があるとはまだ言えないというのが正直なところです...。
が、それでも、まずは小さいものからでも少しづつ意見し続けることが大事そうだと思えました。
勘違い③ 「ベロシティは上げるもの」
「ベロシティ」とは、スプリントごとに終わらせられるポイント数を指すものです。
と聞くと「ベロシティが上がり続けるチームは優秀」みたいに思えますがそうではないようです。
ベロシティはそれが上がっているかよりも、安定しているかのほうが重要だとされています。
なぜなら、ベロシティは「先のことを予測するための指標」という側面が強いからです。
ベロシティを見ることで、リリースまでどれくらいかかりそうなのか、といったことを予測したりします。
リリースまでに絶対に必要な機能の見積もりの合計 ÷ ベロシティ
= 残り必要なスプリント数
という感じです。
これが前回は3ポイントだったのに今回は20ポイントだった、という具合だと、あとどれくらいでリリースできるのかというような予測を立てることが困難になります。
なので、開発チームはベロシティを安定させることに努め、予測を立てやすくする必要があります。
また、「ベロシティを上げることが素晴らしいこと」としてしまうと、予測の指標として使いたいはずのものに、ストーリーポイントの部分で書いたものと同様にプレッシャーという要素が介入し、達成のために工作し始めるみたいなことにも繋がりかねません。
『SCRUM BOOT CAMP THE BOOK』では、実はチームの成長はベロシティではない部分に出るといった内容もありました。（例えば同じストーリーポイントでも、チームの成長により、開発スタート時点と数ヶ月後では成果の大きさが違うなど）
ベロシティの上下に過度に一喜一憂するよりも、先のことを予測するための信頼性を保ち続けることを意識するほうが重要なようです。
さいごに
私はこれまで、スクラムをちゃんと勉強することなく、なんとなくイベントに参加していました。
改めて勉強することで、スクラムの様々な要素の目的をちゃんと理解できていなかったこと、誤った解釈をしていたことに気づけました。
参加してきたチームではところどころオリジナルのスクラムからアレンジされている部分もあったので、なぜそうなっているのかを探ってみるのも、チームの歴史や特性が見えてきそうで面白そうです。
今回の記事で取り上げた内容以外にも、スクラムチームに参画するにあたって知っておいたほうがよさそうなことが、「SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発」にはもっとたくさん書いてあったので、まだ読んだことがない人はぜひ一度読んで見ることをおすすめしたい一冊でした！
それでは、次回14日目の記事もお楽しみください！！💪