はじめに
こんにちは。コミューンのスクラムチームで開発をしているandoと申します！
コミューンの開発チームはスクラム開発を採用しており、2週間スプリントを行っています。
スプリントの終了時には振り返りを通じて改善アクションを出し、日々の業務の中でももっと良くできそうなことがあれば改善するといった形で改善を繰り返しています。
今回はその改善の中から、チームが質とスピードを両立させるために行った改善策を紹介します。
持っていた課題感
私の所属しているチームではそれぞれに対して以下のような課題感を持っていました。
- スピード
- ストーリーをもっと早くリリースできそう
- バーンダウンチャートを見ると、しばらく横ばいで急に下がるような動きになっている
- 考えられる障壁はあるが、チームで収まらない課題も多い
- チーム内で解決できる課題もあるかもしれないが、見つかっていない
- ストーリーをもっと早くリリースできそう
- 質
- テストケースを作りリリース時に動作確認をしているが、まれにケースの実施漏れなどが発生してしまう
- スピードを優先しすぎて品質を疎かにはしたくない
※ 補足
- バーンダウンチャートを見ると、しばらく横ばいで急に下がるような動きになっている
以前の記事に書いてあるようにWIP制限によってバーンダウンするようにはなっていたのですが、仕掛中を増やしすぎない意識が定着しWIP制限を止めた事やWIP制限的な動き方をしてもバーンダウンしないスプリントがあったため、改めてこの課題感に焦点を当てる流れになりました。
やってみた改善の紹介
上記の課題感から、それぞれを代表してやってみた改善を紹介します。
理想線厳守
内容・狙い
端的には「バーンダウンチャートの理想線に沿うようにストーリーを完了させていく」というものです。
バーンダウンチャートと理想線について(chatGPT君に解説してもらいました)
スクラム開発におけるバーンダウンチャートは、プロジェクトの進捗状況を可視化するために使用されるグラフです。理想線とは、あるスプリント期間において、予定された作業量に基づいて描かれる予想の進捗線のことを指します。理想線は、スプリント期間の初めに設定され、チームはその線に沿って進捗状況を追跡していきます。チームが理想線より上に進捗することは、進捗状況が良好であることを示し、下に進捗することは、進捗状況が遅れていることを示します。理想線は、プロジェクトの進捗状況を把握し、スプリント期間中に達成すべき目標を明確にするために非常に役立ちます。
理想線を守ると少なくとも定常的にリリース(ストーリーを完了)していくことになります。
そのため課題感に挙げた「バーンダウンチャートが急に下がる」という動きにはならないので、これを達成することで次にやるべき改善アクションが見えてくるのではないか。というのがこの取組みの狙いになっています。
どうやって実現したか
理想線を守るために、チームでどうすれば実現できるかを考え以下2点をやってみました。
- ストーリーサイズを小さくする
ストーリーの粒度が大きく、完了に必要な作業量が多いと単純に終わるまでに時間がかかってしまいます。
そのため、ストーリーの粒度を小さくして一つ一つのストーリーが完了する時間を短くすることで、細かくバーンダウンさせる=理想線に沿う・超える動きをできるようにしました。
- デイリースクラムで今日達成すべきポイント数を確認する
毎日のデイリースクラムで「今日xxポイント完了すれば理想線到達できる」という点を確認するようにしました。
1日のゴールを明確にし、チーム内で理想線到達に必要なことがなにかという認識を合わせるためです。
やってみてどうか
結果としてはかなりいい具合で、以下のようなものが得られました！
- ストーリーを小さくする
ストーリーを小さくしたことにより各ストーリーのやるべきことが明確になって不確実性が減るというメリットが得られました。
しかし、今回は無闇にストーリーを小さくしてしまったので少し二度手間も発生しました。
ストーリーを小さくする意識は定着しつつあるのですが、上記のような点からもより良い分割の仕方についてまだまだチームで習熟できる余地があるので、今後も続けていきつつ経験を養っていきたいです。
- 1日のゴールが明確になり、計画も立てやすくなった
デイリースクラムで今日完了すべき事柄が明確にわかると、「今日はAを完了させて、Bをここまで進めて明日完了させれば理想線を超えられそう」と日々のゴールと計画を立てやすくなりました。
- チームが盛り上がった
プロセス改善とは別の軸ですが、理想線を超えるぞ！という意識でチームメンバーが結構盛り上がりました。（こういう盛り上がりって大事ですよね）
1日の中で理想線を達成した時にバーンダウンチャートのスクショとともにメンバー一同歓喜していました！
クロスチェック
内容・狙い
- リリース前の動作確認を開発者以外の人が行う
クロスチェックは「リリース前の動作確認を開発者以外の人が行う」といった内容になっています。
課題感で挙げたテストケースの実施漏れに対して、チームでは以下のような仮説を立てました。
開発した本人がテストをすると、ローカル環境での動作確認に慣れていて見落としが発生するのでは
そのためリリース前の動作確認を、変更したコードなどの背景知識が少ない人が行うことによって純粋にテストを行えるため、見落としが無くなるのではないか。という狙いを持ってこの取組みを実施しました。
どうやって実現したか
コミューンの現在のデプロイフローとして、リリース前に一般的にはstaging環境と呼ばれるような環境に変更が一度デプロイされます。
今までその環境での動作確認を開発者本人が行うようにしていたのですが、クロスチェックではここをチーム内の別の人が行うようにしました。
やってみてどうか
やってみた結果として狙い通り見落としやケース確認漏れは防ぐことができるようになりました。
また副次的にテストケースに明確に記載の無いところでも微妙にデザインと違うなど細かい違和感に気づけたり、リリース前に他の人が確認することで開発者本人も安心感が増すといった効果も得られました。
課題点として、やはり一人で進めるのに比べると少しスピードは落ちます。
その要因の一つとしてテストケースの具体的な操作方法などがうまく伝わらない場合などがあるので、今後はそういった点を整えてよりスムーズにクロスチェックができるようにしたいと思っています。
2つを一緒にやってみて
先に挙げた課題感と照らし合わせると、スピード・質の両方においてチーム内で解決できる課題を見つけ、それを改善していくことができました。
それによりスピードを増しつつ品質も担保するという理想的な形により近づくことができたと思います。
しかしながら、課題感の一つであった
- 考えられる障壁はあるが、チームで収まらない課題も多い
こちらのように、改善アクションがまだチーム内の工夫で収まる改善に留まっている側面もあると考えられるので、今後はそういった大きい課題にも目を向け改善していけるチームを目指すのが次のステップかと考えています。
終わりに
コミューンでは「やってみよう」という気持ちを大事にして今回紹介したようなものやそれ以外にもたくさん改善を繰り返しています。
最後になりますが、今回の記事で少しでも興味を持った方がいましたら、今週金曜(4/21)に開催される会社説明会へのご参加、もしくは下記フォームからカジュアル面談の申込みをお願いします！
docs.google.com
