プログラミングにおける悪いカルマ。技術的負債とは何か、そしてそれを解決する方法

技術的負債。専門分野で積極的に取り組んでいるほとんどのプログラマーは、この用語に対処する必要があります。多くの人にとって、その言及は頭痛を引き起こすだけでなく、プロジェクトに取り組んでいるときに技術的負債に対処するたびに現れる体の他の部分の不快感さえ引き起こす可能性があります。 そこで、今日は技術的負債 (TD) について説明します。技術的負債とは何なのか、どのように現れるのか、技術的負債にはどのような種類があるのか​​、そしてそれを効果的に管理する方法について説明します。

技術的負債とは何ですか?

ただし、まず用語を理解しましょう。技術的負債とは、ソフトウェア開発における品質の軽視によってソフトウェア コードまたはアーキテクチャに蓄積され、将来的に追加の人件費を引き起こす問題を表すソフトウェア エンジニアリングの比喩です。これは、Wikipediaによる技術的負債の定義です。簡単に言うと、技術的負債は、開発において単純化された短期的なソリューションを適用した結果であり、その後の改良のための金銭と時間のコストが（もちろん負債が「返済」されない限り）増大し続けることになります。コードを書き直すか、製品を既存の形式で維持します。普通のプログラマーの世界では、技術的負債は負のカルマの一種であり、やる気を失わせるものであり、悪いコード、松葉杖の使用、および「一時的な」（しかし実際はそれほどではない）解決策への報復として来る悲しみの原因です。つまり、将来的に問題が複雑に絡み合うことを犠牲にして、短期的な問題を解決し、開発をスピードアップするのに役立ちます。IT 業界では、技術的負債はかなり深刻な問題です。最近のある調査によると、世界中の企業は、不正なコードの修正だけで年間 850 億ドル以上を費やしています。合計で年間約 3,000 億ドルが、時代遅れのシステムや「悪い」ソフトウェアのサポートに関連するプロジェクトに費やされています。これらは重要な数字です。研究者らは、技術的負債とその結果に取り組むすべての開発者の努力が「正しい」開発に再び焦点を当てた場合、今後 10 年間で世界の GDP が約 3 兆ドル増加すると推定しています。

出現理由

たとえば、事業開発（またはスタートアップの立ち上げ）のためにローンを組む場合、経済的負債に陥ることがプラスになる可能性があるのと同様に、技術的負債は必ずしも悪いことではないことを理解する必要があります。TD の場合、これは、成功を評価して市場ニーズを調査したり、新しいニッチ市場を迅速に獲得したりするために、新しい製品やサービスを迅速かつ頻繁にリリースする必要がある急速に成長している企業にとっては許容されます。ただし、金融負債と同様に、技術的負債にも注意し、その管理方法を知っておく必要があります。そうしないと、重大な問題が発生する可能性があります。ソフトウェア製品の開発中に蓄積された技術的負債が多ければ多いほど、会社への影響が大きくなり、新しいリリースのリリースが遅れ、そのような負債の「維持」を担当する一般のプログラマーの士気が低下し、コストが増加する可能性があります。最終的には会社を破壊することさえあります。技術的負債が発生する理由は、製品をできるだけ早く完成させたい、または新しいリリースでユーザーを喜ばせたいという崇高な欲求に加えて、多くの場合、不十分な製品管理、非現実的な納期やリソースの制限、そしてもちろんコーダーの怠惰です。資格の低さと主要な開発原則の理解の欠如も相まって、債務の増加に寄与することがよくあります。開発者自身は技術的負債の存在と増え続けることを十分に認識しているものの、それを変更する十分な権限がないか、そのような問題の存在とその解決の重要性に関する情報を経営陣に伝えることができないことがよくあります。

分類

上で述べたように、技術的負債にはさまざまな形があり、その定義自体は単なる比喩であるため、技術的負債の種類ごとに異なる方法で分類できます。特に、技術的負債に関する世界の専門家の一人とみなされているTapadの共同創設者兼CTOであるダグ・リオデン氏は、年次CTOサミットイベントでの講演の中で、技術的負債を3つの主要なタイプに分けることを提案した。

1. 意図的な技術的負債。

   これは、開発者が意図的に最適なソリューションではないソリューションを選択する場合に発生します。その理由は、その方が実装が簡単かつ迅速であり、その結果、新製品を迅速に市場にリリースするのに役立つからです。

   「開発時間を短縮するために、意図的に技術的負債を負うこともあります。この方法を選択する場合は、開発中に節約できる時間だけでなく、後でそのような負債を「返済」するために費やす必要がある時間も考慮してください。また、そのような決定が将来他の機能の立ち上げを遅らせることは避けられないことを利害関係者（会社の経営陣）が認識していることを確認してください」とダグ・ジョッデン氏は述べた。

   この種の技術的負債を解決するためのアプローチ

   専門家は、このような技術的負債が失われ、プロジェクト構造の不可欠な部分になる前に、そのようなケースに戻って修正するために、慎重に文書化するようアドバイスしています。

