技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025

Transcript

1. 技術的負債を 正しく理解し、正しく付き合う Mar. 23 2025 PHPerKaigi 2025 Shogo Kawase /

   @shogogg

2. 河瀨 翔吾 / Shogo Kawase 株式会社 PR TIMES　ソフトウェアエンジニア シン・アジャイルコミュニティ　運営メンバー I

   LOVE... 型安全 / アジャイル / F1 / ももいろクローバーZ shogogg shogogg 自己紹介

3. We are Hiring!!

4. • 技術的負債という言葉の解像度を上げ、エンジニア同士 だけでなく、非エンジニアとも語れる ようになる • 技術的負債との付き合い方のヒント を持って帰ってもらう Today’s Goal

5. 1. 技術的負債とは 2. 技術的負債はなぜ生まれるのか 3. 技術的負債とどう付き合っていくべきか 4. 技術的負債を最小限に抑える取り組み・テクニック 5. まとめ

   おしながき

6. 技術的負債とは

7. Photo: Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons •

   WikiWikiWeb の開発者 • アジャイルソフトウェア開発宣言 に署名した17人の1人 • 技術的負債という概念の生みの親 ※諸説あり Ward Cunningham

8. “負債のメタファー を発明したの は、当時の自社プロダクト WyCash で進めているリファクタリングにつ いて上司に説明するためでした。 〜中略〜 上司に説明するとき、それが金融系 ソフトウェアだったので金融の例え 話を使い、それを「負債のメタ

   ファー」と名付けました。” Photo: Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons

9. “もしも自分たちが書いているプロ グラムを、金融の世界に関する正し い捉え方だと自分たちが理解した姿 と一致させることができなくなれば 自分たちは絶えずその不一致につま ずき続けることになり、開発スピー ドは遅くなっていくでしょう。それ はまるで借金の利子を払い続ける かのようです。” Photo:

   Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons Ward Explains Debt Metaphor より

10. • Ward Cunningham の語る「負債のメタファー 」は、今日我々が イメージする「技術的負債 」よりも限定的な概念である。 • その後、このメタファーがあちこちで引用されていった結果、 「技術的負債

    」という言葉が定着し、解釈も拡大していった。 • そのため一般的な原理・原則等と異なり、学術的かつ統一された 定義というものは実は存在しない 。 技術的負債とは

11. 「正しい」とは？

12. 󰢙

13. なのでここからは すべて個人の意見です 😋

14. Q. 技術的負債 とは？

15. A. ソフトウェアの 変更容易性 を下げる ありとあらゆる要素

16. • コードが十分に整理されていない・ドキュメントが未整備 ➡ 何が書いてあるのか読み取るのが困難 ➡ どこに何があるのか・どれが何なのかわからない • ライブラリやランタイムのバージョンが古いまま放置されている ➡ 便利な新機能などが導入できない

    ➡ 脆弱性などが発覚してもすぐに対応できない • テストが自動化されていない ➡ 変更の度に手動で大量のリグレッションテスト ➡ テスト漏れが生じるリスク 変更容易性が低い状態の例

17. • 改修するための作業量が読めず、やるにしても時間が掛かる 開発速度⬇⬇・開発コスト ⬆⬆ • 改修によって生じる影響の度合いや範囲が読めない プロダクト品質 ⬇⬇・障害リスク ⬆⬆ •

    変更の手間やストレスが大きく、開発者に負担が掛かる 開発者のモチベーション ⬇⬇・離職率⬆⬆ 変更容易性が低いと……

18. 技術的負債＝ビジネス的には リスク

19. • ビジネスにおいてリスクは必ずしも避けるべきものではなく、 適切に管理 すべきもの。 • 負債＝借金もその内のひとつ 。もちろん借金には様々なリスクが 伴うが、それによって大きな成長に繋げることもできる。 • 技術的負債

    も同様で、過度に回避しようとするあまり、機動性や スピードを犠牲にしすぎると、逆にそれがネックとなる。 負債のリスクを把握し、適切にコントロールすることが重要 。 • 技術的負債 はビジネス的なリスクである。つまり開発者だけの問 題ではなく、組織全体で理解し、立ち向かう必要がある 。 技術的負債＝リスク＝悪？

20. 技術的負債はなぜ生まれるのか

21. • スキルの不足や事業ドメインの理解不足 • 技術の進歩・環境の変化 • フレームワーク・ライブラリの導入 • スケジュールの優先と人の性 • プロトタイプの本番運用

    技術的負債はなぜ生まれるのか ※あくまで例であり、他にも色んな理由があります。

