はじめに
現場で「技術的負債が溜まっている」という言葉を耳にすることは珍しくありません。
古い実装や場当たり的な設計、当時の制約による妥協などが、後から足かせになるという話自体はよく知られています。
ただ、実務で実際に時間を取られる場面を振り返ってみると、必ずしもコードの問題ばかりではないと感じることが多いです。
「なぜこの仕様なのか分からない」
「これを変更して良いのか判断できない」
こういった“判断できない状態”に直面することの方が、精神的にも工数的にも重い場合が少なくありません。
判断の負債とは何か
コードは読めば、ある程度その意図を推測できます。
一方で、仕様や構成に関する判断は、理由が残っていなければ読み取ることができません。
誰が決めたのか。
なぜその選択肢を取ったのか。
他に検討された案はあったのか。
これらが分からない状態では、正しそうに見える変更であっても踏み出しづらくなります。
この「判断できない状態」そのものを、ここでは判断の負債と呼びたいと思います。
ReadMe整備で感じたこと
最近、リポジトリ内のReadMeを整理する機会がありました。
ReadMe自体は存在しており、内容も一見すると破綻していません。
しかし、読み進めるうちにいくつか疑問が湧いてきました。
いつ書かれたものなのか分からない。
どの利用者を想定しているのか分からない。
そもそも、このReadMeを残すこと自体が今も目的に合っているのか分からない。
結果として、「消して良いかどうか」が判断できませんでした。
更新するにしても、何を正とすべきかが分かりません。
触らないという選択肢だけが、消極的に残っている状態でした。
発生したのは軽微だが確実なコスト
最終的には関係者に確認し、当時の経緯を追い、判断することはできました。
ただし、その過程で一定の工数が発生しました。
コードを書いたわけでもありません。
新しい機能を追加したわけでもありません。
判断の材料を集めるために時間を使った、というだけの話です。
このとき感じたのは、これは技術的負債というより、判断の負債に近いということでした。
実装の問題であれば修正すれば済みます。
しかし、判断理由が失われているものは、修正のしようがありません。
判断の負債が生む停滞
当時、そのReadMeが書かれた判断が間違っていたとは限りません。
当時は有効で、必要だった可能性も十分にあります。
問題は、今それをどう扱うべきかという判断ができなくなっている点にあります。
この状態では、改善のための議論すら始めにくくなります。
結果として、触らないことが最適解になり、停滞が生まれてしまいます。
【おわりに】
システムが長く使われるほど、先に失われるのはコードではなく文脈だと感じています。
そして文脈が失われると、判断ができなくなります。
完璧な対策はありませんが、判断の理由を簡単にでも残しておくことには意味があります。
正解を書く必要はありません。
何を優先し、何を捨てたのか。それだけでも、後からの判断材料になります。
コードは読めば理解できます。
しかし判断は、理由が残っていなければ読み取れません。
判断の理由が失われた状態は、それ自体が負債になるのだと思います。