技術的負債のパターンと悪影響・原因・返却方法について考える

先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。

いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした

— 趣味はマリンスポーツです (@hitode909) 2018年3月27日技術的負債について - hitode909の日記それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。思いついたパターンは3つ。 ●変更困難パターン ●期限付き返却パターン ●ヒヤリハットパターン他にあったり、ここはミスってるとかあったり、こういうことについて書かれている本があったら教えてください。あとたぶんまだまだ分かっていない分野だと思うので、色んな人と一緒に考えていきたい。

変更困難パターン

次にその部分を触った時に負債の影響が一気に襲いかかり、その部分に新しい仕様を追加しようにも非常に時間がかかるという種類の負債。現実の資金の負債と違い、その部分に触らないと負債の影響が現れないというのが難しいところ。触らないと負債の影響が現れないので、特に後回しにされやすいパターン。どういう悪影響があるか ●ある部分の変更容易性が損なわれ、新機能や改善により時間がかかってしまう ●変更が容易ではないので、その部分に新機能を追加しないようにするためのネガティブな圧力が発生する。これにより事業的に必要でも、エンジニアからnoが起こることが多い ●エンジニア以外から見えにくい負債なので、他職種との対立が生まれやすいそれがなぜ起こるのか ●リファクタリングが行われず、同じ機能の実装が何度も変更された ●同じ機能の実装を、色んな人が触りすぎた。そしてリファクタリングが行われていない ●初めの設計がミスりまくっていたどう返却するか

一気に返すのは難しいので、新しい機能を実装を作る時はいつもリファクタリング期間込で見積もりを立て、機能を作る前に先にリファクタリングする
一旦その部分のことは一人の人が責任を持つようにして、その実装部分のタスクを特定の人に集中させる。それでコードの整理がある程度ついたら他の人に知見を共有する
あまり変更の必要がないようなあまり重要ではない部分だったらいっその事放置する

期限付き返却パターン

OSや言語などのLong-term supportや、外部サービスのAPIのdeprecatedなどの外部要因を原因として起こり、期限がある程度決まっているというパターン。難しいのは、Long-term supportが切れたりしても、ただちにサービスが動かなくなるみたいな問題が起こらないということ。このため、他の新機能作成タスクを優先してしまいがち。どういう悪影響があるか ●ある日に突然動かなくなる可能性がある ●期限が過ぎると ●脆弱性が発見された時に直されないみたいなことがある ●速度向上や使い勝手の向上など、新機能が利用できなくなるそれがなぜ起こるのか ●時間経過などによる外部要因 ●コードの中身はあまり関係ないどう返却するか

期限と、その期限が過ぎることによるデメリットが、どちらかといえば見えやすい。そのため先に調査だけすることで新機能作成との優先度を比較がしやすい。簡単な調査を行い、実際のプロダクトバックログに乗せてしまうのが良い
可能ならの返却期限(Long-term supportなどの期限)と、絶対の返却期限(これを過ぎるとサービスが動かなくなる)の二つを可視化して、絶対の返却期限は守れるようにしておく

ヒヤリハットパターン

障害にまでは至ってないけど、何かの拍子に障害が起こる可能性があるパターン。エラーログにまずそうなログが出ているなど、なんらかの傾向が見られたりする。工場とかではヒヤリハットとか呼ばれてたりする？難しいのは、まだ具体的な問題が起こっていないことが多いこと。どういう悪影響があるか ●何かの拍子にユーザー影響のある障害が起こったりする ●データが消えるなど、クリティカルな影響が起こることもあるそれがなぜ起こるのか ●サービスが成長しデータ量が多くなるなどによって、元々の設計では対応できなくなる ●依存している外部要因の変化によって起こる ●確率的に発生するバグを生じるコードをもともと入れてしまっているどう返却するか

ヒヤリハット事例がn件起こったら対応するなどのルールを決める
ヒヤリハット事例が起きた時に簡単な調査は行う

まとめ

今回は技術的負債のパターンと悪影響・原因・返却方法についていろいろ考えてみたことを書いてみた。この三つのパターンをあげてみたけど、実際にはパターンが組み合わさったりしてより複雑になっていることも多い。
例えば

JSのフレームワークのバージョンが古くなっていて、Long-term supportの期限が切れそう
サポートが切れた時に、ブラウザのdeprecatedの機能を使っていた部分がfixされないこともありそうで、どこかで動かなくなりそうという期限付きの場合がある
またJSのフレームワークが古いため、開発速度のスピードが下がり(変更が容易でなくなり)、変更困難パターンも包含している

みたいなこととか？

これが正解だとも思えていないけど、技術的負債にパターンを見出し、それぞれの返却方法について深掘りしていくという考え方は良いような気がする。なので他の人はどういうパターンを見出しているのかとかを聞いてみたい。

2018/03/29 21:30追記

Twitterでさらに議論できて面白かったので、こっちも貼っておきます。この議論の中で僕が言いたかったのは、 ●負債パターンによって、起こる悪影響はぜんぜん違うだろう ●しかし今は悪影響自体も分離できていないように思える ●悪影響を分離し定量化し、その負債の返済コストを定量化すれば、他のタスクと比較可能になる ●ただし、悪影響の中で観測しづらいものもある。例えば﹁次にそこを触る時にかかる時間﹂とか。その場合は別指標に変換もしくは分割できると良いのかもしれないという感じです。

技術的負債、グッドパターンとアンチパターンに分けて考えてみたい気がする。計画的に借り入れられて、そのおかげでビジネスが成功して、計画的に返済できるのはどういうときなのかカタログ化したい https://t.co/5eZhXfL4Ma