同氏が説明した開発効率の向上はその多くが「サイクルを短くする」という言葉で説明できる。エディット -> コンパイル -> デバッグのサイクル、check-in -> テスト -> 退行バグの発見のサイクル、これらのサイクルを短くして回転を早くすることで生産性を向上させようというわけだ。同氏はこの効果として、単に時間が短くなるだけではなく、大胆な変更をもっと簡単に、気軽に行えるようになると説明する。また、単純作業を自動化することで複雑な、本当に人の頭を使う必要のある問題にデベロッパが集中できるようになる。同氏は「ちまたにはagile developmentと呼ばれているもはここからはじまるのでは?」と述べる。エンタープライズのチーム開発でagileの実践はなかなか難しいかもしれないが、同氏が挙げたようなことは実践も現実的かもしれない。

「自動化自動化これまた自動化」。川口氏は最後にこう述べ、どんなに小さな無駄も見逃すべきではない。小さいことの積み重ねが生産性を上げる、と常に生産性に注意をはらう心掛けが重要とした。「是非、早く家に帰りましょう。コンピュータなんかに向かっている時間はなるべく短くしてうまいものでも食べましょう」。会場は川口氏のジョークに沸いていた。ところで、このセッションのタイトルは「定時退社のためにJava」なのだが、川口氏は定時に帰れているのだろうか…… 未踏のプロジェクトも抱え、JAXBなどにも関わる川口氏は実際のところかなり忙しそうなのだが。

これぞ、三大美徳のJava版?

川口氏の話は、Perlの生みの親であるLarry Wall氏の「プログラマの三大美徳」を思い出させる。これはLarry Wall氏の著書"Programming Perl"(Larry Wall/Tom Christiansen/Jon Orwant, Third Edition July 2000, O"Reilly, ISBN: 0-596-00027-8)に書かれた有名な一節で、"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."(プログラマの三大美徳は怠惰・短気・傲慢である。是非これを身につけてもらいたい)というもので、laziness/impatience/hubrisはそれぞれ巻末の用語集にまで登場し、その重要さが詳しく解説されている。この三大美徳はハッカー文化の生み出したもの、という気がするが、Javaコミュニティには意外とこういった気概が欠けているのではないだろうか。

J2SE 5.0時代のJavaはEoD(開発の容易さ)をキーワードとして生まれ変わった。しかし、いくら言語やフレームワークレベルでの改善が進もうとも、チーム開発や日常の業務においてJavaデベロッパ自身が変わらなければ、効率化は進むわけがない。もちろん、一部の開発者を中心としてagileなど変革の動きは既に出てきている。しかし、大多数のJavaデベロッパはどうだろうか?

真剣に考えてみて欲しい。

• J2EEはDIやAOPの源流ともいえるものを多く持ちながら、どうしてJava EE 5の時代までそれを活かす方向に進化できなかったのだろうか?
• どうしてEJBはパーシステンスに専念せず、実際に使われない分散環境を指向してしまったのだろうか?
• Ruby on Railsでいとも簡単にできることがどうしてJavaでは複雑なのだろうか?
• LispやSmalltalkでたやすくできるメタプログラミングがどうしてJ2SE 5.0のAnnotationまで実現されなかったのか?
• エンタープライズJavaのコンフィギュレーションはどうしてこんなに複雑なのか?

どれもかつてのJavaが抱え、一部は未だに解決されずに残っている問題だ。Javaはこれまでなぜか難解な方向に進みたがり、実践的な解決を志さなかった。

SunをはじめとするJavaベンダがこうした問題のうち多くを解決してきたことについては、もちろん大きく評価するべきだろう。後方互換性を保ち、かつ標準規格としてJavaをここまで便利にしてきたJCPの払ってきたコストも多大なものだ。その一方で、Rubyをはじめとした後発の言語の出現に一部の先進的なJavaデベロッパが不安を覚えていることも確かだ。Javaが第二のCOBOLになってしまうのではないかという声も大きい。

こういったことをJavaのせい、もしくはJ2EEの巨大化を図ったベンダのせいと言ってしまうのは簡単だ。しかし、根本的にはJ2EEを使う大多数のデベロッパがその要求を声に出さなかった、もしくは本当の要求を認識できなかったことこそが原因ではないだろうか。JCPもJ2EEベンダもデベロッパありきでJavaテクノロジを進化させようとしているのだ。

EoDを確実な成果に結びつけるためにもデベロッパひとりひとりが、いわばハッカー的な気概を持ってJavaを成長させる必要がある。そしてそれは難しいことではなく、小さなことの積み重ねだ、と感じさせられた。まずは川口氏に倣って、こうなればいいのに、こうなるべきという要求をJREのバグとしてファイルすることから初めてみてはいかがだろうか?

オープンソースコミュニティでは上で示したJavaの問題に対して既に多くの解決方法が示されつつある。さらに、Java SE 6.0 "Mustang"世代では、我々デベロッパが開発に参加することが許されているのだ。デベロッパひとりひとりが問題を認識して改善の声を上げることで、Javaが第二のCOBOLとして廃れるのを避けることが出来ると願いたい。