Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ham
November 21, 2023
4.2k

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

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

ham

November 21, 2023
Tweet

Transcript

  1. Findy Team+(チームプラス)とは?
 3
 開発生産性の可視化、開発プロセスの伸びしろの発見、継続的な改善をサポート 生産性可視化 生産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化・最適化)

    文化づくり・自己組織化 (メンバーの自発的な改善促進、改善を称賛する文化作り) 継続的な生産性向上サイクル データ 連携 Biz Engineer Engineer 開発組織ブランディング (エンジニアは、開発生産性が高い組織で働きたい) Recruit
  2. Four Keys Findyが重視している開発⽣産性を測る指標 • チームのデリバリーパフォーマンスが可視化できる ◦ 品質を維持し、顧客へ迅速に価値提供できていることを定量的に確 認できる • 比較的簡単にデータを取得できる

    ◦ 取得に手間がかかる場合、継続してウォッチするのが困難 • 世界的に認知されておりプラクティスが多数公開されているため、改善 活動に取り組みやすい ◦ DevOpsの能力(DevOps capabilities) ▪ https://cloud.google.com/architecture/devops?hl=ja
  3. プルリクエストの作成数とマージまでの時間 Findyが重視している開発⽣産性を測る指標 • Four Keysだけでは個人のパフォーマンスが見えづらい ◦ Four Keysではチームのパフォーマンスは測れるが、メンバー単位 で深掘りしづらい ◦

    プルリクエストの作成数とマージまでの時間の場合、メンバーごとの アウトプット量とスピードがわかる • 作成数を増やしてマージまでの時間を短くするには、1つ1つのパッチサ イズを下げる必要があり、Four Keysの向上にも繋がる • 簡単にデータを取得できる ◦ プルリクエストベースで開発すると自然にデータが取れる
  4. 開発中に気づいた様々な伸びしろを蓄積しておく 伸びしろ発⾒ 14
 引数変えたいだけなのに 
 修正箇所多いな?
 影響範囲探すの
 つらい...
 テストの書き方が 人に依存してて可

    読性が悪い
 必要なMockが多 すぎてテスト大変
 CI遅すぎて X(Twitter)が捗る
 デプロイ遅いし
 手順多い...
 そもそもテストな いじゃん...

  5. ディスカッションの注意点 ディスカッション • 中長期かかるものは効果を明確にする ◦ ROIが悪いと予想される場合、やらないという選択肢を取る • サクッとできるものは効果は気にせず、定性評価(なんか良さそう)だけで やっちゃう! •

    理想論を話しすぎず、少しずつ解消する ◦ 壮大な夢より現実的な第一歩を! ◦ オーバーエンジニアリングしすぎず、最低限の解消できるくらいが ちょうどよい
  6. ディスカッションの注意点 ディスカッション • 「なぜこうなっているのか?」経緯を探しすぎない ◦ 経緯は探しても見つからないことが多い ◦ 今どうなっているべきか?で方針を決める ◦ 何か想像もできないような理由がある場合もあるので、リリース後一定期

    間は切り戻せるようにしておくと安心 ▪ 「チェスタトンのフェンス」 • 「このフェンスがなぜ立てられたかを理解する前に、そのフェンス を取り壊してはならない。」 ▪ ソフトウェアの良さはすぐ戻せることなのでとにかくやる! • 想像を超えた理由があった場合、速攻で切り戻して、次からは 守るテストを書いておくことで再発防止
  7. 開発計画に技術的負債の解消を盛り込む 改善 • ちょろい改善はスキマ時間やGood First Issueとして消化 • 大規模なものは月次で計画している開発計画に盛り込む ◦ 機能開発

    70%、改善 30%で計画している ▪ 一人が機能開発と改善を兼務するとうまくいかないことが多い (セルフマネジメントが上手い人は除く) ▪ 改善する人は改善に集中してもらい、チーム全体で割合を担保 すると良い
  8. デプロイフローの改善 測定 • 課題 ◦ Four Keysをエリートの水準まで上げられない ▪ バックエンド /

    フロントエンド、それぞれ1日1回デプロイ ▪ リードタイム45h ◦ デプロイに時間がかかる ▪ 障害発生時の切り戻しも同等の時間がかかるため、迅速に切り 戻せない ▪ 商談中など障害時のリスクが高い時間帯を避けてデプロイ ◦ 切り戻し手順が煩雑 ▪ デプロイに対する心理的ハードルが高い
  9. デプロイフローの改善 測定 • 課題解決後の目標 ◦ Four Keysの向上 ▪ デプロイ頻度 2倍

    ▪ リードタイム 1/2 ▪ 変更障害率・平均修復時間 現状維持
  10. 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜

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

    💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上!! 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー!! 💪💪💪💪💪💪💪💪💪 技術的負債の解消の全ての意思決定が 開発チーム内で完結するのでスムーズに進⾏可能!!
  12. 技術的負債解消のサイクルの注意点 • 闇雲に改善すれば良いというものではない ◦ 工数と効果のバランスを意識しよう ▪ 頑張ってもあまり効果がないと改善のモチベーション低下 ▪ リソースは無限ではない ▪

    一方で、細かいものはえいやーでやる勢いも大事 • 細かいものまで効果は?と言われても難しい • 私やみんなの気分が良くなる!だけで良い!
  13. 技術的負債解消のサイクルの注意点 • 細く長くは難しい ◦ 長期間かかる改善をスキマ時間で少しずつ直していくは難しい ▪ 兼務で2番手のタスクを進めるのは難しい ◦ 時間がかかればかかるほど新旧コードの混在期間が延びる ▪

    新旧残っているとキャッチアップ難易度が上がる ▪ 改善前のものが残っているとそこから増殖する • 短期であればチーム内で徹底するだけで防げるが、長期に なると徹底することが難しくなる • Copilotが古いコードを学習する ◦ 専属で改善するエンジニアをアサインして改善期間を短縮する
  14. 開発中に伸びしろに気づく 😇🥺😱🙈🤣🤮🤪 技術的負債解消のサイクル 伸びしろ発見
 ディスカッション
 改善
 測定
 前向きな議論 🤔🧐👍💪󰢏 改善改善〜

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

    💪😇🤪😮😤💪 開発⽣産性や 開発者体験が向上!! 👏🙌👍💪💯🥰🥳 開発しやすくなったー もっと良くしていくぞー!! 💪💪💪💪💪💪💪💪💪 継続的な改善サイクルを回すことで 開発者体験の良い環境を⾃分たちで作っていきましょう!!