ビジネスを止めない技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う / Complexity and Simplicity

phpカンファレンス2026 愛媛の登壇資料です。

Transcript

1. ビジネスを止めない 技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う PHPカンファレンス愛媛2026
2. What is it? ソフトウェアは 日々、肥大化する
3. What is it? ソフトウェアは肥大化するが 品質は維持する必要がある
4. What is it? これはコーディング方法が変わっても ずっと変わってないこと
5. What is it? 人間にもAIにも 理解できるコードを維持する
6. What is it? そのために必要な 戦略・考え方と実践的な話
7. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
8. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
9. 自己紹介 そ ね たけ とも 曽根 壮大（41歳） Have Fun Tech LLC 代表社員 株式会社リンケージ CTO 兼 COO • • • • 日本PostgreSQLユーザ会 勉強会分科会 担当 3人の子供がいます（長女、次女、長男） 技術的にはWeb/LL言語/RDBMSが好きです コミュニティが好き
10. リンケージ
11. リンケージが目指す世界 健やかな心身を通して、社会の幸せを増やす 最後まで、自分らしくある
12. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
13. 返済計画と戦略 ビジネスの仮説検証のために 品質を犠牲にする=技術的負債
14. 返済計画と戦略
15. 返済計画と戦略 借金をするなら 返済計画とセット！
16. 返済計画と戦略
17. 返済計画と戦略 どちらにせよ 品質を改善していくことは必要
18. 返済計画と戦略 それで品質ってなに？
19. 返済計画と戦略 それで品質ってなに？ ↓ 対象に本来備わっている特性の集まりが 要求事項を満たす程度 ※ISO9000の定義
20. 返済計画と戦略 要求は立場によってかわる そのため求められる品質も変わる
21. ソフトウェアの要求 • 利用者 ◦ サービスが正常に使える • 運用担当者 ◦ 管理画面等が正常に使え、業務が円滑に運営できる • 事業責任者 ◦ 必要な機能追加や運営が許容できる費用と期間で継続できる
22. ソフトウェアの品質特性 品質特性 確認すること ソフトウェアでの例 機能適合性 必要な機能と正しい結果を提供できるか ユーザに提供する機能が業務ルールに合う。機能要件を満たす 性能効率性 時間や資源の要求を満たすか 想定負荷で応答時間やメモリ使用量が許容範囲に収まる 互換性 他の製品やライブラリと共存・連携できるか 外部APIとの連携が正しく行える 対話性 利用者が理解し、操作できるか 操作方法やエラーの対処方法が分かる 信頼性 必要な条件で機能し、障害にも対処できるか 稼働を継続でき、障害後に必要な状態へ回復できる 稼働率やMTTR（障害平均復旧時間）など セキュリティ 情報や機能を適切に保護できるか 権限のない閲覧や改ざんを防げる 保守性 想定する保守者が有効・効率的に変更できるか 変更箇所を調べ、修正し、検証できる 柔軟性 要求・環境の変化などに対応できるか 動作環境の変更や負荷の増減に適応できる 安全性 人命・健康・財産などへの危害を抑えられるか 危険な状態を検知し、警告や安全な停止につなげられる ※JIS X 25010:2025 システム及びソフトウェア技術の定義をベースにしています
23. ソフトウェアの品質の低下の例 • AIコーディング ◦ 機能適合性、セキュリティ、性能効率性、保守性など • 長期間の放置 ◦ 機能適合性、互換性、性能効率性、セキュリティ、柔軟性など • 原義の技術的負債 ◦ 主に保守性が犠牲になる • 能力不足 ◦ 不足している能力によって、対象の品質が低下する
24. 返済計画と戦略 そして、今日のテーマは 保守性！！
25. 返済計画と戦略 そして、今日のテーマは 保守性！！ もちろん他の特性も大事なのですが、 今日は時間がないので保守性を軸にします
26. 返済計画と戦略 保守性が低下しているサイン
27. 返済計画と戦略 保守性が低下しているサイン ↓ 例えばFour Keys
28. Four Keys • デプロイの頻度 ◦ • 変更のリードタイム ◦ • 変更のコミットから、本番環境で正常に実行されるまでの時間 変更失敗率 ◦ • 変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度 デプロイによって本番環境で障害が発生する割合 デプロイ失敗時の復元までの時間 ◦ 本番環境での障害から復元までにかかる時間
29. Four Keys • 保守性以外が問題のこともあるが、 品質が低下していることの指標としてわかりやすい デプロイの頻度 ◦ • 変更のリードタイム ◦ • 変更のコミットから、本番環境で正常に実行されるまでの時間 変更失敗率 ◦ • 変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度 デプロイによって本番環境で障害が発生する割合 デプロイ失敗時の復元までの時間 ◦ 本番環境での障害から復元までにかかる時間
30. 返済計画と戦略 保守性の低下のサインが出たら 品質改善の優先度を上げる！
31. 返済計画と戦略 保守性の低下のサインが出たら 品質改善の優先度を上げる！ 他の品質特性も同様に一定の条件を満たしたら 品質改善の優先度を上げることを明確にしておく
32. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
33. 複雑さと向き合う
34. 複雑さと向き合う AIが無限に手数で解決できるので 高凝集じゃなくてもいいかもなって思い始めてる
35. 複雑さと向き合う 疎結合で、責務が明確で単一なコード
36. 複雑さと向き合う 疎結合で、責務が明確で単一なコード ↓ シンプルなコード
37. simple made easy.
38. 複雑さと向き合う 慣れていなくて、複雑なコードが 認知負荷を上げる
39. 複雑さと向き合う つまり複雑なコードが 保守性を下げる！
40. 複雑さと向き合う 複雑さとはなにか
41. 複雑さと向き合う 複雑さとはなにか ↓ ソフトウェアの複雑性にも色々ある
42. 代表的な複雑度 指標 主に測るもの 役立つ場面 循環的複雑度 Cyclomatic Complexity 制御フロー上の独立した経路の数。 通常、判断・分岐が増えるほど大きくなる 分岐の多いメソッド、テストの追加が 必要な場所の抽出 認知的複雑度 Cognitive Complexity 制御の流れやネストなどから見積もる、 処理を追う難しさ 深い条件分岐、読解やレビューに負担が かかるメソッドの抽出 NPath複雑度 メソッド内の非循環な実行経路の数 独立した条件判断が組み合わさる処理、 経路の組合せが多い処理の抽出
43. ソフトウェアの主な内部品質の要素 保守性の副特性 現場で確認したいこと 複雑性が関係する例 モジュール性 一部分の変更が、他の部分に波及しにくいか 一つの変更で複数の機能を直す必要がある 再利用容易性 必要な部品を、他の用途やシステムでも利用できるか 必要な処理を呼ぶために依存するClassが複数ある 解析容易性 原因、影響範囲、修正箇所を調べやすいか 深いネストや暗黙的な状態により、認知負荷が高い 修正容易性 他の品質を損なわず、効果的・効率的に変更できるか 条件を一つ追加すると、別の条件との整合を 広範囲に確認する必要がある テスト容易性 テストの条件を定め、その条件が満たされるか またテストの結果が確認しやすいか 分岐が多い、再現に必要な状態を作りにくい、 外部サービスを切り離せない ※JIS X 25010:2013定義
44. 複雑さと向き合う 指標に対して 低いのか、低下しているのか
45. 複雑さと向き合う 前回 低下 高い 基準線 低い 今
46. 複雑さと向き合う 前回 低下 高い 今 基準線 低い 自分たちがどこの位置にいるのか を知る必要がある
47. 複雑さと向き合う 複雑度を可視化する
48. 複雑さと向き合う https://techblog.timeleap.co.jp/entry/2026/07/09/093440 https://speakerdeck.com/moznion/cccccc
49. 複雑さと向き合う 複雑度を下げる
50. 複雑さと向き合う 複雑度を下げる ↓ 認知負荷を下げる
51. 複雑さと向き合う 認知負荷を下げるためにスコープを絞る ↓ 交換可能にする=シンプルにする
52. ソフトウェアを交換可能にしていく • 交換可能であれば品質の低いコードを捨てれば良い • 交換可能=スコープが小さい ◦ スコープが小さいとAIフレンドリー ◦ インターフェースやテストを活用して、複雑度の低いコードに置き換え ていく • 既存の密結合で複雑度の高いコードを改善する必要がある
53. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
54. 具体例と実践編 デモ
55. 具体例と実践編 https://github.com/soudai/php-demo-cccc
56. 具体例と実践編 リファクタリングの手法は AIは知っている
57. 具体例と実践編 リファクタリングの手法は AIは知っている パターン名や方針を具体的に示して、対象のスコープを指定する
58. リファクタリングやリアーキテクチャの例 • データの取得をREST API経由にする • ビジネスロジックをデータ取得と計算と状態管理に分け、 計算処理は冪等にする • データの取得と更新を分けてCQRSにする • 複数の責務を持つクラスを単一な責務のクラスに分割する
59. リファクタリングやリアーキテクチャの例 • データの取得をREST API経由にする • 全部ずっとソフトウェアとの闘いでやってきたこと ビジネスロジックをデータ取得と計算と状態管理に分け、 今までは面倒だから一緒にしちゃえ！があったが、 計算処理は冪等にする AIがやるので工数を無視できる。 ある程度小分けにしたほうがスコープが小さくなるので、 • AIフレンドリーだし交換可能になる データの取得と更新を分けてCQRSにする • 複数の責務を持つクラスを単一な責務のクラスに分割する
60. 具体例と実践編 状態を維持する ロールバックできる
61. https://soudai.hatenablog.com/entry/database-refactoring-double-write
62. https://speakerdeck.com/soudai/aws-dms
63. https://speakerdeck.com/soudai/web-refactoring
64. 具体例と実践編 先人が積み上げてきた ソフトウェアの知見が今こそ重要
65. あじぇんだ 1. 自己紹介 2. 返済計画と戦略 3. 複雑さと向き合う 4. 具体例と実践編 5. おわりに
66. おわりに AIを上手く活用するためにも 語彙の元になる知識が重要
67. おわりに 大抵の困りごとは ソフトウェアの歴史で言語化されている
68. おわりに 判断基準を曖昧にしない ちゃんと可視化する
69. おわりに シンプルなコードは 人間にもソフトウェアにも優しい
70. おわりに 愚者は経験に学び 賢者は歴史に学ぶ
71. おわりに 目の前のコードを良くできるのは 眼の前にいる自分だけ
72. おわりに 引用元：ワールドトリガー9巻 第76話
73. おわりに コードを書くのに許可はいらない @miyagawa
74. おわりに 引用元：湾岸ミッドナイト 37巻
75. おわりに
76. おわりに 昨日の自分に誇れる 今日の自分になろう
77. おわりに ご清聴ありがとうございました