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

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

技術的負債とは？

技術的負債とは？ ウォード‧カニンガムさんの⽂脈 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) 初めてコードを出荷するということは、借⾦をするようなものだ。少しの借⾦は、書き 直しで速やかに返済される限り、開発を加速させる。オブジェクトはこの取引にかかる コストを許容範囲にしてくれる。危険なのは、借⾦が返済されない場合だ。適切でない コードに費やされた時間はすべて、借⾦の利息としてカウントされる。オブジェクト指 向であろうとなかろうと、統合されていない実装の負債によって、エンジニアリング組 織全体が⽴ち⾏かなくなる可能性がある。

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

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

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

技術的負債の分類

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

Unknown Unknowns※3 で分類 知らない 知っている (知った) 知っている 知らない (知らなかった) 設計する時間がない 間に合わせの設計 なにそれ？ もっとこうすればよかった 今すぐリリースしないと⾏けない あとでなんとかする 及ぼす影響を 負 債 で あ る こ と を ※3 佐藤ちひろ, Known unknownsとUnknown knowns 「知らないことを知っている」とは？, データのじかん (12 19, 2019)

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

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

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

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

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

技術的負債の対処

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

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

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

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

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

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

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

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

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

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

なにもわからない場合

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

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

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

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

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

技術的負債はいつ発⽣する？

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

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

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

技術的負債を認知する

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

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

まとめ

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

ありがとうございました