システムは複数のプログラムで構築されるけど、複数のプログラムを持ち寄ったからと言って「システム」にはならないんですよ。
そこに決定的、徹底的、絶望的に欠如しているのが、構造、規約であり、それを理解して主導できるエンジニア、名前だけアーキテクトでない、本当のアーキテクトです。
これはいくつもの炎上現場を鎮火させて、毎度毎度実感すること。
加えて、今時のシステム、特にWebアプリは成長し続けるのが普通なので、その成長途中の適切な方向づけが必須です。
盆栽にしろ、ガーデニングにしろ、ペットにしろ、子供にしろ、成長するものは、野放図にすれば荒れて価値を減らすというのは容易に考えつくんじゃないでしょうか？
オイラの手を離れた後、好き勝手やって手の施しようがなくなったシステムはいくつもあります。
直接教えた子エンジニアあたりは問題ないとして、孫エンジニアだったり、「俺ってちょっとできるんです。Webページいっぱい読んでるんで」系の口だけベンチャーホッパーエンジニアが参加したりすると、ぶっ壊れスピードは加速します。
半年もてばいい方で、一年経てば絶望的な状態になるのはザラです。
昔に比べてシステムは巨大になって、巨大になった分複雑になっている(巨大にできるだけのリソースが確保できるようになり、そのリソースを埋めるだけの機能や実装を詰め込めるようになった)ので、その場その場の設定なり思いつき実装を積み上げると、一人のエンジニアで担当できる複雑さなんて高が知れているので、あっという間にキャパオーバーになって、人手が足りなくなるんです。
ある会社で、提供しているサービスに比してエンジニアの数が多すぎますね、と言ったことがある。
「やっぱり」ってんで、エンジニアをどんどん減らしていったんだけど(辞めても、というか辞めさせても補充しない)、エンジニアを減らしてもシステムの構造がそれに比例して何もしなくても自動的に綺麗に整っていくわけじゃなく、加えて新規機能を無理やり短期間でローンチするためにやっつけで開発していくものだから、エントロピーが加速度的に増大していく一方という暴走状態に入ってしまい、早晩破綻が目にみえる状態に陥る。
なんて事例もあったりする。
エンジニアは頭数じゃないんで。
システム部門が人手不足になるのは、そのシステム部門の責任者の能力、知見、特に論理的思考力の欠如のせいです。
これを解決するには、その責任者をどうにかして、ちゃんとできる人にお願いするしかないです。
こんな単純な論理的帰結、なんで誰も到達できないか、理解できないんですよね。