Tweet
Tweet

Slide 1

Slide 1 text

技術的負債に対する視力を得る 1 株式会社ラクーンホールディングス 技術戦略部 羽山純

Slide 2

Slide 2 text

自己紹介 ● 名前 ○ 羽山 純（Jun Hayama） ● 所属 ○ 株式会社ラクーンホールディングス 技術戦略部 ● 技術領域 ○ バックエンド・インフラ ○ パフォーマンス改善 ○ AI（企業審査AI） ● 個人活動 ○ アプリ開発 2

Slide 3

Slide 3 text

アジェンダ 1. 技術的負債の問題を理解する 2. 技術的負債の定義 3. 技術的負債の可視化 今回の発表は「技術的負債」に対する知識を高めて 見える状態にすることを目的とします （※問題が可視化されれば自然と対処されるはず） 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

クィーン 生産コスト: 9000 ペリカ 維持コスト: 500 ペリカ ビショップ 生産コスト: 3500 ペリカ 維持コスト: 260 ペリカ ナイト 生産コスト: 3000 ペリカ 維持コスト: 240 ペリカ 5 ポーン 生産コスト: 1000 ペリカ 維持コスト: 100 ペリカ ルーク 生産コスト: 5000 ペリカ 維持コスト: 300 ペリカ 所持金からユニットを生産して戦力を強化します ユニットには維持コストがあります 所持金: 4450 ペリカ 所持金の範囲でユニットを生産します ユニットには生産コストと維持コストがあります

Slide 6

Slide 6 text

6 ユニットの活躍で勢力拡大 → 収益が増加 さらに多くのユニットを生産可能に

Slide 7

Slide 7 text

7 戦略シミュレーションゲームの各要素は ウェブサービス運営と似ている部分があります

Slide 8

Slide 8 text

8 開発力を消費してプログラムコードを生み出し、 便利な機能でウェブサービスをより魅力的にします （ゲームにおける）ユニット → プログラムコード

Slide 9

Slide 9 text

9 プログラムコードの活躍で利用者が増えると 会社規模が拡大して開発力が増加します （ゲームにおける）所持金 → 開発力（人員）

Slide 10

Slide 10 text

10 フレームワーク のバージョンUP OS・言語の サポート切れ 脆弱性対応 プログラムコードは近い将来の技術的負債であり、 継続的なメンテナンスが必要です （ゲームにおける）維持コスト → 技術的負債

Slide 11

Slide 11 text

11 ● 開発力 → 所持金 ● プログラムコード → ユニット ● 技術的負債 → 維持コスト 戦略シミュレーションゲームでは 「維持コスト」をうまくコントロールしています しかし ウェブサービス運営では 技術的負債に振り回されがち

Slide 12

Slide 12 text

12 それはなぜか？

Slide 13

Slide 13 text

13 ● 戦略シミュレーションゲームでは ○ 所持金 → 󰢏見える ○ ユニットの生産コスト → 󰢏見える ○ ユニットの維持コスト → 󰢏見える ● ウェブサービス運営では ○ 開発力（人員） → 󰢏見える ○ 機能（プログラムコード）を開発する工数 → 󰢏見える ○ 機能（プログラムコード）で発生する技術的負債 → 󰢃見えない

Slide 14

Slide 14 text

14 技術的負債は見えない

Slide 15

Slide 15 text

15 技術的負債は見えないので、 無計画に機能をてんこ盛りにすると・・・ この機能あったら 便利だよね！ この機能も ほしくない？ この条件で 表示を出し分けたい スマホアプリも 作りたい

Slide 16

Slide 16 text

16 技術的負債で首が回らなくなります

Slide 17

Slide 17 text

17 そこで、本日のお題は

Slide 18

Slide 18 text

技術的負債に対する視力を得る 18

Slide 19

Slide 19 text

技術的負債の定義 19

Slide 20

Slide 20 text

● 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月 時点のスナップショット）

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

