ゴンザレス様は、このような業界の人でしょうか？
内容は、私にとって難しいですが、実際の現場の状況の大変さが伝わってきました。
そんな現場を経験する事の無い、今の自分に感謝さえします。

ところで、私は、パソコンが好きなので、プログラマの仕事も考えた事があります。
また、元プログラマと言う人にも、多数会った事があります。

プログラマと言う仕事に、大変興味があり、いろいろと聞いてみました。
あの頃は、まだ、プログラミング言語の１つも分かっていなかったので、具体的なことは分かりませんでした。
まだ、オブジェクト指向の概念すら、ままならない時だったと記憶しています。

その様な人から、実際の仕事の大変さを聞かされ、断念しました。
過去の仕事について語る時、開放感に満ちた笑顔がとても印象的でした。

誰もが、あのような仕事を、二度とやりたくないと言っていました。
その過酷さは、○○歳定年説と、普通では考えられない年齢で仕事を辞める現状を聞いたこともあります。
納期など間に合った事が無いなど、普通では考えられない事が起こるのも、この業界の特徴ではないでしょうか？

私は、趣味でプログラムを作るぐらいですが、それでも実際の大変さは想像できます。
しかし、チームとなると個々の実力差の関係から、想像を絶する大変さではないでしょうか？
個人でやっている場合は、バグが出ても、ある程度予想は出来ます。
仕様などの関係から、原因不明って場合もあるかもしれません。
でも、それなりの対処は出来ると思います。
それが、チームとなると想像できません。
もし、その様な経験をしたことがあるなら、経験談などを聞かせていただけないでしょうか。
どうぞ、これからもよろしくお願いします。

ありがとうございました。

　データをやりとりする経路の数は、ターミナルの数の二乗にほぼ比例します。

　ほぼ同じ大きさの２社のコンピュータシステムを統合すると、仕事量は２倍ではなくて、４倍になります。

　従って、統合システムの構築に必要な作業時間・検査作業時間や費用を、ターミナル数に比例すると考えて(上の例では２倍になると考えて)見積もりすると、検査作業時間が不足し、十分なデバックが出来ないままシステム運行に踏み切ってしまう事となります。
　しかし、実際の工事世界では、このような二乗効果が考慮されず、見掛け上の量に比例した見積もりが行われる事がしばしばあります。

　プログラムの世界は、仕事を分割してグループ作業とする事が難しく、最初から最後まで、ボトルネック作業となりがちだと思います。

　その上に、ＳＥ(システムエンジニア、プログラマー)は、システム統合前の旧システムのプログラム構造がどうなっているのか、解読のための時間をかなり削かなくてはなりません。

　この結果、現場作業員に過剰な負担を強いたり、時間不足によるエラーが発生したりします。