Upgrade to Pro — share decks privately, control downloads, hide ads and more …

技術的負債の発生と返し方の判断基準

mkitahara
January 25, 2024

 技術的負債の発生と返し方の判断基準

2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜
https://findy.connpass.com/event/306451/

mkitahara

January 25, 2024
Tweet

More Decks by mkitahara

Other Decks in Business

Transcript

  1. 技術的負債の発⽣と返し⽅の判断基準
    2024-01-25 @ TechBrew in 東京 ~技術的負債と共に歩むプロダクトの成⻑~
    mkitahara ( @mikity01985 )

    View full-size slide

  2. ⾃⼰紹介
    ● 名前
    mkitahara ( @mikity01985 )
    ● 職歴
    ○ SES企業 (2011/04〜 2014/12)
    ■ 新⼈研修で Androidアプリ開発 に出会いました
    ○ 開発受託企業 2社
    ○ EdTech企業 (2016/02〜 2023/07)
    ■ 業務委託時代を含めて7年所属
    ■ Androidエンジニアを中⼼にいろいろ
    ■ 出向‧業務委託のみから社員200⼈超えの組織を経験できました
    ○ FinTech企業 正社員 (2023/07〜 )
    ■ モバイルアプリチームのエンジニアリングマネージャーとしてJOIN
    ● 家族
    ○ 妻、⻑⼥(5)、次⼥(5ヶ⽉)

    View full-size slide

  3. 技術的負債とは?

    View full-size slide

  4. 技術的負債とは? ウォード‧カニンガムさんの⽂脈
    Shipping first time code is like going into debt. A little debt speeds development so
    long as it is paid back promptly with a rewrite. Objects make the cost of this
    transaction tolerable. The danger occurs when the debt is not repaid. Every minute
    spent on not-quite-right code counts as interest on that debt. Entire engineering
    organizations can be brought to a stand-still under the debt load of an
    unconsolidated implementation, object- oriented or otherwise. ※1
    ※1 Ward Cunningham, The WyCash Portfolio Management System (March 26, 1992)
    初めてコードを出荷するということは、借⾦をするようなものだ。少しの借⾦は、書き
    直しで速やかに返済される限り、開発を加速させる。オブジェクトはこの取引にかかる
    コストを許容範囲にしてくれる。危険なのは、借⾦が返済されない場合だ。適切でない
    コードに費やされた時間はすべて、借⾦の利息としてカウントされる。オブジェクト指
    向であろうとなかろうと、統合されていない実装の負債によって、エンジニアリング組
    織全体が⽴ち⾏かなくなる可能性がある。

    View full-size slide

  5. 借⾦というと......
    ネガティブなイメージがありますが.......

    View full-size slide

  6. 借⾦は必ずしも悪いものではない
    レバレッジ(てこの原理)
    - 理解した上で借⾦をしていれば、少ない期間でビジネスを⼤きくすることができます。

    View full-size slide

  7. ビジネスを進める上で
    技術的負債を抱えるという判断をすることがあります

    View full-size slide

  8. 技術的負債の分類

    View full-size slide

  9. 技術的負債の四象限※2
    ※2 Martin Fowler, Technical Debt Quadrant (October 14, 2009)
    無謀 慎重
    意図的
    不注意
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする

    View full-size slide

  10. Unknown Unknowns※3 で分類
    知らない
    知っている
    (知った)
    知っている
    知らない
    (知らなかった)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼす影響を








    ※3 佐藤ちひろ, Known unknownsとUnknown knowns 「知らないことを知っている」とは?, データのじかん (12 19, 2019)

    View full-size slide

  11. Unknown Unknowns で分類
    知らない
    知っている
    (知った)
    知っている
    知らない
    (知らなかった)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼす影響を








    リリース時には
    認知していた負債

    View full-size slide

  12. Unknown Unknowns で分類
    知らない
    知っている
    (知った)
    知っている
    知らない
    (知らなかった)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼす影響を








    リリース時には
    認知していない負債

    View full-size slide

  13. Unknown Unknowns で分類
    知らない
    知っている
    (知った)
    知っている
    知らない
    (知らなかった)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼす影響を








    及ぼす影響を
    知っている負債

    View full-size slide

  14. Unknown Unknowns で分類
    知らない
    知っている
    (知った)
    知っている
    知らない
    (知らなかった)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼす影響を








    及ぼす影響を
    知らない負債

    View full-size slide

  15. 技術的負債と不確実性
    不確実性が⼩さい = 何が起こるかわかっている
    問題となりそうな技術的負債は 不確実性が⾼そうである
    負債
    影響度を知っている
    影響度を知らない
    リリース時に
    認知している
    リリース時に
    認知していない
    (今はわかる)
    リリース時に
    認知している
    リリース時に
    認知していない
    不確実性 ⼩
    不確実性 ⼤

    View full-size slide

  16. 技術的負債の対処

    View full-size slide

  17. ビジネスを進める上でのリスク
    と私は考えています
    技術的負債の私なりの定義

    View full-size slide

  18. リスクとは
    リスク (Risk)
    - ⽬的に対する不確かさの影響※4
    ※ 影響
    - 期待することからの乖離
    - 現状(AsIs)とあるべき姿(ToBe)からの乖離
    - 好ましいもの、好ましくないもの、もしくは両⽅の場合がありうる
    ※4 ⽥邉 ⼀盛, エンジニアのためのリスクマネジメント⼊⾨ (2 27, 2030)
    技術的負債を保持していること
    =
    ビジネスを進める⽬的において不確実な影響 を保持していること

    View full-size slide

  19. リスクマネジメント (リスクマップ と コントロールパターン) の一例



    発⽣可能性(発⽣頻度)
    リスクコントロール
    保有
    - 固有リスクとして受け⼊れる
    低減
    - 発⽣可能性や影響を下げる
    移転
    - 別の要因に移動させる
    回避
    - 要因を取り除く
    ※左記マッピングは⼀例です
    ※4 ⽥邉 ⼀盛, エンジニアのためのリスクマネジメント⼊⾨ (2 27, 2030)

    View full-size slide

  20. 必ずしも 100%撲滅させる必要はない
    リスクに対する組織(チーム)の許容度を把握しておく
    許容度オーバー 許容度内 リスクほぼなし
    100 or 0 でなく、この状態を目指す

    View full-size slide

  21. リスクを認知している技術的負債の場合

    View full-size slide

  22. すでに発⽣(認知)している技術的負債 (顕在リスク)
    知らない
    知っている
    (知った)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼすリスク を








    課題であること
    何かしらのリスクがあること
    を認知している
    知っている
    知らない
    (知らなかった)

    View full-size slide

  23. ビジネスチケットと並べて、対応するのみ!
    すでに発⽣(認知)している技術的負債 (顕在リスク)の対処
    もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    発⽣可能性 すでに発⽣している
    影響度 顕在化している
    対応⽅針 計画可能 (保有‧低減‧移転‧回避)

    View full-size slide

  24. 課題を認知している技術的負債の場合

    View full-size slide

  25. 課題を認知している技術的負債 (潜在リスク)
    知らない
    知っている
    (知った)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼすリスクを








    課題であること
    を認知している
    リスクがあることを
    知らない(わからない)
    (ないかもしれない)
    知っている
    知らない
    (知らなかった)

    View full-size slide

  26. 課題を認知している技術的負債 (潜在リスク)の対処
    設計する時間がない
    間に合わせの設計
    影響度‧発⽣可能性に応じて、対応⽅針を決める
    仮説であることを知りつつビジネスチケットと並べて対処する
    発⽣可能性 未発⽣ → 想定可能
    影響度 未発⽣ → 想定可能
    対応⽅針 計画可能 (保有‧低減‧移転‧回避)

    View full-size slide

  27. なにもわからない場合

    View full-size slide

  28. 課題‧リスクの存在⾃体が不明なもの
    知らない
    知っている
    (知った)
    設計する時間がない
    間に合わせの設計
    なにそれ? もっとこうすればよかった
    今すぐリリースしないと⾏けない
    あとでなんとかする
    及ぼすリスク を







    を なにもわからない......
    知っている
    知らない
    (知らなかった)

    View full-size slide

  29. なにそれ?
    発⽣可能性 未発⽣ → 想定不可
    影響度 未発⽣ → 想定不可
    対応⽅針 不可
    なにもできない......
    課題‧リスクの存在⾃体が不明なものの対処

    View full-size slide

  30. 技術的負債であることを認知しなければ技術的負債ではないのでは?
    潜在的な技術的負債とは

    View full-size slide

  31. やっかいなのは
    しかし、技術的負債は必要になったときに認知することになる。
    しかも、認知したときにかぎって⼤事になることが多い......

    View full-size slide

  32. 問題になるまで発⾒できなかったときは
    発⾒時は腹を括って対応する (しかない?)

    View full-size slide

  33. 技術的負債はいつ発⽣する?

    View full-size slide

  34. 技術的負債の発⽣
    リリース前は技術的負債なく、リリース後に認知済みの技術的負債が顕在化する
    運⽤中の認知した時点で、技術的負債が浮き上がる
    リリース前 リリース後
    認知済みの負債
    運⽤中
    認知済みの負債
    未認知の負債
    (負債として把握していない)
    未認知の負債
    新たに認知した負債

    View full-size slide

  35. 未認知の技術的負債
    技術的負債
    リリース時に認知していた負債
    リリース時に認知していない負債
    そもそも負債
    だと思っていなかった
    環境変化により
    技術的負債になった
    感度を⾼めてなければそもそも負債だと気付くことができないが、
    環境変化によって(今までベターな選択だったものが)技術的負債に変化するものもある

    View full-size slide

  36. 潜在的な技術的負債を認知する対処
    技術的負債として事前に認知する仕組みを構築する
    そして技術的負債を認知する感度とスピードを上げる

    View full-size slide

  37. 技術的負債を認知する

    View full-size slide

  38. Four Key Metrics
    デプロイ頻度
    - 本番環境へのリリース頻度
    変更のリードタイム
    - commitから本番環境稼働までの所要時間
    サービス復元時間
    - 本番環境での障害から回復するのにかかる時間
    変更障害率
    - デプロイ起因による本番で障害が発⽣した割合
    技術的負債の認知⽅法 (⼀例)
    SPACE
    Satisfaction and well being
    - 開発者が⾃分の仕事、チーム、ツール、⽂化にどれだけ満⾜してい
    るか
    Performance
    - 開発者が書いたコードは、想定されたことを確実に実⾏したか?
    Activity
    - 業務を遂⾏する過程で完了した⾏動やアウトプットの数
    Communication and collaboration
    - メンバーやチームがどのようにコミュニケーションをとり、協⼒し
    合うか
    Efficiency and flow
    - 個⼈であれシステムであれ、中断や遅延を最⼩限に抑えて作業を進
    める、完了する能⼒
    技術的負債の増加 = ビジネスを進める上でのリスクが増⼤ = 開発⽣産性の低下

    View full-size slide

  39. ※注意点
    グッドハートの法則
    測定が⽬標になると、それは適切な測定ではなくなる
    キャンベルの法則
    社会的な意思決定において重要な指標ほど操作されやすい
    開発⽣産性の指標は状態の⾒える化に利⽤し、過度に⽬標値として設定しない!
    まずは、変化に気付くことくらいの気持ちで。

    View full-size slide

  40. まとめ
    認知済みの技術的負債ついて
    ● ビジネスを進める⽬的において不確実な影響 (リスク) として扱う
    ● 影響度 / 課題 が明確な(認知している) 技術的負債 は 通常タスクとして扱うことができる
    ● 対処⽅法は 保有(持ち続ける)‧低減(減らす)‧ 移転(他に移動させる)‧ 回避(発⽣させない) がある
    ○ 保持しつづけると判断することも対処。判断できる情報を集める
    未認知の技術的負債ついて
    ● そもそも負債として意識外だったパターンと 環境変化によって負債になってしまったパターンがある
    ● 認知された(発⾒された) ときには問題として⼤きくなっている場合が多い
    ● 事前にできる限り早く、潜在的な技術的負債として認知する必要がある
    ● 認知するために Four Key Metrics, SPACEといった開発⽣産性の指標の変化 がある
    ● すべてを完璧にする必要がなく、できるものから測定する
    ○ 例えば 仕様に対してプルリクエスト の変更量が多いのでは?みたいな違和感から気付くこともある
    ● 測定すること⾃体を⽬的にしないこと。まずは変化に気付くこと

    View full-size slide

  41. ありがとうございました

    View full-size slide