見出し画像

技術的負債は毒なのか 2

前回の記事はこちら

日常の開発の中で「エンジニアである自分にとって技術的負債は、まるで毒のようだ」と感じることが増えてきました。

「ここは負債が溜まっているので、改修するには時間がかかりそうです」

もの作りをしている方なら1度は口にするセリフかもしれません。
説明する相手がエンジニアリングの世界に深い理解を持つとは限りませんし、負債は目には見えないのですから納得してもらえない事もあります。

前回の記事の最後に書いたように、負債を悪だとは捉えない考え方もあります。

今回の記事では「負債は本当に忌避すべき毒なのか」について考えたいと思います。

時間の前借り

「Done is better than perfect. 」とはFacebookのマーク・ザッカーバーグ氏の言葉として有名です。
意味は「完璧を目指すよりまず終わらせろ」とされていて、どんなに素晴らしいプロダクトでも出荷されなければ(ユーザーの手に届かなかれば)価値を産まない、という使われ方をされます。

後から機能改修がしやすく、可読性も優れている素晴らしいコードも世に出なければユーザーが使う事は出来ないのですから、自分もこの名言には頷くばかりです。

それは負債なのか

時間の前借りを選ぶ時、それはプロダクトの出荷が最優先される時です。
すでにユーザーが一定いるプロダクトが改善を行う時に、時間の前借りをお行うのは最善ではないでしょう。必要な工数をかけて改善する方が良いと思います。

新しい機能を提供する時、またはプロダクトそのものが生まれる時に時間の前借りを選択する事があるでしょう。
しかし、その時に生まれた改善・改修のしにくいコードベースのプロジェクトを負債と呼ぶべきではありません。

必要として出荷を優先させたのですから、それは資産とする方が適切だと思います。


「積み木の組み立て方」

スクリーンショット 2020-11-25 23.26.51

プロダクトの出荷のように表現すると、想像し難い気がするので
「積み木を組み立てる」
というタスクに置き換えてみましょう。

例えば

要件1
「これから1分で積み木を1mの高さまで組み立てて下さい。5秒間立っていれば良しとします。ヨーイドン!」

という要件があったとします。

組み立てたら5秒間倒れなかったらオールオーケーなので土台とかちゃんと組まなくても、速さ優先で1mの高さまで到達する事を最優先とするのが良さそうです。
(後は倒れないように祈るのが大事かもしれない。)

要件2
「では、今度は10分間あげます。高さは1mのままでいいので1時間は倒れないようにして下さい。ヨーイドン!」

次にこんな要件が提示されたとしたら、どうでしょうか?
前回と同じ組み立て方をするでしょうか?

先程と同じ組み立て方では、どう考えてもすぐに倒れてしまいそうですよね。
ちゃんと土台から設計した方が良さそうです。

つまり5秒間だけ維持すれば良い組み立て方と、1時間維持させる組み立てには明確な違いがあるのです。

技術的負債が毒になるかどうか

要件1で提示された積み木のままで、要件2を達成しようとすると非常に大変な作業になるのは目に見えています。

ここで重要なのは要件1で組み立てた積み木を一度崩してから要件2の積み木の組み立てに入れるか、だと思います。

一度組み上げたのだからと崩すのを勿体ぶってしまうと、その瞬間から
技術的負債が毒と化していくのです。

画像2

5秒間維持する事を目的として組み立てた積み木を、1時間維持出来るようには改修のはかなりの手腕が必要になると思います。

プロダクトの出荷を優先させる為に「時間を前借り」して作り上げたなら、賞味期限をしっかりを意識しましょう。

出荷を優先して作ったのならそれは負債を抱えているかもしれません。
ですが、それを毒にしてしまうのかは継続して改善していくエンジニアにかかっていると、自分は思います。

逆に、ユーザーへの価値出荷が最優先のフェーズなら技術的負債を生む事に対して臆病にならないで下さい。

負債自体は毒ではなく、必要とされて生まれます。
賞味期限を過ぎても捨てられずに使い続けた時、毒になるのです。

負債を毒にしないエンジニアでありたいなって、と願って日々を過ごしています。



この記事が気に入ったらサポートをしてみませんか?