Googleの技術的負債取り組みを深掘り: 定義、測定、そして管理

ずっと読まなければと思っていた、「技術的負債の定義、測定、管理」というGoogleの研究者が発表したドキュメントにようやく目を通しました。

このドキュメントは近年、Googleは技術的負債と向き合い、その管理方法を見直す活動を積極的に進めています。ソフトウェアエンジニアリングの業界ではよく「技術的負債がプロダクトの成長を阻害する」と言いますし、それを体験することも多いのですが、技術的負債をどのように捉え、体系的にそれを評価することは難しいように思います。このドキュメントでは、それらのアプローチやとりうる施策について紹介されていましたので、簡単にとりまとめて紹介します。

技術的負債の定義

技術的負債とは、エンジニアリングにおいて一時的な解決策や短期的な判断によって生じた、長期的な技術的な問題や課題のことを指す、と定義します。具体的には、将来の拡張性を犠牲にしたコードの書き方、古くなった技術の継続的な使用、不足しているドキュメンテーションなどが挙げられます。

Googleでは、四半期ごとに行われるエンジニアの満足度調査を基に、技術的負債とその影響を明らかにしようとしました。この調査により、多くのエンジニアが技術負債によって作業が阻害されていることが明らかになりました。

技術的負債の測定

この、四半期ごとのエンジニアの満足度調査により、エンジニアが技術的負債の影響をどの程度感じているのかを評価しました。この調査を通じて、エンジニアが直面する技術的負債の具体的なタイプや原因を明らかにしています。

その中で、技術の移行やコードの品質低下、チームの専門知識の不足など、10の主要な技術的負債カテゴリを整理しました。

1. 移行が必要または進行中
   スケールの必要性、依存関係の削減、または廃止予定の技術を避けるためなどが動機となることがある。

2. プロジェクトとAPI（アプリケーションプログラミングインターフェース）のドキュメント
   プロジェクトの動作方法の情報が見つからない、欠落している、または不完全であるか、APIや継承したコードのドキュメントを含む場合。

3. テスト
   テストの品質やカバレッジが不足しており、テストが欠落している、テストデータが不適切であるため、フラジリティ、不安定なテスト、または多数のロールバックが発生する。

4. コードの品質
   プロジェクトのアーキテクチャやコードが適切に設計されていない。急いで作成されたり、プロトタイプやデモだったりする。

5. 死んでいる、または放棄されたコード
   コードや機能、プロジェクトが置き換えられたり、上書きされたりしたが、削除されなかった。

6. コードの劣化
   コードベースが劣化したり、時間とともに変わる標準に追いついていない。コードはメンテナンスモードで、リファクタリングやアップデートが必要であるかもしれない。

7. チームが必要な専門知識を持っていない
   スタッフの欠員や人事の変動、または継承された孤立したコードやプロジェクトが原因である可能性がある。

8. 依存関係
   依存関係が不安定で、急速に変化するか、ロールバックを引き起こす。

9. 移行が不適切に実行されたり放棄されたりした
   これにより、2つのバージョンの維持が必要となった可能性がある。

10. リリースプロセス
    製品のロールアウトや監視が更新、移行、または維持される必要がある。

この中で、特に「1. 移行が必要または進行中」と「2. プロジェクトやAPIのドキュメント」は、多くのエンジニアにとって主要な障壁として挙げられています。

技術的負債の管理

技術的負債を管理する、という考え方は、ソフトウェア開発の持続的な品質を維持するための重要です。Googleは、技術的負債の管理を推進するための具体的なフレームワークやモデルを導入しています。

彼らの取り組みには、技術的負債のインベントリの作成、影響の評価、役割の明確化などのステップが含まれています。また、継続的な教育やトレーニング、コミュニティのフォーラムなど、知識の共有やベストプラクティスの普及にも力を入れています。

具体的には、技術トークシリーズや自己学習コースなどの教育プログラムを通じて、エンジニアのスキルアップや意識の向上を促進しています。さらに、技術的負債の特定や管理をサポートするツールも開発されています。これにより、テストカバレッジの不足や古いドキュメント、非推奨の依存関係などの問題を早期に検出し、対処することが可能となっています。

まとめ

技術的負債の認識と管理は、ソフトウェア開発を効率よく、継続して行うために重要な要素となります。Googleの取り組みを参考に、技術的負債における重要なプロセスをざっくりまとめてみます。

• 継続的な評価
  Googleは、エンジニアリングサーベイを通じて、技術的負債の影響を定期的に評価しています。これにより、組織内の実際の状況を正確に把握し、適切な対策を講じることができます。

• オープンコミュニケーション
  技術的負債の問題を共有し、エンジニア同士で知識やベストプラクティスを交換することは、問題の早期発見と解決に役立ちます。

• 具体的なツールとフレームワークの導入
  技術的負債を分類し、特定・評価・管理するためのツールやフレームワークの導入は、組織全体での技術的負債の取り組む、重要な枠組みとなります。

• 教育とトレーニング
  継続的な教育とトレーニングは、エンジニアのスキルや意識を向上させて、技術的負債に対する認識や対応能力を高めることができます。

最後に、技術的負債の取り組みは、組織による継続的な取り組みが必要です。組織のマネージャーやリーダーは、技術的負債の影響を最小限に抑え、持続可能な開発を推進するための戦略やアクションを継続的に見直し、更新する必要があるでしょう。