現場主導で取り組む継続的な技術的負債の解消

2023/11/21に開催された「技術的負債に向き合う Online Conference」の登壇資料です。
https://findy.connpass.com/event/297813/

Transcript

1. 現場主導で取り組む 継続的な技術的負債の解消 技術的負債に向き合うOnline Conference 2023/11/21
2. 【略歴】 新卒でSIerとして就職 その後、Web系企業やスタートアップを経て2022年5月に ファインディに参画 ファインディではFindy Team+を開発しつつ、EMとして 開発チームのマネジメントを担当 浜田 直人 (ham) ファインディ株式会社 @hamchance0215
3. Findy Team+(チームプラス)とは？
 3
 開発生産性の可視化、開発プロセスの伸びしろの発見、継続的な改善をサポート 生産性可視化 生産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化・最適化) 文化づくり・自己組織化 (メンバーの自発的な改善促進、改善を称賛する文化作り) 継続的な生産性向上サイクル データ 連携 Biz Engineer Engineer 開発組織ブランディング (エンジニアは、開発生産性が高い組織で働きたい) Recruit
4. Agenda • Findyが重視している開発⽣産性を測る指標 • Findyの継続的な技術的負債を解消する取り組み
5. Findyが重視している 開発⽣産性を測る指標
6. なぜ開発⽣産性指標の話？ Findyが重視している開発⽣産性を測る指標 • 技術的負債の解消に取り組む場合、開発生産性の向上を目的とするこ とが多いため • 技術的負債解消前後の開発生産性を比較することで定量的に効果測定 できる ◦ 開発生産性を定量的に示すことで、開発チーム以外にも説明しやす い ◦ 効果が少ない場合、負債を解消しない理由を明確にできる ◦ 生産性が向上した証跡を残すことで次回以降の負債解消がさらに 進めやすくなる
7. 重視している指標 Findyが重視している開発⽣産性を測る指標 • Four Keys • プルリクエストの作成数とマージまでの時間
8. Four Keys Findyが重視している開発⽣産性を測る指標 • Four Keys(2023 State of DevOps Report) https://cloud.google.com/devops/state-of-devops?hl=en
9. Four Keys Findyが重視している開発⽣産性を測る指標 • チームのデリバリーパフォーマンスが可視化できる ◦ 品質を維持し、顧客へ迅速に価値提供できていることを定量的に確 認できる • 比較的簡単にデータを取得できる ◦ 取得に手間がかかる場合、継続してウォッチするのが困難 • 世界的に認知されておりプラクティスが多数公開されているため、改善 活動に取り組みやすい ◦ DevOpsの能力(DevOps capabilities) ▪ https://cloud.google.com/architecture/devops?hl=ja
10. プルリクエストの作成数とマージまでの時間 Findyが重視している開発⽣産性を測る指標 • Four Keysだけでは個人のパフォーマンスが見えづらい ◦ Four Keysではチームのパフォーマンスは測れるが、メンバー単位 で深掘りしづらい ◦ プルリクエストの作成数とマージまでの時間の場合、メンバーごとの アウトプット量とスピードがわかる • 作成数を増やしてマージまでの時間を短くするには、1つ1つのパッチサ イズを下げる必要があり、Four Keysの向上にも繋がる • 簡単にデータを取得できる ◦ プルリクエストベースで開発すると自然にデータが取れる
11. Findyの 継続的な技術的負債を 解消する取り組み
12. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

13. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

14. 開発中に気づいた様々な伸びしろを蓄積しておく 伸びしろ発⾒ 14
 引数変えたいだけなのに 
 修正箇所多いな？
 影響範囲探すの
 つらい...
 テストの書き方が 人に依存してて可 読性が悪い
 必要なMockが多 すぎてテスト大変
 CI遅すぎて X(Twitter)が捗る
 デプロイ遅いし
 手順多い...
 そもそもテストな いじゃん...

15. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

16. 定例で改善⽅針をディスカッションして、イシューを作る ディスカッション
17. ディスカッションの注意点 ディスカッション • 中長期かかるものは効果を明確にする ◦ ROIが悪いと予想される場合、やらないという選択肢を取る • サクッとできるものは効果は気にせず、定性評価(なんか良さそう)だけで やっちゃう！ • 理想論を話しすぎず、少しずつ解消する ◦ 壮大な夢より現実的な第一歩を！ ◦ オーバーエンジニアリングしすぎず、最低限の解消できるくらいが ちょうどよい
18. ディスカッションの注意点 ディスカッション • 「なぜこうなっているのか？」経緯を探しすぎない ◦ 経緯は探しても見つからないことが多い ◦ 今どうなっているべきか？で方針を決める ◦ 何か想像もできないような理由がある場合もあるので、リリース後一定期 間は切り戻せるようにしておくと安心 ▪ 「チェスタトンのフェンス」 • 「このフェンスがなぜ立てられたかを理解する前に、そのフェンス を取り壊してはならない。」 ▪ ソフトウェアの良さはすぐ戻せることなのでとにかくやる！ • 想像を超えた理由があった場合、速攻で切り戻して、次からは 守るテストを書いておくことで再発防止
19. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

