Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

forrep
October 05, 2023

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

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

forrep

October 05, 2023
Tweet

More Decks by forrep

Other Decks in Programming

Transcript

  1. 自己紹介 • 名前 ◦ 羽山 純(Jun Hayama) • 所属 ◦

    株式会社ラクーンホールディングス 技術戦略部 • 技術領域 ◦ バックエンド・インフラ ◦ パフォーマンス改善 ◦ AI(企業審査AI) • 個人活動 ◦ アプリ開発 2
  2. クィーン 生産コスト: 9000 ペリカ 維持コスト: 500 ペリカ ビショップ 生産コスト: 3500

    ペリカ 維持コスト: 260 ペリカ ナイト 生産コスト: 3000 ペリカ 維持コスト: 240 ペリカ 4 ポーン 生産コスト: 1000 ペリカ 維持コスト: 100 ペリカ ルーク 生産コスト: 5000 ペリカ 維持コスト: 300 ペリカ 戦略シミュレーションゲームをプレイした経験はありませんか? 所持金: 4450 ペリカ
  3. クィーン 生産コスト: 9000 ペリカ 維持コスト: 500 ペリカ ビショップ 生産コスト: 3500

    ペリカ 維持コスト: 260 ペリカ ナイト 生産コスト: 3000 ペリカ 維持コスト: 240 ペリカ 5 ポーン 生産コスト: 1000 ペリカ 維持コスト: 100 ペリカ ルーク 生産コスト: 5000 ペリカ 維持コスト: 300 ペリカ 所持金からユニットを生産して戦力を強化します ユニットには維持コストがあります 所持金: 4450 ペリカ 所持金の範囲でユニットを生産します ユニットには生産コストと維持コストがあります
  4. 11 • 開発力 → 所持金 • プログラムコード → ユニット •

    技術的負債 → 維持コスト 戦略シミュレーションゲームでは 「維持コスト」をうまくコントロールしています しかし ウェブサービス運営では 技術的負債に振り回されがち
  5. 13 • 戦略シミュレーションゲームでは ◦ 所持金 → 󰢏見える ◦ ユニットの生産コスト →

    󰢏見える ◦ ユニットの維持コスト → 󰢏見える • ウェブサービス運営では ◦ 開発力(人員) → 󰢏見える ◦ 機能(プログラムコード)を開発する工数 → 󰢏見える ◦ 機能(プログラムコード)で発生する技術的負債 → 󰢃見えない
  6. • 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月 時点のスナップショット)
  7. 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
  8. 技術的負債の考え方 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年 インフラ
  9. その中から PHP8 を選定してコードを書き始めるとします それを途中から Python3 に変更するとしたら? • Python3 へ移行する難易度は高い →

    変化の難易度: 高 ⤴ • Python3 へ移行する必要性は低い → 変化の必要性: 極低 ⤵ 技術的負債は 「高」x「ほぼゼロ」=「ほぼゼロ」 技術的負債の定義 31 PHP8 Python3
  10. 1年経過して、もし PHP8.1 が登場したら? • PHP8.1 へ移行する難易度は低~中 → 変化の難易度: 低 ⤵

    • PHP8.1 へ移行する必要性は高い → 変化の必要性: 高 ⤴ 技術的負債は 「低~中」x「高」=「さほど高くない」 ※難易度はあくまで一般論です 技術的負債の定義 32 PHP8 PHP8.1
  11. さらに2年経過して、PHP9 が登場したら? • PHP9 へ移行する難易度は高い → 変化の難易度: 高 ⤴ •

    PHP9 へ移行する必要性は高い → 変化の必要性: 高 ⤴ 技術的負債は 「高」x「高」=「急上昇 ⤴⤴」 ※難易度はあくまで一般論です 技術的負債の定義 33 PHP8.1 PHP9
  12. 変化の必要性 • 依存リソースの影響 ◦ プログラム言語・フレームワーク・ライブラリ ▪ バージョンアップ・開発元のスタンス・サポート終了・脆弱性対応・非トレンド化 ◦ 外部API・外部リソース ▪

    仕様変更・料金体系変更・通信プロトコル問題・外部起因の障害対応 ◦ インフラ・OS・ミドルウェア ▪ 経年劣化・パフォーマンス・メンテナンス対応・サポート終了 ◦ 開発環境 ▪ 非トレンド化・開発効率 • サービス・ビジネスの変化 ◦ 市場・ニーズ・環境・法制度の変化 → 消費税・インボイス制度 ◦ ビジネスのステージ変化 → 非機能要件の変化・利用者増・投資判断の変化 37
  13. 技術的負債の考え方 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年 インフラ
  14. 変化の必要性 PHP と Python のメジャーバージョンアップ頻度を 単純に比較すると傾向がわかります ※2023年現在 • PHP は過去28年間でメジャーバージョンアップが6回

    ◦ 4~5年間ごとにメジャーバージョンアップ • Python は過去32年間でメジャーバージョンアップが2回 ◦ 16年間ごとにメジャーバージョンアップ サポート期間は https://endoflife.date/ を確認しましょう 39
  15. • 主に「調査工数」と「開発工数」 • 「調査工数」を上昇させる要素 ◦ ドキュメントの未整備 ◦ テストコードの欠如 ◦ 汎用的な機能(実際の使われ方が千差万別)

    ◦ そのシステムをよく知る人が少ない ◦ 利用頻度の低い機能や不要ファイルが残っている ◦ greppability の低いプログラムコード・インフラ設定 • 「開発工数」を上昇させる要素 ◦ 言語・フレームワークのバージョンアップ(破壊的変更の多さ) ◦ テストコードの欠如 ◦ 非機能要件の考慮不足(アーキテクチャレベルの変更におよぶ可能性) 変化の難易度 40
  16. 変化の難易度 • greppability が低い ◦ 複数/単数/スネーク/パスカルをライブラリが自動変換 ◦ 「設定よりも規約」でDBテーブルとモデルを自動マッピング ◦ キーワードを動的生成

    → open(“singup_${plan}.template”) • 利用頻度の低い機能・不要ファイルが残っている ◦ 維持コストがかかるので、必要性の低い機能は消す ◦ 影響範囲調査で使っていないリソースがヒットする • 汎用的な機能 ◦ メモ欄に運用ルールで半構造化データが文字列で残される 41
  17. プログラムコードの総量と価値のバランス 株式投資のEPS(Earnings Per Share)指標をご存じでしょうか? • 「1株あたり純利益」 → 1株あたりいくら稼いだか? ◦ 株式の取得にはお金が必要

    → デメリット ◦ 取得した1株でお金を稼げる → メリット • プログラムコードは? ◦ プログラムコードの生成に工数が必要 → デメリット ◦ プログラムコードの総量に対して維持コストが必要 → デメリット ◦ プログラムコードはウェブサービスの価値を高める → メリット • 少ないプログラムコードで価値を最大化できると良い • EPL=Earnings Per Line(1行あたり純利益)を提唱 ◦ 価値を生み出さないコードをガツガツ消す動機になる ◦ 労働集約型のウェブサービスになっていないかの指標 43
  18. まとめ • 技術的負債とは ◦ 見えていないことが問題 ◦ 現在から未来への「面」で考える ◦ 維持コストであり、必ず発生するものと考える ◦

    可視化できれば自然と削減を考えるはず ◦ 「変化の必要性」と「変化の難易度」の掛け算で求める ▪ 各要素が増加する要因を把握すれば削減もできる ◦ 単純にソースコードの行数を減らすことから始める みなさんも技術的負債と良いお付き合いをしていきましょう 45