技術的負債とその管理方法

「その場しのぎの解決策」がもたらす隠れたコスト

ソフトウェア開発やアプリケーション開発は幅の広い世界であり、技術的負債が発生しがちです。厳しい制約の下では、プロジェクトをすばやく完了させるために、開発者はその場しのぎの解決策を採らざるを得ません。

しかし、こうしたその場しのぎの解決策が次第に「負債」として蓄積すると、少なくともその一部を「返済」する必要が生じます。負債自体は本質的に悪いものではありませんが、厄介な問題に変わることがあります。このような負債によって深刻な問題が積み重なり、対処が必要になるのです。

そこで、この記事では技術的負債とその影響についてまとめました。

技術的負債とは？

ソフトウェア開発者やエンジニアが、タイトなスケジュール、差し迫ったビジネスニーズ、要件の変更といった現実に直面し、ベストプラクティスの適用やコードの完成度に関して妥協を迫られるのはよくあることです。

技術的負債は、こうした状況に対処する過程で生まれるもので、開発者はプロジェクトの納期に間に合わせようと、妥協点を探ったりその場しのぎの解決策を用いたりします。これは「とりあえず作って後から直す」という考え方だともいえるでしょう。

しかし、後で問題が起こるとわかっているものをあえて作る理由は何でしょうか。最初から正しく作った方が得策ではないでしょうか。

技術的負債とは、ソフトウェア開発上の問題に対して、根本的で徹底した解決策ではなく、安易で不完全な「その場しのぎ」の解決策を選択したために、組織が後で支払いを余儀なくされる大きな潜在的コストのことです。こうした解決策には、次のようなさまざまな形態があります。

• 時代遅れのライブラリやフレームワークの使用
• 低品質なコードの記述
• テストや文書化などのプロセスの省略

このような手法は、短期的には緊急策として有効に思えるかもしれませんが、長期的には深刻な結果をもたらす可能性があります。

(技術的負債は、プログラマーのWard Cunningham氏が1992年に初めて提唱した言葉で、エンジニアが担当する開発作業を金融システムに例えたものです。金銭的負債と同じく、技術的負債でも「金利」が蓄積し、問題を修正するためのコストが次第に増加すると同氏は指摘しました。)

技術的負債をうまく活用する方法

技術的負債は悪いもののように思えるかもしれませんし、大半の場合はそのとおりです。しかし、適切に管理すれば、開発を迅速に進めるための手段として活用できます。

MVP (実用最小限の製品)は、大きな技術的負債を抱えた状態で開発されることも珍しくありません。この場合、MVPに継続的な価値があることが証明された段階で、完全にリファクタリングや作り直しが必要になるということが想定されています。

技術的負債とは、物事を迅速に行うことと、それを正しいやり方で行うことは、滅多に両立しないという認識に立った考え方であるといえます。

技術的負債がビジネスに及ぼす影響

• ユーザーの不満による収益の損失：技術的負債がバグとして表面化すると、ユーザーエクスペリエンスが損なわれます。これは、最終的には費用の増加(カスタマーサービスの必要性が増加)と、収益の減少(顧客離れが発生)につながります。
• 開発サイクルの長期化と必要な開発者の増加：技術的負債が悪化するにつれて、開発者は既存のコードベース内で作業することが難しくなり、新機能の開発と古い機能の修正の両方に時間を割かれるため、ソフトウェア開発ライフサイクルが滞り、市場投入までの時間が長くなります。
• 生産性の低下とイノベーションの行き詰まり：技術的負債が深刻な場合、開発者は問題への対応に追われ、革新的な新機能の構築に時間を費やすことができなくなります。
• 潜在的なセキュリティの問題：技術的負債によって脆弱性が高まり、攻撃者や内部脅威者にその脆弱性を悪用される可能性があります。最悪の場合、セキュリティ侵害に見舞われ、資産の直接的な損失、ビジネス上の損失、規制当局による罰金や罰則のリスクなど、金銭的なリスクに悩まされることになります。

技術的負債の例：決断がもたらす結果

