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

by ham

Slide 1

Slide 1 text

現場主導で取り組む継続的な技術的負債の解消技術的負債に向き合うOnline Conference 2023/11/21

Slide 2

Slide 2 text

【略歴】新卒でSIerとして就職その後、Web系企業やスタートアップを経て2022年5月にファインディに参画ファインディではFindy Team+を開発しつつ、EMとして開発チームのマネジメントを担当浜田直人 (ham) ファインディ株式会社 @hamchance0215

Slide 3

Slide 3 text

Findy Team+(チームプラス)とは？  3  開発生産性の可視化、開発プロセスの伸びしろの発見、継続的な改善をサポート生産性可視化生産性向上事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化・最適化) 文化づくり・自己組織化 (メンバーの自発的な改善促進、改善を称賛する文化作り) 継続的な生産性向上サイクルデータ連携 Biz Engineer Engineer 開発組織ブランディング (エンジニアは、開発生産性が高い組織で働きたい) Recruit

Slide 4

Slide 4 text

Agenda ● Findyが重視している開発⽣産性を測る指標 ● Findyの継続的な技術的負債を解消する取り組み

Slide 5

Slide 5 text

Findyが重視している開発⽣産性を測る指標

Slide 6

Slide 6 text

なぜ開発⽣産性指標の話？ Findyが重視している開発⽣産性を測る指標 ● 技術的負債の解消に取り組む場合、開発生産性の向上を目的とすることが多いため ● 技術的負債解消前後の開発生産性を比較することで定量的に効果測定できる ○ 開発生産性を定量的に示すことで、開発チーム以外にも説明しやすい ○ 効果が少ない場合、負債を解消しない理由を明確にできる ○ 生産性が向上した証跡を残すことで次回以降の負債解消がさらに進めやすくなる

Slide 7

Slide 7 text

重視している指標 Findyが重視している開発⽣産性を測る指標 ● Four Keys ● プルリクエストの作成数とマージまでの時間

Slide 8

Slide 8 text

Four Keys Findyが重視している開発⽣産性を測る指標 ● Four Keys(2023 State of DevOps Report) https://cloud.google.com/devops/state-of-devops?hl=en

Slide 9

Slide 9 text

Four Keys Findyが重視している開発⽣産性を測る指標 ● チームのデリバリーパフォーマンスが可視化できる ○ 品質を維持し、顧客へ迅速に価値提供できていることを定量的に確認できる ● 比較的簡単にデータを取得できる ○ 取得に手間がかかる場合、継続してウォッチするのが困難 ● 世界的に認知されておりプラクティスが多数公開されているため、改善活動に取り組みやすい ○ DevOpsの能力(DevOps capabilities) ■ https://cloud.google.com/architecture/devops?hl=ja

Slide 10

Slide 10 text

プルリクエストの作成数とマージまでの時間 Findyが重視している開発⽣産性を測る指標 ● Four Keysだけでは個人のパフォーマンスが見えづらい ○ Four Keysではチームのパフォーマンスは測れるが、メンバー単位で深掘りしづらい ○ プルリクエストの作成数とマージまでの時間の場合、メンバーごとのアウトプット量とスピードがわかる ● 作成数を増やしてマージまでの時間を短くするには、1つ1つのパッチサイズを下げる必要があり、Four Keysの向上にも繋がる ● 簡単にデータを取得できる ○ プルリクエストベースで開発すると自然にデータが取れる

Slide 11

Slide 11 text

Findyの継続的な技術的負債を解消する取り組み

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

定例で改善⽅針をディスカッションして、イシューを作るディスカッション

Slide 17

Slide 17 text

ディスカッションの注意点ディスカッション ● 中長期かかるものは効果を明確にする ○ ROIが悪いと予想される場合、やらないという選択肢を取る ● サクッとできるものは効果は気にせず、定性評価(なんか良さそう)だけでやっちゃう！ ● 理想論を話しすぎず、少しずつ解消する ○ 壮大な夢より現実的な第一歩を！ ○ オーバーエンジニアリングしすぎず、最低限の解消できるくらいがちょうどよい

Slide 18

Slide 18 text

ディスカッションの注意点ディスカッション ● 「なぜこうなっているのか？」経緯を探しすぎない ○ 経緯は探しても見つからないことが多い ○ 今どうなっているべきか？で方針を決める ○ 何か想像もできないような理由がある場合もあるので、リリース後一定期間は切り戻せるようにしておくと安心 ■ 「チェスタトンのフェンス」 ● 「このフェンスがなぜ立てられたかを理解する前に、そのフェンスを取り壊してはならない。」 ■ ソフトウェアの良さはすぐ戻せることなのでとにかくやる！ ● 想像を超えた理由があった場合、速攻で切り戻して、次からは守るテストを書いておくことで再発防止

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

開発計画に技術的負債の解消を盛り込む改善 ● ちょろい改善はスキマ時間やGood First Issueとして消化 ● 大規模なものは月次で計画している開発計画に盛り込む ○ 機能開発 70%、改善 30%で計画している ■ 一人が機能開発と改善を兼務するとうまくいかないことが多い (セルフマネジメントが上手い人は除く) ■ 改善する人は改善に集中してもらい、チーム全体で割合を担保すると良い

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

