始めに
僕はアジャイルな開発手法が好きです。
一歩ずつ改善を繰り返し、より価値の高いプロダクトを作っていく過程が性に合っているのかもしれません。
この記事は、1年半アジャイルな開発手法を体験してきて思ったことをまとめたものになります。
※[宣伝も兼ねて]
この記事は下記のアドベントカレンダー用に作成しています。
新卒2年目の新米エンジニアが書いているので
気になるところがあればバシバシ突っ込みをお願いします。
https://adventar.org/calendars/5231
この記事で伝えたいこと
- スクラムの枠組みの中で改善活動をし続けるための方法
- 変化を恐れずに、積極的に実験していくこと
対象読者
- チーム開発を行っている
- 毎日同じような仕事のスタイルを繰り返している
皆さんのチームは改善し続けられていますか？
我々は複雑で変化の激しい問題に対応し続けなければならない
皆さんはスクラムとはどのような開発手法なのかご存知でしょうか？
スクラムとはアジャイルな開発手法の1つです。
色々なサイトや書籍に内容についてまとまっていますが、ここでは一部分のみ紹介します。
スクラムとは、複雑で変化の激しい問題に対応するためのフレームワークであり
可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムガイドより引用：
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
複雑で変化の激しい状態とは
スクラムガイドによるとスクラムが目指す姿は
可能な限り価値の高いプロダクトを生産的かつ想像的に届けることにあります。
我々、開発チームは責務として価値の高いプロダクトを作る必要があります。
しかし、価値の高いプロダクトって一体どのようなものでしょうか？
例として、皆さんが使っているサービスを想像してみてください。
こんな機能欲しいな。
この機能はいらないんだけど何であるんだろうか？
など機能に疑問を持ったことが一度はあると思います。
ユーザーにとって価値があると思ってリリースされたものでも
世に出てみると様々なフィードバックを受けます。
我々が思っているよりユーザーが求めているものは複雑であり
時期やタイミングによって要望は変化し続けます。
スクラムとは複雑で変化の激しい問題を解決するためのフレームワーク
スクラムではこのような複雑で変化の激しい問題に対する開発手法を仕組みとして提供しています。
細かい説明は省きますが、スクラムではチーム全体でPDCAのようなサイクルを決められた期間内で繰り返し行っていきます。
- Plan (計画) => スプリントプランニング、バックログリファイメント
- Do (実行) => スプリント
- Check (評価) => スプリントレビュー
- Action (改善) => スプリントレトロスペクティブ
ユーザーからのフィードバックを元に、計画、実行、評価、改善を積み重ねていくことで
マーケットの意見を短いスパンでプロダクトに反映し続けていくことが出来ます。
アジャイルな開発手法の比較対象としてウォーターフォールなどの開発手法が存在します。
ウォーターフォールの場合はある程度計画しきったタイミングで開発を行うため
作るものが明確であるものに対しては非常に強い力を発揮しますが
このような複雑で変化の激しい問題に対しては向いていません。
スクラムにおける改善タイミング
スクラムにはスプリントレトロスペクティブと呼ばれる振り返りタイミングが予め用意されています。
スプリントレトロスペクティブでは、1サイクルを通しての振り返りと改善をメインとして行います。
これは非常に素晴らしいことです。
可能な限り価値の高いプロダクトを生産的かつ想像的に届けるという目的を達成するために
現状の開発状況を都度チェックし、改善活動を行うことでより目的に近づくことができるためです。
スクラムを採用しているからといって改善が進むわけではない
改善タイミングが用意されているからと言って、改善が常に進んでいくわけではありません。
上手に課題解決を行ながら進んでいくためには努力が必要です。
「Scrumを適用しようとする者はいずれ、変化の難しさに涙を浮かべてオフィスに向かう日が来る」
なぜなら、Scrumは問題を解決するものではなく、問題を明らかにし、我々の目の前に突きつけるものだからだ。
引用： IN DEFENSE OF MAKING HARD CHANGES by Mike Cohn
チームの成熟度にもよりますが、初期段階の場合は目の前に膨大な量の課題が突きつけられます。
開発チームは課題の1つ1つに向き合いながら改善を繰り返していく必要があります。
TRYを出すまでの過程が成熟していない状態では
あまり効果のないTRYを出してしまったり
最悪のケースでは改善策だけ出した状態で実践しないこともあるでしょう。
次の章からは、1年半アジャイル開発を通して得た改善活動の(個人的な)ベストプラクティスを何点か紹介します。
改善活動のオススメプラクティス
課題の認識を揃える
例えば、ベロシティが下がっていることが課題として上がってきたとします。
その際に、チームの中でこんな状態になったことはありませんか？
- Aさん => ベロシティが下がっている要因はプランニングタイミングにありそう
- Bさん => ベロシティが下がっている要因は各々の作業スピードにありそう
- Cさん => そもそもベロシティって下がってない気がする
A,B,Cの意見はそれぞれバラバラであり、課題に対する認識も異なったものを持っています。
この状態で意見をぶつけ合ったとしても空中線になってしまい、チームとして意味があるTRYは出てきません。
時系列で事象を洗い出す
課題の認識を揃えるためには、時系列で事象を洗い出すことが効果的です。
事象を洗い出すことの目的は以下があります。
- 事象を可視化することで全員の認識のブレが少なくなる
- 本当に課題となっている部分が明確になりやすくなる
下記はあくまでも一例ですが、プランニングからスプリントが始まったあとで
実際にベロシティに関与したであろう事象を時系列で書き出した例になります。
ここで大事なポイントは事象を正しく理解するために、課題に対する影響を可視化しておくことです。
具体的には、プランニングには8時間かかった、ペアプロに2時間使ったなど
課題に対する影響をより具体的な値として表現できていれば、チームメンバー内での認識の齟齬が生まれにくくなります。
TRYの効果検証を行う
レトロスペクティブで出したTRYに対して、以下の状態に陥ったことはありませんか？
- 設定したけど実践するの忘れちゃってた😇
- 効果がありそうなTRYだけど、やってみると負担が大きすぎて幸せじゃないな😇
この状態はTRYが出しっぱなしになっている状態です。
改善活動のゴールはTRYを出すことではなく、チームをより良くしていくことにあります。
TRYとして出した改善案に関しては、スプリント内で効果検証を行っていく必要があります。
効果検証を行うにはどうすればいいか？
TRYに対する効果検証を行うには、以下の状態を評価するテンプレートを作っておくことがオススメです。
- TRYが解決したかった課題を明確にしておき、忘れないように明記しておく
- 実践は出来たのか？
- 効果はあったのか？
- チームとして幸せだったのか？
我々のチームはMiroを用いてTRYを管理しています。
TRYを出したタイミングで効果検証のために以下のようにテンプレートを用意しておきます。
これにより、TRYを設定した目的を忘れることなく効果検証を行うことが出来るため
本当に効果があったTRYなのか、チームが幸せに向かっているかどうかを再確認することが出来ます。
振り返りタイミングはレトロスペクティブだけでは十分ではない
デイリースクラムのタイミングを利用して、短いスパンで改善のサイクルを回し続けよう
あなたのチームではいざ振り返ろうと思っても事象がよく思い出せないようなことは起きたりしませんか？
日々の活動の中で、課題となる事象は小さいものから大きいものまで様々です。
チームはレトロスペクティブのタイミングでスプリントの振り返りを行い、改善に対するアクションを決めます。
しかし、レトロスペクティブには時間の制約があり全ての課題を拾って改善を行うことはできません。
そのため、日々の業務で発生する小さな課題は誰かが主体的に解決する動きが出来なければ埋もれていく傾向にあります。
我々のチームでは上記の問題を解決するために
デイリースクラムのタイミングを利用して小さなKPTを行うようにしました
↓ 改善のサイクルを早く回す
ここで重要なのは以下です。
- 明日から実践できるTRYを決める
- 規模が大きい課題はレトロスペクティブに回す
- TRYには押し進めるオーナーを立てる
我々のチームではデイリースクラムで小さな課題を解決していくことにより
より短いスパンで改善を回すことが出来るようになり
レトロスペクティブのみの時より5倍以上の改善活動を進めることが出来るようになりました。
チームの成熟度にもよりますが
課題が沢山出ている状態では改善のサイクルを早く回すことをオススメします。
最後に
課題に向き合うことは非常につらいことですが
変化し続けるためには避けては通れない部分です。
今回上げたプラクティスは全て言われてみれば当たり前で簡単に実践できるものばかりですが
チームで進めていく以上、意識して継続しなければ直ぐにうやむやになってしまいます。
改善のサイクルを上げながら、沢山実験をしてみて良いチームを作っていきましょう