22. スキルの不足や事業ドメインの理解不足

23. 誰だよ、こんなひどいコード を書いたヤツは…… プログラマーの日常

24. 俺じゃん プログラマーの日常

25. スキルの不足や事業ドメインの理解不足 • スキルの向上 やドメインの理解度向上 によって、数ヶ月前のコー ドを見るとその酷さにめまいがする経験、ありますよね？ • 実装当時はベスト だと思った設計や選択が、後から見直してみると 理想から剥離していることは少なくない。

    • そういった古いコードを放置 していると、それが参考にされたり、 コピーされることで増殖していく 。

26. 技術の進歩・環境の変化

27. class User { var $_name; function __construct($name) { $this->_name =

    $name; } function getName() { return $this->_name; } } PHP 4 時代のクラス プロパティに可視性がなく ”_” で始まる名前は内部用、という慣習 もちろん Property Promotion なんてない 引数も戻り値も型は指定できない

28. class User { function __construct( public readonly string $name )

    { } } PHP 8 時代のクラス

29. この10年での PHP の進化（抜粋） • NULL 合体演算子（PHP 7.0） • スカラー型宣言（PHP 7.0）

    • 戻り値の型宣言（PHP 7.0） • 型付きプロパティ（PHP 7.4） • アロー関数式（PHP 7.4） • 配列スプレッド演算子（PHP 7.4） • 名前付き引数（PHP 8.0） • アトリビュート（PHP 8.0） • match 式（PHP 8.0） • nullsafe 演算子（PHP 8.0） • Property Promotion（PHP 8.0） • enum 型（PHP 8.1） • never 型（PHP 8.1） • スプレッド演算子の連想配列対応（PHP 8.1） • Readonly Propperty（PHP 8.1） • Readonly Class（PHP 8.2） • プロパティフック（PHP 8.4） • 非対称可視性（PHP 8.4）

30. 消えていった（消えそうな）機能の例 • ereg 関数（PHP 5.3 で非推奨、PHP 7.0 で削除） • mysql_*

    関数（PHP 5.5 で非推奨、PHP 7.0 で削除） • mcrypt 拡張（PHP 7.1 で非推奨、PHP 7.2 で削除） • 動的プロパティ（PHP 8.2 で非推奨） • 暗黙的な nullable パラメータ（PHP 8.4 で非推奨）

31. 技術の進歩・環境の変化 • コードは腐る ：実装当時は問題なかったコードであっても、時代の 流れと共に陳腐化したり、動かなくなることも。 • 規模の変化 ：ユーザー数やアクセスの増加に伴って、データベース 設計やパフォーマンス面での問題などが顕在化。 •

    運用環境の変化 ：クラウド移行やコンテナ化、冗長構成化などに よって、問題なく動いていたコードが使えなくなる。

32. フレームワーク・ライブラリの導入

33. None

34. Laravel 4.2 ➡ 5.0 で起きたこと • ディレクトリ構成の大幅な変更 • Contracts（インターフェース）の導入 •

    フィルターの廃止・ミドルウェアの導入 • FormRequest の導入 • Form/HTML ヘルパーの廃止 • （ここに書き切れないその他たくさんの変更）

35. Laravel 4.2 ➡ 5.0 で起きたこと • ディレクトリ構成の大幅な変更 • Contracts（インターフェース）の導入 •

    フィルターの廃止・ミドルウェアの導入 • FormRequest の導入 • Form/HTML ヘルパーの廃止 • （ここに書き切れないその他たくさんの変更）

36. 他にも…… • Codeception + Specify（5.0 以降は使用不能に） • Symfony 2.0 •

    Angular 2.0 • Vue 3.0 • React + Recoil

37. • フレームワークやライブラリを導入することで、短期的には開発速度の 向上が望める。 • 人気のフレームワークなら人材の確保 でも有利。 • ただし、どんなフレームワーク・ライブラリにも破壊的変更 や開発終了 のリスクがあるし、人気がいつまで続くかもわからない。

    • 一度導入すれば継続的なバージョンアップ作業 にも工数が掛かる。 （放置すると脆弱性が見つかった時にすぐに対応できない場合も……） • それらの技術を得意とするメンバーの離職 などによってメンテナンス不 能に陥り、一気に負債化するケースも。 フレームワーク・ライブラリの導入

38. スケジュールの優先と人の性

