技術的負債の6つのタイプ：技術的負債は重荷ではなく、成功のための戦略的手段

• 技術的負債を戦略的手段として捉えるために必要なこと
  • 技術的負債に対する否定的な前提を認識し、解消する
  • 技術的負債の6つのタイプを分類し、それぞれに異なる対応をする
  • 技術的負債の規模を把握する
  • 技術的負債の優先順位を決める方法

How to Not Manage Tech Debt

• 技術的負債を誤って管理してしまう4つの前提

前提 #1 : 技術的負債 = 悪いもの

• すべての技術的負債を「悪いもの」と分類してはならない
• それぞれに名前を付け、痛みの大きさを測って技術的負債を分類するほうがはるかに良い
• 持っていたほうがよい技術的負債もあり、すべてのチームは技術的負債を持つべきである
• 「良い技術的負債を持っていた」Twitterの事例：公開ストレージを使った後、自前の分散DBであるManhattanを開発
• 「技術的負債 = 悪いもの」という前提に対応するための質問
  • 今この技術的負債を積み、来月解消したら何が得られるか？
  • どのような状況なら経営陣はこの技術的負債に関心を持つか？ CTOが経営陣にピッチする際に役立つ情報をどう伝えるべきか？
  • このイニシアチブは会社のより大きなビジョンや戦略的方向性にどうつながるか？

前提 #2 : すべての技術的負債 = 複雑な作業

• 技術的負債に限らず、あらゆる難しい作業と同じく、複雑な仕事を処理するにはさまざまな方法がある
• 特に技術的負債では、Defined/Undefined（定義済み/未定義）の作業にアプローチする方法がある
  • Defined = 作業に始まりと終わりがある
  • Undefined = 作業の始まりはあるが、終わりが明確ではない
• 技術的負債 = 複雑という前提に対応するには
  • 目の前の技術的負債がDefinedなのかUndefinedなのかを明確にすること
    • Definedの場合は、作業完了までの見積もり時間を理解し、少しバッファ時間を持たせる
    • Undefinedの場合は、なぜ仕事が複雑で明確な終了日がないのかを理解できるよう、不明瞭な部分を列挙して利害関係者に共有し、前進するための最善の方法について意見を求める
  • Undefinedな技術的負債を消化しやすい作業単位に分け、複雑さを下げる
    • 複雑で大規模な作業を、複雑ではあっても実行可能な小さな作業へと変換すると、チームはスプリント/四半期ごとの限られた期間の中で技術的負債の一部を解消することに、より動機づけられる
• 「技術的負債 = 複雑な作業」という前提に対応するための質問
  • システムについてどのような誤った前提があるか？
  • この分野の経験者や詳しい人を招くなら、必ず聞くべき質問は何か？
  • この作業を遂行するために必要な適切な人員と知識がチームにあるか？ ないなら、情報の再配置をどう考えるべきか、そしてこの問題を解決するのに最も適した時期はいつか？
  • この技術的負債の複雑さをまったく理解していない人に説明する最善の方法は何か？

前提 #3 : 技術的負債 ≠ プロダクト作業

• 組織は、プロダクト作業がどう会社のメトリクスを改善するかについては明確である
• しかし通常、そこに技術的負債についての説明は欠けている
• 技術的負債を適時に解消することは、たとえ即座に定量化できなくても、会社の成長を促進するうえで重要になりうる
• 技術的負債 ≠ プロダクト作業という前提に対応するには
  • 技術的負債の特定領域がメトリクスと直接結びついていなくても、どのようなユーザー体験/プロダクト体験の改善に役立つかを広く考えること
  • 技術的な利点だけでなく、ユーザーとプロダクトにもたらす利点を同等に強調すると、なぜチームがこの作業を重視すべきなのかを他者に理解してもらいやすい
  • ビジネスリードと技術リードが同じ認識を持っているか(on the same page)を確認する時間を取ること
