改善Dayが想像より良かった話〜技術負債適切に返せてますか〜

こんにちは！初めてブログを執筆する三谷です。
普段は運用広告向けプロダクト開発チームでエンジニアリングマネージャーをしています。

今回はチームで取り組んでいる改善活動について紹介していきたいと思います。

こんな人に読んでほしい！
負債が溜まり返済したいけど新規開発に追われて時間が取れず悩んでる方

こんな人は読まなくて大丈夫！
負債の返済は計画的にできていてシステムは健全な状態を保てている方
恐らく貴方にとって有益な情報はでてきません。回れ右して有益な記事を探しに行きましょう！

背景〜チームの課題〜

私達のチームでは、複数のサービスを開発・運用しています。
中には年数の経った古いシステムや、デリバリー優先の名目の元にテストコードが足りないままローンチされたシステムがあります。
改善したいことは多くあれど整理もされておらず、限られた時間の中ではビジネス的なニーズを優先しがちになっていました。

いつまでも解消するビジョンが見えない毎日を過ごしていたところから話は始まります。

結果から言うと、現在は改善Dayをチームで決めて改善活動に取り組んでいます。
改善Dayを設定しても上手くいかないんじゃないか、と思いましたか？私は思っていました。
ですが、幸いなことに現時点では継続して成果を出せています。

チームに受け入れられ継続できた理由を振り返りつつ紹介したいと思います。

チームの一人ひとりが課題を認識し「解決したい」という思いを持つことが一番重要だと考えています。

まず課題の整理から始めるべく DX Criteria を利用しチームの状態を計測することにしました。
結果として「なにが不足しているか」という客観的な評価をチームの共通認識として持つことができました。

一例を上げると プロダクトの半分以上のモジュール/クラスファイルに対して、ユニットテストが存在しているか という項目で基準を満たせていませんでした。
テストコードが足りないことは感じていましたが、指標としてはっきりとNGを突きつけられると課題として共通認識が持てますね。

※DX Criteriaについての詳細は、内田さんが紹介している記事がありますのでよろしければご参照ください。

課題が明確になったところで、目標として「テストカバレッジ率を上げる」のように決めて走り始めました。
当初は改善Dayのような仕組みを設定せずに開始しましたが、うまく時間を作ることができず進捗は良いものではありませんでした。

下のKPTAは実際の振り返り内容です。

f:id:AdwaysEngineerBlog:20210716114127p:plain

見てわかるようにメンバーのもどかしさが伝わってきますね。
四半期をかけて失敗したしたことで、どうにかしたい思いが色濃くなり改善Dayを設定することにしました。
ここでメンバーからの要望として上がったことも継続できた大きな要因だと考えています。

改善Dayを開始するにあたってルールを設けました。

これだけです。

改善の内容には言及していないため、テストコードの追加でもリファクタリングでも何でもOKです。
忙しいと他の業務をやってしまいがちになるので、改善したいという動機を思い起こさせるルールにしてみました。
やらざるを得ない仕組み作りって大事ですよね。

(もちろんスプリント計画では改善Dayの時間を考慮した見積もりにしています)

この様にして改善Dayを初めてたことによって改善活動を続けることができました。
テストカバレッジ率が30%前後だったサービスも、執筆時点では60%に届きそうです。

ただし改善Dayが万能というわけではありません。この取り組みでは小さな積み重ねが実を結ぶ活動に適しているため、纏まって大きな時間を使って一気に進めるような性質のものには合いません。そのようなものは体制を作って進める必要があるため、将来的に計画して順番に倒して行きたいと思います。

改善Dayが上手く回るまでの取り組みを振り返ると、改善活動を続けるには以下のサイクルが重要だということに気づけました。

組織の特性によって改善Dayが必要なのか、それとも別の取り組みが合うのかは様々かと思います。
ですが、「課題の可視化」〜「活動を振り返り仕組みを改善する」については共通して重要なサイクルでしょう。

この記事が改善活動を始めようという誰かのお役に立てれば幸せだな、と思いを馳せながら晩酌に勤しみたいと思います。