技術的負債の経済的影響

エグゼクティブサマリー

自分がどれだけの借金を抱えているのかわからなかったらどうしますか？ どれだけの費用がかかっているのか、または会社が業務の改善を行ったり、市場の変化に対応したり、ビジネスを完全に変革したりするのをどの程度妨げているのかわからないのは、不快な立場です。

さらに、組織内のだれかが許可を求めずに債務を負う可能性があるとしたらどうでしょうか。 たとえば、不動産の責任者は、1年目の家賃は低くても、年外に家賃が大幅に上昇する複数年の賃貸契約を、会話以外の方法で開示することなく、すぐに開始できます。

これはすべて無分別なガバナンスのように聞こえますが、実際には企業では非常に一般的です。 キャッチは、この種の「債務」は、私たち全員がよく知っている伝統的な金融商品の形ではないということです。

技術的負債には、これらすべての特徴があります。

最も単純な形の債務は、将来返済する意図と約束を持って今日借りています。 今日の借り入れがより良い明日へとつながるとき、たとえば大学への借り入れや家の購入など、借金は理にかなっています。 今日借りることが明日を悪化させるとき、例えば、高価な夕食に出かけて、すぐに返済されないクレジットカードにそれを置くとき、借金は一般的に悪いです。

企業の観点から言えば、債務のコストよりも大きな利益をもたらす投資に資金を提供するために発生した場合、債務は良いものになる可能性があります。 あなたが借金の期限が切れるずっと前に事業を売却することを計画しているなら、それはまた理にかなっているかもしれません。 債務の欠点は、現金と利益を引きずり、柔軟性を制限し、最終的に破産につながる可能性があるほど負担になる可能性がある非常に現実的な費用がかかることです。

これまで、私たちがほのめかしている比喩は、金融債務に関するものですが、さらに別の形態の債務、つまり技術的債務（または「技術的負債」）には多くの類似した特性があり、慎重に測定、管理、および締結する必要があります。 。 それがあなたの会社が競争に先んじて市場に参入することを可能にするなら、それはおそらくそれだけの価値があります。 同様に、潜在的に深刻なセキュリティの脆弱性を軽減するために技術的負債を引き受けることも、おそらくそれだけの価値があります。

ただし、技術的負債には欠点があり、ある部門が別の部門のソフトウェアを使用したくない場合や、短期的な財務目標を達成するためにアップグレードを数回遅らせた場合など、非効率性と慣性につながります。

では、技術的負債とは何ですか？

技術的負債は、コンピュータープログラマーのウォードカニンガムが1992年にこのフレーズを作り出して以来、主に技術コミュニティ内で使用されてきた用語です。その使用法は最近普及し、アジャイルプログラミングの急増とともに中心的な舞台になりました。 この記事で説明する技術的負債は、プログラミング方法論ではなく、その存在の戦略的意味に関するものです。

簡単に言うと、技術的負債とは、新しいシステムを実装したり、既存のシステムを維持したりするときに時間やお金を節約するために行われた事前の決定の結果として、会社のコストが増加し、俊敏性が失われることです。 これは、システムが正しく統合されていない場合、またはコードが過度に複雑な場合に発生します。 これは、非効率性、市場投入までの時間の考慮、古いバージョンのソフトウェアの実行など、さまざまな理由によるものです。

いくつかの明確な例は次のとおりです。

1. 新しいソフトウェアの使用やセキュリティアップグレードの適用を妨げる古いバージョンのWindowsを使用する
2. 非常に古く、カスタマイズされているという悪循環にあるERPシステムは、「リッピングアンドリプレース」作業になるため、アップグレードできません。
3. 組織のさまざまな部分で機能が重複している同様のシステム

次の図は、技術的負債が企業の技術スタック内で作成できる他の技術的実装とどのように異なるかを示すのに役立つ図です。 しばしばバグであると誤解されますが、技術的負債は、その存在が露骨に明白ではない可能性があるという点で大きく異なります。 そこには危険が潜んでいます。手つかずのままにしておく時間が長ければ長いほど、将来の影響の大きさは大きくなります。

