久しぶりにスクラムっぽい開発をしていて、感じたメリットを書いてみる
そもそもなぜスクラムマスター資格を持っている僕があえてスクラムをしばらくやっていなかったか
要約すると、スクラムの実行に限界を感じていたから。 具体的には、POとSMを置くことが僕の能力ではどうしてもできていなかった。 人員が常に不足する開発では、POSM設置への効果への疑念が常に付きまとう。 それが、自分の中でやるべきと確信できていれば進めることも可能だったかもしれないが、あまりに周りに成功事例がないこと、自分も成功体験が一切ないことなどからうまく進めることが出来なかった。
なので、いわゆるなんちゃってスクラムをやっている。 が、そのなんちゃってスクラムでも割とメリットあるなというのが本記事の主題。
なんちゃってスクラムをやる前
1ヶ月単位でのサイクルは作っていた。 その中で見積もりと今月これしようということはざっくり決めていた。
Issueは切るものの、それぞれの中のリファインメントはあまり集中的にはやっていなかった。 そのため、進めていく途中で新事実が発覚して、大きく見積もりがブレることも多かった。 また、そうやって月にやろうと決めていたことができないことがかなり、というかほとんどだったが、それに対する振り返りは行っていなかった。インフラという部署柄、割り込みがかなり多く、それがいいわけになってより深い振り返りを行っていなかったのはある。
なんちゃってスクラム再開後
1週間のスプリントで開発を回すようにした。 それで、バックログリファインメント、スプリントレビュー、レトロスペクティブ、プランニングをがっつりやるようにした。
まず変わったのは振り返り。 今まで外部要因があるからしょうがないよねといわば言い訳していたのを、きちんと要因を切り分けてKPTで分析するようにした。 正直ここは効果が半信半疑だった。というのは、僕自身はこの手のKPTが有意義に継続的に回ったことがないため。 が、メンバーの一人が外部の経験からKPTをリードすると今までと違うものが見えて、格段に良くなった。これで週次の改善がきちんと回るようになった。 いま時点でざっくり振り返ると、今まで僕がリードしたKPTがうまく機能しなかったのは、チーム内で協力してやるという意識が薄く個別主義的だったからではないかと思う。そうなると個々人の振り返りになり他人のProblemに意見を出したりTRYを出したりすることとが難しくなり、表面的になる。今のチームはチームの方向性が束ねられているからKPTが機能しやすい。それが現状に対する僕の解釈。
話を戻す。あと変わったのはリファインメント。 今までより格段にIssueの計画へ時間をかけるようになった。 今は1週間のうち、Issue記述と周辺調査に2~4時間程度かけている。 一見かけすぎのようにも思えるが、POがいるスクラムではPOがプロダクトバックログを四六時中いじっていることを考えれば、POのいない僕たちがその分Issue記述・調査に時間をかけるのはやむを得ない。 それに、それだけ時間をかけただけの効果を感じている。 この記事を書いたモチベーションはそこで、Issue記述へ週の活動のうち1/10もの時間を割いているが、そのおかげでスプリントゴールが達成できるようになってきた。それは結果だが、中身の実行も質が格段に上がっている。具体的には、事前に実行計画がかなり詳細に立つことで実行に集中することができ、結果的に総合的な工数が下がった。なぜなら、実行中に見つけたり発見した事実のために再計画する必要がなくなり、迷ったり調査したりの切り替えで時間ガロスすることがなくなったため。あとは、その発見によるリスケからの調整にかかる時間が少なくなったのとも大きい。 加えて、見逃せないのがタスクスケジューリングの点。 今までは調査と実行が事実上平行であったため、実行がどの濃度で必要か、どの程度連続してできるかの確度がかなり低かった。なので、スケジューリングしても発覚した事実で外部依頼が必要になり、スケジューリング通りに進まないということが多かった。 その結果としてスケジューリングがおざなりになり、外部依頼が必要なことが事前に予測可能なIssueをスプリントの後半にやってしまい、スプリントゴールが達成できない、ということが何度か発生した。 今は事前計画を細かくやっているため、予測可能性が飛躍的に上がった。それによりどのIssueで外部依頼が必要かもわかるようになったため、外部依頼が必要なものをスプリントの最初に日にしよう、といった判断が可能になった。また、依存関係のあるIssueなどもわかるようになったので、依存関係があるIssueは先に着手しよう、などのスケジューリングも可能になった。これらのおかげで、仕事の単位時間あたりのアウトプットは結構高まったように思う。
