オーケストラのバイオリン弾きがプログラマになった

大学は筑波大学の理学系ですが、もっぱら学内オーケストラでバイオリンを弾いていましたね。卒業は1991年。バブル崩壊の予兆はあったものの、まだ理系学生が金融業界に競って就職するような時代でした。

幸いというべきか、株式投資をしていた父親が「なんかきな臭いぞ。バブルは崩壊するぞ。これからは地道に製造業だ」とかいうので、あまり深く考えずに日本板硝子という会社に就職します。金融機関に就職した同級生の中にはその後、大変な憂き目にあった人もいました。

新入社員研修で、マイコン実習という課題があったんです。僕は小中学校のときからPC-8001あたりでプログラムを書いていて、マイコン雑誌に付いているコードのデバッグなんかしていた少年でしたから、研修でも目立ったんでしょうね。

板硝子本体ではなく、すぐに情報子会社のNSGインフォメーションシステムに出向になり、それ以来ずっと情報畑を歩むことになります。このNSGインフォメーションシステムの後身にNTTデータが資本参加してできたのが、前職のNTTデータビジネスブレインズという会社です。

NSG時代は、当時のNECの汎用機ACOS向けの電子帳票パッケージソフト（現在の「Pandora-AX」の前身にあたるもの）をC++言語で開発したりしていました。マイクロソフトのMSDNに紹介されているAPIを全部覚えてやるぞと、それこそ舐めるようにして勉強したのを覚えています。

外部のお客さん向けのSI案件も手がけました。なぜかファイル交換システムというのが多かったですね。自社がプライムになって取る案件もありましたが、多くは大手のSIerから仕事をわけてもらい、部分的に開発するというもの。少人数のチームで、C、C++、Java、.NETなどを使って開発していました。

正月にパッケージ丸ごとJavaで書き直す。「漏れない」Javaに夢を託して

Javaについては、最初は「自分の仕事に関係ねぇな」と思っていたんですが、1998年にJava EEが発表され、「エンタープライズ」だとか「サーバーサイド」とか言われるようになってからは、強い関心を抱くようになりました。

その頃のJava EEについての僕のイメージは「C++言語に文法や記法が似ているから習得しやすいし、それでいてメモリリークを起こさないらしい」というもの。これは僕だけじゃなくて、当時のプログラマはみんなそう思ったんじゃないかな。特にメモリリークやハンドルリークなど、いわゆる「漏れる系」でOSが死ぬのをさんざん経験しているC/C++プログラマにとっては、夢のような言語だったんです。

C++で開発したもののメモリリークやハンドルリークで動作品質が難航していた某パッケージのソースコードを、正月休みかけて全部Javaで書き直したこともありました。拡張子を変えて無理矢理コンパイルするみたいな、無茶なこともやりましたね。

ただ、当時はJava EEについて日本語情報がほとんどなかったんです。英語のリファレンスを読み、APIをいじって、「こういうことがしたいんだったら、これを使いましょう」というような逆引き的な情報をブログに書くと、結構重宝がられました。それが技術評論社の「JAVA PRESS」の編集者の目に留まって雑誌に記事を書くようになりました。

かつての成功体験のままで止まっている人たち

ブログや雑誌の原稿連載などで「エンタープライズJavaのエキスパート」の一人として目されるようになりましたが、実際の仕事は.NETを使うことが多かったかな。Java EEも使いましたけれど、僕は昔からEJBが苦手でね。あんな難しくて面倒くさいもの使えるかって。当時の非力なマシンでは動作も緩慢でしたしね。

だから、EJBはパスして、自分で“おれおれフレームワーク”を作ったり、Java EE開発を効率化するオープンソース・ソフトウェア（OSS）の開発に参画するなどしてきました。その一つが今でも僕が細々ながらコミッターを続けている、「blanco Framework」だったりします。

もちろん Java EEは企業システム開発のなかで一定の成功を収めます。ただ、この成功の後にどうなったかというと、エンジニアたちが、オープンソースを含めた技術の進歩を活かして、さらに先に進むというより、古い技術のままで思考停止してしまっている状況かな、という気がするんです。

