>古いソースコードですと１５年以上も昔の物もあります。
>今後いったい、いつまで使う事になるのでしょうか？
>（中略）
>早く生産的な仕事に復帰したいです。
コボルならまだいい方で、うちなんかだと大昔のアセンブラのプログラムも動いていますから、そんなのには誰も手が出せないという状況です。
うちの事情はともかくとして、一般に企業が自社保有・維持しているシステムの場合、
そこそこ動いている既存システムを再構築するというのは、
(1) 新旧システム移行の手間（ユーザ対応含む）・リスクを考えるとＩＴ部門がまずやりたがらない。（「生産的な仕事」とも思えない）
(2) また、ＩＴ部門がやる気になったとして、経営者を説得するのが難しい。（投入・算出効果を示しにくい）
ということで、古いプログラムがず〜〜〜〜っと動き続けることになると思います。
下記のような外部事情がない限り「耐用年数」って来ないんじゃないでしょうか。
(1) ハードが生産中止になって、しかも保守対象外になる。
(2) メーカー提供ソフトがサポート中止になる。
(3) 上記にもかかわらず使い続けて来たシステムが、2000年に至っていよいよ寿命となる。（ベースのハード・ソフトがダメなため）
2000年問題をクリアしたプログラムは、まだ暫くず〜っと動くでしょう。
本当は、経営レベルが下のような認識を持ってくれると良いのですが。
（例えばマンスリーバッチベースのような、レガシーなシステムを使い続けていたのでは、）
(1) 企業自体の機動性、顧客サービスのレスポンス等の面で競争上不利。
(2) 生産性が上がらない。却って人件費・物件費がかかるので競争上不利。
つまり、経営上の戦略課題として認識する。（ってどっかで聞いたような．．．）
2000年で一般的に問題意識が高まっている現状は、そういった意味では追い風ですから、レガシーシステムを再構築しようと動きだしている所もあるようです。
でも、今、この時期にそんなことをして、2000年対応を積み残したんじゃシャレになんないですよね。（可能性大）
>冗談ですが、また西暦ｘｘ年対応もあるような気がします。
内部的に「昭和」を使い続けているシステムでは､その前に、「昭和100年対応」が必要、なんて話も聞きます。
>旧石器人？（業界ＯＢ）が元気なうちに、やりとげてもらいたい気持ちです。
旧石器人が書いたようなプログラムは、教育上よろしくないので、若い人間には触らせたくないんですよね、本当は。
そういう意味でも、シルバーでベテラーンなエンジニアーの皆さんの活力を活用したいものです。（でも、そーゆー奴等は偉くなっているので、一日中会議で茶飲み話をしているのだ。）