技術的負債の優先順位付けフレームワークテンプレート

TL; TR: 優先順位付け基準

• コード知識。そのコードにどの程度精通していますか?

• 深刻度。ソフトウェアの機能やパフォーマンスにどの程度影響を与えますか?

• 依存関係と規模。そのコードの部分に依存するコンポーネントはいくつありますか?影響を受けるソフトウェアアーキテクチャの規模。

• 修正コスト。技術的負債の問題を修正するのに何ストーリーポイント必要ですか?

合計スコア = (知識 + 深刻度 + 依存関係) – 3 * コスト

こちらもご覧ください 技術的負債の優先順位付けに関する 5 つのヒント。

• TL; TR: 優先順位付け基準
• 技術的負債とは?
• 技術的負債の例
• 技術的負債の問題
• 技術的負債の優先順位付け基準
  • コード知識
  • 深刻度
  • 依存関係とシステムの規模
  • 修正コスト
• 基準の説明をカスタマイズする
• 技術的負債の評価に適さない基準
  • 使用しないでください:ビジネス価値またはユーザー体験
  • 使用しないでください:発生頻度
  • 使用しないでください:課題の経過時間
• 技術的負債の課題の優先度スコア計算
• 技術的負債のバックログのための課題を収集する
  • ヒント 1. タスクトラッカーに専用セクションを作成する
  • ヒント 2. 一貫したフォーマットを使用する
  • ヒント 3. 明確な説明を提供する
  • ヒント 4:偶発的技術的負債を収集するためにコード変更頻度を使用する
  • ヒント 5:遅延と脆弱性のためにコードを自動スキャンする
• まとめ

技術的負債とは?

技術的負債は、ソフトウェア開発で使用される比喩的な用語で、短期的に実装が簡単なコードが、より堅牢またはスケーラブルなオプションよりも選択された場合に発生する追加の開発作業を説明します。これは、ショートカットを取ったり、長期的な保守性、拡張性、または信頼性のために最適化されていないコードを書いたりすることのコストを指します。

技術的負債の例には、読みにくく理解しにくいスパゲッティコードを書くこと、サポートされなくなった古いライブラリやフレームワークを使用すること、コードやテストを文書化しないこと、定期的なメンテナンスや更新を怠ることなどが含まれます。

技術的負債の例

典型的な技術的負債の課題:

1. 古いまたは非推奨の技術を使用すること:古いまたはサポートされていない技術を使用すると、互換性の問題やセキュリティ脆弱性が発生する可能性があります。

2. コードの品質が低い:読みにくく、理解しにくく、保守しにくいコードは、バグ、生産性の低下、開発時間の増加につながる可能性があります。

3. ドキュメントの欠如:コード、プロセス、要件を文書化しないと、将来の開発者がソフトウェアを理解することが困難になり、開発時間の増加とコストの上昇につながります。

4. テストの不足:テストをスキップまたは延期すると、検出されないバグ、セキュリティ脆弱性、ユーザーの不満が発生する可能性があります。

5. アーキテクチャ設計の欠陥:最適ではないアーキテクチャでソフトウェアを設計したり、スケーラビリティの計画を立てなかったりすると、ソフトウェアがより複雑になり、時間の経過とともに保守が困難になるにつれて、技術的負債につながる可能性があります。

技術的負債とは見なされないものの例:

1. プロジェクトにとって重要ではない、または後で完了できる作業を意図的に延期すること。

2. 期限を守るため、またはプロトタイプを迅速に提供するために、ショートカットを取るという情報に基づいた決定を下すこと。

3. プロジェクトの目標に対してまだ許容できる最適ではないソリューションを実装することを意図的に選択すること。

4. 時間、コスト、ビジネス要件などの他の要因とのトレードオフに基づいて、潜在的な制限があることを知っていても、特定の技術またはツールを使用することを決定すること。

5. ソフトウェアを大幅に改善しない日常的なメンテナンスタスクを実行すること。

技術的負債の問題

技術的負債の主な問題は、時間の経過とともに蓄積し、新機能の追加、バグの修正、またはコードベースの保守を困難にする可能性があることです。

• 機能の開発に時間がかかる

• より多くのバグ

コードの改善と新機能の追加の間には常にトレードオフがあります。

