※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
すべてのコードやライブラリ自体が技術的負債である / 高利率な技術と低利率な技術 - Lambdaカクテル
意訳+要約
すべてのコードやライブラリ自体が技術的負債である / 高利率な技術と低利率な技術
- 技術的負債の普遍性: すべてのコードやライブラリは時間と共に技術的負債になる。
- 負債の本質: 負債をゼロにすることは不可能。プロダクトが存在する限り、負債の「利息」を払い続ける必要がある。
- 利率の変動: 技術選択によって利率は変わる。フロントエンドフレームワークやビルドパイプラインは高利率、C言語やSQLは低利率。
- 技術的負債の管理:
- ドキュメンテーション: 負債の利率を下げる。
- 良いコーディング作法: 利率を下げる。
- 一般的な使用技術: 多くの人が使う技術はリスクが分散され、利率が下がる。
詳細な考察
技術と負債の関係:
- 全ての技術が負債を抱えており、選択肢によってその負債の利率が変わる。
- プロダクトは高利率技術と低利率技術のバランスで成り立つ。
高利率技術の特徴:
- 最新技術の採用は便利だが、頻繁な更新や移行が必要となり、負債が急増するリスクがある。
低利率技術の特徴:
- 変化が少なく、安定しているが、即時のビジネス利益には結びつきにくい。
実際の利率調整方法:
- 高利率技術の選択肢には他の部分で利率を下げる対策を取る。
- ドキュメント整備や、コーディングスタイルの統一、一般的な技術の採用でリスクを分散。
結論
技術的負債を完全に避けることは不可能だが、その利率を管理することで、プロダクトの持続的な成長と安定を図ることが可能。適切な技術選択と組み合わせにより、負債を最小限に抑える戦略が求められる。
ChatGPTへのQA
Ｑ：どうやって可視化するのでしょうか？
技術的負債の可視化には、以下の方法が有効です：
技術的負債マトリックス:
- 技術の利率（高・低）と影響範囲（広・狭）で分類し、各技術の負債レベルを視覚化。
グラフとチャート:
- 負債の増減を時間軸で示す折れ線グラフや、負債の割合を示す円グラフなど。
ダッシュボードツール:
- JIRAやConfluenceなどのプロジェクト管理ツールを使って、技術的負債の状況をリアルタイムで追跡。
技術スタック図:
- 現在の技術スタックを視覚的に示し、各技術の負債リスクを色分け。
Ｑ：利率の算出はどうすればいいでしょうか？
技術的負債の利率を算出する方法は次の通りです：
ステップ
技術要素の特定:
- 使用している技術スタックの各要素をリストアップ。
評価基準の設定:
- 更新頻度、メンテナンスの容易さ、学習曲線、コミュニティのサポートなどの基準を設定。
スコアリング:
- 各技術要素に対して、設定した基準に基づきスコアをつける（例えば、1-5の範囲）。
利率計算:
- スコアを合計し、技術ごとの平均スコアを算出。
- 平均スコアが高いほど、利率が高い技術とみなす。
具体例
- 技術要素: フロントエンドフレームワーク（React）、バックエンド（Node.js）、データベース（PostgreSQL）など。
- 評価基準:
- 更新頻度：1（低）- 5（高）
- メンテナンスの容易さ：1（容易）- 5（困難）
- 学習曲線：1（平易）- 5（難解）
- コミュニティサポート：1（少）- 5（多）
- スコアリング:
- React：更新頻度4、メンテナンス3、学習曲線3、コミュニティサポート5 → 合計15
- Node.js：更新頻度3、メンテナンス2、学習曲線2、コミュニティサポート4 → 合計11
- PostgreSQL：更新頻度2、メンテナンス1、学習曲線2、コミュニティサポート4 → 合計9
- 利率計算:※スコアの平均値の算出
- React：15/4 = 3.75
- Node.js：11/4 = 2.75
- PostgreSQL：9/4 = 2.25
このようにして、各技術要素の利率を定量的に評価し、比較することができます。
感想＋雑記
すべてのソース・ライブラリに負債はあるものとして定義することで、ソフトウェアの状態を見ることができるようになるということだろうか？
ChatGPTとどうやって利率を出すかやり取りして思ったけど、ソフトウェアの状態がわかりやすく表現できるようになった気がする。数値化されたポートフォリオみたいな感じになるなと。
問題は、利率の設定だな。評価基準とかは、どうしても塩梅があるから、明確な評価基準がないとブレそう。
今まで、負債は感覚的なもの・認識できた問題のこととして捉えてたから、数値化すると見え方が変わってくると感じた。
解決して終わりじゃなくて、負債との付き合い方が決めやすくなると思った。利率がこうだから、切り替えする/しない、バージョンアップする/しないの判断材料になるなと。
今までだと、SonarQubeとかでコードの評価はしてたけど、ライブラリの評価の視点は抜けてたなと振り返って思った。
