巷では、ITエンジニアはX歳程度になると、コストパフォーマンス的に利用価値がなくなる、と言われていました。
（Xには35とか45とかが入ります）
ほとんど都市伝説です。年齢よりも個人の能力の方が大事です。
とはいえ、簡単に解説しておきたいと思います。
例えばプロジェクトの予算配分で考えてみましょう。
開発コストとエンジニア単価
開発予算が3000万円のプロジェクトがあったとしましょう。
かつ、人件費は以下のとおり。
若手エンジニア単価：月３０万円
年配エンジニア単価：月６０万円
この条件ですと予算の中で、
若手エンジニアは１００ヶ月雇うことができますが、
年配エンジニアは５０ヶ月しか雇うことができません。
そのため、この例では年配エンジニアは若手に比べて倍近い生産力がなければ、不利ということになります。（とはいえ、現実はここまで如実な年功序列にはなりません）
然るべき経験と学習を積めば、ひとりのエンジニアが新米エンジニアの１０倍の成果を出すこともできます。
結局は個人の能力次第というわけです。
まったく同じ条件でしたら、将来性のある若い人が有利かと思います。
年齢が高くなるにつれて、期待値が高まるのは当然のことです。
年功序列制度の功罪
日本の企業には以前から年功序列の慣行があり、『長い年月を勤めると、必ずしも能力に比例せず、待遇がよくなる』というスタイルが定着していました。
欧米型の雇用システムからすると、これは異質なものですし、外資系やベンチャー企業からは、悪しき文化と扱われることがあります。
しかしながら年功序列にもいいところがあります。それは、『腰を据えた教育体制を構築できる』という点です。（閉鎖的で封建的と言えばそうなりますが・・）
ガチガチの成果主義＆学歴主義の元では、できる人は勝手にでき、できない人はずっとできない、という状況になりがちです。
一方、年功序列的な組織の場合は、『基本的にはずっと在籍して、上下関係の中で業務知識を学び続ける』という構図になります。また、会社への帰属意識も高いようです。
まあ、どちらが正解かはわかりませんが、ほどほどに成果を見てもらえ、ほどほどに腰を据えられる会社がいいな、とは思います。
大事なことは、どんなやり方の会社が自分に合っているか、ということではないでしょうか。
自信があるなら能力重視の会社。じっくりと働きたいなら、年功序列の風土がある会社、などと切り分けて考えてみてはどうでしょう。
年齢と立場
従来型の体制では、年齢とともにエンジニアはマネージメント職などにシフトしなければならないケースが多いです。
しかしWEB系の企業や前進的な企業では、給料に見合う生産性や創造性を発揮できれば、シニアエンジニアとして開発現場で活躍し続けられます。
とはいえ、年齢に従って、カバー範囲を広げていくことは重要です。
40代ともなると、コミュニケーションが苦手でプログラミングだけに特化している、という人は同じ条件の若手に入れ替えられていくことが多いように思います。
（著書が複数ある。オープンソースの開発に貢献している。その他大きな功績がある。などの付加価値がない限り、技術一本では厳しいのも現実です）
経験年数に応じて、「マネジメントが得意」「経営が分かる」「デザインなどもできる」「インフラが得意」など、カバー範囲を広げていくべきだと思います。