技術的負債の考え方 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年 インフラ

Slide 23

Slide 23 text

技術的負債の考え方 23 技術的負債をスナップショットで認識すると → 過去～現在に着目 技術的負債を面で認識すると → 現在～未来に着目 あらゆるプログラムコードは技術的負債であり、 維持コストがかかり続けます

Slide 24

Slide 24 text

プログラムコードと技術的負債 24 時間軸 プログラムコードの行数（規模） ゼロから開発、時間経過で 行数増がゆるやかになるの はナゼか？

Slide 25

Slide 25 text

プログラムコードと技術的負債 25 時間軸 技術的負債（維持コスト） プログラムコードの規模に 準じた技術的負債が発生 プログラムコードの行数（規模）

Slide 26

Slide 26 text

プログラムコードと技術的負債 26 時間軸 技術的負債（維持コスト） 開発力（人員） 増員・スキルアップがない 前提とします プログラムコードの行数（規模）

Slide 27

Slide 27 text

プログラムコードと技術的負債 27 時間軸 技術的負債（維持コスト） 開発力（人員） プログラムコードの生成量 維持コストで全ての開発力 が消費される状況 プログラムコードの行数（規模）

Slide 28

Slide 28 text

技術的負債の定義 28 こうならないためには 技術的負債（=維持コスト）の把握が必要です

Slide 29

Slide 29 text

技術的負債の定義 技術的負債の構成要素を次の2点と考えます ● 変化の必要性 ● 変化の難易度 そして、技術的負債を以下の定義とします 技術的負債 = 変化の必要性 x 変化の難易度 29

Slide 30

Slide 30 text

技術選定の段階では無限の選択肢があります 技術的負債の定義 30 技術選定ルート Ruby3 Python3 PHP8 Java Golang

Slide 31

Slide 31 text

その中から PHP8 を選定してコードを書き始めるとします それを途中から Python3 に変更するとしたら？ ● Python3 へ移行する難易度は高い → 変化の難易度: 高 ⤴ ● Python3 へ移行する必要性は低い → 変化の必要性: 極低 ⤵ 技術的負債は 「高」x「ほぼゼロ」=「ほぼゼロ」 技術的負債の定義 31 PHP8 Python3

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

さらに2年経過して、PHP9 が登場したら？ ● PHP9 へ移行する難易度は高い → 変化の難易度: 高 ⤴ ● PHP9 へ移行する必要性は高い → 変化の必要性: 高 ⤴ 技術的負債は 「高」x「高」=「急上昇 ⤴⤴」 ※難易度はあくまで一般論です 技術的負債の定義 33 PHP8.1 PHP9

Slide 34

Slide 34 text

もしあの時 Python3 を選定していたらどうなったでしょう？ 3年後でもメジャーバージョンアップの可能性は低く、 マイナーバージョンアップへの対応で済みます ※依存ライブラリのサポート期間は考慮してません 技術的負債の定義 34 PHP8.1 PHP9 Python3

Slide 35

Slide 35 text

技術的負債の可視化 35

Slide 36

Slide 36 text

変化の必要性・変化の難易度とは 36 「変化の必要性」「変化の難易度」の中身を見ていきます

Slide 37

Slide 37 text

変化の必要性 ● 依存リソースの影響 ○ プログラム言語・フレームワーク・ライブラリ ■ バージョンアップ・開発元のスタンス・サポート終了・脆弱性対応・非トレンド化 ○ 外部API・外部リソース ■ 仕様変更・料金体系変更・通信プロトコル問題・外部起因の障害対応 ○ インフラ・OS・ミドルウェア ■ 経年劣化・パフォーマンス・メンテナンス対応・サポート終了 ○ 開発環境 ■ 非トレンド化・開発効率 ● サービス・ビジネスの変化 ○ 市場・ニーズ・環境・法制度の変化 → 消費税・インボイス制度 ○ ビジネスのステージ変化 → 非機能要件の変化・利用者増・投資判断の変化 37