技術的負債の優先順位付け基準

これらの基準を考慮することで、タスクトラッカーの課題における技術的負債を特定して対処し、ビジネス価値を最大化し、リスクを最小化するのに役立つ優先順位付けシステムを作成できます。

チームによる理解を深めるために、基準の名前と説明を自由に追加、変更、または書き直してください。

各基準について、ストーリーポイント見積もりに最も適した Fibonacci Sequence 評価スケールを使用しています。

hi.ducalis.io ボードと技術的負債の優先順位付け基準

コード知識

これは、開発チームが作業しているコードベースに対する理解と精通度です。コードを理解してナビゲートする能力、およびコード構造、デザインパターン、プロジェクトで使用されているベストプラクティスの理解が含まれます。

コード知識は開発チームにとって重要です。なぜなら、高品質なコードを効率的に作成および保守する能力に直接影響を与えるからです。コード知識が豊富なチームは、より迅速かつ正確に作業できます。

つまり、コード知識は開発チームのスキルセットの重要な要素であり、作業の品質と効率に直接影響を与えます。

• 1:作成者。そのコードを書いた—保守して説明できる。

• 2:保守担当者。そのコードで作業した—どのように機能するかについて質問はない。

• 3:到達可能。チームメイトに尋ねて、それについてのドキュメントを読むことができる。

• 5:文書化されている。作業していない。それについてのドキュメントがある。

• 8:理解可能。作業していないが、大きな努力なしにどのように機能するかを学んだ。

• 13:困難。どのように機能するかを理解するのにかなりの時間が必要。そのコードで作業していないが、作業した人に連絡するか、ドキュメントを見つけることができる。

• 21:聞いたことがない。チームの誰もそのコードを知らない、またはすぐに退職する。

深刻度

影響の深刻度:技術的負債の課題がソフトウェアの機能やパフォーマンスにどの程度影響を与えるかを判断します。影響の深刻度は高、中、または低であり、これは優先順位付けの基準として使用できます。

• 1:影響なし。

• 2:表面的:一部のローカルコンポーネントに浅い影響。リソースと時間が利用可能になったときに将来対処できる。

• 3:軽微:うまく機能しているが、改善できる。リソースと時間が利用可能になったときに将来対処できる。

• 5:ビルダー:生産性を遅らせ、コードの保守性を低下させるか、新機能の追加を妨げる。リソースが許せば後で対処できる。後で対処できる。

• 8:ブロッカー。ソフトウェアの 1 つのコンポーネントに対するさらなる拡張や更新をブロックする。重大な問題が発生するのを防ぐために、すぐに対処する必要がある。

• 13:重大。複数のソフトウェアコンポーネントをブロックし、ほぼ破壊する。プロジェクトに追加のリスクや遅延を引き起こす。

• 21:破壊的。ソフトウェアを使用不可能にするか、解決されないままにしておくと高いリスクを引き起こす。

依存関係とシステムの規模

そのコードの部分に依存するコンポーネントはいくつありますか?影響を受けるソフトウェアアーキテクチャの規模:

• 1:些細。いつでも返済できるため、無視できる。

• 2:軽微なローカル。単一のメソッド、クラス、または関数に自己完結している。SOLID 原則に違反する可能性がある—ソフトウェアの全体的な品質に重大な影響はない。

• 3:中程度のローカル:複数のメソッド、クラス、または関数に影響を与える。意図しない結果を引き起こすことなく変更することがより困難な場合もある。

• 5:グローバル。単一のアプリケーションまたはサービスに自己完結しているが、より広範なシステムのサブシステム全体に広がり、一見無関係な領域に広がる SOLID 違反を含む。抽象化レイヤー間の不一致、統合ポイントの問題、および強い結合を含む場合もある。この負債はアプリケーションまたはサービスの消費者に影響を与えませんが、サービス自体を変更するときに感じられる。

• 8:重大なグローバル。ソフトウェアの品質に対するより重大で広範な影響。複数のサブシステムを含み、アプリケーションまたはサービス全体に影響を与える可能性がある。意図しない結果を引き起こすことなく変更することがより困難な場合もある。