20. 開発計画に技術的負債の解消を盛り込む 改善 • ちょろい改善はスキマ時間やGood First Issueとして消化 • 大規模なものは月次で計画している開発計画に盛り込む ◦ 機能開発 70%、改善 30%で計画している ▪ 一人が機能開発と改善を兼務するとうまくいかないことが多い (セルフマネジメントが上手い人は除く) ▪ 改善する人は改善に集中してもらい、チーム全体で割合を担保 すると良い
21. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

22. ⼤規模な技術的負債の解消は事前に効果を定量的に計画する 測定 • 最近実施した技術的負債の解消 ◦ デプロイフローの改善 ◦ フロントエンドのアーキテクチャー刷新 https://note.com/hamchance/n/n97c551bab985 https://note.com/hamchance/n/n4a074eb0193c
23. デプロイフローの改善 測定 • 課題 ◦ Four Keysをエリートの水準まで上げられない ▪ バックエンド / フロントエンド、それぞれ1日1回デプロイ ▪ リードタイム45h ◦ デプロイに時間がかかる ▪ 障害発生時の切り戻しも同等の時間がかかるため、迅速に切り 戻せない ▪ 商談中など障害時のリスクが高い時間帯を避けてデプロイ ◦ 切り戻し手順が煩雑 ▪ デプロイに対する心理的ハードルが高い
24. デプロイフローの改善 測定 • 解消する技術的負債 ◦ インフラを変更してデプロイ時間を短縮 ◦ デプロイフローの自動化を強化してデプロイの手間を減らす ◦ 切り戻し手順を整備して切り戻しを簡単にできるようにする
25. デプロイフローの改善 測定 • 課題解決後の目標 ◦ Four Keysの向上 ▪ デプロイ頻度 2倍 ▪ リードタイム 1/2 ▪ 変更障害率・平均修復時間 現状維持
26. デプロイフローの改善 測定 • デプロイ頻度 2倍(2→4件) • リードタイム 1/2 (45h→24h) • 変更障害率・平均修復時間 現状維持 Four Keys ヨシッ！
27. フロントエンドのアーキテクチャー刷新 測定 • 課題 ◦ 定性的・定量的にフロントエンド開発の体験が悪くなっていた ▪ キャッチアップが他と比べて大変(定性評価) ▪ プルリクエスト作成数が他を開発しているときと比べて少ない (定量評価) ▪ 影響範囲がわかりづらく、影響範囲が広い
28. デプロイフローの改善 測定 • 解消する技術的負債 ◦ 「簡単に使える」から「簡単に理解できる」アーキテクチャーへ移行 ▪ ぽんぽん置いていくだけでなんかわからんけど動く ▪ 一手間必要だけどなぜ動くか理解できる https://speakerdeck.com/ham0215/izikarasinpuruhe-purodakutonocheng-chang-nihe-wasetaakitekutiyanobian-geng
29. フロントエンドのアーキテクチャー刷新 測定 • 改善後の目標 ◦ プルリクエスト作成数1.5〜2倍 ▪ 他を開発しているときと同等の数値を目指す
30. フロントエンドのアーキテクチャー刷新 測定 • 改善前と比べて一人当たりのプルリク数が2倍に！！ ◦ 実施前1件、実施後2件 => 約2倍！！ PR数 ヨシッ！
31. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定

32. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪
33. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪
34. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪
35. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪
36. 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪
37. 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪 技術的負債の解消の全ての意思決定が 開発チーム内で完結するのでスムーズに進⾏可能！！
38. 技術的負債解消のサイクルの注意点 • 闇雲に改善すれば良いというものではない ◦ 工数と効果のバランスを意識しよう ▪ 頑張ってもあまり効果がないと改善のモチベーション低下 ▪ リソースは無限ではない ▪ 一方で、細かいものはえいやーでやる勢いも大事 • 細かいものまで効果は？と言われても難しい • 私やみんなの気分が良くなる！だけで良い！
39. 技術的負債解消のサイクルの注意点 • 細く長くは難しい ◦ 長期間かかる改善をスキマ時間で少しずつ直していくは難しい ▪ 兼務で2番手のタスクを進めるのは難しい ◦ 時間がかかればかかるほど新旧コードの混在期間が延びる ▪ 新旧残っているとキャッチアップ難易度が上がる ▪ 改善前のものが残っているとそこから増殖する • 短期であればチーム内で徹底するだけで防げるが、長期に なると徹底することが難しくなる • Copilotが古いコードを学習する ◦ 専属で改善するエンジニアをアサインして改善期間を短縮する
40. 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪
41. 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪 継続的な改善サイクルを回すことで 開発者体験の良い環境を⾃分たちで作っていきましょう！！
42. Findy サービス Findy 採⽤ https://findy.co.jp/service/ https://careers.findy.co.jp/