技術的負債の概念を、住宅建設に例えて考えてみましょう。ソフトウェア開発者がアプリケーションを構築するときと同じように、ゼロから住宅を建設しなければならないとします。納期は厳しく、当然ながら予算やリソースも限られています。そこで、建設の過程で、いくつかのその場しのぎの解決策や妥協策を講じることを決断します。技術的負債と同じく、このような対策には次のようなものがあります。

• 低品質な素材を利用
• 特定の施工を簡素化
• 特定の建設要素よりもスピードを優先

このような決断により期限を守ることはできるかもしれませんが、その選択が長期的にどのような結果をもたらし、将来その結果に対処するためにどのような補修や改善が必要になるのかを理解しておくことが重要です。

包括的なテストとコードのレビュー

強固な基盤を構築するには時間とお金がかかりますが、少しでも時間とお金を節約するために、構造的な完全性を損なう可能性があると知りながら、低品質のコンクリートを基礎に流し込むことにしたとします。

完成した基礎は、当面は住宅を支えることができたとしても、本来の強度や耐久性を備えていません。こうした基礎工事の手抜きによって、将来的に構造上の問題や水漏れの原因となる亀裂などが発生し、高額な修理が必要となる可能性があります。

ソフトウェア開発において、リリース期限に間に合わせようと包括的なテストやコードレビューを省略することは、住宅の基礎工事で手抜きをすることに匹敵する行為です。そのようなコードは、当初は動作しているように見えても、バグや非効率性が潜んでいて、将来的に問題を引き起こす可能性があります。

コードの最適化と効率化

住宅の壁を作る際に、エネルギー効率の高い断熱材や窓を利用するのではなく、省エネ性能が劣る安価な代替品を利用したとします。当然ながら、この選択によって短期的には初期費用を削減できますが、長期的に影響が出ることが考えられます。

時間が経つにつれて、エネルギー効率の低い代替品によるエネルギー費用の上昇分が初期の節約分を上回り、支出の増加や持続可能性の低下につながる可能性があるのです。

ソフトウェア開発でも、コードの最適化や効率化への投資を怠ることで、同じような影響が生じることがあります。時間が経つにつれ、リソースの消費が増えて、パフォーマンスの低下や運用コストの増加につながることがあります。しかも、この影響がアプリケーションの効率性だけでなく、全体的なユーザーエクスペリエンスに広がる可能性もあります。

継続的なメンテナンス

住宅では、小さな水漏れやひび割れへの対処といった日常的なメンテナンスを怠ることが、住宅の自然な劣化を意図せず速める結果となります。一見些細な問題が次第に深刻化して、被害が広範囲に及び、本来避けられたはずの大規模な修理が必要になる可能性があるのです。

積極的な対策を講じて、こうしたメンテナンスの必要性に早めに対処することが、住宅の完全性と寿命を維持することにつながります。

ソフトウェアでも、セキュリティパッチの適用や機能の改善など、定期的なメンテナンスや更新を怠ることが、同様の結果につながります。脆弱性が高まり、大規模で時間のかかるアップデートが将来必要になるかもしれません。定期的なメンテナンスを続けることで、問題が雪だるま式に膨らむのを防ぎ、ソフトウェアの効率性を維持できます。

技術的負債の種類

住宅建設とソフトウェア開発の類似性に注目することで、ソフトウェア開発者が開発中に技術的負債を抱えてしまう理由が明らかになり、役立つ教訓が得られたのではないでしょうか。

また、負債を抱える理由が多岐にわたっていることに気づいた方もいるでしょう。実際、技術的負債は大きく次の3つのカテゴリーに分類できます。

意図的な技術的負債

意図的な負債とは、プロジェクトを完了させるためにあえて作られたものです。チームは、製品を早期にリリースする代わりに、ある程度の不安定さ、安全性やパフォーマンスの低さ、ユーザーの不満などの問題を受け入れることになります。

このような技術的負債にはリスクがありますが、これは既知のリスクであり、すべての関係者が適切なタイミングで文書化、追跡、修正することができます。

意図しない技術的負債

