安全に「枯らして消す」機能削除術 ──follow up

安全に「枯らして消す」機能削除術 ──follow up 11/6 Kaigi on Rails 2026事後勉強会 chobishiba 1

自己紹介 chobishiba SmartBank, Inc. Software Engineer / Engineering Manager /
CRE @chobishiba @ksbmyk 2

Kaigi on Rails 2026 https://speakerdeck.com/chobishiba/drain-then-delete 3

発表の概要 • プロダクトの方向性が変われば、不要になる機能も生まれる • 消していかないと増える一方 • でも、使っている人がいると、すぐには消せない • 実際に消したオンボーディングミッション機能を例に、安全な消し方を話した
4

機能を消すときにやること 1. 洗い出す 2. 枯らす 3. 消すコードの依存関係をたどるだけでなく、機能の名前でも検索
なくても成り立つように新規利用の停止残りの利用の終了呼び出し経路を塞ぐ呼び出し元から順に削除呼ばれなくなったことを確かめてから呼ばれる側を消す参照されているデータも同じ 5

感想 6

もらった質問 • Q. データまで消すのは怖くないか • A. いざとなれば復元できるものだったので思い切った • Q. 通知の削除漏れに気づくには、検索するしかないのか
• A. コードの依存関係があると限らない。プロンプトで工夫できるかも • Q. 他にも消している機能はあるか？ • A. あります。合間合間に消してます Q. あのアニメーションどうやって作ったの？ A. Nano Banana（デザイナー作成）+ keynoteの再生/逆再生 7

圧倒的に多かった質問 • Q. 消すことを、経営層にどう納得してもらったか • Q. どうやって消す意思決定ができたのか 8

消す意思決定の流れ 9

狙いがある • 施策にはなんらかの狙いがある • そのために機能をリリースする • 何を達成したらゴールか • どんな効果を期待するか •
効果測定をして、判定できるようにする • 上げたい数値、下げたい数値 10

結果は3つに分かれるプラスの効果があったなんの効果もなかったマイナスの影響があった 11

結果は3つに分かれるプラスの効果があったなんの効果もなかったマイナスの影響があったオンボミッション 12

手を加えたら複雑になった • ほとんど影響を与えなかったので、手を加えた • でも、思うような効果は得られなかった • 手を加えたことで、複雑さが増した • 状態が増えた •
破綻しないように開発していくには、時間がかかる • やりづらい 13

やめる判断のしにくさ • ミッションがあることで時間が余計にかかることは、PM に伝えた • マイナスの影響があるなら、すぐにやめるが… • プラスにもっていけていないだけなら、やめる判断まではしにくい • 提供中の機能を能動的に閉じるイメージを持てない
14

「いつやめるの？」まだ…どのくらいかかるかもわからないしオンボミッションいつやめるの？ PM 隣のPM 15

今だ！！！ 16

割り込んだまだ…どのくらいかかるかもわからないしオンボミッションいつやめるの？できますすぐやめられます！！ 17

割り込んだなら… できますすぐやめられます！！ 18

乗るしかない🌊 • 以前からうっすら消す方法を考えていた • 1時間後には手順と、決めないといけないことを出した 19

2日後 • 必要な人を呼んで決め、関係各所にも連絡した • 2日後目処がたったので連絡した • 「もうちょっと遅らせることできる？」と言われるくらい早かった 20

やりきり • 新規を止めるだけで、隣のチームの施策はできるようになる • でも、そこで止めずにコード・テーブル削除までやりきった 21

消す意思決定のポイント • 機能がもたらしているものの数値化（=効果測定） • 機能があるデメリットの共有 • 他の機能開発に余計な工数がかかる • 他のチームが施策をできない •
メンテナンス（バージョンアップ）の工数がかかる • 言えないと「あってもいいんじゃない」となりやすい • 最近は、セキュリティ面の理由は理解が深まっているかもしれない 22

備える • 普段から材料を集めておく • 「大掛かりなことではない」にする • ここぞという時に動く 23

安全に「枯らして消す」機能削除術 ──follow up

安全に「枯らして消す」機能削除術 ──follow up

chobishiba

More Decks by chobishiba

Featured

Transcript