技術的負債の実際のコスト

「技術的負債」という言葉は、望ましい結果に合わせてソフトウェアを作り直すとチームの速度が低下するという、ウォード・カニンガムが提唱した説が始まりです。それはローンの利息を支払うようなものです。それは欺瞞的な概念になり得ます。「今のところ大丈夫」という考えは、ベロシティ、品質、価値、士気に影響を与える可能性があります。結局、技術的負債はやっかいなものなのです。自分がそのツケを払わなければならなくなるまで、実際の影響には気づきません。

技術的負債は、財政債務への影響を反映します

技術的負債は、金融負債とよく似ています。私たちはさまざまな理由（計算したうえでのもの、リスキーなもの）で金銭的負債を負い、その利息を支払わなければならないことを理解しています。 『コードコンプリート完全なプログラミングを目指して』の著者であるスティーブ・マコネルは、利息が技術的負債を定義すると指摘しています。

長期的に、不十分なコーディングプラクティス、不十分なテスト、不明確な要件などのリスクを冒すことを無視することはできません。チームがリスクを受け入れて前進するとすぐに、目に見えるかどうかにかかわらず、システムと製品への悪影響が始まります。

ある時点で、それに対処する必要が出てきます。ただし、問題への対処は通常、より複雑で費用がかかります。費用は、最初にリスクを負ってからのシステムの変更と進化に依存します。

それが利息です。時間が経てば経つほど悪化し、ベロシティを遅くします。

限られたケースではありますが、技術的負債を計算したうえで利用することも、できます。それは：

短期的にスピードアップする（リリース前、あるいは市場への投入時期に合わせるため）。
短期的なリソース（スタートアップ資本、助成金など）を拡張する。
技術的負債がすぐになくなる時にリソースを無駄遣いしないようにする（寿命が近づいているシステムのサービスなど）。

上記のような戦略的な例においては、受け入れた負債を、遅かれ早かれ返済するための計画と予算を考慮しておく必要があります。

上記ような例外とは別に、よりリスクの高い技術的負債が蓄積するまでの行動は、以下のようなことから生じる可能性があります。

短期的な集中の傾向（「このリリース／修正／機能だけを片づけてしまおう」)。
正しくやることへの怠慢（例えば、不完全なコーディング技術やコーディング標準の欠如、退屈だとか、細かい作業だと思って、ユニットまたは他の種類のテストをスキップするなど）。
必要なプラクティスをサポートするインフラストラクチャの欠如（継続的インテグレーションのシステム、頻繁な、あるいはつまらないタスクの自動化など）
不十分な知識やプラクティス（例：テストを自動化していない、チームが互いに学習していない、コードライターとテスターがサイロで運用しているなど)）
作業が、新しく価値のある機能に直接関連していない。
開発者が、技術的な品質への影響を考慮しない期限を設定した。

技術的負債の発生が意図的ではなかったにせよ、そのツケを払う必要がないわけではありません。金銭的負債のように、技術的負債を返済しないということは、時間の経過とともに利息が増加することを意味します。

ベロシティへの影響

クレジットカードで最大限の借金した場合、その人の手取り収入は利息の支払いのみに使われ、新規購入ができなくなります。技術的負債でも同じことが起こります。つまり現在の機能を維持するには、最大限の利用可能枠が必要なのです。そうでないと、革新して付加価値を提供する能力を制限してしまいます。

たとえば、電卓アプリを構築しているとします。下記のとおり、価値の提供とリスク（負債）の蓄積の進行を考えてみてください。

スプリント１：基本 GUIー番号を入力すると、その番号がディスプレイに表示される。とても単純なプログラムなので、そのための自動テストを作成しないことにしました。
スプリント２：追加機能を実装します。それはうまく機能し、手動でテストするのは簡単です。加算のテストは、番号の入力テストとしてもカウントします。
スプリント３：減算は、加算と同じくらい簡単にテストできます。ただし、品質を高く保つには、減算と加算の両方を手動でテストする必要があります。
スプリント４：掛け算。ここでもまた、この機能がうまくいきますが、テスターはいらいらしてきます。乗算、減算、加算のテストをする必要があるからです。
スプリント５：割り算。手動テストには、以前のスプリントでテストされた３つを含む４つの機能のテストが含まれるようになります。テスターは時間外労働をして、なんとかすべてのテストを遂行しました。テスターはうまく手動のテストスクリプトを実行できましたが、週末は潰れました。
スプリント６：小数。テスターは、このテストは１スプリントには大きすぎると言います。チームの他のメンバーは、他の機能よりも大変には見えないと言います。テスターは、すべてを再テストする必要（１スプリント分の作業時間を少し超えるくらいの時間がかかる）に加えて、新機能もテストする必要があると言います。６単位分のテスト（GUI、加算、減算、掛け算、わり算、小数）の代わりに、10単位分（小数点の有無にかかわらず、前の５つのスプリントに相当する機能）かかります。品質を維持するために、ベロシティが遅くなります。