• 13:システム全体。複数のアプリケーション、インフラストラクチャ、またはチームにまたがる。データストアを共有する多数のサービス、異なる境界づけられたコンテキスト間の高い結合、および技術実装とビジネスロジック間の著しい不一致を含む。システム全体の負債は長期的には維持できず、即座の注意が必要。

• 21:クリティカル。ソフトウェアの全体的な品質に重大なリスクをもたらし、システムの安定性と信頼性に影響を与える可能性がある。

修正コスト

技術的負債の課題を修正するのに何ストーリーポイント必要ですか?

• 1:労力なし

• 2:低コスト:スプリント期間の 10%。

• 3:中程度:スプリント期間の 20%。

• 5:重大:ハーフスプリント

• 8:高:1 スプリント

• 13:非常に高い:1 スプリント以上、2 スプリント未満。複数の課題に分割することを推奨。

• 21:法外に高価。今のところどのように処理するかわからない。2 スプリント以上。

基準の説明をカスタマイズする

最良の基準の説明は、チームメートが理解しやすいものであることを忘れないでください。より具体的な基準とスケールの説明があればあるほど、優先順位付けプロセスにとって良いです。スプリント期間、依存関係の説明、ブロッカーの定義、およびコード知識の意味を指定してください。基準の説明の編集について詳しく読む。

基準の説明をカスタマイズする

技術的負債の評価に適さない基準

ビジネス価値、発生頻度、経過時間、およびユーザー体験への影響は、技術的負債を評価するための信頼できない基準です。

使用しないでください:ビジネス価値またはユーザー体験

コード品質、ドキュメント、テストカバレッジ、ソフトウェアアーキテクチャなどの要因は、収益などのビジネスメトリクスと直接相関することはめったにありません。これらの要因は、開発チームが効率的に変更を加える能力と、ソフトウェアの全体的な品質、信頼性、およびスケーラビリティに影響を与えます。

技術的負債を維持しない最も一般的な理由の 1 つは、潜在的な収益でそれを評価することです。

使用しないでください:発生頻度

将来、技術的負債の課題が再び発生する可能性を考慮してください。技術的負債は、再び発生する可能性のあるバグではありません。将来を予測することに時間を無駄にしないでください。

使用しないでください:課題の経過時間

古いライブラリを早くリファクタリングするのは明白で簡単なアイデアのように感じるかもしれません。しかし、コードがうまく機能し、遅延や脆弱性を引き起こさない場合、なぜ時間を費やす必要があるのでしょうか?経過時間は優先順位付けの基準であるべきではありません。

技術的負債の課題の優先度スコア計算

通常、技術的負債の最優先課題を設定するための適切な戦略のために、基準の重みをバランスさせる必要があります。デフォルトでは、重み -2 があります。チームの開発リソースが少ないほど、重みはより負である必要があります。

「コスト」基準の重み設定

最終的な式は非常にシンプルです:

技術的負債のバックログのための課題を収集する

「Essential Scrum: A Practical Guide to the Most Popular Agile Process」で、著者の Ken Ruben は技術的負債を定義するために 3 つのカテゴリを使用しています:偶発的、既知、およびターゲット技術的負債。

• 偶発的技術的負債は、日常的な製品の使用またはメンテナンス中に公開されるまで、開発チームが存在を知らなかった技術的負債です。たとえば、ソフトウェアに新機能を追加している間、チームは何年も前にコードに追加され、変更されないままにされた回避策を発見し、予期しない動作を引き起こす可能性があります。偶発的技術的負債は、時間の経過とともにコードが劣化し、その機能と使いやすさが変化する「ビット腐敗」によっても引き起こされる可能性があります。

• 一方、既知の技術的負債は、開発チームがすでに認識しており、ソフトウェアで見ることができる技術的負債です。既知の技術的負債の例には、コード品質の低さ、ドキュメントの欠如、またはテストの不足が含まれます。

• 最後に、ターゲット技術的負債は、開発チームが特定のスプリントまたはリリースで対処することを選択した既知の技術的負債です。これには、技術的負債を削減し、ソフトウェアの品質を向上させるために、コードの改良、ドキュメントの改善、またはテストカバレッジの増加が含まれる場合があります。

技術的負債のさまざまなタイプを理解することで、開発チームは努力に優先順位を付け、ソフトウェアの長期的な保守性と信頼性への影響を最小限に抑えるために技術的負債に対処するように働くことができます。