この形態の技術的負債は、ソフトウェアエンジニアリングのずさんさ、予期しない複雑さ、または技術的専門知識の不足から発生します。経営陣が突然出荷期限を1週間早めたために、エンジニアリングチームが手を抜いたり、製品のテストを完全に行わなかったり、不注意で製品にバグが入り込んだりすることによって、意図しない技術的負債が発生することがよくあります。このような技術的負債は文書化されることもありますが、しばらく気づかないことが多いため、通常は文書化されません。

意図しない技術的負債を修正することは可能ですが、そのためには、開発プロセスを調整し、出荷済みのコードを見直す時間をスプリントシステム内に確保する必要があります。

環境による技術的負債

技術的負債の最後のカテゴリーは環境による技術的負債です。これは、時間の経過によって、あるいはアクティブな対策を行わないことによって発生します。完璧なプログラムを開発し、リリース後の評判も上々であったとしても、環境は常に変化しているため、プログラムがアクティブに管理されていなければ、環境による技術的負債が発生する可能性があります。たとえば、次のような問題が実際に起こっています。

• オペレーティングシステムにパッチが適用されたことで、不整合や互換性の問題が生じる。
• Webサイトの中で管理が手薄だった部分の再設計や再構築を行うと、Webサイトをライフサイクル全体で適切にメンテナンスしていた場合と比べて、はるかに多くの修正作業を強いられる。
• ベンダーのAPIや必要なソフトウェアライブラリのアップグレードにより、互換性の問題が生じる。

こうした変化に対応できなければ、アプリケーションはやがて正常に機能しなくなり、他の技術的負債と同様、時間とともに悪化の一途を辿ります。

技術的負債の返済：必要な投資のためのベストプラクティス

技術的負債は、厳しい納期に対応したり、短期的にコストを削減したりするための緊急策として許容できることもありますが、最終的には隠れたコストや長期的な影響を組織にもたらします。したがって、計画的に取り組み、技術的負債の存在を忘れないようにすることが必要です。さもなければ、こうした負債が脆弱性や脅威などのリスクを生み出し、攻撃者に悪用される可能性があります。

そこで、組織が技術的負債に対処するためのベストプラクティスをいくつか紹介しましょう。

• 技術的負債を慎重に追跡する：目に見えないものを修正することはできません。開発における他の課題と同じように、技術的負債を監視して追跡し、優先順位を付けます。
• 良い技術的負債と悪い技術的負債を分ける：技術的負債を、その発生場所と、意図的である(良い)か意図的でない(悪い)かに基づいて分類しましょう。これは、重大な問題に優先的に対処するのに役立つ可能性があります。
• 重大な問題を優先する：技術的負債が原因でアプリケーションが停止したり、セキュリティ上の欠陥が露呈したりしている場合、これらの問題に最初に対処する必要があります。たとえば、疑わしいコードであっても、パフォーマンスへの影響が少ない場合はすぐに対処する必要がないかもしれません。
• アジャイル/スプリントのプロセスに技術的負債を明示的に含める：技術的負債の返済を日々の開発プロセスの一部に含めて、バックログにならないようにします。
• 品質基準を設定して遵守する：プログラマーがずさんなコードを出荷するのを阻止できれば、意図しない技術的負債を回避しやすくなり、管理も容易になります。
• メンテナンス作業に対しても正当に報いる：目立つ新製品を市場に投入したソフトウェア開発者にばかり賞賛が集まりがちですが、既存のソフトウェアプロジェクトや製品の機能を修正し、維持するために全力で取り組んでいる人たちにも目を向けましょう。
• 突然のスケジュール変更を避ける：経営陣が開発者に対するルールを変更したり、納期を変更したりすると、技術的負債が避けられなくなることが多々あります。現実的なスケジュール、手法、対応可能なワークロードを提案して、技術的負債を管理しやすくします。

住宅の建設中に性急な判断を下すと、住宅所有者が改修や修理にお金をかけざるを得なくなりますが、それはソフトウェア開発でも同様です。ソフトウェア開発チームは技術的負債に対処するためのリソースを割り当てておかなければなりません。

手抜きをしたり、ベストプラクティスを無視したり、技術的な課題の発生に対処しなかったりすると、技術的負債が増大し、プロジェクトの長期的な成功が妨げられ、総所有コストの増加につながる可能性があります。

このブログはこちらの英語ブログの翻訳です。