こんにちは、karahiyo(@karahiyo_n)です。
今回はZucksアドプロダクト事業本部における技術的負債返済との付き合い方とその変化の話になります。 事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。8年間は今までのやり方でいい感じにやってこれたのですがシステムも人も事業も業界も変化し今までのやり方だけでは不十分ということで、今後も事業を支えられるシステムであり続けるためにもあらためて技術的負債について向き合いました。
tl;dr
- 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた
- 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理
- チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定の個人ではなくチーム全員で負債返済の対応ができている
背景
事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。当時の開発チームのメンバーは8人。 当然長年の運用を経たシステムというのもあり技術的負債はいくつもあり、その課題にぶつかったタイミングで都度返済したり、今すぐ返済対応はしないけれど重要なものはissueに残し、機会を見てその負債返済の対応をしてきました。
しかし、それでは返済しきれていないさまざまな負債が事あるごとに顕在化し、本来やりたい機能開発・保守運用を阻害していました。
変化の激しいアドテク業界の中で生き残るためにも事業の内容とプロダクトを常に改善し続ける必要があります。一方現状は事業の成長を支える理想的なシステム状態とはいえない部分が多くなってきており、これだけ優秀なエンジニアが揃っているのにおかしい、もっとうまくやれるはず！攻め方を考え直す必要がありそうとなったのが始まりです。
技術的負債についてあらためて向き合う
次の点についてチームのエンジニア全員で話し合いをしました。
- 現状どんな技術的負債があるか、それを踏まえ現状の返済状況はどうか
- 現状の技術的負債返済対応自体の課題を考える。どうして技術的負債が生まれたのか、返済できていないのか
1. 現状どんな技術的負債があるか、それを踏まえ現状の返済状況はどうか
まずは現状確認からです。現状どんな技術的負債があるのかをチームで確認し、今の負債返済状況を評価します。 各々に考えつく技術的負債とそれによる影響を挙げてもらい共有し合いました。以下はその課題の一部になります。ここでは抽象的に書かせていただきます
- 配信サーバのコードにおけるモジュール化の弊害
- 責務が曖昧になってしまっている箇所。型システムが使えていない箇所も(Map[String, String])
- あらゆるビジネスロックが詰まった管理画面の複雑さ
- 大量のページ、APIの数。そしてコード量も多く全体の把握が困難。
- 多くの商材と細かな要求に答えるために増え続けている広告配信タグの管理
- 横断的な変更が難しい。テストが不十分
- 複数世代を経た歴史あるプロビジョニングコード(お掃除できていない)
- バッチ処理系の改善
- パフォーマンス、保守性を上げたい
- 言語やフレームワークのバージョンアップ
- 脆弱性リスク。パフォーマンスの安定性。新機能が使えない
- システム監視のノウハウの共有
- というかあのアラートずっとwarningなんだけど
- などなど
結果、やはり多くの技術的負債があること、それによる開発への影響も大きいということがわかりました。今の技術的負債返済対応に改善余地があるということをチームで合意することができました。これが最初のゴールでした。
2. 現状の技術的負債返済対応自体の課題を考える - どうして技術的負債が生まれたのか、返済できていないのか
より良い負債返済対応を考えるためにも、まずは現状の技術的負債返済対応について再確認をしました。あらためて自分たちのチームに向き合い、チームのタスク管理や、開発フロー、組織構成などを省みて今うまくやれてることと、苦手なことを洗い出します。
うまくやれてること
- スピード重視の開発をするにしても質は落とさない、機能を落とすという判断をする。ゴールを小さくする
- ある開発をする際に、既存のコードに課題があればリファクタリングから始めてる
- 高いリリース頻度
- スケジュールがきっちり決まった仕事があまりない。なるはや
- => 必要ならスコープを広げてリファクタリングからやる手段がとりやすい
- 組織構造による負債の生まれやすさはたぶん小さい
- 〇〇やりたいけど権限がないということはない
- エンジニアチーム内で依頼する関係ではない
- 新しく作って次の日にはそれを作り直したいとなることは少ない
- ビジネスサイドが本当に必要としてるものを作る。〇〇に困っているという課題のレベルから解決策を一緒に考えている
- レビュー
- 技術的なレビューはもちろん
- 新しく負債になりやすそうなコード、設計には注意。早すぎる最適化、まだ見えてない課題への対応をしていないかなど
- 運用に耐えられるものか。システム的にもユーザ的にも
- 捨てやすいこと
- 新技術への挑戦はしやすい
- goが出やすい。妥当な理由があってそれをチームに共有できれば
- 逆に既存の実装に囚われすぎて今やっておきたい改善をしていないと突っ込まれる
- 設計が悩ましいタスクや後戻りがしにくいタスクをやる際には、システム設計、仕様策定の段階で自発的に相談会を開きアイデアを多く集めるプラクティスがある
- 開発ルールが少ない。既存の実装に引っ張られすぎない(良くも悪くも
- 言語、ライブラリ選定などの際にはそのとき最適なものを選択できる
苦手なこと
- 課題とは認識しつつも対応が進まない、優先順位があがりきらないタスク
- ビジネスインパクト的な重要度に紐付けにくい
- バージョンアップ、不要なコードの削除、など
- どこにどんな技術的負債があるか把握しきれていない
- 負債対応ではない別タスクをしているなかではじめて気づく
- 今いる人と当時の開発者は違う
- コードの肥大化
- その分野、システムの専任はいない。知識の積み重ねがしにくい
- 気づいたタイミングでの根本的な負債返済の対応は簡単ではない
- 気付いたタイミングでリファクタリングできる程度のものとそうではないリアーキテクチャが必要なものがある。もう少し本腰いれる必要がある規模感のものは今すぐやらずに別issueを作成し、優先度を確認しつつ次の仕事に回しがち。N回目の「次こそ倒す」
- 運用期間が長くなり、当時の最適解が今の最適解と違ってきてるものがある
- 当初の想定以上の負荷や、当時の想定にはない仕様の変化など
一部抜粋ではありますがこのような話が出てきました。洗い出してみると、負債を生み出す要因は一般的によく挙げられるものではなく、当時の最適解と今の最適解との乖離が大きくなってきたことと、技術的負債のタスク管理ということがわかりました。現状のタスク管理では課題として把握しきれていない負債はもちろん、優先順位が上がりにくい仕事であるようです。
技術的負債返済カンバンはじめました
先の話で課題として上がった負債の把握と優先順位付けのために、「技術的負債カンバン」を作成し負債の管理と共有のためのMTGを始めました。 スプレッドシートには次のようなカラムがあります。
| カラム名 | 説明 |
|---|---|
| やりたいこと | 例: 〇〇のバージョンアップ |
| 課題 | サポート期限やバージョンアップを今していないことで開発・保守運用が難しくなっている具体的な課題、影響をあげる |
| github issue url | 弊チームではgithub issueでチケット管理してます |
| 優先度 | S, A, B, C |
| 戦略 | ゴールの確認とその道筋をブレスト。難しい仕事が多いのでこのタイミングで第一アクション、最初のゴールをすり合わせできているとうまくいきやすいかなぁと |
| 記載者 | 私です |
| ステータス | 対応中 |
| 進捗 | 最高です |
| やる人 | 私です |
シートに技術的負債を各々列挙してもらい毎週のMTGにて共有し優先順位をつけていきます。実際の返済対応をどうやるかですが、この負債返済の議論をしていた当時は今から動いたほうがいい仕事もいくつかあったのでチームメンバ8人のうち1人、2人が常時返済対応にあたろうという分担となりました。 このような形で半年ほど運用しています。
まとめ
今回は技術的負債返済との付き合い方、その変化の話でした。
普段から負債を産まないことを意識しつつ開発を行い、優先度が上がればその都度負債対応を行い、組織的なしがらみが小さくその都度妥当な意思決定がしやすい組織ながらも、それでも技術的負債は生まれ私たちが本来やりたい機能開発・保守運用を阻害していました。今後も事業の成長を支えられる理想的なシステムであるためにも攻め方を考え直し、チームで継続できる技術的負債返済対応を始めました。
今ではチームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が関わり負債返済対応が回せており、今まで放置されていたいくつもの課題が解消されてきました。実際の負債返済対応の詳細な話はまた別の機会に。
反省としては、この動きがもっと早くできてたらなというのは思います。もし数年前からやり始めていたら今やってる仕事は大きく変わっていただろうなというのがあります。が、そういうものかな。次はもっとうまくできるでしょう
FAQ
Q. こうしたことについて開発チーム外の人(ビジネスサイドとか事業部の偉い人)と話すことはありますか？
A. ビジネスサイド含めたカンバン確認MTGがあります。その場でエンジニアから優先度が高い技術的負債タスクを「技術的負債カンバン」からピックアップし共有しています。技術的負債返済も目指すのは事業の成長であるので、負債による具体的な影響、課題を正しく伝えることでエンジニア以外の方とのコミュニケーションにおいても困ったことはあまりありません。が、やはりビジネスサイドからの開発要望も山ほどあるので技術的負債返済タスクも並べた時の優先順位決めは簡単ではありませんね
