先日のランニング中に、The Changelog – Episode #425 State of the “log” 2020 を聞いてた。
Changelog の 2020年のエピソードの総まとめみたいな回だった。
その中で The Changelog – Episode #379 Good tech debt という面白そうなエピソードがあり元になった 3 Kinds of Good Tech Debt というブログを読んだ。

メインとなる考え方は、技術負債は常に悪く語られることが多いが負債 (借金) と考えたときに「車のローン」や「家のローン」など良い負債もあるのではないかというもの。

The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage? If we define tech debt as work that will have to be done in the future, we can track spending in terms of the time that will be spent on that future work. We can also “invest” time in work done now.

意図的な技術負債を将来の作業として先送りすることで、今の機能を動かすことができる。

Podcast 中では、例えば
「メールを送信する機能」を挙げてて、最初は for 文で回して CPU リソースが取られても良い。それによって「メールを送信する機能」をユーザーに試してもらってそもそも必要ないことがわかったり方向性が間違ってることがわかる。
当然、順調に成長すればいつかは Worker を使ったりしてうまくスケールさせる必要がある、しかしそれはそれが必要なときに対応すれば良い。

一時的には、完璧とは言えない (スケールしないことがわかってる) 実装を意図的に残す (借金する) ことで 「メールを送信する機能」を短い時間でユーザーが使えるまでに持っていくというリターンを得ることができるというような考え方が根幹にある。

さてさて Three Kinds of Good Tech Debt というくらいなので記事の中では、 3つのパターンが紹介されてる

Scaffolding

You never know until you try it, so I try to get my code into a real-world situation as quickly as possible. This usually means finding a way to make something useful with the risky parts before moving on to build the rest of the application.

最もリスクが高いコンポーネントに最初に取り組むべき。リスクが高いというのは、不確実だったり複雑だったりする箇所で、実際に実装してみるまで何が問題になるかわからないのでこの部分をまずは作る。

冒頭でも出たメール機能の実装の例が出てた

Squarespace Email Campaigns の Feature 実装時の話。
この時競合に勝つには、何よりも Email の編集画面が重要だった。
機能としては、大量のメールを送れる必要があったが、この時点ではその必要はなかった。
それよりもユーザーからの編集画面に対する Feedback が重要だった。

Scaffolding だとプロトタイプとかという捉え方をしてしまいそうだけれどここで言ってるのは、あくまでもプロダクションでプロダクションなんだけど、想像できてる限界がきてしまうということをリリースする前から知ってしまってる状態だと読み取った。

Scaffolding をうまく活用するためのいくつかのガイドラインも紹介されてた。
そのうち刺さったものを紹介する。

We understood the scaffolding’s limitations, and avoided using it in a situation where a failure would cause harm. We’d be going deeper into debt than expected if we spent time cleaning up errors caused by the scaffolding, so we were very intentional about the testing situations the scaffolding was used in.

現状の実装の限界を明確に理解している。
またそれを返済しないといけない状況も定義している点がよかった。

Stakeholders knew we were deliberately taking on debt. We bragged about these limitations with our stakeholders and users as if they were features—“Look at all the time we saved!”—and in the process made sure they knew we would need to invest time later to build the real email delivery system.

ステークホルダーに対して「技術負債を作ったので早く作れた、早く価値を出すことはビジネス的にwinであるはず。しかしいつか限界が来るのでその時になったら返済しないといけない」ということを理解してもらってた点もよかった。

Hardcoding Things

時には、コードの中にコンテンツや動的にいじる可能性があるものをハードコーディングしてしまうのはひとつの手である。 ここでも例があげられていた。

ダッシュボードに、季節のメッセージやコンテンツなどを表示するという機能があった。
これらを動的にエンジニアの工数をかけずに更新するには何かしらの CMS が必要だった。
最終的には CMS を作ることにはなったが、この時の実装では、YAMLにハードコーディングして CMS っぽい挙動をさせていた。 CMS を作るとなると本来バリデーションなども必要だがこれらは YAML に対するコードレビューで補完された。

当然、デメリットもあるのでそのメリット、デメリットを考慮して意図的にやることが大事。
またここでもいつ CMS を作ることにするかということを定義しておくことが大事になる。

Not Fixing All the Edge Cases

全てのエッジケースを要求通り完璧に実装する必要がない時もある。

ユーザーが 10個までアイテムを作成できて、10個以上は許容しないという機能があった。
このとき Squarespace は、 NoSql を分散DB で使ってたので 例えばアイテムが9個のときに二重で write が走ってアイテムが11個になってしまうケースが考えられた。 しかし、11個になることは他の部分に影響もなく大量の Lock 機構を書くくらいなら放置した方がよかった。

ここで大事なのは、放置はするけれど、予想していたよりも 11個になってしまうケースが発生していないかということはモニタリングしていたという点。
その結果ほとんどの場合でそういうケースが発生しなかったのでこの仕様は今も残っているらしい。

まとめ

Good Tech Debt Is Intentional

The key is to be intentional about what you invest time in and aware of the costs you’re taking on

意図的に技術負債を活用して早く進むために使えという話で大変よかった。

また最後に

Build things to be easy to throw away and replace; it’ll make your code more modular.

モジュール性を高くして、返しやすいことも重要という話もよかった。

全体として、Tech Debt は意図的に、何か得るために前借りをしていて、いつ返さないといけないということを意識することが大事と書かれててめちゃくちゃ共感した。