スプリントレトロスペクティブを実施するようになって目に見えて変わったところ2選

事業開発チームの嶋田です。弊社はアジャイルな開発手法を取り入れてまもなく一年になろうとしています。

私自身はアジャイル導入前の状態もよく知っているため、導入前後で大きく変わったところも見てきました。

アジャイルは開発手法として一般的なスクラムを弊社も行っていますが、スクラムの活動の中でもスプリントレトロスペクティブ(長いので以下振り返り)をするようになったことが、エンジニアの意識も大きく変わったところじゃないかと感じています。

今回はその中でチームとして大きく変わったというところを2点上げていきたいと思います。

不具合検知の仕組みがまだまだなところがありますが、最近整備できたことのひとつにHTTPステータスコードの監視があります。

これまでのリリース後の不具合発見の多くは非エンジニアチームの報告が多かったのですが、これによりエンジニア発の不具合報告も数として多くなってきました。

ステータスコードの監視は仕組みとしては少し前からあったのですが、毎日みんなで確認することを振り返りですることが決まり、これにより全員の正常動作に関する意識が高まりました。

少し違和感がある状態があると調査を行い結果的にその周辺でバグを発見したりというケースも出てきて、良い循環が生まれています。

今回ブログを書くにあたって振り返りのログを一通り見たんですが、振り返りがうまく働くとそのチームの問題点が浮き彫りになるのかなとログをみて感じ、自分たちの問題点は曖昧な部分が多かったというのが気づきでした。

スクラムの導入前まではそれぞれのエンジニアが自分たちの力量で細かなところをカバーして運用していくという割合がおそらく他社比でもかなり多かったかと思います。

例えば、ビジネスサイドからのタスクの依頼方法はテンプレートに沿って作ってもらいこれを運用していく形になっていました。

これまでだとこのテンプレートの方法だととあるケースでは分かりづらいなとかあったとしても、報告の場があまりなかったこともあり、その時にエンジニアが追加でヒアリングするなどして対応するみたいなエンジニアがその場その場で臨機応変に対応するといったことがこのケースに限らず多発していました。

しかし振り返りが習慣化したことで、これはあとで振り返りで議題として上げようといった流れができて、曖昧なところがどんどんと解消されていっています。

これによりあとからエンジニアが参加してもキャッチアップの時間が短くなり、より組織としてスケールしやすい体制になりつつあるかと思います。

以上、1年近くスプリントレトロスペクティブを運用しての気づきでした。引き続き組織としてブラッシュアップすべく改善を繰り返していきたいと思います。