IT部門で働き、高レバレッジの企業でITの報告を受けたCFOとして、技術的負債が従来の負債とどれほど似ているかを知りました。 それはまた、それがどれほど不透明で危険であるかにも私を驚かせました。 金融のバックグラウンドを持つ人々は、金融債務のメカニズムに精通しています。それは具体的で計算が簡単です。 しかし、技術的負債についてはそうではありません。技術的負債は、他の誰かの問題であると誤解されたり、誤って想定されたりすることがよくあります。

技術的負債のコストは正確には何ですか、そしてそれらは本当ですか？

簡単な答えは、現金コストは非常に現実的であるということです。 個別に測定および管理するだけでなく、特定する必要のある重要なソフトコストもいくつかあります。 これらのコストのいくつかの例について、以下で詳しく説明します。

現金費用

技術的負債は、利息の支払いと同じくらい現実的です。 ただし、通常、次のように、単純な「利息」ライン費用よりも間接的な方法で損益に現れます。

人員

• 既存のシステムを維持するためだけに、より多くの人員が必要
• 新しい機能をもたらすための追加の開発者時間

オーバーヘッド

• 買収統合の相乗効果の実現の遅れ
• セキュリティ違反から発生する修復と罰金

売上高

• システム停止による売上損失
• 効率の悪いマーケティング支出

運転資本

• 特に在庫残高の多い企業の要件の増加

ソフトコスト

ハードコストには実際の金額が関連付けられていますが、ソフトコストもあり、定量化して節約を実現するのは困難ですが、ビジネスの結果に絶対的な影響を及ぼします。 これらには以下が含まれます：

マーケットインテリジェンス

• 機会や市場の変化に迅速に適応できない
• より良い意思決定を行うためにデータを情報に変換する能力の低下
• 真実の複数のバージョン

生産性

• システムの停止によるスタッフの生産性の低下
• データの分析よりもデータの抽出とマッサージに多くの時間を費やす生産性の低いスタッフ
• 重大なセキュリティ侵害が発生した場合、上級管理職の時間と注意を狂わせる

技術的債務と財政的債務の比較を見ると、重要な違いの1つは、前者には正式な管理がないことです。 金融債務の場合、通常、信用委員会、資産および負債管理チーム、およびタカのようなレベルを監視する財務スタッフがいます。 ただし、技術的負債があるため、これらの統制のほとんどは従来のビジネスには存在しません。

技術的負債が発生する方法と理由

従来の債務では、取締役会はCEOおよびCFOとともに、通常、資本構造、つまり、資本の額、債務の額、および債務の種類（リボルバー、資産ベース、またはバニラ無担保）を設定します。 キャップテーブルは、どの債務がいつ返済されるかについても明確です。 これがすべて正式に決定されると、債務を調達するための構造化されたプロセスが開始されます。

貸し手は、債務返済の履歴、信用格付け、およびそれを裏付ける担保の質の評価を通じて、債務を返済する企業の能力を調べます。 ただし、技術的負債が発生した場合、この正式なプロセス、定量化、および承認は行われません。 これが技術的負債が発生するプロセスをどのように、そしてなぜ発生するのかを見てみましょう。

時間の制約は妥協につながります

市場投入までの時間はビジネスのすべてです。 新しいテクノロジーの実装は、スタンドアロンベースで実行できる場合、はるかに高速に実行できます。 残念ながら、これが意味することは、他のシステムが実装と同期されていないことです。 単純な技術スタックを持つ無駄のない組織の場合、これはそれほど悪くはないように思われるかもしれません。

ただし、システム構成の複雑さが増すにつれて、問題が発生します。 結局、テクノロジーはプロセスを自動化し、情報に変換されるデータをキャプチャします。 統合されていないテクノロジーは、連携して機能しないビジネスプロセスと、真実の複数のバージョンをもたらします。

速度のために時間が犠牲になると、確立されたテストプロトコルは無視されるか、免除される可能性があります。 これは通常、将来的に「バグ」を引き起こし、何らかの形でシステムの劣化を引き起こし、開発者がそれらを修正するための時間を無駄にします。