Slide 38

Slide 38 text

技術的負債の考え方 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年 インフラ

Slide 39

Slide 39 text

変化の必要性 PHP と Python のメジャーバージョンアップ頻度を 単純に比較すると傾向がわかります ※2023年現在 ● PHP は過去28年間でメジャーバージョンアップが6回 ○ 4~5年間ごとにメジャーバージョンアップ ● Python は過去32年間でメジャーバージョンアップが2回 ○ 16年間ごとにメジャーバージョンアップ サポート期間は https://endoflife.date/ を確認しましょう 39

Slide 40

Slide 40 text

● 主に「調査工数」と「開発工数」 ● 「調査工数」を上昇させる要素 ○ ドキュメントの未整備 ○ テストコードの欠如 ○ 汎用的な機能（実際の使われ方が千差万別） ○ そのシステムをよく知る人が少ない ○ 利用頻度の低い機能や不要ファイルが残っている ○ greppability の低いプログラムコード・インフラ設定 ● 「開発工数」を上昇させる要素 ○ 言語・フレームワークのバージョンアップ（破壊的変更の多さ） ○ テストコードの欠如 ○ 非機能要件の考慮不足（アーキテクチャレベルの変更におよぶ可能性） 変化の難易度 40

Slide 41

Slide 41 text

変化の難易度 ● greppability が低い ○ 複数/単数/スネーク/パスカルをライブラリが自動変換 ○ 「設定よりも規約」でDBテーブルとモデルを自動マッピング ○ キーワードを動的生成 → open(“singup_${plan}.template”) ● 利用頻度の低い機能・不要ファイルが残っている ○ 維持コストがかかるので、必要性の低い機能は消す ○ 影響範囲調査で使っていないリソースがヒットする ● 汎用的な機能 ○ メモ欄に運用ルールで半構造化データが文字列で残される 41

Slide 42

Slide 42 text

技術的負債の可視化 プログラムコードを生み出す際には 「変化の必要性」「変化の難易度」を把握しましょう ※変化の必要性 x 変化の難易度 = 技術的負債 42

Slide 43

Slide 43 text

プログラムコードの総量と価値のバランス 株式投資のEPS（Earnings Per Share）指標をご存じでしょうか？ ● 「1株あたり純利益」 → 1株あたりいくら稼いだか？ ○ 株式の取得にはお金が必要 → デメリット ○ 取得した1株でお金を稼げる → メリット ● プログラムコードは？ ○ プログラムコードの生成に工数が必要 → デメリット ○ プログラムコードの総量に対して維持コストが必要 → デメリット ○ プログラムコードはウェブサービスの価値を高める → メリット ● 少ないプログラムコードで価値を最大化できると良い ● EPL=Earnings Per Line（1行あたり純利益）を提唱 ○ 価値を生み出さないコードをガツガツ消す動機になる ○ 労働集約型のウェブサービスになっていないかの指標 43

Slide 44

Slide 44 text

技術的負債オフセット 価値（プログラムコード）を生み出すと技術的負債も発生します 全体の総量としての技術的負債をコントロールできればよいので 新しい技術的負債を生み出す代わりに リファクタリングで既存の技術的負債を削減する 技術的負債オフセット という方法も推奨します 44

Slide 45

Slide 45 text

まとめ ● 技術的負債とは ○ 見えていないことが問題 ○ 現在から未来への「面」で考える ○ 維持コストであり、必ず発生するものと考える ○ 可視化できれば自然と削減を考えるはず ○ 「変化の必要性」と「変化の難易度」の掛け算で求める ■ 各要素が増加する要因を把握すれば削減もできる ○ 単純にソースコードの行数を減らすことから始める みなさんも技術的負債と良いお付き合いをしていきましょう 45

Slide 46

Slide 46 text

ご清聴ありがとうございました 46