例えば、「Apache Struts」。2000年にStruts1が発表されて広く受け入れられ、2005年頃にはJava Webフレームワークのデファクトスタンダードと呼ばれるほどの普及を見せました。しかし、その後は欠陥も多く指摘されるようになり、特に最近はセキュリティの脆弱性が指摘されています。しかもStruts1はすでにサポート切れ。それなのにレガシーなシステムにはそのまま使われていることが多いのです。

一般的に言って、メンテの終わってしまったOSSを外から見えるところで使い続けるということほど、危険なことはありません。OSSの進化をもっと取り込むとか、サードベンダーがきちんとサポートするツールを使うとか、あるいは標準APIだけを使うとか、セキュリティ対策はいくらでもあると思うのですが、そのあたりがおざなりになっているような気がする。いわば、2000年のままで止まっているんです。

Java EEの将来は魅力的。技術にもっと愛をこめて欲しい

もちろんJava EEに将来性がないというつもりはありません。僕も Struts1に代わる新たなフロント開発技術を模索してきて、JSFに注目してきました。JSF1の頃はしっくりこなかったけれど、2009年のJSF2になってからは、Faceletsが組み込まれることで、見違えるような生産性の向上を感じました。

POJO（Plain Old Java Object）を画面部品に組み込むことができるなど、最初からコンポーネンツ志向だし、生産性という意味では.NETはもちろん、LL系の開発環境も越えるものじゃないかと思えるくらい。構造的にセキュリティホールの発生を低く抑えることができるという点でもアドバンテージがあります。

そういうわけで、最近の僕はもっぱらJSF2、Facelets押しで、そのことはOracleのイベントなどでも盛んに話しているんだけれど、なかなか広まらないですね。それは、みんな枯れた技術を好むということもあるんだけれど、実際の開発プロジェクトで導入しづらいということもあるんじゃないかと思います。

例えば、SIerが新しいJava案件を受注してで来月100人のエンジニアを集める必要があるとします。Faceletsでやるとなると100人はまず無理。Struts1ならそれがたぶん可能。という大人の事情で結局、問題の多いStrutsをいまだ使い続けることになっているんじゃないか。まあ、これは僕の想像ですけどね。

それはともかく、最新の技術、最新の機能について無関心のエンジニアが多いのはどうかと思います。Java EE 7はもとより、Java EE 6についても関心が薄い。格好の日本語の入門書が少ないという事情もあったりするんでしょうけれどね。

そもそも、僕の周辺の若いエンジニアを見ていると、Javaを本当に好きで開発しているのかどうか疑わしいところがあります(笑)。昔のCOBOLのような感じで、レガシーのメンテみたいなスタンスで開発している人もいるんじゃないか。

ついつい最近の流行に合わせて、RubyとかPythonにいってしまう。それを悪いとは言わないけど、自分が関わる言語環境の魅力をとことん引き出す努力も必要なんじゃないか。技術への愛情をもっと深めてもいいんじゃないか、そういう気がします。

---

伊賀 敏樹（いが・としき）氏
エンバカデロ・テクノロジーズ
シニア・セールスコンサルタント
1968年生まれ。筑波大学第1学群自然学類卒。91年、日本板硝子入社後すぐにNSGインフォメーションシステムに出向、NTTデータビジネスブレインズに移籍。パッケージソフト開発からSI開発、システム開発の技術支援等に従事。C++、Java言語の技術情報を「いがぴょんの日記」や技術誌で発信。
blanco Framework、Benten、Pleiades、Eclipse 日本語化言語パックなどオープンソースによるフレームワーク開発も行う。2014年6月、エンバカデロ・テクノロジーズに転職。

自分の書いたコードを誰かに評価されたいエンジニアは、けっこう多い？

ITエンジニアのための実務スキル評価サービス『CodeIQ』で出題されている「コード銀行」問題に挑戦すると、あなたのコードが評価されます。

評価(1)出題者からの評価　　⇒評価フィードバック例を見る

• 企業ではたらくという観点からあなたのコードをチェックします
• フィードバックされた観点をふまえてコードを書くと世の中の企業にとって「いいコード」が書けるようになります

評価(2)企業からの評価　　⇒評価フィードバック例を見る

• 「あなたと一緒にはたらきたい」という企業からスカウトが届きます
• あなたのコードが社会でどこまで通用するか、リアルな評価が得られます

興味を持った方はこちらからチャレンジを！