Done is better than perfect(完璧を目指すよりまず終わらせろ).

Up-Free / Pixabay

言いたいこと
最初から綺麗なコード・設計を書ける状態を目指せ。
そうもいかないものは天秤だが、勝手に背負うな。
(中略)
スピード重視、と一口で言いますが、綺麗な設計・コードというのは複雑でもなく記述量も少ないため、最初から書けるのであれば最速です。
技術的負債について考えた – 考えた。

Done is better than perfect(完璧を目指すよりまず終わらせろ).

“開発スピードを優先するのか、それとも技術的負債を発生させないことを優先するのか”という議論はよくある。基本は“it depends(場合による。ケースバイケース).”なのだが、新しいプロダクトを作り出す初期段階では、基本は“開発スピード”を優先させるようにした方が良い。

理由は簡単で、市場は待ってくれないからだ。どんなに素晴らしいプロダクトでもユーザーに使われなくては意味がないのと同様に、どんなに綺麗なコード・設計でも会社に益を齎さないのであれば(=市場に出ていない)意味がない。

また、プログラミングは料理に似ているにも書いたが、

料理と同じように、どんなに優秀なエンジニアでも、決して自分自身でプログラミングをせずに、良いプログラムを作ることは出来ない。
もちろん、プログラミングを始める前に大まかにプログラムの設計をするが、それは仮置きの設計でしかない。そのため、この段階で設計書を書くようなことはせず、プログラミングの作成にかかるのだ。そうやって、プログラミングをし始めて、初めて見えてくることや思いつくことがたくさんある。それらを元に柔軟に設計を変更しながらプログラミングし続け、プログラムが予定通りに動き始めてやっと、設計が完成するのだ。ただ、この作り方だと継ぎ接ぎだからでソースコードが汚くなってしまうので、この段階に来たら、読み易さやメンテナンス性を重視して、プログラムを書き直し、そうしてやっとプログラムが完成する。
このアプローチはテスト駆動開発でも実践されていて、汚く動かないコード -> Green -> 汚いが動くコード -> Refactoring -> 綺麗で動くコードいう具合に進めているはずだ。

基本的に“汚く動かないコード -> Green -> 汚いが動くコード -> Refactoring -> 綺麗で動くコード”という流れになっているので、機能が動作する最速の状態は“汚いが動くコード”になる。

それに加えて、プロダクトを取り巻く外部環境(開発中のプロダクトの競合プロダクトや市場ニーズの移り変わり)は自分たちでは残念ながら制御(コントロール)できないものだ。そのため、なるべく早くリリースし、ユーザに実際に使ってもらうことで、フィードバックを早期に得、よりビジネス価値の高い仕様に変更する必要がある。

一方、技術的負債については適切にコントロールしていれば問題なく返済可能だ。上記のblogでも以下のように書かれている。

技術的負債とは?
技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。
技術的負債について考えた – 考えた。

そして、市場に出ていない段階では“事業が失速したり損害が発生”することはないのは自明の理だ。もちろん、“必ず”スピードを優先しない場合がある通り、バランスが重要だ。どんな技術的負債も生み出す/組み込んで良いというわけではない。

ただ、“Done is better than perfect(完璧を目指すよりまず終わらせろ).”の精神で、「これまだ汚いけど要求仕様/機能は満たしてる(=汚いが動くコード)からとりあえず一旦リリースして、それから修正しよう」というのをよく実践している。ここで大事なのはリリースした後に汚いコードを“必ず”リファクタリングして綺麗にするということだ。