こんにちは、こんちゃん(@konchanSS)です。
今回はZucksアドプロダクト事業本部で、2年ほど前からはじまった負債カンバンを作成する動きから
負債返済へのアクションを起こして1年経ったのでそれを振り返ったものです。
負債カンバンとは
負債カンバンとは簡単にいうと、弊事業部にあるさまざまなサービスの負債をまとめたものです。
なぜ始まったかというのはゆっけ(@karahiyo)さんのtech blogを読んでもらえるとよりわかります。
以下、記事から抜粋したものです。
苦手なこと 課題とは認識しつつも対応が進まない、優先順位があがりきらないタスク
どこにどんな技術的負債があるか把握しきれていない
気づいたタイミングでの根本的な負債返済の対応は簡単ではない
運用期間が長くなり、当時の最適解が今の最適解と違ってきているものがある
具体的に負債をどのように管理しているかも記事から抜粋したものを貼っておきます。
スプレッドシートには次のようなカラムがあります。
カラム名 説明 やりたいこと 例: 〇〇のバージョンアップ 課題 サポート期限やバージョンアップを今していないことで開発・保守運用が難しくなっている具体的な課題、影響をあげる github issue url 弊チームではgithub issueでチケット管理してます 優先度 S, A, B, C 戦略 ゴールの確認とその道筋をブレスト。難しい仕事が多いのでこのタイミングで第一アクション、最初のゴールをすり合わせできているとうまくいきやすいかなぁと 記載者 私です ステータス 対応中 進捗 最高です やる人 私です
その他細かい経緯については下記の記事を参照してください。
負債カンバンはどうだったのか？
半年ぐらいで一度振り返りを行い、良かった事としては以下が上がってきました。
- 実際やってみてチーム間で負債に関して共通認識ができた
- 意外と自分だけじゃなくてみんな辛かった
- ビジネスサイドにもちゃんと温度感とか伝わった
- それによって前よりも負債改善はしやすくなった
- 新規機能作っている時にできるだけリファクタリングできるところはリファクタしている
- これは元々弊チームでこれまでやってきたこと
- 認識することでより一層意識するようになった
一方で課題も出てきた
- EOLが決まらないと始まらない負債返済
- 結局やって終わり、負債防止まで手が回らない
- 1つ1つの負債がなかなかヘビーで手がつけにくい
- RDS移行, 言語のバージョンアップ, フレームワークのバージョンアップ, etc....
- 長年運用されてきたシステムなので負債はたくさんある
- 負債カンバンには101の項目がある...
負債返済に集中する日を作った
段々と普段の仕事で手を加える範囲のリファクタリングだけをしても、新規開発が辛くなってくることが増えてきました。
とはいえ、根本解決をやっていくのは普段の業務の中だとなかなか難しいので
明確にこのタイミングは負債返済をすると決めて動くことにしました。
はじめるにあたってビジネスサイドと経営陣への合意を取るわけですが、これまで負債カンバンをビジネスサイドがいるミーティングで毎週共有しており
負債の量や新規開発していく上での辛さをある程度理解してもらえていたので、はじめる際の合意は得やすかったです。
ここはこれまで負債カンバンを続けてきた恩恵があったと思います。
進め方については、毎週この日は集中してやると決めた方がチームとして動きやすいのと
以前他社で同じような進め方をしていたエンジニアの話も聞き
負債返済だけをする日を週に1日決めて動くようにするところから始まりました。
もちろん、ただやるのではなく、チームとして今年はどの負債を最低限返済したいかという目標は設定しています。
この取り組みを僕たちは 負債返済DAYと呼んでいます。
負債返済する際の意思決定
負債返済をするといっても、負債だと感じたところをただ返済するようにしている訳ではないです。
弊エンジニアチームでは以下のことを意識してそれに該当する負債を返済するようにしていました。
- 直近と今後の開発で必要になることはわかっているが、当時の設計が今のビジネスの形とマッチしておらず、追加で開発していくのが辛い
- 価値提供までのリードタイムを産んでしまうような負債
- アプリケーションのフレームワークやインフラ周りのEOLが決まっている(もしくは過ぎている)のに放置されているもの
- 弊部署の場合、先任者の特定の技術に強い人に任せっきりで、退職されたもしくは部署異動で放置されてしまっているケースがあった
- ただ上げるのではなく、チームとしてガーデニング等の常に上げていける、誰でも上げれる仕組みをつくるところまでセットで考える
負債返済DAYの当初の狙い
負債返済DAYをはじめるにあたって当初は以下のことを意識していました。
- 目標は普段の仕事の延長の負債返済から1歩ステップアップして、負債返済を1つのタスクとして認識してやってもらうこと(意識付け)
- 目的は負債返済DAYではなくても、チームメンバーが普段の業務の一環として行っていくこと、重たいタスクは小さいタスクに分けることで日常的に負債にコミットできる環境、負債を生み出しにくいシステムにしていくこと
- ただ負債を返済するだけでは、返済して終わりになってしまう
- システムの改善を常日頃から行える体制作りができることが大事
では1年経った今、どういう変化が起きたか
- 負債返済DAYを平日に挟むことで簡単な負債返済はリフレッシュ代わりになり、1日空くことで普段の仕事の方針をあらためて見直す機会になった
- チームの中で負債返済を必須化しようという動きが高まった
- 最初はビジネス優先度が高いタスクを優先し、負債返済DAYをスキップするケースが見られた
- しかし、チームで振り返りをした際にそれだと負債返済が中々進みづらいという話があり、基本必須化しようという動きが起きた
- ビジネスサイドにもそれを理解してもらうような動きが起きた
- 普段の仕事を平日4日のパフォーマンスで考えるようになった
- ビジネス優先度の高いタスクとの調整はチーム内でうまく分担できるようにしている
普段の仕事でも負債返済を意識的にやる動きがチームの中で見えた
- 普段の仕事で開発が入るところに関して、負債を事前に直していくという動きがチームで見られた
- これまでの様な簡単なリファクタリングではなく、ビジネスロジックにまで踏み込んだ負債返済が見受けられた
負債返済DAYじゃなくても、日常的に大きな負債を返済しようという動きが起きた
- これまで大きな負債返済をやっていたのは主に自分だったが、チームメンバー間での意識に変化が起きて自分以外にもやるようになってきた
一方で課題はまだまだある
- 1日では軽い負債が消化されがちになり、大きな負債を返済するには週一だと時間がかかりすぎる
- これははじめるときから分かっていたこと
- これに対する現状の答えは、負債返済DAY関係なく、大きな負債を担当した人がタスクを分解し、普段の仕事に落とし込めるレベルにしていくこと
- とはいえ、少しずつ進んでいるという実感が確かにある
まとめ
今回は負債返済プロジェクトを実施した結果、1年で何が変わったのかについて話をしました。
実際に続けていく中で、負債返済は着実に進みつつ、チームの意識に変化が起きていました。
負債返済DAYをきっかけにチームとして負債返済に動いていくことがこれまで以上に多くなり、結果的に今では週1日以上集中して負債返済をしているメンバーもいます。
一方で、週1日では重い負債の返済としては不十分などまだまだ改善の余地はあります。
普段のビジネス課題の解決をおろそかにせず、重い負債をチームで返済できるような仕組みを作ることは今後もやっていかなければならないことです。