• 「技術的負債 ≠ プロダクト作業」という前提に対応するための質問
  • 今この作業を進めるべき最も重要な理由は何か？
  • この仕事のインパクトを理解すべき人は誰か？ なぜその人たちはこれに関心を持つべきなのか？
  • 自分が伝えたいことは何か？ それは利害関係者が聞きたい内容と一致しているか？ もし一致していないなら、どうすれば彼らの問題を解決できるか？
  • 自分またはチームにとって、妥当な結果と素晴らしい結果の違いは何か？
  • 期待される結果を過剰に約束していないか？ 結果について「素晴らしい」と「良い」に分けて期待値を調整できるか？

前提 #4 : 個人の痛み = 組織の痛み

• 技術的負債に近いエンジニアは、技術的負債を扱うことが個人的に苦痛だと繰り返し語ることが多い
• 当人は世界の終わりのように感じるかもしれないが、組織のほかの人々は同じ痛みを感じていない
• これはキャリア初期の人によく見られ、通常はより広い戦略的コンテキストの欠如から生じる
• 個人の痛み = 組織の痛みという前提に対応するには
  • 技術的負債の中で優先度の高い領域に触れたら、それが個人レベルのペインポイントなのか、組織レベルのペインポイントなのかを立ち止まって見極めること
    一般的に、組織レベルの問題は何らかの形で顧客やビジネスに直接影響する
  • 自分よりも多くの組織的コンテキストを持つ人の視点で考えてみること。他チームの誰かに説明してみるのもよい
• 「個人の痛み = 組織の痛み」という前提に対応するための質問
  • この技術的負債を分類し解消することで、どれだけ多くのチームが利益を得るか？
  • 会社が技術的負債の作業を担った人を認識または報酬したのはいつか？ それはどのタイプの技術的負債で、その当時なぜ必要だったのか？ その人がその作業をどう位置づけたのかについて話せるか？
  • 自分のエンジニアリングマネージャーは技術的負債作業の価値を理解しているか？ 彼/彼女はパフォーマンスレビューの際にこの作業への自分の貢献を擁護してくれるか？

技術的負債の6つのタイプ

• Maintenance debt（保守負債）
  • チームが技術のアップデートに追いつけないとき
  • 実験開始 / 機能ロールアウト / デプロイ取り消しなどの後にデッドコードを削除しないことや、ライブラリ更新、コンテキストコードへのコメント付与、実装判断の文書化を更新しないことも含まれる
  • 例) log in with Spotify 機能を実験したあと中止したが、該当コードを削除しなかった
• Developer efficiency debt（開発者効率性負債）
  • 会社にプロダクト向けの適切なテスト、監視、アラートシステムがない場合
  • エンジニアリングのワークフローが非常に非効率で、デプロイ/ビルドに何時間も何日もかかり、開発者が本番投入前に技術的問題を検知できないという、典型的なタイプの負債
  • 例) 組織が1年間で15人から50人に増加し、あまりにも多くの実験が進行。プロダクションで見つかったバグ修正リリースが2〜3件分滞留し、購入体験のための新しいテストはさらに後回しになっている
• Stability debt（安定性負債）
  • 組織にさまざまなタイプの技術的負債が蓄積し、インフラの安定性に影響を与えるとき
  • オンコールを事前に管理するのではなく、問題発生時に該当の専門家を事後的に呼び出したり、チーム全体がオンコールになったりするシナリオが発生する
  • これはエンジニアやオンコールローテーションチームには大きな悩みの種だが、会社のほかの人々にとっては、問題を把握して説明すること自体が難しい
  • 安定性負債はプロダクトの信頼性にも影響し、顧客が直面する問題を引き起こすこともある
  • 例) モバイルチームにはiOS開発者が多く、AndroidアプリよりiOSを優先。その結果、Androidアプリにはビジネス上重要なフローに関するプロダクトガイドラインが不足し、サードパーティが初期に開発した脆弱な Kryptonite コードも残っている。これによりAndroidユーザーが旧機能にアクセスした際にクラッシュが発生し、Google Playの評価が悪化した
