技術的負債は、ソフトウェア業界の技術チームにとって身近な問題です。 どんなチームでも、技術的負債は避けて通れないものだからです。
そこでこの記事では、技術的負債の重要ポイントについて解説します。 まずは技術的負債の概要と発生原因から始めて、技術的負債への対応が必須である理由、技術的負債が増え続ける理由について説明します。 その後、技術的負債が必ずしも害ではないことに触れ、技術的負債の計測方法や、DevOps の力で技術的負債を管理する方法をご紹介します。
目次
技術的負債とは？
なんらかの問題が起こったとき、技術チームはしばしば妥協策を取ります。しかし、実はこれは、最善の対応にかかるコストの支払いを先延ばしにしているにすぎません。 つまり、チームは技術的な “負債” を負ったことになります。
プロジェクトの規模が大きくなるほど、チームが抱える技術的負債も膨らみます。 また、借金と同じように、技術的負債にも “利子” が発生します。 プロジェクトの成長に伴って、問題への対処はどんどん難しくなり、コストもかさんでいきます。なぜなら、負債を解消するための知識が失われ、必要な変更の規模が大きくなるためです。 技術的負債に早期に対処した方が、コストを抑えられることはまず間違いありません。
技術的負債の多くは、技術チームの経験が豊富であれば把握しやすいものです。しかし、発覚しにくい負債もまた存在します。 そして残念なことに、気づきにくい負債は、気づきやすいものよりも解消のコストがかさみがちです。
解決策は、DevOps プロセスの導入です。問題の早期発見と品質管理を行い、技術的なギャップに組織全体で対応する仕組みを構築することで、技術的負債が溜まりにくい環境を整えられるでしょう。
技術的負債が発生する原因
さて、DevOps プロセスを役立てるには、技術的負債が生まれる原因を理解することが必要です。 技術的負債を生み出す要因は、主に次の 2 つです。
- ビジネス要件: 時間的なプレッシャーや状況の変化など
- 技術的なリーダーシップの問題: レビュー プロセスやツール、ドキュメント、テストスイートの不備、技術設計の不十分さなど
他にも、古いバージョンやフレームワーク言語の使用、関係者達との間でのコミュニケーション不足、複雑すぎるコードや設計等も技術的負債を生み出す一種の原因として知られています。 さらに、組織内で技術的債務に対処するためのサポート体制が不足しているために、負債が発生するケースもあります。
なぜ技術的負債に対処すべきなのか？
単純に言えば、技術的負債を放っておくと、対応にかかるコストが膨らむからです。 しかも、以下のようにさまざまな面で問題が現れます。
- 機能の開発期間の長期化
- 製品品質の低下
- 会社の評判の低下
- DX化推進の問題
技術的負債が増える仕組みを理解するために、DevOps なしで開発を行っているチームを想像してみましょう。 DevOps を導入していない原因は、時間や予算がなかったからであるかもしれません。 あるいは、DevOps には導入コストに見合うほどのメリットはないと思ったのかもしれません。
理由はともかく DevOps を導入していないので、新しいコードを実装する際には、開発者が自分のコンピューターでテストし QA 環境にプッシュします。 これはシンプルですが、ミスが発生しやすい方法です。たとえば、古いコードをデプロイしたり、正しいコードを間違ったサーバーにデプロイしたりしてしまうかもしれません。また作業中に、他の人がコミットしていないコードをプッシュする可能性もあります。 このような問題に気づき解消するまでにかかる時間こそが、DevOps を導入しなかったことで生じた “技術的負債の利子” です。
システムの中断が最小限で済み、他のチームにほとんど影響が及ばないケースこともあるでしょう。 しかし一方で、こうしたミスによって環境全体がダウンし、組織全体が影響を受けてしまう場合もあります。 少なくとも、ミスをした当人はテストの再実行で時間を浪費することになります。これにより開発時間が延びるので、組織全体で余計なコストがかかることも間違いありません。
このように技術的負債は金銭面で実際に影響を及ぼすので、会社として、技術的負債が膨らんでいく理由を理解しておく必要があります。 そうでないと、技術的負債に対処する技術チームをサポートすることはできません。
なぜ技術的負債は溜まっていく？
一般的に言うと、技術的負債が溜まる一番の原因は、時間的なプレッシャーです。 納期を守るために大急ぎで作業していると、優先度の低いバグへの対応は後回しにしてしまいがちです。 ほとんどの場合、後回しにしたバグはそのまま放置されてしまうので、このようなバグの数は増える一方です。
また、優先度の高い問題であっても、手早く簡単な応急処置で済ませがちです。 つまり、後で見直して対応すればいいと考えてしまうのです (コード内の “TODO” コメントがどれほど多いことか)。 しかし実際には、後になっても “TODO” が解決されることはありません。技術チームはいつも厳しいスケジュールに追われているため、コードを読み直す時間を確保できることはまずないからです。 そして時間が経つにつれ、問題の背景や影響を忘れてしまい、対処する意欲を失ってしまいます。
さらに、技術面についての判断は、時間が経つとソフトウェアのニーズに合わなくなるものです。 しかし多くの開発チームは、ここでも時間を節約しようとします。つまり、時間をかけてリファクタリングするのではなく、デリバリーを遅らせないように応急処置で済ませてしまうのです。 そうこうしているうちに、場当たり的な対応を保守するコストが、技術的負債を解消するコストを大きく上回るようになります。 ここで初めて、コードのリファクタリングに踏み切るのです。 極端な場合、プロダクトを一から作り直すことになるかもしれません。
時には、良いコードを書くための知識やスキルがないために、知らず知らずのうちに技術的負債を抱えていることもあります。 このような場合は、コードベースが大きくなるにつれて、コードの管理が難しくなります。
チームの構成や会社の種類によらず、技術的負債の発生は避けられません。 だからこそ、技術的負債を管理し、定期的に解消しておくことが非常に重要です。 ここで役立つのが DevOps です。
技術的負債は絶対に悪いもの？
先述のとおり、技術的負債は多大なコストを生み出します。しかし、あらゆる負債を即座に解消すべきかと言うと、必ずしもそうではありません。 企業が事業の成長のためにあえて借金をするように、手に負えない量でなければ、技術的負債を抱えていても問題にはなりません。 完璧にこだわりすぎて、本来の目的を見失わないようにしましょう。
将来的に問題に対処する場合のコストの方が、負債の解消よりも安く済むのなら、負債をそのままにしておくことも理にかなっています。 ただし、技術的負債を放置すると管理しきれなくなり、コードベースが根本から崩れる可能性があるので、 負債の管理だけは必須です。
技術的負債を計測するには？
考慮すべき要素がたくさんあるため、技術的負債の計測方法は複雑になりがちです。 チームの配置、テクノロジー、さらには要件など、変化する要素は多岐にわたります。 しかし、とある比率を使用すれば、こうした要素の変化で生じる影響を最小限に抑えられます。
技術的負債比率
技術的負債比率 (TDR) とは、コードベースの構築コストと修正コストを比較した比率です。 コストの計測単位は、時間または金銭的価値です。 このような比率があれば、社内でサポートを受けやすくなります。 たとえば、タイムラインの緩和、予算の追加、”実装必須” 機能の削減、トレーニングやツールの支給などが期待できるでしょう。
また、TDR を経営陣や関係者に示すことで、肥大化する前に技術的負債を解消した方が得だと説得できます。 TDR を許容範囲内に留めておくことを、組織の目標にしてもよいでしょう。
自動ツールでコードの技術的負債を分析する
手作業で技術的負債を見積もってしまうと、解釈が主観的になり、一貫性も損なわれます。そのため、ビジネスの観点で信用されにくくなってしまいます。 こうした問題は、SonarQube や Kiuwan などのコード検査ツールを使用することで払しょくできます。 たとえば SonarQube では、コードベース全体を検査して、検出された問題への対処にかかる時間を客観的に見積もることができます。
このようなツールは、DevOps と組み合わせると一層有意義なものになります。
DevOps で技術的負債を管理するには？
いくら DevOps でも、技術的負債の問題を全面的に解決できるわけではありません。しかし、早期発見によりバグが減り、コミュニケーションも改善されるので、負債が溜まりにくくなります。
SonarQube や Kiuwan などのツールを CI/CD パイプラインに組み込めば、技術的負債を継続的に計算し、上層部に報告できます。 DevOps は、技術チームと上層部をつなぐコミュニケーション ツールなのです。 また、将来的にバグを引き起こす可能性のあるコードについて開発者を教育するツールにもなります。 知識を蓄積するほどコードの品質は向上し、バグは減っていくことでしょう。
DevOps の導入の遅れは、絶対に解消すべき技術的負債です。 DevOps 方式で明確な基準を定義すれば、コードのチェックインからテストの実行、デプロイまでの各段階ごとに品質を確保できます。 これにより、反復作業やミスしがちな手作業から開発者を解放し、開発作業の効率を最大限に高められます。 さらに、現場の士気を上げて生産性アップを実現できるので、最終的に企業のコスト節約にもつながります。
また、DevOps を導入することで継続的デリバリーも実現できます。 継続的デリバリーでは、開発を進めながら機能をプッシュします。 リリース頻度が高い状況でも問題を迅速に検出しやすくなるため、リファクタリングのハードルを最小限に抑えられます。
おわりに
技術的負債は、ソフトウェア チームが時間を節約しようとして妥協策を取ったときに発生します。 この負債には “利子” が付くため、状況は時とともに悪化します。これを “返済” するには、最適かつ持続可能な解決策を講じるしかありません。 返済を先延ばしにしても良いケースはありますが、 技術的負債は必ず管理し、対処可能な範囲内に抑えるようにしましょう。
DevOps を導入し、SonarQube や Kiuwan などのツールを組み込めば、技術的負債を大幅に管理しやすくなります。 これらのツールを使用することで、改善の余地のあるコードを早期に発見し、バグの数を減らして、関係者全員に最新の情報を共有できます。
技術的負債と開発速度のバランス取りでお悩みであれば、CircleCI がお役に立ちます。ぜひ、こちらの Web ページで CircleCI のメリットをご覧ください。
