はじめに
質とスピード / Quality and Speedで言われているように質がスピードを上げるという考えが正しく、1月以内に内部品質への投資の損益分岐点が現れるという前提に立って考えています。
略語について
結論（個人的な考え）
- プロトタイピングは内部品質が低くても構わない。
- MVPはピボットのパターンによっては捨てるコードが大量に生まれるので、内部品質が中程度になるようにする（内部品質が高い部分と低い部分を持つようにする）。
- 普通のサービス開発（PMF後に相当）では、内部品質が高くなるように開発する。
開発が関わるビジネスの各ポイントを3つにわけて考えてみた
プロトタイピング
ここでのプロトタイピングは、
- プロダクトに組み込まない
- 十分に小さく、極めて短期（1月以内）で開発できる
を満たすようなプロトタイプの作成です。
極めて短期で作られ、変更が従来のものの延長線上にないような形で行われることが多いのならば、ここは内部品質が低くてもよいと思っています。
MVP（PMF達成前）
一般的なMVPをイメージしています。
ここは通常であれば、継続した開発が行われるので、内部品質を高く保つべきだと思いますが、特定のピボットのパターンではコードを大量に捨てることになるので、内部品質は中程度（高い部分と低い部分が顕著に混在する）に保つべきだと思いました。
ビジネスの動向を注視して、（PMFを目指して行うため難しい部分が多々あると思うが）品質を高くしておくべき部分と、低くても問題ない部分に切り分けてうまいこと取り組むのが理想的だと考えました。
ガチのスタートアップで生きるか死ぬかだという考え方があったとしても、1月で損益分岐点が来ることを考えると保守性を軽視することは死期を早めることにつながるので、正しく作ることを意識したほうが得策だと思います。
普通のサービス開発（PMF後）
ここは品質を高く保つことでスピードを上げるという考え方をそのまま適用できると思います。
終わりに
新規事業に関わることが多くなり、どの程度の品質でソフトウェアを開発すべきかと悩むことが多かったため、一旦自分なりに整理してみました。
プロトタイプをプロダクトに組み込まないという考えは、しっかりとビジネス側と合意に至っておかないと破綻するため、気をつけたほうがよいです(プロトタイプをプロダクトに組み込まないという考えをもたない現場もあると思うので)。