技術的負債の影響を時系列で見ると、問題が手つかずのままである時間が長いほど、影響の大きさは大きくなります。 小さなコードリファクタリングの演習として始まるものは、将来の全体的な近代化と交換の取り組みに雪だるま式に進む可能性があります。

短期的なコスト削減の誘惑

それに直面しましょう。経営陣は、数字を打つという絶え間ないプレッシャーにさらされています。 今日の支出を延期することはあなたが四半期を作るのを助けることができます、しかし借りるのと同じように、あなたはある時点でそれを返済しなければなりません。 企業が短期的にお金を節約するが、最終的に技術的負債をもたらすいくつかの方法は次のとおりです。

ソフトウェアの更新

定期的なソフトウェア更新の実装にかかるコストと問題により、ソフトウェアの更新が遅れることがあります。 時々、これは何年も続きます。 不便なときにMicrosoftAutoUpdateが表示された場合、私たちは皆、MicrosoftAutoUpdateを強制終了する罪を犯しています。

システムが現在のバージョンよりもかなり遅れている場合、システムと統合する必要のある新しいソフトウェアは単純にできません。 さらに、一度に複数のバージョンをアップグレードすることは、通常、維持するよりも費用がかかり、ほとんどの場合、時間がかかります。

ハードウェアの交換

組織が複雑になるにつれて、ハードウェアの更新サイクルを同期するという膨大な労力は、圧倒的でコストがかかる可能性があります。 これにより、現在のハードウェアが、チーム間のハードウェアの品質の間に存在する極端で大きな格差にまで拡大する可能性があります。 一部のチームは、ITがアップグレードを開始するのを待つのではなく、イライラして新しいハードウェアを購入し、デスクの予算で費用をかけるだけです。

この格差は、共同作業の生産性とハードウェア/ファイルの互換性に影響を及ぼします。

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

問題について話すだけでなく、プロアクティブを適用して、技術的負債を解決するための解決策をいくつか説明しましょう。

そのために、私たちは金融債務を管理するために使用される技術を呼び出すことができます。 あなたの負債を管理するために、あなたは最初にそれらが何であるか、それらがいくらであるか、そしてそれらの支払い条件を知る必要があります。 技術的負債についてこれを試してみましょう。

1.あなたが持っている技術的負債の内容と金額を把握する

金銭的債務は、各ピース（たとえば、シニア、メザニン、またはリボルバー）の優先順位によって定義されるトランシェで発生し、次に、どちらが最初に返済されるかを示します。 技術的負債にも同様の優先順位のパターンがあります。 まず、ミッションクリティカルなシステムから始める必要があります。 彼らにはどのような技術的負債がありますか？ 次に、より広いエコシステムを見てください。より適切に言えば、システム間のどのような技術的負債が費用を引き起こしているのでしょうか。

このプロセスを過度に複雑にしないでください。 ある時点で、上から下への評価に取り掛かりたいと思うでしょうが、そこから始める必要はありません。 IT責任者に、この宿題と一緒に管理チームを引き寄せてもらいます。

1年前にすべての技術的負債を完全に清算したとしたら、今年（または来年）はどのようにうまく機能したでしょうか。

トップ10のアイデアを取得し、それらを2x2のマトリックスに入れます。一方の軸で支払いを行うのは簡単/困難で、もう一方の軸で利益の程度を示します。 うまくいけば、ビジュアルがどこから始めればよいかを理解するのに役立つでしょう。

そこから、ドリルインして、賞品のサイズと労力に関する仮定を検証します。 ここでは中立性が重要であるため、「無料の評価」を実施することを提案しているソフトウェアベンダーには注意してください。

2.何をすべきかを決定する

自分が持っている技術的負債がわかったら、次にそれをどのように処理するかを決める必要があります。 取るべき多くのオプションがあります。