• Security debt（セキュリティ負債）
  • ブルートフォース攻撃、データ漏えいなどのセキュリティ脆弱性がある技術スタックを使用している場合
  • 起こりうること（または起こらないこと）を計画・評価するのは難しいため、多くの組織でセキュリティ負債が発生する
  • 例) 会社内部のプロセス上の問題でアップデートが間に合わず、既知の脆弱性にパッチを当てられなかったことで、顧客の個人データが漏えい（小規模企業から、1億4,000万人に影響したEquifaxのような企業まで）
• Technical product debt（技術的プロダクト負債）
  • プロダクトへの悪影響が目に見えて現れるとき
  • 最も見つけやすく、解消しやすい負債であり、ユーザーにも影響があり、組織内のすべてのチームが売上/収益への影響を認識できる
  • 例) ユーザーがプロダクト内で特定の作業を行うのに数秒かかる。これはさまざまな負債によって生じうるが、ユーザーの中核的なプロダクト体験に影響する
• Decision debt（意思決定負債）
  • 以前の技術的意思決定がX%間違っていた、あるいはスコープ・時間・リソースの面でトレードオフした結果、その意思決定のコストを支払っている状態
  • 技術的負債の最も一般的な形態
  • 例) Webサイトで特定の実験のためにサードパーティを使用。数年の間に大きく成長し、今では数百万人のユーザーが訪問している。その結果、技術チーム、データチーム、プロダクトチームのすべてが、複雑な実験を行うたびに苦労している。
    これは、チームがサードパーティと自社開発のどちらにするかでトレードオフの意思決定をしたために生じた意思決定負債である。当時は正しい判断だったかもしれないが、いまは影響が表れている

技術的負債の規模を決める : Acute vs Systemic

• 技術的負債の種類を理解したら、得られるものと比較できるようコスト規模を決める必要がある
• チームが「技術的負債に取り組む時間はいつ取れるのか？」と尋ねたとき、それが時間・思考・労力の観点で小さいのか大きいのかを判断するのは難しい
• Acute（急性）な技術的負債
  • 比較的小さな技術的負債
  • 例) 新機能提供のため、利用規模が小さいプラットフォーム/ブラウザ向けの作業をスキップした。他に作業がなければ1日以内に容易に追加可能
• Systemic（構造的）な技術的負債
  • 大規模から巨大規模の技術的負債
  • 例) CTO/創業者が5年前にプロダクト（間接的には技術）に関する意思決定を行い、それを前提に努力を積み重ねてきた。これを変えるとさまざまなものに影響が及ぶ。
    この技術的負債は簡単には解消できず、変更には数か月から数年かかることがある

戦略的に技術的負債の優先順位を付ける

• 柔軟に検討・評価する方法
  • Confidence : これが重大な問題につながる可能性は高いか？ 低い/高い
  • Time : これはいつ問題になるか？ 緊急ではない/緊急
  • Impact to User : これをやらないと、ユーザー体験を損なう速度/品質の問題が発生するか？ 低い/高い
  • Sequence : これは重要なマイルストーン到達の妨げになるか？ 小さな影響/ブロッカー
  • Accumulated debt : すでにどれだけの負債を蓄積することを選んできたか？ 少ない/多い

会社の成長段階に応じた戦略的技術的負債ポートフォリオ

• Traction :
  • Product-Market fit以前
  • 正確性・安定性・プロセスよりも速度を優先したエンジニアリング判断が必要。大規模な開発者効率性負債
  • 一般的には、Django、Rails、PHP などのフルスタックフレームワークを選び、素早く開発することを意味する
• Inflection :
  • PMFの兆候があり、プロダクトがスケーラブルなループへ移行する時点
  • チームは一部のプロセスが必要だと気づき（開発者効率性負債が解消され始める）、まだ内部プロセスとユーザー体験のバランスを取っているため、技術的プロダクト負債が増加する