2. 偶発的なもの、または古いプロジェクト アーキテクチャから生じる技術的負債。

   また、プロジェクト アーキテクチャの作成段階でのエラーや欠陥により、時間の経過とともに技術的負債が発生することがよくあります。システムが進化し、ソフトウェア要件が変化するにつれて、設計上の誤りがより明らかになり、新機能の追加にはより多くの時間と労力が必要になります。ここでは、初期プロジェクトのアーキテクチャの品質が重要な役割を果たします。シンプルかつ機能的でなければなりません。そうすれば、変更への適応が容易になります。

   この種の技術的負債を解決するためのアプローチ

   この種の技術的負債が蓄積し、臨界レベルを超えないようにするために、Dag Llodden 氏は、システムが安定した状態にある期間に、定期的に (約 2 年に 1 回) リファクタリングを行うことを推奨しています。チームリーダーとプロダクトマネージャーは、アーキテクチャや頻繁に変化するプロジェクトの要件によって生じるこの種の技術的負債を「返済」するために時間を割り当てる必要があります。

3. 時間の経過とともに生じる技術的負債。

   専門家はこうした技術的負債を「長期にわたって腐り続けている」と呼んでいる。多くの変更が絶えず追加されるため、コンポーネントまたはシステムが徐々に複雑になるにつれて、時間の経過とともに蓄積されます。異なる人が異なる段階でシステムに取り組み、元のアーキテクチャを完全に理解していない場合、この問題はさらに悪化することがよくあります。

   この種の技術的負債を解決するためのアプローチ

   これは、定期的なリファクタリングを通じて継続的に回避するように努めるべき 3 種類の技術的負債のうちの唯一の 1 つである、と専門家は言います。理想的には、開発チームは、たとえそれがもともと他の人によって作成されたものであっても、自分たちが取り組んでいるシステムのアーキテクチャを徹底的に理解するために時間を費やす必要があります。このシステムを理解すれば、プロジェクトを「腐る」段階に至らせることなく、悪いコードを徐々に改善して修正できるようになります。

技術的負債管理ソリューション

技術的負債を効果的に管理するためのオプションは数多くありますが、技術的負債はほぼすべての開発に不可欠な部分であり、技術的負債を無視する企業は後の段階で常に問題に直面するため、専門家全員がこれを実行する必要があることに同意しています。ここでは、開発チームの技術的負債を管理するための効果的なソリューションとアプローチをいくつか紹介します。

1. 作業時間の一定の割合を技術的負債の処理に割り当てます。

   技術的負債の問題は、意図的に行わない限り、それを解消するための作業を行う時間が決してないことです (優先度の高いタスクが常に存在するため)。したがって、適切な解決策は、作業時間の一定の割合 (約 20 ～ 25%) をこれらの目的に割り当てることです。

   これはさまざまな方法で実行できます。

2. 週に 1 日、技術的負債に取り組む

   週に 1 日をチーム全体として TD を排除する作業に割り当てると、これはちょうど総作業時間の約 20% になります。一部のチームでは、このアプローチは問題なく機能し、チーム全体がその曜日に残りの開発時間を悩ませる問題の解決に取り組むため、士気も向上すると言われています。

3. 4 つおきのタスクを TD の作業に充てる

   このシステムは、プロジェクトの作業を、完了までの時間と労力がほぼ等しいタスクに分割する傾向があるチームに適しています。4 つのタスクのうち 1 つが TD の「支払い」に充てられるとすると、これには総開発時間の約 4 分の 1 がかかることになります。そして、このアプローチを原則として導入することで、プログラマーが技術的負債を「後回し」にすることがなくなります。

4. 移行期の役割

   技術的負債を排除するという問題に対するもう 1 つのアプローチは、異なるチーム メンバーを特定のタスクに順番に割り当てて、時には最も快適ではない作業をチーム メンバー間で均等に分配することです。TD を「集める」ために割り当てられる開発者の数はさまざまです。4 ～ 5 人のチームの場合は 1 人で十分ですが、大規模なチームの場合は 2 人または 3 人を割り当てることができます。しかし本質は同じで、全リソースと工数の約 20 ～ 25% を TD の作業に費やす必要があります。

5. ボーイスカウトのルール。

   ボーイスカウトのルールは、キャンプ場（テント場）を到着時よりも常に良い状態にしておくこと、つまり、残されていないゴミも片づけることです。海外のプログラマーが発見したように、この原則は技術的負債の管理にも最適です。このルールによれば、チームメンバー全員は、何らかの形で TD に遭遇するたびに、TD を修正しなければなりません。もちろん、TD の修正にかかる時間が総時間リソースの「妥当な」25 ～ 30% を超えないよう、このルールは賢明に適用する必要があります。

6. 「高価な」技術的負債を優先する

   専門家は一般に、技術的負債の重要性は異なる可能性があることを忘れないよう推奨しています。すべての種類の技術的負債が直ちに解決する必要があるわけではないため、さまざまな種類の技術的負債を分類し、それに応じて作業の優先順位を付けることに取り組むことが重要です。簡単に言うと、まず第一に、基本アーキテクチャの一部である製品開発の速度に直接影響を与える負債を解消する必要があります。このような借金は、雪だるま式に新たな借金が増える可能性があるため、最も危険です。

結論

最後に、ソフトウェア開発において技術的負債を避けて行うことは不可能であることをもう一度強調したいと思います。なぜなら、技術的負債は開発の不可欠な部分だからです。しかし、その技術的な性質にもかかわらず、TD は依然として開発における人的要因によって引き起こされる問題です。完全にそれなしでやっていくことはできませんが、「クリーンな」コードを記述し、可能な限り責任を持って専門的に開発プロセスに取り組む場合、技術的負債の量を可能な限り減らすことができます。これが私たちが皆さんに望むことです！