キーポイント
- Technical debt impacts the whole company, but it especially affects engineers as more tech debt means more bugs, performance issues, downtime, slow delivery, lack of predictability in sprints, and therefore less time to work on new exciting projects.
- Engineers waste seven hours per week on technical debt which is often invisible to stakeholders. Speaking to non-technical stakeholders using business terms is the best way to make technical debt easily seen.
- Mess isn’t always bad, just as technical debt doesn’t always mean there’s a problem. The key is to fix the right amount of technical debt at the right time.
- Companies should aim to proactively and continuously address technical debt. Continuously addressing technical debt gives teams an opportunity to deliver value regularly and empowers engineers to make decisions.
- In the future, technical debt will become less of an engineering problem and more of an important business prerequisite that helps with delivering more value to our customers and the business.
この記事では、3人の専門家（Alex Omeyer氏、Nicolas Carlo氏、Maarten Dalmijn氏）が「技術的負債の状況2021」レポートの主な調査結果を説明します。説明する内容は、技術的負債がエンジニアリングチームに与える影響、継続的なメンテナンス作業の長所、技術的負債の将来、技術的負債に対処することの重要性を企業のリーダーシップに伝えるために各エンジニアリングチームができることです。
技術的負債調査の状況
「技術的負債の状態2021」レポートは、200人以上のエンジニアとエンジニアリングリーダーを調査した後、開発者の声を測るSaaS企業Stepsizeによって作成されました。レポートは、技術的負債がエンジニアリングチームのやる気、速度、および顧客体験に与える影響を示しています。主な調査結果は次のとおりです。
- エンジニアの52％は、技術的負債がチームのやる気に悪影響を与えると考えている。エンジニアの60％以上が、技術的負債によってバグや停止を引き起こされ、開発プロセスが遅れると考えている。
- 平均的なエンジニアは、技術的負債の対処に週7時間（約1日）を費やしている。
- エンジニアの大多数（66％）は、技術的負債に対するプロセスがあれば、チームは最大で100％早く出荷できると考えている。
- 技術的負債がビジネスに与える悪影響についてエンジニアが確信しているにもかかわらず、58％の企業はまだ技術的負債を管理するプロセスを持っていません。
技術的負債がエンジニアリングチームのやる気に影響を与えるのはなぜか
汚れた鍋やフライパンでいっぱいの散らかったキッチンで、毎日さまざまな料理を準備しなければならない料理人を想像してみてください。必要な調理器具を簡単に見つけられず、食材を準備するスペースがありません。残念ながら、片付けをする時間はありません。そのため、このひどい環境で働くことを強いられ、作業は遅くなり、料理することが難しくなります。
そんなキッチンで料理人として楽しめますか。皆さんが仕事をする日に、常にそのような条件下で料理を準備しなければならず、避けられない遅れと不幸な顧客がいる状況に、どれほど苛立たせることであるかを想像してみてください。
Dalmijn氏は次のように述べています。「これは、ソフトウェア開発者が技術的負債の多いシステムで作業しているときと同じ状況です。混乱により開発者の動きが遅くなり、時には彼らが実際の仕事をするのを妨げることさえあります。技術的負債により、厄介な障害の対処に多くの時間が失われ、皆さんが仕事を誇りに思うことを難しくしてしまう可能性があります。あなたは、ヘディングだけでゴールを決めなければならず、両足を使ってシュートとパスをすることができないサッカー選手のようなものです。技術的負債がフラストレーションを引き起こすのも不思議ではありません。」
最大の問題は、汚れたキッチンと違い、技術的負債は技術的でない利害関係者にはほとんど見えないということです。彼らには、減速として現れる影響しか見ることができません。しかし、見られるようになったときには、すでに手遅れであることがほとんどです。これはすべて新機能に関するものであり、すでに脆弱な基盤に常に新しいコードを追加しています。
もう1つの問題は、技術的負債が多すぎると、エンジニアリングチームが消防モードになることです。技術的負債は会社全体に影響を与えますが、技術者にとっては、技術的負債が増えると、バグが増え、パフォーマンスの問題が増え、ダウンタイムが増え、デリバリが遅くなり、スプリントの予測可能性が失われます。結果として、価値あるものを作るために費やす時間が減ります。
エンジニアは技術的負債に週7時間を消費
「このことに驚きはありません」とCarlo氏は言う。「平均的な開発者は、技術的負債にむしろ週7時間を超える時間を浪費していると思います。開発者がほとんどの時間を既存のコードの読み取り/デバッグ/テストに費やしていることは明らかです。」
2017年に公開されたMicrosoftの調査によると、開発者の時間の58％はコードの理解に費やされています。特にソフトウェアが本番環境に出荷され、それをメンテナンスする必要がある場合です。これは、開発者が直感的に認識できるものです。コードに慣れていないほど、時間がかかります。サプライズが多いほど、時間がかかります。すべてのシナリオを再現するのが難しいほど、それを正しく行うのに時間がかかります。そのため、優れた自動テストが非常に重宝されます。
コードを読むことは、コードを書くことよりも難しいです。多くの場合、技術的負債が多いということは、読む必要のあるコードが多く、コードを理解するのが難しいことを意味します。技術的負債はまた、チームのメンバーが全体像を見ることなく、システムの小さな部分をほとんど理解することを意味します。
この問題の修正に費やされた時間は、技術者以外の利害関係者には見えないことが多いです。これによる生産性の向上は、別の変更が行われるまで見えません。清潔なキッチンは、そこで料理をする必要があるまでスピードアップには繋がりません。開発者が「前回、技術的負債の修正に時間を使ったので、この変更は簡単でした」と言うのを聞くことはほとんどありません。生産性の向上は明解ではないため、技術的負債を修正するために余分な時間を割り当てることはありません。
技術的負債を管理している場合、企業は最大100％早く出荷可能
技術的負債を管理することは、定常的に価値を提供するための前提条件です。整頓された清潔なキッチンがおいしい料理を定常的に提供するための前提条件であるのと同じです。これは技術的負債を持つべきではないという意味ではありません。常にある程度の面倒を抱えているでしょうし、それも健全です。目標は面倒をゼロにすることではありません。目標は、あなたの動きを遅くし、素晴らしいキッチンを運営することを妨げてします面倒を取り除くことです。
「企業が2倍の速さで出荷できると言うのは間違った見方です。これは私の意見です。準備に時間がかかりすぎたり、料理が冷たくなったりすると不満を言う慌ただしい顧客でいっぱいのレストランでサービスを提供するという面倒がなく、清潔なキッチンがあることが有益であることには誰も疑問を持ちません。」とDalmijn氏は言っています。
ただし、面倒は必ずしも悪いわけではありません。時には、流れを保つために面倒も必要です。何か新しいことをしているとき、例えばIkeaのベッドを作ると、組み立て中の面倒があります。仕事で忙しいときにこの面倒をすぐに片付けると、すべての流れが失われます。適切な時期に適切な量の技術的負債を修正するのです。
技術的負債をより効果的に対処することが重要です。これは、めったに使われない、あるいは変更されない製品の領域の技術的負債に同程度の配慮をしないことを意味します。また、これは開発者が技術的負債の修正を正当化する必要がないことも意味します。キッチンの掃除が料理の一部であるように、技術的負債の修正はコーディングの一部です。
「こんなにたくさんの人がいるのを見て驚いた」とOmeyer氏は言っている。「しかし、私はそのことを経験的に検証することができます。このように考えてみてください。ある機能がスプリントを使い切ると見積もった回数はどの程度でしょうか。完了するまでに2回、あるいは3回かかるでしょうか。ここで、これを会社全体の規模で想像してみてください。技術的負債を本当にうまく処理している企業は、そうでない企業の2倍の速さで出荷できることは信じ難いものではありません。」
Carlo氏は、企業によっては2回、3回、あるいは、はるかに速く出荷できると考えています。「私はコード品質へのさまざまなアプローチを試しました。同等ではありませんが、1日以内に製品に対する有益な変更を出荷できた場合と、1週間待たなければならない場合とでは、生産性の違いがわかりました。これは実際には自動的に評価するのに適したエクササイズです。新規参入者がプロジェクトを設定し、変更を加え、テストし、本番環境にデプロイするのにどのくらい時間がかかるでしょうか。同様の規模のプロジェクトの場合、答えには数時間から数週間の幅があります。」
メンテナンス作業を継続的に行うことの長所と短所
技術的負債に継続的に対処することは、ほとんどの企業にとって非常に重要です。特に市場に適合させ、高品質の製品を顧客に提供することを目指す企業には重要です。達成するのは常に簡単というわけではなく、このアプローチにはプラスの面とマイナスの面の両方があります。
長所：
- アジャイルな働き方。継続的なメンテナンス作業は、定常的に価値を提供するための前提条件です。制御できる状態に戻すために別のプロジェクトが必要となるような技術的負債は、定常的に価値を提供することができないことを意味します。
- 開発者の幸福感を高める。 混乱の中で働くことを好む人は誰もいません。技術的負債を扱うプロジェクトは、かなり長い間対処しなければならない目に見える面倒事があることを意味します。
- 新機能の市場投入までの時間の改善によるビジネス価値の向上。技術的負債により、皆さんの動きが遅くなります。本当のコストはあなたが失う開発者の時間ではありません。新しい機能を市場に出すのに遅れるコストがあるという事実にあります。その機能の遅延によるコストは、開発者の生産性の損失よりも桁違いに大きくなる可能性があります。これが技術的負債の真のコストであり、時間でけの問題ではありません。
- 許可を求める必要はありません。 ボーイスカウトとしてコードをクリーンアップしているのであれば、機能実装の一部として実装するように変える必要があります。そうすれば、そのための予算を要求する必要はありません。それは仕事の一部で、皆さんはその専門家です。
- 実際のところ、簡単に始められます。 技術者でなくても、クリーンアップしたい小さなことを追跡し、進めていく中で対処することで、自分で始めることができます（たとえば、変数名を変更したり、関数を抽出したり、...）
短所：
- 時間の経過とともに蓄積された大きな技術的負債に対処するのは困難です（たとえば、現在4つのメジャーバージョンが遅れているORMライブラリのアップグレードです）。ただし、チームが十分な経験を積んだら、作業を小さなまとまりに分割する方法を見つけましょう。これは通常、継続的に行うこともできますが、最終目標について明確なビジョンを持っている必要があります。ほとんどのチームにとって、これがプロジェクトで行う簡単なやり方です。
- 通常のビジネス上の圧力によって簡単に、継続的なメンテナンス作業が中断されてしまいます。また、エンジニアがコードベースの改善に対する報いがない場合（たとえば、新機能のみが称賛され、キャリアアップにつながる場合）、エンジニアは改善に対して適切な優先順位を付けられません。
- 継続的な取り組みは目に見えず、賞賛をもたらすことがありません。 私の経験では、多くの企業が防火に取り組む人でなく、消防士を賞賛します。生産上の問題を解決するために1時間余分に働いたことで、従業員が賞賛されることがどの程度あるでしょうか。そもそも問題の発生を防いだことで従業員が称賛されたことは何回あるでしょうか。継続的な取り組みは目立ちません。その恩恵は、許可を求める必要がなく、火を消すために余計に大変な作業をする必要がないことです。しかし、そのことで賞賛されることはありません。私は、技術リーダーとCTOに変えていくことを奨励します：防火に対して賞賛しましょう！
技術的負債の将来と今できること
「私は、既存の（レガシー）コードを効果的に扱う開発者がもっと現れてほしいと思っています。私たちはそのようなスキルを教えていません。「コードの読み方」を実際には教えていないのと同じです。信念は「試して、実験して、学ぶ」ことです。これは、人々が実際に実験に頼るようになるまでは楽しいことです。」このようにCarlo氏は言います。
業界が成熟するにつれて、私たちは品質基準を引き上げ続けます。保守可能なソフトウェアを書くのは難しいです。企業にとっての課題は、開発者が変わるのが2年未満（知識の喪失！）であり、経験豊富な開発者がある時にコーディングをやめるときです。将来的には、メンテナンスするプログラムが増えるにつれて、このトピックへの関心が高まるでしょう。
技術的負債が多い場合は、次の3つの手順で状況を改善できます。
-
エンジニアリングチームに技術的負債を積極的に特定してもらいます。まず見えるようにしてから、取り組みを開始できます。
-
ビジネス用語を使って、技術者でない利害関係者と話します。そのために技術的負債に対処するということではなく、機能をより早く提供したいからです。多くの例があり、例えば「TTM（Time-To-Market）を短くしたい」、「コードの品質に時間を費やせば離職を低減できる」があります。事実に基づいて実際の数値を取得できる場合はボーナスポイントとなります。お金に結び付けると、追加のボーナスポイントとなります。例えば「過去3か月で、開発時間の42％をバグ修正に費やし、100万ドルの費用がかかりました」。
-
このコミュニティに参加して、同じ取り組みをしている人たちと知識を交換してください。
過去数年間で、開発者ファーストの新しいツールが爆発的に増えています。同時に、開発者が強くなってきています。特にお気に入りのツールの選択においてです。
企業は、技術的負債に積極的かつ継続的に対処することを目指す必要があります。これを行う唯一の方法はリファクタリングです。アジャイル組織は常に学習し、進化しています。コードベースの継続的な改善に投資しない場合、コードは静的なままであり、数日のうちに多額の負債を負うことになります。
継続的なコードベースの改善に投資することで、バグの減少、ダウンタイムの減少、サポートリクエストの減少、予測可能性とデリバリの高速化、エンジニアの満足度（組織にとどまる）向上につながります。
「技術的負債が、ビジネスの利害関係者には見えない開発者の問題ということでなく、顧客とビジネスにより多くの価値を提供するのに役立つ重要なビジネスの前提条件になることを願っています」とDalmijn氏は言っています。
見えない技術的負債の例を紹介します。あるテクノロジー会社は、さまざまな開発チームを再構築するための市場を組織化しました。誰もがどのチームで働きたいかを決めることができました。誰も取り組みたくないチームが1つありました。人が理由ではありませんでした。そのチームは、技術的負債のあるレガシーシステムに取り組んでいました。
同社は、開発者にとって、たくさんの技術的負債を抱えるシステムを持つこのチームで作業することをより魅力的にするために、プレミアムを支払うことにしました。ようやく、そのチームに参加する人の準備ができました。その結果、技術的負債を修正する明確なビジネスケースが生まれました。技術的負債が目に見え、金銭的価値がありました。突然、それに対処することが優先事項になりました。以前は、それがビジネスと開発者のやる気に同じ悪影響を及ぼしたとしても、誰もそれを本当に気に留めませんでした。
開発者はすでに気にかけています。ようやく、他の人にもそれを気にかけてもらう時が来ました。
著者について
Alex Omeyer氏はStepsizeの共同創設者兼CEOです。エンジニアリングチームが技術的負債を管理するためのSaaSコラボレーションツールを提供する。Omeyer氏は、ほとんどの時間を、技術的負債の対処方法について世界最高のソフトウェア開発チームと話すことに費やしています。
Nicolas Carlo氏は、コミュニティとメンテナンス可能なソフトウェアの構築が大好きなWeb開発者です。彼は「Software Crafters Montréal」ミートアップを開催し、VS Code拡張機能を開発し、Understanding Legacy Code blogブログでレガシーコードに取り組むためのヒントとコツを共有しています。
Maarten Dalmijn氏は、Rodeoの製品責任者、Scrumの製品管理のトップライター、Serious Scrumのアンバサダー兼編集者、Agile Product Managementブログのライターです。