ついに顕在化しはじめたのか？「.NET Remotingリスク」

英語圏ではかなり前から.NET Remotingで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ。日本でもそう遠くない未来だと思う。

若手エンジニアの不足

ASP.NET WEB APIのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く、需要も供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況が.NET Remotingに起きている。特に深刻なのは安価な若手エンジニアの採用が絶望的に難しいという現実だ。WCFが台頭して数年経ちRESTfulがメインストリームの先頭を突っ走る2013年において新しく.NET Remotingを勉強しようとする若者はよほどの物好きしかいない。30~40歳の.NET Remotingエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価な20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹に.NET Remotingを新たに学ぶ若者は絶滅寸前だ。

とても優秀な若者を雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「.NET Remotingは習得していますか？」「もちろんWCF Data ServiciesやASP.NET WEB APIはお手の物です。WCFもある程度可能です」「もう一度伺いますが.NET Remotingは習得していますか？」「申し訳ございません 未習得です」

悲劇だ。

イノベーションの枯渇

もう何年も.NET Remoting界隈で新しいモノが生まれたと言う話を聞かない。こんな事を言えば.NET Remotingハッカーは激怒するかもしれないが、しかし現実にWCF Data ServiciesやASP.NET WEB APIに比べればこの10年の間に.NET Remotingから生まれたものは微々たるものだ。何かしらのライブラリにしてもwebサービスにしても、ハッカーが新しいモノを試す土俵にはいつもWCF Data ServiciesやASP.NET WEB APIが選ばれて来た(もちろんSignalRもね)。

もはや彼らが.NET Remotingを選ぶ理由はただ一つ「今.NET Remotingで開発しているから仕方なく」

最低の理由ではないだろうか。

10年前に.NET Remotingで開発していた企業は最先端を走っていた。迅速に分散システムを具現化するツールとして.NET Remotingは最適だった。それが今やどうだろう。自分たちの書いたコードを保守し続けなければいけないという理由「のみ」で.NET Remotingを使い続けている。他に理由など無い。.NET Remotingで開発する理由は自分たちの過去の仕事を保守しなければならないという理由のみだ。

控えめに言っても、そういう企業に未来は無いと思う。過去とは決別し、10年後の自分たちにとって最適な選択をすべきだ。今すぐにだ。本当に手遅れになる前に。

元ネタ： ついに顕在化しはじめた「Perlリスク」