技術的負債を理解する
ソフトウェア開発において、「技術的負債」という言葉を聞いたことがありますか？
この言葉は、開発チームが直面する一種の「借金」を表しています。しかし、この「借金」は金銭的なものではなく、ソフトウェアの品質や開発速度に影響を及ぼす可能性があります。
今回は、技術的負債について深掘りし、その理解と対策について考えていきましょう。
技術的負債とは何か
技術的負債とは、ソフトウェア開発において、短期的な解決策や手抜きを選んだ結果として後で直す必要が出てくる部分のことを指します。これは、時間やリソースの制約により、最適な解決策を採用できない場合に発生します。
Ward Cunninghamはこの概念を次のように説明しています：
初めてのコードを出荷することは、借金をするようなものです。少しの借金は、それがすぐに書き直しによって返済される限り、開発を速めます。オブジェクトはこの取引のコストを許容範囲にします。危険なのは、借金が返済されないときです。ちょっとしたコードに費やしたすべての時間は、その借金の利息としてカウントされます。
これを別の例えをすると
家を建てる際に手抜き工事をした結果、後で修理が必要になる状況に似ています。その修理を先延ばしにすると、家全体の機能が低下し、最終的には住めなくなる可能性が出てくる
というふうにも考えることができます。
同様に、技術的負債も放置すると、ソフトウェアの品質が低下し、開発速度が遅くなり、保守コストが増大します。これは、ビジネスに大きな影響を及ぼす可能性があります。
しかし、技術的負債は必ずしも悪いものではありません。適切に管理されていれば、プロジェクトの進行を柔軟にするための有効な手段ともなります。重要なのは、その存在を認識し、適切に評価・制御することです。
技術的負債が生じる原因
そもそも技術的負債が起こってしまう原因は様々です。
コードの質が低い
コーディング規約がなく、設計が不十分で、複雑な部分が多い。加えて、何かを説明するコードコメントが多い。
テストが不十分
ユニットテストから統合テスト、E2Eテストまで、適切なテストアプローチが必要
モジュール間の結合が強すぎる
それぞれが他のモジュールの進行を阻害し、そのようなコードを扱う時間を増加させる。強い結合が存在すると、一部の変更が他の部分に予期しない影響を及ぼす可能性があり、その結果、バグの発生やコードのメンテナンスが困難になる
古いライブラリやツールを使い続ける
セキュリティや新しい技術やプラットフォームにアップデートできないなど、いくつかの問題を抱えたレガシーなライブラリやツールを使ってい流状態。私たちは開発者として、常に最新のテクノロジーと効率的なツールを使って仕事をしたいと考えています
手動プロセスが多い
私たちのデリバリーにおけるいくつかのプロセスは自動化する必要があります。自動ビルドやCI/CDプロセスがない。
アーキテクチャが不適切
適切なアーキテクチャがない、または泥の塊だ。アーキテクチャはシステムで実現したいことを反映していないか、うまくスケールしていない。
ドキュメンテーションが欠如している
ドキュメンテーションがないか、システムの現状を反映するように更新されていない。
知識が共有されていない
ナレッジ共有の文化がないため、新参者がスピードアップするのが容易でない。作業中の決定事項や仕様は必ず文書化するべき
などが主な原因となります。
これらはすべて、ソフトウェアの開発と運用における効率と品質を低下させ、ビジネス全体に影響を及ぼす可能性があります。
技術的負債の管理と対策
技術的負債を管理し、新たな負債の発生を最小限に抑えるためには、まず技術的負債を優先することが重要です。
開発プロセスとコードベースを分析し、ボトルネックを見つけて技術的負債マップを作成します。その上で、どの部分が最悪の技術的負債を持っているか、またその部分が現在および将来の開発で使用されるかをマークします。これらのステップを踏むことで、技術的負債を効果的に管理し、削減することができます。これはエンジニアにとっての重要なネクストアクションとなります。
このマトリックスは、技術的負債を管理するための「テクデットウォール」を視覚化したものです。マトリックスは「コスト」（X軸）と「価値」（Y軸）によって定義されます。
緑色の領域 (左下): Quick Wins (早期の成功) – 低コスト、低価値。時間があるときに取り組むことで、コードベースを少しずつ改善することができます。
青色の領域 (左上): No-Brainers (明らかな改善) – 低コスト、高価値。これらはすぐに取り組むべき問題で、しばしばウォールに掲示する前に解決されることが多いです。
赤色の領域 (右下): Nope (手をつけない) – 高コスト、低価値。これらの問題は、その解決がもっと価値を持つようになったり、解決するための労力が減ったときだけ取り組む可能性があります。
紫色の領域 (右上): Worthy Investments (価値ある投資) – 高コスト、高価値。これらの問題は投資の対価として良いリターンを提供する可能性がありますが、他の利害関係者との交渉を必要とすることもあります。
技術的負債を低く保つためには
技術的負債を最初から作らないためには高品質のソフトウェア開発プロセスを持つことが大切になってきます。そのために行うべきことをいくつか挙げています。ただこれは負債になることの単なる裏返しでしかないです。
希望する結果のためのシステム設計
チームの形成からアーキテクトを関与させ、そのトポロジーを定義してください。そうしないと望ましいアーキテクチャにはなりません。
ペアプログラミング
一人の開発者がコードを書き、もう一人がフィードバックと提案を提供。これによりコードの品質が向上します。これを実装すれば、コードレビューは必要ありません。
開発者にリファクタリングを許可する
技術的負債を修正するために許可を求める必要がない文化を作るべき。特に数時間で済むようなものであれば。
高品質のコードの作成
まず開発者に、プログラミング言語を深く理解し、オブジェクト指向の概念、デザインパターン、リファクタリング、クリーンコードの原則、アーキテクチャパターンとスタイル、そしてSOLID、YAGNI、KISS、DRYの原則を理解するよう教育します。
まとめ
技術的負債は、ソフトウェア開発における避けて通れない課題です。
しかし、その存在を理解し、適切な対策を講じることで、その影響を最小限に抑えることが可能です。
ビジネスマンとエンジニアが共にこの課題に取り組むことで、より良いソフトウェア開発とビジネス成果を実現することができるので試してみてください。
参照
この記事が気に入ったらサポートをしてみませんか？