39. ヤバイ、納期が近い……！ コードの整理は後日にしよう。 レビューお願いします、っと……。 よくある話①

40. ちょっと気になる点は残ってるけど、 やり取り多くなるとしんどいし、時間も あまり残ってないし……まぁいっか。 Approve ポチッとな。 よくある話②

41. なんだこれ？ よくわからないコードだな……。 手を入れるの怖いし、指示された最低限 の部分だけ変更してコミットしよう。 よくある話③

42. 今回のプロジェクトはスケジュール優先 だし、誰も自動テストを書いたことがな いんだよな……。 余裕ができたら自動化すればいいよね？ よくある話④

43. スケジュールの優先と人の性 • スケジュールを優先 した結果、設計やコーディングに十分な時間を とれず、最適とは言えないコードが生まれてしまう。 • さらに人は弱い生き物 なので、楽な方へと自然に流れていく。 • 強い意志を持った人であっても、疲労や納期のプレッシャー

    に気 付かない内に負けてしまう。 • そうやって生まれたコードがコピーされ、増殖していく 。

44. プロトタイプの本番運用

45. とあるスタートアップにて…… フィードバックを集めたいから、とりあえず動くものを用意したい。 スピード最優先で雑にプロトタイプを作ってくれないか！ わかりました！実際に製品開発を開始するときは作り直す必要があり ますが、問題ないですよね？ もちろん！ その時は予算も時間もちゃんと確保するよ！

46. とあるスタートアップにて…… フィードバックを集めたいから、とりあえず動くものを用意したい。 スピード最優先で雑にプロトタイプを作ってくれないか！ わかりました！実際に製品開発を開始するときは作り直す必要があり ますが、問題ないですよね？ もちろん！ その時は予算も時間もちゃんと確保するよ！ 数週間後...

47. とあるスタートアップにて…… 評判は上々！ このまま一気に本格運用するぞ！！ ちょっと待ってください！ 実際の製品版は作り直すって約束でしたよね！？ この機を逃したら先を越されてしまうかもしれない！今回はあきらめ てくれ！ところでこの機能を追加してくれないか、明日までに！

48. プロトタイプの本番運用 • 「プロトタイプだから〜」「後で作り直せるから〜」という約束が 守られることはない 。 • さらに初期フェーズでは頻繁かつ短納期での機能追加・仕様変更 が頻発し、さらにコードが複雑化していく。 • プロトタイプだと思って自動テストを書いていない

    場合、日々の 変更によって状況はどんどん悪化していく。 • そうやって生まれたコードがコピーされ、増殖していく 。

49. 技術的負債とどう付き合っていくべきか

50. • スキルの不足や事業ドメインの理解不足 • 技術の進歩・環境の変化 • フレームワーク・ライブラリの導入 • スケジュールの優先と人の性 • プロトタイプの本番運用

    おさらい：技術的負債はなぜ生まれるのか

51. • つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう！

    それなら……

52. • つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう！

    それなら…… なるほど完璧な作戦っスねーッ

53. • つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう！

    それなら…… 不可能だという点に 目をつぶればよぉ

54. • 仮につよつよエンジニアだけを集めたとしても、あらゆる変化 に備えることは不可能 に近い。 • フレームワークやライブラリを一切使わない場合、それらに相当 する機能を自分達で作り、メンテする コストが発生する。 • 現代のビジネス環境では、すばやく仮説検証サイクルを回し、市

    場投入のタイミングを逃さないことが極めて重要。のんびり開発 している暇はない 。 技術的負債は必ず生まれる！

55. • ビジネスにおいてリスクは必ずしも避けるべきものではなく、適 切に管理すべきもの。 • 負債＝借金もその内のひとつ。もちろん借金には様々なリスクが 伴うが、それによって大きな成長に繋げることもできる。 • 技術的負債 も同様で、過度に回避しようとするあまり、機動性や スピードを犠牲にしすぎると、逆にそれがネックとなる。

    負債のリスクを把握し、適切にコントロールすることが重要 。 • 技術的負債はビジネス的なリスクである。つまり開発者だけの問 題ではなく、組織全体で理解し、立ち向かう必要がある。 おさらい：技術的負債＝リスク＝悪？

56. • ビジネスで成果を生むため、必要な技術的負債は受け入れてい く必要がある。 • 無策に・無闇矢鱈に負債を抱えていい訳ではない。不要な負債を 抱えないためにも、計画的な管理と返済を前提とした意思決定 が必要。 技術的負債をコントロールする