⼤規模な技術的負債の解消は事前に効果を定量的に計画する測定 ● 最近実施した技術的負債の解消 ○ デプロイフローの改善 ○ フロントエンドのアーキテクチャー刷新 https://note.com/hamchance/n/n97c551bab985 https://note.com/hamchance/n/n4a074eb0193c

Slide 23

Slide 23 text

デプロイフローの改善測定 ● 課題 ○ Four Keysをエリートの水準まで上げられない ■ バックエンド / フロントエンド、それぞれ1日1回デプロイ ■ リードタイム45h ○ デプロイに時間がかかる ■ 障害発生時の切り戻しも同等の時間がかかるため、迅速に切り戻せない ■ 商談中など障害時のリスクが高い時間帯を避けてデプロイ ○ 切り戻し手順が煩雑 ■ デプロイに対する心理的ハードルが高い

Slide 24

Slide 24 text

デプロイフローの改善測定 ● 解消する技術的負債 ○ インフラを変更してデプロイ時間を短縮 ○ デプロイフローの自動化を強化してデプロイの手間を減らす ○ 切り戻し手順を整備して切り戻しを簡単にできるようにする

Slide 25

Slide 25 text

デプロイフローの改善測定 ● 課題解決後の目標 ○ Four Keysの向上 ■ デプロイ頻度 2倍 ■ リードタイム 1/2 ■ 変更障害率・平均修復時間現状維持

Slide 26

Slide 26 text

デプロイフローの改善測定 ● デプロイ頻度 2倍(2→4件) ● リードタイム 1/2 (45h→24h) ● 変更障害率・平均修復時間現状維持 Four Keys ヨシッ！

Slide 27

Slide 27 text

フロントエンドのアーキテクチャー刷新測定 ● 課題 ○ 定性的・定量的にフロントエンド開発の体験が悪くなっていた ■ キャッチアップが他と比べて大変(定性評価) ■ プルリクエスト作成数が他を開発しているときと比べて少ない (定量評価) ■ 影響範囲がわかりづらく、影響範囲が広い

Slide 28

Slide 28 text

デプロイフローの改善測定 ● 解消する技術的負債 ○ 「簡単に使える」から「簡単に理解できる」アーキテクチャーへ移行 ■ ぽんぽん置いていくだけでなんかわからんけど動く ■ 一手間必要だけどなぜ動くか理解できる https://speakerdeck.com/ham0215/izikarasinpuruhe-purodakutonocheng-chang-nihe-wasetaakitekutiyanobian-geng

Slide 29

Slide 29 text

フロントエンドのアーキテクチャー刷新測定 ● 改善後の目標 ○ プルリクエスト作成数1.5〜2倍 ■ 他を開発しているときと同等の数値を目指す

Slide 30

Slide 30 text

フロントエンドのアーキテクチャー刷新測定 ● 改善前と比べて一人当たりのプルリク数が2倍に！！ ○ 実施前1件、実施後2件 => 約2倍！！ PR数ヨシッ！

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪

Slide 33

Slide 33 text

技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  前向きな議論 🤔🧐👍💪󰢏 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪

Slide 34

Slide 34 text

技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪

Slide 35

Slide 35 text

技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪

Slide 36

Slide 36 text

開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったーもっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪

Slide 37

Slide 37 text

開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったーもっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪 技術的負債の解消の全ての意思決定が開発チーム内で完結するのでスムーズに進⾏可能！！

Slide 38

Slide 38 text

技術的負債解消のサイクルの注意点 ● 闇雲に改善すれば良いというものではない ○ 工数と効果のバランスを意識しよう ■ 頑張ってもあまり効果がないと改善のモチベーション低下 ■ リソースは無限ではない ■ 一方で、細かいものはえいやーでやる勢いも大事 ● 細かいものまで効果は？と言われても難しい ● 私やみんなの気分が良くなる！だけで良い！

Slide 39

Slide 39 text

技術的負債解消のサイクルの注意点 ● 細く長くは難しい ○ 長期間かかる改善をスキマ時間で少しずつ直していくは難しい ■ 兼務で2番手のタスクを進めるのは難しい ○ 時間がかかればかかるほど新旧コードの混在期間が延びる ■ 新旧残っているとキャッチアップ難易度が上がる ■ 改善前のものが残っているとそこから増殖する ● 短期であればチーム内で徹底するだけで防げるが、長期になると徹底することが難しくなる ● Copilotが古いコードを学習する ○ 専属で改善するエンジニアをアサインして改善期間を短縮する

Slide 40

Slide 40 text

Slide 41

Slide 41 text

技術的負債解消のサイクル伸びしろ発見  ディスカッション  改善  測定  開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 前向きな議論 🤔🧐👍💪󰢏 改善改善〜 💪😇🤪😮😤💪 開発⽣産性や開発者体験が向上！！ 👏🙌👍💪💯🥰🥳 開発しやすくなったーもっと良くしていくぞー！！ 💪💪💪💪💪💪💪💪💪 継続的な改善サイクルを回すことで開発者体験の良い環境を⾃分たちで作っていきましょう！！

Slide 42

Slide 42 text

Findy サービス Findy 採⽤ https://findy.co.jp/service/ https://careers.findy.co.jp/