Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025
Search
shogogg
March 22, 2025
Technology
7
1.6k
技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025
2025年3月20-22日に中野セントラルパークカンファレンスで開催された PHPerKaigi 2025 DAY-2 登壇資料です。
shogogg
March 22, 2025
Tweet
Share
More Decks by shogogg
See All by shogogg
5分で理解する SOLID 原則 #phpcon_nagoya
shogogg
1
490
パスワードよもやま話
shogogg
1
260
readonly class で作る堅牢なアプリケーション
shogogg
2
1.8k
Other Decks in Technology
See All in Technology
Engineering Managementのグローバルトレンド #emoasis / Engineering Management Global Trend
kyonmm
PRO
6
940
SpannerとAurora DSQLの同時実行制御の違いに想いを馳せる
masakikato5
0
490
Vision Language Modelを活用した メルカリの類似画像レコメンドの性能改善
yadayuki
9
1.1k
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
770
SSH公開鍵認証による接続 / Connecting with SSH Public Key Authentication
kaityo256
PRO
2
200
開発組織全体で意識するSLI/SLOを実装している話
zepprix
1
750
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
140
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1k
SLI/SLO・ラプソディあるいは組織への適用の旅
nwiizo
4
1.1k
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
210
AIエージェントキャッチアップと論文リサーチ
os1ma
6
940
日本MySQLユーザ会ができるまで / making MyNA
tmtms
1
220
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
What's in a price? How to price your products and services
michaelherold
244
12k
Designing for Performance
lara
605
69k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
Designing Experiences People Love
moore
140
23k
Done Done
chrislema
183
16k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Transcript
技術的負債を 正しく理解し、正しく付き合う Mar. 23 2025 PHPerKaigi 2025 Shogo Kawase /
@shogogg
河瀨 翔吾 / Shogo Kawase 株式会社 PR TIMES ソフトウェアエンジニア シン・アジャイルコミュニティ 運営メンバー I
LOVE... 型安全 / アジャイル / F1 / ももいろクローバーZ shogogg shogogg 自己紹介
We are Hiring!!
• 技術的負債という言葉の解像度を上げ、エンジニア同士 だけでなく、非エンジニアとも語れる ようになる • 技術的負債との付き合い方のヒント を持って帰ってもらう Today’s Goal
1. 技術的負債とは 2. 技術的負債はなぜ生まれるのか 3. 技術的負債とどう付き合っていくべきか 4. 技術的負債を最小限に抑える取り組み・テクニック 5. まとめ
おしながき
技術的負債とは
Photo: Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons •
WikiWikiWeb の開発者 • アジャイルソフトウェア開発宣言 に署名した17人の1人 • 技術的負債という概念の生みの親 ※諸説あり Ward Cunningham
“負債のメタファー を発明したの は、当時の自社プロダクト WyCash で進めているリファクタリングにつ いて上司に説明するためでした。 〜中略〜 上司に説明するとき、それが金融系 ソフトウェアだったので金融の例え 話を使い、それを「負債のメタ
ファー」と名付けました。” Photo: Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons
“もしも自分たちが書いているプロ グラムを、金融の世界に関する正し い捉え方だと自分たちが理解した姿 と一致させることができなくなれば 自分たちは絶えずその不一致につま ずき続けることになり、開発スピー ドは遅くなっていくでしょう。それ はまるで借金の利子を払い続ける かのようです。” Photo:
Carrigg Photography, CC BY-SA 3.0, via Wikimedia Commons Ward Explains Debt Metaphor より
• Ward Cunningham の語る「負債のメタファー 」は、今日我々が イメージする「技術的負債 」よりも限定的な概念である。 • その後、このメタファーがあちこちで引用されていった結果、 「技術的負債
」という言葉が定着し、解釈も拡大していった。 • そのため一般的な原理・原則等と異なり、学術的かつ統一された 定義というものは実は存在しない 。 技術的負債とは
「正しい」とは?
なのでここからは すべて個人の意見です 😋
Q. 技術的負債 とは?
A. ソフトウェアの 変更容易性 を下げる ありとあらゆる要素
• コードが十分に整理されていない・ドキュメントが未整備 ➡ 何が書いてあるのか読み取るのが困難 ➡ どこに何があるのか・どれが何なのかわからない • ライブラリやランタイムのバージョンが古いまま放置されている ➡ 便利な新機能などが導入できない
➡ 脆弱性などが発覚してもすぐに対応できない • テストが自動化されていない ➡ 変更の度に手動で大量のリグレッションテスト ➡ テスト漏れが生じるリスク 変更容易性が低い状態の例
• 改修するための作業量が読めず、やるにしても時間が掛かる 開発速度⬇⬇・開発コスト ⬆⬆ • 改修によって生じる影響の度合いや範囲が読めない プロダクト品質 ⬇⬇・障害リスク ⬆⬆ •
変更の手間やストレスが大きく、開発者に負担が掛かる 開発者のモチベーション ⬇⬇・離職率⬆⬆ 変更容易性が低いと……
技術的負債=ビジネス的には リスク
• ビジネスにおいてリスクは必ずしも避けるべきものではなく、 適切に管理 すべきもの。 • 負債=借金もその内のひとつ 。もちろん借金には様々なリスクが 伴うが、それによって大きな成長に繋げることもできる。 • 技術的負債
も同様で、過度に回避しようとするあまり、機動性や スピードを犠牲にしすぎると、逆にそれがネックとなる。 負債のリスクを把握し、適切にコントロールすることが重要 。 • 技術的負債 はビジネス的なリスクである。つまり開発者だけの問 題ではなく、組織全体で理解し、立ち向かう必要がある 。 技術的負債=リスク=悪?
技術的負債はなぜ生まれるのか
• スキルの不足や事業ドメインの理解不足 • 技術の進歩・環境の変化 • フレームワーク・ライブラリの導入 • スケジュールの優先と人の性 • プロトタイプの本番運用
技術的負債はなぜ生まれるのか ※あくまで例であり、他にも色んな理由があります。
スキルの不足や事業ドメインの理解不足
誰だよ、こんなひどいコード を書いたヤツは…… プログラマーの日常
俺じゃん プログラマーの日常
スキルの不足や事業ドメインの理解不足 • スキルの向上 やドメインの理解度向上 によって、数ヶ月前のコー ドを見るとその酷さにめまいがする経験、ありますよね? • 実装当時はベスト だと思った設計や選択が、後から見直してみると 理想から剥離していることは少なくない。
• そういった古いコードを放置 していると、それが参考にされたり、 コピーされることで増殖していく 。
技術の進歩・環境の変化
class User { var $_name; function __construct($name) { $this->_name =
$name; } function getName() { return $this->_name; } } PHP 4 時代のクラス プロパティに可視性がなく ”_” で始まる名前は内部用、という慣習 もちろん Property Promotion なんてない 引数も戻り値も型は指定できない
class User { function __construct( public readonly string $name )
{ } } PHP 8 時代のクラス
この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)
消えていった(消えそうな)機能の例 • 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 で非推奨)
技術の進歩・環境の変化 • コードは腐る :実装当時は問題なかったコードであっても、時代の 流れと共に陳腐化したり、動かなくなることも。 • 規模の変化 :ユーザー数やアクセスの増加に伴って、データベース 設計やパフォーマンス面での問題などが顕在化。 •
運用環境の変化 :クラウド移行やコンテナ化、冗長構成化などに よって、問題なく動いていたコードが使えなくなる。
フレームワーク・ライブラリの導入
None
Laravel 4.2 ➡ 5.0 で起きたこと • ディレクトリ構成の大幅な変更 • Contracts(インターフェース)の導入 •
フィルターの廃止・ミドルウェアの導入 • FormRequest の導入 • Form/HTML ヘルパーの廃止 • (ここに書き切れないその他たくさんの変更)
Laravel 4.2 ➡ 5.0 で起きたこと • ディレクトリ構成の大幅な変更 • Contracts(インターフェース)の導入 •
フィルターの廃止・ミドルウェアの導入 • FormRequest の導入 • Form/HTML ヘルパーの廃止 • (ここに書き切れないその他たくさんの変更)
他にも…… • Codeception + Specify(5.0 以降は使用不能に) • Symfony 2.0 •
Angular 2.0 • Vue 3.0 • React + Recoil
• フレームワークやライブラリを導入することで、短期的には開発速度の 向上が望める。 • 人気のフレームワークなら人材の確保 でも有利。 • ただし、どんなフレームワーク・ライブラリにも破壊的変更 や開発終了 のリスクがあるし、人気がいつまで続くかもわからない。
• 一度導入すれば継続的なバージョンアップ作業 にも工数が掛かる。 (放置すると脆弱性が見つかった時にすぐに対応できない場合も……) • それらの技術を得意とするメンバーの離職 などによってメンテナンス不 能に陥り、一気に負債化するケースも。 フレームワーク・ライブラリの導入
スケジュールの優先と人の性
ヤバイ、納期が近い……! コードの整理は後日にしよう。 レビューお願いします、っと……。 よくある話①
ちょっと気になる点は残ってるけど、 やり取り多くなるとしんどいし、時間も あまり残ってないし……まぁいっか。 Approve ポチッとな。 よくある話②
なんだこれ? よくわからないコードだな……。 手を入れるの怖いし、指示された最低限 の部分だけ変更してコミットしよう。 よくある話③
今回のプロジェクトはスケジュール優先 だし、誰も自動テストを書いたことがな いんだよな……。 余裕ができたら自動化すればいいよね? よくある話④
スケジュールの優先と人の性 • スケジュールを優先 した結果、設計やコーディングに十分な時間を とれず、最適とは言えないコードが生まれてしまう。 • さらに人は弱い生き物 なので、楽な方へと自然に流れていく。 • 強い意志を持った人であっても、疲労や納期のプレッシャー
に気 付かない内に負けてしまう。 • そうやって生まれたコードがコピーされ、増殖していく 。
プロトタイプの本番運用
とあるスタートアップにて…… フィードバックを集めたいから、とりあえず動くものを用意したい。 スピード最優先で雑にプロトタイプを作ってくれないか! わかりました!実際に製品開発を開始するときは作り直す必要があり ますが、問題ないですよね? もちろん! その時は予算も時間もちゃんと確保するよ!
とあるスタートアップにて…… フィードバックを集めたいから、とりあえず動くものを用意したい。 スピード最優先で雑にプロトタイプを作ってくれないか! わかりました!実際に製品開発を開始するときは作り直す必要があり ますが、問題ないですよね? もちろん! その時は予算も時間もちゃんと確保するよ! 数週間後...
とあるスタートアップにて…… 評判は上々! このまま一気に本格運用するぞ!! ちょっと待ってください! 実際の製品版は作り直すって約束でしたよね!? この機を逃したら先を越されてしまうかもしれない!今回はあきらめ てくれ!ところでこの機能を追加してくれないか、明日までに!
プロトタイプの本番運用 • 「プロトタイプだから〜」「後で作り直せるから〜」という約束が 守られることはない 。 • さらに初期フェーズでは頻繁かつ短納期での機能追加・仕様変更 が頻発し、さらにコードが複雑化していく。 • プロトタイプだと思って自動テストを書いていない
場合、日々の 変更によって状況はどんどん悪化していく。 • そうやって生まれたコードがコピーされ、増殖していく 。
技術的負債とどう付き合っていくべきか
• スキルの不足や事業ドメインの理解不足 • 技術の進歩・環境の変化 • フレームワーク・ライブラリの導入 • スケジュールの優先と人の性 • プロトタイプの本番運用
おさらい:技術的負債はなぜ生まれるのか
• つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう!
それなら……
• つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう!
それなら…… なるほど完璧な作戦っスねーッ
• つよつよエンジニアだけを集めて…… • 最初からあらゆる変化に対応できるように備えて…… • フレームワークや外部ライブラリを導入せずに…… • スケジュールはめっちゃ余裕をもって…… • プロトタイプ検証が終わったらゼロから作り直そう!
それなら…… 不可能だという点に 目をつぶればよぉ
• 仮につよつよエンジニアだけを集めたとしても、あらゆる変化 に備えることは不可能 に近い。 • フレームワークやライブラリを一切使わない場合、それらに相当 する機能を自分達で作り、メンテする コストが発生する。 • 現代のビジネス環境では、すばやく仮説検証サイクルを回し、市
場投入のタイミングを逃さないことが極めて重要。のんびり開発 している暇はない 。 技術的負債は必ず生まれる!
• ビジネスにおいてリスクは必ずしも避けるべきものではなく、適 切に管理すべきもの。 • 負債=借金もその内のひとつ。もちろん借金には様々なリスクが 伴うが、それによって大きな成長に繋げることもできる。 • 技術的負債 も同様で、過度に回避しようとするあまり、機動性や スピードを犠牲にしすぎると、逆にそれがネックとなる。
負債のリスクを把握し、適切にコントロールすることが重要 。 • 技術的負債はビジネス的なリスクである。つまり開発者だけの問 題ではなく、組織全体で理解し、立ち向かう必要がある。 おさらい:技術的負債=リスク=悪?
• ビジネスで成果を生むため、必要な技術的負債は受け入れてい く必要がある。 • 無策に・無闇矢鱈に負債を抱えていい訳ではない。不要な負債を 抱えないためにも、計画的な管理と返済を前提とした意思決定 が必要。 技術的負債をコントロールする
None
技術的負債を最小限に抑える取り組み・テクニック
• 機能追加や修正の度に影響範囲を調べ、手動でテストをするのはとても大 変な作業。プロダクトが大きくなればなるほどそのコストは増大 。 • ランタイムやフレームワーク、ライブラリのバージョンアップ作業は影響 範囲が大きくなりがち。 (全体のリグレッションテストを手動で……?😱) • 自動テストを導入
することで、機能追加はもちろん、ランタイムのバー ジョンアップなども短時間かつ自信を持って 行うことができるようにな る。 • もちろん継続的インテグレーション(CI) もご一緒に。 自動テストを導入する
自動テストを書く余裕がない……? https://zenn.dev/coconala/articles/write-tests-in-parallel https://speakerdeck.com/o0h/phpcon-nagoya-2025
• 先に述べたとおり、フレームワークやライブラリを導入すること で、バージョンアップ対応のコスト や、破壊的変更・開発終了の リスクが生じる。 • そのため、フレームワークやライブラリの導入の際は、まず必要 性や導入によるメリットを十分に検討し、場合によっては導入を 見送る決断 も必要。
• 導入する場合も、将来性や安定性、他パッケージへの移行のしや すさなどをしっかりと見極め、適切なパッケージを選ぶようにす る。 依存を最小限に抑える・厳選する
• 「◦◦さんが作ったところだから」「□□さんが詳しいから」で 任せきりになっていると、ボトルネックになる し、退職時に詰 む。 • 属人性を排除し、チーム全員がコードに責任を持ち、誰でも変更・ 改善できるようにすることでボトルネックは解消 する。 •
また、知識がチーム全体で共有 され、メンバーの退職や異動によ るリスクを最小化 できる。 • ペアプロやモブプロもオススメです。 コードの共同所有
• 「クラス名とメソッド名を見れば、みんなわかるでしょ」「やって ることがシンプルだし、コメントいらないよね?」は危険! • コードの意図 をコメントなしで100%表現するのはとても難しい。 実装時の背景や経緯が残ることで、リファクタリングも容易に。 • 論理名(日本語)と物理名(英語)の関係を全員が理解できている とは限らないため、クラスやプロパティの説明も大事
。 • チーム全体での知識共有・コードの共同所有が促進され、新規参画 したメンバーもスムーズに作業に参加可能に。 コメントやドキュメントをちゃんと書く
• 腐敗防止層: 外部やレガシーシステムの複雑さを吸収し、内部をクリー ンに保つための設計パターン。 • 外部依存との間に: 依存するパッケージや外部 API などとの間に抽象化 された腐敗防止層を置くことで、破壊的変更への対応や、将来的な乗り
換えが容易 になる。 • レガシーコードとの間に: 新しい機能を開発する際、レガシーコードを 直接参照せずに腐敗防止層を挟むことで、新しいコードをクリーンに保 ち、リファクタリングも容易 になる。 腐敗防止層
腐敗防止層 https://speakerdeck.com/okashoi/interface-and-anti-corruption-layer
• 返済せずに放置すれば負債は増え続ける 。 • 整理・整頓・リファクタリングを「いつかやる 」ではなく日常の ルーティン に組み込み、文化を醸成 することで、コードをクリー ンに保つ。
• ボーイスカウトルール: コードに手を入れる際、ちょっとだけで もコードをキレイにする。 • リファクタリングデー: 毎月必ずリファクタリングのための日 を 設ける。 • 20%ルール: スプリントの20%を開発者目線の改善 に充てる。 日常的な整理・整頓・リファクタリング
リファクタリングデーについて https://developers.prtimes.jp/2021/12/13/introducing-refactoring-day/
まとめ
• 技術的負債はビジネス的なリスク であり、開発者だけの問題では ない。 • 無闇に敵視したり回避したりするのではなく、必要な負債は受け入 れつつ、最小限に抑えることが重要 。 • 放置すると負債が膨らみ、手に負えなくなる。適切にコントロー
ルすることで、スピードと柔軟性を維持するのが吉。 まとめ
THANK YOU!!
• 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ • よし、技術的負債について知ろう
- Qiita • 『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya • 時間がないからこそ、テストを書く • 設計の考え方 - インターフェースと腐敗防止層編 #phpconfuk Appendix: 参考資料