「技術的負債」は 、Ward Cunningham が、望ましい結果に合わせてソフトウェアを作り直すとチームの速度が低下することを説明しました。 それはローンに利息を支払うようなものです。 それは欺瞞的な概念である可能性があります。 「今のところ大丈夫」という考えは、速度、品質、価値、士気に影響を与える可能性があります。 結局、技術的負債は扱いにくいものになる可能性があります。 あなたがそれを支払わなければならないまであなたはそれがいくらかかるかわかりません。
技術的負債は、金融負債の影響を反映しています
技術的負債は、金融負債とよく似ています。 私たちはさまざまな理由(計算されたもの、危険なもの)でそれを使用し、利息を支払うことを理解しています。 Code Complete の著者である Steve McConnellは、利子が技術的負債を定義すると指摘しています。
長期的には、不十分なコーディングプラクティス、不十分なテスト、不明確な要件などのリスクを冒すことを無視することはできません。 チームがリスクを受け入れて前進するとすぐに、目に見えるかどうかにかかわらず、システムと製品への悪影響が始まります。
ある時点で、あなたはそれに対処する必要があります。 ただし、問題への対処は通常、より複雑で費用がかかります。 それは、最初にリスクを負ってからのシステムの変更と進化に依存します。
これが興味です。 時間の経過とともに複合し、速度を遅くします。
限られたケースでは、技術的負債を計算された方法で使用できます。
- 短期的なスピードを得る(リリース前または市場ウィンドウにぶつかる)。
- 短期的なリソース(スタートアップ資本、助成金など)を拡張します。
- 技術的負債がすぐに無関係になるときにリソースを浪費しないようにします(寿命が近づいているシステムのサービス)。
上記の戦略的な例では、計算の一部には、受け入れられた債務を遅かれ早かれ返済するための計画と予算を含める必要があります。
上記の例外とは別に、よりリスクの高い技術的負債の蓄積行動は、以下から生じる可能性があります。
- 短期的な焦点の傾向(「このリリース/修正/機能を出すだけ」)。
- 何かを正しく行いたくない(例えば、貧弱なコーディング技術やコーディング標準の欠如、退屈な、または気まぐれに見えるためにユニットまたは他の種類のテストをスキップするなど)。
- 必要なプラクティスをサポートするインフラストラクチャの欠如(継続的インテグレーションシステム、頻繁または退屈なタスクの自動化など)
- 不十分な知識やプラクティス(例:テストを自動化していない、チームが互いに学習していない、コードライターとテスターがサイロで運用しているなど)
- 作業は、新しい価値のある機能に直接関連していません。
- 開発者は、技術的な品質への影響を考慮しない期限を課しました。
意図的な理由で技術的に発生したとしても、それはそれが支払われる必要がないという意味ではありません。 金融負債のような技術的負債を返済しないということは、時間の経過とともに増加することを意味します。
速度への影響
クレジットカードの借金を最大にした場合、可処分所得は利息にのみ向けられ、新規購入は禁止されます。 技術的負債でも同じ点に到達できますが、現在の機能を維持するにはすべての容量が必要です。 したがって、革新して付加価値を提供する能力を制限します。
たとえば、電卓アプリを構築しているとします。 価値の提供とリスク(負債)の蓄積の次の進行を検討してください。
- スプリント 1: 基本 GUI:番号を入力すると、ディスプレイに表示されます。 それはとても単純なプログラムです。そのための自動テストを作成しないことにしました。
- スプリント 2: 追加機能を実装します。 それはうまく機能しますが、手動でテストするのは簡単です。 加算のテストは、テスト番号の入力としてもカウントされます。
- スプリント 3: 減算は、加算と同じくらい簡単にテストできます。 ただし、品質を高く保つには、減算と加算の両方を手動でテストする必要があります。
- スプリント4: 掛け算。 繰り返しになりますが、この機能は素晴らしく機能しますが、テスターは欲求不満に達します。 乗算、減算、加算をテストする必要があります。
- スプリント 5: 除法。 手動テストには、以前のスプリントでテストされた 3 つを含む 4 つの機能のテストが含まれるようになります。 彼女はなんとか余分な時間働くことができますが、すべてを成し遂げます。 彼女は今、これらの手動テストスクリプトを実行するのが得意ですが、週末の一部を失いました。
- スプリント6: 小数。 テスターは、スプリントには大きすぎると言います。 チームの他のメンバーは、他の機能よりも労力が大きくないように見えると言います。 テスターは、すべて(スプリント全体の作業価値があり、もう少し)と新機能を再テストする必要があると指摘しています。 6 単位のテスト (GUI、加算、減算、乗算、除算、小数) の代わりに、10 単位 (小数点の有無にかかわらず、前の 5 つのスプリントに相当する機能) を使用します。 現在の品質を維持するために、速度が遅くなります。
開発チームが技術的負債を管理し、以前に自動化を使用した場合、以前の機能の新しいテストに関するテスト担当者のポイントは引き続き有効です。
ただし、既存の 自動 テストでは、すでに作業の半分をカバーしています。 自動化により、テスト担当者は、スプリントの終わりに向かってすべてのテストを行う代わりに、チームが小数機能を実装したときにテストの作成を開始できます。
品質の低下
技術的負債は、長期的なものを犠牲にして、より簡単な短期的なソリューションを採用するための選択です。 この決定は、品質保証と管理に常に影響を与えます。
- 品質保証:製品はビジネス/顧客のニーズを満たしていますか?
- 品質管理:製品は高い技術的品質を持っていますか?
どちらの場合も、結果は顧客の失望と後で無駄なやり直しになります。
提供される価値が少ない
品質の低下は、顧客から報告された欠陥や消防の増加につながります。 製品所有者の予測には、ますます価値の低い機能が含まれています。 開発チームはまだ同じように一生懸命働いていますが、もはや無視できない未払債務のために、新しい価値の量は少なくなっています。
当初の品質慣行へのわずかな投資により、長期にわたって継続的で持続可能な価値の提供が可能になったでしょう。
チームの士気が低い
技術的負債も開発チームに害を及ぼします。 ほとんどのソフトウェアエンジニア(または他の専門家)は、自分の仕事をうまくやっていることに誇りを持っています。 自分の基準を満たしていないと感じる実装を行うように言われると、 自律性、習熟度、目的の感情が低下します。
実例
さまざまな業界における技術的負債の実際の例を見てみましょう
カンタス航空
オーストラリアの航空会社 カンタス 航空には、50年以上の歴史を持つITショップがあります。 同社は700以上のアプリケーションに苦労し、その多くはCOBOLやFORTRANなどの古い言語で書かれていました。 この老朽化したインフラストラクチャにより、いくつかの実質的で費用のかかるアップグレードプロジェクトが必要になりました。
そのうちの1つは、部品管理システムであるジェットスマートと呼ばれていました。 カンタス航空は、彼らのニーズを評価するために飛行機の整備士と会いませんでした。 彼らは何を入れるべきかを十分に知っていると思い込んでいました。 システムは非常に扱いにくいため、整備士組合はメンバーにソフトウェアを使用しないように指示しました。 廃用により、$40Mプロジェクトは衰退しました。
カンタス航空の技術的負債:
- レガシーシステムで増分アップグレードを行わず、代わりに既存のシステムが複雑すぎて使いにくくなるまで待つ。
- ユーザーや主要な利害関係者とのニーズを明確にしない。
- 実際のユーザーによるユーザビリティテストの欠如。
HealthCare.gov
手ごろな価格のケア法の重要な部分である HealthCare.gov 、立ち上げ時に長い応答時間とサービスの停止を経験しました。 稼働時間は43%しかありませんでした。 システムの失敗は非常に目覚ましく、発売から3週間も経たないうちに、オバマ大統領と彼の首席補佐官はウェブサイトを作り直すための特別なチームを作りました。
Webサイトの展開には、Webサイトの設計の標準であるキャッシュは含まれていませんでした。 ハードウェアの冗長性も不十分でした。 メンテナンス中に1つのデータストレージユニットとスイッチが故障し、5日近く作業が停止しました。 また、システムの正常性を確認するためのメトリックやダッシュボードも利用できませんでした。 特別チームは、仕事の初日にこれを行いました。
HealthCare.govの技術的負債:
- バックエンド開発にベストプラクティスを使用する必要はありません。
- ハードウェアの冗長性はありません。
- パフォーマンステストやストレステストはありません。
- パフォーマンス要件の検証はありません。
- システムを追跡し、チームがその正常性を維持するのに役立つバックエンド監視ではありません。
技術的負債に対処するための戦略
多くの場合、技術的負債を使用する決定は技術的なものではなく、社会的またはビジネス上の決定です。 品質を構築するためのトップマネジメントのサポートの欠如は、プロジェクトの失敗の初期 の重要な指標 です。 技術的負債を支払うためにも同じサポートが必要です。 技術的負債の影響を、その現在の使用または悪用とともに定量化して説明できることが重要です。 このプラクティスは、開発チームから製品所有者へ、および製品所有者から組織の他の部分へ行う必要があります。
完了の定義を適用する
done の適切な定義は、技術的負債を回避するために多くのことを行います。
- テストとタスクの自動化。
- 物事がどのように機能し、重要な決定を下すかについての文書化。
- コードレビュー。
- 仕事の正確さを確実にするのに役立つ他のもの。
プロダクト所有者は、バックログ項目に対するチームの作業が受け入れ前に標準に達していることを確認するための最後の防衛線です。 スクラムマスターは、プロダクトオーナー(実際にはスクラムチーム全体)が全体的に完了の定義を適用するのに役立ちます。 製品所有者が完了の定義を満たさない完了した機能を受け入れると、負債が発生します。
借金を追跡する
決定によって技術的負債が発生した場合、または検出された場合は常に、それに対処する ための製品バックログ 項目を優先する必要があります。 それを忘れたり無視したりしないでください。 これらの技術的負債製品のバックログ項目は、他の項目と同様に 見積もり です。 開発者が技術的負債を特定した場合は、製品所有者が最適な優先順位付けの決定を下せるように、その用語でそれを伝える必要があります。
または、製品所有者は、ビジネス価値が明確でない場合は、明確にするために質問する必要があります。 これらのバックログ項目は、製品所有者が技術的負債が優先順位にどのように影響するかをスクラム チームの外部に伝えるのに役立ちます。
適切な優先順位付け
技術的負債が発生したら、長期にわたって一貫して対処する方が実用的な場合があります。 一押しで取り組むと、新たな価値創造が長期にわたって止まってしまいます。
金融負債と同様に、すべての技術的負債項目が同じように高価、リスク、または影響力があるわけではありません。 たとえば、金融債務の返済では、金利または残高が最も高いものに緊急性が与えられます。
すべての技術的負債項目を一度に処理することは、経済的に意味をなさない場合があります。 時間をかけてそれらに対処する計画は、チームの通常の速度で持続可能なペースを可能にします。 大きなプッシュは失敗する傾向があります。 それらは非常に大きいため、小さなアイテムでの作業がもたらす明確な方向性が欠けている可能性があります。
一部の技術的負債は、外部要因が原因で発生します。 新しいソフトウェアまたは言語のバージョン、ベンダーの廃止、またはスケーリングへの調整は、このカテゴリに分類されます。 これらの項目も追跡し、優先順位を付けます。
伝える
借金の返済は優先順位とスケジュールに影響を与えるため、コミュニケーションは非常に重要です。 前述のように、チームは最初に技術的負債を追跡します。 スクラムマスターとプロダクトオーナーは協力して、リスクの教育、定量化、公開を支援します。
量化する
多くの場合、新機能には金銭的な価値があります。 したがって、技術的負債に優先順位を付ける際には、その負債のコストを定量化することが役立ちます。 これを行うには、次の 3 つの領域で計算します。
- 開発がどのように遅れているか(チームメンバーの給与のコスト)。
- 機会費用(より迅速に提供できること)。
- 収益の損失。
顧客満足度、採用、従業員の士気など、ビジネスに固有の負債を定量化する方法は他にもあります。
リスクを明らかにする
技術的負債はリスクです。 技術的負債が高いほど、リスクは高くなります。 不適切な要件、急いでいるコード、脆弱なインフラストラクチャはすべてリスクを生み出します。 これらのリスクは、製品が市場機会を逃し、顧客を不快にさせ、お金を失う可能性を高めます。
ここでも、財務上の比喩が役立ちます。 お金を貸すリスクを評価するとき、貸し手は資格としてクレジットスコアを使用します。 このスコアは、アカウントの数、アクティブな期間、総負債、未払いの支払いなど、複数の要因によって異なります。
技術的負債のクレジット スコアを作成できます。 その計算は、以下に関連して、事業ごとに異なります。
- 技術的負債のバックログ項目の数。
- 技術的負債のバックログ項目 (ストーリー ポイントなど) の合計見積もり。
- 技術的負債のバックログ項目の平均経過時間。
- 支払われた技術的負債と作成された技術的負債の比率 (技術的負債を獲得しているか失っているか)。
- 技術的負債の支払い専用のスプリントあたりの金額。
このスコアは、技術的負債の状態を示し、その返済を追跡するのに役立つメトリックになります。 たとえば、チームはリリースを加速するために技術的負債を引き受ける場合があります。 技術的負債のクレジットスコアが高いかどうかを言う可能性が高く、リリース後に対処する時間があると確信できます。
逆に、スコアが低すぎると、チームは予測を信頼できない可能性があります。 この場合、リスクが高すぎます。 チームは、リリース日を確認する前に解決する必要があります。
技術的負債の管理は常に課題です
技術的負債の管理は、常にソフトウェア開発やその他の業界の一部でもあります。 財政のように、慎重かつ賢明にそれを管理する人もいれば、それに溺れる人もいます。 いずれにせよ、あなたはいつかそれを支払わなければなりません。
技術的負債の状況がわかりませんか? アジャイルトランスフォーメーションをどのように行っているのか疑問に思っていますか?技術的負債を明らかにし、それを返済する計画を立てる方法については、 お問い合わせください 。