開発チームが技術的負債を管理し、もっと早期に自動化を使用していた場合は、最初の機能を再テストするというテスターの指摘は有効です。

しかし、既存の 自動化テストでは、すでに作業の半分をカバーしています。自動化により、テスト担当者は、スプリントの終わりに向かってすべてのテストを行う代わりに、チームが小数機能を実装したときにテストの作成を開始できます。

品質の低下

技術的負債は、長期的なものを犠牲にして、より安易で短期的なソリューションを採用することです。この選択は、常に、品質保証と管理に影響を与えます。

品質保証：製品はビジネス／顧客のニーズを満たしていますか？
品質管理：製品に高い技術的品質がありますか？

どちらの場合も、結果は顧客の失望と、あとからくる無駄なやり直しにつながります。

提供する価値の低下

品質の低下は、顧客から報告され得る欠陥や緊急対応の増加につながります。プロダクトオーナーが予測には、価値のある機能がどんどん少なくなっていきます。開発チームは同じように一生懸命働いていますが、もはや無視できない未払債務のために、提供できる新しい価値の量が減っていきます。

品質保証プラクティスに、最初のちょっとだけ時間をかけていれば、長期にわたって継続的で持続可能な価値の提供が可能になったでしょう。

チームの士気が低い

技術的負債は開発チームにも害を及ぼします。ほとんどのソフトウェアエンジニアは（または他のどの専門家であっても）、自分の仕事をうまくやることに誇りを持っています。自分の基準を満たしていないと感じる実装を行うように言われると、自律性、習熟度、目的に向けた士気が低下します。

実例

さまざまな業界における技術的負債の実際の例を見てみましょう

カンタス航空

オーストラリアの航空会社カンタス航空には、50年以上の歴史を持つIT部門があります。同社は700以上のアプリケーションに苦労し、その多くはCOBOLやFORTRANなどの古い言語で書かれていました。この老朽化したインフラストラクチャにより、実質的で費用のかかるアップグレードプロジェクトがいくつか必要になりました。
そのうちの１つは、部品管理システムであるJestmartです。カンタス航空は、飛行機の整備士と会って彼らのニーズを評価することをしませんでした。彼らは何を導入すべきか、十分に知っていると思い込んでいました。システムは非常に扱いにくいため、整備士組合はメンバーにソフトウェアを使用しないように指示しました。使わないことにより、４千万ドルのプロジェクトが行き詰まりました。

カンタス航空の技術的負債：

旧来のシステムでインクリメンタルなアップグレードを行わず、既存のシステムが複雑すぎて使いにくくなるまで待ったこと。
ユーザーや主要なステークホルダーのニーズを明確にしないこと。
実際のユーザーによるユーザビリティテストの欠如。

HealthCare.gov

アフォーダブルケア法の重要な機関であるHealthCare.govは、立ち上げ時に長い応答時間とサービス停止を経験しました。稼働時間は43％しかありませんでした。システムの失敗があまりにもひどく、開始から３週間も経たないうちに、オバマ大統領と彼の首席補佐官はウェブサイトを作り直すための特別なチームを作りました。

Webサイトの展開には、Webサイトの設計の標準であるキャッシュは含まれていませんでした。ハードウェアの冗長性も不十分でした。メンテナンス中に１つのデータストレージユニットとスイッチが故障し、５日近く作業が停止しました。また、システムの正常性を確認するためのメトリクスやダッシュボードも利用できませんでした。特別チームは、作業初日にこれを行いました。

HealthCare.govの技術的負債：

バックエンド開発にベストプラクティスを使用しています。
ハードウェアの冗長性がない。
パフォーマンステストやストレステストをしていない。
パフォーマンス要件の検証をしていない。
システムを追跡し、チームがその正常性を維持するのに役立つバックエンド監視をしていない。

技術的負債に対処するための戦略

多くの場合、技術的負債を利用するかどうかの決定は技術的なものではなく、社会的またはビジネス上の決定です。品質を構築するためのトップマネジメントのサポートの欠如は、プロジェクトの失敗を示す初期の重要な指標です。技術的負債を支払うためにも同じサポートが必要です。技術的負債の影響を、その現在の使用または悪用とともに定量化して説明できることが重要です。このプラクティスは、開発チームからプロダクトオーナーへ、およびプロダクトオーナーから組織の他の部分へ行う必要があります。

完了の定義を適用する

適切な完了の定義は、技術的負債を回避するために貢献してくれます：

テストとタスクの自動化。
物事がどのように機能し、重要な決定を下すかについての文書化。
コードレビュー。
仕事の正確さを確実にするのに役立つ、その他のこと。