57. None

58. 技術的負債を最小限に抑える取り組み・テクニック

59. • 機能追加や修正の度に影響範囲を調べ、手動でテストをするのはとても大 変な作業。プロダクトが大きくなればなるほどそのコストは増大 。 • ランタイムやフレームワーク、ライブラリのバージョンアップ作業は影響 範囲が大きくなりがち。 （全体のリグレッションテストを手動で……？😱） • 自動テストを導入

    することで、機能追加はもちろん、ランタイムのバー ジョンアップなども短時間かつ自信を持って 行うことができるようにな る。 • もちろん継続的インテグレーション（CI） もご一緒に。 自動テストを導入する

60. 自動テストを書く余裕がない……？ https://zenn.dev/coconala/articles/write-tests-in-parallel https://speakerdeck.com/o0h/phpcon-nagoya-2025

61. • 先に述べたとおり、フレームワークやライブラリを導入すること で、バージョンアップ対応のコスト や、破壊的変更・開発終了の リスクが生じる。 • そのため、フレームワークやライブラリの導入の際は、まず必要 性や導入によるメリットを十分に検討し、場合によっては導入を 見送る決断 も必要。

    • 導入する場合も、将来性や安定性、他パッケージへの移行のしや すさなどをしっかりと見極め、適切なパッケージを選ぶようにす る。 依存を最小限に抑える・厳選する

62. • 「◦◦さんが作ったところだから」「□□さんが詳しいから」で 任せきりになっていると、ボトルネックになる し、退職時に詰 む。 • 属人性を排除し、チーム全員がコードに責任を持ち、誰でも変更・ 改善できるようにすることでボトルネックは解消 する。 •

    また、知識がチーム全体で共有 され、メンバーの退職や異動によ るリスクを最小化 できる。 • ペアプロやモブプロもオススメです。 コードの共同所有

63. • 「クラス名とメソッド名を見れば、みんなわかるでしょ」「やって ることがシンプルだし、コメントいらないよね？」は危険！ • コードの意図 をコメントなしで100%表現するのはとても難しい。 実装時の背景や経緯が残ることで、リファクタリングも容易に。 • 論理名（日本語）と物理名（英語）の関係を全員が理解できている とは限らないため、クラスやプロパティの説明も大事

    。 • チーム全体での知識共有・コードの共同所有が促進され、新規参画 したメンバーもスムーズに作業に参加可能に。 コメントやドキュメントをちゃんと書く

64. • 腐敗防止層： 外部やレガシーシステムの複雑さを吸収し、内部をクリー ンに保つための設計パターン。 • 外部依存との間に： 依存するパッケージや外部 API などとの間に抽象化 された腐敗防止層を置くことで、破壊的変更への対応や、将来的な乗り

    換えが容易 になる。 • レガシーコードとの間に： 新しい機能を開発する際、レガシーコードを 直接参照せずに腐敗防止層を挟むことで、新しいコードをクリーンに保 ち、リファクタリングも容易 になる。 腐敗防止層

65. 腐敗防止層 https://speakerdeck.com/okashoi/interface-and-anti-corruption-layer

66. • 返済せずに放置すれば負債は増え続ける 。 • 整理・整頓・リファクタリングを「いつかやる 」ではなく日常の ルーティン に組み込み、文化を醸成 することで、コードをクリー ンに保つ。

    • ボーイスカウトルール： コードに手を入れる際、ちょっとだけで もコードをキレイにする。 • リファクタリングデー： 毎月必ずリファクタリングのための日 を 設ける。 • 20%ルール： スプリントの20%を開発者目線の改善 に充てる。 日常的な整理・整頓・リファクタリング

67. リファクタリングデーについて https://developers.prtimes.jp/2021/12/13/introducing-refactoring-day/

68. まとめ

69. • 技術的負債はビジネス的なリスク であり、開発者だけの問題では ない。 • 無闇に敵視したり回避したりするのではなく、必要な負債は受け入 れつつ、最小限に抑えることが重要 。 • 放置すると負債が膨らみ、手に負えなくなる。適切にコントロー

    ルすることで、スピードと柔軟性を維持するのが吉。 まとめ

70. THANK YOU!!

71. • 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ • よし、技術的負債について知ろう

    - Qiita • 『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya • 時間がないからこそ、テストを書く • 設計の考え方 - インターフェースと腐敗防止層編 #phpconfuk Appendix: 参考資料