すべてのコードは負債という考えが好き
なぜなら、コードは資産ではなく負債だからです。つまり、コードが増えれば、ソフトウェアにバグが持ち込まれる経路が増えることとなり、プロジェクトを維持するコストもさらに高くなってしまう、ということです。そのため、この問題を解決するためには、コードは最小限にするべきなのです。
単体テストの考え方/使い方 という本のP10に書いてある。
コードは負債。この考えが好き。
ただ、資産ではない、とまで言っていいのかは分からない。
負債かつ資産なコードもあるのでは？と思う。
(コードと言うよりプロダクトに関してですが)こちらの記事に書かれているようなイメージ。
プロダクトは作った瞬間に負債になる。世の中は絶えず変化・進化していくので、作った瞬間から陳腐化が始まる。それを防ぐために継続的なメンテナンスや改善が求められる。
通常、その負債が問題視されないのは、そのプロダクトが負債以上に大きな果実つまり価値をもたらすからである。アジャイルの名のもとに incremental delivery などと言うと聞こえはいいが、要するに負債より多くの価値を生み出すための自転車操業をかっこよく言っただけである。少しトゲのある表現になったが、価値が負債を上回っている間はその自転車操業は正当化されてもよいだろう。
https://note.com/ak_iii/n/nc65032dcc1b6
負債以上に価値を提供できてお金を産み出しているコードもあるだろう、ということ。
事業の成長のためにはソフトウェアの成長も必要である。
新たな機能の追加や既存機能の変更など。
元となるコード(以下、コードベースと言う)が少ないほうが、機能の追加や変更がしやすいということはなんとなく想像できるだろう。
コードが多いほどコードベースの複雑性が増し、理解が難しい状態となる。
機能追加や変更時の影響範囲が広くなり、一つのバグ修正作業だったはずが新たなバグを生んでしまったり、ソフトウェアの一部を変更すると他の部分が機能しなくなってしまったり。
こちらの記事にあるソフトウェアの劣化に関するグラフのように、時間が経ちコードが増えるほど、複雑度・開発時間・エラー率が上がる。
コードが多ければ多いほど、ソフトウェア・事業の成長スピードが遅くなってしまい、逆に少ないほどソフトウェア・事業の成長スピードが速いと思います。
だからこそ、できるだけコードを書くことを避けたい。
新しい機能の要望があったとしても、その機能が実際に使われ、価値を生むかどうかは、実際に試してみないとわからないことが多い。
（もちろん、「課題は何か？」「そもそも何のためか？」という点は考慮した上で）価値の検証方法として、
- コードを書かずに検証できないか
- どうしてもコードが必要なら、なるべく少ないコードで検証できないか
を模索していきたい。
たとえば、コンシェルジュ型MVPやオズの魔法使い型MVPのように、コードを書くことなく人力で課題を解決できないか。
どうしてもコードが書く必要がある場合は、なるべく機能・コードを少なくできないか。
さらに、既存のコードベースに極力依存せず、・他からの依存もない独立したスククリプト的コードのようなもので対応できないか。
など。
人力で解決したり運用でカバーするのはそれ自体が工数がかかるが、
短期的な効率化のためにコードを追加することが、長期的には負債を増大させ、組織全体のアジリティを低下させるリスクがあるなと。
Discussion