プロダクトオーナーは、バックログ項目に対するチームの作業が受け入れ前に標準に達していることを確認するための最後の防衛線です。スクラムマスターは、プロダクトオーナー（実際にはスクラムチーム全体）が全体的に完了の定義を適用するのに役立ちます。プロダクトオーナーが完了の定義を満たしていない完成機能を受け入れると、負債が発生します。

負債を把握する

決定によって技術的負債が発生した場合、または検出された場合は、常に、それに対処するためのプロダクトバックログ項目を優先する必要があります。それを忘れたり無視したりしないでください。これらの技術的負債製品のバックログ項目は、他の項目と同様に見積もりです。開発者が技術的負債を特定した場合は、プロダクトオーナーが、最適な優先順位付けの決定を下せるように、そのことを伝える必要があります。

またはビジネス価値が明確でない場合は、それを明確にするためにプロダクトオーナーが質問する必要があります。これらのバックログ項目は、技術的負債が優先順位にいかに影響するかを、プロダクトオーナーがスクラムチームの外部に伝えるのに役立ちます。

適切な優先順位付け

技術的負債が発生したら、長期にわたって一貫して対処する方が実用的な場合があります。一押しで取り組むと、新たな価値創造が長期にわたって止まってしまいます。

金銭的負債と同様に、すべての技術的負債項目が、でれも同じように高価、リスク、または影響力があるわけではありません。たとえば、金融債務の返済では、金利または残高が最も高いものに緊急性が与えられます。

すべての技術的負債項目を一度に処理することは、経済的に意味をなさない場合があります。時間をかけてそれらに対処する計画によって、チームが通常のベロシティで持続可能なペースを保つことをができます。一気にやろうとすると失敗する傾向があります。一気にやろうとしすぎると、小さな項目に取り組むときのような明確な方向性が見いだせないかもしれません。

一部の技術的負債は、外部要因が原因で発生します。新しいソフトウェアまたは新しい言語バージョン、ベンダーの廃止、またはスケーリングへの調整は、このカテゴリに分類されます。これらの項目も把握し、優先順位を付けます。

コミュニケーション

借金の返済は優先順位とスケジュールに影響を与えるため、コミュニケーションは非常に重要です。前述のように、チームは、まず最初に技術的負債を把握します。スクラムマスターとプロダクトオーナーは協力して、リスクの教育、定量化、公開をサポートします。

定量化する

多くの場合、新機能には金銭的な価値があります。したがって、技術的負債に優先順位を付ける際には、その負債のコストを定量化することが役立ちます。これを行うには、次の３つの領域で計算します。

開発がどのように遅れているか（チームメンバーの給与のコスト）。
機会費用（より迅速に提供できること）。
収益の損失。

顧客満足度、採用、従業員の士気など、ビジネスに固有の負債を定量化する方法は他にもあります。

リスクを明らかにする

技術的負債はリスクです。技術的負債が高いほど、リスクは高くなります。不適切な要件、急いでいるコード、脆弱なインフラストラクチャはすべてリスクを生み出します。これらのリスクは、製品が市場機会を逃し、顧客を不快にさせ、お金を失う可能性を高めます。

ここでも、財務上の比喩が役立ちます。お金を貸すリスクを評価するとき、貸し手は資格としてクレジットスコアを使用します。このスコアは、アカウントの数、アクティブな期間、総負債、未払いの支払いなど、複数の要因によって異なります。

技術的負債のクレジットスコアを作ることができます。その計算は、以下に関連して、事業ごとに異なります。

技術的負債のバックログ項目の数。
技術的負債のバックログ項目（ストーリーポイントなど）の合計見積もり。
技術的負債のバックログ項目の平均経過時間。
支払われた技術的負債と発生した技術的負債の比率（技術的負債が増えているのか、減っているのか）。
技術的負債の支払い専用のスプリントあたりの金額。

このスコアは、技術的負債の状態を示し、その返済を追跡するのに役立つメトリクスになります。たとえば、チームはリリースを加速するために技術的負債を引き受ける場合があります。技術的負債のクレジットスコアが高く、リリース後に技術的負債に対処する時間があると確信している場合は、そう言うかもしれません。

逆に、スコアが低すぎると、チームは予測を信頼できない可能性があります。この場合、リスクが高すぎます。チームは、リリース日を決める前に解決する必要があります。

技術的負債の管理は常に課題です

技術的負債の管理は、ソフトウェア開発だけでなく、あらゆる業界の一部です。財務のように、慎重かつ賢明にそれを管理する人もいれば、その沼にはまってしまう人もいます。いずれにせよ、いつかは負債を片づけなければなりません。

ご自身の技術的負債の状況を知りたいですか？アジャイル移行がうまくいっているでしょうか？あなたの技術的負債を明らかにし、それを返済する計画を立てる方法については、当社にお問い合わせください。