最終的には何もしないのが最善かもしれません。 「少額」または「低金利」と評価された債務については、早期に返済するという重大な「前払いペナルティ」がある場合と同様に、そのままにしておくのが最適な場合があります。 戦略的な利点もあるかもしれません。 1つのバージョンの後ろにあり、そこにとどまるのは通常は問題ありませんが、他の人の10セント硬貨でねじれを解決できるという利点がある場合もあります。

技術的負債の返済または削減には、システムの交換とコストの打撃が含まれます。 これは、すぐに実行することも、段階的に改善するプロセスを通じて時間をかけて実行することもできます。 金融債務と同様に、技術的債務を「借り換え」ることができる創造的な方法があり、メンテナンスをアウトソーシングすることもそのような方法の1つです。 これは最終的には解決にさらにコストがかかる可能性がありますが、それを分散して当面のコストヒットを下げることができ、分業の原則を通じて、より専門的なエンティティにタスクを委任します。

クラウドベースのソフトウェアおよびハードウェアサービスの出現は、リースベースの金融の人気との比較ももたらします。 クラウドサービスの使用は、CAPEX要件の削除と、開発の焦点をクラウドプロバイダーに移すことの両方において、技術的負債を削減するための効果的なツールでもあります。

3.支払いプランを作成します

技術的負債を削減するコストに圧倒されたり、一度に完済しようとしたりしないでください。 これは、あらゆる規模やバランスシートの組織を圧倒する可能性のある野心的な演習になります。

繰り返しになりますが、財務比較に戻ると、最も高い金利のクレジットカードを最初に返済するという考え方があります。 これは単に、最初に価値の高い/努力の少ない活動を攻撃することを意味します。

前のセクションでは、技術的負債に取り組むさまざまな方法について説明しました。 それぞれのコストを評価するときは、比較演習を行うのが最善です。 それぞれの潜在的な結果のキャッシュフローコストをランク付けすることで、利害関係者は各パスのトレードオフと利点を明確に把握できます。 このようなビジュアルの例を以下に示します。

この比較は、理論上の解決と、問題の解決と何もしないこと（「既存のベースライン」）との間の明確なコントラストの間に存在するトレードオフを示しています。 この例では、クラウドに移行する場合、SaaSベースのソリューションがビジネスにとって最も経済的なオプションになります。

今後の技術的負債の管理

ベースラインと攻撃の計画を確立したら、その可視性を維持し、新しい債務が忍び寄るのを防ぎたいと思うでしょう。この演習は、新たなスタートであり、問​​題を防ぐためのベストプラクティスを実装する機会であると考えてください。将来再びエスカレートします。

ローン開示ステートメントを実装する

ほとんどのテクノロジープロジェクトには、エグゼクティブスポンサー、高レベルの目標、予想されるメリット、スケジュール、そしてもちろんコストを備えた正式な承認プロセスがあります。 これは、発生する新しい技術的負債とその正当化を一掃するのに最適な場所です。

借入しきい値の設定

新しい基準を設定することに熱心になりすぎないでください。 事前に設定された制限のある企業のクレジットカードを発行するのと同じように、技術的負債を過剰に管理したくありません。 技術的負債の多くは小さく、コードの記述に関連しており、すぐに返済されます。 これは特にアジャイル開発に当てはまります。 IT責任者を信頼して、このしきい値を設定および監視してください。

引受人を再訓練する

大企業では、ITには「変更管理」と呼ばれるプロセスがあります。 新しいソフトウェアが公開される前に、通常は変更管理が行われます。 簡単に言うと、変更管理の仕事は、会社のテクノロジーシステムへの新しい変更が他のシステムに影響を与えないようにすることです。 彼らは、新しいシステムが標準化された方法と手順に準拠していることを確認することによってこれを行います。 このプロセスを使用して、新しい債務が発生するのを防ぐか、少なくとも特定することを検討してください。

技術的負債は、ビジネスを行うための実際のコストであり、システムの停止と会社全体の俊敏性の低下の本当の原因です。 ただし、継続的な負担である必要はありません。スマートCFOは、組織にどれだけの技術的負債があり、それを最適化するために何が必要かを知っています。