技術負債について考えてみた。
お久しぶりです。Think 木下です。 はい。
今日はふと技術負債について考えたので、書きます。
技術負債とは
行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である
最初のコードを出荷することは、借金をしに行くことと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる
by wiki
負債とは
一般用語としての「負債」は、他人からお金や物資を借りることであり、また借りた金銭や物資のことである。なかでも金銭を借りることや、借りた金銭のことは「借金」と呼ばれている。
「借りる」というのは、将来的に返すという約束のもとに他人の何かを使用することを意味している。将来的に返す約束があるので、法律上は債務に分類される。
by wiki
技術負債は、そもそも何を借りるの？
- お金？
- 技術？
- 人？
- 時間？
んーどうも技術負債とはいうが、何か借りるイメージではないな。
どちらかというと、費用対効果の認識がずれているだけだと思う。
費用対効果の認識がずれているだけだと思う理由
例えば
- すぐに手に入るけど、壊れやすい商品
- 時間はかかるけど、壊れにくい商品
があるとする。
よくあるパターンは、1.を買って壊れたのに使っている。
- もちろん、壊れているから直してから、使う必要がある。
- もちろん、時間がかかる。
- もちろん、毎回直す必要があるから、モチベーションさがる。
でも、これって当たり前だよね。
だって、1.を選んだ時点でわかりきっている。
それなのに、対策もせずに、見ないふりをしてきたことが良くないと思う。
じゃーどうするべきか
1. 先のことを想定しておく。
- 壊れた場合、同じ商品を買う
- 壊れた場合、壊れにくい商品に買い替える
- 壊れないように、メンテナンスする
- 壊れないように、壊れにくいように改修する
2. 現状を考えて対策を打つべき
- 同じ商品があるか
- 代わりとなる、より耐久性のある商品があるか
- メンテナンス、改修する時間はあるか
システム的な話になると、同じ商品、代わりとなる商品は、ほぼほぼない（見えない部分も含めて。ブランドとか）
そうなると、
- メンテナンスする
- 壊れないように、壊れにくいように改修する
3. まとめると
- 壊れて諦めるか
- 壊れにくいものを買うか、作るか
- 優秀なメンテナンス、改修チームを作るか、雇うか
だと思う。
はじめから検討しておく点としては、
- 使用する期間を決める（１年くらいなのか、１０、２０年使うのか）
- しっかりと設計できるか、作り込まれている製品を買えるか
- 技術レベルの高い人を雇えるか
になるのかな。
しかし、昨今のビジネスのスピード、コストを考えると、そう出来ない場合は多々ある。
いい加減でも先にリリースするメリットがあるのであれば、それはするべきであって、間違いではないと思う。
しかし、テスト自動化などの導入が後からでも簡易に可能かは、検討しておくべき
- ユニットテスト、E2Eなどのテストが、簡易に導入できるか、もしくは、導入されているか
- 機能を全て把握しているか
1.は、さぁ導入しようとなったときに、独自フレームワークなどの理由で、導入が難しい場合。 かなりのコストがかかり、現状のシステムにも影響がある可能性が高いため、導入は容易ではない。
2.は、機能の洗い出しからはじめることになり、コードから逆算して見つけることや、色々な人に確認する必要があり、かなりのコストが発生する。
この２点だけおさえておけば、重要度や、関係性を洗い出し、部分的にすぐにテストが導入可能で、徐々に改善していくことは可能だと思う。
システムにコストがかかるだけではなく、人という財産まで失う可能性もあるので、しっかりと検討しておくべき部分だと思う。
既に手遅れな場合は、焦らず専用チームつくって徐々にやって行くしか無いと思う。
なんせ、武器も何も持たず、未知の樹海に突っ込む様なもので、PDCAを回して、徐々に進まないと、人がどんどん消えていく。
自分はお金をもらっても、未知の樹海へは入っていきたくないな〜
お宝が埋まってたら行くかもしれないがw
と思った今日この頃でした。
今後は１週間に１記事くらい書いていきたいと思ってます。