• Scale :
  • 企業のハイパーグロース期
  • 内部のプラクティスやプロセスとユーザー体験のバランスを取りながら、技術的プロダクト負債と開発者効率性負債は減少し、安定し始める
  • 非常に急速な成長の結果として、セキュリティ負債、保守負債、意思決定負債が増加する
  • テスト自動化、デプロイシステム、監視とアラート、ロギングとインストルメンテーション、テストとステージング、ETL などに多くの変更と修正が起こる
• Expansion :
  • Saturationの始まり。ビジネスがより成熟する
  • 大量の古いコードと意思決定により、保守負債と意思決定負債が引き続き増える
  • チームが成長のための新たな機会を模索する中で、開発者効率性負債が再び増え始める
  • 技術的プロダクト負債、セキュリティ負債、安定性負債は、前の期間以降バランスが取れてきている

技術的負債ポートフォリオ管理のためのヒント

• 生み出される技術的負債を減らすためのプロセス
  • 技術的負債を蓄積することは戦略的である一方、初期からプロセスを実装して技術的負債が生まれないようにしたほうがよい場合もある
  • エンジニアが増えるにつれて開発者効率性負債が減るべきInflectionおよびScale段階では、特にそうである
  • 開発者効率性負債が減ると、その代わりに意思決定負債や保守負債が増える可能性がある
  • こうしたプロセスの例 : コード/PRレビュー、監視標準、QA承認、技術/設計レビュー
• 特定タイプの負債形成を防ぐツール
  • 基本的なツールに投資すれば、一部のタイプの負債が形成されないようにできる
  • Scale段階では、セキュリティ問題（セキュリティ負債）、ユーザー体験に影響するバグの防止（技術的プロダクト負債）、コードの一貫性（開発者効率性負債）のために特に重要
  • こうしたツールの例 : Linter と CI/CD パイプライン
• Reactive & Acute な技術的負債のためのスプリント作業
  • 組織がオンコールを必要とする規模に達したら、オンコールスプリントは現在の火消し、または技術的負債に関連する対応作業に使うべきである
  • これによって組織は緊急度の高い技術的負債項目を処理でき、オンコールチームを通じて現在/過去の問題に実際の対処を行える
  • 対応作業のためにオンコールを可能にすることは、成長のScale/Expansion段階で特に重要である。緊急の技術的負債を処理することで、ほかのチームが新機能/新製品を作りつつ、追加負債にも対処できるようになるためだ
• 能動的で構造的な技術的負債のためのロードマップ作業
  • 技術的負債をロードマップに入れるには、多くのチーム間の足並み合わせが必要
  • 技術的負債をロードマップに入れる例 : 大規模なリライト、顧客が主に使用する機能のデータシステム再調整、主要経路に対するアラートの定義と実装、決済システムの切り替えなど

技術的負債を重荷から戦略的手段へ転換する方法

• 蓄積された技術的負債を通じて、チームはどのイニシアチブを実行するかについて全体的な戦略判断を下せる
• チームが経験しうる一般的な技術的負債に関する前提を考えてみること。「技術的負債 = 悪いもの」や「技術的負債 ≠ プロダクト作業」に反対できているか？ 「個人の痛み = 組織の痛み」と考える同僚の話を聞いていないか？
• 「技術的負債」という包括的な用語を使わないこと。保守負債、開発者効率性負債、安定性負債、セキュリティ負債、技術的プロダクト負債、意思決定負債と名付ける
• 曖昧さを減らすために技術的負債の規模を決める。AcuteかSystemicか？
• 会社のほかの領域と比較しながら、戦略的に技術的負債の優先順位を付ける。確信度、時間、ユーザーへの影響などのベクトルに基づいて優先順位付けを行う
• 会社の成長に伴う変化と要件に合わせて、技術的負債ポートフォリオを進化させ、バランスを維持する

[roxie]

最も基本的で重要なことは、それが「これがあなたの痛みです」と明確に伝えることだと思います。数字であれ何であれ。

それができないのなら、実際のところ、もしかすると、それは技術的負債ではなかったという結論にも至りうる気がします。