各フェーズ
新規フェーズでは、プログラミングだけで無く、それに先んじて仕様を作らないといけません。
仕様はそれ自体が形而上と言っても過言では有りません。
ですので
- 「どの規模でも自動テストをするべき（実際には小さい部分のみ解が存在）」であっても、
- 「今までに無い素晴らしい何か」（実際には何十年も解が無い）であっても、
仕様を作る上での、大切な基礎となると思います。
しかしながら、
保守フェーズでは、もう、定まった、仕様とは並立した秩序が出来上がった後に、それを変更したり最新化したりする訳で、解が無い提案に対して、保守作業と等価とされると非常に困ります。
データの意味やそれをサポートするプログラムは、仕様に則ってはいますが、独自の秩序であり、全てが形而下の作業です。（後述）
保守フェーズで、その様な事を提案したい人は、その人が費用を出すべき（形而上の提案の価値は低い）です。
さらに、
運用業務は、その出来上がった秩序を、変更したりも、最新化したりもせず、外から監視するだけだと思います。
歴史的観点
- 新規開発も、保守開発も、運用業務も全て同じ組織で担って
いました。
それをその後、
（大変だけれど大変もうかる）運用業務や、（大変でもうからないけれどしないといけない）保守開発を、別の組織が（その業務の中心人物を中心として）
- 持っていってしまう（スピンオフ？ 違う？？）
ことが有りました。
それを考えると、のちの運用組織がDevOpsとか言っているのは、
- 単なる自業自得（いいとこ取り、クリームスキミング）
にしか見えません。スピンオフしたいと言い出したのは運用組織の方で、それでかなり儲けたはずです。調子が悪くなってから、みんなの事を考えようとか言うのは不誠実です。
さらにその後、形而下関数型プログラミングの一思潮として、
- プログラミング中のチェックやログは、テストがしにくくなるし、コストもかかるので、良く無い👎
と言う考え方が出て、運用組織をさらに窮地に追い込む風潮になりました。
新規開発も、保守開発も、運用業務も同じ組織で担っていれば、（我が事である、将来の）運用の為に最善を尽くして、チェックやログを入れたり、それ以上の事をしたりもするはずですので、
スピンオフ先の事など、考えない方が妥当だと思います。
ここではこれ以降、その様なスピンオフの問題は考えない（内製ほどドラスティックでは無いが、その3つを同じ組織で担うと言う、それなりに大変な組織構成を想定）とします。
それにより
それにより、
- DevOps
- 毎回、新規開発とし、保守の為の設計やフレームワークを省く
（出来た試しが有りません。そのつもりで作っても、新規開発は1回切りとなり、保守の事を考えていないシステムを保守する羽目になったりします。）
と言う、3つの内のどこかにとって都合の良すぎる（現実世界でも、成立していない）考え方は無視できます。
上代に立ち返って考えると言う訳です。
結論
これからも「投資を呼ばない形而上の提案を形而下のそれと等価だと言われる」事でプログラミングが嫌いになる人は存在し続けることでしょう。
