技術的負債という武器の扱い方を考える

by to_lz1

Slide 1

Slide 1 text

技術的負債という   「武器」の使い方を考える   2025-12-02 大規模Webサービスの技術負債、どう向き合う？？   Classi株式会社鳥山誠（Toriyama Makoto）  

Slide 2

Slide 2 text

Copyright © 2025 Classi Corp. All Rights Reserved. 2 従業員数自己紹介  鳥山誠  Classi株式会社プロダクト本部     経歴:  新卒でSIer子会社  → 人材系企業  → 医療系企業   → 現職（教育系企業）    経験してきたロール:   ソフトウェアエンジニア、  データエンジニア、  SRE、チームリーダー etc.    趣味:  音楽、本、ゲーム、ときどき山登り 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

技術的負債の正体   01 

Slide 6

Slide 6 text

Copyright © 2025 Classi Corp. All Rights Reserved. 「技術的負債」の出典、負債のメタファー   6  著名な開発者、Ward Cunninghamが言った......と、   『リファクタリング』の著者、Martin Fowlerは言っている   出典: https://bliki-ja.github.io/TechnicalDebt   ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。 

Slide 7

Slide 7 text

Copyright © 2025 Classi Corp. All Rights Reserved. ご本人の説明   7  2009年にWard CunninghamがアップロードしたYouTube動画上での説明は、こう......   もしも自分たちが書いているプログラムを、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、......開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです   出典: https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor  

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © 2025 Classi Corp. All Rights Reserved. けど、考えてみると   12  「現時点での不十分な理解」でソフトウェアをリリースすることが「負債」の定義だとすると、   「当時最新のフレームワークで書いたシステム」が古くなるのは必ずしも「負債」ではないかもしれない   フレームワークの進化  最近出たAngularJSに   挑戦してみよう！  全然最新に追随出来てない！  EOLじゃん！負債だ！  （変更が大変なのはそれはそうだけど）  2010年の時点では何も犠牲にしてない   有識者の離脱  更新の停滞  2010  2025  ※架空の事例です 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © 2025 Classi Corp. All Rights Reserved. 「より早く＝借り入れ」の現場で起きていること   15  いくつかパターンがあるが、概ね「知識の欠落」という言葉と   「内部的 ⇔ 外部的」「技術的 ⇔ ドメイン的」の2軸で整理できる（と筆者は考える）   理論値では動くはずだけど、   本番の負荷に耐えられるか……？   全部入りで作ろうとしてるけど、   本当にお客さんはこれ使うの？   設計に自信がないけど、   有識者のレビューを受ける時間がない   この例外処理、業務フロー的に   あり得ないと思うけど一応書くか  

Slide 16

Slide 16 text

Copyright © 2025 Classi Corp. All Rights Reserved. 「内部的な知識の欠落」は基本的に埋めた方が良い   16  「設計に自信がないけど、有識者のレビューを受ける時間がない」（内部×技術）   ❌「レビューせずに急いで出してヨシ！」   󰢏「レビューはする。期日の件はスコープ調整しよう」   → レビューで得た設計知識が次の生産性を上げる     「この例外処理、業務フロー的にあり得ないと思うけど一応書くか」（内部×ドメイン）   ❌「違和感あるけどコードとしては動くから approve！」 󰢏「ドメインエキスパートのXXさんにSlackで聞いてみてくれない？」   → 質問して得たドメイン知識が次の生産性を上げる          

Slide 17

Slide 17 text

Slide 18

Slide 18 text

事例紹介 - 「欠落」を「リリース」で埋めに行く   02 

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright © 2025 Classi Corp. All Rights Reserved. 一口に「カスタマイズ」と言っても   22  理論上は色々なパターンが考えられる   - コロナ対応で「COVID-19」を追加したい   - 「出席停止」系を保護者に勝手に入れられると困るから消したい   - 自分の学校独自の活動を大項目として追加したい   - 「病気」を早退の時でも使えるようにしたい   - 「その他」使用時に備考欄に必ず理由を入力してもらいたい      

Slide 23

Slide 23 text

Copyright © 2025 Classi Corp. All Rights Reserved. 解法: 小さな仕様でまずリリースする   23  例えば、「小項目だけ追加 or 削除ができる」仕様なら......  - コロナ対応で「COVID-19」を追加したい → 対応可能 ⭕  - 「出席停止」系を保護者に勝手に入れられると困るから消したい → 対応可能 ⭕  - 自分の学校独自の活動を大項目として追加したい → 対応不可✖   - 「病気」を早退の時でも使えるようにしたい → 対応不可✖   - 「その他」使用時に備考欄に必ず理由を入力してもらいたい → 工夫すれば可能△   - 「その他（備考欄に必ずご入力下さい）」を新設して貰えばいい     

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright © 2025 Classi Corp. All Rights Reserved. 結果: 小さな仕様で大多数のユーザに満足いただけた   26  - 想定したユースケースはハマっていて、感謝の言葉ももらえた 󰢏  - 大項目を追加したい、という声も一部あった   - が、懸念していたより少数だった   - 声が多かった場合は作ることを覚悟していたが、一旦作らない判断をした     1. 小さな仕様にすることで「より早くリリース」した     2. 「顧客が要望しているもの」に関する知識を得た     3. 「使われない機能」という最大の負債を防いだ  

Slide 27

Slide 27 text

まとめ - 負債の再解釈   03 

Slide 28

Slide 28 text

Copyright © 2025 Classi Corp. All Rights Reserved. まとめ - 負債の再解釈   28  - 「知識の欠落がある前提でリリースを急ぐこと」こそが負債の「借り入れ」である   - 内部知識の欠落を放ってリリースしてしまうと、自然には返せない   - だからこそ、我々は普段こっちを目にすることが多い     - 「外部知識の欠落」なら、実はリリースすることによって埋めることもできる  - 我々のコードがプロダクトと実世界を繋ぐから   - ここで力を発揮するには「要件定義への参画」が必須   - 得られた知識によって、必要に応じてまた改修をすれば良い   - だからこそ、「継続改善リリースしやすい環境」が超重要  