技術リーダー、プロジェクトマネージャー、管理職は、ソフトウェア開発者に多くの時間を与えることで技術的負債を防ぐことができる。さらに、チームがコードを改善できるように、余剰時間やリファクタリングスプリントを計画することができるとNedelcho Nikolov氏は主張する。技術的負債に優先順位をつけるために、開発チームは、今投資すればどれだけの時間を節約できるか、今技術的負債を返済しなければ将来ソフトウェアがどれだけ複雑になるかを示すことができる。
Nedelcho Nikolov氏は、DEV Challenge Accepted 2023で、技術的負債に対処する経験を共有した。
Nikolov氏は、技術的負債とは多くの場合、期限に間に合わせるためにコードを急がなければならず、適切な作業時間がないことが原因だと語った。妥協したこともあり、大抵の場合、単体テストか、本番稼動しているのに誰もその方法と理由を知らないような、ひどい書き方をしたコードであると彼は付け加えた。
技術的負債のもう一つの原因は、Nikolov氏が説明したように、チームがまだ新しく、コーディング規約がまだ整備されていないことかもしれない。
結成されたばかりのチームが真新しいプロジェクトに取り組んでいたので、誰もが自分のスタイルでコードを書いていました。
技術リーダー、プロジェクトマネージャー、管理職は、開発者にすべてのテストと良いコードを書く時間を与えることで、技術的負債を防ぐことができるとNikolov氏は言う。また、プロジェクトに余剰時間を計画することで、大慌てで物事を進めた後に整理整頓に費やせるようにしたり、チームにリファクタリングスプリントを数回持たせ、コードを改善する時間を取らせることもできる。
技術的負債の優先順位付けは難しい。なぜなら、お金をもたらさないことに時間を割くよう、上の人間を説得しなければならないからだ、とNikolov氏は主張した。Nikolov氏は、今投資すれば後々どれだけの時間を節約できるのか、将来的にどれだけ複雑になるのかなど、いくつかの数字を会話に入れることを提案した。
これは、コードが問題なく書かれていて負債がなくそしてコードが現状のままである場合、開発者からの見積もりで示すことができます。通常、利害関係者は数字に興味を持つので、これが最良のアプローチかもしれないです。
技術的負債に対処するために、Nikolov氏は、チームが負債を返済するためにスプリントごとに時間を投資すること、または、少なくともチームメンバーが自分のタスクをこなし、修正またはリファクタリングのためにパイプラインに残っているものを見たときに、その時間を投資することを提案した。これは簡単なことで、今すぐ時間を投資して実行すればいい、と彼は提案した。
スプリント全体を修正だけに費やすという別のアプローチもある。とNikolov氏は説明した。
あるプロジェクトで、新しいチームが作業していたが、コード品質に妥協しながらも予定通りに終了しました。終了後、私たちは数スプリントのすべてリファクタリングし、品質を戻すことに費やしました。こうすることで負債を返済でき、ナビゲートしやすく、新しい機能を追加しやすい、見栄えの良いコードベースを手に入れることができました。
時間が経つにつれて、ますます難しくなるので負債を返済するためにできる限り時間を割くことだとNikolov氏は付け加えた。技術的負債を恐れる必要はない。それは必要悪である。技術的負債があるからこそ、プロジェクトやタスクを期限内に終わらせることができるのだ。しかし、その後にできるだけ早く返済し、大混乱に陥らないようにしなければならない。
InfoQは、技術的負債への対処についてNedelcho Nikolov氏にインタビューを行った。
InfoQ: 技術的負債を修復するコストと利益について詳細な見積もりができない場合、優先順位をつける別の方法はあるのだろうか?
Nedelcho Nikolov氏:別の良いアプローチは、インパクトエフォートマトリクスを使うことである。その中で、各タスクを以下の方法で採点することができる。
簡単にできて、仕事に大きな影響を与える - クイックウィン
やるのは簡単だが、コードの変更されない部分であったり、近い将来誰も変更しないような機能であったりするため、まり役には立たない - タイムフィルイン
難しい/時間がかかるが、大きな影響がある - メジャープロジェクト
実現が難しく、プロジェクトへの影響もない - マネーピット
上記のスコアを念頭に置けば、今すぐ返済すべき債務と、後回しにしてもよい債務に簡単に優先順位をつけることができる。
InfoQ: 時間をかけて蓄積された技術的負債が多い場合はどうすればいいのか?
Nikolov氏:技術的負債がたまりすぎて、それを処理するのが本当に難しくなったら、その時点でプロジェクト全体を最初からやり直すしかないです。利害関係者を説得するのは難しいが、不可能ではないです。資金を投入したり新しい機能を追加したりするのではなく、すでにあるものをやり直すことに時間を費やしたいのだからです。
私のチームでもそのようなプロジェクトに遭遇した;フレームワークがない15年前のPHPアプリケーションで、PHP、HTML、JSのコードが1つのファイルに混在していました。利害関係者は、レスポンシブデザインによる完全な再設計を望んでいました。適切な説明と見積もりによって、プロジェクト全体をゼロから始めるよう説得することができました。今、私たちはLaravelとVueJSのフロントエンドで動作するモダンなPHPアプリケーションを持っており、Tailwind CSSと提携しています。もちろん、時間的な制約があったため、新たな技術的負債を抱えることになったが、スプリントごとに少しずつ返済しています。