https://nealle-dev.hatenablog.com/entry/2024/12/18/01

こんにちは！ニーリーアドベントカレンダー2024 18日目は ARCHチームの野呂が、借入についての記事をお届けします！

ここだけの話なのですが、我が家のリビングのドアのドアノブが失われてそろそろ1ヶ月経ちます。
リビングのドアにドアノブがないと非常に不便です。
ちゃんと閉まらないのでエアコンの暖気がだだ漏れになりますし、猫が脱走して大暴れします。
皆様におかれましても、リビングのドアノブを持ち去られそうになった場合、勇気を持ってNoを言った方が良い結果を生むことが多いのではないかと思います。
相手がプロで、自分が素人であってもです。
参考になりましたら幸いです。

さて、ここからが本題なのですが、皆様はどのくらい借金をしていますか？
適度に借金をしてきちんと返済すると、信用スコアが上昇し、次に借りられるお金の上限が緩和されがちです。
資本主義では元手が多いほどお金を集めやすいので、借金をうまく利用するのが経営のコツとも言われているとかいないとか。

ではソフトウェア開発の世界ではどうでしょうか？

ソフトウェア開発における借入の定義と、お金の借入の類似点

一般に「技術的負債」と呼ばれているものと大体同じような概念ですが、ここではあえて「技術的借入（以下借入）」と呼ぶことにします。

ソフトウェア開発における「借入」とは、一時的に「読みにくい」「わかりにくい」「本質的ではない」コードを導入して、機能の完成を前倒しにすること（と解釈されることが多い）
「借入」た部分について、バグが発生しやすくなったり、その範囲の追加開発が遅くなるなどの「利子」の支払いを余儀なくされる
「利子」はスノーボールしていくので、時間が経つほど返済が難しくなっていく

良いソフトウェアを作ることが目的なのであれば、基本的には借入はしない方が良い、という結論になりそうです。
しかし、ビジネスでソフトウェアを作っている限り、「良いソフトウェアを作ること」は目的ではなく手段であることが多いと思います。

現実にはそんなことは起きませんが、もし「借入た分だけ早く機能が完成し、前倒しした期間できっちり返済できる」という前提であれば、その機能利益を前倒しして生み出すことにより、同じ労力でより大きな結果を得ることができます。

この「前倒しされたタイミング」から「元々リリースされるはずだったタイミング」までを便宜的に「返済猶予期間」と呼ぶことにします。
「返済猶予期間」にもリリースされた機能は利益を生み出します。 さらに、この返済猶予期間にはリリースによる学びや反響などが蓄積されるため、最初から内部品質を高く作り込むよりももう少し情報が多い状態で構造を決定できるという利点もあります。

しかし、上記のようなことは現実ではなかなか起きません。

では現実的には？

現実世界では、日々以下のような事態に陥ります。

「そのままのコードの上に機能を加える時間」よりも「内部品質を高く保つために既存のコードを変更するのにかかる時間」の方が大きくなりそう
機能を完成させる方法は見えているが、どうやったら品質を高くすることができるのかわからない
「その機能」を締切までに完成させなければサービスの存続が危うい

そして、そういう状況に直面した時に人は「借入」を選択します。
『3のような特別な状況以外「技術的負債」と呼ぶべきではない』と言われることもあるようですが、僕はどちらも「返済が必要」という意味において「借入」だと思っています。（なので、あえて借入と呼んでいます）
人類には最初から完璧な設計は行えないので、機能を増やしていくとどこかのタイミングで必ず借入は行われます。
であれば、「何を借入と呼ぶか」ではなく「どうやって返済するか」を議論した方が良さそうです。

ソフトウェア開発における借入の定義と、お金の借入の相違点

そう、借入というのはメタファーに過ぎないので、当然相違点があります。
特に僕が大きいと思っている相違点を2つ挙げてみます。

お金の利子の増量は期間により一定だが、開発の借入は「参加人数」と「借入箇所の変更頻度」によって 利子の増量が大きく変化する
お金の借入は「借りた人」や「組織」に返せば良いが、開発の借入は「どこを」「どんな風に」「何故」借りたのかが返済に必要な上、 そのコンテキストが容易に失われる

これはつまり

どこが借入であるかの目印をつけるべき
判断の背景を残しておくべき
借りた方法によって生み出される利子の量が変わるため、生み出される利子の多い借入を優先的に返済すべき
借入の方法は同じでも、借入れた箇所によって生み出す利子の量が違うため、利子を多く生み出す箇所を優先的に返済すべき

ということです！

では、どうやってそれを行うか？

借入したことをメモる。
借入の種類をメモる。
規模感をメモる。
日付をメモる。
背景をメモる。

それだけ。

借入メモの書き方！簡単７ステップ！

「あ〜これ、本当はこう実装すべきではないけど、諸般の事情で完成を優先させたいな〜」と思う。今までだったら「見て見ぬ振りをする」か「完成を遅らせる」しかなかったが、今後は「借入メモを残す」という選択肢が取れる喜びを噛み締める
借入箇所か、関数のコメントか、クラスのコメントのうち、適切なところに TODO: DEBT と書く
一体何が借入に相当するのか、分類一覧を見て一番近いアルファベット1つを書く Dなど。（分類の一覧はAppendixを参照）
- TODO: DEBT D
1〜5の規模感を主観で選んで分類の横に書く
- TODO: DEBT D3
日付を書く
- TODO: DEBT D3 2024/11/20
借入を返済するチケットをこの時点で作成し、URLを横に書く
- TODO: DEBT D3 2024/11/20 http://…
コメントを書く
- TODO: DEBT D3 2024/11/20 http://… この借入の完全な返済方法を思いついたが、ここに書くには余白が足りない　※余白が足りない場合は、チケットに詳細を書く

借入メモのレビューやその他

PRレビュー時、レビュアーも、種類や規模間に違和感がないかレビューする
またレビュアーが「あれ？ここちょっとよくない実装だけど、直してたら追加で1週間くらいかかるかも…」と思ったら、「借入メモを残す」という選択肢が取れる喜びを噛み締める
ここ借入っぽいからメモ書いといて、というコメントをつけるなどする
リリース後、可及的速やかに返済するが、優先度の判断は都度行う
負債の総量をモニタリングすることで、常にコードのヘルスチェックを行う
- CIでチェックして、どの部分に借入があり、合計どれだけの規模か、増えるペースがどうかなどを可視化できると尚よし！
借入メモがある部分に、返済する前にさらに手を加える場合、借入メモを同じ箇所にもう一度書く
- ↑これによって、どの部分が多くの利子を生み出しているかが可視化されます

ニーリーでの運用

実はこのルールを弊社で取り入れてからそれほど時間が経っていません。
そのため、どのくらい上手くいくかは未知数ではあります。
ただ、少なくとも借入を選択する際の心理的な負担が軽くなったことを感じています。
これ以外にも借入を検知したり返済の効率を良くしたりする取り組みがいくつかありますが、それはまたの機会に。

お読みいただきありがとうございました！

Appendix 借入の種類早見表


名前	内容	略称	Initial
影響範囲が広い	やれば終わる > 影響範囲が広過ぎる	widespread	W
実装が汚い	やれば終わる > 影響範囲が狭いがダーティ	messy	M
規約違反	規約に反している > 沿うのが大変	cumbersome	C
規約の見直しが必要	規約に反している > 規約を見直したい	unrealistic	U
仕様に問題がある	やるにも準備がいる > 仕様上の問題	specification	S
設計に問題がある	やるにも準備がいる > 設計上の問題	design	D