「10分以内に機能を消せる状態」 の実現のためにやっていること

PHPConference福岡2025の登壇資料です！
https://fortee.jp/phpcon-fukuoka-2025/proposal/02f747bb-61f3-4280-b761-f28f613e5163

Transcript

1. 「10分以内に機能を消せる状態」 の実現のためにやっていること PHPConference福岡2025
2. 自己紹介 名前：荻島 貴（おぎ） 所属：カオナビ 職業：開発者（PHPer） 特技：スノーボード PHPCon福岡は２回目の登壇！
3. 過去の登壇履歴
4. ※今回はインターフェースの話はしません （でも設計の話はします）
5. 本題
6. 捨てやすい設計とは？
7. Package By Feature (PBF) レガシー回避のPHP開発術
8. 今回削除した機能を開発したチームの哲学 ソフトウェアは捨てやすく作ろう
9. フラクタル構造 packages |---packageA | |---FeatureA | |---Http | |---Models | |---FeatureB | |---Http | |---Models |---packageB • パッケージの中で更に機能でディレクトリを 分ける入れ子構造 • 機能間の相互依存がないような構成 （依存の向きは常に一方向） ソフトウェアは捨てやすく作ろう
10. 依存関係が明確 ＝ 不要なコードが削除しやすい
11. 実際にローカルで 機能を１つ消してみた
13. （いきなりリリースするの怖い🥶）
14. “削除対象を探す時に本当に使われていな いのか見極めているのであれば恐れるこ とはないです。” 不要なコードを見極めて削除するポイント
15. 「使われていない」ことが 保証できれば...？🧐
16. Feature Toggleを使って 「安全に」消す
17. Feature Toggle “フィーチャートグル（Feature Toggle）とは、ソフトウェアの特定の機能のオンと オフを、プログラムのコードを変更したり、再デプロイしたりすることなく、動的に 切り替えるための技術です。フィーチャーフラグ（Feature Flag）やフリッパー （Flipper）とも呼ばれます” by Gemini
18. Feature Toggleによるリリース制御 Feature Toggleなし （デプロイとリリースが同時） サーバー サーバー サーバー ①デプロイ ＆リリース ②変更失敗⚠ ④再デプロイ ③ソースリバート⚠ サーバー Feature Toggleあり （デプロイとリリースが分離） サーバー サーバー サーバー ①デプロイ🔴 ②リリース🟢 ④トグルオフ🔴 ③変更失敗⚠ サーバー
19. Feature Toggleを使った安全な削除の手順 1. 画面側の動線に制御を追加 2. API側にロジックの制御を追加 3. Feature Toggleを埋め込んだコードをデプロイ 4. 機能廃止日にFeature ToggleをON 5. 問題なければ順次コードを削除
20. フロントエンドのコンポーネント制御イメージ
21. Feature Toggleを使った安全な削除手順 1. 画面側の動線に制御を追加 2. API側にロジックの制御を追加 3. Feature Toggleを埋め込んだコードをデプロイ 4. 機能廃止日にFeature ToggleをON 5. 問題なければ順次コードを削除
22. バックエンドのロジックの制御イメージ
23. Feature Toggleを使った安全な削除手順 1. 画面側の動線に制御を追加 2. API側にロジックの制御を追加 3. Feature Toggleを埋め込んだコードをデプロイ 4. 機能廃止日にFeature ToggleをON 5. 問題なければ順次コードを削除
24. Feature Toggleを使った安全な削除手順 1. 画面側の動線に制御を追加 2. API側にロジックの制御を追加 3. Feature Toggleを埋め込んだコードをデプロイ 4. 機能廃止日に Feature ToggleをON 5. 問題なければ順次コードを削除 ここが10分以内にできれば、提供価 値としてはビックバンリリースで消す のと変わらない
25. Feature Toggleを使った安全な削除手順 1. 画面側の動線に制御を追加 2. API側にロジックの制御を追加 3. Feature Toggleを埋め込んだコードをデプロイ 4. 機能廃止日にFeature ToggleをON 5. 問題なければ順次コードを削除
26. 変更量とリードタイム - マージ回数：8回 - 合計ファイル数: 149 ファイル - 削除された行数: -20,488行 - 最初の削除マージ：10/14 13:29 - 最後の削除マージ：10/15 09:02 ※バックエンドのコードのみ
27. Feature Toggleで閉じていたので 自信を持って削除できた💪
28. うまくいかなかった事例
29. Feature Toggleは 「銀の弾丸」ではない🐺
30. FeatureToggleの外に機能が漏れてしまった • フロントエンドのコンポーネントで FeatureToggleを追加 • 対象のコンポーネントには後からカ スタムフックが追加 • FeatureToggleのif文はカスタム フックの後に... 結果： ON／OFFにかかわらず、 Feature Toggleの裏側にある APIがコールされ てしまった ※イメージ
31. freeeのリリースフラグ誤操作による障害（2018） • 原因 ◦ 消されずに残っていたリリースフラグ（ Feature Toggle）が負債化 ▪ ”どのフラグがいつ・どう変更されたのかがわからなかった ” ▪ ”数が多いことで正確に判断することが難しかった ” • 対策 ◦ フラグの削除を実施 ◦ フラグ変更を通知する仕組み作り ◦ 月次モニタリング運用 ▪ リリースフラグの目的 ▪ 残存期間の目安 ▪ 期間を超過した場合のアクション ▪ 残存させ続ける条件 システム障害のおわびとまなび
32. まとめ
33. 「10分以内に機能を消せる状態」 の実現のためにやっていること PHPConference福岡2025
34. • 依存を管理して、コードの削除をしやすく • デプロイ／リリース分離で素早く、安全に
35. 言うは易く行うは難し （いうはやすくおこなうはかたし）
36. 〜アジャイル宣言の背後にある原則より〜
37. その機能、 10分以内に 消せますか？
38. 参考 • 不要なコードを見極めて削除するポイント • ソフトウェアは捨てやすく作ろう • レガシー回避のPHP開発術 • FeatureToggle戦略と運用方法 • アジャイル宣言の背後にある原則 • ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやす い設計”から始められてはいかが？ • システム障害のおわびとまなび