運用フェーズのメンバーの冷遇と既得権益
このような状況が生まれる原因として、その担当者が工程によって工数単価や待遇が変わることが影響している。具体的には、運用フェーズは下流工程と呼ばれ、要件定義や開発工程より、一般に待遇は低くなる。それでも責任感の強い現場は、使い勝手が非常に悪いシステム、言ってしまえば「使い物にならないシステム」だったとしても、発生するさまざまな問題を都度解決してしまう。そして日本においては、何十年もこのようなことがまかり通っている。実際問題として、現場は「運用でカバー」することによって多くの問題を解決してきてしまったのだ。しかし、この事実が別の問題を生む。それは、その構造の欠陥や問題の本質を隠してしまうことだ。
その結果、非常に重要で難易度も高いはずの要件定義フェーズが空洞化してしまった。運用フェーズで発生した問題をその場で解決しまうということは、その問題が要件定義のメンバーに共有されないという結果を生む。要件定義フェーズでつぶしておかなければならない多種多様な問題も、システムの開発や運用フェーズで対処する事態が常態化してしまったのだ。さらに、そのことによって要件定義フェーズが経験値を積めなくなり、要件定義をするスキルが失われた。そして、要件定義が機能しないまま後工程でそれをカバーし続けるという構造的な悪循環を生んでしまった。

運用でカバーが生む悪循環サイクル
この悪循環によって、「運用でカバー」しなければならない運用負荷の高いシステムが数多く完成した。それでいて、そのような最適な運用を実現している運用のメンバーの待遇は低くなりがちだ。要件定義はもちろん、開発フェーズと比較しても運用での待遇は低いことが多い。要件定義は社内も社外も優位な立場の組織にいる担当者が一般に実施する。つまり、ここでも前回述べたような企業や組織、利益構造による力関係が影響を与えているのである。
そして、この構造には企業規模や業界でのポジショニングによる複雑な既得権益が絡み合い、ステークホルダーが数多くいることで問題の全貌を見えにくくしている。数万人~数十万人の従業員規模の巨大企業グループやグローバル級の有名企業たちが、この構造の頂点付近を寡占している。それ以外のベンダーもこの業界で仕事をするには、その枠組みへ入らざるを得ないのだ。そのため、この状況に表立って異を唱えることは難しく、何度も崩壊の可能性が叫ばれつつも、現在まで連綿と続いている。