スピードを優先したソフトウェアで何を得られるか

品質を犠牲にすればソフトウェア開発のスピードは得られるか。

品質を蔑ろにしてスピードは得られるわけがない。品質はその対象が本来備えている特性である。ソフトウェアであれば、要件を構成する機能仕様ではないか。であれば、品質を犠牲にしているソフトウェアには本来備えていなければならない性質が足らないのだから、やることはやらなければならない。

いやいや、犠牲にするとは、その品質として備えていなければならない要件（のうちの機能仕様）の一部を作ることを先送りしているだけ、と言うなら理解できる。ただ、それは機能を犠牲にしているのではなく、機能を段階的に開発しているだけに過ぎず、犠牲は生じていないことになる。

ソフトウェア開発の規模に関わらず品質は、要件のとして存在する。

特に大規模プロジェクト経験したエンジニアは思い出して欲しいのだが、工程の作業プロセスの中にレビューが組み込まれていたはずだ。品質を重視するプロジェクトなら、セルフレビュー、チーム内レビュー、外部レビューなど多段に組み込む。これは作業プロセスの中に品質管理を組み込みことで、作業品質を確保する考えに基づいている。

ついついバグの件数とかに目を奪われがちになるが、本来備えていなければならない要件を機能仕様として備えているかを検証しているのである。言い換えれば、なければならないものを犠牲にすると言う考えはありえない。意思を持って要件から除く以外は。

小さな規模のプロジェクトではどうか。品質を犠牲にしてリリースするとスピードは爆速に得られるか。

要件を備えていないソフトウェアは使われるだろうか。アプリなら、速攻で削除するだろう。あるはずの機能がなくて、使えないのだから。結局、いくら速くリリースできても、使えないものは、直すか捨てるしかない。直すなら、品質を犠牲にして作った時間+直す時間が正味の時間である。捨てるなら、金をドブに捨てたのである。

品質を犠牲にしたソフトウェアで使われ続けたなら、その要件は本来必要とされていなかった要件だ。