ヒント 1. タスクトラッカーに専用セクションを作成する

バグや機能などの他の課題から技術的負債の課題を分離するプロパティを持つことが重要です。特別なタグ/ラベル、課題タイプ、またはコンポーネントを使用してください。すべての課題を含む完全なバックログを常に確認し、タイプでフィルタリングするオプションが必要です。

ヒント 2. 一貫したフォーマットを使用する

バックログツールのユーザーストーリーやタスクなど、技術的負債の課題をログに記録するための一貫したフォーマットを使用してください。これにより、技術的負債の課題を簡単に特定して優先順位を付けることができます。

ヒント 3. 明確な説明を提供する

コードベースへの影響、修正に必要な推定労力、および潜在的なリスクまたは結果を含む、技術的負債の課題の明確な説明を提供してください。

ヒント 4:偶発的技術的負債を収集するためにコード変更頻度を使用する

コード変更頻度は、ソフトウェアシステムのコードベースに変更が加えられる頻度です。

これは、ソフトウェアプロジェクトの健全性と品質を評価し、潜在的な問題とリスクを特定するために使用できます。影響の評価、高リスク領域の特定、およびコードベースの変更に関する情報に基づいた決定を行うことができます。

• 頻繁な更新、改善、不安定性、またはエラーを示す可能性のある高い頻度。

• メンテナンスまたは進化の欠如を示す可能性があり、技術的負債やその他の問題につながる低い頻度。

このアイデアについての Adam Tornhill のトークを視聴することを強くお勧めします、「

」。

ヒント 5:遅延と脆弱性のためにコードを自動スキャンする

コード分析のための多くのツールがあります。試してみて、見つかった課題をタスクトラッカーのバックログにプッシュしてください。

1. Code Scene — コード、知識、およびその背後にいる人々に関してソフトウェアを視覚化、理解、改善するための 1 つのツール。自動化され、優先順位付けされ、実行可能な推奨事項に基づいて改善を行います。

2. SonarQube:コードのセキュリティ脆弱性、コードの臭い、およびその他の問題を検出できる一般的なツール。さまざまなプログラミング言語をサポートし、さまざまな CI/CD ツールと統合します。

3. OWASP ZAP:SQL インジェクション、クロスサイトスクリプティング、およびその他のセキュリティ問題などの脆弱性を検出できるオープンソースの Web アプリケーションセキュリティスキャナー。

4. CodeClimate:コードを分析し、その品質、保守性、およびセキュリティに関する洞察を提供するクラウドベースのプラットフォーム。さまざまなプログラミング言語をサポートし、GitHub、Bitbucket、およびその他のツールと統合します。

5. Snyk:コードと依存関係をセキュリティ脆弱性についてスキャンし、修復アドバイスを提供するクラウドベースのツール。さまざまなプログラミング言語をサポートし、さまざまな CI/CD ツールと統合します。

6. AppDynamics:応答時間、エラー率、およびその他のメトリクスを含む、アプリケーションのパフォーマンスに関するリアルタイムの洞察を提供するツール。パフォーマンスのボトルネックを特定し、コードを最適化するのに役立ちます。

7. Qodana。所有、契約、または購入するコードの整合性を評価します。JetBrains IDE から愛用しているすべてのスマート機能で CI/CD パイプラインを強化します。

まとめ

技術的負債はソフトウェア開発において避けられませんが、進歩とイノベーションにとって重大な障害にもなり得ます。チームに適した技術的負債の優先順位付けシステムを開発することで、その影響を最小限に抑え、時間の経過とともにソフトウェアの品質と信頼性を維持できます。

技術的負債は開発者だけの問題ではないことを忘れないでください。組織全体に影響を与えます。技術的負債管理をプロジェクト管理プロセスに組み込むことで、全員がその影響を認識し、それに対処するために協力していることを保証できます。

最後に、技術的負債への対処は 1 回限りのイベントではないことを覚えておくことが重要です。継続的な注意と努力が必要です。技術的負債のバックログを定期的に確認して更新することで、潜在的な問題を把握し、長期的にソフトウェアが健全で信頼できる状態を維持できます。

次を読む:技術的負債の優先順位付けに関する 5 つのヒント