技術的負債に対する視力を得る / How to View Technical Debt

見えているはずなのに認識できていなく、でも一度気づいたら以降はよく目に入るようになった経験はありませんか？
「技術的負債」はそのたぐいの問題で、普段は目に見えないから無意識のうちにたまり、
ある日気づいたら身動きが取れないほど蓄積していたという状況になりがちです。
そこで今回は技術的負債に対する視力を得ることで、技術的負債の蓄積を普段から意識して、自然と削減する方法を解説します。

1. 技術的負債に対する視力を得る 1 株式会社ラクーンホールディングス 技術戦略部 羽山純
2. 自己紹介 • 名前 ◦ 羽山 純（Jun Hayama） • 所属 ◦ 株式会社ラクーンホールディングス 技術戦略部 • 技術領域 ◦ バックエンド・インフラ ◦ パフォーマンス改善 ◦ AI（企業審査AI） • 個人活動 ◦ アプリ開発 2
3. アジェンダ 1. 技術的負債の問題を理解する 2. 技術的負債の定義 3. 技術的負債の可視化 今回の発表は「技術的負債」に対する知識を高めて 見える状態にすることを目的とします （※問題が可視化されれば自然と対処されるはず） 3
4. クィーン 生産コスト: 9000 ペリカ 維持コスト: 500 ペリカ ビショップ 生産コスト: 3500 ペリカ 維持コスト: 260 ペリカ ナイト 生産コスト: 3000 ペリカ 維持コスト: 240 ペリカ 4 ポーン 生産コスト: 1000 ペリカ 維持コスト: 100 ペリカ ルーク 生産コスト: 5000 ペリカ 維持コスト: 300 ペリカ 戦略シミュレーションゲームをプレイした経験はありませんか？ 所持金: 4450 ペリカ
5. クィーン 生産コスト: 9000 ペリカ 維持コスト: 500 ペリカ ビショップ 生産コスト: 3500 ペリカ 維持コスト: 260 ペリカ ナイト 生産コスト: 3000 ペリカ 維持コスト: 240 ペリカ 5 ポーン 生産コスト: 1000 ペリカ 維持コスト: 100 ペリカ ルーク 生産コスト: 5000 ペリカ 維持コスト: 300 ペリカ 所持金からユニットを生産して戦力を強化します ユニットには維持コストがあります 所持金: 4450 ペリカ 所持金の範囲でユニットを生産します ユニットには生産コストと維持コストがあります
6. 6 ユニットの活躍で勢力拡大 → 収益が増加 さらに多くのユニットを生産可能に
7. 7 戦略シミュレーションゲームの各要素は ウェブサービス運営と似ている部分があります
8. 8 開発力を消費してプログラムコードを生み出し、 便利な機能でウェブサービスをより魅力的にします （ゲームにおける）ユニット → プログラムコード
9. 9 プログラムコードの活躍で利用者が増えると 会社規模が拡大して開発力が増加します （ゲームにおける）所持金 → 開発力（人員）
10. 10 フレームワーク のバージョンUP OS・言語の サポート切れ 脆弱性対応 プログラムコードは近い将来の技術的負債であり、 継続的なメンテナンスが必要です （ゲームにおける）維持コスト → 技術的負債
11. 11 • 開発力 → 所持金 • プログラムコード → ユニット • 技術的負債 → 維持コスト 戦略シミュレーションゲームでは 「維持コスト」をうまくコントロールしています しかし ウェブサービス運営では 技術的負債に振り回されがち
12. 12 それはなぜか？
13. 13 • 戦略シミュレーションゲームでは ◦ 所持金 → 󰢏見える ◦ ユニットの生産コスト → 󰢏見える ◦ ユニットの維持コスト → 󰢏見える • ウェブサービス運営では ◦ 開発力（人員） → 󰢏見える ◦ 機能（プログラムコード）を開発する工数 → 󰢏見える ◦ 機能（プログラムコード）で発生する技術的負債 → 󰢃見えない
14. 14 技術的負債は見えない
15. 15 技術的負債は見えないので、 無計画に機能をてんこ盛りにすると・・・ この機能あったら 便利だよね！ この機能も ほしくない？ この条件で 表示を出し分けたい スマホアプリも 作りたい
16. 16 技術的負債で首が回らなくなります
17. 17 そこで、本日のお題は
18. 技術的負債に対する視力を得る 18
19. 技術的負債の定義 19
20. • 2020年前半にリリースしたウェブサービス ◦ 2023年10月時点のサポート状況を洗い出し • 「腐臭を放つものを技術的負債とみなす」のが多数派 ◦ ある時点のスナップショットで判断 技術的負債の考え方 20 名前 リリース日 サポート期限 対応 Python 3.8 2019-10-14 🟢 2024-10-14 OK Django 2.2 (LTS) 2019-04-01 🔴 2022-04-01 3.2 or 4.2 へ Update React 16 2017-09-26 🟡 - Update したい Ubuntu 18.04 (LTS) 2018-04-26 🔴 2023-05-31 22.04 へ Update ・・・ ・・・ ・・・ ・・・ とあるウェブサービスのシステム構成（2023年10月 時点のスナップショット）
21. 2020年 2021年 2023年 2024年 2022年 技術的負債の考え方 21 ウェブサービスを運用するタイムライン とあるスナップショットに着目して 技術的負債の検出と返済をする ローンチ 技術的負債を「点」でなく 「線」で考える 2020年 2021年 2023年 2024年 次のように考える Python3.9 Python3.10 Python3.11 2022年 Python3.12 Python3.8 2019年 2019年 Django2.2 Django3.2 Django4.2
22. 技術的負債の考え方 22 Python Django さらに 「線」でなく「面」で考える ※必ず発生するものと考える ・ ・ ・ 外部API Ubuntu nginx ローンチ 機能A 機能B React 開発環境 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 インフラ
23. 技術的負債の考え方 23 技術的負債をスナップショットで認識すると → 過去～現在に着目 技術的負債を面で認識すると → 現在～未来に着目 あらゆるプログラムコードは技術的負債であり、 維持コストがかかり続けます
24. プログラムコードと技術的負債 24 時間軸 プログラムコードの行数（規模） ゼロから開発、時間経過で 行数増がゆるやかになるの はナゼか？
25. プログラムコードと技術的負債 25 時間軸 技術的負債（維持コスト） プログラムコードの規模に 準じた技術的負債が発生 プログラムコードの行数（規模）
26. プログラムコードと技術的負債 26 時間軸 技術的負債（維持コスト） 開発力（人員） 増員・スキルアップがない 前提とします プログラムコードの行数（規模）
27. プログラムコードと技術的負債 27 時間軸 技術的負債（維持コスト） 開発力（人員） プログラムコードの生成量 維持コストで全ての開発力 が消費される状況 プログラムコードの行数（規模）
28. 技術的負債の定義 28 こうならないためには 技術的負債（=維持コスト）の把握が必要です
29. 技術的負債の定義 技術的負債の構成要素を次の2点と考えます • 変化の必要性 • 変化の難易度 そして、技術的負債を以下の定義とします 技術的負債 = 変化の必要性 x 変化の難易度 29
30. 技術選定の段階では無限の選択肢があります 技術的負債の定義 30 技術選定ルート Ruby3 Python3 PHP8 Java Golang
31. その中から PHP8 を選定してコードを書き始めるとします それを途中から Python3 に変更するとしたら？ • Python3 へ移行する難易度は高い → 変化の難易度: 高 ⤴ • Python3 へ移行する必要性は低い → 変化の必要性: 極低 ⤵ 技術的負債は 「高」x「ほぼゼロ」=「ほぼゼロ」 技術的負債の定義 31 PHP8 Python3
32. 1年経過して、もし PHP8.1 が登場したら？ • PHP8.1 へ移行する難易度は低~中 → 変化の難易度: 低 ⤵ • PHP8.1 へ移行する必要性は高い → 変化の必要性: 高 ⤴ 技術的負債は 「低~中」x「高」=「さほど高くない」 ※難易度はあくまで一般論です 技術的負債の定義 32 PHP8 PHP8.1
33. さらに2年経過して、PHP9 が登場したら？ • PHP9 へ移行する難易度は高い → 変化の難易度: 高 ⤴ • PHP9 へ移行する必要性は高い → 変化の必要性: 高 ⤴ 技術的負債は 「高」x「高」=「急上昇 ⤴⤴」 ※難易度はあくまで一般論です 技術的負債の定義 33 PHP8.1 PHP9
34. もしあの時 Python3 を選定していたらどうなったでしょう？ 3年後でもメジャーバージョンアップの可能性は低く、 マイナーバージョンアップへの対応で済みます ※依存ライブラリのサポート期間は考慮してません 技術的負債の定義 34 PHP8.1 PHP9 Python3
35. 技術的負債の可視化 35
36. 変化の必要性・変化の難易度とは 36 「変化の必要性」「変化の難易度」の中身を見ていきます
37. 変化の必要性 • 依存リソースの影響 ◦ プログラム言語・フレームワーク・ライブラリ ▪ バージョンアップ・開発元のスタンス・サポート終了・脆弱性対応・非トレンド化 ◦ 外部API・外部リソース ▪ 仕様変更・料金体系変更・通信プロトコル問題・外部起因の障害対応 ◦ インフラ・OS・ミドルウェア ▪ 経年劣化・パフォーマンス・メンテナンス対応・サポート終了 ◦ 開発環境 ▪ 非トレンド化・開発効率 • サービス・ビジネスの変化 ◦ 市場・ニーズ・環境・法制度の変化 → 消費税・インボイス制度 ◦ ビジネスのステージ変化 → 非機能要件の変化・利用者増・投資判断の変化 37
38. 技術的負債の考え方 38 Python Django 赤いプロットが変化の必要性の 発生ポイント ・ ・ ・ 外部API Ubuntu nginx ローンチ 機能A 機能B React 開発環境 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 2020年 2021年 2023年 2024年 2022年 インフラ
39. 変化の必要性 PHP と Python のメジャーバージョンアップ頻度を 単純に比較すると傾向がわかります ※2023年現在 • PHP は過去28年間でメジャーバージョンアップが6回 ◦ 4~5年間ごとにメジャーバージョンアップ • Python は過去32年間でメジャーバージョンアップが2回 ◦ 16年間ごとにメジャーバージョンアップ サポート期間は https://endoflife.date/ を確認しましょう 39
40. • 主に「調査工数」と「開発工数」 • 「調査工数」を上昇させる要素 ◦ ドキュメントの未整備 ◦ テストコードの欠如 ◦ 汎用的な機能（実際の使われ方が千差万別） ◦ そのシステムをよく知る人が少ない ◦ 利用頻度の低い機能や不要ファイルが残っている ◦ greppability の低いプログラムコード・インフラ設定 • 「開発工数」を上昇させる要素 ◦ 言語・フレームワークのバージョンアップ（破壊的変更の多さ） ◦ テストコードの欠如 ◦ 非機能要件の考慮不足（アーキテクチャレベルの変更におよぶ可能性） 変化の難易度 40
41. 変化の難易度 • greppability が低い ◦ 複数/単数/スネーク/パスカルをライブラリが自動変換 ◦ 「設定よりも規約」でDBテーブルとモデルを自動マッピング ◦ キーワードを動的生成 → open(“singup_${plan}.template”) • 利用頻度の低い機能・不要ファイルが残っている ◦ 維持コストがかかるので、必要性の低い機能は消す ◦ 影響範囲調査で使っていないリソースがヒットする • 汎用的な機能 ◦ メモ欄に運用ルールで半構造化データが文字列で残される 41
42. 技術的負債の可視化 プログラムコードを生み出す際には 「変化の必要性」「変化の難易度」を把握しましょう ※変化の必要性 x 変化の難易度 = 技術的負債 42
43. プログラムコードの総量と価値のバランス 株式投資のEPS（Earnings Per Share）指標をご存じでしょうか？ • 「1株あたり純利益」 → 1株あたりいくら稼いだか？ ◦ 株式の取得にはお金が必要 → デメリット ◦ 取得した1株でお金を稼げる → メリット • プログラムコードは？ ◦ プログラムコードの生成に工数が必要 → デメリット ◦ プログラムコードの総量に対して維持コストが必要 → デメリット ◦ プログラムコードはウェブサービスの価値を高める → メリット • 少ないプログラムコードで価値を最大化できると良い • EPL=Earnings Per Line（1行あたり純利益）を提唱 ◦ 価値を生み出さないコードをガツガツ消す動機になる ◦ 労働集約型のウェブサービスになっていないかの指標 43
44. 技術的負債オフセット 価値（プログラムコード）を生み出すと技術的負債も発生します 全体の総量としての技術的負債をコントロールできればよいので 新しい技術的負債を生み出す代わりに リファクタリングで既存の技術的負債を削減する 技術的負債オフセット という方法も推奨します 44
45. まとめ • 技術的負債とは ◦ 見えていないことが問題 ◦ 現在から未来への「面」で考える ◦ 維持コストであり、必ず発生するものと考える ◦ 可視化できれば自然と削減を考えるはず ◦ 「変化の必要性」と「変化の難易度」の掛け算で求める ▪ 各要素が増加する要因を把握すれば削減もできる ◦ 単純にソースコードの行数を減らすことから始める みなさんも技術的負債と良いお付き合いをしていきましょう 45
46. ご清聴ありがとうございました 46