問題の歴史:
当初、ITチームは常に技術的負債に注意を払わず、最小限の作業可能なソリューションのリリースに焦点を当てていました。しかし、負荷の増加とシステムの変更が増えるにつれて、開発の持続可能性を確保するために、技術的負債の形式化と記録の必要性が生じました。
問題:
技術的負債は、新しい機能の迅速な開発を妨げます。未発見または管理されていない負債は、サポートコストの増加、"パッチ"ソリューションの出現、アーキテクチャの複雑化を引き起こします。重要なのは、システムアナリストが新しい要件の分析時に既存の負債をどのように考慮し、記録できるかです。
解決策:
システムアナリストは以下を行う必要があります：
主な特徴：
技術的負債は見つかり次第すぐに修正する必要がありますか？
必ずしもそうではありません。ビジネスへの影響と技術的リスクに基づいて優先順位を評価する必要があります。時には、負債の解消はより適した段階まで延期されることもあります。
システムアナリストは、開発チームとの対話なしに技術的負債について単独で決定を下すことができますか？
いいえ、アナリストは負債を記録し文書化しますが、解消方法と期限についての決定はアーキテクトとチームと協力して行います。
新しい変更の承認を早めるために、技術的負債の一部を文書に隠すべきですか？
いいえ、完全で最新の負債と制限のレジストリが必要です。これは、製品とチームを将来のサプライズから守ります。
ネガティブケース: アナリストは、システムの古いモジュールを無視し、古いコードの上に新機能を実装しました。後に改良が必要になり、高すぎる技術的負債のために実現が問題になりました。 長所:
ポジティブケース: アナリストは"ボトルネック"の技術的説明を用意し、リファクタリング計画を承認し、負債を最小化してから新しいモジュールを実装しました。 長所: